Staredit Network

Ok, this isnt another post asking what you can do with them, it's a post asking how to make them work . I didn't understand the tutorial cause I don't know much about hex numbers. All I got from screwing around was that it works with multiples of 256. Anyway, when i choose something in the death count converter and it tells me the 00 00 00 00 thing with the red parts and more than one part is red, i get confused! What do i do?!

Ok, a more specific problem then. Say I want to change damage bonus on psi storm. I choose damage bonus in list one. I choose psi storm in list 2. It says 00 00 00 00. The first 4 0's are in red. Next I go into starforge and put the deaths of -29300 owned by player 3 (as specified by the converter). Now how do i find out what to put so that it'll do +5 damage per upgrade? (Don't just tell me the number, tell me how to find it out). If I understand that I'll be able to make psi storm actually be upgradable.

Edit:
Ok I got it to work, but when i up it it kills me 1 hit no matter what number

So basically since original is 1, putting 4 makes it 4+1=5? Or.. what?

Okay, like DT_Battlekruser said, you can find out you need to add 4 to make the damage bonus 5 from looking at what the original number was using Arsenal III. What I wanted to explain was, the reason you only add 4 and not some strange number like 1024, because I know that's the question you were asking. To explain what's happening, let me draw up what just happened.


(XX signifies bytes that have values we don't know.)

So our goal here is to find out what value to add in the trigger, knowing the bytes we want to edit and the amount we want to add to those particular bytes. First I'll explain how we should do it, and then I'll explain how we simplify that method.

What we did there first was we found we needed to add 4 to those particular bytes, and then we converted that into the full hexadecimal four bytes: 04 00 00 00. How did we get that?

1. We know the value 4 in hexadecimal is 4.
2. One byte is represented by a pair of hexadecimal digits. So, for the two bytes we want to edit, we need four digits (two pairs). If we were to write hexadecimal 4 with four digits, we'd get: 0004. Just like normal numbers, when you pad the front of a number with zeroes, it doesn't change the value.
3. Next we need to convert that 0004 into bytes. For some stupid reason that computer scientists call "little Endian" the smallest bytes are always written first: 04 00. See how that works? The smallest byte, 04 was written first, and then we wrote the next largest byte 00 after.
4. Now we slot the 04 00 number into the full four bytes that we are going to add into the correct position, leaving all the bytes we don't care about as 00. So, now 04 00 gets put into the full string 04 00 00 00. We don't care about those last two bytes, and so we set them to 00 so when we perform the addition they have no effect. So now we have found what we should add to the original 01 00 XX XX set of bytes to get 05 00 XX XX.
5. To get the value we should add with the trigger, we need to turn our 04 00 00 00 string back into regular hexadecimal that we can read. This means, reversing the pairs into the order that we read them in: 00000004 in hex.
6. Converting 00000004 hex back to decimal gives us 4, and so now we know what to add.

That was a bit of a boring example, but it illustrated why 4 remains as 4. Let's try that with more interesting numbers.

Say we go along to MemCalc and find we want to edit the last two bytes:
00 00 00 00

We want to set the variable we're editing to 500, and we know that it is currently 200. So, how do we know what to add?

1. We know that we want to add 300, because 500 - 200 is 300. 300 decimal is 12C hexadecimal courtesy of the windows calculator.
2. We're editing two bytes, so we need two pairs of hexadecimal digits to match the two pairs of hexadecimal digits we will be adding to. That's four hexadecimal digits in total - 012C.
3. In this step we rewrite our 012C as it would appear in a PC's memory: 2C 01. Blame little Endian for making us reverse our pairs like this. Remember, the "least significant" pair always gets written first, hence the "little" in "little Endian."
4. It is only possible for us to add four-byte values, and to work out the four byte value we're going to add we need to place 2C 01 into a string of four bytes, like this: 00 00 2C 01. We place 2C 01 in the last two bytes because those are the two bytes we're editing.
5. To get the actual value we'll be adding using the trigger, we need to turn 00 00 2C 01 back to regular hexadecimal, not "little Endian" hexadecimal. Again, we just reverse the pairs: 012C0000.
6. Now we convert 012C0000 hex into decimal, which gives us 19660800. This is the number we need to add.

If I draw a diagram of this, basically we're doing this addition:


So what you're really trying to do is find what the value of that second line should be in hex, and then converting that number back into decimal. Here are a few more quick examples:

Editing the second byte only: 00 00 00 00
1. We know the value starts off as 100, and we want to set it to 150. That means adding 50 decimal = 32 hexadecimal.
2. We need to have one pair of hexadecimal digits to match the one pair we are adding to. We already have a pair of hexadecimal digits - no need to pad with zeroes. Our number is still 32.
3. Now write 32 as it would appear in the computer's memory: 32.
4. Put 32 into the four byte string that we need to add: 00 32 00 00. All the bytes we're not touching we'll just add zero to, and they will remain unaffected.
5. Convert 00 32 00 00 back to readable hexadecimal: 00003200.
6. 00003200 hex is 12800 decimal, so we need to add 12800 decimal.

Editing all four bytes: 00 00 00 00
1. We know the value starts off as 2500, and we want to set this to 12000. That means adding 9500 decimal = 251C hex.
2. We need four pairs of hexadecimal digits to match the four digits we're adding to: 0000251C.
3. Converting to how that would be represented in the memory of a little Endian computer: 1C 25 00 00.
4. Put that into a four byte string so we know what to add: 1C 25 00 00 - no changes required here.
5. Convert back from 1C 25 00 00 to readable hexadecimal: 0000251C.
6. 0000251C hex is 9500 decimal, so we need to add 9500 decimal.

I could keep going, but I hope by now you understand the concept behind what we're doing here. If you do, then now you can cut corners.

Let's go back to the second example, where we were adding 300 to the last two bytes. What we can actually do here is, instead of following those six steps to get the value we need to add, we can actually just go: 300 * 256 ^ 2, where ^ indicates "to the power of." That equals 19660800, which is the same value we got from doing all six steps. How does this work you might ask?

Just think about it.

• If we wanted to add 300 to the two bytes starting at byte number 0, we'd be adding 2C 01 00 00, or 12C hex = 12C * 1 hex = 300 * 256 ^ 0 dec = 300 decimal.
• If we wanted to add 300 to the two bytes starting at byte number 1, we'd be adding 00 2C 01 00 or 12C00 hex = 12C * 100 hex = 300 * 256 ^ 1 dec = 76800 decimal.
• If we wanted to add 300 to the two bytes starting at byte number 2, we'd be adding 00 00 2C 01 or 12C0000 hex = 12C * 10000 hex = 300 * 256 ^ 2 dec = 19660800 decimal.

There's a pattern here. Do you see it? We're just appending 00, depending on which byte we're starting at. This is true for whatever number of bytes we're adding, the only thing that changes the number of 00s we need to append is the byte we're starting at. How can we append zeroes in hexadecimal? It's really easy. Just like we can multiply by 10 in decimal to append a zero, we can multiply by 10 in hexadecimal to append a zero. But remember, 10 in hexadecimal = 16 decimal. If we wanted to append two zeroes, we'd multiply by 100, which is 256 in decimal.

So, for byte number 0, we'd multiply by 256 (100 hex) 0 times to append 0 pairs of 00. For byte number 1, we'd multiply by 256 1 time to append 1 pair of 00. For byte number 2, we'd multiply by 256 2 times to append 2 pairs of 00. So we multiply by 256 <byte number> times. This is the same as saying, multiply by 256 ^ <byte number>.

And that explains why when you add 4 to those bytes MemCalc gives you for the damage bonus of psionic storm you just add 4 with the death counter. It's 4 * 256 ^ 0 = 4.

One last thing, changing the damage bonus won't be enough, you'll need to change the upgrade type to something like Protoss Ground Weapons. I just answered how to do that in another thread though, someone else asked how to do it for the Photon Cannon, so check that one.

Wow, indeed he is... so much typing

I don't bother with w/e byte it says to modify, since all i need to know is the unit number and player

Tyvm. I got my psi storm to upgrade . That's a lot more in-depth than the tutorial I read. Now there's another problem . I was looking through the memcalc list, and... I can't find the thing for giving a unit a tech. So is it even there? Is it the same as "Special Ability"? And is there a way to give, say, a science vessel abilities from more than one units, such as Lockdown, Optic Flare, and Load (dropship)? I was thinking of making a map where you have to transport your people through challenging places and you buy special abilites. By the way, I've been having trouble making it work for more than one unit, like making 5 gols all supergols. Is there any way around this?

Given the known limitations of what you can edit with EUD, you can't give a unit special abilities using EUD. The way we do it with modding is through a program called MemGraft, and at present I think we can assume that the offsets that MemGraft edits are outside the range of EUD. I haven't confirmed this for myself yet, although I'm planning to, but I'm pretty sure MemGraft is beyond the editable range.

However, there are possibilities. For example, I was thinking about making spells into suicide weapons used by invisible, cloaked units of another player. That way you could press a button on a selector or something and the one charge of the spell would be automatically cast to attack the nearest unit within range by creating the appropriate invisible suicidal spellcasting unit. That is possible, but as a lot of people will come to have known by now, I don't write step-by-step tutorials for large-scale changes because of the amount of time it takes and also I feel that when I write step-by-step tutorials people just borrow my modding skills for their mod (or EUD-driven map) instead of learning to do things themselves. Maybe if I have time on the weekend I'll write a tutorial that covers how to do that at a high-level, but I can't do a step-by-step tutorial for something like that.

The tutorials aren't n00b friendly. Not even n0v1c3 friendly.

Memgraft offsets are below the range editable by EUD triggers. Even if you could edit them, you'd be working with limited space. You could not add any requirements or buttons, you could only change them. And if you did not know exacty what you were changing, some requirements wouldn't work. I know this from first hand experience in changing the Archon Merge script so that any unit could merge. Dark Archons could no longer cast spells, because the req for them were messed up.