So I was doing some theorizing about EUPs/nEUDs and came up with a really cool idea. (That's why I came back to SEN. No trolling pls.) Sadly I couldn't find the version of SCMDraft I need in order to actually test it; if anyone could point me to the version where you can change a unit's ID, that would be most welcome. Anyway, I'll try to explain my method now.

If you Give an extended unit, it subtracts from one address based on its unit ID and the player that owned it before it was Given, and adds to another address based on its ID and its owner after it was Given. This means that if you Give a unit and then immediately Give it back, nothing changes. However, I realized that, with another extended unit, you could modify its unit ID or player ID between the two Gives. The specific application of this technique I have in mind is to use this to increase the unit ID of yet another extended unit, which can then be used to write to other addresses. Doing this actually requires five extended units. To help explain why, I'll copy part of the unit struct reference:
The first, EU1, is the unit we wish the change the unit ID of. The second, EU2, is set to write to EU1's MainOrderTimer field. (If you look at the unit struct reference you'll see that this is 16 bytes beneath the unit ID field. Raising a unit's player ID by 1 through the Give trigger causes one memory location to be decreases and the one four bytes higher to be increased.) The other three extended units, which I call the "switcher units", are set to add to EU2's MainOrderTimer, which is also four bytes above PlayerId. We repeatedly do the following:

• Give the switcher units so that their player IDs decrease by 1. EU2's playerId goes up by 3.
  
• Give EU2 so that its playerId increases by 1. This subtracts 1 from EU1's shields and adds 1 to its unitId.
  
• Give the switcher units' back.
  
• Give EU2 to its original owner. This deceases EU1's OrderTargetX by 1 and increases its MainOrderTimer by 1.
  

The end result is that EU1's unit ID goes up by 1, and some other fields that don't matter are changed around. This could be used to get extended units set up to write to addresses we previously couldn't reach.

+0x2073, threadPtr

Rewording your explanation a bit so I can think about it better:


Key:

Units
Player
EUP operation
Side-effects


Setup:

3 Switchers are setup such that giving them subtracts from EU2's main order timer
EU1 is having its UnitID changed
EU2 is setup such that giving it subtracts from EU1's shield


Process:

Give Switchers to current owner-1
     Increases EU2's current owner by 3
     Decreases EU2's MainOrderTimer by 3

Give EU2 to current owner+1
     Increases EU1's UnitID by 1
     Decreases EU1's shields by 1

Give Switchers to current owner+1
     Decreases EU2's current owner by 3
     Increases EU2's MainOrderTimer by 3

Give EU2 to current owner-1
     Decreases EU1's OrderTargetX by 1
     Increases EU1's MainOrderTimer by 1


Net Effect:

Increases EU1's UnitID by 1
Decreases EU1's shields by 1
Decreases EU1's OrderTargetX by 1
Increases EU1's MainOrderTimer by 1

Post has been edited 4 time(s), last time on Jan 29 2013, 8:40 pm by jjf28.

Is changing a unit's PID directly enough to cause the control tables to update? I assume this would only be for players between 1-12, and the give trigger would be what ultimately sets off the EUP for the manipulated unit.

Also, most versions of ScmDraft (including the latest) allow you to change a unit's ID in the property window; just enter it as a plain number.

Post has been edited 1 time(s), last time on Jan 29 2013, 10:00 pm by Roy.

No, according to my tests. Modifying a unit's owner by EUP does not update the tables, which is the whole point of this. (Though admittedly I tested it with a mod that changed the unit ID, rather than changing it by EUP, but I doubt that'd matter.)

EDIT: @jjf28: That looks right.

Hey, people who actually know what they're doing, has anyone looked into this at all yet? >_>

Started on the math, needed three give-able units two of which point to the sweet spots inside the unit table, a third of which should be giveable and have an index as high as possible.

Realized we don't really have that, built a scanner, scanned UnitID 227-17000 on windows XP for player 2, got these results (unfortunately there seem to be none after ~14500)

Need to filter the results with a windows 7 computer; scanner currently isn't programmed to use a scanlist; this is the point i'm at now, and will push forward when i'm not swamped with schoolwork.

After that the results need to be filtered further to find give-able units, need more mods to the scanner.

After all that jazz, this'll get tested

How's that goin'?

*pokes jjf28*

higher priority

back to this after basic unit display/editing is working

If you're looking for a more updated Unit structure reference, use this: https://code.google.com/p/bwapi/source/browse/branches/bwapi4/bwapi/BWAPI/Source/BW/CUnit.h#40

We still just need a comprehensive list of extended units that don't crash. Post the source for your scanner, jjf?

Glorious.

You've come so far my child...

Updated to reflect changes in the files grabbed from chkdraft, prolly alot of junk hanging around in the code but i've already spent more time on this than I wanted to atm.

- No longer uses a config file, fetches sc directory from registry or fails to open.
- Better looking GUI
- More options? don't really remember how it was b4
- Logs to new text file every test start/stop
- Source included

Attachments:

This example map add's 75 to the unitID, then subtracts 9, turning a marine into a goon using 3 units.

Thinking ahead we can freely add to a unitID, change something at the address, then subtract back to a normal unitID, cheers!

Attachments:

I came up with an elaborate strategy to modify only the unitID of a post-placed unit to an arbitrary value, but it appears that StarCraft unfortunately polls the unitID every frame, so crashes still occur after modifying only the unitID.

The LoopEUPs.scx doesn't add to an extended unitID, and the method in the Dynamic Unit ID map by Chia-Tyrant is limited by pre-placed units limit, and still would crash at units like goliath turret and most extended unitID's.


This unfortunately will only work for amounts that you can both add then subtract in a single trigger cycle, but should in theory work (haven't tested yet).

?


I've greatly expanded on the method: http://www.staredit.net/topic/16427/ , much freer to edit unit ids inside interceptors, addons, powerups, etc.

Dragoon is an extended unitID?

oh misinterpreted that, you can reach some extra extened unit ids but yea most are still offlimits