Dude this is awesome help. Can I add you on discord? I am trying to learn EUDs and utilise them in my upcoming projects and could really use a mentor.

Sure. You can also just ask in the EUD section of the SEN server we talk there a lot.

Also that is a sick Enterprise dude!

https://youtu.be/H_XbWq49vUM?t=62

Within the example map the unit's movement is controlled through keypresses using WASD. Right click creates a scarab that will explode dealing splash damage. These two actions will only happen if the marine is selected.


EUD HYPER TRIGGERS

Eud Editor>Trigger Editor
Condition: Always
Action: Eud>Eud Turbo
Preserve Trigger

I forgot to add this earlier in the thread. This enables Eud Hypers which will boost the speed of the trigger cycle to once per frame as opposed to normal hyper triggers which are once per two frames. This allows us to use conditions and actions just as fast as the game.


ORDER DETECTION

EUDDB Address

With the above address you can detect what kind of order a unit has received. For the purpose of the example map I'll only be detecting the move order for right click detection. The order is called ignore and is the 6th entry within orders.dat. You can either use the wiki link or switch to the orders tab within DatEdit for reference.



The Player ID for Unit Index is 19044 since we are detecting the order for unit index 0.
The value is exactly 1536 since ignore is entry 6 and it must be multiplied by 256.


CLICK DETECTION

EUDDB Address

This address stores the coordinates of any order. The value is stored for pixels. A tile is 32x32 pixels so a 64x64 map will be 2048x2048 pixels. In order to read this value and write it into the location position we use Binary Countoffs. Since this address shares all orders that use coordinates (such as patrol, rally, attack, etc.) we specify that it will only uses countoffs if the move order was given.




Since the map is 64x64 we start at 1024 halving it every trigger until 1. This ensures that the location is at the exact position that the order was made.




After the countoffs we reset the location to the top left of the map and stop the marine from actually moving to the clicked location. We also create a scarab.


SELECTION DETECTION

Player ID 161877 to 161973
EUDDB Address




We will use this address since we want to detect the selection of P1 within the map. The value is 5885096(0x0059CCA8) because this address points to the unit table. Since we are detecting unit index 0 we use 0x0059CCA8. Unit index 1 would be 0x00628298. It works differently than CUNIT shit but follows a similar pattern.


KEY PRESS DETECTION

Eud Editor 2>Plugin>MSQC

MSQC WILL SPAWN A UNIT AND TAKE UP A UNIT INDEX!

MSQC is an incredible plugin that allows for key press and cursor detection. Normally these would be local only and cause desync but MSQC allows for it to be used in multiplayer. For whatever reason the cursor detection gave me an error when trying to compile which is why I had to use Euds for the click detection system. Cursor location will require 8 locations (one for each player) in order to work. MSQC will sacrifice the recognition unit type meaning you cannot use this unit within the map. In return for your sacrifice you will be able to detect key presses. You can set the DCs set for each key press. The detection will apply to all players and if a player pressed that key it will create DCs for that current player. It will detect key presses regardless of what unit is selected, if you're typing, or even if you're alt tabbed so it's best to use this with additional conditions.





Each key press gives a specific number of ghost DCs which I can use as conditions. I add the additional condition of having the marine selected. In this trigger it orders the marine to attack to a location 300 pixels above it. Attack order is used so it doesn't conflict with the move order detection we have from right clicking. The WASD buttons within the marine's command card don't actually do anything and are there for visuals only.


DDS WITHOUT REAVERS

We can modify the DDS by making it both more consistent and use less units. The scarab unit type is hardcoded to not be able to spawn with triggers. If we copy the settings within DatEdit>Unit tab to another unit we can spawn them normally.


Failed to get ImageSize ( http://www.staredit.net/wiki/index.php/Direct_Damage_System )

Next we check the availability flags within DatEdit>Unit>StarEdit tab so triggers will affect it normally as well.




Finally we change the human idle to 65 to allow the scarabs to explode and damage other units. If this isn't changed they wont do anything. I believe normally scarabs will never enter an idle state but since they are spawned in and do not have targets they will become idle. We then move the scarab to an unmovable location (such as water) to make them explode.


CONCLUSIONS

The system within the example map works but there are some issues.

• Right clicking on a unit will not create a scarab as the move order will point to that unit specifically, not the coordinates of that unit.
  
• Sometimes the marine will run away from units attacking it despite the "battle reactions" box being unchecked. Weapons were removed from it to allow movement without it stopping to attack.
  
• Typing will also activate the marine moving as there is no additional condition to disable the system whilst typing.
  
• The unit will stop moving to fire a scarab. This is because of the countoffs trigger resetting order coordinates.
  

All of these issues could possibly be solved. Specifically for issue 4 you can have another unit selected instead of the marine. This will allow for fluid movement and attacking as there would be separate coordinates for each unit.

Attachments:

Post has been edited 5 time(s), last time on Jun 14 2022, 12:47 am by Sie_Sayoka.

QUIRKS
These are weird stuff that either requires further testing or has some kind of hard coded bullshit.

• Splash causes units to run away depending on the weapon graphic. Arclight and White Circle do not cause running.
  
• HP bar and selection circle size are tied to sprites. Not really a quirk as these Euds are read only but Eud Editor lets you change the values despite them not doing anything.
  
  

UNIT TYPE QUIRKS
These are hardcoded quirks for unit types (Unit slots within the DatEdit>Units tab).

• Scarab and interceptor unit types cannot be created with triggers.
  
• Carrier/Reaver/Vulture and heroes are the only slots with hangars.
  
• Carrier and Reaver hangar unit exit times are hardcoded. A reaver may only have 1 scarab out at a time.
  
• Doors and Nuclear Missiles cannot be selected at all and cannot be moved with triggers.
  
• Map Revealers also cannot be selected and will be invisible.
  
• Scanner Sweep has many interesting properties.
  
• Bunker will release carried units upon death if it has the building flag.
  

Post has been edited 7 time(s), last time on Mar 18 2020, 6:35 am by Sie_Sayoka.

SPRITE SUBSTITUTING




This will show you how to change sprites around and avoid the dreaded crash or rock doodad. By understanding the mechanics of how the game uses sprites and images you can better manipulate sprites into whatever purpose you need. Within the example map we will create an SCV with the sprite of a longbolt missile. Refer to the iscript and opcodes.


Process:

• Units point to sprites for what graphics they will use. Units point to flingy for what movement they will use.
  
• Sprites point to a specific image.
  
• Images use iscripts to tell it what frames to use and when.
  

Iscript Process:

• All images start at the init(ial) animation, this is what happens when the image is first created.
  
• After the init animation it will go down the animation list. Waits are measured in frames.
  
• Animations may point to the start of the same animation, creating a loop.
  
• The "end" opcode removes the image.
  

Rules:

• Once a sprite and image are created they will stay on that unit until it is removed or killed.
  
• Images created from iscripts cannot be substituted like sprites (i.e. science vessel turret) but can be modified in the image tab.
  
• Images are always tied to a sprite. However, not all sprites are tied to units.
  
• Any bullet iscript on a unit will result in a crash.
  
• When a sprite on a unit calls a frame that doesn't exist for that sprite it will create a rock doodad and brick the unit.
  
• When a sprite is removed from a unit it will crash. This is because units require a sprite.
  
• Sprites and images that aren't connected to units do not have any negative effects from missing frames or ending.
  
• An image can only have one draw function.
  
• Pure sprites (i.e. doodads) will only play the init header animations?
  
• It's not currently possible to remove sprites that don't end themselves through iscript.
  

Refer to the iscript to view the animations and see which iscripts are stable. Stable in this context are iscripts that have looping animations so they do not play the "end" code which will result in a crash. Eud Editor 2 has a useful feature that previews the image with the iscript. However it neither creates additional images nor says when an animation ends.




The above example would be when referring to the iscript would be useful. Within Eud Editor it looks as though the science facility overlay just uses frame 0 in a loop.



If we look at the iscript it will, of course, start at the init animation but then immediately goes to the "isworking" animation. I believe that "tmprmgraphicend" functions similarly to the end opcode which will result in a crash. In order to make it usable we would need to replace the iscript with one that loops the 0 frame. A doodad or building iscript with no frame changing animations would work.


Below are the steps to change an SCV into a missile.

1. Eud Editor>DatEdit>Sprite. Change the SCV sprite into a missile.
2. Eud Editor>DatEdit>Image>Graphic Properties. To prevent it from crashing we must change the iscript of the missile. The missile image only has directional frames so we would need an iscript that has this as well. For this purpose we will use the wraith iscript. Unfortunately the missile exhaust is tied to the missile iscript, however the wraith iscript has engine overlays which will give a similar effect.


Because the wraith iscript creates a shadow image we can remove it by cloaking the SCV as cloaked units do not have shadows. Alternatively if the missile shouldn't be cloaked (because of its draw functions other players can see it but not target without detection) just change the wraith shadow to draw function 8 or 17.

1. Eud Editor>DatEdit>Unit>Advanced. Check the "permanent cloak" box for the SCV.
2. Eud Editor>DatEdit>Image>Graphic Properties. To prevent the shadow from being transparent change the draw function to 1 for the missile.
3. Eud Editor>DatEdit>Image>General Properties. Because cloaked units don't have engine overlays as well we need to make it visible by checking the "draw if cloaked" box for the wraith engine.


Currently the SCV is only selectable through drag clicking. This will make it clickable.

1. Eud Editor>DatEdit>Image>General Properties. Check the "clickable" box for the missile.


To change the speed of the new SCV missile you can change the values of it.

1. Eud Editor>DatEdit>Flingy. Go to the SCV entry, not the missile. This is because the unit points to the flingy, not the sprite.


iDoodler gave great advice when dealing with the rock doodad. You can change the rock doodad's image to EMP draw function (8) and its iscript to something that expires (such as defense matrix hit) to remove them when encountered.


UNLIMITER PLUGIN

Eud Draft Post

The unlimiter plugin allows for an increased bullet/image/sprite limit by utilizing unused memory or something. Whilst I don't know what that actual limit is, it's greater than that of extended limits and should be, for most purposes, more than you need. This opens many possibilities, mainly for static visual and bullets. There are some issues such as images changing or having incorrect elevation which would lead to overlapping problems.


IMAGE LINKING




This system will allow you to create an image, instead of a sprite as the 'main' visual. In practice this will allow you to display incorrect frames as the image is missing frames, not the sprite. The "Doodad Header(Secondary)" iscript creates an image under the host unit. This image is linked to that unit and I believe what's happening is that the image's iscript will take priority over the host unit's. Because it's the image, and not the unit, that can display incorrect frames it will not result in crashes or rock doodads as it's just an image. This works much in the same way that shadows are linked to their host unit.


The above is the entry for the imgulnextid opcode. For the example map we will use a Rhynadon image.

1. Eud Editor>DatEdit>Image>Graphic Properties. Because we want to use the Rhynadon image we look at the image before that. Change the Ragnasaur (Ash) Shadow iscript to Doodad Header(Secondary).
2. Eud Editor>DatEdit>Image>Graphic Properties. Next change the Rhynadon's iscript to firebat. We use firebat because it matches up with the frames better than other iscripts. The iscript of the target image determines the functions that the unit can do. Because firebats lack air attack animations the rhynadon wont be able to attack air as well.
3. Eud Editor>DatEdit>Sprite. The unit we will be using is a marine. Change its sprite to Ragnasaur (Ash) Shadow.


There are two issues with this system. First is that if the unit dies it will probably create a rock doodad. This happens because the doodad header has no death animation and thus the host unit has no frames to play when it dies. Alternatively you can use the carrier iscript but you will have the issue of the image being offset 42 pixels below the unit but create no rock doodad on death. It's also possible to detect when the unit dies through CUNIT order or HP detection and remove the unit prior to it creating the rock sprite. The second issue is that because we are using iscripts that aren't necessarily compatible with the images we are using they will display strange animations. This is most apparent in units that require a lot of frames and have weird frame numbers like many of the zerg and terran infantry.


ANIMATION CALLING

EUDDB Address
Eud Editor>DatEdit>Order>Animation




This system will enable you to call any animation from a unit iscript. It utilizes the order animation EUD to change which animation is played when the order is used. For some reason (possibly hardcoded) only spells that have the default "cast spell" animation are able to have their animations changed. All other orders will do nothing. By changing the animation and then using the order we are able to call any animation of the unit.


Within the example map a ghost has the circle marker3 sprite, the circle marker3 image has doodad header(secondary) which creates the pylon aura image on init. Whenever EMP is cast it calls on the init animation which creates more pylon aura images. Images are not able to be offset a certain distance away from the host unit which is why subsequent images are placed weirdly. I'm unsure why the first aura does not share this rule. Because these images are linked with the host unit, if it's killed then the images will be removed as well. It has an additional benefit of being able to move. This is most useful in maps where dynamic sprites/images are required.

It's possible to order a unit to animation call directly with triggers using the main order ID address. Any unit can cast a spell as long as they have the requirements for it.


SPRITE PLACEMENT




The example map has an observer where, if hotkeys are pressed, it creates sprites. These sprites have some of their iscripts changed to persist forever. The sprites are created from changing death and remnant sprites. For some reason scourge, guardian, mutalisk, and overlord death sprites cannot be changed. Because the sprites are from unit deaths they can be created easily and precisely.


Unfotunately we are not able to do frame calling with sprites as directional frames are only for units. The list above are iscripts that you can use to create static sprites that use those particular frames. For animations there's a lot to choose from with varying animation frames and waits.

Attachments:

Post has been edited 5 time(s), last time on Mar 18 2020, 11:47 am by Sie_Sayoka.

SELECTION CIRCLES

EUDDB Address





Selection circles can be modified in two ways. The first would be their color and second the iscript. Selection circles are images that are loaded locally, this means that other player's wont see the same circles as you do. Circles that are made by selecting a unit (as opposed to changing the sprite of something into a circle) cannot have their draw function changed. They can, however have their iscript changed which can lead to some interesting visuals. However, since selection circles are shared by all units of the same circle size (see images 561-570) it may not be that useful to change them.

Rules:

• The circles will update once a unit is selected or reselected.
  
• The size of the circle will depend on the unit's sprite, this cannot be changed. Read this to change it.
  
• Circles cannot have their draw function changed.
  
• Circle images are removed once deselected. Exceptions are if the iscript creates another image?
  

The above is a list of the values and colors. Those with an asterisk are inconsistent. They might be based on an image's palette but I'm unsure exactly whats going on.

The example map lets you change the values of p1's circles through key presses. The temple has its circle's iscript changed to a longbolt missile which is why it will play the sound and smoke trail from it. The value can be increased or decreased, minerals show what the current value is.
1: add 1
2: subtract 1
3: add 50


LOCAL VALUE ACTIONS

EUDDB Address

Because the circle colors are a local value we can change how they are displayed relative to the current player. This is how normally your own units will be green, allies/neutral will be yellow, and enemies will be red. Without doing this it will turn selection colors of a player to a certain color regardless of the alliance status. Within the example map the circle colors will change only from p1's perspective. P2 will only see the default circle colors.



The above address is a local value that detects a player. Within the example map it detects if the player is p1 so the value would be 0. Because it is a local value, p2 would read 01. By combining this local condition with the local action of circle colors we can change how each player views the circle color of other players. The actions must be local such as display text, play wav, and center view. If a global action such as set deaths or set resources is applied it will lead to a desync.



The global actions are applied using a separate trigger.

Attachments:

Post has been edited 4 time(s), last time on Mar 5 2021, 10:45 am by Sie_Sayoka.

REMOVING AIR REPULSION

EUDDB Address
EUDDB Address
EUDDB Address


Video

Air repulsion happens much like ground repulsion where if two or more units occupy the same area they will repulse each other until their collision boxes do not overlap. However, unlike with ground, air repulsion will still occur even if the 'no collide' and 'is gathering' flags are checked. By changing this EUD we can get rid of the repulsion for a particular CUNIT.

The above addresses dictate the values of air repulsion behavior. The first controls the angle, the other two control the rate of repulsion. However, since our goal is to remove it altogether we set the value for all of these addresses to 0. The result will be a unit that will be unaffected by other units overlapping its box. Within the example map the helicopter has around 5 units with close proximity of each other. Without the EUDs it will repulse itself.


INFINITE INTERCEPTORS

EUDDB Address



Interceptors/Carriers have many hardcoded features and it's difficult to modify them. I was able to get a carrier to have an infinite amount of interceptors though. Because carriers are hardcoded? to have a certain amount of hangar space it isn't normally possible to go over this limit. However, with this system, it's possible to trick the carrier into thinking it has less than the maximum amount of interceptors.



The above address is the value that the carrier thinks it has inside of its hangar. It's not the actual value as the EUD cannot create the interceptor units. By setting this value below the maximum amount of hangar space and then modifying the hangar to a value above it, it will trick the carrier into having more interceptors than its supposed to. In the example map the interceptors will cap out at 30 but there is no limit other than the unit limit.

Attachments:

Post has been edited 1 time(s), last time on Mar 18 2020, 9:33 am by Sie_Sayoka.

The Carrier infinitive intercepters is Nice finding i think i can use that Thanks good job

SPRITE PLACEMENT PT.2

Original Post



This is just a rough translation of the above Korean post. This method of sprite placement is much better than the previous method. It allows for instant and clean sprite placement using the properties of the scanner sweep unit type (33). Below is a list of what the unit type does:

• Unclickable
  
• Doesn't show up on the minimap
  
• Is stackable? without using status flag EUDs
  
• Ignores collision checks (will not slow down ground units)
  
• Unaffected by move triggers
  

Eud Editor 2>DatEdit>Unit>Scanner Sweep>StarEdit

Check the 'Unit Listing & Palette' box. This enables the scanner sweep to be created with triggers.

Eud Editor 2>DatEdit>Sprite>Scanner Sweep Hit

This is the sprite that we will change. You can change it to something else here, however, if you want it to be dynamic you would have to change it through triggers.


The image id is the number of the image within the images tab of datedit.



This is what the trigger will look like to create a zerg building explosion (60) at a location.


The remove action is required as it will continue to create sprites in a circular pattern.

The scanner sweep iscript is hardcoded to output the initial sprite at an elevation of 4 regardless of the scanner sweep's elevation. Subsequent sprites will follow the scanner sweep's elevation if the iscript is allowed the continue running. If you need to change the elevation of a sprite you will have to use the previous method using unit deaths. I recommend using queen death and having the queen invisible. The shortest iscript I could find with an end opcode is the tank turret overlay iscript. This allows you to create a sprite with a 2 frame lifespan. Unfortunately I couldn't find one for 1 frame.

Attachments:

Post has been edited 5 time(s), last time on Mar 22 2020, 7:58 am by Sie_Sayoka.

Woah, sounds like sprite placement makes create/kill units method totally redundant??

Fixed, thanks.
No, using units for graphics is still useful as there's no way to modify frames for sprites/images other than the init animations. Units are much more dynamic as visuals and, depending on the purpose, are necessary in many applications. Or are you talking about the example map with the observer? In that case yes, there's no reason to use that over the scanner sweep system.

Oh I thought you were saying we could now dynamically place unit death animations.

You can with scanner sweep.

PREVENTING UNIT DEATHS

EUDDB Address
EUDDB Address
EUDDB Address

By preventing unit deaths you can ensure that the unit index will always be correct. Thanks to zzt and Armo for showing me how it works.

When a unit reaches 0 HP it receives the 'die' order. The unit will be unable to receive any new orders and it will then be removed and create a death sprite. By detecting the die order we can intercept the death process and reverse it.



In the example map the marine is unit index 0. If Fenix attacks the marine it should die as he does 40 damage to marine's 40 HP.

The condition will detect the die order.

The order is then changed to the 'stop' order.
The HP of the marine is modified to 1.
The 'Cannot receive orders' status flag is removed.

Once the trigger is finished the marine will be left with 1 hp and be alive.

Attachments:

Post has been edited 1 time(s), last time on Mar 18 2020, 9:39 am by Sie_Sayoka.

EXAMPLE MAP



The 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 INFORMATION

EUDDB Address: Flingy Top Speed

Lifting 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 DETECTION

EUDDB Address: Main Order ID
EUDDB Address: Status Flags

When 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.



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 INFORMATION



Within 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 DETECTION



The 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 ORDERS

EUDDB: Main Order ID
EUDDB: Main Order Timer

There 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 PREVENTION

DatEdit>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 TURRETS

Subunits Post


The 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 LINKING



Previous Post
Example Map: Heli1.scx

This 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.

This is beyond sick. I think I won't likely ever get to doing this, but it's enlightening nevertheless. Thanks for all the effort!

@Sie_Sayoka Dude! You're amazing! This is amazing!

I'm a long time map maker (like 12+ years) and I was in some of the well known map making clans back in the day, and friends with a lot of well known map maker community staples including farty, but that's besides the point.

I just recently started getting back into it after like a 4-5 year break basically, and saw Starcraft Remastered, and how they added EUD's back in! I was stoked, but I never even learned them back in the day, one of the things I didn't learn, but I do know quite a bit, I'm no noob at mapping that's for sure. But some of this EUD stuff looks pretty complicated. I just read over half of the little mini articles on different EUD uses you're compiling here, and I noticed a couple that I really want to learn and I remember hearing about them back in the day. I even have a couple maps completed or near completed that could seriously benefit.

I really could use more help understanding Click Detection, and HP Regeneration after I'm not so tired, and re-read them, study the example maps, and then see if I still can't figure it out I might head over to the section for questions and ask about those there, and hopefully you, or someone knowledgeable like you, can help me at that point!

This is really too cool, thanks so much for taking the time to do this for the community. I'm not always the fastest learner on the more complex concepts in map making but I'm persistent!

Maybe you can shoot me your discord info or whatever else you use to communicate if possible, I saw someone else ask, if there's not too much already on your plate. I understand if not though.

Looking forward to learning some of this stuff! Looks really cool I'm stoked on this!

Thanks in advance!

You can join the Staredit Discord. Here is the link for it.

Post has been edited 1 time(s), last time on Apr 19 2020, 1:41 am by Sie_Sayoka.

Adding to this information, I have two follow-up tutorials which I derived from SkywinDragoon's tutorial, which is similar to what you've said here.

TUTORIAL TIME
CHANGING COMMAND CARD BUTTONS
Continuing from the information you learned from the custom command cards button tutorial, this tutorial will show you how to modify command card buttons in-game via triggers.

Here is my custom button in Firegraft.



First I copy the button data number (third red circle) and paste it for later in a notepad file.

When you change the button icon (first red circle), the button data code (third circle) changes. Same when you change the Character field (second red circle). The character field is the text your button shows, and the drop down menu shows all the button texts in the game. Simply modify one of those button texts (of a button you're never going to use) to the button you want your new button text to be. Now after changing the button image and button text, here is what my FireGraft looks like:



Note how the Button data numbers are now different? You want to copy that number and paste it for later. Get the other number (the one you want the button to be on game start) and paste it to reset the icon and text to the way you had it originally.

Now you close Firegraft and open the Trigger Editor. Here are my triggers.


For the purposes of this tutorial ignore everything except the bottom two triggers, and remembering what you learnt from the first tutorial.

What I have done here is set it up so that when I press the button, it changes from Gun Gauntlet to Flamethrower. When you press the button again, it changes back from Flamethrower to Gun Gauntlet. The action you need to do this is called SetButton.



SetButton is found in the EUD tab, it is an action. It has two parts "UnitBtn and BtnData". UnitBtn is which unit you are changing the buttons of. For me it is the Zerg Defiler, which is default selected. So what I have to do is click the drop-down arrow next to Zerg Defiler, and reselect Zerg Defiler. Then you see the list of buttons (Move, Twin Autocannons, Stop, etc.) for some reason my custom buttons are identified here only by their images (Twin Autocannons, Charon Boosters, and Burst Lasers) so remember that when trying to find your own custom buttons. So remember, for UnitBtn you have to select the unit AND the button you're changing.

BtnData is that big number you copied before. What you are pasting here is what you want the button to change INTO. So after selecting both of those, it now looks like this:



Now, in-game, you see I start with Gun Gauntlets.



I press Q, and it changes to Flamethrower!



So that's how you change buttons! With this information, you can create entire sub-menus by changing every single button on the command card, and making one of the buttons a cancel or back button. This is exactly what happens when you press "build" with an SCV, Drone, or Probe in the vanilla game!

GREYING OUT BUTTONS
This tutorial will teach you an easy way to grey out buttons. Greying out buttons has many uses. For instance, if your button is a spell, greying it out can easily show to the player that it's on cooldown, you're out of mana, etc. If the button is for a crafting system, it can be greyed out to show that you're missing a crafting ingredient, and so on.

I must stress this is only one way you can make buttons greyed out. There are other ways but I'm told this one is one of the most convenient.

First, open FireGraft and go to your custom button you want to grey out.

The red circle shows the Unavailable text. This is the text that appears when the player mouses over a button that is greyed out.

I have set up this tutorial to be that the button is greyed out when the map starts. The player has to stand on the beacon to make the button clickable. Hence why the unavailable text will say "Stand on the Beacon!"

Once you have done this, you will see three tabs. Unit information, button set, and requirements. Press requirements.


There are a bunch of tabs, but since my button is based off the Build Terran Marine button (see first tutorial) I have to select the Terran Marine. Change the requirements by clicking the "custom" option, bottom right of this window. Then, delete the requirements that are already there. In this example, I am making the requirement "Is researched... Irradiate." What this means is the button is greyed out until Irradiate has been researched by the player.

Now close FireGraft and open TriggerEditor. Here are my triggers:



For this we are focusing on the highlighted if-then trigger. How it works is if we bring a unit to the beacon, then we can press the button because Irradiate has been researched. We can modify researches, on and off, using the SetTech EUD action:



The SetTech EUD action has five variables. PlayerX, Techdata, UTType, Count, Modifier. PlayerX = which player you are giving or taking research. Techdata = which research is it (in this case, Irradiate). Uttype: Choose between Researched (button pressable) or Available/Empty (button greyed out (I think)). Count: not quite sure here, it could be for weapon upgrades, or maybe it's a binary 0=off, 1=on, but I set it to 1 and it works. Modifier = Set To, Add, Subtract. Now this is what mine looked like after:



Now, in-game, before I stand on the beacon, it looks like this:



And after:



So, in summary, you can toggle research on and off to turn buttons on and off. But I have one more important point:

BUTTONREFRESH
There is a EUD action called ButtonRefresh. If you don't use it in the above tutorials, you may notice the button does not change until you select a different unit then reselect the unit with the changed button. If you use the ButtonRefresh action after each time you modify a button (whether to change its image/text or grey or ungrey it out) it will refresh the graphic of the button instantly without having to unselect and reselect the unit. So it's an important action to remember!

Good luck mappers!