HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

Unit - Replace action freezes game

09-20-2002, 05:53 PM#1
Guest
I made a trigger to replace a peasant with a footman.
Event - unit enters region
action - replace triggering unit with footman using footman's default life and mana
action - wait 2 seconds
action - unit - issure order to (last created unit) move to random point in region

why does this freeze the game?

talanathar
09-20-2002, 06:17 PM#2
Guest
Use Last Replaced Unit. When you replace a unit it is not considered Last Created Unit.
09-20-2002, 07:00 PM#3
Guest
thanks a lot
09-20-2002, 07:34 PM#4
Guest
Quote:
Originally posted by Talanthar
why does this freeze the game?


DrunkOM, you ninny, he didn't ask how to FIX his problem. He only asked why it froze his game.

My guess is that at the time the Last Created Unit is used there are none, and the game tries to give an order to a null unit. Crash!

Care.
09-20-2002, 07:36 PM#5
Guest
well i did want to know how to fix it,m but that didn't fix the problem
same thing happens

replace unit then order last replaced unit and it freezes
09-20-2002, 07:50 PM#6
h0pesfall
no heaven that cant be it... if the event response is null, the game just ignores it. It's probably something else... maybe something he edited on the unit, or he tries to create a unit when the max number of units on the map is already reached, or something like that...
09-20-2002, 07:55 PM#7
Guest
my unit count is just under 80 I replace a peasant with a footman which is where it freezes, ie I don't even see the footman
09-20-2002, 10:01 PM#8
Guest
I was just being silly when I responded above. Heh.

But the wait is bothering me. It means that the next time you use last whatever, you're not guaranteed of it being what you think it is. In other words, when we hit that wait, execution can be transferred to another trigger which can alter the contents of the global variables. When execution is passed back to your program, last replaced may be something entirely different than the unit you just replaced 2 seconds ago.

I would use custom text and make a local variable.

But Zzzz, I was thinking like this:

Game starts.

Unit enters region, firing the trigger
Unit is replaced.
Wait.
Last created unit ordered to move.

Since there isn't a last created at that point (i.e., assumedly it's NULL) then a null unit is ordered to move. If the move unit order is null proof, then yeah, fine...it'll be ignored. But some seemingly simple other stuff has crashed W3 on me several times while testing custom text.

Meanwhile, Talanthar says he is now using last replaced and it's still crashing. Hmm...stick a wait 0.5 right before the replace. And of course, use entering unit instead of triggering unit to make sure you get the right one.

In random point in region...is the region good? Defined, whatever?

Try disabling all other triggers except this one and see if it still freezes.

Let us know what happens!

Care.
09-20-2002, 10:11 PM#9
Guest
using entering unit instead of triggering unit works
thanks for all your help guys

talanthar
09-21-2002, 01:16 AM#10
Guest
Quote:
But the wait is bothering me. It means that the next time you use last whatever, you're not guaranteed of it being what you think it is. In other words, when we hit that wait, execution can be transferred to another trigger which can alter the contents of the global variables. When execution is passed back to your program, last replaced may be something entirely different than the unit you just replaced 2 seconds ago.

Actually, this is incorrect. Only variables that you create, and a few select ones (like the For Loop Integers) are Global. Event responses and the like, such as Triggering Unit, Last Created Unit, Dying unit etc are kept local within that "Trigger thread".

This means that if you have a wait, and during that wait it runs a trigger with the same event response (IE Triggering unit), then they will each have their own Triggering unit. If you run another trigger from your initial trigger, then that Triggering Unit will actually carry over into the trigger you run (making it a "trigger thread").

If you experiment, then you'll see that this is actually how it work. It's actually quite cool.
09-21-2002, 05:21 AM#11
Guest
Quote:
Originally posted by DrunkOM
Actually, this is incorrect. Only variables that you create, and a few select ones (like the For Loop Integers) are Global. Event responses and the like, such as Triggering Unit, Last Created Unit, Dying unit etc are kept local within that "Trigger thread".
Ahem. *cough* :)

I think you are incorrect on this one, DOM. Let's thrash this out until we've got it straight...it's sorta' important. From my understanding, all of the "last" vars are global. Blizzard.J defines them so. And from my understanding of the use of the word global, they can only contain one value at a time throughout the game. A quick test bears this out:

-------

event: player1 types a chat message containing "footman"
actions:

create footman
display text name of last created unit
wait 10.0
display text name of last created unit

-------

event: player1 types a chat message containing "knight"
actions:

create knight
display text name of last created unit
wait 10.0
display text name of last created unit

-------

Output of the above test if player types first "footman", and then immediately afterwards types "knight":

footman
knight
knight
knight

Ok. That settles that, right? All of the "last x'd" vars are indeed capable of holding only one value at a time throughout the game. Apparently.

Quote:
This means that if you have a wait, and during that wait it runs a trigger with the same event response (IE Triggering unit), then they will each have their own Triggering unit. If you run another trigger from your initial trigger, then that Triggering Unit will actually carry over into the trigger you run (making it a "trigger thread").

Here you're comparing apples and oranges. "Triggering unit" is not a global. I believe that every time you use it in the GUI you're actually using a GetTriggerUnit() function, which simply returns the triggering unit of the current thread, or trigger. (EDIT: Likewise Dying Unit would be GetDyingUnit(), etc., etc.) When a trigger calls another trigger, it makes sense that it passes it's triggering unit to the called trigger, since the called trigger would have no associated event to create it's own triggering unit variable. Again, apparently.

Quote:
If you experiment, then you'll see that this is actually how it work. It's actually quite cool.
Ok, I've experimented. Results are contrary. Please refute.

:)

Care.
09-21-2002, 06:32 AM#12
Guest
Ugh, you're right. Event responses are, "last" stuff isn't.

Time to put the crack pipe down. Of course it isn't going to work that way. Obviously a trigger can have more than 1 unit created, and they aren't all going to be last created unit.