<><><> <><><> <><><> Features (The Modded Training Map), my signature map mod <><><> - This map has just about all the mods that I've made for UBER V7.0 FFA/TDM, and serves as a training ground for any future modders. - The Allies first spawn in the tents area, behind the large fence with the 3 green lasers across it. The Axis spawn between the ladder and the first double doors (before the gun ranges). The first objective for both Allies and Axis (or just Allies, if the Axis want to maintain a bottleneck instead of accessing the rest of the level) is to blow up the tank. Depending on the Training map's "tank_m3_replace.scr" and "obj6b_explosive_tanktrig.scr" scripts, the tank will either be "static" or "drive" for driveable. If "static", then the Allies will have explosives spawned inside one of their tents. These explosives must be taken deep inside the Axis spawn and planted on the tank. Once planted, everyone has 5 seconds to run away from the tank, the 3 hangars, and the green oil barrels before everything blows up. If "drive", "obj6b_explosive_tanktrig.scr" must be commented out (you won't need explosives anymore). The driveable tank shoots green-lit projectiles that explode with a red-flash similar to grenades. Only Giant Bombs, Radiobomb-Walkies, and rockets can destroy the driveable tank. If you comment out the "drivetank_tempimmunity" thread, then airstrike bombs can kill the driveable tank too. The "drive" version of this Training mod is much easier for the Allies to do, thus the "drive" version was chosen as default instead of "static". - Once the tank is destroyed, the double doors unlock, and player spawns change to include the first and largest gun range (Axis spawn primarily in the large gun range now). All doors except for the final mg42 gunrange are unlocked. Both Allies and Axis now have to complete 4 field objectives: shoot the closest target 10 times, shoot the middle target 50 times, shoot the farthest sniper target on the red bull's eye 5 times, and throw a grenade into each of the 3 cement enclosures. Then, the door to the final mg42 gun range is unlocked. Both Allies and Axis now have to complete 2 more field objectives: destroy the target with the mg42 or grenades, and shoot the red explosive barrels in the back right corner. Once all 7 objectives are completed, the red final door's overhead red light turns yellow. This means the final door key has spawned. The lower smaller red light is for the door's keypad, not the final door itself. - The final door key always spawns near the final door at first; it then randomizes to one of 10 locations across the map. This green-lit spinning object trigger can be picked up, and it drops to the ground when the player carrying it dies. Once carried to the final door, the smaller red light illuminating the keypad must be triggered with the USE key. Once the keypad is triggered, it turns green, removing the final door key from the player (respawns to a new random location after the final door light turns yellow again) and indicating that the yellow-lit final door is now unlocked and can be opened with the USE key. Nothing else happens until the final door is opened with the USE key one more time (like a regular door now), which turns green when it opens and then yellow again after 4 seconds, also locking after 4 seconds. NOTE: Sometimes the final_door trigger can be triggered without actually opening the door (you'll know it was triggered when the overhead light turns green). Make sure you open the door while the light is green, otherwise you'll miss your chance to open it when it turns yellow again. Just press the USE key a few times near the door; it will open. Also, make sure you close the door behind you; it does not close automatically. Once it's yellow and closed, you won't have to worry about someone following you into the final tunnel. - The players have now unlocked the final part of the UBER Training Map Mod. A red tele will appear at the end of this short dark tunnel inside the red final door, after the final door key unlocks the final door for the first time. Depending on whether or not the ".../tunnelbase_nazi.scr" script is included in the Training map script, the tele will either take you inside the Nazi Tunnel Base (made out of banquet tables, located in the Allies spawn under the tents, under the map) or outside onto the first of 5 Sky Platforms. The Nazi Tunnel Base has another tele at the opposite end (exit side), which then takes you to the 1st of 5 Sky Platforms. These transparent (but not shoot-through) platforms are high above the map and great for sniping. Players can travel between them sequentially with small red teles floating about eye-level in the middle of each platform, while the 5th and last platform's tele (behind the Allies spawn) takes you back to the final door tunnel (or back to the Nazi Tunnel Base's exit). - The training map includes the following triggers: Giant Bombs, Light Bombs, Living Dog, Grenade Ammo, Rocket Ammo, Toxic Snowball Ammo, +200 Health, Joint (Blunt), Spotlights, 3 LED Dot Traps, and 2 Radiobomb-Walkies. The training map also includes the Training-specific scripts below (see folders: maps/training_mapscripts/... maps/gen_mapscripts/... maps/UBER_mapscripts/... map/UBER_mapextras/... map_triggers/map_switches/... and map_triggers/gen_switches/...): --- --- --- Essential Mods for Training Map --- - (1.) tank_m3_replace.scr: This essential Training map script prevents some entity bugs from occuring and establishes the modded gametype for the players. First, radiusdamages destroy some unwanted entities: the old tank (if using "drive"), the old m3 halftrack (replace it with a new one with 9999999 health since it never had a targetname to adjust its health), and some green oil barrels (only for "drive", since driving the tank over them causes the tank to blow up). If using "drive", a laserprism can be added with the specified RGB color. This laserprism outlines the solid object barrier around the old Training tank. Even if the tank moves away or is destroyed, an unwanted player-barrier object still lingers where the tank initially was, but bullets and grenades can pass through. Without a targetname (wasn't the same as $tank), it cannot be removed. Thus, a laserprism can be added to outline this player-barrier so players can easily walk around it without impeding movement. The laserprism is not visible until the driveable tank moves from its initial origin, controlled by a while-loop. Two more while-loops are also running, one waiting until the "drive"-able tank is destroyed (to begin running exec .../obj6b_explosive_tanktrig.scr::obj6b 1), and another waiting until the "static"-only tank moves from its origin. The last while-loop is a fix that readjusts the "static" tank back to its origin anytime a kickback or other moving object suddenly pushes it away from where it needs to be. Usually, the tank gets pushed when a Giant Bomb or Light Bomb is fired at the upper part of the tank's treads. - If the game "type" is "static", then the tank in the Axis spawn will not be driveable. The Allies will have yellow-lit explosives (run by obj6b_explosive_tanktrig.scr::main, or "::main" can be omitted) on a bunkertable inside of a tent, which must be planted on the tank in the Axis spawn, and only these explosives can destroy the tank. When using "static", the Allies will have a much harder game to beat without teles to travel behind walls around the trench, since players will mostly be bottlenecked there and will never reach the tank to plant explosives. Thus, the "drive" game type is much easier for Allies, opening up the gun ranges to all players much sooner (Axis can also destroy the tank if they want). Only one player at a time can drive around in the tank if using the game type "drive". Giant Bombs, Radiobomb-Walkies, and rockets are the only weapons that can kill the tank. The rockets are weak in this mod, so it's unlikely that a rocket could destroy the tank. Since the Giant Bomb's origins are spread out across the map, Allies have more access to long-ranged weapons that can kill the tank. Destoying the tank changes all player spawns to include portions of the main gun range field, while unlocking the metal double doors behind the original Axis spawn. - Parameters: type = "static" or "drive" (make tank static or driveable), laserprism (0 = off or 1 = on), r, g, b (laser prism color). - Example: exec .../tank_m3_replace.scr drive 1 0.125 0.0 0.333 - (2.) obj6b_explosive_tanktrig.scr: Comment this out if using "drive" above (unless you want a useless explosive). This large Training map script includes the essential "obj6b" thread for blowing up the tank and blowing up other stuff, as well as spawning in the "static" tank explosives in an Allies-side tent. If the player holding the tank explosives dies, they drop to the ground (be careful not to lose them in midair). Once planted on the tank, a 5 second countdown timer begins before blowing up the tank. 4 more explosions occur 0.15 seconds after the tank blows up, 3 inside each roofed hangar adjacent to the tank's initial origin, and one at the rack of green oil barrels. Each hangar has a row of 3 wooden boxes on top of bunkertables that also blow up (explosiveboxes.scr::blowup). The green oil barrels blow up 1 second after the previous 3 explosions, and this explosion spawns in two exploding red barrels (also launching into the air and emitting black smoke for a short time). Red exploding barrels can only be spawned in via scripts if others already exist on the map (see the very bottom of this script in "barrels" thread for more details). However, cloning any barrels will spam duplicate entity errors in the console, so they must be blown up waitframe seconds after spawning them in. Afterwards, both middle doors behind the Axis spawn are unlocked, the uboat walls are modified to become notsolid, more indycrate stairs are shown, Allies and Axis spawns are changed, explosiveboxes.scr::endfire occurs (beginning the countdown before small fire emitters disappear), tankexplosions.scr::removeemitters occurs, and 1 out of 7 objectives are marked as completed. - Parameters (a): tank explosives origin, angles, r, g, b (explosives rgb light), light radius - Example (a): exec .../obj6b_explosive_tanktrig.scr ( -4751 420 -256 ) ( 0 70 0 ) 1 1 0 65 - Parameters (b): driveabletank (0 = 5 second countdown timer and bomb plants onto tank; 1 = skip countdown, blow up instantly, for "drive"). - Example (b): thread obj6b or exec .../obj6b_explosive_tanktrig.scr::obj6b 1 - (2b.) tankexplosions.scr: This script provides all the explosion emitters and extra black smoke for the racks of green oil barrels, as well as the m3 halftrack that replaces the old one killed by radiusdamage in tank_m3_replace.scr. This script initializes all emitters when the map loads and keeps them off by default, that way they're not all spawning in after the tank blows up. If the "removeemitters" thread runs, then all the explosion emitters will be removed, including stopping and/or removing the three fire emitters below the blown-up "static" tank. If the "explodeall" thread runs (for testing purposes only), then all explosions emitters will run once after waiting a certain amount of time, including turning on or not turning on the fire emitters below the tank. - Parameters (a): none - Example (a): exec .../tankexplosions.scr (or exec ../tankexplosions.scr::main) - Parameters (b): stoptankfire (1 = stop it), removetankfire (1 = remove fire emitters completely). - Example (b): exec ../tankexplosions.scr::removeemitters 0 0 - Parameters (c): time until explode, notankfireorsmoke (0 = turn them on, 1 = don't turn them on). - Example (c): exec ../tankexplosions.scr::explodeall 5 1 - (2c.) playertank.scr: This script is required if using "drive" for the "type" parameter in tank_m3_replace.scr (the main objective tank is already included in tank_m3_replace.scr). Slightly modified from the 2006 version (code was reformatted/simplified), this script allows a player to press USE near a tank to hop inside and begin driving around. Grenades and bullets cannot damage the tank. When destroyed, the tank leaves a "destroyed model" (or desmodel) behind until the map ends. The tank's health and vehicle speed can also be specified. A fix within the script ensures that the tank's trigger remains attached to the tank model, in case a Giant Bomb or Light Bomb pushes the tank away while no one is driving it (usually if fired at the upper part of the tank's treads). - Parameters (a): targetname, model, turret model, destroyed model, tank origin, angles, health, vehicle speed. - Example (a): exec global/playertank.scr tank2 vehicles/panzer_tank_europe.tik vehicles/panzer_cannon_europe.tik vehicles/panzer_iv_eud.tik ( 2301 2127 -403 ) ( 0 -90 0 ) 1000 200 --- --- --- Mods Still Needed, But Not As Essential - (3.) explosiveboxes.scr: A simple script for spawning in 3 groups of 3 small, closed, wooden explosive boxes (static/exp_crate...) found on bunkertables inside the hangars in the Training map. The explosion emitters are found in "tankexplosions.scr". When the "blowup" thread runs, these closed boxes change models to their open-crate versions, and fire emitters appear inside all the boxes. When the "endfire" thread runs and two times are specified, the 3 pairs of 3 fire emitters will remain shown until the 1st time duration has passed. Then, the outer two of each pair of fires disappear. After the 2nd time duration passes, the last 3 middle fire emitters disappear. Running the "reset" thread removes everything and respawns in the closed wooden boxes and hidden fire emitters. - Parameters (a): none - Example (a): exec .../explosiveboxes.scr (or .scr::main); exec .../explosiveboxes.scr::blowup; exec .../explosiveboxes.scr::reset (not used in Training script) - Parameters (b): time duration for 2 of 3 fires, time duration for the last fire. - Example (b): exec .../explosiveboxes.scr::endfire 13 43.5 - (4.) tentwall_lasers.scr & training_trainswitch.scr: The trainswitch script spawns in a train lever switch that is pulsating red initially. The tentwall lasers script spawns in three thin horizontal lasers inside the Allies-side barbwire wall/fence. Since the barbwire wall is invisible from the Axis side, these lasers are used to show where the wall is when facing both sides. While the lasers are on (green by default), players cannot walk through the wall, but bullets and projectiles can still pass through. The Axis side does not have a train lever to turn off the lasers, so Axis will be unable to spawn camp if the lasers are still active. Inside an Allies-side tent is the train lever switch. Once triggered, the tentwall lasers flash red, then off within 1 second, while the barbwire wall rotates downwards over "rotatetime" seconds. As long as the lasers are completely gone, players can pass through over the barbwire wall. The trainswitch does not pulsate red when the barbwire wall and lasers are down. Once triggered again, red lasers instantly reappear, blocking players from walking through. The barbwire wall rotates back upwards over "rotatetime" seconds. The lasers' color turns green again after the barbwire wall is back up and vertical. - Parameters (a): r, g, b - Example (a): exec .../tentwall_lasers.scr .3608 .6627 .0016 - Parameters (b): origin, angles, wallclip, barbwirewall, rotatetime, r, g, b - Example (b): exec .../training_trainswitch.scr ( -4695 -500 -307.5 ) ( 0 289 0 ) clip_2 door_mid 3.4 .3608 .6627 .0016 - (5.) uboatmapwalls.scr: Spawns in two sets of invisible walls up to the map's ceiling, blocking off access to the main gun ranges (beyond the metal double doors), and blocking off access to the final mg42 gun range. These are made of only 12 uboats (largest available entities) and 4 barbwire total. Two threads inside the script also spawn in trigger_multiple walls across the uboat walls, for printing "gun range not accessible yet" messages to any player that touches the walls. The first and main uboat's trigger messages can only be turned off when the tank blows up (not the extra green tank in the fields). The final uboat wall at the mg42 gun range field can only be turned off when all 4 field objectives are completed. The uboat walls can be modified in-game via another script (such as in obj6b_explosive_tanktrig.scr::obj6b) by running the "modify" thread and specifying the wallname, whether it's solid or not, and whether it's visible or not. - Parameters (a): none - Example (a): exec .../uboatmapwalls.scr - Parameters (b): wallname ("mid" or "final"), solid (0 = notsolid, 1 = solid), show (0 = hide, 1 = show the uboat walls). - Example (b): exec .../uboatmapwalls.scr::modify mid 0 0 - (6.) radios_musictrig.scr: A standalone script for easily spawning in a civilian radio or military radio that is off by default. Once triggered, a radio static sound loops. When triggered again, radio music loops. When triggered again, the radio stops looping sound. - Parameters: radio origin, angles, model (add "animate/military_radio.tik", or leave empty for "miscobj/radio_civilian.tik"). - Example: exec .../radios_musictrig.scr ( -4890 697 -256 ) ( 0 340 0 ). Use the full folder path, not periods. - (7.) lampswitch.scr: A generic switch trigger script that turns on/off a light around an object with the specified targetname, whose radius and RGB colors are also speficied in the parameters. - Parameters: name, r, g, b, radius (where r,g,b are decimals from 0 to 1, representing 0 to 255 values). - Example: exec .../lampswitch.scr lamp3_tent 1 0.96 0.8 300 - (8.) trucksounds_trig.scr: A training map script, which can be used in other maps, that spawns in a trigger and invisible object for sound to loop from, with the desired targetname and "horn" parameter. When a player holds USE for 3 seconds near the trigger, the truck audibly turns on. Holding USE for 1 second or less while the truck is on will honk the horn (the horn is much louder than the truck's idling sound). Hold USE for 3 seconds to turn off the truck. This script also works for halftracks, but ideally the "horn" parameter should be 0 since the halftrack does not have a horn. Place the trigger's origin near a truck door, or a halftrack door, or tank, or any other vehicle. Place the soundorigin object ideally where the truck's engine is (inside the hood of the truck), and specify a "targetname" for the soundorigin object. Specify the "name" of the sounds to be looped (since this is for the Training map, only "truck" or "track" are available). Specify 0, 1 or 2 for the "horn" parameter, where 0 = no horn, 1 = honk while vehicle is on only, and 2 = honk while on or off. Optionally, you can increase the trigger's setsize1 and setsize2, or leave them NIL (blank/empty) for default settings. - Parameters: trigorigin, soundorigin, targetname, name (truck or track), horn, setsize1, setsize2. - Example: exec .../trucksounds_trig.scr ( 133 -2334 -345 ) ( 80 -2393 -340 ) truck_engine truck 1 - (9.) spotlight_colorswitch.scr: Only added in Training map, but can be added elsewhere; this script spawns in an alarm switch. When triggered, the spotlight with the same targetname as "name" will change colors only after the player is close enough to rotate the spotlight (while player-angles are changing). If the colorswitch's "name2" parameter = "rainbow", then the spotlight's color will change continuously, only while the player is moving the spotlight. Once the player walks too far away, the spotlight stops changing colors. Ideally, the spotlight colorswitch should be placed near the spotlight whose beam-color will be changed. Name = the same name as a spotlight's name. Name2 = "rainbow" or leave it empty. If name2 is empty or NIL, then triggering the alarmswitch will change spotlight's color to a new random color one time, and the alarm switch turns off. If name2 = rainbow, then triggering the alarmswitch will turn on a rapid randomization of the spotlight's color, and triggering the alarmswitch again will turn off the rapid color switching. If name = "all", then all spotlights on the map will have their beam-colors change one time. If name = "all" and name2 = "rainbow", then all spotlights on the map will have their beam-colors changing rapidly and continuously until the colorswitch is triggered again. Multiple spotlight_colorswitches can be used for one spotlight. - Parameters: origin, angles, name, name2. - Example: exec .../spotlight_colorswitch.scr ( 6008 -2528 -376 ) ( 0 -90 0 ) s13 rainbow - (10.) finaldoor_keytrig.scr: This script contains everything related to the final key and final door triggers. When the final key (can only be dropped by dying) is carried to the final door and the player presses the USE key near the small red-lit keypad, the key is removed from the player and the keypad light turns green. This means the yellow-lit final door is now unlocked. Press USE one more time to open the door, turning the overhead light green. If somehow the door turned green without opening, make sure to keep pressing USE until it opens, otherwise it will soon lock again. The green light above indicates that the final door is still unlocked (even if it briefly closes and reopens while green). Once the light turns yellow again, the final door locks and respawns the final key to a new random origin. - Running "main" initializes all 10 random key origins as level variables. In the Training map script, only the 1st origin is included for "main", forcing the key to spawn near the final door only for the 1st time. In the thread "finaldoor_triggertemp", after "the final door key has respawned" message, the following line adds the other 9 random key origins: "waitthread maps/training.scr::addremaining_keyorigins". If you include all 10 random key origins after ""::main" initially, then the key will not forcibly spawn near the door. Initially running "finaldoorlight" spawns in a red light above the final door (status of objectives: red = not finished, yellow = done, key has spawned, green = opened & 4 seconds until locking again), a small picklock model representing the keypad, and a red light for the keypad (status: red = key not inserted, green = key inserted & ready to unlock the yellow door). Initially running "finaldoor_trigger" initializes the "door is locked" message trigger whenever a player tries to open the door without a final key. The "finaldoor_triggertemp" thread spawns in a temporary trigger to avoid opening the final door before a previous trigger's "waittill trigger" begins waiting for a player. This thread, after triggered, changes the overhead light to green, shows all the Sky Platforms with "exec maps/UBER_mapscripts/sky_platform.scr::on sky1" (and sky2,3,4,5), activates the red teles behind the final door and Tunnel Base Nazi (if included) and the 1st Sky Platform (closest to the final door), waits 4 seconds before locking the final door (does not close by itself), then changing the overhead light back to yellow and the keypad light to red, and lastly adding the 9 other final key origins (unless they were already added). - Parameters: randomized final key origin1, origin2, 3, 4, 5, 6, 7, 8, 9 (for "main" only). - Example: exec .../finaldoor_keytrig.scr::main ( 5533 -2627 -387 ); exec .../finaldoor_keytrig.scr::finaldoorlight; exec .../finaldoor_keytrig.scr::finaldoor_trigger - (11.) sky_platform.scr: An UBER map script that can be spawned into any map. Each platform contains 8 entities: 4 invisible bodies_tarp and 4 visible red lasers outlining the edges of the platforms. Teles were added in a separate script (training_teleporters.scr::activate) to travel between the 5 sky platforms in the Training map. The Training map Sky Platforms are in the following locations: behind Allies-side tents, above the trenches, above the tank and rack of green oil barrels, above the trees along the metal double doors wall, and above the trees behind the mg42 gun range. The platform floors can be seen through, but no bullets nor rockets nor grenades can pass through. Extra parameters allow the changing of the rectangle laser prism's color or changing the orientation of the platform (longer side along x-axis or y-axis). The origin is the center of the platform (between the 4 bodies_tarp entities). Running "exec .../sky_platform.scr::on sky1" makes the platform solid and lasers visible for the platform named "sky1", while running "exec .../sky_platform.scr::off sky1" makes "sky1" notsolid and lasers deactivated. The platforms are off by default when they are initially spawned in. - Parameters (a): origin, RGB color, name, orientation (0 or 1, for longer part along x-axis or y-axis) - Example (a): exec .../sky_platform.scr ( 6466 -1508 1205 ) ( 1 0 0 ) sky1 0 - Parameters (b): name - Example (b): exec .../sky_platform.scr::on sky1; exec .../sky_platform.scr::off sky1 --- --- -- Fun Mods, But Not All Needed --- --- 2 or more scripts below (ideally Nazi Tunnel Base & Fire Fields) must be commented out before running a dedicated server (too many entities) --- - (12.) tunnelbase_nazi.scr: An UBER map script that can be spawned into any map (about 140 entities each). The tunnel is surrounded by the tops of banquet_tables on all sides, being 3 tables wide, two tables high, and 11 tables in length. The specified origin is the floor centerpoint of the entire tunnel. Both ends have two tall Nazi flags, and the exit side has two white corona lights near the ceiling. Two small alarm bells are near the ceiling in the middle of the tunnel. The entrance side has 2 large cabinets and an indycrate to see above them. The exit side has 4 large cabinets, an indycrate to see above them, a sideways bunkertable, and an mg42 with an ammobox on top of the table. In the Training map script, a spotlight, two spotlight-color changers, two medics, a valve switch for raising and lowering the large cabinets & indycrates, and an electrical switch for triggering the alarm bell lights ("alarmsound" thread) are all inside the Nazi Tunnel Base. The "mirrorflip" parameter only flips the large cabinets and other entities inside the tunnel, not the entire tunnel itself. A nearly identical UBER map script, called "tunnelbase_nazi2.scr" spawns in a Nazi Tunnel Base whose orientation is along the opposite axis from tunnelbase_nazi.scr. The centerpoint of the Nazi Tunnel Base should be deep under the map or in midair, given enough space to avoid spawning into buildings or partially out of bounds. - The script itself has two additional threads: "move_cabinet" for moving any specified cabinet or indycrate up/down 120 units for a specified amount of time (mg42 and bunkertable do not move), and "alarmsound" for playing 1 of 5 loud randomized alarm sounds from the small Nazi Tunnel Base ceiling alarm bells and flashing red and blue lights for a specified amount of time. The red and blue colors can be changed to any two desired colors (both alarms alternate through the two colors), and the amount of color flashes/alternations within the time duration can be specified with the "flashes" parameter. These threads are ideally executed after triggering a valve or switch. - Parameters (a): mirrorflip (0 or 1, to flip interior objects from leftside to rightside). - Example (a): exec .../tunnelbase_nazi.scr ( -5200 500 -730 ) 0; exec .../tunnelbase_nazi2.scr ( -5200 500 -730 ) 0 - Parameters (b): name, move (0 = move down, 1 = move up), move time (set as rotatetime in "training_valveswitch.scr"). - Example (b): exec .../tunnelbase_nazi.scr::move_cabinet 7 0 local.rotatetime - Parameters (c): 1st RGB color, radius, 2nd RGB color, radius, time amount for playing alarm sounds, number of "flashes"/color alternations within time duration. - Example (c): exec .../tunnelbase_nazi.scr::alarmsound local.color1 local.radius1 local.color2 local.radius2 local.time local.flashes (these are all set in "training_electricalswitch.scr") - (12b.) training_valveswitch.scr: This script spawns in a valve switch and is found inside the Nazi Tunnel Base near the exit side, only slightly modified from "gen_switches/valveswitch.scr". Regardless of whether the valve rotates clockwise or counterclockwise, triggering this valve will first lower the 8 interior entities (cabinet_larges and indycrates) until they are completely under the floor, moving for a specified "rotatetime" (also determines how long to rotate the valve before stopping). Once triggered again, the 8 entities move up from the ground and back to their original positions. The valve pulsates red while it is rotating, and while the entities are moving. - Parameters: origin, angles, rotate time/move time, rotate amount in degrees, clockwise (0 = counterclockwise, 1 = clockwise). - Example: exec .../training_valveswitch.scr ( -4175 633 -623 ) ( 0 -90 0 ) 5 270 0 - (12c.) training_electricalswitch.scr: This script spawns in an electrical switch (eswitch) and is found inside the Nazi Tunel Base near the exit side, modified from "gen_switches/electricalswitch.scr" to make the eswitch automatically turn off once alarm sounds are done. Triggering this eswitch will "toggle the alarms" by flashing between the two specified RGB lights at the two small red alarm bells near the ceiling of the tunnel. The lights perform "flashes" number of alternations, and they alternate for "time" seconds. The alarm sounds randomize between 1 of 5 possible sounds each time the eswitch is triggered. - Parameters: origin, angles, 1st RGB color, radius, 2nd RGB color, radius, time amount for playing alarm sounds, number of "flashes"/color alternations within time duration. - Example: exec .../training_electricalswitch.scr ( -4175 368 -623 ) ( 0 90 0 ) ( 1 0 0 ) 200 ( 0 0 1 ) 200 4 32 - (13.) firefields.scr & training_detonator_field.scr: The Fire Fields script spawns up to 74 entities of fire emitters and wide trigger_multiples that cause pain over time, burning all players standing in the large gunrange field. The field detonator script spawns in 3 detonators, each at the back end of the concrete lines in the field. The Fire Fields script has two sets of trigger_multiples: 4 across the edges of the field (including partially inside the cement gun range windows) that cause pain according to the "firepainedge" thread, and 32 spread evenly across the field that cause pain according to the "firepain" thread. Firepainedge deals 5 volumedamage per trigger, killing the player in 5 seconds. Firepain deals 12.5 volumedamage per trigger, killing the player in 2 seconds (both threads hurt players 4 times per second). Once 1 of the 3 detonators are triggered, fuses made of a welding_spark and firegood emitters travel down the adjacent concrete line and travel perpendicular towards the other 2 detonators, before traveling down those concrete lines too. As many as 3 fuses appear at one time, each moving the same speed and reaching their destinations (at the concrete gun range windows) at different times. Shortly behind the fuses are fire emitters that are shown via carefully timed for-loops, with their respective pain-causing trigger_multiples activated at the same time. The fire emitters begin counting down from the "firetime" amount to 0 only after all fire emitters have turned on. The fuses all eventually travel straight down the field along the concrete lines with a speed that takes "fusetime" seconds to finish. In short, the fire emitters and pain triggers do not turn on row-by-row; they turn on in triangular rows since the furthest fuses (from triggered detonator) take longer to begin traveling down the field. The fire emitters can also be delayed behind the fuses according to "waitmultiplier"; this parameter should remain between 0 and 0.5 to prevent the fire emitters from being too incorrectly timed behind the fuses (just doesn't look good). Too close to waitmultiplier = 0, and the fire emitters will be turning on directly next to the fuses, so 0.2 or 0.25 are ideal. After "firetime" seconds are done, the fire emitters quickly turn off row-by-row towards the concrete windows to make a smooth wave-like effect. - Inside the Fire Fields script are 3 sets of for-loops and "wait" timing threads for the left, mid, right detonators, and 2 threads for the fuses. If the mid detonator is triggered, 3 fuses travel to the left, right, and down the field. If the left/right detonator is triggered, only 2 fuses travel out of the detonator; the 3rd fuse always comes out of where the middle detonator is, but it waits for another fuse to reach the middle detonator first. The thread "fusespark_downrange" is always called first to spawn the fuses, and given the parameters: name, origin, fusetime, firedelay. Depending on which detonator name is triggered (left, mid, right), this thread will call two "fusespark_sideways" threads that are each given a name parameter: right/rightmost, left/right, left/leftmost, along with origin, fusetime, and firedelay. In the "fusespark_downrange" thread, the fuses make a welding torch sound while traveling, and make a sizzling sound once finished. The fuses from "fusespark_sideways" do the same thing, except they first travel left/right 704 units or leftmost/rightmost 1408 units (field is 4800 units long from concrete windows to detonators). Triggering the mid detonator runs "detmid_ignitefields", which also runs "fusespark_downrange" and does 3 simple math equations: "firewait time = fusetime * waitmultiplier", "waitinc = fusetime * 0.125" or divided by 8, and "firedelay = fusetime * 0.14667" (1 second to travel 4800 units = 0.14667 seconds to travel 704 units), before waiting for firewait time. If waitmultiplier = 0.2, for example, then firewait will be 1/5 of the fusetime before the 1st fire emitters appear. Then, the "detmid_ignitefields" thread runs "ignitefields_delay_middet" with the parameters: fusetime, firetime, firedelay for starting leftside/rightside's fire emitters (only one delay thread is needed for "detmid" since both fuses reach left/right at same time). Triggering the left or right detonators does 4 math equations before waiting for firewait time: same as first 3, and "firedelay2 = fusetime * 0.29334" (1 second to travel 4800 units = 0.29334 seconds to travel 1408 units), but the "detleft_ignitefields" thread instead runs two threads: "ignitefields_delay_leftshort" and "ignitefields_delay_leftfar", "leftfar" with the parameters: fusetime, firetime, firedelay, firedelay2. In the "detleft" or "detright" primary threads, the 1st for-loop turns on the nearby fire emitters in 8 rows (each time waiting for "waitinc"), before waiting for "firetime" and running another for-loop to turn the 8 rows of fire emitters back off (each row waiting for 0.25 seconds), and disabling the detonator for "offtime" seconds. The "delay_middet", "delay_leftshort", and "delay_rightshort" threads all do the same thing as the "detmid", "detleft", "detright", but they wait for "firedelay" instead of "firewait" before running the 1st for-loop. After the for-loop is done, the script waits for "firetimeearly = firetime - firedelay" seconds before running the 2nd for-loop to turn the fire back off. The "delay_leftfar" and "delay_rightfar" threads are also almost the same as, but "firetimeearly = firetime - firedelay2", and the threads wait for "firedelay2" instead of "firewait" before running the 1st for-loop. - The field detonator script for the left, mid, right detonators has a secondary "otherdets_animonly" thread (parameters: name, animation) to ensure that all 3 detonators do the same "fire" or "idle" animations together. When a detonator is triggered, all 3 are pushed down and disabled, turning on the Fire Fields and spawning fuses. Depending on the detonator's name, the two "otherdets_animonly" threads and the "waitthread .../firefields.scr::det[name]_ignitefields" thread all run. The 3 detonators will not be enabled again until the fire emitters are all gone and "offtime" is done. The detonators also remain in the pushed-in position. Therefore, a player must press USE near one to push all 3 back out and "reset the detonators". While the detonators are disabled, no messages are printed and nothing occurs until the "offtime" has finished. The fusetime, firetime, waitmultiplier, and offtime are parameters available for each detonator. In the Training map script, the middle detonator has fuses that travel faster (5 seconds), while the left/right detonators have fuses that travel slower (8 seconds). - Parameters (a): center origin of all fire emitters (should be the very center of the gun range field). - Example (a): exec .../firefields.scr ( 3384.5 2395 -395 ) - Parameters (b): name (left, mid, right), origin, angles, fusetime, firetime, fire start waitmultiplier, offtime. - Example (b): exec .../training_detonator_field.scr mid ( 3384.5 2395 -395 ) ( 0 90 0 ) 5 10 0.2 60 - (14.) trenchbombs.scr & training_alarmswitch_trench.scr: The Trench Bombs script spawns in up to 24 entities of bangalores and explosion emitters. Only one other thread ("blowup") is in this script, which is called by "training_alarmswitch_trench.scr" per bangalore to blow each one up. The "blowup" thread has parameters: name, offtime, damageradius, pulsatingoff. In this thread, a red-pulsating ghost where the bangalores used to be will either be on until "offtime" has ended (pulsatingoff = 0), no ghost will appear (pulsatingoff = 1), or the ghost will pulsate red for only 12 seconds after blowing up (pulsatingoff = 2). Once "offtime" has ended, the bangalores reappear and the alarm switches are triggerable again. - The trench alarm switch script spawns in an alarm switch near one side of the trench. Since only 2 are needed, the alarm switch's "name" can only be "tents" or "tank". This script contains the timings between each explosion. There are 8 bangalores total: 2 on both ends facing the Allies/Axis spawns, and 6 on the outer walls of the trench, but each alarm switch only blows up 6 of them (does not blow up the 2 bangalores next to the triggered alarm switch). Blowing up the trenches will kill almost every player still inside. When an alarm switch is triggered, an "otherswitch_animonly" thread similar to the one in "training_detonator_field.scr" ensures the opposide-side alarm switch is animated simultaneously. Then, randomized wait times between 0.25 and 1.25 seconds occur between each "thread .../trenchbombs.scr::blowup" line, allowing the timings between each bangalore explosion to be different every time an alarm switch is triggered (could be very fast, could be slow). The 2 bangalores next to each other on the opposite side of the trench blow up at the same time. The last "trenchbomb.scr::blowup" thread to run is a "waitthread", allowing "offtime" to begin counting after the last bangalore (pair of 2) explodes. Depending on the "manualreset" parameter (0 = no, 1 = yes), the alarm switches may need to triggered again to flip them back up ("reseting the alarm switch"). - Parameters (a): scale (only the fx_truck_explosion fireball emitters, not the mortar_dirt_nosound emitters). - Example (a): exec .../trenchbombs.scr 1.5 - Parameters (b): origin, angles, offtime, damage radius, pulsatingoff (0 = on until offtime ends, 1 = off, 2 = pulsating only for 12 seconds) manualreset (0 or NIL = no, 1 = yes). - Example (b): exec .../training_alarmswitch_trench.scr tents ( -3144 208 -254 ) ( 0 -180 0 ) 75 450 2 - (15.) finalfield_bombs.scr & training_detonator_final.scr: The Final Field Bombs script spawns in up to 18 entities of mine explosions (5 rows of explosions) and final-bomb explosions (row of 4 explosives above the cement gun range window, near the red final door; and emitters). The final-field detonator script spawns in a detonator in the center of the final mg42 gun range field, on the far end of the central cement line. The script begins when the "bombfield" thread (parameters: origin, fusetime, offtime, mine_damageradius, pulsatingoff) runs after "training_detonator_final.scr" is triggered. Similar to "firefields.scr", only one fuse travels down the the final field, along the cement line below the detonator, and stops traveling once it reaches the gun range window. Any explosive barrels in the final field, not including the 7th objective ones next to the final detonator, will be blown up. Before the fuse begins moving, a 2nd thread "mines" (parameters: fusetime, damageradius) starts waiting for "time" seconds ("time = (fusetime * 919) / 2658", time it takes fuse to travel to 1st explosion; 919 units to 1st row, 2568 units to cement windows). Then, the 1st row of explosions occurs, only one explosion emitter on the rightside (if facing the gun range window). The script waits for a new "time" seconds ("time = (fusetime * 510) / 2658, time it takes fuse to travel between 1st row of emitters and 2nd row, also the same between 2nd-3rd, 3rd-4th (4th row is right next to the fuse's destination, so no additional time needed betweeen 4th row and the gun range windows). Either the leftside or rightside emitter will explode in the 2nd and 3rd rows, depending on a randomized integer 0 or 1, while the opposide emitter in the same row will explode after a randomized time of "rdec1" or "rdec2", or after 0 to 0.2 seconds. The 4th and final row only has one mine explosion emitter at the fuse's destination, in the middle of the field and next to the cement windows, which blows up and ends the thread. Back in the "bombfield" thread, a "waitthread finalbombs" (parameters: offtime, damageradius, pulsatingoff) runs after the fuse is gone. This thread contains the 4 large explosions inside the cement gun range windows. The 4 small green exlosives blow up and debris rains down in front of the windows shortly after the 4th row of the central mine explosion occurs, and after a randomized amount of time (between 0 and 2.5 seconds). Only 2 of the 4 explosions play an explosion sound, randomized between two possible sounds. If pulsatingoff = 0, then the 4 green explosives will have red pulsating ghosts visible until "offtime" is done. If pulsatingoff = 1, then no red pulsating ghosts appear. If pulsatingoff = 2, then the red pulsating ghosts appear for only 8 seconds. - The final-field detonator script is similar to "gen_switches/detonatorswitch.scr, but this script runs "waitthread .../finalfield_bombs.scr::bombfield" when the detonator is triggered, waiting until "offtime" duration is done. When triggered again, the detonator "resets" and is pushed back up to the idle position. If "fusetime" is specified as 0 instead of an integer, then the script will randomize the fusetime between 2 and 5 seconds each time the final-field detonator is triggered. The "minedamageradius" parameter only specifies the explosion radius for the 6 explosions in the field, not the 4 explosions inside the gun range windows. - Parameters (a): none - Example (a): exec .../finalfield_bombs.scr - Parameters (b): origin, angles, fusetime (if 0, then randomize 2-5 seconds), offtime, minedamageradius, pulsatingoff (0 = on until offtime ends, 1 = off, 2 = pulsating only for 8 seconds). - Example (b): exec .../training_detonator_final.scr ( 5495 193 -395 ) ( 0 90 0 ) 0 45 400 2 - (16.) bangalore_wallbomb.scr & training_alarmswitch_gunrange.scr: These scripts can easily be added to other maps. The Bangalore Wall Bomb script spawns in a bangalore, a fireball explosion emitter (fx_truck_explosion), and a falling-debris emitter (explosion_bombwall). The alarmswitch gun range script spawns in an alarm switch whose name is specified with the same name as a Bangalore Wall Bomb. When the "blowup" thread is called (parameters: name, offtime, damageradius, pulsatingoff), a randomized time delay of 0 to 1.5 seconds occurs before the explosion occurs (radius can be adjusted with "damageradius" parameter; damage is always 300). One of 5 randomized explosion sounds are played. The script then waits for "offtime" to finish before ending the thread. If pulsatingoff = 0, then a red pulsating bangalore ghost will appear until "offtime" is done. If pulsatingoff = 1, then no red pulsating ghost appears. If pulsatingoff = 2, then the red pulsating ghost appears for only 8 seconds. - The alarmswitch gun range script is similar to "gen_switches/alarmswitch.scr, but this script only runs one "waitthread .../bangalore_wallbomb.scr::blowup" when the alarmswitch is triggered, waiting until "offtime" duration is done. If manualreset is 0 or NIL, then the alarmswitch will automatically flip back to idle and reset once "offtime" is done. If manualreset = 1, it must be triggered one more time in order to "reset the alarmswitch". - Parameters (a): bangalore name, origin, angles, horizontal distance from bangalore, vertical distance from bangalore. - Example (a): exec .../bangalore_wallbomb.scr b1 ( 4441 -2528 -190 ) ( 60 -90 0 ) 100 0z - Parameters (b): origin, angles, bangalore name, offtime, damageradius, pulsatingoff (0 = on until offtime ends, 1 = off, 2 = pulsating only for 8 seconds), manualreset (0 or NIL = no, 1 = yes). - Example (b): exec .../training_alarmswitch_gunrange.scr ( 4800 -2814 -311 ) ( 0 0 0 ) b1 60 430 2 - (17.) airstrike_radiotrig.scr: Arguably the 2nd most complex trigger script besides the radiobomb-walkies, this script spawns in a military radio that can be triggered multiple times to cycle through radio-static loopsounds (similar to radios_musictrig.scr). However when "offtime" has passed, the radio begins pulsating red, ready for a player to hold the USE key for 4 seconds to play a "sendtransmission" sound. After 4 seconds of holding USE, the radio calls in an airstrike to bomb the opposite side of the map from the triggered radio. The script begins in "main" when a player first triggers the radio before "offtime" is done. A state machine is set up as a "state" variable for the radio trigger, where 0 = none (initial state), 1 = not ready, 2 = ready, 3 = holding USE, 4 = successfully called an airstrike. The trigger's setthread is "notready" at first, and the main thread does not continue until "offtime" is done. In this "offtime" while-loop: triggering the 1st time loops a radio static sound, the 2nd triggering loops a different radio static sound, the 3rd triggering stops the loopsound. The "notready" setthread tells the player that "airstrikes are not available yet," while keeping the trigger's "state = 1". Once "offtime" is done, the radio trigger's gets a new setthread: "ready", and state = 2. The radio begins pulsating red and a new while-loop waits until "state = 4." When a player is holding the USE key near the radio (as long as "level.airspace_toobusy = 0", or when other airstrikes are not occuring), the "ready" thread's while-loop begins counting to 4 seconds and displaying a stopwatch (the trigger's "state = 3"). The while-loop in "main" that is waiting until "state = 4" also has an if-statement for looping 1 of 2 randomized radio morse-code sounds while "state = 3". If the player fails to hold USE for 4 seconds (or dies, or changes teams, or airspace gets too busy again), the trigger's "state = 2", stopping the morse-code sounds. However, if the USE key was held for 4 seconds, an "Airstrike Called!" iprint message is displayed. Back in the main thread, the while-loop ends and a "sendtransmission" sound is briefly played, along with a human dialogue sound saying "Explosives Ready!". The dialogue sound is in English if the player is on the Allies team, German if on the Axis team, or randomized between those two if the gametype is free-for-all. Lastly, the two bomberplanes are spawned in after the "airstrikebombs.scr::splinepath_change" exec runs, before resetting the radio trigger and starting at the top of "main" again. "Add code here" line comments were also added around the "airstrikebombs.scr" exec lines, in case a future modder wants to use the airstrike_radiotrig.scr script for different airstrikes, or any other functions. - Parameters: bomberplane's pathname ("allies", "axis", or "final"), origin, angles, offtime, bombsoff (0 = bombs on, 1 = bombs off), bulletstokill (default = 10 bullets), killtime (default = 2.5 seconds). - Example: exec .../airstrike_radiotrig.scr allies ( -4868 753 -256 ) ( 0 340 0 ) 180 0 10 2.75 - (17b.) airstrikebombs.scr: This script packs together everything related to bomberplane airstrikes, dropping bombs, bomb drop coordinates, and splinepaths. The script starts (when airspace is not busy) by spawning in an airplane at the first spline path origin (if "pathname" = allies, spawn a p47 plane; if "pathname" = axis or final, spawn a fockwulf plane). Two other threads run for each plane: "damagetrigger" and "killplane". In "main", the plane begins playing a flyover sound in and looping an idle sound before running the "bombdropcoords" thread (parameters: pathname, position), only running if "bombsoff = 0". If the plane's "position = second", then this plane waits 1 second before traveling down the splinepath. If the plane's "position = first", then this plane waits 1 second after reaching the last splinepath node (ensures that both first and second planes' main threads end at the same time). As long as "offtime" = 0 or NIL (the "offtime" for the planes is already in "airstrike_radiotrig.scr"), the plane will not continuously do airstrikes after each "offtime" duration has passed. This script can only spawn two planes at a time for each airstrike: "position = first" or "second". The "airstrikebombs.scr::splinepath" thread is initialized in the map's main script before any "airstrikebombs.scr" scripts are loaded. This thread spawns all 12 nodes for only the Allies-side p47 splinepath, and the target paths between the nodes. In order to minimize the number of entities, only 1 of 3 splinepaths (for allies, axis, final) are spawned in the map at any given time. The "splinepath_change" thread (parameters: pathname) changes the node origins and target paths whenever a radio trigger with a different pathname (allies, axis, or final) is triggered. The "splinepath_change" thread should ideally have "waitframe" after it runs, and before the main thread in "airstrikebombs.scr" runs. The "bombdropcoords" thread is called one time per plane (one for "first", one for "second") in the "main" thread, before the plane begins moving. This thread contains all coordinates for each bomb to be dropped from the plane. For the Training map, each plane (depending on "pathname" and "position") will drop 12 to 18 bombs, each run by the "dropbomb" thread (parameters: origin, wait time, speed, zrotate, damageradius, position). In the "dropbomb" thread, a script_origin is spawned in at "origin" somewhere on the ground, and a "ammo/us_bomb" is spawned at the bomberplane's current location. The bomb then moves to the script_origin destination with a speed of "speed" and slowly rotating the bomb from horizontal to vertical ("zrotate", front of bomb rotates to point straight down, simulating gravity). Once the ground script_origin is reached, the bomb explodes with an "fx_mortar_dirt" emitter with a specified "damageradius" (damage is always 200). - The "damagetrigger" thread (parameters: position, pathname, bulletstokill) spawns in a trigger_multiple (glued to the plane inside the thread's while loop) that only responds to bullets and explosions occuring near them, and given the setthread "triggered". The "triggered" setthread only incremenents a "triggered" variable. While the plane still exists, if-statements check if the plane trigger was shot at "bulletstokill" times (default = 10 bullets, no smaller than 1) or if the trigger touches any Giant Bombs or Light Bombs fired by players. If somehow a player touches the plane trigger, the player is killed. The "killplane" thread (parameters: position, pathname, killtime) runs a while-loop that waits until the plane was shot at "bulletstokill" times, or touched a Giant Bomb or Light Bomb. If the plane was shot at, a fire emitter and planesmokefly emitter are attached to the plane. While on fire, the plane will not drop any more bombs. Another while-loop waits until "killtime" seconds have passed or if the plane reaches the splinepath node at the furthest skybox corner of the map (technically, waiting until the plane goes beyond the node's x and y coordinates). This while-loop contains 1 of 2 if-statements: if "pathname = allies" or if "pathname = axis" or "final", then spawn explosions at the respective skybox corner. Since the splinepath nodes' coordinates are default if "pathname = allies" and reversed if "pathname = axis" or "final", the map-corner node's targetname ($aa10) is the same in both while-loops. Once "killtime" seconds have passed or if the plane exits the map, an fx_truck_explosion emitter and a barrel_gas_destroyed emitter are spawned at either the plane's current location in the sky, or at the $aa10 splinepath node's origin (sometimes, the plane exits the map's skybox before reaching the final node, for example in The Hunt map; thus most xy coords are +/- 50 units). If the plane touched a Giant Bomb or Light Bomb fired by a player, then the 2nd while-loop with "killtime" is skipped (no fire or planesmokefly emitters either), and the explosion emitters are spawned in immediately. After exploding, all emitters are removed and sounds & loopsounds are stopped. The very last splinepath node is usually 500-1000 units diagonally outside from the skybox corner node, for maintaing the plane's speed as it exits the map. If making your own splinepaths, make sure that both of the final outer-map node's X and Y coords are increased by 500-1000 from the 2nd-to-final node at the map's edge, otherwise the "killplane" thread will not show explosions when the burning plane exits the map, since the planes will be removed once reaching the last node. The last thread "splinepath_seenodes" is for testing purposes only. If "exec .../airstrikebombs.scr:splinepath_seenodes" runs after "exec .../airstrikebombs.scr::splinepath" (and "waitframe" in between them), then all nodes will be shown in the sky indicated by large red corona lights, useful for hashing out the plane's angles between each node. - Parameters (a): none - Example (a): exec .../airstrikebombs.scr::splinepath - Parameters (b): pathname (allies, axis, final), position ("first" or "second"), bombsoff (0 = no, 1 = yes), offtime, bulletstokill, killtime. - Example (b): exec .../airstrikebombs.scr local.pathname second local.bombsoff 0 local.bulletstokill local.killtime - Example (c): exec .../airstrikebombs.scr allies first 0 240 10 2.5 (add this to map's "main" thread only for continuous airstrikes every 4 mins) - (18.) training_valveswitch_final.scr: This script spawns in one of two valves for moving the long banquet table bridge towards the left or right. Behind the gun range field is a big square void in the map's terrain, with the table bridge going between the back hills and the side cement wall. An invisible tele respawns any players that touch the square void (fell out of bounds). The two valve triggers are on opposite corners of the square void. When a valve is first triggered, the "clockwise" variable is attached to the valve script_model (local.valve.clockwise = local.clockwise), and the "othervalve_animonly" thread runs (parameters: name, rotatetime, rotateamount). Inside this thread, the name of the valve is increased by 1 (hence, the names of both valves must be either "1" or "2"), now referencing the opposite-side valve from the triggered valve. Both valves pulsate red while rotating, and both valves' clockwise variables are toggled (either 0 for counterclockwise, or 1 for clockwise). While the valves are rotating, the bridge made of 11 banquet tables moves to the opposite side, with a moving time = "rotatetime". Each table is controlled by a "exec ...training/cratesstuff.scr::movefinaltables" thread (parameters: name, move (0 = move right, 1 = move left), rotatetime). When a valve is triggered again, the bridge moves back to its original position. In the Training map script, one valve begins with "clockwise = 1", the other begins with "clockwise = 0" (looks better than both rotating the same direction). - Parameters: name (must be "1" or "2"), origin, angles, rotatetime, rotateamount (in degrees), clockwise (0 = no, 1 = yes). - Example: exec .../training_valveswitch_final.scr 1 ( 4825 2382 -329 ) ( 0 0 0 ) 5 270 1 - (19.) training_cratesstuff.scr: This script spawns in all the script_model objects found throughout the Training map, including bunker tables, indycrates, banquet tables, lamps, crate lid below the train switch trigger, barbwire boundary walls, tables & chairs inside the hangars & tents, table lanterns, mg42 ammo box, and nontriggerable military radios. There are about 260 entities in this script. If all objects are spawned in, many other mods will not work due to the 1024 maxentity limit. Thus, there are 2 parameters ("nogoingbehindwalls" and "spawnfewerobjects") to spawn fewer than 260 entities. There are 3 more parameters ("midshow", "finalshow", "boundaryshow") to either show or hide some entities, but these 3 parameters are mainly for testing purposes only. "Midshow" controls indycrates and banquet tables that are all hidden behind the Axis-side walls, so nothing changes if "nogoingbehindwalls = 1". "Midshow" should be "0" initially, so the "obj6b_explosive_tanktrig.scr::obj6b" thread can run the "midshow" thread within training_cratesstuff.scr. The "finalshow" thread runs inside the main Training map script when the 4 field objectives are completed (before the mg42 final field). "Finalshow" only controls 16 indycrates for 3 sets of stairs (should also be "0" initially), each going above walls in the mg42 final field. "Boundaryshow" controls the barbwire located at the back edge of the fields behind the dirt hills. If "boundaryshow = 1", then the barbwire is visible, which blocks players from going/shooting under the map. If "boundaryshow = 0", then the barbwire is hidden, but still solid. "Nogoingbehindwalls" spawns or omits spawning in all objects that are found behind walls, or otherwise inaccessible areas to players in MOHAA's original Training map. Making "nogoingbehindwalls = 1" omits spawning in about 70 entities, greatly changing gameplay. When "nogoingbehindwalls = 1", players cannot go behind walls to avoid the Trench Bombs explosions, and blowing up a "static" tank with explosives becomes much harder for Allies to do since the tank is deep in the Axis player spawns. It's ideal to use a "drive" tank if "nogoingbehindwalls = 1". If "spawnfewerobjects = 1", then none of the decorative script_model objects will be spawned, only the essential objects. If "spawnfewerobjects = 0", then the script will spawn in 39 more tent objects, 21 more hangar objects, and 41 more field objects, all mostly tables and chairs. The main thread in this script runs 5 threads: "crates" (parameters: midshow, finalshow, nogoingbehindwalls), "tentobjects" (parameters: spawnfewerobjects), "hangarobjects" (parameters: spawnfewerobjects), "fieldobjects" (parameters: spawnfewerobjects), "boundarywall" (parameters: boundaryshow). There are also 5 threads for controlling some objects after the map has loaded, for example with a switch or after objectives are completed: "midshow", "midhide", "finalshow", "finalhide", and "movefinaltables" (parameters: name integer, move, move time). - Parameters: midshow (0 = no, 1 = yes), finalshow (0 = no, 1 = yes), boundaryshow (0 = no, 1 = yes), nogoingbehindwalls (0 = yes & spawn more objects, 1 = no & no objects behind any walls), spawnfewerobjects (0 = no, 1 = yes & fewer script_model objects). - Example (a): exec .../training_cratesstuff.scr 0 0 1 1 1 - Example (b): exec .../training_cratesstuff.scr::finalshow - (20.) training_teleporters.scr: This script spawns in all the trigger_use red teles and all the trigger_multiple out-of-bounds teles in the Training map. For all the other maps, the scripts containing their tele origins (for example: "dm1_teleporters.scr") are not as simplified as this script, since "tele.scr" was not created yet. See the "tele.scr" section of this readme for more details. Parameters are: 1st tele origin & 2nd tele destination, 1st tele destination & 2nd tele origin, teletype (0 = no 2nd return tele, 1 = yes for two-way tele, 2 = fell out of map & respawn player), setsize1, setsize2, model, scale. Setsize1, setsize2, model, and scale parameters are all NIL (or omitted), unless the "teletype = 2". If the tele is an out-of-bounds tele, then the 2nd coords parameter can = the 1st parameter, since players are simply respawning. Each tele has 2 entities (corona entity and trigger). Teles with "teletype = 1" have 4 entities. The script runs "tele.scr" 18 times for spawning 18 teles or tele-pairs. If "nogoingbehindwalls = 0", then 21 more tele-pairs are spawned in for allowing players to travel behind any map walls that have floors with enough room for players to walk around in. Once the final door is unlocked with the final key in the Training map, "training_teleporters.scr::activate" runs from the "finaldoor_triggertemp" thread in "finaldoor_keytrig.scr". The "activate" thread spawns 4 very small red teles floating about eye-level in the center of all the sky platforms to allow players to travel between them, as well as 2 teles-pairs between final-door exit & sky platform 1 and between sky platform 5 & final-door exit. If the Nazi Tunnel Base script is loaded in the Training map ("tunnelbase_nazi.scr"), then 3 tele-pairs are spawned in instead of the previous 2 tele-pairs: between final-door exit & tunnel base entrance, between tunnel base exit & sky platform 1, and between sky platform 5 & tunnel base exit. When the Nazi Tunnel Base script is loaded, the tele-pair between final-door exit & tunnel base entrance (in the "finaldoor_to_tunnelbase" thread) is specialized to force any player that triggers the teles into facing a specific yaw-angle (player.angles[1]). It's almost always more convenient for a player to keep their current yaw-angle when going through a tele, hence why all other teles in this mod do not force players to face a specific yaw-angle. But in this case, traveling from the long skinny final-door exit to the tunnel base entrance made players run into the tunnel base's wall, while traveling from the tunnel base entrance to the final-door exit also made players run into the wall. - Parameters: nogoingbehindwalls (0 = yes & spawn more teles, 1 = no & no teles to go behind walls). - Example (a): exec .../training_teleporters.scr 1 - Example (b): exec .../training_teleporters.scr::activate <><><> <><><>