Staredit Network > Forums > SC1 UMS Theory and Ideas > Topic: Concept Ladder
Concept Ladder
Apr 26 2008, 7:00 pm
By: lil-Inferno
Pages: < 1 3 4 5 6 >
 

Apr 30 2008, 4:53 pm The Starport Post #81



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(); :P
  • 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.



None.

Apr 30 2008, 6:52 pm Wormer Post #82



Quote from name:Tuxedo-Templar
It seems there's some function that 'updates' the status of units found within a location/the map, where that status is being cached between each consecutive activation of the Brings/Commands conditions. Then there appears to be something that resets that cache when the brings/commands consecutive occurrences gets broken (during the same trigger cycle?).

Quote from name:(U)devilesk
I think with more tests using many different cases, we'll be able to put together a more definitive explanation and model for how it's working, but I'm going to bed now.
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.



Some.

Apr 30 2008, 7:08 pm The Starport Post #83



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

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.



None.

Apr 30 2008, 7:36 pm Wormer Post #84



Quote
Lazy Blizzard coders indeed!
Very very lazy! :D 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.



Some.

Apr 30 2008, 7:55 pm The Starport Post #85



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



None.

Apr 30 2008, 8:06 pm Wormer Post #86



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.
Quote
Victory
Defeat
Draw
MoveUnit
MuteUnitSpeech
Order
PauseGame
PauseTimer
PlayWAV
RunAIScript
RunAIScriptAt
SetAllianceStatus
SetCountdownTimer
SetDeaths
SetDoodadState
SetInvincibility
SetMissionObjectives
SetNextScenario
SetResources
SetScore
SetSwitch
TalkingPortrait
Transmission
UnmuteUnitSpeech
UnpauseGame
UnpauseTimer
Victory
Wait
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.



Some.

Apr 30 2008, 8:33 pm Demented Shaman Post #87



Quote from Wormer
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.
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
Quote
Bring("Player 1", "Any unit", "Location 0", Exactly, 0);
Create Unit("Player 1", "Terran Marine", 2, "Location 0");

Trigger C
//Uses bring to check if X marines were brought to Location 1
//Creates 1 ghost if true
Quote
Bring("Player 1", "Terran Marine", "Location 1", Exactly, X);
Create Unit("Player 1", "Terran Ghost", 1, "Location 0");

Trigger B
//Uses bring to check if X marines were brought to Location 0
//Creates 1 firebat if true
Quote
Bring("Player 1", "Terran Marine", "Location 0", Exactly, 0);
Create Unit("Player 1", "Terran Firebat", 1, "Location 0");

The cases consist of the following sequences

Quote
A
B
B
Result: Two firebats created

A
B
B
C
Result: Two firebats created

A
B
C
B
Result: One firebats created

A
C
B
B
Result: No firebats created

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

Quote
Bring("Player 1", "Any unit", "Location 0", Exactly, 0);
Create Unit("Player 1", "Terran Marine", 2, "Location 0");

//X changes between 0 and 1, Location 0 and Location 1
Bring("Player 1", "Terran Marine", "Location X", Exactly, 9999);
Comment(" ");

Bring("Player 1", "Terran Marine", "Location 0", Exactly, 0);
Create Unit("Player 1", "Terran Firebat", 1, "Location 0");

Bring("Player 1", "Terran Marine", "Location 0", Exactly, 0);
Create Unit("Player 1", "Terran Firebat", 1, "Location 0");

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.



None.

Apr 30 2008, 8:49 pm Brontobyte Post #88



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

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.



None.

Apr 30 2008, 8:49 pm The Starport Post #89



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. :P



None.

Apr 30 2008, 8:58 pm Wormer Post #90



Quote from name:devilesk
Quote from Wormer
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.
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.
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.

Quote from name:Tuxedo-Templar
Not sure about using Create Unit actions with a different locations, though...
It won't flush even with different locations. I've tested it.



Some.

Apr 30 2008, 9:04 pm Demented Shaman Post #91



Quote from Wormer
Edit2: Oh well, I'am tired :|
The following actions are to be tested.
Quote
Wait
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...

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.

Quote from Wormer
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.
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.



None.

Apr 30 2008, 9:10 pm Brontobyte Post #92



Quote from name:devilesk
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.

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?



None.

Apr 30 2008, 9:16 pm Demented Shaman Post #93



Quote from Brontobyte
Quote from name:devilesk
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.

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.



None.

Apr 30 2008, 10:28 pm Brontobyte Post #94



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



None.

Apr 30 2008, 10:53 pm Demented Shaman Post #95



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



None.

Apr 30 2008, 11:24 pm Falkoner Post #96



Quote
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...

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: :O! 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 :P

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.

Quote
It won't flush even with different locations. I've tested it.
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.



None.

Apr 30 2008, 11:43 pm rockz Post #97

ᴄʜᴇᴇsᴇ ɪᴛ!

Quote from name:devilesk
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 thought it worked in multiples of 42.



"Parliamentary inquiry, Mr. Chairman - do we have to call the Gentleman a gentleman if he's not one?"

Apr 30 2008, 11:44 pm O)FaRTy1billion[MM] Post #98

👻 👾 👽 💪

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



TinyMap2 - Latest in map compression! ( 7/09/14 - New build! )
EUD Action Enabler - Lightweight EUD/EPD support! (ChaosLauncher/MPQDraft support!)
EUDDB - topic - Help out by adding your EUDs! Or Submit reference files in the References tab!
MapSketch - New image->map generator!
EUDTrig - topic - Quickly and easily convert offsets to EUDs! (extended players supported)
SC2 Map Texture Mask Importer/Exporter - Edit texture placement in an image editor!
\:farty\: This page has been viewed [img]http://farty1billion.dyndns.org/Clicky.php?img.gif[/img] times!

Apr 30 2008, 11:47 pm Falkoner Post #99



New topic for discussion

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



None.

May 1 2008, 2:41 am Demented Shaman Post #100



Quote from rockz
Quote from name:devilesk
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 thought it worked in multiples of 42.
I just pulled a number out of my ass. i have no clue, but 42 sounds right.



None.

Options
Pages: < 1 3 4 5 6 >
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[07:15 am]
IlyaSnopchenko -- Or was it a switch :)
[06:59 am]
IlyaSnopchenko -- But I need to do more work on the system to make it look better (hard to explain without showing the map and explaining precisely what i added them for)
[06:57 am]
IlyaSnopchenko -- I've added set death hypertriggers
[2019-8-25. : 4:02 am]
Pr0nogo -- single frame hypers with a simple line of code without using EUDs imo
[2019-8-24. : 11:01 pm]
Suicidal Insanity -- They never go to bed on time
[2019-8-24. : 9:49 pm]
NudeRaider -- But why would you even want to do that? Hypers have almost no downsides.
[2019-8-24. : 9:49 pm]
NudeRaider -- IlyaSnopchenko
IlyaSnopchenko shouted: A stupid question: can I run hypertriggers for just one phase in the map, not all of it (I know I can... just wanting to know if there are any caveats)
you can, but you'd need to run switched hypers. Classic hypers can't be stopped afaik.
[2019-8-24. : 4:42 pm]
TF- -- It should be fine
[2019-8-24. : 3:41 pm]
IlyaSnopchenko -- Is that a yea or nay? :)))
[2019-8-24. : 3:36 pm]
TF- -- 🤙🏾
Please log in to shout.


Members Online: Roy, marleefwalls