Integer A does not bug

[Squiggy]

So, dear community

I stumbled upon a spellthread which also stated that people should avoid using Integer A for loops in gui

The reason for this was that there'd be a low probability that it 'bugs'
The fact that they 'bug' (overlap in this case and run one time too much) seemed strange, so I put this trigger

• loop
  • Events
    • Time - Every 0.05 seconds of game time
  • Conditions
  • Actions
    • For each (Integer A) from 1 to 10, do (Actions)
      • Loop - Actions
        • Set int = (int + 1)
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • int not equal to (!=) 10
      • Then - Actions
        • Game - Display to (All players) the text: |cffff0000OMG U R R...
        • Set point = (Center of (Playable map area))
        • Unit - Create 1 Soldat for Player 1 (Red) at point facing default building degrees
        • Custom script: call RemoveLocation(udg_point)
      • Else - Actions
    • Set int = 0

(the original trigger is this*8)
and copied it a couple of times.
Running warcraft after like 20 minutes showed me this(I removed the call BJDebugMsg):

Click me

which is quite a proof that the int never turned 11 and therefore no units were created, means Integer A does not bug or overlap or run too often.

If you want to test this for yourself, I uploaded a version of the testmap as attachment - copy the triggers if you want.

 

[GhostWolf]

Why would it bug?

 

[Squiggy]

I was told that it MIGHT bug if two loops interfere with each other but the actual ''reason'' for this is unknown - I'd surely apprechiate it if the inveltor of this theory told me

 

[PurplePoot]

The actual reason is because (Integer A) is a global so two loops running it at once interfere with one another as they both access it and change it at the same time (more accurately, one changes it while the other is waiting for the first to finish).

 

[tml616]

So (Integer A) is just like any global integer we would make for loops but with a built in (set A = A+1) at the end of the loop?

 

[PurplePoot]

No. It's built in to the loop construct.

--

(Integer A) is the global variable bj_forLoopAIndex.

 

[GhostWolf]

That's not a bug, that's bad coding. It seems like Squiggy was told about real bugs.

 

[Mooglefrooglian]

Forgive me, but don't triggers NEVER run at the same time, therefore nulling the possibility of globals overlapping?

 

[GhostWolf]

No .

 

[PurplePoot]

Yes, but that doesn't mean one can't interrupt the other.

 

[Kwah]

As far as I can see, these never collide.

 

[Mooglefrooglian]

Yes, but that doesn't mean one can't interrupt the other.

Could you clarify on that? If no two triggers will ever be executing at the same time - they wait for one another, unless theres a wait, correct? Shouldn't that mean that if there is no wait they would never be using the same global at the same time? Therefore never interrupting?

 

[Sophismata]

Say you have a specific unit that has a UnitTakesDamage event. When the unit takes damage, an Integer A loop runs and causes that unit to damage a random nearby enemy unit A times for half the damage originally taken.

Now, you have a spell with an Integer A loop that somehow deals damage to this specific unit during the loop. The spell thread is interrupted while the damage trigger runs, which also uses Integer A. You now have a conflict.

This example may be a bit more complicated than it needs to be, but I tried to present a situation that someone might actually code.

 

[Anachron]

Everything is in a order loop, while a loop must be ended before another one starts.
Even if the other thing is at the same time, the computer have to calculate after each other, so there is no collision at all.

 

[GhostWolf]

Oh yes, there is. Ever heard of multithreaded tasks (it is said that ExecuteFunc and all his friends start a thread, don't ask me if it's right)?

And another thing is (which I assume PurplePoot meant to say):

• For (Integer A) do bla bla
  • ...
  • For (Integer A) do bla bla 2
    • ...

 

[Vulcano]

people just say it bugs because they have 2 loops with Integer A and then put a wait in one of the loops. It would also bug with any other global var.

EDIT: I just thought of a trigger with a loop that took 5 seconds to complete, but while it was doing the loop no other triggers were excuted (normally a trigger should loc camera but i could just move screen). In short, i don't think loops without wait can interfere with each other.

 

[Sophismata]

Odd. I posted an answer, but it's not showing up.

Say you have a specific unit that has a UnitTakesDamage event. When the unit takes damage, an Integer A loop runs and causes that unit to damage a random nearby enemy unit A times for half the damage originally taken.

Now, you have a spell with an Integer A loop that somehow deals damage to this specific unit during the loop. The spell thread is interrupted while the damage trigger runs, which also uses Integer A. You now have a conflict.

This example may be a bit more complicated than it needs to be, but I tried to present a situation that someone might actually code.

 

[Ciebron]

just do a "jass loop" with custom scripts and a local integer

 

[Anachron]

I can't see why this topic is useful at all.
I mean its one of the basics of wc3, what do you think?
It will NEVER fail, because else wc3 would have even more bugs.
The loop is a well programed thing.

 

[Squiggy]

I can't see why this topic is useful at all.
I mean its one of the basics of wc3, what do you think?
It will NEVER fail, because else wc3 would have even more bugs.
The loop is a well programed thing.

It's merely a clarification to avoid the misleading of new users because some were told that they had to avoid it which is wrong

 

[Anachron]

It's merely a clarification to avoid the misleading of new users because some were told that they had to avoid it which is wrong

Avoid the most working function in wc3? Lol.

 

[Squiggy]

http://www.hiveworkshop.com/forums/1222074-post7.html
http://www.hiveworkshop.com/forums/1222280-post15.html
http://www.hiveworkshop.com/forums/1222294-post18.html

 

[Pharaoh_]

Uh, indeed @Anachron & @Squiggy, everyone claims that Integer A is problematic, GetLocalPlayer() can crash the WC3 or give some bugs, Unit - Remove unit is an also problematic action... bla bla! How come i never had crashes, when using those functions, only God knows

 

[Element of Water]

If your loop has waits in it, and another trigger executes while that trigger with a loop executes while that trigger is "sleeping", integer A would bugger up. I think this could even cause infinite loops.

 

[GhostWolf]

Uh, indeed @Anachron & @Squiggy, everyone claims that Integer A is problematic, GetLocalPlayer() can crash the WC3 or give some bugs, Unit - Remove unit is an also problematic action... bla bla! How come i never had crashes, when using those functions, only God knows

GetLocalPlayer() is a BIT more risky then this...

 

[Element of Water]

Yeah. It desyncs. But only when used with functions which cause net traffic. IE most functions.

 

[Anachron]

http://www.hiveworkshop.com/forums/1222074-post7.html
http://www.hiveworkshop.com/forums/1222280-post15.html
http://www.hiveworkshop.com/forums/1222294-post18.html

Its connected with waits and GetLocalPlayer() and things like that, but the bug is not the LOOP, its the wait...

Anyway, I always use my own count variable.

 

[Element of Water]

In JASS, it's easy - you use a local. In GUI, if you want to have waits in your loop, use your own variables, but otherwise, there is absolutely NO PROBLEM with Integer A / Integer B.

 

[Anachron]

In JASS, it's easy - you use a local. In GUI, if you want to have waits in your loop, use your own variables, but otherwise, there is absolutely NO PROBLEM with Integer A / Integer B.

Agreed, quoted for truth and hopefully solved this.

 

[Squiggy]

Whoever uses jass, uses a local - but this is related to gui

 

[PurplePoot]

Could you clarify on that? If no two triggers will ever be executing at the same time - they wait for one another, unless theres a wait, correct? Shouldn't that mean that if there is no wait they would never be using the same global at the same time? Therefore never interrupting?

If you kill a unit, any triggers with A Unit Dies will interrupt the current thread rather than wait for it. The same goes for any other events or function calls.

 

[busterkomo]

Putting any waits inside the loop will also cause it to completely malfunction.

 

[Element of Water]

Not completely malfunction - just go wrong if another Integer A loop runs at the same time.

 

[busterkomo]

Obviously.

 

[Deuterium]

Well, ok so simply use a local/struct variable/indexed global... I mean, in Jass that takes even less time to do. In GUI, meh an additional 5 seconds...

 

[Mooglefrooglian]

If you kill a unit, any triggers with A Unit Dies will interrupt the current thread rather than wait for it. The same goes for any other events or function calls.

Ah, so that's how the order goes. Thanks.

 

[PurplePoot]

Uh, indeed @Anachron & @Squiggy, everyone claims that Integer A is problematic, GetLocalPlayer() can crash the WC3 or give some bugs, Unit - Remove unit is an also problematic action... bla bla! How come i never had crashes, when using those functions, only God knows

It's called being a responsible coder.

 

[Eleandor]

Ok explained in simple words:

What happens is this:

1. While (Integer A) < 10 Do:
2. (Your actions)
3. Set Integer A = Integer A + 1
4. Repeat line 1

A trigger can only be interrupted by a different trigger when a "Wait X seconds" action is used. Thus, if both triggers use Integer A, and a Wait action occurs inside the loop, then trigger A is interrupted, trigger B modifies Integer A, and then trigger A continues looping but this time with a modified Integer A. This is where the bugs happen. It is a very logical bug and oh-so-easily avoided with jass.

Another bug occurs with nested loops, since both loops are modifying Integer A. For example:

• While (Integer A) < 10 Do:
  • While (Integer A) < 5 Do:
    • Set Integer A = Integer A + 1
    • Repeat line 2
  • Set Integer A = Integer A + 1
  • Repeat line 1

The bug is obvious: After 5 loops, the first (outer) loop will have modified Integer A to be larger than 5 but smaller than 10. Yet, the second loop requires it to be smaller than 5, and thus bugs occur.

 

[Deuterium]

Well PP, even if a unit dies, I don't think it interrupts the actions of one trigger, but maybe interrupt the queue of triggers to run... or am I wrong? (this is just an educated guess).

 

[PurplePoot]

You're wrong. Feel free to test it--this has been the subject of several annoying bugs in my code in the past, which is why I finally realized how this thing worked.

 

[Mooglefrooglian]

So to summarize, it is cocded to run only one trigger at a time in a huge line. Any new trigger called will interrupt the first one, putting it to sleep until the new trigger is done or has its own wait. Waits are shoved to the back of the line depending on how long they have left.

Is that how it works, or what?

 

[Deuterium]

So as a conclusion:

DON'T USE Integer A/B

 

[Squiggy]

I was proving the exact opposite in my first post

Unless you don't use nested loops and/or waits, you're fine

 

[baassee]

I was proving the exact opposite in my first post

Unless you don't use nested loops and/or waits, you're fine

I have to put in my word here:

No one said that Integer A/B bugs ALL THE TIME when there loops are running at the same time.

The chance is pretty low of my experience since I used it alot before.

Squggy your example is not enough cause the same trigger copied is wrong, try many different triggers with different periodic events and other events that happens at the same time and you will see my point.

Even thought I get your point with the loops. It takes less then nano seconds to execute these loops and the chance that they overlap should be LOW enough to be use able but if you have like 50 spells with periodics and only using int A and mostly casted all around the game it will prob bug.

~baassee

 

[PurplePoot]

It has nothing to do with chance and everything to do with competent coding.

 

[Deuterium]

I was proving the exact opposite in my first post

Unless you don't use nested loops and/or waits, you're fine

But PP proved you wrong, so yeah nesting/wait doesn't matter anymore...

 

[PurplePoot]

Nested loops and waits are not the only ways to make it explode; see what I said about triggers that interrupt you.

 

[Anachron]

GUI loops suck, but only while being combinied with waits, interrupts or other loops.