Using Physics to Caculate when to do something.

[Zanderist]

I've made a trigger using the formula v= d/t (and it's other variants)

• Replace On arrival to point
  • Events
    • Unit - A unit Is issued an order targeting a point
  • Conditions
  • Actions
    • Set Distance = ((Distance between (Position of (Ordered unit)) and (Target point of issued order)) / (Default movement speed of (Ordered unit)))
    • Game - Display to (All players) the text: (ETA: + (String(Distance)))
    • Wait Distance seconds
    • Unit - Replace (Ordered unit) with a Footman using The old unit's relative life and mana

But it has a problem, if you keep clicking on on the map while the unit(s) are selected you can end up creating an extra unit.

How can I prevent that extra unit for being created.

 

[PurgeandFire]

Instead of (Ordered Unit), try (Triggering Unit). I believe it is local to the function. (I am not positive though)

 

[Zanderist]

nope it's still happening.

I may have to make use of custom scripts.

 

[Dave312]

It is occurring because you are running multiple instances of the trigger for the same unit. Hence when it tries to replace the triggering unit, sometimes the unit has already been replaced, hence the triggering unit no longer exists and it will create a new unit. To solve this problem, you will need to add in some sort of check to see if the order that started that trigger is still that units current order. Using custom script to define local variables or custom value of a unit is probably your best way to go.

BTW. Using physics in this case can be very unreliable. Units will only use a straight path to travel from one point to another when there is nothing it has to move around (such as other units, doodads etc.)

EDIT: On second thought you could also use a check to see if the ordered unit is equal to no unit before trying to replace it.

 

[Zanderist]

The use of this formula (t = d/v) could allow players trying to develop a cinematic much easier.

Just take a unit that has the velocity you want the camera to move with, use the terrain brush to make point you want that camera to move to. Then move that unit to all the different points you want that camera to go to, and write down the time. Remove all the terrain points.

Now you know how long to apply to camera object for.

 

[Narks]

the wait function in GUI is not 100% accurate (very inaccurate for short durations, and also does not work properly with player lag screens).

 

[Zanderist]

You can make it display only 3 significant figures if you like.

And what is the player lag screen?

 

[Narks]

the wait function in GUI is very inaccurate (try waiting 0 seconds, minimum wait is 0.27 or something, and it has a lot of variance)

the player lag screen is the screen that appears when one player is lagging (with the drop player button) - wait function will still tick down during that, when it really should not (except under special circumstances)

 

[Zanderist]

This was really more a science experiment than anything else, since I wanted to see if this would actually work under vacuum conditions.

The wait function seconds is set by the formula. And it will only use the first 3 figures of that variable (because you can only enter in 3 significant figures).

You can also introduce a if/then/else trigger if the wait time set by the variable is less than the wait minimum.

When will a unit get to the point it's ordered to move to in 0 seconds? The value will always be greater than zero, and teleportation doesn't count.

Besides I only want to see if it would work in a totally flat barren terrain, It has with the only side effect of extra units being created, it also proves that the formula does work which was my original objective (in a vacuum world).

However, when a unit is order to move through a forest an invisible line is created. From the unit and to the point, if the trigger could be modified to change when the slope of that line changes it could also work for when the unit has to move around objects.

The only thing I can say to player lag, is come up with a trigger that will add 'x' amount of seconds to the wait time. I don't think that can by done in the GUI but maybe in JASS.

Though I do not know what will happen when the unit moves over a hill. My guess it should still work because the only thing changing when it comes to a hill is the Z-axis, though I am not sure if the velocity is changing.

Edit:

I've now tested using 3 different situations, Hill, flat, and forest.

I found that it all worked untill the forest.

I think if I could make use the distance the unit has to travel, instead of the distance to the two points. It will work perfectly.

 

[Dave312]

If you use 'wait - game time seconds' then that should take into account any lag.