Staredit Network > Forums > SC1 UMS Theory and Ideas > Topic: Death-Table-Addon EUPs
Death-Table-Addon EUPs
May 17 2014, 8:12 am
By: jjf28
Pages: 1 2 34 >
 

May 17 2014, 8:12 am jjf28 Post #1

Cartography Artisan

So... I moved the command centers addon pointer from the comsat station to the death table :awesome: - 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.



TheNitesWhoSay - Clan Aura - github

Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

May 17 2014, 12:13 pm trgk Post #2



hahahaha

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



EUD

May 17 2014, 4:28 pm jjf28 Post #3

Cartography Artisan

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.



TheNitesWhoSay - Clan Aura - github

Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

May 18 2014, 4:15 pm LoveLess Post #4

Let me show you how to hump without making love.

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?



None.

May 19 2014, 4:34 am jjf28 Post #5

Cartography Artisan

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.



TheNitesWhoSay - Clan Aura - github

Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

May 20 2014, 4:37 am trgk Post #6



hahahaha

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



EUD

May 22 2014, 8:08 pm jjf28 Post #7

Cartography Artisan

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]




Quote
1. If we operate with multiple extended units, trigger execution time will be much shorter. (I hope)

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

Quote
2. Modify 0x6509B0 and give extended units to Current player. In this way we can give any unit to any player we want, thus modify sprite player(byte) to any values we want.

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

Quote
3. Pointer to CSprite can be not aligned to 4byte boundary, so we can actually modify anywhere in the location, not only the third byte.

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.



TheNitesWhoSay - Clan Aura - github

Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

May 23 2014, 8:21 pm 007shinobi Post #8



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



None.

May 23 2014, 8:32 pm jjf28 Post #9

Cartography Artisan

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



TheNitesWhoSay - Clan Aura - github

Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

May 23 2014, 8:47 pm 007shinobi Post #10



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 :(.



None.

May 25 2014, 6:14 pm Raygoza Post #11



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?



None.

May 28 2014, 10:02 pm jjf28 Post #12

Cartography Artisan

EUD enabler map can be done easy enough

Quote
Do you mean within a size limit do anything a mod can do but have it intergrated in the map?

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.



TheNitesWhoSay - Clan Aura - github

Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

Jun 4 2014, 7:44 pm LoveLess Post #13

Let me show you how to hump without making love.

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.



None.

Jun 4 2014, 7:55 pm Roy Post #14

An artist's depiction of an Extended Unit Death

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.




Jun 4 2014, 9:50 pm LoveLess Post #15

Let me show you how to hump without making love.

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.



None.

Jun 30 2014, 10:33 am Raygoza Post #16



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.



None.

Jul 18 2014, 8:03 pm Cinolt Post #17



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.



None.

Jul 19 2014, 1:21 am trgk Post #18



hahahaha

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



EUD

Jul 19 2014, 1:39 am Cinolt Post #19



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.



None.

Jul 21 2014, 5:19 am ClansAreForGays Post #20



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




Options
Pages: 1 2 34 >
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[12:54 pm]
Ultraviolet -- :wob:
[2021-10-22. : 8:31 pm]
O)FaRTy1billion[MM] -- :wob:
[2021-10-22. : 6:07 pm]
UndeadStar -- :wob:
[2021-10-22. : 12:00 pm]
Ultraviolet -- :wob:
[2021-10-22. : 10:38 am]
jjf28 -- :wob::wob:
[2021-10-22. : 10:32 am]
Zycorax -- :wob: intensifies.
[2021-10-22. : 8:51 am]
Zincoshine -- :wob:
[2021-10-22. : 4:43 am]
RdeRenato -- :wob:
[2021-10-22. : 4:43 am]
RdeRenato -- : wob :
[2021-10-21. : 4:52 pm]
jjf28 -- :wob: cause you failed to prefix your message with :wob:
Please log in to shout.


Members Online: IlyaSnopchenko, Roy, Omen