Staredit Network

Staredit Network -> UMS Assistance -> [solved] EUD debugging
Report, edit, etc...Posted by scwizard on 2006-10-30 at 21:37:38
My trigger is for player 1 and reads thus:
(if you can't understand starforge triggers you can't anwser this question)
Conditions:
Deaths(P8, AtLeast, 67109888, 13252);

Actions:
DisplayText("Massing on", 4);
SetDeaths(CurrentPlayer, SetTo, 0, 179);
PreserveTrigger();
Comment("The center");

ARTmoney says the offset for the rally point for the building in question is 00624808
It's a 4 byte integer and ARTmoney says it equals xpos + (ypos*65536)


The condition used to be: Deaths(P8, Exactly, 67109888, 13252);
Which checked if the player had set the rally point for their gateway to the center. And the action used to not include the text displaying.

Before I changed the condition to AtLeast the trigger refused to respond ever.

This is where things get wierd:
When I changed it to at least it would always respond UNLESS I hadn't set a rally point yet or I had set the rally point to the very top left corner.
Now things get wierder:
My brother suggested that by player 8 ubercalc mean player 7, so I changed the player to player 7 and I got THE EXACT SAME RESULT.

wtf is going on. Why does the memory location = 0 when there is no rally point and equal a number far greater than it would be (I clicked in places that artmoney said were worth a mere 8) when a rally point is set? Also why does it behave the same way for player 7 and 8.

Why aren't the results that ubercalc gave me correct? How can I find the correct player number and unit ID?

And finally does anyone here know anything about EUDs besides me?

ADDITION:
I'll email the map to people upon request.
Report, edit, etc...Posted by DT_Battlekruser on 2006-10-31 at 01:11:15
It's simple math.

I don't know much about the memory structure, but it's possible that the (x,y) position of a unit with a given LocalID repeats itself once. MemCalc verifies that you have the right unit/player, so I'll go from there.

Deaths(P8, Exactly, 67109888, 13252);

will check to see that the rally point is EXACTLY (1024,1024). This condition must be met precisely; the position is in pixels so any difference whatsoever in either x or y will change this and make it off.

Unless I'm much mistaken, these are measured relative to the entire map, so (1024,1024) is at <32,32>, the center of a 64x64 map. But remember, if the rally point is misplaced by EVEN ONE PIXEL in EITHER the X OR Y directions, the condition will hold false.

If you change the condition to

Deaths(P8, AtLeast, 67109888, 13252);

we are now checking for a dword of 00 04 00 04 or greater.

So, for ALL X VALUES such that the y-coordinate of the rally point is 400 (1024 is dec) or greater and if the y-value is 400, the x value is 400 (1024) or greater.

Therefore, the entire map south of the 1024 pixel line should make the condition true, while anything above that line will make it false.

This is at least what should happen; I'm not sure exactly how to interpret your described results.
Report, edit, etc...Posted by scwizard on 2006-10-31 at 18:34:56
QUOTE
So, for ALL X VALUES such that the y-coordinate of the rally point is 400 (1024 is dec) or greater and if the y-value is 400, the x value is 400 (1024) or greater.


That would be great, but what's happening is that for ALL X VAULES for the rally point (except for hasn't been set/0) it triggers.

ADDITION:
In short I made a stupid mistake.

I'm very sorry.

Ignore all the other stuff I said, I just made a stupid simple mistake.
Next Page (1)