Staredit Network

Ever make a map, and the triggers are working perfeclty, then you add a respawn trigger and everything just freezes up? and the waits become 1hour nitemares?

Well I have solved the problem... [Syncronized Wait] and [Sliced Wait].


-What exactly is causing the problem you might ask?
Well in StarCraft, the game activates map triggers by going along within the map from top to bottom throughout the triggers. The triggers are fluidly ran and go on infinitely until the action and condition are met. There are a few triggers, however, cause for the actions from top to bottom from occuring. These triggers "break" the loop from top to bottom. These "breaks" include the actions: [Wait], [Pause Game] and [Center View]. These triggers are what cause the game to stop the loop and have the most priority in actions (meaning, they happen and end before any other triggers occur).

These "breaks" allow for the game to initiate commands without them clashing into each other.

What really causes the main problem is the fact that you can entirely ruin your game by adding a [Hyper Trigger], which is a trigger that causes for the 1300ms pause that naturally occurs, and turns it into a <97ms pause.



So, whats the solution?





[Syncronized Wait]
It is in essence, a wait that occurs with another wait... sound impossible? Well, the StarCraft engine runs from top to bottom, and checks to see if a trigger is finished. If all triggers are ran with the exact same wait; it results in them becoming sync; meaning they start to not stack, but run with each other (it makes it seem as though its not stacking).




How exactly do you make this happen?

Simple, just make every wait within your triggers a set amount.
For example, setting your waits to exactly 500ms.

By setting your triggers to exactly 500ms as well as your [Hyper Trigger] to 500ms, you can sync all of your waits together which solves your long waits. The only problem with adding a 500ms synced [Hyper Trigger], is that the hyper trigger tacks on an additional wait time (so in this example, the wait adds 500ms to each trigger).

If you have a respawn that occurs after 5000ms, but are using the 500ms example, just put within the trigger something called a [Sliced Wait].





[Sliced Wait]
What is a sliced wait?

A sliced wait is basicly what it is, a wait that is broken up into separate parts, but still containing the exact time occuring each time.

For example, above I stated that I wanted to add a 5000ms wait within a 500ms [Syncronized Wait].

To slice it, you take the 5000ms/500ms. resulting in 10x.

This 10x would mean that the wait in the trigger has to have 10 of them. so the resulting trigger would look like this:


CONDITION:
Commands 0 Marine

ACTION:
Create 1 Marine
Wait 500ms.
Wait 500ms.
Wait 500ms.
Wait 500ms.
Wait 500ms.
Wait 500ms.
Wait 500ms.
Wait 500ms.
Wait 500ms.
Wait 500ms.
Preserve trigger.


and because the [Hyper Trigger] is sync'ed by 500ms, you divide the amount of triggers by 1/2, resulting in:

CONDITION:
Commands 0 Marine

ACTION:
Create 1 Marine
Wait 500ms.
Wait 500ms.
Wait 500ms.
Wait 500ms.
Wait 500ms.
Preserve trigger.


By having this trigger, it slices your triggers wait times and allows for the trigger to [Sync Wait] and occur smoothly, without the need to use death counters.

Of course, you don't need to Sync your [Hyper Trigger], if you don't sync your hyper trigger, you may place the [Hyper Trigger] on the way bottom of the list.

By having both these concepts into action within your map, you will no longer have the "forever center screen", "everlasting wait", and "the wait disaster" that you all have experienced at least once in your mapping life.


As a normal side effect, your amounts of trigger actions will decrease greatly due to the multiplied waits that are required.







But, this will allow for you to use infinite amounts of waits for a single player without resorting to deathcounts.




Hopefully this solves your problems.

(btw, this is how I did that whole craziness in my bounds, where the 'unit colors are flashing', 'music is going', and 'leaderboard is changing'.)





(Im still testing on effectiveness and the limits of this concept.)





And remember, Red2Blue taught you this...

You know, I would actually use that if I didn't know about custom score and death counters.

Let's say your making a bound, there are 227 (Some might not be selectable) units you can make a death counter off of. But if your using them in your bound, you might want to use units that are not exploding and units that are not bounding.

Also, there are eight (Well, seven, becuase Total is a bit useless in this situation) kinds of scores you can use too. Units, Buildings, Units and Buildings, Kills, Razings, Kills and Razings, Custom. Now obviousley you can only use a select few of those options in a bound.

Units: Can't use becuase you have a bounding unit.
Buildings: Would work.
Units and Buildings: See "Units."
Kills: If you have a banner, this won't work. Unless to ban you kill buildings.
Razings: Would work if your not killing men with your banner.
Kills and Razings: If you have a banner, this will not work.
Custom: Would work.

Now I assume you, Reddy, would know how to use all of those options to loop music, change a leaderboard, modify unit HP, and all those other effects.

Using counters, your Hyper Triggers also don't have a wait effect on them, so you only wait 11.9x (Go LW, go =P) milliseconds. Not 500.

Oh, and I forgot resources.
To make players not cheat (Like "Show me the money" in single player) just set resources for a computer player.

But then that would only work if you have four computers (Assuming 8 slot map).

So just disable single player all together, like you do in your maps anyway ;).

He was using 500ms as an example...

I know that. But still, with counters, your hyper triggers are as effective as possible.

How is it not as effective with what Red2Blue was saying?

We have tutorials for everything!

Because with whay Reddy said, the Hyper Triggers now add a 500ms wait (Whatever wait you set them to) on EVERY trigger. But the waits don't stack.

This method will work great if you don't like fooling with death counters and scores.

I recommend this for beginner/average map makers.

Edit: Please, stop quoting posts that are RIGHT ABOVE yours.

I'm really getting tired of these wait problems.

Trigger

Players:

¤ Player 1

Conditions:

¤ Switch 1 is set

Actions:

¤ Wait for 0 ms

¤ Clear Switch 1

¤ Preserve Trigger

You can use any player, just make sure the second one is greater in number.

Trigger

Players:

¤ Player 2

Conditions:

¤ Always

Actions:

¤ Wait for 0 ms

¤ Set Switch 1

¤ Wait for 0 ms

¤ Preserve Trigger

GG Wait problems.

(U)Bolt_Head or whoever introduced me to that style of hyper trigger really is smart.

so with the hypper triggers u just said here minimoose, if the same player that have hyper trigger and he have waits, it will not stuck ? If true, I can modify some of my maps to add players that were used only for hypper triggers
and Red2Blue, if u have hyper trg of 0ms, lol..... we can't make anything, so i think i will use minimoose hyper trg (why isn't this hyper trg on tutorials ????????????????)

I hate how you introduce this as the perfect solution. (although i didn't read it)

Its not really the perfect solution... its more like a way to fix up what has been messed up.

Obviously death counters are the efficient way to substitute for wait; im just offering an example to fix any mistakes a "wait" could cause.

and you don't have to use the 500ms example. I usually use 10ms (there is no difference at all to the 0ms, feels the same). I believe that it is also possible to use multiples of the number in smaller forms, say 100ms for the 10ms hyper trigger.


Yes, minimoose using 0ms before and after trigger actions will have the same effect as the 500ms effect. But applying 0ms to every trigger is much harder to do then to fix your triggers by slicing.



In addition, hyper triggers don't always have to have max 64 actions. I rarely do that for a wait intensive map.

I always create a hyper trigger using 3 triggers:

CONDITIONS:
Always.
ACTIONS:
Wait10ms
Wait10ms
Wait10ms
Wait10ms
Wait10ms
Wait10ms
Wait10ms
Wait10ms
Wait10ms
Wait10ms
Preserve Trigger.



CONDITIONS:
Always.
ACTIONS:
Wait10ms
Wait10ms
Wait10ms
Wait10ms
Wait10ms
Wait10ms
Wait10ms
Wait10ms
Preserve Trigger.




CONDITIONS:
Always.
ACTIONS:
Wait10ms
Wait10ms
Wait10ms
Wait10ms
Wait10ms
Wait10ms
Preserve Trigger.




each one has 2 less 10ms.

This method of hyper trigger doesn't overdo it, and doesn't hurt your waits as badly as 64,0ms.

And to think..I have 62 waits in each hyper (Becuase comment and preserve)
And I copy that five times.
62x5.

----------------------------------------------------------------------------------------------------------------
I would have to agree with rexy that the system works if you use death counters and minerals on comps and the like. But so should the trigger where it alternates wait triggers, this creates a hyper trigger system that never runs out for a period of time...
----------------------------------------------------------------------------------------------------------------

Actually... no.

The waits within the triggers cause for the hyper triggers to repeat themselves before the trigger that contains the waits completes. Resulting in an infinite loop even though you have shorter amounts of waits.

The example shown probably lasts for approx 10 minutes without synced waits, but infinitely with the syncronized waits.

Besides, games only last for at usual max 30 minutes. What... have a 30hour hyper trigger? For what? Someone is going to sit there for 30 hours to see the trigger die?

Dont spam those dashes to make your posts longer resulting in more minerals. You should be warned for blatantly abusing the system.

Dude, he posted that on February 2nd. We have found it by now, and dealt with it. Either use the report function or check the dates, before YOU get warned for abusing the system.

Ah but I don't get minerals for short tidbits like these or for quoting him so

This post has no relevance to the concept anymore...

I never knew that you are rewarded minerals for the amount of textual blips in a post. HM....


BLAHBLAHBLAHBLAHBLAH, was that 2 minerals?


back on topic...

I found out that the triggers are hardly synced... it fixes major center view problems. Back to the drawing board.

How many HTR before the NEO?