So... I moved the command centers addon pointer from the comsat station to the death table - allowing the sprite pointer to be set with "Set deaths of Terran Marine for player 4", and any other properties you wish to explore to be set in the same way (such as unitID and player).


When you give a command center with a comsat station to a different player the player field of CSprite is written to, which is a 1-byte set.


Use 1: You can now set any byte starcraft has write access to, to a value 0-10 (ie: you can read 4-byte values with 1024 triggers, you can change a 4-byte value by millions in an instant)

    To do so set deaths of player 4's marine to your targetAddress-10
    Then give the command center to the player+1 you want to set the targetAddress to

    Restrictions (note: you could work backwards from zero'd values):
        targetAddress+4 bit4 (whether the sprite is selected) must NOT be set
        targetAddress+18 (4 bytes) must be zero


Use 2: You can now add or subtract 1 very easily from any 4-byte value starcraft has write access to by setting the unitID and player fields embedded in the death table (you could create hundreds of EUP units with minimal hassle).

    To do so set deaths of player 2's vulture to floor((targetAddress-5776160)/48)
    Then give the command center to player ((targetAddress-5776160)%48)/4 (adds) _{1-based player}
    Or give the command center away from player ((targetAddress-5776160)%48)/4 (subtracts) _{1-based player}
    To do this continuously, reset deaths of p2's vulture before changing back player


Use 3: You can decrease a value to any amount easily by setting one or more bytes to 0, subtracting 1 from the 4-byte amount, and repeating


Example map: this map takes 1-5 seconds to load, it will appear frozen for that time, after that, the last trigger for p1 will give the command center from p1 to p2, which due to how p4's marine deaths are set, will increase the targeted byte by one (in this case the second byte of minerals increases by 1, adding 65536 minerals).

Download

Cheers!

Post has been edited 10 time(s), last time on Aug 25 2015, 2:46 am by jjf28.

hahahaha

Post has been edited 2 time(s), last time on Aug 2 2014, 4:17 am by trgk.

All Unit Counts Table:
48*UnitID + 4*Player + 5776160

Completed Unit Counts Table:
48*UnitID + 4*Player + 5787104

Give simply adds 1 to address given by the player it goes to and subtracts one from the address given by the player it comes from
The spritePointer+0xA is also set to the player the CC's given to, which sets a sprites owner unless you change the sprite pointer.

---

Now for how the map works... if text isn't colored it's because the effect is negated later or generally unimportant

- The "set" trigger moves UnitID:2547 from neutral to p3, which means UnitID:2547 is now in position to add to the interceptor's (index 1628) unitID

- The "add to UnitID" triggers increase the interceptor's (index:1628's) unitID, until it reaches 2651 (the position required to edit the command centers addon pointer), the following operation increases the interceptor's (index:1628) unitID by 1
     - Give 2 UnitID:2635 owned by Neutral to Player 1 (subtracts 2 from orderQueueTail, adds 2 to UnitID:2547's (index:1648's) player (so it's now 5))
     - Give 1 UnitID:2547 owned by Player 5 to Player 7 (no subtract, adds 1 to interceptor's (index:1628's) untiID)
     - Give 2 UnitID:2635 owned by Player 1 to Neutral (subtracts 2 from UnitID:2547's (index:1648's) player (so it's now 5), adds 2 to orderQueueTail)
     - Give 1 UnitID:2547 owned by Player 5 to Player 3 (no subtract, adds 1 to mainOrderTimer)

- The "Subtract from Target" decreases the command center's (index:1646) addon pointer until it reaches 5808996 (the start of the death table) the following operation subtracts 1 from the addon pointer (aka where the interceptor is setup to edit using equation 1)
     - Give 1 UnitID:2547 owned by Player 3 to Player 1 (no subtract, adds 1 to interceptor's (index:1628's) player)
     - Give 2 UnitID:2635 owned by Neutral to Player 1 (no subtract, adds 2 to UnitID:2547's (index:1648's) player)
     - Give 1 UnitID:2547 owned by Player 3 to Player 5 (no subtract, adds 1 to orderTargetUnitPointer)
     - Give 2 UnitID:2635 owned by Player 1 to Neutral (subtracts 2 from UnitID:2547's (index:1648's) player, adds 2 to orderQueueTail)
     - Give 1 Protoss Carrier owned by Player 5 to Player 7 (subtracts 1 from CC's addon pointer (since interceptor is UnitID:2651 and owned by p6 at this point), and adds 1 to CC's addonBuildType)
     - Give 1 Protoss Carrier owned by Player 7 to Player 5 (subtracts 1 from CC's addonBuildType, adds 1 to CC's loadedUnit#4) -- this is just to get the carrier back to p5
    
- The "finish" trigger moves UnitID:2547 from p3 to neutral, preventing the crash that tends to result from staying with p3


So in summary:

- The group of UnitID:2547 and UnitID:2635 increases the interceptor's (index:1628's) unitID to 2651
- The interceptor edits the command centers addon pointer with UnitID:2547 and UnitID:2635's to help change its player
- Now when the command center is given, the "addon" as it appears in the death table is also given, its spritePointer, unitID and player all being under your direct control

Post has been edited 7 time(s), last time on Jul 23 2014, 10:37 pm by jjf28.

So, for the less intelligent and short-sighted people, what you are saying is that you made EUDAs possible in a work-around? We can write to SC's memory again?

We can indeed write to StarCraft's memory again!


Layout of how much power we have at diff. locations in memory:

Byte-set (set bytes to 0-10) <---- 0x00582324 ----> Near full control (Set byte to 0-10, add/subtract from 4-byte values)

Before 0x00582324 we can only set bytes to 0-10

After 0x00582324 we have have the same as before plus full control over what the last three bytes of any 4-byte block becomes (combined we have the power to subtract by any amount), but the highest byte we can only feasibly set to 0-10.
 

Post has been edited 5 time(s), last time on Jul 23 2014, 10:38 pm by jjf28.

hahahaha

Post has been edited 5 time(s), last time on Aug 2 2014, 4:17 am by trgk.

New method for 4-byte sets confirmed!

Prime the surrounding memories to avoid the restrictions (see below)
Adjust CSprite ptr of a powerup so the "sprites" position overlaps the target address
Move the worker holding the powerup to the position (the value you want to set the target address to)
Remove the worker holding the powerup
Restore CSprite ptr of the powerup

Restrictions:
    targetAddress-0x14 and -0x10 (both 4 bytes) must be 0
    targetAddress+0x4, +0x8, and +0xA (all 4 bytes) must point to readable memory

---

So to run an exe...

[Withheld for now]

---

maybe a bit, but there's heavy diminishing returns with setting up more extended units so that's something to look at later


tried it, but it does bound checks on current player as well


indeed, however we can only set bytes to 0-10, and since we only have superb subtract powers and not addition, the highest byte cannot be easily manipulated with gives (which is why I sometimes say we only have complete power over the last 3 bytes... until now)

Post has been edited 2 time(s), last time on Aug 2 2014, 6:01 pm by jjf28.

I think I'm completely misreading this but when u mean by running an executable, are you leaning towards running mods?

I mean running executable code without the help of external programs (just through StarCraft maps) - you could run mods through this if they were of reasonable size

Wow thats amazing... keep up the good work! Also another stupid question... could we make something comparable to EUD enabler to execute for every player? I don't really understand much of the technical detail though .

jjf28 Does this mean that you could make maps that change as many things in WC3 as in SC using this?
Do you mean within a size limit do anything a mod can do but have it intergrated in the map?

EUD enabler map can be done easy enough


I can't confirm what i'm not sure of, but you can include almost anything in an MPQ and do almost anything with executable code so reasonably sized mods should be possible to integrate in a map, whether with ease or difficulty I can't say for sure

I'll also note that the extended units necessary will almost certainly crash macs and some pcs, though the overflows should otherwise mirror nicely across operating systems.

Post has been edited 1 time(s), last time on May 28 2014, 10:07 pm by jjf28.

So currently, the two most desired things would be...

Giving the unused players vision, which to my knowledge, isn't something we could do before. Can we do this for the higher number players? Being able to use P13 and beyond would be revolutionary. The second would be as you said, an EUDA Enabler.

Because of the way the data is stored in memory, getting extended players to work as playable players is out of the question, but getting trigger conditions and actions to be able to recognize units owned by extended players may be possible. It would require much more work than just manipulating the Set Deaths action to overflow again, though.

I realize that you wouldn't be able to get them to work as normal players, but just being able to use them as pseudo computers that you can order around is more than enough.

By the way could you inject hacks in the map file?
If yes could you do that with a mod together with the hack?

How do I do any of this?
Is it an executable or an MPQ that is injected?

But how is the process of including a mod and or hacks in a map?
I don't know how to work with triggers btw.

So I just figured out what OP is talking about (not so sure about post #7 with executing code, there's no writeable data segments that also have executable permissions, so it would need to be manually set with an API call), and I'll give props to jjf28 for discovering it. It's definitely the most complicated application of extended preplaced units that has been posted on SEN as of yet, so it will take a while for me to set things up on my own but I can confirm that in theory it should be very close in power to EUD Actions. The nature of it too makes it fairly stable (as in not causing crashes) in theory.

hahahaha

Post has been edited 2 time(s), last time on Aug 2 2014, 4:17 am by trgk.

Oh, you're right. I thought those readable, writable, executable segments were unusable or something.

Holy shit, so it's pretty much confirmed that SC maps can contain full-blown viruses.

I never thought I'd see the day someone brought EUD actions back, even in workaround form. This is amazing.