Ugh... I don't know where it went, I must of erased it when I wiped my computer last time..

Ugh... I don't know where it went, I must of erased it when I wiped my computer last time..

I have it. Trying to find it right now actually. http://www.staredit.net/files/447/ http://www.staredit.net/files/446/ I forget which one is the mario one.

I have it. Trying to find it right now actually.

http://www.staredit.net/files/447/
http://www.staredit.net/files/446/

I forget which one is the mario one.

"B" is Mario "Z" is Maze I remember he showed 1 other person at the time he showed me those 2 maps, I think it was you urmom- I'm glad you still have them. The first 30 seconds of the maze map I had no idea what I was looking at... I just thought it was random color changes- until he pointed out it was the 3d maze... then it all came together.

"B" is Mario
"Z" is Maze

I remember he showed 1 other person at the time he showed me those 2 maps, I think it was you urmom- I'm glad you still have them.

The first 30 seconds of the maze map I had no idea what I was looking at... I just thought it was random color changes- until he pointed out it was the 3d maze... then it all came together.

At the end of the maze it said "coming soon" or "coming 2006" or something like that, did he mean the conversion program?

At the end of the maze it said "coming soon" or "coming 2006" or something like that, did he mean the conversion program?

Only 2095 triggers in that maze one, a-mazing. :P

Only 2095 triggers in that maze one, a-mazing.

[quote=name:razorsnail]At the end of the maze it said "coming soon" or "coming 2006" or something like that, did he mean the conversion program?[/quote] I don't think so- because he used the program to make the map and he was strongly against releasing it publicly. I really wish I could remember his name, I am pretty sure Fred_E was his old account he no longer used.

Quote from razorsnail

At the end of the maze it said "coming soon" or "coming 2006" or something like that, did he mean the conversion program?

I don't think so- because he used the program to make the map and he was strongly against releasing it publicly. I really wish I could remember his name, I am pretty sure Fred_E was his old account he no longer used.

I wonder if you could get higher definition using smaller units.. Maybe the lag was too bad.

I wonder if you could get higher definition using smaller units.. Maybe the lag was too bad.

I don't know if this works for everyone but if you hold the 'tab' button down it will constantly refresh the minimap to overcome any 'lag' problems.

I don't know if this works for everyone but if you hold the 'tab' button down it will constantly refresh the minimap to overcome any 'lag' problems.

Game lag, not minimap lag, and holding it down didn't speed anything up for me, probably because the movie was not made at a higher framerate though.

Game lag, not minimap lag, and holding it down didn't speed anything up for me, probably because the movie was not made at a higher framerate though.

[quote=name:Falkoner]Only 2095 triggers in that maze one, a-mazing. :P[/quote] How do you count the number of triggers in it? [quote=name:Falkoner]I wonder if you could get higher definition using smaller units.. Maybe the lag was too bad.[/quote] You probably would get higher definition, since smaller units appear as smaller squares on the map. But, you might reach the unit limit. EDIT: If anybody understands how the triggers in that map work, can they please explain it to me.

Quote from Falkoner

Only 2095 triggers in that maze one, a-mazing.

How do you count the number of triggers in it?

Quote from Falkoner

I wonder if you could get higher definition using smaller units.. Maybe the lag was too bad.

You probably would get higher definition, since smaller units appear as smaller squares on the map. But, you might reach the unit limit.

EDIT: If anybody understands how the triggers in that map work, can they please explain it to me.

[quote=name:stickynote]EDIT: If anybody understands how the triggers in that map work, can they please explain it to me.[/quote] Here's my explanation for the triggers in Minimap-Show-4x3-Z.scm. I know it's long. Tell me to clarify if something's vague. Custom score is the counter. Player 8 adds 1 to it every trigger cycle. Ore and gas is just for the benefit of the players (or maybe the mapmaker), to see how much time has elapsed. [b]Player 6 is the "blank" or "neutral" player[/b], and [b]Player 4 is the "primer" player[/b]. The "Terran Marine" death count is used to give sections of the screen from Player 6 to Player 4 in preparation for the animation. Every time a cannon is given to any player in order to display that player color on the minimap, it was given FROM Player 4, unless it was Player 6 or Player 4, which are also used in animation. This is probably because Player 4 appears as the green floor and walls and makes up most of the movie, and Player 6 is a lot of the walls. Therefore, most of the other players are merely subtractions or cuts into the large blocks of color made up by Players 4 and 6. [color=#CE091D]MAIN TRIGGER[/color] (owned by "All Players", the one with Condition 'Current Player's Custom score is exactly X') For each second... [color=#DFA51C]1.[/color] Set specific Terran Marine Death Count [color=#DFA51C]2.[/color] Set List of Death Counts that will display animation. Starts with Zerg Zergling. [color=#86EE59]Here's what happens in each cycle (each new custom score):[/color] [color=#DFA51C]1.[/color] All cannons are given to Player 6 to "wipe" the screen. [color=#DFA51C]2.[/color] The necessary sections of the screen are given to Player 4, according to the proper Terran Marine Death Count. These are the "active sections" -- the ones that will be part of the display. For example, '33554432' for Terran Marine will give the first two columns of cannons (called 'Scan 0') to Player 4 in preparation for the Display. [color=#DFA51C]3.[/color] The Display information starts: [color=#81A7EF]a.[/color] the first Death Count is checked. For example, '306783379' for Zerg Zergling for Player 1. The first applicable trigger is Force 2's 'Current Player has suffered 268435456 deaths of Zerg Zergling'. This gives one cannon owned by Player 4 to a certain player (in this case, Player 9), updating the minimap display. Since all of Player 4's cannons are currently in the first two columns, it will give one cannon in the first column to Player 9. The applicable Death Count is wiped (exception: see Note below). [color=#81A7EF]b.[/color] the next Death Count is checked, and it goes through a similar process as above. This continues until all the remaining Death Counts have been checked for that cycle. [color=#EBEE80]Note:[/color] The triggers with Death Counts as conditions are arranged in descending order. The only exception to this is triggers giving cannons to Player 1 always have ranges as conditions (e.g. 'at least 1 and at most 268435455 deaths of zerg zergling'). This accounts for the little red blip that stays there at the top left of the map. Not sure what it's for. Looking through the triggers, at first it may seem like there are not enough Give actions to account for the large swathes of color that occur in the animation, but it's because the Give actions update faster than the minimap does, so you get multiple Give actions in before the minimap updates. Of course, the question is how he decided which death counts would apply to which Give operations, but as Joker47 said, he had a program for that. Since most Give operations are probably used many times throughout the movie, most of the operations are recycled. As for why he fills up each main trigger with 'Modify death counts for player 8: set to 0 for terran marine', I'm not really sure. Maybe they're placeholders. My guess is it had something to do with the generation of the triggers through his own program and don't really have any effect on the behavior of the map.

Quote from stickynote

EDIT: If anybody understands how the triggers in that map work, can they please explain it to me.

Here's my explanation for the triggers in Minimap-Show-4x3-Z.scm.
I know it's long. Tell me to clarify if something's vague.


Custom score is the counter. Player 8 adds 1 to it every trigger cycle. Ore and gas is just for the benefit of the players (or maybe the mapmaker), to see how much time has elapsed.

Player 6 is the "blank" or "neutral" player, and Player 4 is the "primer" player. The "Terran Marine" death count is used to give sections of the screen from Player 6 to Player 4 in preparation for the animation. Every time a cannon is given to any player in order to display that player color on the minimap, it was given FROM Player 4, unless it was Player 6 or Player 4, which are also used in animation. This is probably because Player 4 appears as the green floor and walls and makes up most of the movie, and Player 6 is a lot of the walls. Therefore, most of the other players are merely subtractions or cuts into the large blocks of color made up by Players 4 and 6.



MAIN TRIGGER (owned by "All Players", the one with Condition 'Current Player's Custom score is exactly X')

For each second...
1. Set specific Terran Marine Death Count
2. Set List of Death Counts that will display animation. Starts with Zerg Zergling.



Here's what happens in each cycle (each new custom score):

1. All cannons are given to Player 6 to "wipe" the screen.

2. The necessary sections of the screen are given to Player 4, according to the proper Terran Marine Death Count. These are the "active sections" -- the ones that will be part of the display. For example, '33554432' for Terran Marine will give the first two columns of cannons (called 'Scan 0') to Player 4 in preparation for the Display.

3. The Display information starts:
a. the first Death Count is checked. For example, '306783379' for Zerg Zergling for Player 1. The first applicable trigger is Force 2's 'Current Player has suffered 268435456 deaths of Zerg Zergling'. This gives one cannon owned by Player 4 to a certain player (in this case, Player 9), updating the minimap display. Since all of Player 4's cannons are currently in the first two columns, it will give one cannon in the first column to Player 9. The applicable Death Count is wiped (exception: see Note below).

b. the next Death Count is checked, and it goes through a similar process as above. This continues until all the remaining Death Counts have been checked for that cycle.


Note: The triggers with Death Counts as conditions are arranged in descending order. The only exception to this is triggers giving cannons to Player 1 always have ranges as conditions (e.g. 'at least 1 and at most 268435455 deaths of zerg zergling'). This accounts for the little red blip that stays there at the top left of the map. Not sure what it's for.

Looking through the triggers, at first it may seem like there are not enough Give actions to account for the large swathes of color that occur in the animation, but it's because the Give actions update faster than the minimap does, so you get multiple Give actions in before the minimap updates.


Of course, the question is how he decided which death counts would apply to which Give operations, but as Joker47 said, he had a program for that. Since most Give operations are probably used many times throughout the movie, most of the operations are recycled.

As for why he fills up each main trigger with 'Modify death counts for player 8: set to 0 for terran marine', I'm not really sure. Maybe they're placeholders. My guess is it had something to do with the generation of the triggers through his own program and don't really have any effect on the behavior of the map.

Another thing i noticed was that he put conditions that said Always and Never in the same trigger. What does 'never' do, exactly.

Another thing i noticed was that he put conditions that said Always and Never in the same trigger. What does 'never' do, exactly.

'Never' means the trigger will never run. I'm guessing he was playing around with the number/placement of hyper triggers. Instead of deleting one, he just put 'never'. I sometimes do that too, instead of deleting the trigger, so I can remember what I was thinking before or what I tried before. That way I won't have to make the same mistake twice or go through the process of remembering what I did. Maybe he had different reasons, I don't know.

'Never' means the trigger will never run. I'm guessing he was playing around with the number/placement of hyper triggers. Instead of deleting one, he just put 'never'.

I sometimes do that too, instead of deleting the trigger, so I can remember what I was thinking before or what I tried before. That way I won't have to make the same mistake twice or go through the process of remembering what I did.

Maybe he had different reasons, I don't know.

That's about the only use for the never condition.

That's about the only use for the never condition.

That's what I thought it did, but when he put always and never in the same trigger, I got confused. I thought that maybe the never condition might also do something else. Isn't it easier to just delete the trigger?

That's what I thought it did, but when he put always and never in the same trigger, I got confused. I thought that maybe the never condition might also do something else. Isn't it easier to just delete the trigger?

[quote=name:stickynote]What does 'never' do, exactly.[/quote]I've actually looked at the code... 'Never'[i] just [/i]returns False. Always/No Condition just return True.

Quote from stickynote

What does 'never' do, exactly.

I've actually looked at the code... 'Never' just returns False. Always/No Condition just return True.

SC keeps checking the conditions until one of them return false. After that it stops checking them and continues with the next trigger. I was wondering some days ago if you could significantly reduce the lag of some maps if you put the conditions that are more likely to return false on top of the conditions list.

SC keeps checking the conditions until one of them return false. After that it stops checking them and continues with the next trigger.
I was wondering some days ago if you could significantly reduce the lag of some maps if you put the conditions that are more likely to return false on top of the conditions list.

Why would that reduce lag? It still has to run through them, false or no, no matter where you put them.

Why would that reduce lag? It still has to run through them, false or no, no matter where you put them.

[quote=name:Clokr_]SC keeps checking the conditions until one of them return false. After that it stops checking them and continues with the next trigger. I was wondering some days ago if you could significantly reduce the lag of some maps if you put the conditions that are more likely to return false on top of the conditions list.[/quote] Yeah, see, this is what I always wondered about using exact conditions. Example: You want CP's Zergling deaths to always be reduced to 0 if the current player has at least 100 ore and has killed at least 1 marine. If a condition returns false, then SC won't check the subsequent conditions. So if you say, C: CP suffers at least 1 death of Zergling. C: CP accumulates at least 100 ore. C: CP has killed at least 1 Marine. A: Set deaths for CP: Set to 0 for Zergling. A: Preserve trigger. If CP has 100 ore and has killed a Marine, but has suffered no deaths of Zergling, it won't need to run the second or third conditions. Therefore, less lag. The other way would be this: C: CP accumulates at least 100 ore. C: CP has killed at least 1 Marine. A: Set deaths for CP: Set to 0 for Zergling. A: Preserve trigger. In this case, if CP has 100 ore and has killed a Marine, the trigger will always run, thereby increasing lag. So presumably, if you include the deaths condition, SC will return false quicker and eliminate the lag caused by the trigger.

Quote from Clokr_

SC keeps checking the conditions until one of them return false. After that it stops checking them and continues with the next trigger.
I was wondering some days ago if you could significantly reduce the lag of some maps if you put the conditions that are more likely to return false on top of the conditions list.

Yeah, see, this is what I always wondered about using exact conditions.

Example: You want CP's Zergling deaths to always be reduced to 0 if the current player has at least 100 ore and has killed at least 1 marine.

If a condition returns false, then SC won't check the subsequent conditions. So if you say,

C: CP suffers at least 1 death of Zergling.
C: CP accumulates at least 100 ore.
C: CP has killed at least 1 Marine.
A: Set deaths for CP: Set to 0 for Zergling.
A: Preserve trigger.

If CP has 100 ore and has killed a Marine, but has suffered no deaths of Zergling, it won't need to run the second or third conditions. Therefore, less lag.

The other way would be this:

C: CP accumulates at least 100 ore.
C: CP has killed at least 1 Marine.
A: Set deaths for CP: Set to 0 for Zergling.
A: Preserve trigger.

In this case, if CP has 100 ore and has killed a Marine, the trigger will always run, thereby increasing lag.

So presumably, if you include the deaths condition, SC will return false quicker and eliminate the lag caused by the trigger.

Oh! I thought you said TRIGGERS at the top, okay, this makes a lot more sense, I bet it would help, maybe not in one or two triggers, but I bet in maps with thousands of triggers with conditions like that if you put the conditions right, I bet you could speed things up.

Oh! I thought you said TRIGGERS at the top, okay, this makes a lot more sense, I bet it would help, maybe not in one or two triggers, but I bet in maps with thousands of triggers with conditions like that if you put the conditions right, I bet you could speed things up.