Staredit Network

Staredit Network -> Concepts -> More reasearch needed about hyper units
Report, edit, etc...Posted by Deathknight on 2005-04-24 at 15:01:43
Just to tell you, all wireframes will be of a marine, and all sounds will be random.
Report, edit, etc...Posted by Doodle77(MM) on 2005-04-24 at 15:22:44
AHHHHHHHHHH HELP ME IM SCARED, my science vessle got scared and ran into(entered) my dropship that had a unit 5671 in it!
EDIT: OK, it ran into that unit 5671, which entered my dropship. VEry Weird!, that unit can pick up anything, including lifted off buildings smile.gif it ate my command center!
Report, edit, etc...Posted by The_Shattered_moose on 2005-04-24 at 17:13:08
I've been thinking, I wonder what these units do if they're picked up with the probe trick, my moneys on it crashing, but you never know, maybe we can finally get a probe carrying the stuff that was previously unstable.
Oh, and how exactly are you guys placing these units, i've checked in starforge semi throughly....
Report, edit, etc...Posted by Doodle77(MM) on 2005-04-24 at 17:44:52
oh, easy you place them by going to a units properties in SF and changing Unit Type to a number, wish i could hex edit to get ones above 32476(i think).
another thing about the 5671, if you get it in a dropship then it you can pick up unlimited units, but all of the units that go higher than the 7th slot dissapear and go into a extrademesional space which we cannot see! but they stilltake up supplies!
Report, edit, etc...Posted by Staredit.Net Essence on 2005-04-26 at 13:24:20
I keep asking this, but does anyone understand WTF is going on here? I'm a programmer, and I think I know why:

I am 99% positive that these are buffer-overflows (writing over memory which is past what is intended). Some units happen to overwrite memory that the game uses, causing strange game functions to be called, and some go crazy and overwrite other memory, which causes the crash. This would also explain the randomness of some units: things aren't always in the same spot in memory, so you might get unlucky and cause a crash.
Report, edit, etc...Posted by scwizard on 2005-04-26 at 14:23:03
Yes, it works the same way for hyper players.
That also exspalins why the effects change after every patch (only including the times when numbers change), becuase every patch blizzard changes the memory locations to stop hacking.

ADDITION:
QUOTE(Ðeathknight @ Apr 20 2005, 02:39 PM)
You realize someone could just write a program to calculate every effect of all 65535 units. I have no skill in programming, so I wouldn't be able to do it.

It's possible to determine what changes the effects of these units using that method as well. I used a memory searcher to do something similar with extended players. If someone would want to write a program, I can find and provide them with the addresses.

Testing extended units can be fun, but only untill the next patch. You know there are extended units, extended players, extended portraits, extended colours, and most uncommon; extended tiles, extended trigger conditions/actions, extended player types/races, and some more things.
[right][snapback]192113[/snapback][/right]


Since your a programer, do you think you could pull of something like that? A memory searcher would help the SEN community a lot.
Report, edit, etc...Posted by Staredit.Net Essence on 2005-04-26 at 14:41:38
I could probably do it. However, I'm not used to dealing with memory, I usually do the Good Thing and try and avoid messing with that stuff. It avoids madness like this. wink.gif I used to program that way, so it shouldn't be too hard.

If someone could post all the info I need about memory adresses I'd be glad to try, but I don't really want to do all of that research on my own. I have several other projects I have been working on.

EDIT:

The more I think about this the less I want to volunteer myself. It will be a much larger task then I initially pictured (you can't just assume that x value is stored at y adress, and since this whole thing probably f*cks with the stack it will make wading through the info a bitch). Good luck to whoever wants to do this, but I really don't want to. If DeathKnight is an expert on starcraft's internal workings, it probably won't take much time for him to pick up enough programming to realize how long this will be.

edit: clarity
Report, edit, etc...Posted by axblader on 2005-04-26 at 19:12:17
i dont think i can see 5671 on my SC....
Report, edit, etc...Posted by Deathknight on 2005-04-26 at 20:58:29
QUOTE
you can't just assume that x value is stored at y adress

What do you mean by that? Values that contain unit data are kept at the same position every load. They are also read in a certain way, like every two bytes would read each unit's shield amount, in the same order. Extended units read beyond it(buffer overflow), but follow the exact same pattern.
Report, edit, etc...Posted by Forsaken on 2005-04-26 at 21:37:19
I have an idea for people who don't have time to test all of these units. Could anyone possibly compile a list and put everything together that does work. I am lazy and have dial-up so it takes like 5-6 minutes per page to load. So, if I could get a list of which units that do work and have cool affects, that would be greatly appreciated. tongue.gif
Report, edit, etc...Posted by l)ark_13 on 2005-04-26 at 22:28:16
I actually have a few questions if you have the time to answer them:

1. I've started testing some extended(EX) units too, they're cool tongue.gif I've started at 8000 because I noticed no one was really talking about them, and I aslo read that all the units after (I think) 9000 would crash. I am I right or will all the units after 8000 crash as well?

2. How are you guys testing these? I have a few units of mine in the game to test things such as if the EX unit attacks, can be recalled, ect... I do not start the map looking at the the EX unit or any of my units around it but I have 4 map revelers around the EX unit. I am testing on desert terrain and in single player. Does any of this make a difference in testing?

3. I've already noticed a pattern after I got to about 8016 with the EX units (I haven't gone that far because I need to know question 1 before I continue). Every fourth unit is a "special" unit. It ALWAYS goes: [8001]vesvaine orb/sac/tank (I haven't seen a vesvaine tank yet but I assume there will be one at about 8041), [8002]an unknown sprite (possibly a bullet), [8003]and then an infested terran. [8004,8008,8012,etc...]After that its a different unit every time. Is there a pattern like this for other numbers as well?
Report, edit, etc...Posted by hidiho on 2005-04-26 at 23:06:39
QUOTE(l)ark_13 @ Apr 26 2005, 08:28 PM)
I actually have a few questions if you have the time to answer them:

1.  I've started testing some extended(EX) units too, they're cool tongue.gif  I've started at 8000 because I noticed no one was really talking about them, and I aslo read that all the units after (I think) 9000 would crash.  I am I right or will all the units after 8000 crash as well?

2.  How are you guys testing these?  I have a few units of mine in the game to test things such as if the EX unit attacks, can be recalled, ect...  I do not start the map looking at the the EX unit or any of my units around it but I have 4 map revelers around the EX unit.  I am testing on desert terrain and in single player.  Does any of this make a difference in testing?

3.  I've already noticed a pattern after I got to about 8016 with the EX units (I haven't gone that far because I need to know question 1 before I continue).  Every fourth unit is a "special" unit.  It ALWAYS goes: [8001]vesvaine orb/sac/tank (I haven't seen a vesvaine tank yet but I assume there will be one at about 8041), [8002]an unknown sprite (possibly a bullet), [8003]and then an infested terran.  [8004,8008,8012,etc...]After that its a different unit every time.  Is there a pattern like this for other numbers as well?
[right][snapback]196184[/snapback][/right]

What do you mean by this? Is the graphic in Starforge or in Starcraft? Because the graphic of an extended unit in starforge doesn't mean anything, and we're not really looking for cool sprites and stuff, we're looking for units that could be used in maps or just fun to screw around with.
Report, edit, etc...Posted by l)ark_13 on 2005-04-26 at 23:11:08
Of course I'm testing them in Starcraft. Im not a moron. Thats why I asked question 2. If those variables meant anything or changed the outcome of anything. Please answer at least one of my questions, you haven't answered anything. And for the part about the pattern, the sprites in starforge are the patterns. They have all crashed in Starcraft so far. Thats why I asked question 1.
Report, edit, etc...Posted by Staredit.Net Essence on 2005-04-27 at 01:37:12
QUOTE(Ðeathknight @ Apr 26 2005, 07:58 PM)
What do you mean by that? Values that contain unit data are kept at the same position every load. They are also read in a certain way, like every two bytes would read each unit's shield amount, in the same order. Extended units read beyond it(buffer overflow), but follow the exact same pattern.
[right][snapback]196101[/snapback][/right]


I assume from this that starcraft allocates it's own block of memory and deals with it from there, instead of allocating it along the way? Otherwise there is no gaurantee where in memory something will be (and even using the previous method you would have to add the program's offset in memory first).

EDIT: Then how will you explain the random effects?
Report, edit, etc...Posted by scwizard on 2005-04-27 at 13:39:59
QUOTE(l)ark_13 @ Apr 26 2005, 09:28 PM)
3.  I've already noticed a pattern after I got to about 8016 with the EX units (I haven't gone that far because I need to know question 1 before I continue).  Every fourth unit is a "special" unit.  It ALWAYS goes: [8001]vesvaine orb/sac/tank (I haven't seen a vesvaine tank yet but I assume there will be one at about 8041), [8002]an unknown sprite (possibly a bullet), [8003]and then an infested terran.  [8004,8008,8012,etc...]After that its a different unit every time.  Is there a pattern like this for other numbers as well?[right][snapback]196184[/snapback][/right]

Who said the effects were random.

5671 (I think it is) is invisible in SC. However that doesn't stop it from loading air units (and lifted off buildings) If you run an AI scipt telling your units to go into the nearest trasport. It can also be picked up by regular trasports, glitching them, making it so they can load infinite units (but not unload them).
This is my favorite one so far, mostly becuase it's remarkably stable.
Report, edit, etc...Posted by Deathknight on 2005-04-27 at 16:32:20
QUOTE
EDIT: Then how will you explain the random effects?

Buffer overflow. Example: Say the number of upgrades comes right after the unit HP. There are only 228 registered units. Now say unit 229 was viewable and selectable. It will have 0 HP until you upgrade Terran Infantry Armor. Once you upgrade that, it will have a max of 1 hp. It's just how it works. It does the same thing for every unit, sprite, image, player, etc. In 1.11b I determined that a certain player's alliance will be affected by the number of pauses the 8 players have left. It worked. I did the same for extended player deaths and the technologies available for the 8 players. Random testing showed that it was consistant.

But there's more work involved to get the addresses of values from units.dat, images.dat, flingy.dat, sprites.dat, and iscript.bin.
Report, edit, etc...Posted by l)ark_13 on 2005-04-27 at 16:52:49
So I'm guessing all units after 8000 wont crash? I'm just guessing though, because I still dont know for sure.. I've gone ahead and kept testing though. More patterns. Every 64 units the LARGE patter starts again. It goes back to the very first unit, the scarab. Also, every 40 or so units the vesvaine sac/tank/orb changes. I'm just letting you guys no this because maybe we can find a pattern for all the units that "work" or not instead of testing evey single one.
Report, edit, etc...Posted by Staredit.Net Essence on 2005-04-27 at 17:36:48
QUOTE(Ðeathknight @ Apr 27 2005, 03:32 PM)
Buffer overflow. Example: Say the number of upgrades comes right after the unit HP. There are only 228 registered units. Now say unit 229 was viewable and selectable. It will have 0 HP until you upgrade Terran Infantry Armor. Once you upgrade that, it will have a max of 1 hp. It's just how it works. It does the same thing for every unit, sprite, image, player, etc. In 1.11b I determined that a certain player's alliance will be affected by the number of pauses the 8 players have left. It worked. I did the same for extended player deaths and the technologies available for the 8 players. Random testing showed that it was consistant.

But there's more work involved to get the addresses of values from units.dat, images.dat, flingy.dat, sprites.dat, and iscript.bin.
[right][snapback]196452[/snapback][/right]


I still don't understand. If another unit was added, it wouldn't push everything else in memoeyr forward, it would take up unused space in the pre-acllocated buffer. That may explain why things only sometimes crash, but it wouldn't explain random effects, unless radically different things could go in different spots in memory. If that is the case, then what I originally said is true.
Report, edit, etc...Posted by Deathknight on 2005-04-27 at 21:53:33
It doesn't alter memory. It reads from it. It doesn't move memory around or anything.

Another example.

Say you're at address 0006A053 and just pretend the units get their health values from this. It would go

0006A054 - Marine hp value (unit 0)
0006A058 - Ghost hp value (unit 1)
-----
All the way to...
-----
0006A3E4 - Vespene Gas Tank 2 hp value. (unit 228)

and say the next section contained the unit shield amounts.
0006A3E8 - Marine shield value
0006A3EC - Ghost shield value

Now placing unit 229, which does not exist, will have 100 hp because the marine has 100 shield points(All units have a shield value, if they don't use shields, its default is set to 100) because it reads beyond its memory in the same way it reads all registered units' hp values(every four bytes).


If that's like what you already said before then I'm sorry I didn't understand.
Report, edit, etc...Posted by Staredit.Net Essence on 2005-04-28 at 01:28:04
You've obviously studied this more than I have, but if random sounds play under seemingly identical testing conditions (not different number of units, upgrades, etc.), then it seems things do not have a set spot in memory.

Again, you have studied this more than me.
Report, edit, etc...Posted by AkkiBifuu on 2005-04-28 at 06:46:34
Any more needed to be tested? give me alot to not no silly number like 200 lol
Report, edit, etc...Posted by Doodle77(MM) on 2005-04-28 at 10:48:58
if you want to, AkkiBifuu you can test 1800-2000
Report, edit, etc...Posted by Deathknight on 2005-04-28 at 15:46:41
The sounds also read in the same fashion. In units.dat, it states the range of sounds it will play when you select a unit, another range when the unit is "pissed off", and another range for when you order the unit. If the range has two weird values, then it will play a random sound out of that range, which is basically what it's doing. I guess that's the best I can explain it.
Report, edit, etc...Posted by scwizard on 2005-04-29 at 20:23:24
QUOTE(l)ark_13 @ Apr 27 2005, 03:52 PM)
So I'm guessing all units after 8000 wont crash?  I'm just guessing though, because I still dont know for sure..  I've gone ahead and kept testing though.  More patterns.  Every 64 units the LARGE patter starts again.  It goes back to the very first unit, the scarab.  Also, every 40 or so units the vesvaine sac/tank/orb changes.  I'm just letting you guys no this because maybe we can find a pattern for all the units that "work" or not instead of testing evey single one.[right][snapback]196469[/snapback][/right]

There was a section I was randomly testing, where every other unit would play a scourge death sound. I think it was 6000ish, but I'm not sure.
Report, edit, etc...Posted by Doodle77(MM) on 2005-05-08 at 11:36:42
unit 718 is a door that can be walked on, and can be group selected.
edit:can be attacked. (dissapears suddenly when killed)
edit2:when group selected plays a random protoss sound ( smile.gif its a protoss left pit door) it can be recalled but after it has been recalled it crashes when you look at it.
Next Page (3)