Staredit Network

Hmm, even more strange. Two different answers. Well I trust yours more, bolt, but remember that even the tiniest bit of lag can throw off that count completely, though if it's an empty game I don't see that as being an issue. It's strange that it's actually less than 12, though (according to your calculation).

Any speculation on why this is?

I would assume the time is a result of what wait 0 is rounded up to.
If i take 1 / 11.8713 then i get .0842 the amount of time it takes for SC for one hypered wait. And I assume this is about what wait 0 is rounded to. But of course that time also includes the time that it takes SC to actually go though the actions and check the conditions. (witch isn't much time) but might be almost the whole 8/100ths of a second.

I don't know what minimoose did for his results but keep in mind all my times are based on the elsaped time shown at the end of the game. Also minimooses statement says hypers are exicuted 12.2 times faster than normal triggers. (not 12.2 times per second).

I think the (2 second wait) or 1 second whatever actualy varies depending on your game speed. I think it is 2 seconds for regular speed and close to 1 second for fastest. But thats pure guessing. I havn't actually done anything to test this. Maybe i should. I know how i could test it.

Well its 2 seconds (or more like 1.5) if you are measuring it by the countdown timer, but I remember I ran a 40 second (exactly) wav loop with a wait action + preserve trigger as well as a countdown timer (set to exactly 60 seconds), and they both completed at the same time! This was on fastest mode, tested both with and without other people over bnet. I didn't test it over the long run, though (the game lasted less than 10 minutes).

I'm not sure how game speed factors into this, though. Don't really have the patience for extensive testing, as long as I know it works for my purposes.

Well i know the countdown timmer doesn't accurately reflect real time. And i assume the elsapsed game time is the same value.

Well, I ran another test to see what's going on. I had a trigger activate zero waits and add 1 mineral on preserve AFTER 10 seconds had elapsed (to prevent initilization aspects and such), and gave a victory trigger end after 60 seconds more. Single player, no lag.

467 Minerals Accumulated

I ran the map again to see if the result would remain the same, again 467.

I let the map go one more time. This time, I put the game speed on normal. Yeah. 467.

Thus proving game speed does NOT affect trigger activation speed.

Then I took out the hyper triggers and ran the map. 31 Minerals were accumulated on a trial in both Fastest and Normal game speeds.

Apparently, running it after 10 seconds had passed disproves my 12.2x theory, perhaps it took some time to initialize. In my 12.2x trial, there was no elapsed time requirement on the triggers.

467 / 31 ~~ 15.1

Whatever, I'm not too sure anymore. :/
I'm sure the order of the triggers would effect this, too.

~Post #1000~

EDIT- Grr, another post seconds before mine. That'll learn me to use the QUOTE feature from now on.

Yeah thats where I'm most confused on. Let's see, we have the:

• Countdown timer
• 'wait # milliseconds' action
• Hyper trigger-timed counters (your 'add 1 mineral' thing, for instance. A.K.A 'wait 0 milliseconds' actions looping constantly)
• Elapsed scenario time

I'd like to know the exact nature of these timers. Any volunteers to test these?
(me == lazy)

EDIT 2- Back on topic: now that the Blur FX experimental map I submitted is up, mind updating my "cool trick" tip with the link?

http://www.staredit.net/index.php?download=440

Generally speaking the most likely cause for crashes in your game will be the placement of units over the maximum.

Save feature only shows slowest computer on the game in question, nor is that always the the cause of lag.

Replays will not provide the correct view if viewed at faster than fastest speed, or whatever it was played out, if certain events happen quickly, most likely with the Trigger's.

Only one of those you listed is a map making tip, and its not really true either. The most common cause of crashes is either placing units too close to the map's edge, placing invalid units, corrupting your map altogether (especially with the use of strings), or placing units with disable doodad (probably the most common, as many maps do it deliberately.) Placing units over the maximum isn't possible unless you're using a non-staredit/xtra editor.

I don't know if this is a tip, but it's just an interesting phenomena I observed: Flags always retain their original color. That is, if a Flag is blue and you give it to a green player, the Flag will stay blue but still belong to the green player. Strange, huh?

Hmm, I'll have to test that at some point.

That reminds me though of two discoveries I found involving player properties:

Any unit given to the neutral player (P12), either by triggers or from someone dropping the game, will retain their original alliance status and color (not on the minimap, though). Thus it is possible to have player 12 own seperate sets of units with completely different coloration and alignment settings. Further, any units given to P12 from a player still in the game will share that player's alliances even if they are changed!

Units created for players without start locations or those who have dropped from the game (players 1 - 8), A.K.A "zombie" units, will always be hostile, and unable to be affected with triggers actions.

I think that last one may need some more research, though. That was a long time ago that I discovered that, but I only made it as a casual observation rather than a thourough test, so I may be outright wrong even.

P.S.Isn't proedit compromised now? This'll probably need to be edited, Yoshi. Remember these are the first things people see when they come to this page, so I'd think accuracy and correctness would be essential.

It is correct. And it does prevent people from removing your credit and hard work. Just like it says. so does GUedit, and SCM Toolkit.

Not everyone has a unprotector and not everyone can unprotect Proedit with the new utility no one has told me about. It just doens't prevent ALL people from unprotecting it.

To protect your map so NO ONE can ever unprotect it. Select the map in windows explorer and press the delete button. (not a serious suggestion)

I've tested that "Zombie" units thing extensively over the years, Omega. It's true, they can't be effected by actions. Even removing all units for all players won't affect 'em. I just ran into this problem yesterday, in fact. I'm not sure if they can be used as conditions, however...

I can't remember if someone has done this one yet;

If you set a trigger for a Force with more than one player in it, even if they are not present within the game, and set to create a unit, just 1, it will create 1 for every single player, (and often make another so it ends up as 2)

I seriously need to see a test map to believe that. You're saying triggers for a force of players that have none actually in the game will activate for all players?

That IS possible, but it would depend on whom activates the trigger and who the units are created for. If I tell it to create for All Players, it's obviously going to do that.

Bah what am I thinking, of course you can't activate triggers for players not in the game. I think I understand now. Yes, I believe that was already posted.

EDIT- Clarification: the tip about creating units for forces/all players is what I'm refering to, if that's what YOU were refering to. But what you said was just plain wrong about making units for all players, unless I'm misunderstanding something.

Yoshi, you better not post this one.

I don't even see how that helps you. I'm going to post these all again soon!

To prevent computer units from burrowing, you can do a few things. You can give them to player 12 at the onset, thought they will no longer be able to attack unless given back. You can disable burrowing for the player, if you don't need it. You can constantly order them to patrol in place in their location. Finally, you can disable them (so long as the unit won't crash or you don't mind some possible weird effects).

I probably forget a few, and I'm not sure about disabling offhand, but someone asked about that so I think it'd be a good tip in general.

What, i think i meant that it will create one for each of the player within that force, which i think was already present, however it didn't make sense to you guys, so its not every player, rather the players within that force.

Here is one; If you set Transports to Junk Yard Dog, they will go around picking up units and dropping them randomly. As long as they are on their team, IE Player 1 Transport picks up Player 1 Units.

Createing a trigger owned by a force is exactly the same thing as createing the exact same trigger for each of the players in that force.
So of course its going to create extra units, because you have multiple copies of the trigger. One that runs for each player.

Thats what i meant, but some people get confused when it happens. The second one is correct though, i tested it. Its most interesting, funny to watch as well!

Don't steal other peoples work!

-If you use a computer AI script, the computer won't use resources to make buildings/units. Instead, the computer just makes the unit, even if it costs, and even if they have no resources.

^-- Not sure if it works for all AI's, I only tested with Expansion Protoss Insane AI.

Certain AI Scripts give money to them. They won't show in trigger for conditions or anything, but the money is there. Save a replay and check it. They're probably spending that "hidden" cash.