Ok. We already know that the "reset" (where the glitch goes away) gets tripped when you either use a different location with Brings or switch over to Commands instead (or visa versa to Brings FROM Commands).

Now then, I'm trying to figure if other conditions trip the reset as well. Let's see:

• Accumulate("Players", At least/At most/Exactly, Resource Amount(#), Resource Type);
  
• Always(); Never trips it.
  
• Bring("Players", "Unit Name", "Location", At least/At most/Exactly, Unit Amount(#)); Only trips when a different location is used, or if it's used between consecutive Commands conditions.
  
• Command("Players", "Unit Name", At least/At most/Exactly, Unit Amount(#)); Only trips when switches from consecutive Brings condition uses?
  
• Command the Least("Unit Name");
  
• Command the Least At("Unit Name", "Location");
  
• Command the Most("Unit Name");
  
• Commands the Most At("Unit Name", "Location");
  
• Countdown Timer(At least/At most/Exactly, Time in Seconds);
  
• Deaths("Players", "Unit Name", At least/At most/Exactly, Deaths Amount(#));
  
• Elapsed Time(At least/At most/Exactly, Time in seconds);
  
• Highest Score(Score Type);
  
• Kill("Players", "Unit Name", At least/At most/Exactly, Unit Amount(#));
  
• Least Kills("Unit Name");
  
• Least Resources(Resource Type);
  
• Lowest Score(Score Type);
  
• Most Kills("Unit Name");
  
• Most Resources(Resource Type);
  
• Never();
  
• Opponents("Players", At least/At most/Exactly, Player Amount(#));
  
• Score("Players", Score Type, At least/At most/Exactly, Score Amount(#));
  
• Switch("Switch Name", set/not set);

These still need to be determined.

I'm going to suggest a formal model of what is going on. I does not mean this is the way things happen to be in reality but this is the way they could be represented or thought to happen. I'm not saying there is no other models which could describe triggers behaviour.

Model description.
Let's assume there is a buffer for created units. All units in the buffer are tagged with the location where they have to be created. The buffer can be binded to location or the whole map (the whole map is not the Anywhere location but a different object). The buffer could be binded only to one object at a time. The statement that the buffer is binded to the location means that all units created on that (and only that) location get to the buffer (tagged with the location) instead of the location. If the buffer is binded to the whole map all created units are get into the buffer. The buffer could be flushed, it means that all units in the buffer get actually created at the locations they tagged.
At start of the game buffer is not binded to any object. When "bring", "command the least at" or "command the most at" conditions execute at location L the location L is compared to the object O the buffer is binded to at the time. If the location L equals to the object O nothing happens. If the location L differs from O then two things happen: the buffer become flushed and is binded to the location L. When "command", "command the least" or "command the most" conditions are executed the whole map is compared to the object O. If O equals to the whole map nothing happens. In other case the buffer is flushed and binded to the whole map. The buffer is flushed at the end of every trigger circle.
Actions "kill unit", "kill unit at", "remove unit", "remove unit at" result in flushing the buffer and disattaaching it from the object. The "move location" action flushes and detaches the buffer if the location which is being moved equals to the location which is attached to the buffer.

All tests I carried out so far do not contradict with the model, however it could be supplemented with some unknown conditions or actions which might flush the buffer or bind it to the other object.

Post has been edited 9 time(s), last time on Apr 30 2008, 8:32 pm by Wormer.

Buffer and Flushed. Yeah. Those are better words than "cached" and "reset", probably. I'll go with your model.

Lazy Blizzard coders indeed!



Edit: We should really get someone like ShadowFlare of Farty or whoever knows SC memory well to try and piece this together. Though I'm not sure what use it could be just yet...

Post has been edited 3 time(s), last time on Apr 30 2008, 7:18 pm by Tuxedo-Templar.

Very very lazy! The model updated with command the most/the least (at) conditions.

Edit: Other conditions do not seem to flush or bind the buffer at all.

Post has been edited 2 time(s), last time on Apr 30 2008, 7:46 pm by Wormer.

Hmm. Forgot about Commands most/least. I just never use those.

However some actions result in flushing the buffer. Actions kill unit, kill unit at, remove unit, remove unit at flush the buffer and unbind it with the attached object.
Model updated.

Edit: the "move location" action flushes and detaches the buffer as well if the moved location equals to the location which is attached to the buffer (more tests with move location needed). It seems to me that the model with the buffer and flushing/binding is not the best one... But I cant think of another model for now.

Edit2: Oh well, I'am tired
The following actions are to be tested.
However I dont expect ones that does not have locations in their parametes to influence the buffer. The suspicious actions are marked out. I've tested all other actions and conditions and the results I got are reflected in the model.
It's already long time to go to bed...

Post has been edited 5 time(s), last time on Apr 30 2008, 8:43 pm by Wormer.

I just performed some tests, so you can check to see if it follows your model.

I wanted to examine if bringing to a different location than was created at would have any difference, even if the locations were over the same area.

I tested many cases, and they're pretty redundant and will probably just verify your model.

First of all there's 2 locations, Location 0 and Location 1. They are the same size and are stacked on top of eachother.

Trigger A
//Remains unchanged throughout the tests

Trigger C
//Uses bring to check if X marines were brought to Location 1
//Creates 1 ghost if true

Trigger B
//Uses bring to check if X marines were brought to Location 0
//Creates 1 firebat if true

The cases consist of the following sequences


In all the cases, a ghost is created when x = 2, and no ghost is created when x = 0. Regardless of the x value, however, the resulting firebat creation remains the same. So C affects the following B triggers whether or not C itself is true.




I just performed a simpler test, which I think illustrates it more clearly as well


There's only one trigger that's changing. It has no actions, and it's checking for 9999 units, so it will be false regardless of whether it's at Location 0 or 1, since theoretically based on previous experimental data, if it's at Location 0 and looking for 0 units it will be true, and if it's at Location 1 and checking for 2 units it will be true. Setting it to 9999 ensures it's false for both cases and that the truth of the condition doesn't affect the results, even though theoretically and experimentally they don't. This is just a precaution to keep as much control as possible.

However, when it's set to Location 0, the following two triggers run. Two firebats are spawned.
When it's set to Location 1, the following two triggers do not run.

Post has been edited 3 time(s), last time on Apr 30 2008, 8:46 pm by devilesk.

I can't pm anyone at the moment so here you go!

This is pretty simple. Its just like AngelFarto's Tron map in the way that you move an air unit by creating units from a building of some sorts. The catch is that my way of doing it is most likely better and easier to understand then what he did. It still uses a Coordinate Grid and a few other location for other purposes. The triggering is pretty simple. The moves are on a death counter. Counts of 1,5,9 are Left. Counts of 2,6,10 are Up. Counts of 3,7,11 are Right. Counts of 4,8,12 are Down. I made it like this because you can only add and subtract with death counters. ( set as well but thats useless ) You start the game with a count of 8 which will move your Corsair down. As you move left and right by creating a Medi(C) or a (M)arine you add and subtract to this count. Their also has to be repeat triggers that if set, they reset the count to a normal value. ( 5,6,7,8 ) This is used to lessen the amount of triggers used. All they do is if a count of 1 is achieved, it will set the count to 5, which is the same direction in terms of counts. Its the same for all the rest of the moves.

Yeah, using Bring Unit with a different location flushes the buffer.

Not sure about using Create Unit actions with a different locations, though...



Edit: We really need to start a new thread for this shit.

Well, good. Everything in the tests is as it is expected for now... The goal is to find refutation to the model. There might be one because I'm not quite statisfied with it.

It won't flush even with different locations. I've tested it.

Before waits are tested, I think we should establish the current theory on how waits work. Moose recently straightened out a few things and explained certain fuzzy areas to me. Before I've heard that when SC hits a wait it goes and rechecks all the triggers, but I didn't know the specifics and the extent to which it did so and then what it did after.

I'm pretty sure it goes in the following way:

First I'm going to define the trigger order.
All of P1's triggers are run, then P2's and so on, P3 P4 P5 P6 P7 P8.

When a wait is hit, SC goes back and starts checking triggers again, starting with P1.
It goes through each trigger checking the conditions, and running the trigger if it's true, like normal.
It goes through P1's then P2's and so on until P8.

However, for the player that owns the wait, when SC is checking that player's triggers, once it reaches the trigger with the wait again, it will stop checking that player's triggers.
For example if the wait was located in P2's triggers, the following would happen:
It would check all of P1's triggers and then check P2's triggers up until the trigger with the wait. It will then skip the rest of P2's triggers and proceed to check all of P3's and all of the other player's triggers.

Once SC makes one pass through all of the player's triggers, it will then proceed to do the actually waiting of the wait. After the wait period is finished, it will resume from the point it originally left off by executing the actions immediately where the wait was. It will finish that trigger and then keep going normally.

If a wait is encountered when SC is going through its initial single wait-induced pass/check of the triggers, then that whole process will be put on hold, and another check from the beginning will be run.

Essentially the waits are like a "stack" structure, LIFO (last in, first out). If it hits the wait, it puts its current position in the stack and rechecks all the other triggers. Each wait encountered adds to the stack, and the original wait cannot be finished until the last wait put on top of the stack has been completed.

There might be holes in the explanation, but it seems to make sense.

Yea, in my tests I just tried to keep things extremely simple and controlled just to make sure we are associating the correct conditions/actions as the causes of what we are seeing.

As for refutation I think the best thing to do is outline a test based on the model and use the model to predict what the outcome should be, and then actually implement the test to see if the results match the predictions.

So should you put the hyper triggers after ( on the bottom ) of the trigger list for that player? Or do you mean it stops looking after the wait, inside the trigger containing the wait?

EDIT: So does it matter the value of the wait? Its normal 0ms but does it matter if its 10ms, 100ms, 1000ms?

Yes hyper trigger should go at the bottom of the trigger list. No, I don't mean it stops looking within the trigger where the wait occurred. After the wait has finished doing its business and rechecking, it resumes from that same trigger where it left off. In other words, it continues with the next action in that trigger.

The value of the wait does matter. It determines the period of time after which SC has rechecked the trigger list it will "wait" for. However, I believe it rounds down to multiples of 63ms or something. So anything less than 63ms is treated as 0ms. 0ms wait means that there's no pause after SC has rechecked the triggers as a result of the wait. If the wait was lets say 10s, then after SC has rechecked the triggers, it will wait/pause for 10s, before resuming from where it left off.

I know the obvious benefits from using hyper triggers, but how often does StarCraft check the triggers with/with out hyper triggers?

Like every 2 seconds without. Like 12 times per second with.

Yeah, I was talking to Farty about this last night, he got all excited saying that:
4/29/2008 8:51:58 PM O)FaRTy1billion: ! Bring takes a loop to update?
4/29/2008 8:52:06 PM O)FaRTy1billion: That means somewhere there MUST be a table for units in location
4/29/2008 8:52:08 PM O)FaRTy1billion: I MUST FIND IT

He just signed on, I'll tell him to get his butt in here

Also, I'm starting a new topic now, so move there with this discussion.

Waits round up to the nearest multiple of 42, so a 0 is 42, and a 43 is actually 84.

Really? Because it seems that when I create a unit at a location, different or the same, it simply flushes the entire buffer and I can now detect any units, as shown in the Binary Count-Off Unit Transfer map.

Post has been edited 2 time(s), last time on Apr 30 2008, 11:42 pm by Falkoner.

I thought it worked in multiples of 42.

Always and Never just return true and false, respectively. They do nothing ever.
I'll go poke the condition list.

New topic for discussion

Sorry for spamming up your topic, lil-inferno, it was in the name of StarCraft!

I just pulled a number out of my ass. i have no clue, but 42 sounds right.