Staredit Network

I am in the final stages of a map I'm making and looking back at some of the funny stuff I did. For one I did not use a single wait trigger... (apart from hyper triggers obviously)

That is right...

All things that require a timeframe to execute is solved by a small corner of the map where armories with 2% life spawn...

Now... I know how to use wait triggers... I just didn't.

Now choose for yourself am I crazy, stupid, or am I creating a new no-wait trigger revolution.

REVOLUTION BABY!!!

Well jesus, do you wanna give us an example!?! Otherwise, this is spam.

This would fall under the "share ideas" part of the forum discription. Plus I am inciting a revolution.

I would have to say your stupid.
Hey you asked

But its ok, most people are intemidated by wait triggers when they realize there is a problem but don't understand it fully. The thing is you can use hyper triggers and waits at the same time without any interferance if you do it right (seperate players and such).

Anyways the idea isn't bad. Using amrorys for waits has a better advantage however. You now have a wait that varies with the game speed.

Personaly, the way I would do it is have only one armory (or other physical wait device) and set it up as the smallest wait increment that your going to use. Then whenever it 'resets' just add a value to a bunch of death counters. Then you can use the individual deaths counters for your wait values.
Doing it like this you won't have to have many differant physical wait timers, you can use just one. And not waist space, and after you have done so many, it would proboly save triggering time.

"Virtual" wait systems are inherantly superior to wait triggers because they can control many different rates easily without the dangers of wait trigger interference, and it will indeed vary with game speed.

If you are using death counters for something else, an alternative would be to have a unit move along a path by one unit for every "tick" of the minimal-time counter, being reset to the beginning of the path when the desired interval has been achieved. That way you can vary the time interval by having the reset point be determined by those conditions that determine the time interval. It is not as flexible as the death counter system, but it does allow you to give the universal timer to a player that is already encountering death elsewhere. By using multiple paths, you can also achieve asynchronous timing: whereas the number of tick deaths is a constant, if you have different actions "resolving" at different rates, you can have one counter be closer to reset than the others, without the necessity of making every resolution time an even subdivision of the maximum number of deaths before the whole system resets.

Just use wait triggers damn it! lol, thats what their there for . Although they tend to be annoying some times, like they stopped working on me once. I dont get the whole millesecond thing eaither, isnt a second 100milliseconds?! Why is it 1000 milliseconds on Star Edit. Never understood that. Usssseee theeee waaaaits lol

Both can be usful at times. However, with more advanced systems, to get some parts to work right you need to know exactly how wait triggers work, and use them.
In my map I use a lot of wait 0s becuase many things wouldn't work without them.

Wtf is wrong with you?
That's like saying that there's 100 1000th-meters in a meter...

Personally, I don't think you're smart or stupid for not using Wait triggers.
The only problem with them is the fact that they require physical space. That, and they require more work, since with Wait triggers you just add 1 action to your trigger, but oh well.
I'd use virtual waits for my map if not for the fact that I don't have space and don't feel like doing the extra trigger work...

Heh, you know, I kind of share the same fear. I always avoid using wait actions for "programmatic" delays, like if I'm going to create a unit and then kill it or remove it a fraction of a second later, I prefer to use a method other than a wait action. The only reason I do this is because programmatically I see the commands on either sides of the wait as different stages of the triggers, and so I like to split them up into different triggers. But for things like, displaying text, I dump it all in one trigger with waits.

Usually when I simulate a wait, I just have a trigger that subtracts 1 from a death counter on every tick. The death counter is set to some value to indicate how long to wait, and the triggers know that the wait is over when the death counter hits zero. I just work on the rule that there are fifteen ticks per game second (might not be correct, but I've been modding with that knowledge for long enough to have it etched in my brain) and then I can work out what all my waits are in game seconds. It works well and it seems easy to do for me. I have never actually used the burning down building idea as a timer.

I'm quite sure that there are a maximum of twelve trigger cycles in a game second.

The prefix milli means 1000th. Just like there are 1000 millimeters in 1 meter.

So why is it that on your watchs, the milliseconds only go up to 100

Cause people are stupid I guess. I always called them "hundredths of a second" I guess the term "centasecond" isn't ever used.

Alot of people think that there are 100 milliseconds in a second. I asked them why. Apparently, most people believe this because on their stop watches there are 2 "small numbers" after the seconds that "go up really fast", and so they assume that these "small numbers" are milliseconds because "well, they are shorter than a second so they must be a millisecond!"

Still don't believe me? Believe your computer! Open the attached script so you can see my point.

(There is no virus in this script, anybody who knows VBScript will tell you that it is perfectly safe)

Addition:

Just as I said, this is most people's mentality. The reason is quite simple. An extra digit would take up more space, making the watch bigger, and making it more expensive to produce and more "clunky". Who wants to sacrifice this just so that you can get an accurate reading on a 1000th of a second?

Addition2:
Oh, and for those that want to argue that the intTime parameter in the Wscript.Sleep subroutine for VBScript isn't measured in milliseconds, here you go

The milliseconds on your watch go up to 100... WTFage? If they go up to 100, they're 1/100ths of a second, or centiseconds.

Ok, 1000 milliseconds=1 second.
the timer only shows 2/3 digits of the miliseconds cus they're cheap bastards.
0.230 is the same as 0.23 so why show the last digit?

Another possible reason is that since the human reflexes are slow, you really don't want to have a person win a race by 0.001 seconds do you? (aka 1 millesecond)

The typical human variation in the use of a stopwatch is about 0.1 seconds, which makes even the second decimal place unneccessary for most applications.

It is compleatly pointless to program the watch to count miliseconds but not display them. Even then without that extra 0 people think "23" not "230" hince it is refered to "23 hundredths of a second" not "230 milliseconds"

Mmm this conversation is starting to repeat itself.