Every 0,5 seconds ... is this a bad thing?

[Nordmar]

If it runs over hours if the trigger itself is leakfree? Just curious..if I wanna check if there is a specifig item in a specifig region.

Thanks

 

[SAUS]

It can be bad if it uses expensive actions (big loops, big unit groups and stuff).

There is most likely a better way to check this. How does the item get into this region? Does a unit drop it? You could perform the check only when a unit drops an item. You don't want to spam these kinds of repeated checks because you might slow your game down.

 

[NeosDany]

You can even use every 0.03 intervals but remember to clean any stored variable.

 

[Nordmar]

Well..the problem is that the region is very small where the item should be dropped.
I already asked about this here: https://www.hiveworkshop.com/forums...ck-if-item-got-dropped-certain-region-273830/

But you answered my initial question so thank you If you have ideas for my other problem you can post it there.

You can even use every 0.03 intervals but remember to clean any stored variable.

Thanks. I didn't expect this ^^

 

[ZiBitheWand3r3r]

you can move your trigger actions into condition section to not start new thread every time
zibi

 

[SAUS]

you can move your trigger actions into condition section to not start new thread every time
zibi

This is a JASS trick. I don't know if he uses JASS or not, but all triggers I have seen from him so far are GUI.

 

[EdgeOfChaos]

For just that simple check, no it shouldn't matter. 0.5 sec might actually be too slow for your purposes, as you could drop an item in and pick it up during that time.

 

[SAUS]

So I looked mine up and it is, indeed, also a periodic check lmao.

Anyway, I think I will update mine to just swap it out from your inventory since that can trigger when a unit enters the region and there isn't really any need for it to be dropped.

 

[kingkwong]

This might work for you. You may have to index if you want to make it MUI.
If you are using powerups in your ma, you probably want a trigger that removes the item to stop them leaking. Eg. Tomes, when you use them, you can notice a tiny model left after you pick it up.

• Untitled Trigger 007
  • Events
    • Unit - A unit Acquires an item
  • Conditions
    • ((Item being manipulated) is A powerup) Equal to True
  • Actions
    • Item - Remove (Item being manipulated)
    • Game - Display to (All players) for 0.50 seconds the text: Powerup used

• Untitled Trigger 005
  • Events
    • Unit - A unit Loses an item
  • Conditions
    • (Charges remaining in (Item being manipulated)) Greater than 0
  • Actions
    • Wait 0.01 seconds
    • Item - Pick every item in (Playable map area) and do (Actions)
      • Loop - Actions
        • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
          • If - Conditions
            • (Item being manipulated) Equal to (Picked item)
          • Then - Actions
            • Game - Display to (All players) for 0.50 seconds the text: Dropped
            • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
              • If - Conditions
                • ((Item being manipulated) is in Region 000 <gen>) Equal to True
              • Then - Actions
                • Game - Display to (All players) for 0.50 seconds the text: In Region
              • Else - Actions
          • Else - Actions

 

[Dr Super Good]

It is better to run the tests when items are dropped or moved rather than periodically.

 

[Bribe]

0.1 or 0.2 second timers are fine for this. On average, there will be a 0.05 or 0.1 second delay between when the item is dropped and when it is detected as being in the region. Again, 0.03 is only for animating objects and unneeded for periodic checks.

 

[aple]

It can be bad if it uses expensive actions (big loops, big unit groups and stuff).

There is most likely a better way to check this. How does the item get into this region? Does a unit drop it? You could perform the check only when a unit drops an item. You don't want to spam these kinds of repeated checks because you might slow your game down.

0.5 seconds will not cause any problems, even with the largest of triggers.

0.03 on the other hand, which is generally what you want to use if you need speed, can be if you have virtually any leaks what-so-ever.

 

[Dr Super Good]

0.5 seconds will not cause any problems, even with the largest of triggers.

That is a very bold statement to make... I am sure there are at least a dozen people on this site who could make a 0.5 second periodic trigger than does cause performance problems.

 

[aple]

That is a vary bold statement to make... I am sure there are at least a dozen people on this site who could make a 0.5 second periodic trigger than does cause performance problems.

I think you'd almost have to deliberately be making a faulty trigger for 2 times a second to be the actual cause of any lag. Rather, it would more likely be what's actually in the triggers that will cause the problem, which would happen at any interval be it 0.5 seconds, 1 second, or 60 seconds. 33 times a second (0.03), however, can be the soul cause of a lag problem if you don't take precaution that it's going that fast.

To be honest I've never actually had a problem with a trigger of almost any size at any speed, so long as it's leak free or doesn't heavily rely on taxing functions like Pick Unit Groups.

 

[Dr Super Good]

I think you'd almost have to deliberately be making a faulty trigger for 2 times a second to be the actual cause of any lag.

Or do something such as picking every unit near every unit and doing some calculations from that.

It is not how often the trigger is fired, but rather how complex it is. You are also still limited to not dropping a frame. Even a 0.5 second trigger can cause frame drops which degrades user experience. You will find such a limit is similar to lower period triggers and is basically a scheduling style problem.