Not running hypers, i do have lots of bring conditions. Is there anything else that can cause major trigger lag? It tends to happen with more players so my guess is its trigger lag.

If you are frequently playing with a similar set of people, I would also be concerned about conflicts as the source of lag.



As for trigger lag, I like to roughly rank propensity to cause lag like this, perhaps it could help you identify something causing it:

- Creating/Destroying unit(s)*
- Bring/Location based conditions
- Order/AI actions*
- Give actions*
- Move actions

---

- Most other conditions/actions
- All counter-based conditions/actions (deaths, score, command, etc)

* varies greatly with the number of units in a given trigger

Post has been edited 2 time(s), last time on Nov 18 2012, 8:02 am by jjf28.

It depends:

How many triggers do you have? Even if you have 10,000 triggers they won't cause lag unless you're doing some pretty hefty unit stuff.

jjf28's list is somewhat wrong. Bring/location conditions and counter based conditions/actions are extremely unlikely to be the cause of your lag issues, unless your map has (as a rough estimate) more than 2-3000 triggers. If you only have 500 triggers and every single trigger has 16 conditions and 64 actions (max possible), then maybe these could be the cause of your lag, but its very unlikely. Definitely examine your triggers for lots of spamming AI's or creating/killing units.

Actions involving units are most likely to be the source of any trigger based lag. jjf28's list covers the basics, Creating/Killing (removing a unit is much easier), AI/Order, Give, Move, are essentially the biggest offenders.

My guess is that you actually aren't experiencing trigger lag, since you aren't using hyper triggers. The lag would be intermittent, since your triggers will only be running once every 2 seconds or so, instead of 12 times per second.

To clarify, I was listing list all of the most commonly used triggers in a ranking of how likely they are to cause lag, not listing triggers that cause lag

Shoulda put a line under move actions to make that clear (edited).

Thanks for the reply. I definitely have a lot of brings and death counters; I'm wondering whether doing stuff like moving non-location conditions to the top of my triggers would really help.

Also when I test alone with 7 computers it doesn't really lag.

But it definitely does lag a bit in a FH. I'm wondering if wait triggers would be a less laggy alternative to death counters for some things?

Edit: Stace I think it is trigger lag because the lag is definitely patchy - feels like 1-2 second breaks inbetween.

I'm going to remove my constantly firing p12 kill triggers and replace them with removes and see if that helps. I take it gives also affect this?

Death counters don't cause lag, and sorry that misunderstanding's on me

I recommend you stay away from waits in general.

Untrue. Bring conditions allocate memory in an inefficient way, are fairly processor intensive, and can cause memory leaks.

When I originally made Autocracy RPG, I created 240 triggers that managed to "lag" the map to completely unplayable levels, and all they consisted of were Bring conditions (all the actions were simply Preserve Trigger).

The one thing that was painfully obvious: It was always worse with more players. Even if those players were computers, it didn't matter.

Is there any way you can put the Bring conditions below other conditions that don't always fire? Conditions are checked in order, so if the top condition isn't met, the rest aren't evaluated. Also, is it possible for you to use Commands instead of Brings? Commands is a very efficient condition.


Have you tried testing with just one other person, or with different people? Maybe saving during the game to see who it says is lagging, and having them leave? If you have a decent rig, you might not be suffering that badly from the effects of processor-intensive triggers, until you're in a game with someone who's on a worse machine.

Ya Azrael I actually stumbled upon a thread were you mentioned the bit about your RPG, brings, and removed triggers piecemeal to find the root before writing this. I also tried using just computer players to see if I could cause the lag - even replicating player behaviors that could cause lag and I didn't get anything noticeable on my end. As soon as I played a FH I felt the lag waves and they definitely go down with less players. If DCs aren't a problem I think Kill triggers could be so I removed all the ones I had. I just did a quick check and I have 3.6k bring conditions in the map firing for all 8 players (1comp) for most probably. I could probably shave that down 50% but I wouldn't want to take that on unless I knew there would be a significant result from it. Since it would entail a lot of manual editing and new conditions.

Just saw your edit, so I know that it doesn't lag with less players or certain players. But it's lagging way too often and inconsistently (saving and asking the last name to show up to leave never clears it) for it to just be coincidence, know what I mean? Also since I did experience crippling lag on the map when it did use hypers I'm doubly suspicious.

Easy way to find out if reducing the Bring conditions will help, put a Never condition above the Brings conditions and test like that (or remove/replace the Brings conditions themselves). Keep removing and disabling things until you can test with a full house and have it not lag.

It seems that testing by yourself isn't going to help, as your computer must be better than the average player's. Any triggers that cause lag in a full house should cause just as much lag with computer players, unless you're testing on a rig that's better than those used by one or more people who join your game.

I think it's almost certainly going to be the bring conditions. Pretty sure there's a demo map in the DLDB somewhere that has different trigger actions/conditions firing and you can control them to see how much lag each one produces. The DLDB is being a bitch and giving me heaps of SQL errors so I can't find it at the moment.

Then again, he says he's not running hyper triggers, so triggers being the principal source of his lag seems unlikely.

He happens to be in the "extremely unlikely" class where his triggers (or at least Brings) measure in the thousands.


My RPG currently has 10,317 bring conditions, but like Azrael's, if you add in some logical conditions above the Brings in the condition list, a lot of times these conditions will never even be checked. This way, you can keep the condition but get the benefit of "less lag". Also, I would double-check with someone like Heinermann before you switch all your Brings to Commands, unless I'm mistaken Command still has to search memory blocks to count up the units.

Edit:
Removed false information

Post has been edited 3 time(s), last time on Nov 18 2012, 6:06 pm by Stacy Keibler.

Just a thought based on the lag getting worse as more players are in the game, and crippling when you have hypers.

Does your map have triggers that constantly run non stop, and when you tested with the computers did you simulate to meet the conditions of those triggers?

If so, do those triggers need to constantly run or can they be shut down until the next time conditions are re-met?

If they can't be shutdown, can you add a death counter to act as a delay/cycle?

Yes, they can.


Yes, they do.


There's a condition that does this too. It's called "Bring".

Specifically, every time you use Bring at a location that's different from the last time you used Bring.


Brings physically scans the location for all units. Command checks in a much more efficient way.

Edit: This information is from a long conversation I had with Heinermann on the subject.

Post has been edited 2 time(s), last time on Nov 18 2012, 9:59 am by Azrael.

I suspect it must be triggers that fire nonstop. I've tried to be good along the way by putting brings after command conditions or death counts but most of the time these conditions are always met. I did remove/revise all of my constant fire kill p12/computer unit triggers and I think that helped. I definitely notice a cyclic lag spike though and it basically goes away at 5 players. Ideally I'd like to just find more culprit triggers but a DC delay condition is a pretty pro idea. I actually have those on some other constant fire triggers but it didn't occur to me to add them to everything else. So I can definitely try that.

Also I can replace some Brings with Command the most at, that should help right?

Yea bring condition causes lag if it repeats nonstop
you need to accompany it with death counter to remove lag

condition
player brings unit to location
death of unit is 0

action
move unit to location
set death to 1

Oh yes, definitely. The Command condition just checks a table in memory, which is basically as efficient as a death counter; Command Most looks up each player in the table, which is still pretty efficient (about 8 checks). Bring, on the other hand, scans a location for a collision with units, resulting in potentially hundreds or thousands of checks before determining if the condition is met or not.

Edit: I misread (see jjf's post below).

The problem with that is that SC will still have to run the checks for the Bring location every trigger cycle, because you've listed it as the first condition; this won't improve map efficiency unless it's the Move Unit action that's actually causing the lag.

As was mentioned above, your Bring conditions should always be at the bottom of the condition list for optimal results.

Post has been edited 1 time(s), last time on Nov 18 2012, 7:40 pm by Roy.

Thank you for correcting me, Azrael. My own memory on the topic was wrong.

For anyone interested in the original SEN literature on the Bring condition topic:
http://www.staredit.net/topic/2754/0/

And a previous topic on trigger lag:
http://www.staredit.net/topic/11648/1/

Post has been edited 1 time(s), last time on Nov 18 2012, 6:12 pm by Stacy Keibler.

We're talking command the most at, not command most. Command the most at is still a location-based condition. Command the most at presumably must first do a bring-like operation and then 7-11 death-counter-like comparisons - I would predict that it's actually less efficient than bring (compared to a single bring).

---

- If a trigger specifies "bring to anywhere", replace it with command
- If a trigger's purpose is to measure how many units of type x are on the map (or at the only location they can be at), use command
- If (a) trigger(s) purpose is to compare how many units of type x are on the map, use the appropriate command the most/least condition
- If you are doing comparison between number of units at a location using multiple brings, replace those with the appropriate command the most/least at condition.
- If you need to know specifically whether a unit or units are at a specific location, use bring
- If you need to put some kind of coordinate-based info in a deathcounter - there are some efficient algorithms for doing so, may be able to help you cut the trigger count down!

Post has been edited 2 time(s), last time on Nov 18 2012, 7:13 pm by jjf28.

You mind posting the map so we can look at the triggers you're having trouble with, it kind of feels like we're working in the dark and giving solutions to a problem that you're not really sure of the root cause.

http://www.redactedhtml

I'm thinking I could run a short death count (maybe 4 cycles) and just divide up a lot of constantly firing bring conditions among that?

It'd be super tedious since my options for a trigger copier all involve tedious renaming but I think that could work.

Post has been edited 1 time(s), last time on Nov 19 2012, 7:50 pm by Veta.