There are 256 possible owners rather than 12; these don't all work with gives but for placing and deaths they typically do.

It would be nice if you added comments for every line, it gets confusing when you have to figure out which action each line of triggers is doing, (just giving to a player? affecting address through table 1, 2? by giving or removing?)


7.1


Two Switchers: UnitID 2635 owned by Player 12 at arbitrary indexes
One Bumper: UnitID 2547 owned by Player 12 at index 1648
One Target: Any UnitID owned by Any Player at Index 1628


Initialize:
Give Units to Player("Player 12", "Player 3", 2547, 1, "Anywhere"); \\ this is just to get the bumper in position? (p3 bumper), why not just start out with the bumper owned by p3?

Loop format:
Give Units to Player("Player 12", "Player 1", 2635, 2, "Anywhere"); \\ +2 to player id for the bumper (p5 bumper)
Give Units to Player("Player 5", "Player 7", 2547, 1, "Anywhere"); \\ bump target unit id (p7 bumper)
Give Units to Player("Player 1", "Player 12", 2635, 2, "Anywhere"); \\ -2 to player id for the bumper (p5 bumper)
Give Units to Player("Player 5", "Player 3", 2547, 1, "Anywhere"); \\ move bumper into position to repeat loop (p3 bumper)
(Repeat this to increase by multiple)

Trigger Cycle End:
Give Units to Player("Player 3", "Player 12", 2547, 1, "Anywhere"); (The Switchers will no longer work when the trigger cycle ends)

\\ (p12 bumper) why don't the switchers work anymore? couldn't we just repeat the initialize step to start doing loops again? whats the point of this step, couldn't we just have a death counter that tells the loop to repeat x times and to then stop?

I guess this last step is undoing the memory alteration caused by the initialize step?






7.2



A Protoss carrier is owned by Player 5, it is located at index 1627 and has 1 interceptor in hanger (so the interceptor is at index 1628).

Triggers to decrease target value by 1:

Give Units to Player("Player 3", "Player 1", 2547, 1, "Anywhere"); \\ move bumper (p1 bumper), what else does this do?
Give Units to Player("Player 12", "Player 1", 2635, 2, "Anywhere"); \\ +2 to bumper player (p3 bumper)
Give Units to Player("Player 3", "Player 5", 2547, 1, "Anywhere"); \\ move bumper (p5 bumper), what else does this do?
Give Units to Player("Player 1", "Player 12", 2635, 2, "Anywhere"); \\ -2 to bumper player (p3 bumper)
Give Units to Player("Player 5", "Player 7", "Protoss Carrier", 1, "Anywhere"); // Get carrier player to match interceptor player (p7 carrier)
Give Units to Player("Player 7", "Player 5", "Protoss Carrier", 1, "Anywhere"); // Decrease target given by give formula with player 7 by 1, is this via table 1 or 2?
(Repeat to decrease by more)


what happens when u give an interceptor to a different player then the carrier?



7.3

Addon address (modified) = Value at: (owning building’s address) + 128 \\\\ this is where the address of the addon of the current unit is stored? so if we change the value at (owning building’s address) + 128 we can can specify any unit we want to be it's addon?

Addon’s CSprite address = (Addon address) + 12
Addon’s UnitID address = (Addon address) + 100
Addon’s Player address = (Addon address) + 76

Setting Target Byte by Giving:
Addon’s CSprite Value = (Target Address) – 10
Give to Player 1 + (Target Value-1)

Target Address + 4, 4th bit must NOT be set \\\\ we must make sure that 0x4 is not set or is it 0x7? (does not set mean =0?)
Target Address +18 (4 bytes) must be zero \\\\ make sure 0x12, 0x13, 0x14, 0x15 are 0?

By Giving:
Address incremented = 48*(Addon’s UnitID Value) + 4*(New Owner) + 5776160
Address decremented = 48*(Addon’s UnitID Value) + 4*(Addon’s Player Value) + 5776160 \\\\ addons player value = old owner?

Address incremented = 48*(Addon’s UnitID Value) + 4*(New Owner) + 5787104
Address decremented = 48*(Addon’s UnitID Value) + 4*(Addon’s Player Value) + 5787104


- Incremented/Decremented means +1/-1


the set up seems to be

Given:
Target Address satisfying: Target Address + 4, 4th bit must NOT be set, Target Address +18 (4 bytes) must be zero
Unit at address X (playing add-on role) with Address X+12 = target value - 10
Unit at address Y (playing ‘being added on to’ roll)


step 1) set Address Y + 128 to X
step 2) give the Address Y unit to 1+(Target Value - 1)

I'm not seeing what we're accomplishing with 7.2 or 7.3

Post has been edited 3 time(s), last time on Oct 4 2014, 11:54 pm by sigsaucy.

I just added the template dEUP map: dEUP 256xTemplate.scx


I didn't bother to calculate all of the effects, and my original notes are missing I'll prolly reverse engineer all the effects sometime.


In my experience something happens to ID:2547 such that it's no longer give-able the first or 2nd frame after the 1st trigger cycle. If the "reset" trigger isn't executed, then the game crashes; so I sometimes combine them saying this trigger destroys the unit. Its purpose is to avoid the crash, it might undo an alteration from initialize, I haven't isolated the exact memory cause of the crash.


You can't use the give trigger I don't think; when you change the player with EUPs you can change what address gets subtracted from when it gets given to someone else (old owner in give formulas).


Pretty much, but it doesn't have to be a unit, I make the addon to be the first several entries of the death table.


Target Address + 4, 4th bit (0x8) must NOT be set


Essentially, but we have the freedom to select where the player value is located, and in the case of the death table we can freely modify it.


Loop EUPs move the interceptor's unitId to a place where it can edit an addon pointer, Interceptor EUPs (assisted with Loop EUPs) subtract from an addon pointer till it reaches the death table, dEUPs take over.

Post has been edited 6 time(s), last time on Oct 7 2014, 6:51 pm by jjf28.

here are some notes I made on the template map, not all organized enough to be included in the guide just yet

ID:2547
Minimum xc: 257
Minimum yc: 257
Maximum xc: mapWidth*32-1
Maximum yc: mapHeight*32-33
Crash conditions: Selected, often becomes crash on view after using EUP operations., index must equate to 1648 (will appear as 1647, but the interceptor in the carrier counts as 1)
Recommendations: Place at (mapWidth*32-1, 257)
Notes: Selectable anywhere

While the x coordinate (mapWidth*32-1) is ideal SCMDraft deletes units at these positions on map load (Chkdraft can be used to toggle their positions if necessary) so you may prefer x=mapWidth*32-9 at least until you are finished creating an end-user map.


ID:2635
Minimum xc: 0
Minimum yc: 0
Maximum xc: mapWidth*32-1
Maximum yc: mapHeight*32-33
Crash conditions: Selected
Recommendations: Place at (mapWidth*32-1, 0), if stacking, vary each stacked unit's yc by 1 to avoid a glitch that makes it selectable, indexes can be whatever.
Notes: Stackable, Unselectable when at the maximum xc.

While Coordinates x=mapWidth*32-1 and y=0,1,2... are more stable/ideal, SCMDraft deletes units at these positions on map load (Chkdraft won't, so you can use it to toggle their positions if necessary), so you may prefer x=mapWidth*32-9, y=9,10,11... at least until you are finished creating an end-user map.

ID:Carrier
Minimum xc: 32
Minimum yc: 32
Maximum xc: mapWidth*32-33
Maximum yc: mapHeight*32-32
Crash conditions: View during load
Recommendations: Place at x=mapWidth*32-33, y=32, index must equate to 1627, player should be p5 (may be possible to vary this), must have 1 unit in hanger.

ID:Comsat Station
Recommendations: index must be 0, unit sprites cannot be uesd (they would change the index), place wherever you wish, should be invincible.

ID:Command Center
Recommendations: must be linked to the index 0 comsat, move to wherever you wish, should be invincible., index must equate to 1646 in game (will appear as 1645).

ID:Start Location
Recommendations: place last, after anything else

ID:Map Revealer
Recommendations: they make good fillers for getting the carrier and ID:2547 to the required indexes, you may replace them with your own units but make sure the units are always in game (a good strategy is to have them owned by p9-12 then given to dest players), and make sure the indexes still come out properly.

Post has been edited 1 time(s), last time on Feb 24 2015, 7:16 pm by jjf28.

To have this clearly posted: dEUPs are now windows 8/windows 10 compatible, making them valid across the windows platform since XP.

So I calculated pretty much all of the effects of the dEUP setup process the other day (the useful ones we already know, but the side-effects we didn't necessarily know).

Too busy for a nice write-up and exhaustive testing at the moment so here's a quick summary and my raw notes:

Summary:
    Index 1613 - Receives some changes such as halt location being moved left, probably safe (make it a map revealer if you're worried)
    Index 1616 - Receives some changes such air strength+6, probably safe (make it a map revealer if you're worried)
    Index 1661 - Receives unsafe changes to attributes like visibility, status flags, unit-being-built-inside, make this a map revealer or a unit that gets removed after setup.

All other effects are all to indexes that are expressly used in the dEUP setup process and are known not to be generally dangerous.


Edit: A limit to equations based on table 1 have been found... UnitID cannot be higher than 11522, so address edited cannot be higher than 0x6093B0 (you cannot edit units at indexes lower than 379, and for index 379 you can't edit offset 0x13C and higher)).

Attachments:

Post has been edited 8 time(s), last time on Nov 16 2015, 5:20 pm by jjf28.