EXAMPLE MAPThe example map features a transport unit that has many features that aren't found within the game. The systems heavily rely on CUNIT EUDs and some are per player as well which will prevent multiple of the same type of units to function. I'll cover them within this post, here are some of the features:
- Ability to land and lift off, changing the unit's status from grounded to in air.
- Ability to release units upon death, like a bunker.
- Ability to attack when a unit is loaded, like a bunker.
- Ability to load units only when on the ground.
- Unit visual changes achieved by stacking 15 units and some sprites.
- Custom damage visuals.
- Custom shadow and landing visuals.
- Ability to load up to 8 of any type of unit.
- Faster than normal unloading speeds.
One thing I forgot to do in the map is to make the stacked units unselectable. This can be done by giving the units to another player, for example p9, and cloaking them. Changing the draw function to 1 will ensure that the unit will not be transparent or invisible. It will however be selectable if detected.
LIFTING & LANDING INFORMATIONEUDDB Address: Flingy Top SpeedLifting and landing of units are done through orders and iscript. There are several requirements for a unit to correctly lift and land. Since it's a feature that is quite unique within the game, there are many things we must accomplish to achieve lifting and landing.
Rules:
- The unit must use an iscript from a Terran building that can lift and land.
- The unit must have the flags 'building' and 'flying building' under DatEdit>Unit>Advanced. If the 'building' flag isn't checked the unit will be able to land but not lift.
- The unit must have an image of a Terran building that can lift and land in multiplayer. Anything else will cause desyncs for some reason.
- The speed at which a lifted building moves is set after the lifting animation. Thus to change this you must use EUDs that affect its speed.
Because of these requirement it will functionally just be a normal flying building. Within the example map I've made the bunker use a command center image and iscript and made it invisible. The EUD address is what I used to change the top speed.
LIFTING/LANDING DETECTIONEUDDB Address: Main Order IDEUDDB Address: Status FlagsWhen a building is lifted it has the 'in air' flag, when on the ground it has the 'groundedbuilding' flag. Buildings will change the flag at the start of the lifting animation and at the end of the landing. Curiously, there's a lifting animation order (76) but none for landing.
The example map will detect both the landing and lifting animation. When the unit starts the landing animation the shadow will detach from the unit and an emp sprite will be created. This will continue until the unit has finished the lifting animation. I don't think it's possible to detect these animations directly without accessing CSPRITE shit so we will have to do them indirectly using the above EUD addresses.
Collapsable Box
CommandCenterLanding:
nobrkcodestart
wait 18
playsnd 472 # Misc\Land.WAV
playfram 4
wait 5
playfram 3
wait 5
playfram 2
wait 5
playfram 5
wait 5
playfram 0
sigorder 16
nobrkcodeend
goto CommandCenterWalking
CommandCenterLiftOff:
nobrkcodestart
playsnd 471 # Misc\LiftOff.WAV
playfram 5
wait 5
playfram 2
wait 5
playfram 3
wait 5
playfram 4
sigorder 16
nobrkcodeend
goto CommandCenterWalking
The above iscript are the landing/lifting animations for a command center. Notice that it has the 'nobrkcodestart' opcode. This is also status flag and we can use this in combination with order detection to tell exactly when the animations are playing. There is, however, a frame when the unit is both 'in air' and 'groundedbuilding' so a timer will have to be used to ensure that the shadow location doesn't move.
This address is another possibility to detect landing but I haven't tested it.
TRANSPORT INFORMATIONWithin the game there are two types of transports. The first would be the normal transport (Overlord, Shuttle, Dropship) the second is the building transport. Each have their own special properties.
Rules:
- A transport is limited to a maximum of 8 different units. This is hardcoded and any additional units will be removed or in transport limbo.
- Transports can only carry units that are below their provided space, this is why many units have 255 required space. DatEdit>Unit>Basic
- Transports will unload all of their units whilst on the ground but only 1 unit when flying. The first unit loaded will be the first to unload.
- Building transports can only load units with 1 space and have both Terran flags checked. DatEdit>Unit>Basic, DatEdit>Unit>Staredit
- A unit can have 0 space and not show up on the loaded window, however the maximum of 8 units will still apply.
- The Bunker unit ID is unique in that it will unload units upon death. However, if it's in the air when it unloads it will only unload 1 as per the previous rule.
- If a unit is loaded within a building transport and it was targeting an enemy it will try to attack the enemy once inside. This will cause a crash if the transport doesn't have the bunker iscript.
The bunker's unique dying behavior is why it was chosen for the example map. This behavior could probably be replicated by detecting when a unit dies and delaying it until the units are unloaded.
TRANSPORT DETECTIONThe
EUD address for a transport's loaded units is unsupported for some reason. We can get around this by detecting either the 'in transport' or 'in building' status flags for the units inside the transport. A building transport will give both flags but a normal transport will only give the 'in transport' flag. Because we can only detect if a unit is inside a transport and not which transport has a unit additional conditions will be required when using multiple transports.
To prevent crashing from units trying to attack whilst inside of a transport we detect when that specific unit enters a transport. If it does then order it to stop, this will clear the target and ensure the unit cannot attack whilst inside.
TRANSPORT ORDERSEUDDB: Main Order IDEUDDB: Main Order TimerThere are several orders that are specific to transports and some that were modified for the example map. I'm unsure of the specifics for the orders, descriptions are only speculation.
- [092] Move/Enter Transport - This order is specific for non-transport units telling them to move and enter a transport.
- [093] Idle (Transport) - Idle order for transport units, allows them to enter the 'load unit' order if another unit wants to enter.
- [094] Load Unit (Mobile Transport) - Will order the transport to move to the target unit to load them.
- [095] Load Unit (Bunker) - Orders target unit to 'Move/Enter Transport'.
- [111] Unload Unit (Transport) - Unloads unit on self. i.e. Bunker or moving unload. If on the ground will unload all at once.
- [112] Move&Unload Unit (Transport) - Unloads units on a specific area. Requires the transport to be in the air.
FireGraft>Requirements>Order
In the example map I only wanted units to be able to load whilst on the ground. Because the 'Move/Enter Transport' order is for non-transport units the requirements for the order must be global as a transport cannot refuse a unit to load. In the example map I set the requirement of the displayed orders to only work if Fenix is owned by the player. Fenix is created when the transport is in the air. Unfortunately because the requirement is global this system will only work with 1 transport unit. I've tried using the technology requirement but couldn't get it to work.
When transports in the air unload units there's a timer that dictates the rate at which it can unload. This timer is the Main Order Timer. By changing this value to 0 it's possible to speed up the rate at which a transport can unload units. I believe the reason why units cant unload once per frame has to deal with hardcoded rates.
CRUSH PREVENTIONDatEdit>Unit>AI Actions
Units such as Interceptors, burrowed units, powerups, and Siege Mode Tanks are crushed when a building lands on them. Crushing is hardcoded to kill the unit and death prevention EUDs will not stop a unit from dying. This has to do with the right-click movement action of the unit. By changing the right-click action to something that moves you can prevent a unit from being crushed. I believe that it's dependent on a flag as burrowing units do have a movement right-click action but I'm unsure of which one.
ADDITIONAL UNIT TURRETSSubunits PostThe example map detects if a unit is loaded within the transport. If it is, then a wraith will be given to the player so it can attack. The wraith has a tank turret that's invisible and only the Siege Tank(Tank) Turret Attack Overlay (536) can be seen when it attacks. Although this system isn't the same as an actual subunit or bunker it will be functionally and visually identical to one. The map only has one wraith but more can be added if desired.
DatEdit>Unit>Advanced
Single Entity prevents the Wraith from being selected with other units.
Permanent cloak will make it always cloak like DTs or Observers.
Change the subunit to something else, in this case Duke Turret.
DatEdit>Unit>AI Actions
For the Duke Turret change the AI Actions. The normal subunit actions are tied to its parent unit and since the parent unit will always be moving the turret wouldn't be able to attack. The building actions are independent and this will make the turret attack when moving.
DatEdit>Image>General Properties
Uncheck the 'draw if cloaked' box for the Wraith and Siege Tank (Tank) Turret images. Uncheck 'Graphics Turnable' and 'Clickable' for the Wraith. This prevents it from turning (permanent 0 frame) and being clicked.
Datedit>Image>Graphic Properties
Siege Tank(Tank) Turret Attack Overlay is the muzzle flash overlay the tank uses when it attacks. Since it's a separate image it will be visible if cloaked. Change the iscript to Bunker Overlay to have it flash multiple times per attack.
DatEdit>Flingy
Change the Wraith's movement properties to make it as fast and responsive as possible. This is to ensure that it will always follow the host unit.
Have the Wraith always ordered to move to whatever the host unit's location is. Unfortunately move triggers do not work as it resets their targeting whenever moved. Because the Wraith is very fast it will always maintain a constant position over the host unit. The Tank Turret placement isn't centered on the Wraith so you may need to offset the destination location a bit to ensure it matches up correctly with the host unit.
Whenever a unit is detected to be within the transport the Wraith is given from P9 to P1 and thus can attack.
DIRECTION LINKINGPrevious PostExample Map: Heli1.scxThis will go into more depth of how to link unit directions to create customized looking units. Linking directions enables a host unit, in this example the invisible Bunker using the Command Center image, to dictate the direction and location of all other units linked to it. By detecting the direction that the Bunker is facing, you use move triggers and direction EUDs to affect the child units. It's recommended to use an image editing program as it helps both with the conceptualization of the units as well as finding the correct location offsets.
The above image was created in an image editing program. Screenshots were taken from the DatEdit>Image section and then merged to create what I wanted. Not much changed from the original concept to the completed product.
The Bunker is invisible for two reasons. First is that I'm only going to use a total of 17 different directional frames and second is that using the Command Center image is unavoidable for this map. I use 17 directions because it will cut the amount of work in half. It will be less smooth than having 33 frames but the amount of time isn't worth it. The Valkyrie will be moved directly on top of the Bunker, because it's centered we will use the Valkyrie image as our frame of reference.
Under DatEdit>Image I take screenshots of the Valkyrie and another image, in this case the Science Vessel Turret, and paste them within a paint program. Either change the opacity or blending option of the turret layer so you can see both of the layers at once.
Shift the turret layer to the desired location whilst counting the amount of vertical and horizontal pixels. The resulting value is how much you will need to offset the location. In this instance I need to offset the location by adding 18 pixels vertically and subtracting 30 pixels horizontally. Now do it for every frame until you reach frame 16.
Once you reach 16 you can copy the triggers for the other half of the directions and invert the horizontal values. Because the frames are mirrored it will result in the same effect for the other side. Keep in mind that because direction goes clockwise you will have to implement the location offsets in that order as well.
'No Collide', 'Is Gathering', and repulse prevention should be used.
Attachments:
Post has been edited 7 time(s), last time on Mar 19 2020, 7:55 am by Sie_Sayoka.
None.