I am trying to create a map and for some reason half of my triggers aren't working and I am unsure of what I need to do to resolve this problem. I have tried pretty much everything , but it doesn't seem to work. Here are pictures of my current triggers
The melee AI scripts are only meant to be executed once when needed. At the moment, P5 and P6 are instructed to run the Insane AI Script, but you have also included an unneeded [Preserve Trigger]. This is causing the computer to re-run its script with each trigger-cycle and may be confusing the computer's build order.
The computer expects the AI script's location to be positioned directly on its main base. The "Center" is determined by the center of the location you use in the trigger-action.
For example, P5 currently has [Trigger-Action: Execute AI Script 'Expansion Zerg Campaign Insane' at 'ZERG SPAWN']
The computer will then assume its main base is located at the center of location 'ZERG SPAWN'.
However, your location, 'ZERG SPAWN' streches the entire map with its center hovering somewhere close to where P4-Purple is located. This may also be confusing the computer. Place the computer AI locations on top of their main bases. The size of the location is not an issue so long as the location's center is on top of the main base.
This issue applies to P5 and P6 since their locations span the entire area of the map
P6 is currently running [Trigger-Action: Execute AI Script 'Expansion Terran Campaign Insane' at 'PROTOSS'].
Re-edit P6 to use 'Expansion Protoss Campaign Insane'.
I am unsure why you have decided to make the AI locations as large as they are (as stated above). If I may make a guess, I would assume you were intending the computer AI to see the entire map as its "base" and thus secure new resource positions.
If this was your reasoning, you need not to worry. The Insane Scripts are already programmed to secure additional resource positions in a manner similar to human players.
* * * Timed Messages * * *
You have created several triggers to display messages at certain points in time during the game.
For many of these triggers, you used [Trigger-Condition: Elapsed Time is EXACTLY NN game seconds].
The idea is correct, however, Starcraft's trigger system does "check" its triggers as fast as we sometimes want it to (unless you implement a Hyper-Trigger System). Your trigger design must be able to display the message even if the trigger "check" comes late even by a second or two.
Luckily, since the time elapsed only goes up, we can be sure that if the current time is equal to or greater than the time a certain message is supposed to appear, the trigger displaying this message should activate.
Changing the EXACTLY time-conditions to AT LEAST should ensure the messages are shown even if Starcraft's trigger "check" (trigger-cycle) arrives too late.
"2 MINUTES UNTIL GAME OVER" [All Players]
"1 MINUTE UNTIL GAME OVER" [All Players]
End Scenario in Draw after 50 minutes [All Players]
Add 2000 ore and gas at 1500 seconds + message [Force 1] (You could probably combine these two triggers into one)
Add 2000 ore and gas at 2700 seconds [Force 1]
"5 MINUTES UNTIL GAME OVER, 2000 ORE+GAS ADDED!" [Force 1] (This trigger could probably be combined with the one above)
* * * Never-Condition Triggers * * *
I have noticed Force1(Humans) and Force2(CPU) own a few triggers with the condition:Never.
In Force1: Never => Set Current Player to Ally // Never => Set Current Player to Allied Victory
In Force2: Never => End Scenario in Victory // Never => End Scenario in Defeat
Be sure not to confuse Condition-Never as meaning "Never let this happen".
For example, even though Force2 has [Never => End Scenario in Defeat], Force2 is still capable of being defeated. The Never-Trigger does nothing.
Every Trigger-Condition can be either 'True' or 'False'. As an example, [Trigger-Condition: Elapsed at least 20 game seconds] is a 'False' condition if the game has been active for only 10 game seconds. If the game has been active for 20 game seconds or more, this same Trigger-Condition is a 'True' condition.
A trigger activates when it has absolutely no 'False' Trigger-Conditions. (In other words, there are exactly ZERO 'False' conditions)
[Trigger-Condition: Always] will always be a 'True' Condition.
[Trigger-Condition: Never] will always be a 'False' Condition.
A trigger with only the Always() condition has 0 'False' conditions and will activate upon the next trigger "check".
A trigger with only the Never() condition has 1 'False' condition and will never activate since Never() will never be a 'True' condition in any situation.
A trigger with both conditions, Always() AND Never(), will not activate because one of its two conditions is 'False'.
The Never() condition is useful for experimentation when you need to temporarily disable a trigger without going through the trouble of deleting it.
However, if used in a "serious" manner, any trigger with the Never() condition is no different than a deleted trigger, since it will never activate.
* * * Bonus Resources * * *
As seen in the *Timed Messages* section, the map grants extra resources at certain points in time during the game.
From +2000 ore&gas trigger: [Trigger-Action: Modify Resources for 'Force 1': Add 2000 ore and gas]
However, this trigger is owned by 'Force1' instead of a specific player.
Giving a trigger to an entire Force can be seen as an easy way of copy/pasting that trigger to every player in that force.
If there are two people (P1 and P2) who play as Force1; both players will have a copy of this trigger. But that also means, this trigger will run TWICE.
When P1 runs this trigger: Force1(P1 and P2) will get +2000 ore and gas
When P2 runs this trigger: Force1(P1 and P2) will get another +2000 ore and gas
This totals to a 4000 ore+gas bonus.
To resolve this issue, give the ore+gas bonus to only the 'Current Player' running the trigger.
[Trigger-Action: Modify Resources for 'Current Player': Add 2000 ore and gas]
When P1 runs this trigger: Current Player(P1) will get +2000 ore and gas
When P2 runs this trigger: Current Player(P2) will get +2000 ore and gas
* * * Testing in SinglePlayer * * *
One of the triggers declares victory for Force1 if there are at most 2 opponents in the game.
There are also exactly 2 computer opponents in this map.
If you have been testing this map in multiplayer with a friend, there should be no problems.
However, if you have been testing this map in single-player mode (the one with cheats), you would get automatic victory since you only have "at most" 2 opponents. (In my own testing (single-player cheat-mode), the Victory box does not appear because the [Preserve Trigger] is constantly declaring victory. Removing [Preserve Trigger] allows the Victory Box to appear. This is not an issue if playing in multiplayer)
If you do intend to test something on this map in single-player mode (the one with cheats), you may want to temporarily disable this trigger.
2. Re: How can I fix my map triggers? 07/30/2012 12:47:48 AM PDT
Thank You for the Reply I have been waiting months for a good reply and finally I got one! I edited the map like you said and tomorrow I am going to test the map out (hopefully) with my friend. Well thanks again Oh and the Big location for the zerg spawn was so the zergs would control the outer edges of the map. So what I did instead was set the zergs location to "Anywhere".
[ Post edited by Radical924 ]
Check out my youtube channel here:
3. Re: How can I fix my map triggers? 07/30/2012 12:23:18 PM PDT
The "Anywhere" location is identical to a large location spanning the entire map.
It is essentially the same as the super-large locations that were originally used.
Melee scripts are not concerned with the size of the location. The only information they need is the position of the location's center (where they should establish their main base). Since "Anywhere" is identical to the super-large locations you had used earlier, the Zerg computer will try to establish its main base in the water next to P4-Purple.
The melee AI script decides the size of the area it considers its base. For example, I assign melee AI scripts to locations that are barely larger than a hatchery. Obviously, the computer does not attempt to squish everything into the tiny spot. Likewise, assigning a huge location does not mean the computer will try to make its base just as large. The only useful information the melee AI needs is the position of the location's center.
But there is a much more suitable approach to your desired computer behavior. Blizzard has also included specialized AI scripts such as "Value This Area Higher". This script is designed to be used alongside the typical melee scripts such as the Insane AI. When used, the melee computer will mark the areas covered by "Value This Area Higher" as 'special' and will attempt to keep it safe from enemy control.
The computer will hold onto the area as long as it believes it has a fighting chance at it. If you take over the area and set up a Mega-Wall-Of-Death around it, the computer will not send its reinforcements on a suicide mission.
Remember, the position of the location's center is the useful information. Put the Insane Zerg AI location on whichever of the two bases you want to pick as its main. Have maybe 12 locations in a loop around the map's perimeter cliff-side (3 per side: 3 North, 3 West, 3 South, 3 East). Run "Value This Area Higher" on all 12 of such locations.
Additional Info on "Value This Area Higher": I haven't experimented much with this AI script. Though, from my distant memory, I recall a few aspects of it.
#1: Location-size with this script may have some merit. I remember seeing varying unit distributions depending on the size of the valued area. But please don't use "Anywhere" or some large location spanning the whole map for your situation. You'll end up with the computer trying to defend spots around the center of the map rather than defending the perimeter cliff-sides.
#2: Computers can get "bored" of a valued spot if there isn't much enemy traffic going through it. Computers may stop sending its units there if there's nothing interesting going on. The computer may renew interest in the spot if you send a few of your own forces to the spot.
##: This is based on my observations from very long ago. I do not know if the script behavior has changed since the last few Starcraft patches. I do not have an up-to-date analysis of this script unless I start new experiments with it, or unless another mapmaker offers their observations.
* * * *
I had forgot to mention in the first post about burrowing: pre-placed burrowed units do not start off burrowed unless the unit already has the ability researched/available.
You may want to give the computer Zerg the benefit of having the burrowing ability pre-researched.
* * * * * *
Have you tried posting for map-help on other Fan-made Starcraft websites such as StarEdit.net?
4. Re: How can I fix my map triggers? 08/12/2012 04:46:03 PM PDT
Naw I haven't tried posting to other websites like staredit but I am going to try using the scripts you mentioned. My only question is if the scripts can be set to activate at a random start location like in another map I was editing.
Here are links to both maps updated to August 12th 2012:
The setup of these two maps are quite different from each other, so I am not sure what you truly mean by "random start locations".
I don't quite see how the computers would be randomized in 'Radical Jungle'. They each only have one ideal base location.
If you wanted the AI Script to execute on either one or another location, you could make use of switches.
Randomize a switch. If the switch comes out 'Clear', execute the AI Script at Location#1. Otherwise, execute the AI Script on Location#2. (This assumes location#1 and location#2 both cover different spots the computer could immediately use for its main base)
You can use this basic setup to have a computer, which has multiple bases, to choose one at random as its main base.
The idea of start-location randomization on your edited 'Station Unrest' is a bit fuzzy because (as of your August 12th update) there isn't a randomizing system for the computers yet.
Currently, you have 6 humans randomized and 2 computers randomized. Humans and computers are in separate forces.
A problem arises in the separation of the Forces:
* * * Randomized Start Locations * * *
#1: Start Locations under a certain Force are only randomized with other locations in the same Force.
#2: Of the locations specified in #1, players of pre-selected species only randomize with the start locations of other players that have pre-selected species.
Likewise, players which have 'User selectable' species are only randomized with the start locations of other players that have 'User Selectable' species.
Example of #2: Your two computers are pre-selected species: P5-Zerg and P6-Protoss. Their locations are randomized only with each other since they are the only two players in Force2. If we inserted a human player (Species: User Selectable) into Force2, P5 and P6 would still only randomize their start locations between each other while the new human user-select-species player would always start in the exact same spot (there is only one spot to choose from since there are no other user-select-species players in the Force). Pre-selected-species players only randomize with other pre-selected-species players. User-Select-species players only randomize with other User-Select-species players.
As a result, the computers in your 'Station Unrest' only have 2 spots to choose from when they pick their "random" spot. This isn't really helpful since, by this system, we would always know that the two computers start at the same two spots every game.
I am guessing you intended for the computers on this map to be randomized along with the human players in a manner similar to regular melee games. Doing this through UMS, however, would require resolving the issues presented in #1 and #2.
Solving #1: Since players may only be randomized with other players of the same force, we cannot have the humans and computers separated into different forces if they are supposed to be randomized together.
The humans and computers must be combined into the same Force.
Solving #2: Even after combining the humans and computers into the same Force, they're pool of randomized-locations are still separate because User-Selectable-species do not mix with pre-selected-species.
We can't turn the human players into pre-selected species because it would go against your game design.
The computers must be turned into User-Selectable species instead of being pre-selected (P5-Zerg and P6-Brown).
As a consequence, P5 and P6 will be a random species when the game starts since "Random" is the default choice for User-Selected species.
An even greater consequence of using the solution above is that the triggers for this map would need to be completely re-written. Your triggers, which have been originally split between Force1 (Humans) and Force2 (Computers), would now have to be squashed into a single Force. On top of that, the triggers would have to know whether the player was a human or computer and activate/skip itself depending on whether the trigger was meant for a human/computer player.
But the reward for doing so would give you a map that randomizes its players very much like the way a real melee game randomizes ALL of its human and computer players together.
If you feel this solution is worth the effort I can provide you with a head-start.
* * * * * * *
I have created a quick implementation of the above solution into 'Station Unrest' and uploaded it to Mediafire.
StarEdit, which comes installed along with Starcraft, will not allow you to save the map with Humans and Computers in the same Force. You will require another editor to save any work.
I will eventually delete this file from mediafire.
I have disabled the trigger that grants victory upon having two opponents or less. This is to allow you to run the map in SinglePlayer so as to use 'black sheep wall' and observe the computer's randomization.
If you choose to, you can use this version as a starting block and continue building up the map.
You would, however, have to familiarize yourself with these new sets of triggers in order to add to it.
* * * Version Notes:
- I have interpreted the (currently disabled) trigger which grants victory upon having two opponents or less as meaning, "Victory if there are no other human players left" (the two last opponents being the computer). Consequently, I have rewritten the trigger to reflect this.
- Computers will run the appropriate AI script of their species at their appropriate base location. The trigger first finds the location of its base on the map, and runs the AI script depending on which building it finds (Hatchery/Command Center/Nexus)
- There was a flaw in the design of the trigger which imposed defeat upon any player that continued playing without a base for over 60 seconds.
The error was that it was all condensed into the same trigger:
'You have 1 minute'; wait 30secs; 'You have 30 seconds'; wait 30secs; defeat()
Triggers do not re-check whether their conditions are still true in-between waits. As a result, even if the player had begun building something, the trigger would continue counting down 60 seconds then eliminate the player.
The trigger has been rewritten using a death-counter-clock which re-checks for new structures at specified time intervals and stops/resets the clock when a new structure is found.
- Forced un-ally: triggers will detect any human-player alliances and un-ally them automatically. I do not know for sure if this is what you intended. If not, you can remove the triggers.
- All 8 Player slots are usable. The 8th player P8, originally excluded from the game solely to run hyper triggers, has been converted into a regular player. Hyper triggers are now processed by every player in the game.
* * *
I have only tested some of the triggers in this edited version.
- Computer start-location randomization and AI Script execution
- Forced unally
- 1-Minute Base-Rebuild warning/countdown
- Victory when no human opponents (currently disabled)
- Defeat after losing 200 men
Everything else remains untested.
[ Post edited by Fishinspace ]
6. THANK YOU FOR ALL THE HELP!!!!!!!! 08/16/2012 11:57:01 PM PDT
Hey man thank you for all of the time and energy you put into helping me with my map. I feel bad because I found out most of this stuff on my own at staredit.net like you suggested earlier. Sorry. But anyways I mentioned you in the map comments.
I have it changed so cpus respawn after they are killed around 2 and a half minutes later. If the spawn is blocked then they wont spawn which I like.
Here are some things I don't know how to fix or add in:
1. I do not know how to force allies on players w/o using death counters.
2. This version also doesn't remove units that players leave behind when they leave the game unfortunately.
3. This version does not have the fix for 200 deaths of men by more than one player.
4. I'm not sure if I should do this but if I changed the randomization switches to force 2 would this be better? At the moment all triggers pretty much affect the current player and I was thinking maybe it would be better if the triggers affected the force? Then it would be very simple to change the amount of computer players vs human players.
5. I do not know how to make a trigger to disable the computer from winning or losing as a backup in-case other triggers present bugs I don't know about.
Any of this things you are welcome to fix or any suggestions are welcome.
Here is the map in its current state: https://rapidshare.com/files/2334874252/Jungle World TEST NEW MUSIC.scx
THANKS AGAIN B/C ALL OF THIS WOULDN'T HAVE HAPPENED IF IT WASN'T FOR YOU LOL
PS: I know how to compress my map now (I know to keep a backup) and import new terrain into the map. So I can import terrain from other maps and just move the locations and that's it XD
[ Post edited by Radical924 ]
Check out my youtube channel here:
7. Re: THANK YOU FOR ALL THE HELP!!!!!!!! 08/18/2012 12:47:53 AM PDT
Not sure why you are avoiding death counters, but if it suits you, the BRING condition should be good enough.
The player running the trigger can detect ally units if such units belong to "Allies" or "Neutral Players". There is a difference between the two, as well.
# Bring ["Allies"] at least 1 unit to "Anywhere"
This trigger-condition detects ally units when the player has [ALLIED VICTORY] enabled.
# Bring ["Neutral Players"] at least 1 unit to "Anywhere"
This trigger-condition detects ally units when the player does NOT have [ALLIED VICTORY] enabled.
If either of these two triggers activate, you may assume that the player owning the trigger has allied another player and you may add trigger-actions to resolve it.
(Modified Map File at end of Post)
* * * Neutral Units * * *
Neutral units are owned by Player-12. In ScmDraft, Player-12 is renamed "Neutral", not to be confused with "Neutral Players".
You can use a trigger to detect such units owned by "Neutral" and eliminate them.
When designing the trigger, you should note:
#1: Your trigger should belong to a player that is "in the game". Defeated players cannot run triggers. Player-12 cannot run triggers either.
#2: Do not be tempted to use Trigger-Action:[Remove [any unit] owned by "Neutral"].
Mineral fields and Vespene geysers are also "units", and having them disappear may not be your intent.
Remove [men] and [buildings] instead.
Combining the Player-7&8 triggers into Force2 should work fine. You can give it a try and see if everything turns out ok.
Though, the operation of the computer's base randomizer worries me in some aspects.
1. By its current design, it picks a random start location and builds a base there if it is unoccupied. If it "misses" (picks an occupied area) it will not spawn. However, since the respawn timer resets for another 2.5 minutes, the computer's respawn could be delayed for long periods depending on its chances of "missing" unoccupied spots. If this is intended, then all is well. If there are very few "open" spots left, the computers will have a hard time "landing" on it with pure chance.
I would suggest having the computers pick a random spot out of the remaining "open" spots to guarantee its respawn if an open spot exists. But, as said before, I do not know your intention.
2. Currently, the respawn triggers that actually create the base do not check whether or not it is actually the correct time for the computer to respawn. The switch randomizer obeys the 2.5 minute rule, but the spawner triggers are not bound to it.
As a result, this leaves a strange side effect regarding base spawns.
Consider the theoretical situation:
A player manages to eliminate a computer. The switch randomizer picks spot#3 and respawns the computer there.
Another player sees the respawn and sends 666 nukes to it. In less than 2.5 minutes, the computer is defeated again.
At this point, the switch randomizer does not activate. The randomizer is still fixed at spot#3.
However, the spawn triggers are not bound to the 2.5 minute rule.
When the nuclear apocalypse passes, the respawn-system will find that spot#3 is once again empty.
Since the randomizer is still fixed at spot#3, the respawn-system will then respawn the computer almost instantly among the ashes of the inferno.
This side-effect can be confirmed by using triggers as a substitute base-killer.
Run this map in single player a few times. You can observe simulated computer obliterations.
Obliterations begin AFTER 10 seconds, when the auto-randomizer stops auto-randomizing switches.
You will need to redesign the system so that the respawn-system also obeys the 2.5 minute rule.
3. There is one final theoretical scenario in need of full-proofing. The issue is Zerg Creep.
Zerg Creep prohibits Terran and Protoss buildings from being placed upon it.
If the randomizer picked an "open" spot covered with Zerg Creep. The respawn-system would fail to spawn the building, but succeed in spawning workers.
You may want to split the trigger which creates the structure from the one that creates the workers.
If the first trigger (create structure) is successful, THEN create the workers. Otherwise, pretend the area is occupied.
The map files below have not altered the computer-base randomizing system.
The following file implements Forced-Unally and Removal of defeated player-units
This file is identical to the one above, except for WAV-Sounds
I have edited the audio files because I found them somewhat inaudible.
If you want, you can check the WAV files in this map and use them if you find any to be suitable.
The modified WAV-files have had however much audio-quality trimmed to closdly match the file-size of their original counter-parts
All three file links will be deleted eventually.
8. Re: THANK YOU FOR ALL THE HELP!!!!!!!! 08/18/2012 11:38:19 AM PDT
Ok I like what you did with the sound files and I understand the triggers you added. What I meant about death counters not being added was I don't understand how to use death counters myself so that's why I prefer not to use them if possible BUT if it is easier to use them I would prefer that.
Also what I meant about the 200 deaths was a suggestion I thought I read here. It said that a problem with my 200 deaths to lose was that a player can have units killed by more than one player and accumulate 200 deaths fast. The suggestion was to separate the deaths a player receives into the deaths a player receives from each player and if either of the death counts went to 200 then the player would be defeated. This would exclude the computer in the triggers as they are not supposed to lose. However, a player can accumulate 200 deaths by the computer and lose and if only 2 humans were in the game then the other human would claim victory. (I do not know if 200 deaths by one player is a great number in all situations but I think it would still be a good number of deaths to lose by)
Thirdly, I am not sure how I would fix the issue with CPU's choosing to spawn at an occupied space even if other spaces are unoccupied. I thought I already fixed this sadly but from what you are telling me apparently not....-_- I thought that the condition that " All players brings exactly 0 "any unit" to spawn location 1-8" would fix this issue. Oh and I just noticed that the player who helped edit my randomized system changed the condition from at most to exactly on 129 triggers..... so I am wondering if you can change that back quickly as the guy that was helping me seemingly edited all of them in under 2 minutes which if I were to edit them it would take about 2 hours..............
I took a look at the Simulation you added into my map and saw the bug so how do I fix this problem???
Fourthly (omg so many points LOL), how am I supposed to split the randomization triggers into two separate triggers to account for the creep bug????
Lastly, I have noticed that my mission briefing in the mission briefing menu cannot all be read, and I have also noticed my mission briefing is not inside the mission objectives while playing the game.
Also I would love to know how you added another sound file yet it seems that now my map size is smaller after you edited the sound files and made them louder. (I myself use wavepad sound editor and save the files as 6000 Hz PCM Uncompressed)
Again thank you, and I hope this isn't too much for me to ask of a random stranger LOL but THANKS!
Again any of these problems you can give me suggestions of what triggers to use or if you feel it would be better you can fix them yourself (whatever's best in your opinion)
Here is the link if you do modify it (it is your link, I like what you changed): http://www.mediafire.com/download.php?3ly5482p6s6p8p7
[ Post edited by Radical924 ]
Check out my youtube channel here:
9. Re: THANK YOU FOR ALL THE HELP!!!!!!!! 08/18/2012 11:37:46 PM PDT
* * * Death Counters * * *
Death counters take on the role of program-variables. They are just something we can use to make Starcraft remember a certain number that we will use later. What you choose to do with that number and how you use it is up to you.
The anti-alliance implentation I posted earlier should be sufficient for your purposes.
Any player that does not have a unit (with which the trigger uses to detect alliances) will be defeated anyways.
So it turns out you won't have to integrate a death-counter into the anti-alliance system for this map.
I did ask the question earlier as to whether you were sure about having players eliminated for losing 200 units.
Though it is true it takes a while to rack up 200 losses, given that it also takes 200 slaughters to win, it is mostly expected (with high probability) that a human player will be eliminated by this method.
On top of that, it adds to the disadvantage of playing as Zerg, which are designed to overwhelm enemies with greater numbers. Removing this 200-loss limit would allow Zerg players the freedom to feed off computers to (somewhat) accomodate for the now disadvantagous feature of the Zerg.
Removing the 200-loss limit (if you choose to do so) is not difficult. You would merely just delete the trigger.
Even if this trigger is removed, if a player loses 200 units to a single/certain player, they would still lose because, remember, any player that achieves 200 slaughters is granted victory.
When a trigger grants victory, anyone else that is not also granted victory at the same time will automatically lose.
Your condition which checks for existing units at the start-location is effective at preventing your system from SPAWNING a base. But that does not in any way stop the randomizer from PICKING an occupied spot.
Your system consists of three conceptual parts: A timer, a randomizer, and a spawner.
. . . <When Computer has no Base, add death-timer by 1>
. . . v
. . . v
. . . <When death-timer is greater than 1786, choose a random spot; then reset death-timer to 0>
. . . v
. . . v
. . . <If computer has no units and chosen spot has no units, build new base at location;
. . . . . . . . then run an AI Script> [8 spots x 3 species x 5 AI Scripts = 120 combinations (triggers)]
The randomizer does not selectively choose "open" spots. The Spawner is not coordinated with the timer.
It is possible to re-design the system to have the eight map-locations themselves randomized using a Fisher-Yates Shuffle. In such a case, the spawner would simply check one location after another for an "open" spot.
This solution is neat in that it can accomplish the job in a single trigger-cycle.
In other words, if there is an "open" spot, the computer will randomize, find, and pick one "open" spot, all in one single pass.
In contrast the system above (and the one to be mentioned below) must "retry" every time the computer "misses".
But SC1 triggers aren't exactly an ideal programming platform with which to work with arrays and mathematical computations. As a result, this method is trickier to implement into a map.
If you wish to try it, familiarize yourself with the Fisher-Yates Shuffle (if you aren't already familiar with it). But make a backup copy of your map before proceeding.
Rather than designing a new Fisher-Yates Shuffle system, you can modify your already existing system.
This is the concept for a modified system. It contains 7 parts: Randomizer, timer, timer-reset(no spots open), timer-reset(computer already has base), Base-Structure Spawner, Base-Worker Spawner, timer-reset(Failed Base Spawn)
Note that the Base-Spawn triggers only activate when the 2.5 minute timer is "ready".
. . . <Always pick a new random start-location each trigger cycle>
. . . v
. . . v
. . . <If computer has no base AND death-timer is at most 1786, add death-timer by 1>
. . . v
. . . v
. . . <If all 8 spots are "occupied", reset death-timer to 0>
. . . (There is no point in trying to find an "open" spot if there actually aren't any. Make computer wait until a spot is "open" first)
. . . v
. . . v
. . . <If the computer has at least 1 building, reset death-timer to 0>
. . . v
. . . v
. . . (Base-Spawn Section)
. . . v
. . . . v
. . . . . v
. . . . . <If the computer has no base AND death-timer is at least 1786 AND random spot has no units then
. . . . . . . Create Zerg/Terran/Protoss Building; Set death-timer to 6666>
. . . . . . . (Do not run an AI Script yet. We don't know if Zerg Creep is blocking)
. . . . . . . (There is nothing special about the number "6666". But we will use this "information" next)
. . . . . v
. . . . . v
. . . . . <If computer has a building AND death-timer = 6666, then
. . . . . . . Create Zerg/Terran/Protoss workers at computer's base; Run an AI Script>
. . . . . . . (Our timer trigger stops adding after 1786. If the death-timer = 6666, then we know for sure that the trigger tried to spawn a structure. This is an appropriate time to spawn workers IF the structure was actually built successfully. We check for the structure in case it was blocked by Zerg Creep/Unforseen errors)
. . . . . v
. . . . v
. . . v
. . . <If death-timer = 6666, then set death-timer to 0>
. . . (This trigger is a fail-safe. Without this trigger, the computer will try to respawn again if it was blocked by Zerg Creep. Resetting the timer to 0 delays the computer's attempt by another 2.5 minutes)
. . . (But at the same time, we DO WANT the computer to retry again if the randomizer happened to pick an "occupied" spot. If the randomizer did pick an "occupied" spot, none of the Base-Spawn triggers will have activated, leaving the death-timer still at 1786 or 1787. The randomizer will re-pick again and the cycle repeats)
The death-timer should be set to 1786 deaths upon game start. This will allow the computers to spawn as they should upon game-start.
Before implementing this system, you may want to learn how to move locations (Trigger-Action: Move Location).
You create/use a temporary location and move it to wherever the randomizer has chosen.
Learning how to do this will save you the trouble of making 8 duplicates of each trigger set (once for each start location)
Have the randomizer Trigger-Action:MoveLocation the temporary-location onto some non-existant unit at the chosen start-location.
The temporary-location should be the same size as the original 8 locations you created to ensure that its Trigger-Condition:Bring produces identical results.
Your Mission Objectives are too long. It can't fit in the tiny box.
Mission Objectives shown in the briefings usually show up in-game as well. However, it is possible to skip the Mission Briefings so fast that the Mission Objectives never appear. Thus, no mission objectives appear in-game.
To fix this, use a trigger as a fail-safe.
Investigate: Trigger-Action: Set Mission Objectives
Well I've been sitting here hours now trying to understand your post for the Randomizing Spawn Locations.... I am completely at a lack of understanding of what to change. I have however changed everything else so all that's left to fix is the spawns =(. So unfortunately I am wondering if you can modify the triggers using my existing triggers.( If not I will waste more time getting nowhere lol). Sorry I would change them if I understood Lol sorry.
I have however found a program that can find and replace multiple triggers at once. All you do is copy the old trigger or part of it and replace the new part into the trigger.
To add in new condtions you "Find" "Conditions:" and replace the "Conditions:" with
(Trigger text goes here)
NOTE THIS ALSO WORKS WITH ACTIONS!!!!! I'm sure you already know of this program but if not here is the link to the page: http://www.staredit.net/topic/15296/
Also here is my updated map: https://rapidshare.com/files/735509775/Jungle World 8-19-2012.scx
I'm also sure you use the trigger editor on SCMDraft so you know where to get the Input from.
I am really sorry for all the trouble I am putting you through BUT in the end there will be a map where one can easily import new terrain and move the 8 locations into 8 new spots and it will be truly different each time one plays!
Oh on a side note I changed all the "exactly 0" to "at most 0". Oh and I will upload the "blanked terrain version of this map" when its done to youtube
I didn't realize how difficult a random spawn system could be.
Check out my youtube channel here:
11. Re: I Do Not Understand What Triggers to Fix 08/20/2012 11:32:29 PM PDT
You need to familiarize yourself with the practice of having several sets of triggers working together if you want to build complex systems.
Normally, Starcraft's triggers are ideal for linear tasks. (As an analogy, RPGs can have linear storylines or branching ones)
For an idea of what I mean, such a task would be taking papers from a pile and putting them into a shredder.
This task is straightforward with each step of the task leading directly to the next.
Starcraft's triggers operate similarly; once the conditions for a trigger are fulfilled, it executes its actions step by step without asking questions in-between.
Branching tasks are when the steps could change depending on the situation.
Referring back to the earlier paper-shredding example, a branching version of this task would be this:
1. Take a paper from the pile.
2. If the paper has confidential information, shred it. If it does not have any confidential information, put it into the recycling bin.
Starcraft's triggers are not well-suited for this kind of branching task.
To allow branching, the task must be perfomed by several triggers working together: one that takes a paper, another to shred this paper if it is confidential, and one more trigger to recycle the paper if it is not.
You have already begun creating a branching trigger-system. Your randomizer picks a random spot and your spawner creates a base at that spot. However, you have only gone as far as one level of branching. Once the randomizer is finished with its share of the task, your system goes back to being linear:
Your spawner has 120 triggers, each one "responding" to exactly one of the possible 128 outputs of your randomizer. (8 spots * 3 Species * 5 AI Scripts = 120 combinations)
Resolving the zerg creep problem in this system would require you to split the building-spawn from the worker-spawn, thus doubling the total to 120*2 = 240 triggers.
One level of branching is not going to work out too well.
You need to go deeper.
(I had mentioned in the previous post that you would want to learn how to move locations via triggers. If you haven't already, you will need to in order to properly divide the trigger-system into multiple parts)
Your task is creating a random base in one of eight possible spots.
Split the task into "pieces" wherever it "branches". The triggers in each "piece" do their job, then set everything up for the next "piece" to do its job.
You must also ensure that the "pieces" only do their job when they are supposed to. Ensure this by having them check for a switch that the very first "piece" flips. That way, whenever the switch is flipped, it creates a domino-effect of "pieces" doing their required job.
(Timer: Waits 2.5 minutes after computer dies. When done, flip a switch. This switch acts as a domino-effect which tells the "pieces" after it to do their job) ==>>
==>> (Randomizer: Pick one random spot out of eight. Move a temporary location onto this spot.) ==>>
==>> (Species Randomizer: Pick a random species) ==>> (Structure-Spawner: Create building of chosen species at temporary location) ==>>
==>> (Worker-Spawner: If building created successfully, create workers) ==>>
==>> (AI-Script: Run a random AI Script) ==>> (Reset-Timer: Rollback the timer to 0 seconds)
This is an overly-general description of the system. Previous post is more technical.
This is a concept-map for a trigger system split into "pieces".
It is a 2-level branching system.
1. Pick random spot out of 4
2. Build either a CC/Barrack/Factory/Starport + units
The task is performed using 13 triggers.
A linear-style solution to this task involves (4 spots * 4 building-types = 16) 16 triggers.
Branching has given an advantage worth 3 triggers. This is quite small, but remember, the linear-solution can increase its complexity exponentially with each branch-layer.
* * * * *
* * * * *
When you have understood the concept behind this map, try to add a third-branch level for practice.
See if you can set up the buildings to come out with a random amount of hit-points (25%hp, 50%hp, 75%hp, 100%hp).
You should be able to do this with only 5 new triggers, totaling to (13 + 5 =) 18 triggers (ignoring comments & hyper triggers)
Use Trigger-Action: Modify Unit Hit Points
* * * Random Output * * *
You may have noticed that when generating random results, you are usually stuck using a number of results equal to a power of 2; (2,4,8,16,32,64, . . .)
It is beneficial to be able to extract a random result with a total of your own choosing.
For example, being able to pick a random result out of three is crucial for your zerg/terran/protoss computer spawn.
This is possible by generating a very large number that falls between 0 and some very large max-number and find where the result lands between the divisions of this range.
As an analogy, imagine you have a 300cm-long ruler. You drop a bouncy ball on it and wait for it to come to a stop at some random spot between the two ends of the ruler.
If you wanted two possible results, you would simply check if the ball fell on the left side or the right side of the ruler.
If you want three possible results, you would check if the ball fell onto the left side, middle, or right side of the ruler.
0cm-99cm = left, 100cm-199cm = middle, 200cm-300cm = right
Do this with Death-Counters. Generate a large number and find where it falls between 0 and the theoretical maximum value your trigger-system can generate.
Concept-Map: This map spits out either rock/paper/scissor every trigger-cycle.
The trigger-system is a simple 1-Level Branch.
* * * * *
* * * * *
[ Post edited by Fishinspace ]
14. Re: I Do Not Understand What Triggers to Fix 08/21/2012 07:32:17 PM PDT
The terran beacon is not important. I only used it to "activate" the spawn-system. Keep in mind, none of the four spawn areas have any beacons or identifying units within them.
If the beacon continues to mislead your analysis, I shall re-post the map using a count-down timer instead.
* * * * *
* * * * *
This version has only plain terrain. No beacons. No flags.
Just plain naked terrain.
Pay special attention to the triggers that actually create the units. All of them use "SpawnTemp".
How does a single location, "SpawnTemp", represent all four different spots?
The concept-map also serves another purpose besides simply showing how its triggers work.
I had intentionally designed it to operate similarly to your map so that you could also use it as your map-making lab rat.
Since there are only 13 triggers to look through, you can easily edit it and catch mistakes as you work.
It provides you a cleaner environment in which to work instead of using your main map which already has many triggers.
After you have understood the entire concept, then you can begin applying it to your real map.
#1) Firstly, this version only reports an error message if a spot is "occupied". You can "occupy" a spot by camping a unit there.
Try to redesign the system such that when it lands on an "occupied" area, it will immediately repeat the build-cycle in the next upcoming trigger-cycle.
Hint: The coutndown-timer activates a trigger cycle.
#2) The system must be tested against unforeseen circumstances such as Zerg Creep.
If the triggers fail to construct a structure, the [men] must not spawn either.
Implement this by splitting the structure-creation and [men]-creation into two seperate branches.
Use water-terrain as a substitute for Zerg Creep. Appropriate spots for water are shown with grass.
Additionally, the triggers should not behave like #1 when this happens. It should retry after a full count-down.
* * * Random Numbers * * *
The very first trigger resets the death-counter to 0 every cycle.
The switch is always re-randomized before deciding whether or not to add more deaths to the death-counter.
Each of the triggers that add deaths have a 50% chance of actually doing so.
Sorry I took so long to re-post my map with the new spawns and the music system but I have been having issues lately wiht SCMDraft2 constantly giving me the error "Something bad happened would you like to save a diagnostic file?"... So it took me a while to finally save ma map with the correct triggers.
Please post any new bugs you find with either the map spawning or anything. I currently haven't found any bugs accept maybe with the Allied victory checkbox not unchecking if you click it, but I am not sure if that is an issue. Also I was wondering if you could add in a trigger for removing shared vision for Force 1 at all times... THX
The 'Allied Victory' checkbox will not cause any problems.
All that matters is that the player cannot actually make any alliances.
The Spawn system is mostly operational.
+ Passed Creep-test. Workers will not spawn unless the structure-spawn was successful.
+/- Retry spawning if creep-blocked. Not sure if this is a pass/fail since it depends on your intentions.
If creep blocks the spawn, the system will re-run again in the next trigger cycle.
If ALL the available spots have creep, players will be spammed with "Unable to Place Unit" errors.
This is somewhat remedied by the randomizing aspect of the spawn-system. Given that the comp may spawn as Zerg 1/3 of the time, there will only be so many "Unable to Place Unit" errors before the dice-roll lands on a Zerg-Base-Spawn.
If only some spots have creep, an immediate re-try is also advantageous in that the computer may pick a creep-free spot on its second try if it failed to spawn on creep during its first try.
There are AI Scripts available in ScmDraft which can force Shared Vision On/Off for players.
Running the proper AI script continuously can ensure that players are unable to permanently share vision.
These AI scripts work on both, human and computer players.
Use [Run AI Script] (without location) for whichever player should/should not receive vision from another.
DO NOT let the player turn off shared vision with themself. Doing this will put the player into "lights off" and they will be unable to see their own units.
The music-system works fine.
However, its trigger-design may be using up too many resources (switches, death-counters, and triggers)
A death-counter can also be used similarly to a switch, thus eliminating the need to create a switch for every player.
This same switch can also be used as the "clock" for each segment of the song.
The current implementation has a death-counter for each segment of the song.
Visualized, it can be represented as, for example, hour-glasses.
When one hour-glass has finished, it flips the next hour-glass after it. Each flipped hour-glass plays its own segment of the song.
However, this is inefficient resource-wise since it is using a death-counter for every "hour-glass". In addition, each death-counter needs its own trigger to make it 'tick' per trigger-cycle.
The task can be done using a single death-counter.
Instead of hour-glasses, this single death-counter is used as a clock.
The clock runs continuously, with each "hour" triggering the next segment of the song.
When the final song-segment has finished, the clock will have made a full-circle back to its first "hour" which starts the song loop again.
The time-length of each "hour" is determined by however long each song-segment is.
Supposing song-segments last 12 seconds:
Hour#0: 0 deaths
Hour#1: 143 deaths
Hour#2: 286 deaths
Hour#3: 429 deaths
. . . and so on until it "resets"
Your current implementation is fully operational.
Whether to optimize it is your choice and depends if you or another map-maker later wants to use a lengthier song.
Trigger-wise, it is not ideal and forces map-makers to use even more death-counters for longer songs.
Regarding BGM music in general, using such large music samples is not worthwhile in my opinion.
Its success is dependent on the player's musical taste.
Personally, I have my own MP3 playing instead of map-included music or Starcraft's own BGM.
The 1MB map download in lobby may not be worthwhile considering the chances they will turn it off when the game starts. Those who leave the music on would have to like the BGM more than whatever they were listening to beforehand (if they were listening to anything).