I'm looking for a way to figure out where a generic unit (as in, there is more than one in the map per player) is when it dies. I have an idea how, but it's pretty convoluted and annoying. I think I heard someone once say there was a way to do this (they where talking about a Raise Dead spell in an RPG). Does anyone have any ideas, or do I have to work this out myself? (It's fine if I do...)

Here
Here

http://www.staredit.net/files/649/

http://www.staredit.net/files/510/

These both create a unit underneath the units they want to detect death. Then when one of the units is killed, a location scans over each of the units that were placed, usually a burrowed zerg zergling, and checks to see if the unit is there (Maine). If not, it creates two Marines above the original spot, and then removes all of the zergling and then starts again. Its a pretty simple concept but it only works 50% of the time, or something like that.

Why does it have a 50% chance?

I'm not sure exactly, JaFF told me.


And the marines stop moving because I run the Junkyard Dog script only when a marine is duplicated. That's not a bug, more like me being lazy.

I guess the maps rely on the fact that dying units can still be detected for a split second.

But its shorter than the time for a trigger loop. So sometimes the next trigger loop comes in time and detects the unit and sometimes it comes too late.

As JaFF said, it's just the way the game works. Starcraft has a trigger loop that runs nearly every 1/12 second and an animation loop that runs nearly every 1/24 second. Half the time, the animation loop will run by itself, and half the time both will run together. When the unit is killed in the animation loop alone, you can't detect it. When you kill a unit during both loops, the unit's corpse remains there. When the corpse is in the trigger loop, it has already counted as a death, and can still be centered on and given, but it cannot be moved or removed. In my original dying unit test map, I moved all units around you to another area and moved them back. If one wasn't able to move, the map knew that it was a corpse and a data disc was created there. In his map (if I remember correctly), JaFF centers on each unit and places a burrowed unit under each. After that trigger loop, JaFF scans through all of the burrowed units. If the marine is there, nothing happens. If the marine is not there (died), then create 2 marines.

Hopefully that clears things up. If it doesn't (because I'm terrible at explaining things), you can just PM me.

WEll, how about this one, a trigger set that uses an extra player to cycle marines (would have some limitations)

Trigger 1:
Gives marines from player 1 to player 2, and gives zerglings in the same way.

Then, about a million sets of the following:
Move location X over zergling (has to be big enough for the marine to be able to be offset by 1/12 of a second worth of moving)
If there's a marine there, give the zergling and marine back, and move the zergling under the marine.
If there's no marine there, give the zergling to a third player and run whatever trigger you like on it.

I don't see how this would be affected by the 50% chance thing...

With location X large enough to do it that there would be problems with locations/zergling stealing.

It just creates a whole new set of problems

Care to explain it a bit better? I have no clue what you're attempting...
Why do you want a million copies of this trigger? (or do you mean 1 for each possible marine?)
What do you mean by "able to be offset by 1/12 of a second of moving"? Why should the marine move or be offset simply by burrowing zerglings underneath? How does location size affect that?

Also keep in mind that every trigger action is calculated instantly. And only after all triggers have been processed the game continues to display the next frame.
That's why you can create trigger lags.

Post has been edited 1 time(s), last time on Aug 24 2008, 7:53 am by NudeRaider. Reason: clarifications

JaBoK suggested basically the same thing as I did in that map, with the exception of giving marines: he gives marines from P1 to P2 to scan through them, which is superfluous and ruins the whole system, because constantly giving a unit between two palyers will make it uncontrollable.

The location part with the marine offset: he thought that a marine can leave a 0x0 location between trigger loops, but he can't (without stim). And if you were to make the location anything bigger than 0x0, it automatically creates the chance of location stealing.

I still don't get in what way Jabok's would help to improve the situation - not even the idea he had, even when if it would be wrong.

There's units that can escape a 1x1 pixel loc? I thought even a hero ling wasn't fast enough...

If you use a 1x1 location, there is a chance of it being stolen by another unit. Though I don't know about 1x1, a hero ling can outrun a 0x0 location, if memory serves.

Usually the location manages to stick to it for a while, but it eventually manages to escape, I think you could make it perfect if you used both an inverted location and a normal one, and then detect if it leaves the inverted one, then center the inverted and the normal back on the zergling inside the normal one, the reason why it ever manages to get away is because sometimes, it is just barely inside the 1x1 pixel location and then the triggers run, and detect it's there, then it manages to escape before the next cycle runs.

Copying the triggers will do nothing but create lag, if SC worked that way, it'd be possible to have the triggers running get stacked on each other, although you kinda have to use it to make it so it happens faster, but that won't solve your 50% problem.

You have to differentiate between giving location sizes in blocks or pixels.
What I meant was what you call 0x0 location = 1x1 pixels.
1 block (or terrain tile) = 32 pixels. You can't really make a 0x0 blocks location. It will be a 1/32 x 1/32 blocks location.

What are you trying to say here? That wouldn't work.

The reason why it can get left behind is that many units can move half their width or height in a 1/12 of a second.

I think you're mixing up 2 concepts here.
When I speak of escaping the 1x1 pixel loc I mean that every hyper trigger loop the location is recentered on the unit at this 1x1 pixel location (and hope the unit is still touching it).
There's another concept, used for movement detection, which recenters it as soon as the unit has escaped the pixel loc. In that case you can use inverted locations to detect even the slightest movements to detect the movement earlier.
So when I just recenter it every trigger loop it's the best I can do to prevent the escaping. Except increasing location size, but as JaFF pointed out this may lead to glitches.

No. I'm speaking about a 0x0 pixel location. To create one, go to the location's properties in SCMDraft2 and make the corresponding X and Y borders equal (right border X coord = left border X coord; top border Y coord = bottom border Y coord).

Alright, then we were talking about the same. Altough the borders match (delta x = 0, delta y = 0) the location has the size of 1 pixels. Namely the x and y coordinates you set.

Ah wait, you're right, I forgot that it's constantly centered anyway, for some reason had it in my head that it only recentered when you left the location.


That's not 0x0, 0x0 is 0, 1x1 is 1, the location is one pixel, not 0 pixels.