Okay, discussion starting here.

Basically, this discussion is about how the conditions Bring and Command detect units, as in many cases you have problems where a unit being created or removed is not immediately updated in the game, and so the two conditions may still detect it, or may not detect it, when it seems that logically they should.

Discussion solved, here's the description that DoA gave:

The topic was originally discussed in the first pages of this topic. Most of the need-to-know information is found above though.

Post has been edited 4 time(s), last time on May 1 2008, 10:06 pm by Falkoner.

Sounds interesting...

Link to the old topic where the discussion started:
http://www.staredit.net/54275/
Good for reference and what has already been discussed/tested

This will be very helpful for tracking down/avoiding bugs, but I wonder if this couldn't be used for anything...

I wonder how much people should take this into account when making their maps or how many untold unexpected glitches this has caused.

Oh one more thing. Have you tested what happens if the triggers are separated by different players? Same triggers, just owned by different players. I'm wondering because maybe the "buffer flush" may happen at the end of each player's trigger list.

I can't currently test maps with other people at the moment. But unless the buffers are stored client side for each player the triggers run for (which wouldn't matter in a solo game), it appears player does not affect the buffer.

Post has been edited 3 time(s), last time on May 1 2008, 3:33 am by Tuxedo-Templar.

Doesn't have to be other humans, it could be comps. I'm just wondering like after SC checks all of P1's triggers would it flush that buffer before going on to P2's triggers and so on.

Hmm, is any of you open for a testing session soon? If so, I can make the map, or you can if you want, I can get on and help test.

I would love to find out exactly what makes these conditions tick, as I have had many maps where this caused me major problems, and I ended up having to go through many annoying measures to fix the problem.

Seperating by different players do not flush the buffer. Already tested.

Edit:
You have "give unit" actions there, it may vary from "create unit" behaviour. In any case, you have "remove unit" action which flushes the buffer, it's not the "create unit".

Well, you know, I'm not statisfied with the model because of three reasons:
The first and the main reason is that when activating "create units" action units are actually created at the location. They are just don't visible to the bring conditions. This could be tested for example by setting unit's hit points to 50% immediately after the unit is created. That created unit won't be seen by the following "bring" condition but will have 50% of hit points. That means the buffer only exists in some way for bring/command actions only, that means this is not a buffer at all.
The next reason is that flush/bind operations occure only in pairs. Which makes me think that actually they are one inseparable operation.
The last reason is that the model seems a bit complicated to me. I belive it is possible to make it simplier.

I've analyzed everything one more time and came up with another possible model that seem to me more adequate.

Alternative model desctiprion:
There is a cache C(L) for each location and the whole map that is bufferizeing all information about units found at that place. For convenience let's talk about the whole map as an imagineable location Map. Each cache may be found in two states: valid or invalid. The valid state means that the information contaned in the cache is actual. All caches are found in invalid state at the start of the game.

Some conditions are assigned to locations. Namely, conditions "bring", "command the least at", "command the most at" are assigned to the location they are executed at and the "command", "command the least", "command the most" conditions are assigend to the Map location. All other conditions are not assigned to any location.

When the condition assigned to the location L is executed and the location's cache is found in invalid state all information about units at the location is gathered and placed into the cache C(L) which is then marked as valid, all other caches are marked as invalid. The next time the condition will execute at the location with the valid cache the information about units is taken from the cache instead of the location itself.

However some actions after their execution could make the chache's state invalid. Actions "kill units", "remove units" make the cache assigned to the location Map invalid. Actions "kill units at" and "remove units at" make the cache assigned to the location they are executed at invalid. The action "move location" makes the cache assigned to the moved location invalid.

All caches are explicitly marked as invalid at the end of each tirgger circle.
Alternative model description finished.

Post has been edited 1 time(s), last time on May 1 2008, 8:07 am by Wormer.

Heh, that's close to how it works, but not quite.

First thing to remember is that SC is old, and therefore doesn't have a large amount of memory to use. Both previous models use a lot more memory than needed. Here's what it actually does.

There is a single block of data set aside for searching for how many units are at a certain location. When the trigger cycle begins, this block of memory is marked as invalid. When SC comes across a trigger that requires a number of units, it determines if it needs to repopulate that block of data. SC treats the entire map different from a location. If the block was previously filled with the entire map data and the current condition also applies to the entire map, it skips refilling the block. With locations, it does the same thing, except it checks that the block has the same location.

Repopulating the block begins with copying the counts that SC keeps of all units on the map. If it is a location search, it narrows the data down to the units that are in the location.

There are several trigger actions that can invalidate the block. They are:
Kill Unit
Kill Unit at Location
Remove Unit
Remove Unit At Location
Move Location
Move Unit

Creating a unit does not tell SC that it needs to refresh the data. Therefore, if the next condition needs the 'same' type of data as the last one, it won't refresh.

If there are any questions about how it works, I'd be happy to answer them.

Ah, so it was removing units, not creating them that was refreshing.

Thanks DoA, that definitely simplifies things, so I have one question, what action can I use in one trigger, in order to make all the bring and command conditions work according to how the units are ACTUALLY on the map, rather than how they are in the block?

Doing any of the actions I listed will set the block as invalid and force a refresh for the next condition.

EDIT -

Remove Unit and Kill Unit will always reset the block, even if there isn't a unit to remove.
Remove Unit at Location and Kill Unit at Location will reset as long as it is given a valid location, even if it doesn't actually remove a unit.
Move Unit and Move Location will reset as long as both source and destination locations are valid.

Post has been edited 4 time(s), last time on May 1 2008, 10:30 pm by DiscipleOfAdun.

It doesn't flush between comp/neutral players. I didn't get to find out about humans players, I meant.

To avoid having to take into account it being unrefreshed could one just put a "remove an unused unit" action in every trigger to force a refresh? Does refreshing a lot contribute to lag?

If the action doesn't actually do anything then it shouldn't create any extra lag, as shown by the lag test performed by Tux a while back.

So will remove unused unit be the new "preserve trigger"?

Nah, just a new addition Of course, I'll probably only add it when needed.

I wonder if using a dud Brings unit condition with a bogus location (or at least a different one) in each trigger wouldn't lag less?

Hmm. I really need to do a more rigorous lag test at some point.

I think that it won't be a problem removing a non-active unit, just do it when you need to and it shouldn't cause any extra lag at all.

Devilishly interesting. Guys, you even dont know how I like solving riddles like this! One more problem is quite solved. DoA, I suppose you've looked at the real SC code. Actually I was suspecting something like that. You see, when constructing my models, I was not bothered of how it really works, I just wanted to build an adequate and simple representation of the SC behavour. Of course those both models are using lots of memory, but the object I was pursueing was simplicity of an exposition along with it's exactness. I just thought having a seperate cache for each location would be more clear for understanding, but mabe I was wrong.

Could you, please, explain what locations do you mean saying the location is valid?



As one can see from the description SC actually do operations even if it do nothing (removes nothing for example). It is refreshing the units' cache. Even more, it is collecting information about all units on the map and then narrows data to the particular location. That means having command conditions would potentially lag less, though I dont even know and suppose noone can allege that it would or would not cause the lag without carrying out tests. Only tests could answer the question.

Heh. I wonder how SC mapmaking turns from making maps into making them the way they would not lag, which is degrees more complicated task. Everyone can write a program, there are people who can write the correct program, and only ones can write the correct and efficient program. This is really an art...

P.S.
Oh, and one more thing. DoA, could you please explain how waits are actually working in SC, if you know of course. Because I've heard explanations of the behavior (the last one was the develisk's) and know that it is happening in a resembling way, but I (and think the others too) want to be finally sure about how it works. Thanks.

Post has been edited 3 time(s), last time on May 2 2008, 10:23 am by Wormer.