update your scmdraft.

It sounds like something else is crashing the map.

Now, I'm going to make this very clear: If my map doesn't create a marine then 0x41e283 isn't 0x39.

The process to get the number isn't too hard. If the address ends in 0, 4, 8, or C, multiply the number by 1. If the address ends in 1, 5, 9, or D, multiply the number by 256. If the address ends in 2, 6, A, or E, multiply the number by 65536. If the address ends in 3, 7, B, or F, multiply the number by 16777216. This is on a byte basis, so, no, you can't multiply 73b0796ae9 by 256.

I'm sorry, but that still doesn't make sense to me...

I have your map working, and I have the triggers for that hack working on mine.. and I understand now how you got that number...

But, for this I cannot get it.

E9 8C 41 77 is my hex.

If I take that number, put it in as a hex and then multiply it by any of the examples you gave I can't get a number that works.

For example, my first attempt was to take 41 and multiply by 256, because of

But to no avail.

I thought it was:
Byte 0 is x*1
Byte 1 is x*256
Byte 2 is x*65536
Byte 3 is x*16777216

Because 41h=65d*256=only 4100h (41 00 only 2 bytes whilst you're trying to look at byte 3)

But if you do 65d*65536 you get 410000h 41 00 00 3 byte.

Edit: Just realize E9 8C 41 77 would be flipped to 77 41 8C E9 and thus 41 would be in the Byte 1 space.

Either way I could of swore that 4 bytes had to be read; and that you couldn't just pick individual ones out.

Post has been edited 2 time(s), last time on Mar 1 2010, 7:47 pm by SkiPz.

Okay, there's two things: An address is a location where data is stored. Regardless of that data, the address doesn't change. Let's refer to this picture:

Everything in column 01 ends in either a 0 or an 8. I don't care if it says 55 there, that doesn't matter. What matters is that the ADDRESS is 0x41e280.

Now then, moving along you'll see the 4 highlighted boxes. These are what you HAVE to read. When you read a death count, you can only read 4 bytes at a time. There are two inputs into the memory condition: player number and value. The player number refers to the address. The value refers to the actual value that is in that address. That means if you want to read 55 00 00 00, the value would equal exactly 85 decimal. 55's address ends in a 0. It doesn't matter that 55 ends in a 5, that's the value. The address is what is important in this step, so we only have to multiply by 1.

The next box is 00 8B 00 00. Notice how this time the address ends in 1, so we'd multiply by 256 decimal, or 100 hex. Notice how 8B * 100 is 2 bytes? It's still exactly what you have in the memory.
So on and so forth through the next boxes.

Now, the problem with all of this is that in 55 8B EC 83, we can't detect "55" because we have to read all the bytes at the same time. Inputting a value of exactly 85 decimal would refer to a hex value of 55 00 00 00. However, that's clearly not our value. Since the other numbers are nonzero, we can't detect the 55 hex until we also detect the nonzero numbers. If they don't change, you're in luck, and you can just detect them all using my previous formula I posted (just convert the value from hex). This is why in practice you can really only detect the most significant byte in 4 byte data.

Hmph... I don't know if I'm just stupid or what but I still can't figure out how I am suppose to take E9 8C 41 77 and put that into a trigger.

What are the addresses of e9, ec, 41, and 77?
ie... "e9's address is 0x41e281."

Well, I don't know because I use Ollydbg and not Artmoney and it doesn't display like yours does... so my one address I get with E9 EC 41 77 = something that I can't re-call at this exactly moment.. but its only one address.

According to this picture:

0x41e281 : E9
0x41e282 : 6a
0x41e283 : 39
0x41e284 : 3a
0x41e285 : 6f
0x41e286 : 57
0x41e287 : 8b

Is it that hard to understand what an address is? You could also use artmoney pretty easily.

Yes, because I never understood each of those hexes correlated to an address

And I can't use ArtMoney at college because it requires admin privileges.

Here is a snapshot of the address.



So how do you add to 7E?

Post has been edited 1 time(s), last time on Mar 1 2010, 9:26 pm by Oo.DaMeiN.oO.

Just use Olly, just go to the spot in the dump where you are reading EP EC 41 77, look to the left, and there is the initial address.

EDIT:Sorry for the double post.

byte 72 Falls on address 0x48CF81 which ends with 1, so 114d*256d= 29184d=7200h; while 72FFh=29439d

Con:

Memory at Death Table -259321 is at least 29184

Memory at Death Table -259321 is at most 29439

Act:

w/e you want.



Post has been edited 1 time(s), last time on Mar 1 2010, 11:35 pm by NudeRaider. Reason: merged posts

make sense?

Skipz, that didn't work for me


Isn't it bad that the hex changes?

The first three are always the same, but none of the others.

For example:

In the picture above its E9 8C 41 72 03

In the one I have up now its E9 8C 41 CF 05



Okay, so I think I have the At Least figured out..

For this address/hex it would be the following condition, correct?

0048CF7E = -259322
E98C4152 = 16640 (This is due to the 41 > Decimal = 65*256 = 16640)

So this one will be:




But I don't know how to find the Most, I understand how I could get the number after I know which number I use.. but I cannot find it out.

As in.. the most would be say.. 52 and I would do 52 > Decimal = 82*65536 = 5373952, correct?

And for this one, if 52 was the number it would be





I also noticed Skipz, that our Olly's are different.. in the Location one you showed it has 55 E9 6A 39 62 6C whereas mine shows up as E9 6A 39 27 74 (It's missing the 55, why is that and is it vital?)

And I understand how you got the At Least.. but I can't figure out how you figured out how to multiply it by FF FF FF to get the At Most, because I can't get the number you got doing any of the math you've given.

Post has been edited 7 time(s), last time on Mar 2 2010, 3:40 pm by Oo.DaMeiN.oO.

yes
no
0048CF7E = -259322
E98C4152 = 2364080128 (This is due to the e9 > Decimal = 233*65536 = 15269888 + 8c > Decimal = 140*16777216 = 2348810240 = 2364080128)




add ff into the previous insignificant bytes.

no. 52's address ends in a 1, so you'd multiply by 256, but 52 changes so it's pointless.

He moved the hex dump to show the first byte that a trigger would read. The first three red parts are still the same (e9 6a 39). This shouldn't be confusing, because the addresses are all the same. However this leads me to believe you still don't understand the concept of an address.

You don't multiply by ff ff ff, you add it. You multiply by 1000000.

Follow my math carefully:

e9 8c 41, others change, so can't use them.

e9: 0048cf7e. Address ends in e. multiply by 10000. e90000 hex = 15269888 dec
8c: 0048cf7f. Address ends in f. multiply by 1000000. 8c000000 hex = 2348810240 dec
41: 0048cf80. Address ends in 0. Can't use because there are larger, changing numbers in this dword (dword is 4 bytes, all dwords start on 0, 4, 8, c, and death counts read dwords).

The address needed to be read is 0048cf7e and 0048cf7f. EUDTrig gives us a player number of -259322, but that refers to 0048cf7c, so there are two bytes before the two bytes we are reading.

To read the range, we want to read from at least 00 00 e9 9c and at most ff ff e9 9c, since the first two numbers can be any number and still won't affect the last to bytes.
8ce90000 hex = 2364080128 dec
8ce9ffff hex = 2364145663 dec

Now, I want you to do me a favor and find the triggers for the second set of 4 bytes in this picture. I'll do the first set. I'm going to shorten my work, so refer to my first one if you've got problems.

00 00 57 8b -> 2337734656
ff ff 57 8b -> 2337800191
dword address: 0041e284 -> -372792
3d f4 00 00 -> 15860. Assuming 0041e28a and 0041e28b don't change.
dword address: 0041e288 -> -372791

Trigger 1
Memory(-372792, at least, 2337734656)
Memory(-372792, at most, 2337800191)
Trigger 2
Memory(-372791, exactly, 15860)

Now you try.

Post has been edited 1 time(s), last time on Mar 2 2010, 8:05 pm by rockz.

Okay.. I understand the math portion of what to multiply by etc. etc.

But I still don't understand how you got 8c = 0048cf7f when I can't find it on the list anywhere, how did you know this was the address?

As for the test...

C = Multiply by 1 and so does 0 so you can't do those, could you?

But I think once I understand how you got the 8c = 0048cf7c I would understand this test better, right?


Also, for the
8ce90000 hex = 2364080128 dec
8ce9ffff hex = 2364145663 dec

this wouldn't work as a trigger because you can't put this into SCMDraft 2, right?

0048cf7f is one larger than 0048cf7e. Please take a look at my previous pictures which highlight a byte, then say the ADDRESS of that byte. Hopefully you can learn how to add 1 to a number.
Use trigedit.

Okay, I got the address thing now...

But as for the TrigEdit, it does not work.. for me nor Skipz.

Here is what I mean:


If I put this trigger in manually (Classic Map Triggers) I do not crash and it works 100%




Now if I open TrigEdit, copy and paste EXACTLY what is in that codebox, do the check and it says its done and start Starcraft, open the map I crash automatically. This exact thing happens to Skipz too.


( Skipz, I'm on AIM, see ya viewing this )


As a sidenote, when I manually put this trigger in and then go into TrigEdit it changes to

Do I really have to tell you (again) to update scmdraft? It works fine on mine.
-372793 and 4294594503 are the same number. anything higher than 7fffffff has the last bit flipped, and thus is a negative number. Logic interprets them as unsigned (-1 > 5), but formulas and crap interprets them as signed (which is why we can read any value).

Open the trigger in starforge and see what the numbers actually are. Make sure you've put starforge to interpret numbers rather than names.

Just so you know in you're test thing for the 2nd round of bytes you want him to figure out 0x41E2A4 is 00 F0 EF 6C for me, and not 00 F0 EF 00. (un hacked Starcraft) and seems to be a little tricky. Just thought I would point it out for if when he decided to try it out.

it's all theoretical, since having that 6c there would ruin the trigger, so I changed the numbers a little to a believable mock situation.

Was wondering if that was the case, just wanted to clear it up either way.