Staredit Network

Ok people, let's eat these little illegitimate childs for diner, shall we?
There are 5 overlays, whose meaning I hope to be found or at least researched thanks to this topic. Also, this is a topic that will concentrate particularly on the LO? files, and their interworking in Stacraft.

Overlay 1
Entries using it (+LO-type):
Drone LOG
Guardian LOG
Hydralisk LOG
Mutalisk LOG
Arhon-Being LOL
Battlecruiser LOX
Bunker LOA
Wall flame trap1 LOA
Wall flame trap2 LOA
Devourer LOG
Lurker LOG
Dark Archon-Being LOL

Hypothesis: After testing this one, it seems that it controls some part of the unit's attack animation or something, because removing it hangs the game when the unit is instructed to attack, no matter which LO-type it uses. However, I have no clue what is the interworking of this property and the X/Y offsets from weapons.dat. Maybe one sets the base point for another?

A strange thing happens with the Battlecruiser because removing its LOX doesn't seem to affect the unit at all. I tested both normal attack and the Yamato Gun.Maybe it has to do with the fact that BC has a LOL file linked as "Overlay 3"?

Overlay 2
It is pretty much clear what it does, if you browse through images.dat and see which entries use it - it's the "Flames overlay" (as may suggest the last letter of the only LO-type used in it - LOF), which controls where does the flame/blood graphics appear on a building when it is damaged.

An interesting thing here is that it is not enough just to give this overlay to a unit to make it "bleed/burn". Try to give an already used overlay to, say, Ultralisk, and watch the game freeze when its HP reaches around 80% (precise values when the overlays appear are unknown...anyone?). I found out that this can be avoided if you give the Ultralisk the Iscript animation of a building (the units.dat Building property has nothing to do here, I tested it), say the Nydus Canal, which clearly points to Iscript as the decisive factor. However, nothing in the Nydus Canal iscript seems to have a similar meaning (to the extent I analysed it).

Hypothesis:My current hypothesis is: the activation of the "Flame/Burn overlay" is dependent on the presence of a specific Iscript.bin animation set. The question is - which one? To the extent I had tested it I was getting only instant crashes after starting the map, so I'm asking for assistance in finding this out

Also, there is no property that dictates which particular variant of flames/blood should be shown. Is it random or controlled?

Overlay 3:
Entries + LO-types:

Drone LOO
Extractor LOS
Probe LOO
Assimilator LOS
Battlecruiser LOL
Goliath Base LOL
Wraith LOL
SCV LOO
Siege Tank (Tank) Base LOL
Siege Tank (Siege) Base LOL
Siege Tank (Siege) Turret LOA
Science Vessel (Base) LOL
Refinery LOS
Vespene Geyser LOS
Unknown547 LOB

Hypothesis: The partial meaning of this overlay can be read from the units using it:
For the Resource-Miners, this is the overlay that controls where they "hold" the resources after harvesting them from a mineral field or a geyser.
For the gas-related units, it probably controls the smoke graphics (LOS), as the game hanged after I removed it for the Refinery and launched the map. Iscript-connected via the "creategasoverlays" (0x38) opcode.
For the base-turret units, maybe it controls the location where to put the turret ("imgol" connection?)
For the Battlecruiser, it is the location where to create the Yamato Gun graphics, as the game hanged when I tried to do so after removing the overlay.
For the remaining units (Wraith, Unknown), I have no idea.Maybe wraiths were to have afterburners or something?No visible effect on removal.

Overlay 4
Entries + LO-types:
Scourge birth LOB
Zergling birth LOB
Infested CC LOU
Dropship LOU
Science vessel (base) LOU
Barracks LOU
Command Center LOU
Factory LOU
Science Facility LOU
Starport LOU
Engineering Bay LOU
Valkyrie LOU

Hypothesis: The meaning of this can also be guessed I think:
For the buildings, it's the landing dust location.
For the zerg units, the location where to put the 2 spawned units (LOB, for Birth)
For the terran units, I think it's the same as for buildings, because if you dig deep enough (for example here:Evolution of SC) you will know that both the Dropship and Science Vessel were originally destined to take-off and land, and not not only fly. As for the valkyrie...I have no idea, maybe same thing?

Overlay 5
Entries: (the LO-type is LOD)
Infested CC
Dropship
Science Vessel (base)
Barracks
Command Center
Factory
Science Facility
Starport
Engineering Bay
Valkyrie

Hypothesis: Complementary to Overlay 4, this one controls the lift-off dust for the buildings using it, and is a remainder of the unimplemented features for the other units.

I think that's it, any ideas for new labels for these properties?

For overlays 4 and 5, the LO-type may be misleading, because you have LOU for landing dust, yet the U may suggest the Upwards direction, and the LOD for lift-off dust, when you might have taken the D for Downwards direction. I've fallen for this one, so...always test your hypothesis!

-------------------------------------------
Oh, last note: the overlays are SPECIFIC. This means that even though their properties may seem a bit randomly spread, the game engine looks for a particular overlay in a particular place, it does not browse through the overlay list for a target LO-type. Putting an overlay normally found under "Overlay 1" in "Overlay 4" won't work.

Corrected a bit

also if you put the tank lo file there for the battle cruiser the yamato charge up shows up in the center. Might be the other way around if you put the battle cruiser lo file for a tank, the turret might be where the yamato shows up, that might be funny looking.

LOS, LOU, and LOD are implemented in scmdraft actually
LOS controls where the smoke clouds spawn
the other two are for liftoff and landing, I believe the files also control which type of dust cloud to spawn but I havn't touched that code in a while.

"Also, there is no property that dictates which particular variant of flames/blood should be shown. Is it random or controlled?" -> probably also stored directly in the file itself, same as with landing

Thanks SI, it's good to have an external confirmation on the research. Any chances you can look into that code soon? Just asking.

here

LA>Could you talk in a bit more detail about this? I would put this info in the Overlay hints in DatEd.

im confirming that LA said cause I was tinkering with that file since i made a pylon float, so it looked weird for the ground to be burning. I changed the file and lo and behold i had red and blue flames.

Interesting research Broody

I was looking for some LO? explanations for some time and yours came just in time As for the U and D, I thought the same as you, but was a bit lazy to check. The Valky, imo, might need the U and D overlays since it used to have bombs and I assume it would land to recharge them (just a guess), but it might have to do with that; another possibility is an overlay for the afterburner tech as already mentioned.
The opcode in question (0x41) is orderdone which unsets the bit set by sigorder. I'd say it is a bit AND modifier.

As for the smoke puffs... I did some asm fooling around in the exe and I found the address where the Refinery (yes, only Refinery atm) replaces the Geyser.
Normally, building it will stack them and finishing building it will replace it. Upon destruction the geyser is returned. I managed to replace it with a Bunker. Basically you DO build a Refinery (that is what it starts as), but the building animation and final result are of the Bunker. It crashed. As soon as I added the Assimilator overlay (was lazy to look for another one) and added the overlay Iscript commands for the smoke puffs it didn't crash anymore. Well the puffs were all over the map (lol); also I didn't check whether it worked like a Bunker or a Refinery (... will do that eventually ), but upon its destruction, the Geyser wasn't returned... (too complicated to check where the Geyser gets returned)...

Anyway, my point... yes, the engine looks for specific LO formats like you said, but I think I can still add my own overlay IF I do it in the correct overlay section
... although I will do more research on it as soon as I figure out more about overlays since it is not my favorite subject



Interesting! One question: how does it decide which of the 22 entries to use ? Randomly or is there some sort of prioritization or ID specific data (unit or weapon?) ?

One note on the "flames overlay" LOF files. It does not crash if you give the LOF the proper number of "frames" which correspond to the highest numbered frame that would be used in iscript.bin for that graphic (including the turned frames).

I did exactly that for the mod that goes with my work-in-progress Starcraft Maul map. The buildings I have in that have custom iscripts which correspond to graphics for units instead of buildings. I eventually thought to check the lo* files that were used and found that I needed to have it match the number of frames I used in the iscript. The feature I put in LO?Edit for copying the offsets to the other lo* frames is very useful for this. All you need to do is increase the number of frames that it is storing offsets for and then click the button to copy them.

Just a random guess, maybe someone else can confirm this.
Flames / bleed effects are generated as image overlays attached to the building sprite in the image list while landing dust / takeoff dust are new sprites entirely.
Can someone verify this?

flames/bleed effects are generated by one of the lo files, which type is determined by locations in the lo file. Its really complicated. Basicly you could make a unit look burning when its hurt. Its pretty cool but kinda glitchy.

I believe he was saying ... in simple terms that assuming each graphic type is a separate class (well they are sort of), Flames are spawned classes consisting of images (LOF "code" so to speak) and Lift-Off/Land (LOD/U) are generated as sprite classes.

... in other words assuming we'd control it by IScript, flames would be spawned as imgol/imgul commands and lift/land as sprol/sprul.

(but I do admit I am guessing what he meant )

You kinda got it...
lets see... there are sprites in SC and images
each sprite consists of onr or several images.
the question was whether the flames are created as another subimage of a sprite or as an extra sprite object, and if it is a subimage how SC knows what images to take away when the building was repaired...

Thought so

Taking a very extreme wild guess, I'd say flame/blood uses images if it uses overlays as to display several parts of images so to speak, and not a complete ensemble of a sprite. I'd say the lift/land use sprites, though...

Although it is just a (semi-educated) guess. Not very reliable.

thats exactly my guess but I dont know how SC would know what overlays to remove when it stops burning

Well, I think SI and I based the assumption on logic, but yeah, looking in Sprites.dat would say the same

As for the LO? thingy you said, it isn't hard to understand... What I don't understand (maybe SI too, but I won't speak for him) is how each part of the overlay is decided...

From what I understood, each LO? entry (respectively an overlay frame) corresponds to a blood/flame entry (respectively, an image), correct ?
If so, what I don't understand is how each building decides which LO? entry to choose (therefore influencing which image to use)... I mean, is it based on the last projectile trajectory ? Or random ?

... I tend to smell a bit of hardcoded-ness in there somewhere...

I assume its random, the same way the damage wireframe is done

That was my impression too...

Its not random! When ever a building burns its the same burn patterns everytime! But this is what confuses me, I took the barracks lo file for burning and gave it to the carrier. When the carrier was hurt it started burning, but all the burns were in random locations!!

I have 2 rax at 890 hitpoints with different flames on them...

edit: ok barracks have 3 spawn points, each of which jumps to the large version of the flames before an additional one spawns. (22 small flames and 22 large in images.dat)
first flame appears under 905 / 1000 HP
Gets large aroung 810 / 1000 (a bit random)
and another small around 700

hmm this is weird, repairing it caused the big flame to turn small///