EUD tutorial

[matefkr]

I will share informations here and an EUD sample for 1.12b version (remove dt permacloak and something related to marine).

Basic info:

-sc stores data in the memory (imagine like a line of bytes)
-when sc start to run, it get a sized memory (virtual memory) from windows (i don't know mac system).
-There are two part of that memory: code and data memory (segment). While code memory is readable and executable (cpu can interpret numbers here as commands); data memory is writeable and readable.
-so sc store data about deaths in the data memory.
-The first dword (4 byte) in the deaths data memory section contains the number of deaths of marines suffured (maybe typo) by player 1. The memory address of the player1 marine deaths isn't the same in every sc version.

Let's say for example: 00560009h (h in the right side means that the number is in hexadecimal) is the address of player1 marine deaths. Note: there are 4 byte to store the deaths of a unit and you can only write/addres four byte with death triggers(every 4the byte from/with the begining of death table); but you can access bytes, as a part of a dword. So the next death data (player2 marine death) is on 0056000dh (00560009+4), and the next (player3 marine death) is on 00560011h and so on, till it reach player12?).

So how does the death trigger work?

The engine have the base address of death "table" (address of player1 marine deaths), it adds unitId*48 (you can get the id from datedit and such if you wanna check) + playerId * 4 (becouse every death use 4 bytes) [!playerId is 0 based so player1 = 0]. That will be the address. If it is the condition, the engine compare the 4 byte long number with the number given in a death trigger (the number of deaths). If it is the action, it will set the 4 byte long number in that addres, or it will add to or substract from the 4 byte long number in that address.

You only can reach memory after the death table (unit id and player id can be only positive value). And also, here is a major problem about EUD: you can't write every dword after the death table. After every eigth's dword, you can't acces 4 dword (so you can't write p9-p12 deaths).

So, if you set a higher value for the unitId then The higher unitId value in units.dat, you can address memory outside of the death table (becouse you have to give the unitId as a two byte number; max value 65535, but the highest unitId in units.dat is smaller than that).

What to do?

Get a memory viewer (ArtMoney, for example), run sc, push windows button, run memvviewer, attach/get/ something else process, pick sc from the list, then searche for value 0 (if 0 player1 marine died), then continue run sc, kill one marine of yours (if you are obviously the player 1), then push windows button again, then search for 1 in the last founds (sieve in artmoney), then continue sc, kill another marine, then interrupt again and search for 2 and so on, till you can found only one address. then you should change the value in that address, and make check.

Note: bytes on greater addresses, are byte on greater powers. So if you want to write down 4 byte (when you have one on the 1, one on the 2, one on the 3 and one on the 4 address) correctly as one 4 byte long number, you have to write it reverse, so write the last one (on greatest power) to left and the first one (lowest power) to right (i think you can figure out what i mean), becouse some memviewer write bytes from left to right (addresses increase from left to right).

Back to story: after changed the value of p1 marine address, go back to sc. You should create a map for that, which should have a trigger, which should continiously do something if p1 suffured exactly "some" deaths of marines.

With that, you shall find the base address of death table, and knowing that, you can interchange offsets to death trigger parameters (playerId, unitId).

BUT YOU DONT NEED THAT process, if you want to write eud trigs for 1.12b, just get ubecalc made by LegacyWeapon. It is a little messy but well usable. On the first screen you can see a combo-box. Pick 1.12b actions from the list and work with that (this is 1.12b addresses, not actions). You can change several things. If you want to calculate an inputed address, then substract 32 from that address before.
Here is the link: übecalc2 (http://clanunknown.net/euds/ubecalc2.php)

Also you can find a free memory block usable to store custom data from
006c4f00 to 006c5d00 (1.12b version). You can use that to save/load data between scenarios.

Note: EUD actions can only work below or with 1.12b version or in every version where EUD enabler works. Here (http://quickshare.ru/upload/3829/fff2.zip) is an 1.15.1 sc executable version but still only runs on podolsk (or other similar gateways).
EDIT:
EDIT.

[Durandal]

This is really helpful, but I wish there was more meat to it.

I don't know the difference between signed and unsigned bytes, or for example, there's an EUD action on that Ubecalc that allows you to set a unit name to a different string, but I don't know how to actually edit the offsets or whatever to reflect what string I want it to load?

Can you address simple things like that, as well as how to set up a trigger using a normal editor? I don't suppose that ubecalc will be updated anytime soon either, as it's missing a lot of things.

[matefkr]

This is really helpful, but I wish there was more meat to it.

I don't know the difference between signed and unsigned bytes, or for example, there's an EUD action on that Ubecalc that allows you to set a unit name to a different string, but I don't know how to actually edit the offsets or whatever to reflect what string I want it to load?

Can you address simple things like that, as well as how to set up a trigger using a normal editor? I don't suppose that ubecalc will be updated anytime soon either, as it's missing a lot of things.

1. There is no difference between signed and unsigned bytes, but program can handle byte signed or unsigned: if unsigned, then the min value will be 0, max 255, if signed, the bit on the highest power will show the sign (0 positive, 1 negative) but here is an example: +100 = 01100100; - 100 = not(01100100) + 1 = 10011011 + 1 = 10011100, note in form 128 and -128 is equal, so there is only -128 (if the data size is byte and threated as signed).

2. units names are pointers (ids) to strings in stattxt.tbl. The best you do is to copy other unit values.

3. i will make an example for that (but not now).

4. i will make an offset list.

[Durandal]

Yes, but the thing is I'm pretty sure that ubecalc is telling me this

0 = Default name.
1 = Changing this number will point the unit name to a different string number.
2 = Refer to an editor find out what number corresponds with which string.

So obviously, if I edited a certain byte that tells it what string to refer to, I can give it a different unit name. (On a related note, does it refer to stat_txt.tbl, or to the SCM's string file? If I edit a name for lets say, a mineral chunk, and changed a Marine's name to the mineral chunks, will it give me the mineral chunk's default name, or my edited one?)

Offset from Deaths of P1 Marines: 1729652
Player ID: 6
Unit ID (unsigned): 36034
Unit ID (signed): -29502

However, when I bring that knowledge to here, what the hell do I edit? Let's say I want to set it to string 17? I also am not completely sure how to set up the trigger itself. Is it like (using quotes for organization purposes);

Actions:
Always

Conditions:
Modify Death counts for player 6: set to 1729652 for UnitID:36034?

[matefkr]

Actions:
Always

Conditions:
Modify Death counts for player 6: set to 1729652 for UnitID:36034


you have to insert 17 after set to. Offset from p1 marine death (here is written in hexadecimal) means the distance between that memory location and the begin of the death table. But it is not important now. However, there is also a sign which tells you the byte offset in the double word (four byte) you will write. so. if it is at the first postition, then you will write set to 17, but if it is on the 2-nd byte position you will write 17*256, if it is at the 3rd position you will write 17*256*256. You better wait a little for the offset list for the 1.15.1 exe i have providen before, also that exe can do things better (attached readme in the zip).

[matefkr]

Check out Farty's (http://farty1billion.dyndns.org/EUDDB/) EUD page for memory offsets.