After a recent post in MMA, I got to thinking. Back in maplantis days I knew nothing of EUDs, and I got mixed results from the veterans. Most said "don't bother with this, ever", while others claimed it was simple. So I learned, and it was indeed simple.

After looking at extended supply, and supply above 200, it's pretty clear that we can determine at least some of the effects of preplaced units, and can at least predict what might happen if the unit does not crash. I realize that extended units are "buffer overflows all over the place".

For those who don't know or haven't bothered to check why extended supply works:

Each unit has a "build score" associated with it which is added for preplaced and created units. Thus the build score (you can find a list of them here) is added to the player's location. It just so happens that player 157's location for build score is 157*4 = 628 bytes in front of player 1's build score, and happens to be player 1's zerg available supply. Build score is also not removed when the unit dies, so this effect is permanent.

So then, why does player 15 hold such importance in modifying the game speed/animation speed?

Do extended player deaths correctly update the death table (I can't test this right now)? Same with kill score/kill count.

I know we can't document every single buffer overflow a unit makes, but we can at least figure out some of the stuff, or have it documented somewhere for those who do know this stuff.

Post has been edited 1 time(s), last time on Jan 12 2011, 4:31 pm by rockz.

Honestly, I'd be willing to test the extended units, if I can be given reasonable guesstimates as to what unit and player combo to test.

As for the player 15 trick, if I were to gamble, I'd say it has to do with where player 15's unit score is. Interceptors (which IIRC was one unit that increased the speed) have a build score of 30, and should alter a byte that deals with game mechanics. Although it makes no sense why this isn't hardcoded. If someone could find the address for game speed, I honestly wouldn't be too surprised if player 15 has some stats recorded in the same area. Although this is probably complete and total crap.

TL;DR: I'm ready to brute test basically anything anyone wants.

map revealer and scarab seem to have an effect, and they don't have a build score. There's also a clear indication that it's animation speed, not necessarily game speed, as one makes units move at normal speeds but attack twice as fast (or something like that), but it always seems to be player 14 or 15.

If you want to (and know how to) you can determine if the death is updated properly (use player 13 terran marine, if you get 1 death of player 1 ghost, it's updating in at least in the death table).

Finally, while it's not related, cloaking/stacking needs some brute testing. I know I messed up in some areas, and things like hydras ARE cloakable if you order them after enabling them.
Disabled sprites - http://www.staredit.net/?p=oldwiki&s=61
http://www.staredit.net/starcraft/Set_Doodad_State

A p13 Marine doesn't affect p1 Ghost deaths at all. Test attached.

Meh, we need Heiney to tell us why SC does what it does.

I'd be willing to brute test, but would I just be enabling the sprites or would I be ordering, killing, etc?

EDIT: The Hydralisk sprite crashes immediately after disabling. The unit takes roughly half a second longer, but ditto on crash. Upon removing vision from the unit, Starcraft waits until you can see the hydra to crash, while the sprite still is an immediate crash. Triggers are set up to disable/enable/enable, after 5 seconds order to move to a location, then after 10 minutes that location sends them to a place I have vision of.

Post has been edited 2 time(s), last time on Jan 12 2011, 9:27 pm by poison_us.

a p13 marine does indeed affect p1 ghost deaths. I figured as much (try killing the marine, 1 death of p13 marine should equal 1 death of p1 ghost).

also, hydras can be stacked and disabled, but placing a disabled hydra sprite seems to be subject to a crash. there might be other units that do it as well.

In a separate map, I got all those units listed in the oldwiki to stack. Also note you don't have to test every unit, just the avatar/unit graphics (if a ghost does it, so do both durans and stukov, but not kerri, she has a different graphic).

Attachments:

My bad, didn't actually kill it
Anyways, how exactly did you get the disabled hydralisks to not crash Starcraft? Every time I viewed anywhere near them I crashed instantly.

look in the map?

in this case I enabled it, wait 0, disable, wait 0, enable, order somewhere, move it somewhere else, give it to player 1.

_{Note that I'm really tired right now ... so I (probably) have a point, I'm probably just skidding and sliding around it a lot}

Cloaking crashes based on the overflow animation they play ... Look at just disabled marines, for example. They play a nonexistant, but valid, animation. Now look at minerals ... They do a similar thing but then crash. Enabling and Disabling call different animations (opening and closing for doodads), most units don't have these animations ... Most units crash if you don't give them another order that changes their animation, and most of these animations crash pretty quickly (immediately).


Also this still has some useful addresses... Such as this (which was mentioned).

Farty, I've had 2 hours of sleep and I understand you perfectly. When a unit that isn't intended to be enabled (after disabling, of course) is enabled, there's no "real" animation for it to play. By "real" I mean no animation that is intended for a unit to do...don't really know how to elaborate more on that. Disabling works the same way, at least as far as forcing Starcraft to play an animation that might not exist for a given unit. Crashes occur more or less when Starcraft is forced to do something it doesn't want to, and was never intended to do, like have a map size of 63.

Anyways, it's just another example of how we push a game that's over a decade old beyond its limits, just like EUDs.

Yes. Data for extended players and units are handled just like any other unit.



All other pieces of data are handled the same way.
I could make a better memory map, though it may be a lot of work since I've got most of Starcraft's data defined. Also you can do a million calculations, then there's the programmatic way of testing things, and also a programmatic way of filtering out units that are known to crash (example: sight range > 11). I generated a list of "working" extended units but I'm not sure if I still have the program. It can easily be re-created though.

EDIT: Or I could just add it to the EUDDB.
Also, @Farty, if you want to update the unit structure then use http://bwapi.googlecode.com/svn/trunk/bwapi/BWAPI/Source/BW/Unit.h
There were so many changes and new definitions that it no longer resembles the reference.

Post has been edited 1 time(s), last time on Jan 17 2011, 2:00 pm by Heinermann.

It would be pretty cool to know why that one extended player creates an arbiter field, and know how to recreate that effect in future maps, regardless of patch (there's probably only 1-2 patches left for SC).

if it's not too much trouble, I'd like to know the programmatic way of filtering, and how extended units have their sight range >11 (among the other crashing things).

Shoot, even that horribly out of date memory map which is now deleted on bwapi was immensely useful despite being out of date because I could use it to see where things were in relation to each other. I knew it could only be off by a few bytes anyway, and you're a fool not to check it first before making an eud trigger. The EUDDB is nice and all, especially for details about the address, but having a working, searchable, easily viewable memory map again would be nice.

Not sure, but

might have something to do with creating an arbiter field. It's a bit field where a bit corresponding to the player is set. I havn't checked how Starcraft handles this field but there's a chance that it may overflow depending on how the data is handled (low chance of this though).

I can't think of anything else that would cause it.

The programmatic way of filtering is to write a hack that reads the unit data in memory, and purposely overflow to obtain extended unit data. You can grab the unit data offsets from BWAPI and write a DLL using it. Not much work involved in this case, besides exporting it to a txt files with whatever you want in it. I'll throw up an example.

Also, I don't exactly have all known pieces of data labelled in my database, but I can export the list of addresses that have names.

EDIT: I found the program, source code is here: [attach=7668]
Mirror 1

Notes: Use /xunits to write documents to your Starcraft folder.
HackUtil is poorly coded, will work for more than one Starcraft Patch (probably 1.15.X - 1.16.1), command engine only available on Battle.net (it's "hookless", so what do you expect?).
Also may not be "perfect" because of different units' rules and attributes. Goes only to unit #29629 because of a read overflow I think.
Date was Jan. 15 2010, over a year ago.

Attachments:

Post has been edited 6 time(s), last time on Jan 19 2011, 3:21 am by Heinermann.