[Trigger] A MUI concern

[JaysProjex]

A MUI concern - [Solved]

I seen this in Magtheridon96 MUI guide, my question is once you set the write & read index to 0 isn't that going to cancel out the rest of the ones above in the write index to 0? Once you 0 out a integer isn't it for the whole integer itself? or just that 1 number? I'm a bit confused by this

• Pro Trigger
  • Events
    • Unit - A unit starts the effects of an ability
  • Conditions
    • (Ability being cast) Equal to MyDerpyAbility
  • Actions
    • -------- WriteIndex and ReadIndex are integer variables --------
    • Set WriteIndex = (WriteIndex + 1)
    • Set caster[WriteIndex] = (Triggering unit)
    • Wait 5.00 seconds
    • Set ReadIndex = (ReadIndex + 1)
    • Unit - Remove caster[ReadIndex] from the game
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • ReadIndex Equal to WriteIndex
      • Then - Actions
        • Set ReadIndex = 0
        • Set WriteIndex = 0
      • Else - Actions

 

[Ceday]

That method seems very good.

Try simulate some units using this spell inside your head.

"ReadIndex equal to WriteIndex" --> This line actually means "There is no units currently casting this spell" or "all spells are over"

Because WriteIndex is the number that saves how many times is this spell used whereas ReadIndex is the number that saves how many times is this spell finished.

 

[JaysProjex]

That method seems very good.

Try simulate some units using this spell inside your head.

"ReadIndex equal to WriteIndex" --> This line actually means "There is no units currently casting this spell" or "all spells are over"

Because WriteIndex is the number that saves how many times is this spell used whereas ReadIndex is the number that saves how many times is this spell finished.

Ohhhh ok thanks for clarifying so only when it reaches equal value it will clear it

 

[Wrda]

This method might not be the best one on really rare cases, I repeat, really rare cases.
For example: C[1] = caster 1, C[2] = caster 2 etc...; I = WritenIndex, I2 = ReadIndex
C1 casts the spell. I = 1; I2 = 0
After 3 seconds C2 casts the spell. (2 secs before for the C1 has the spell finished) I = 2; I2 = 0
After 3 seconds C3 casts the spell. (2 secs before for the C2 has the spell finished, 1 after C1) I = 3; I2 = 1
After 3 seconds C4 casts the spell. (2 secs before for the C3 has the spell finshed, 1 after C2) I = 4; I2 = 2
And so on.
As you can see I and I2 won't get reseted, and maybe hit the max index, 8191. This sounds really absurd, yes, I'm not saying that it's a bad method, but it isn't definetly the best one. Anyway, this would only happen in a map such as Hero Line Wars or something that contains many units.

 

[JaysProjex]

Anyway, this would only happen in a map such as Hero Line Wars or something that contains many units.

Understandable & thanks for your input, although I don't think it will be used that frequently in my map it's more of an occasional use so it should be fine.

 

[deathismyfriend]

The problem with this type of indexing is that it can be broken rather easily.

If a person disconnects / has connection problems waits continue. The spell can then be broken because of that.
Waits are also inaccurate. 5 seconds will be about anywhere from 4.75 to 5.25 seconds.
This can hit the array limit if it is cast frequently.

You can also use a loop after the wait just like in normal indexing to fix this. But you still have the inaccuracy of the waits.

 

[Ceday]

Sorry but these things are just on theory.I have seen many maps which use wait, and some of them were even popular maps.I am also sure I faced many connection problems in my games but no disaster happened, no desyn problem happened.

Sure if I am mistaken you can show me a practical example.

 

[deathismyfriend]

Problem is causing a temp player disconnect at the right time to test this is just not possible.

Also that is a well known thing about waits.

 

[Drone]

The trigger in its current form can fail if events actions processed do not catch up with generated events. The simple solution is to make sure the caster array wraps around. With wrapping it will be very unlikely to lose events due to more than 8192 event actions ran before an event action has a chance to finish. That's just a theoretical case and not actual practice.

To conclude...

You have to keep into account that there's a minimum wait time and waits are not that reliable. Furthermore you can't use certain trigger context functions after a wait other than GetTriggerUnit(). For the rest this will work for simple GUI MUI.

I've attached a map that presents an extreme case.

• Pro Trigger
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
    • (Ability being cast) Equal to Thunder Clap
  • Actions
    • -------- WriteIndex and ReadIndex are integer variables --------
    • Set WriteIndex = ((WriteIndex + 1) mod 8192)
    • Set caster[WriteIndex] = (Triggering unit)
    • Wait 10.00 game-time seconds
    • Set ReadIndex = ((ReadIndex + 1) mod 8192)
    • Unit - Remove caster[ReadIndex] from the game
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • ReadIndex Equal to WriteIndex
      • Then - Actions
        • Set ReadIndex = 0
        • Set WriteIndex = 0
      • Else - Actions

 

[deathismyfriend]

Instead of using mod you should use an ITE to check. This does solve the array limit but it still has the other problems.

 

[Drone]

Instead of using mod you should use an ITE to check. This does solve the array limit but it still has the other problems.

I did say used for simple things . Because waits are unreliable it's not wise to use it for time sensitive stuff.

But I don't understand your other problems with it. Hit the op limit? How? Explain to me how working with one element of a head/tail buffer per event triggered hits the op limit? Why would the user use a loop for processing a single element? I don't follow your reasoning.

Maybe you were talking about something like this?

If the events trigger at an absurd rate then performance will suffer but the op limit counts per thread. That is 300000 byte code operations for the VM instance that is created per triggered event. Do you really think this action code can possibly reach the 300000 byte code executed limit? Silly you

 

[deathismyfriend]

If I said op-limit I meant array limit.

Waits are only a small cost. So it is the sum of the other actions that will cause op-limit to be hit. (In the case above there are not enough.)

If you don't understand why I do not like waits then it is mainly because I don't like inaccuracies. As for the rest look at my tutorial things you should know when using triggers / gui. The chapter on waits shows you more things on why waits should not be used.

Also it really is easy to do indexed arrays which is almost the same as the above.

 

[Wrda]

If I said op-limit I meant array limit.

Waits are only a small cost. So it is the sum of the other actions that will cause op-limit to be hit. (In the case above there are not enough.)

If you don't understand why I do not like waits then it is mainly because I don't like inaccuracies. As for the rest look at my tutorial things you should know when using triggers / gui. The chapter on waits shows you more things on why waits should not be used.

Also it really is easy to do indexed arrays which is almost the same as the above.

You can't say that waits shouldn't be used. In fact, they are useful for cinematics, simple timed spells (only 1 hero for that spell). However, they shouldn't be used for spells have have more than 1 hero in the game.

 

[deathismyfriend]

You can't say that waits shouldn't be used. In fact, they are useful for cinematics, simple timed spells (only 1 hero for that spell). However, they shouldn't be used for spells have have more than 1 hero in the game.

With the problems with them I don't think they should be used. My mind will not change on this as they offer 2 many problems when using them.