With all the poking around in memory I've been doing (see
http://wiki.staredit.net/Memory_Map) I've realized that we're not using EUDs in the most effective way possible. What do I mean? Well, if you look at the memory map, the deaths table is at offset 0x58932C. This means that anything that comes before this offset is off-limits to a EUD condition. So what can we do? Use an action that reads data from memory that comes before the death table. The player resources memory is one of the earliest blocks of known memory there is (at offset 0x57E0B8). Another advantage of using this condition instead of the deaths one is that the math is simpler - all you have to worry about is a player index rather than a player and unit index.
I'll try and whip up a proof of concept map that does something that EUDs can't do...
i don't know about this stuff, but are you saying that EUDs can be configured easier? or are you saying that new 'EUD' conditions are possible? or both
?
From what I get from this, it wouldn't be a EUD at all... More of a "EPR" or "Extended Player Resources" trigger. Sounds interesting, but I'll need to see some proof.
Here it is. The only really interesting thing in memory between the player resources and the death counts (that we know of..yet) is the supply used and available counts. So I made a map to demonstrate detecting how much supply you have. I only made triggers for when the terran supply is 1 or 2. Check it out. I'll post a .trg file with all the supply triggers in a bit.
EDIT: And here's the rest of it. Attached is a trg file with all the supply conditions you'll ever need. There's a comment in each trigger that says what the conditions are for. Each trigger has 12 conditions, one for each player 1-12 in order. You can change the "at least" condition and the value to whatever you want them to be when applied to supply. The last thing to note is that all the values in memory are actually stored as double what you normally think about as supply - this is because units like the zergling and scourge only take up one "actual" unit of supply, while units like the marine take 2, and the zealot takes 4.
Yess! I knew this could be done... I just couldn't think of which trigger can be used in a manner similar to the deaths... Well done
This is an interesting discovery good job
Wow. This will lead to new systems in unit building.
One which detects when you start, another which detects when you finish, good for say... a ship repair system...
Count up supply for units in a deathcount, and see how much a player has actually finished.
Which player is it actually detecting from it just says unknown in SCMDraft.
How about one where it detects how much supply is left, and if it goes under 10, give the player a supply depot.
ADDITION:
Come to think of it, if we were to revert to an old version with EUDs(or EPRs) actions still available, does this mean we could change the amount of supply used or left, creating an endless supply game? or am I a bit too much of a dreamer.
QUOTE(Laser_Dude @ Oct 8 2006, 12:19 PM)
Come to think of it, if we were to revert to an old version with EUDs(or EPRs) actions still available, does this mean we could change the amount of supply used or left, creating an endless supply game? or am I a bit too much of a dreamer.
[right][snapback]573320[/snapback][/right]
Yes - it does. There's actually one more data block of supply for each player that I didn't expose through these triggers - the maximum value. It's always set to 400 (remember that doubling bit) for all players, but if you changed it you could go above 200 supply. Alas, EUD/EPR actions don't work in 1.14...
Yeah, the player will say unknown because it's outside the normal range (somewhere around 3100).
do they do overflow checks on set resources? and one of the problems with this is that it has a more limited range.
QUOTE(Doodle77(MM) @ Oct 9 2006, 07:59 AM)
do they do overflow checks on set resources? and one of the problems with this is that it has a more limited range.
[right][snapback]573615[/snapback][/right]
Yes, they do overflow checks on the set resources action.
The limited range is basically a non-factor: The player index is a 4-byte value, so you can reach 16 GB of ram with this method.
Just wondering, do these work on Macs?
QUOTE(IsaT @ Oct 9 2006, 02:41 PM)
Just wondering, do these work on Macs?
[right][snapback]573742[/snapback][/right]
Nope.
QUOTE(PCFredZ @ Oct 10 2006, 06:39 AM)
Nope.
[right][snapback]573780[/snapback][/right]
That sucks, us macies always miss out
Off TOPIC: Mac has now been rated as the fasted desktop and laptop computing in the world. Suck on that PCs!!
It is also the most unpopular OS for those of us who like games. Haven't you noticed that not as many games are made for mac as opposed to Windows?
Anyone here wanna bug Blizzard into putting new actions and conditions in Staredit?
lol, that would be so awesome... however, the patch would be so large, you might as rename the game starcraft 2
Not at all. A while ago, Clokr and I had done some experimenting with adding conditions and actions through code injection. I think SI had done something similar (project stingray I believe it was called).
lol, i wasn't actually being serious. i've always imagined it'd be fairly simple, cause we're basically doing the same thing with EUDs.
ADDITION:
ps, how did the projects turn out?
I duno much about Clokr's or SI's work. I think they got something working. I did too, but it was for one of the 1.13 versions and wouldn't work on 1.14 (although it wouldn't take much to get it there). The main issue is that you have to run a patching program after running SC (like EUDEnabler) and you'd need a map editor capable of creating these new triggers (I had to hex them into the map).
it would not be that hard to add them to überation
That may be true. One of the reasons the project didn't get all that far is that I wanted to standardize a set of triggers with SI, or even work together with him; having two systems to accomplish the same goal would hurt our projects in the long run since you would only be able to run one of them at a time. He agreed with me on this point, but we never really got anywhere cooperatively. Maybe I'll start working on something again and we'll see if he shows up =P
One of the problems with this program is that, like all memory patchers, it will likely stop working between patches. I know DoA is working on a data file system for his FireGraft project to work around that; maybe I could use something similar.
QUOTE(Heimdal @ Oct 21 2006, 10:27 PM)
Not at all. A while ago, Clokr and I had done some experimenting with adding conditions and actions through code injection. I think SI had done something similar (project stingray I believe it was called).
[right][snapback]577118[/snapback][/right]
Hmm, sounds interesting.
QUOTE(Heimdal @ Oct 22 2006, 02:01 AM)
I duno much about Clokr's or SI's work. I think they got something working. I did too, but it was for one of the 1.13 versions and wouldn't work on 1.14 (although it wouldn't take much to get it there). The main issue is that you have to run a patching program after running SC (like EUDEnabler) and you'd need a map editor capable of creating these new triggers (I had to hex them into the map).
[right][snapback]577197[/snapback][/right]
Ooh, SCMLoader would be the perfect place for putting in such a patcher.
Especially since it is already a patcher related to Starcraft maps.
QUOTE(Heimdal @ Oct 22 2006, 10:11 AM)
One of the problems with this program is that, like all memory patchers, it will likely stop working between patches. I know DoA is working on a data file system for his FireGraft project to work around that; maybe I could use something similar.
[right][snapback]577311[/snapback][/right]
If I knew enough about the patches performed, I could possibly update the offsets on my own for each new Starcraft version while in the process of updating SCMLoader for that version.
Hopefully this isn't patched as well. v_v
Though conditions usually aren't patched, or something like that...
They won't be patched specifically since the Extended Player Resource actions don't work. However, it does get scrambled in patches.