Jump to content

sn0wsh00

Members
  • Posts

    59
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by sn0wsh00

  1. I recently created a geodesic dome model for my Vertumnus fight yard maps (Day version, Night version) in CS:GO. I used this video as a guide on how to create the dome: This is probably something very basic for a lot of you guys, but as a 3D modeling noob, I'm pretty proud that I was able to create and import this model into CS:GO without many issues. I mean, Blender isn't exactly MS Paint. I also created a collision mesh for the dome: Model download link: https://drive.google.com/file/d/13xt4h3H4tMMPuA-JY45kW2l-BTw61vrJ/view?usp=sharing
  2. Version 0.33 For this update, I overhauled the layout around Chamber B to make it less CT sided. Here are some GIFs: And here's how these changes look on radar: To summarize, I removed access through the bottom entrance, replacing them with closed doors, and widened the existing side entrance into Chamber B. While you can't enter Chamber B through the bottom entrance anymore, you can still wall-bang through those doors. I also modified the main B path to remove direct access to the vents and connect mid closer to the chamber. In turn, this update should make it quicker to reach the vents going through mid.
  3. Version 0.32 For versions 0.31 and 0.32, I decided to overhaul the appearance of Chamber A and the mid-to-A connector to give them an even more of Asian/Japanese look. Here are some GIFs of the changes: As you can see from the GIFs, I installed a couple of engawas in the chamber, added some furniture in the connector and changed some of the lighting. Some of the assets added in this update were taken from Jingshen. While I think the chamber looks better in this update, I also feel that the engawas might have made Chamber A a bit more cluttered. Would like to hear what other players think about the new layout.
  4. Version 0.3 I made major changes in cs_exodium in update following the 0.21 playtest: In addition to removing the 10 second delay to the T-spawn door, I also added a short delay to the corresponding chamber door when a hostage is picked up (5 seconds in Chamber A, 4 seconds in Chamber B). For example, if a CT picks up a hostage in Chamber A, the door in Chamber A will open 5 seconds later, while the doors at T-spawn and Chamber B will immediately open. If CTs somehow manage to pick up both hostages at the same time, then there will be no such delays. I overhauled paths between the chambers and warehouses so that they are now outdoor walkways instead of hallways Given that CTs had a major advantage attacking Chamber A, I decided to remove access to the offices above Chamber A, leaving only two CT entrances into A. CTs still have 3 entrances into Chamber B To declutter Warehouse B, I removed the Exodium-branded trailer. Don't worry, you can see still see it in the junkyard near the Chamber A to Warehouse A/B path. Players can now rotate around the hostage rescue zone. A bunch of crates were added to prevent a single player from guarding all three exits at once. Warehouse-Chamber paths are now directly to the back of the hostage chambers, so to encourage the terrorists to defend inside the chambers, instead of the hallways behind the chambers Finally, I added a some detailing, such as barb wires and gravel patios And now, on to the GIFs. First up, hostage chambers: Gravel patio in front of Chamber B: And in front of T-Spawn: Chamber to warehouse paths: Decluttering Warehouse B: The hostage rescue zone: And finally, the map overview:
  5. I recently completed a playtest of this map (h/t MapINK). Here are some highlights/lowlights from that playtest: Some takeaways from this playtest: As I suspected, the map was heavily CT-sided. Once a CT picked up a hostage, it was almost always a guaranteed win for the CTs. Overall, CTs won 20 out of 26 rounds. Relatedly, many players got frustrated by the fact that they could not rotate around the hostage rescue zones, which were located in three disconnected areas. I had intended for players to rotate around the warehouses in front of the rescue zones, but I guess the rotations between the warehouses just didn't play well Players also hated the fact that the door at T-Spawn had the 10 second delay. Given that defending the hostage rescue zone was hard enough, adding the 10 second delay was just another unnecessary (and confusing) obstacle. With regards to aesthetics, players disliked the hallways between the hostage chambers and the warehouses. They preferred that those paths be outdoors. On the plus side, players really enjoyed the vents in Chamber B. Another major issue I noticed from this map, but was not mentioned during the playtest, was that the paths leading to the warehouses connected not to the hostage chambers themselves, but instead to the hallways behind the chambers. This led to some terrorists camping in said hallways instead of in the chambers, something I definitely did not want to happen. Directly connecting the chambers to the warehouses will hopefully encourage the chamber camping. I'm currently overhauling the map based on this feedback. Hopefully I can release version 0.3 soon.
  6. Version 0.2 update After a playtest, I've decided to make more changes to cs_exodium. First, I modified the shed between Warehouse A and B to make it easier for remaining Ts to stop CTs going through Warehouse A. In version 0.11, CTs going from Chamber A can reach Warehouse A before Ts can, even when carrying a hostage (assuming remaining Ts were guarding Chamber B beforehand). This makes it incredibly easy for CTs to simply slip into the rescue zone A without encountering any terrorists. For version 0.2, I decided to allow Ts a line of site from Warehouse B into Warehouse A. You can see what I'm talking about in the GIF below (terrorists running from Chamber B will arrive at the spot where these screenshots were taken seconds before a CT carrying a hostage will arrive at Warehouse A): Another thing I did was to further discourage terrorists from camping a T-spawn. It did this two ways. First, I added obstacles in the tunnels between T-spawn and the Warehouse, forcing terrorists to sometimes crawl. These obstacles increase the travel time through the tunnels from 3 seconds to 5 seconds. Secondly, I added a pit-like area in front of the doors to the tunnels. Thus, any Ts that try camping at the tunnel doors will be extremely vulnerable to any incendiary grenade CTs chuck over the crates and plant exhibit.
  7. Version 0.11 update Based on feedback I received so far, I've made a few changes to the map. First, I simplified the hallways between the hostage chambers and the central rescue zone. The original path to the center warehouse required players to make a U-Turns, which tends to ruin player flow. This update removes the U-Turns and replaces them straight paths. Here's a GIF showing off the change in layout: Secondly, a lot of people commented on how hostage rescue mode's economy needed to be fixed. In turn, using Vscripts, I created a custom economy that is more in-line with defuse mode's economy. Here are the rewards in this new economy: CT player reward for picking up hostage: $300 (same as default) CT team reward for picking up hostage: $800 (originally $600) CT team reward for eliminating Ts: $3250 (originally $3000) CT team reward for each hostage rescued: $0 (originally $600) CT team reward for winning by hostage rescue: $2700 (originally $2900) T team reward for eliminating CTs: $3250 (originally $3000) T team reward for winning by running out the time: $3250 (same as default) All other cash rewards remain the same (loss rewards are the same in both defuse and hostage rescue). I also decided to keep the $1000 reward given to the individual players that rescue hostages, to offset potential penalties for injuring hostages. This custom economy only works in the custom game mode.
  8. After creating several AIM and FY maps, I decided to start working on a hostage rescue map. After about a month of work, I'm proud to present Exodium: Download (version 0.33): Steam Workshop Gamebanana This map is my attempt to re-balance hostage rescue mode so that it wouldn't be so T-sided. To do this, I did two things. First, I placed the hostages into two separate locations, similar to how bombsites are located on defuse maps. Thus, unlike a map such as Assault or Office, terrorists will now have to split up to effectively guard the hostages. Secondly, I made the map dynamic. Instead of returning to CT spawn when a hostage is picked up, the CTs instead go to a new area that becomes accessible to rescue the hostage (see blue area in layout). More specifically, there are three doors to the hostage rescue zone that are closed at the start of each round (marked in red). The two doors near the chambers will open when the CTs pick up the hostages, while the door at terrorist spawn will open after a 10 second delay, to discourage terrorists from camping at T-spawn. When a CT picks up a hostage, the round becomes a footrace to the rescue zone. Because the player carrying a hostage moves at only 200 units/second (as opposed for 250 units/seconds for knife players), the terrorists still have a chance to cut off the CTs before they reach the rescue zone. However, I also placed three separate rescue zones in three separate lots/warehouses, thus terrorists will have to choose which rescue zones to guard when they reach the back area. If they camp the wrong rescue zone, then the CT might easily slip past them undetected. Thus, CTs have a massive advantage when they reach a hostage, which I think it's fair given that reaching the hostage in my opinion should be the equivalent to planting a bomb in defuse mode. I got this idea of a dynamic hostage rescue map from @El_Exodus, who first proposed this back in 2016. This is also why the map is named, well, Exodium. And now, more screenshots: Lobby near CT spawn Hallway to Chamber A Chamber A Mid Route to Chamber B. You can also see a bit more of the skybox I created in SpaceEngine. Chamber B. Influenced by de_cache's bombside B. One of the warehouses near to the rescue zone. You can also see signs the the other two rescue zones in this screenshot. While all the brushes are textured, cs_exodium is still in the early stages. Would really love to hear feedback regarding my tweaks to the hostage rescue mode, as well as the map in general.
  9. After working on a bunch of FY and AIM maps, I finally decided to start working on a hostage rescue map. Here are some screenshots, I guess: The more important thing I want to share, though, is this layout: This map is another attempt at balancing the hostage rescue mode to give CTs a better chance at winning. First, you'll see that the two hostages are placed far apart, similar to how bombsites are located on defuse map. Also, because T weapons are stronger than CT weapons, I gave CTs more attacking routes into each hostage chamber than Ts. The biggest change I made, though, was that I made the map dynamic. The area highlighted in blue are inaccessible at the start of each round and are blocked off by three doors (marked red in the layout). When a hostage is picked up, the two doors nearest the hostage chambers will immediately open, while the door at T spawn will open 10 seconds later (to discourage Ts from camping at T spawn). After a CT picks up a hostage, the round becomes a race to the rescue zones at the back at the map, with the CTs having major advantage (similar to how Ts have a major advantage once a bomb is planted in defuse mode). However, because the CT carrying the hostage moves really slowly (200 units/s), the Ts still have a chance to intercept the CTs near the rescue zone. But the Ts will have to decide quickly where to go, because there are three rescue zones the CTs can choose from. I got this dynamic hostage rescue map idea from @El_Exodus, who proposed something like this back in 2016. And this why I named this map... Exodium. You can take an look at what I've made so far here: https://steamcommunity.com/sharedfiles/filedetails/?id=2459039008
  10. Some custom skybox terrain I created using World Machine and Twister: This custom terrain can be found on my map am_frozen_fortress. You can read more about how I generated this here.
  11. For the final spinoff map, I decided to create a custom terrain for the 3D skybox with the help of World Machine: Map download (am_frozen_fortress): Steam Workshop Gamebanana The heightmap and texture image for this terrain was created in World Machine, while Twister was used to convert the heightmap to displacements. In Twister, the settings I used were a length and width of 8192, a height of 3072, a power of 3 and a displace resolution of 16 (256 tiles total). And here was how my logic chart looked like when I created the heightmaps and textures (only the "Outputs with snow" outputs were used):
  12. For those of you who have played Payday 2, here's something inspired by the Diamond Heist puzzle that I created in CS:GO: This puzzle was created using func_door, logic_case and math_counter entities and can be found on my map am_jungle_pit. You can find a general explanation on how I did this here.
  13. For the spinoff of aim_six_arenas' jungle room, I created a random path generator thing inspired by Payday 2's Diamond Heist puzzle: Map download (am_jungle_pit): Steam Workshop Gamebanana This generator was created using math_counter, func_door and logic_case entities, with the func_door platforms arranged in a 5x7 grid (5 columns, 7 rows). The path will always move straight in rows 1, 4 and 7. In rows 2, 3, 5 and 6, on the other hand, the path can move either left, right or straight. If path moves right or left in row 2, the path in row 3 will move the same direction in row 2. Same concept applies to rows 5 or 6. The math_counter entities raise the func_door platforms when they reach the max value, and they also activate corresponding logic_case entities. The logic_case entities present cases that either causes the path to continue going left or right, or to go to the next row on the grid. In rows 2, 3, 5 and 6, each platform has two corresponding math_counters. One set of math_counter are used when the path is going right, while the other set of math_counter entities are used when the path is traveling left. Within these rows, platforms in column 2 through 4 also have two corresponding logic_case entities, while the platforms in the outer 2 columns have 1 corresponding logic_case entity. Like with the math_counter entities, one set of logic_case entities are used when the path is going right, while the other set of logic_case entities are used when the path is traveling left. Because the path can't travel anymore left or right in columns 1 and 5 respectively, only a single logic_case entity is needed for platforms in those columns (e.g. if a path in row 2 is traveling right, when it reaches column 5, the only thing the path can do is move onto row 3). Here's a screenshot from Hammer showing off how I arranged the entities:
  14. Not a screenshot, but I did recently create a Monty Hall problem simulator mainly using logic entities. In my version, the cars and goats have been replaced with cash and fire: And here's a couple of videos of me running 100 simulations: The process of creating this simulator is a bit long and you can read about it here. However, the AddOutput command was very useful preventing the map igniting the same button the player picked during the first round (i.e. preventing something like this from happening). You can test this simulator out yourself on my map am_muntions_cache. It's a secret area, but it's pretty easy to noclip to.
  15. The process on how I made the Monty Hall problem simulator is pretty lengthy, so I'm going to create a separate post for this. A challenge in creating a Monty Hall problem simulator is preventing the map from burning the same button the player picked during the first try. To do this, I made each button have a corresponding set of logic_branch, logic_compare and math_counter entities . The logic_branches tells the map which button is eligible to be burned after the first press, while the logic_compares determines whether or not the player used a safe button (i.e. the button that will open the door) during the second press (each button's corresponding math_counter entity also only activate during the second press). Both logic_branch and logic_compress have initial values of 1, while the logic_compare also has a compare value of 1. At the start of each round, the map, via a logic_case, chooses which button will be the button that'll open the door by disabling a button's corresponding logic_branch and logic_compare entities. To disable these entities, the map sets logic_branch's initial value to 0 and logic_compare's compare value (which, remember, is separate from logic_compare's initial value) to 0 (false). When a player uses a button during the first press, the button will do three things: add 1 to an overall math_counter entity (which I will name press_1st_counter), add 1 to the button's corresponding math_counter entity and disable (i.e. sets false) the button's corresponding logic_branch. If a player presses the door-opening button for the first press, then there will be no corresponding logic_branch entity to disable. Press_1st_counter has a maximum legal value of 1 and only activates when the first press (and only the first press) occurs. After Press_1st_counter reaches is max value (i.e. 1), Press_1st_counter sends out a Test output to the logic_branch entities. When the logic_branches receive the Test input from Press_1st_counter, all logic_branches whose value are still true will send an AddOutput command to an empty logic_case entity. These AddOutput commands add cases to the empty logic_case entity, essentially building a logic_case from scratch. You can see how the Output tab for one of the logic_branches look like below: With a newly assembled logic_case entity, we can now send a PickRandom command from the button to that formerly empty logic_case entity, the later then randomly choosing a button to ignite. Because the logic_branch entity corresponding with the first picked button did not send an AddOutput command (due to it being false) to the empty logic_case entity, the map will never choose to ignite the button the player pressed on the first attempt. Making the second press work is much simpler than the first press. Recall that each button has a corresponding math_counter that only activates on the second press, and that the map had set the safe button's logic_compare compare value (NOT the initial value) to 0. On the second press, the button's corresponding math_counter entity sets the logic_compare's initial value to 0 and then compares the initial value to the compare value. If they are equal, logic_compare will open the door. Otherwise, logic_compare sets the button on fire.
  16. I recently released another spinoff of AIM_Six_Arenas, this time a de_cache themed arena called Munitions Cache (am_munitions_cache). You can download this map at the following links: Steam Workshop Gamebanana The thing about Munitions Cache is that the main area is very similar to de_cache's 1v1 warmup arena. In turn, I thought it would be a great map to add secrets to. The first secret is a short obstacle course with round-to-round variations that you have to complete in 60 seconds. The secret is a Monty Hall problem simulator, created using only logic entities. Here's a video demonstrating how the Monty Hall problem simulator works, as well as a logic path visualization: And here's a video of me running 100 simulations: And here's a video who want their simulations in Python chart format:
  17. sn0wsh00

    [AIM] Dune Arena

    It's rare to see AIM maps use detailed custom textures and models, so it's a really nice change of pace to see something like your map. Great job, even if I feel like AKs and deagles are overused on these types of maps.
  18. sn0wsh00

    [CS:GO] de_sapper

    Just played both versions and so far everything looks really great. The hostage at E1 looks really easy to camp, but overall, I couldn't find any blatant gameplay issues, at least with the hostage version. Can't wait to see the finished map. Great job with that barbershop painting as well. Definitely something worth getting a mild case of carpal-tunnel over. From a lore perspective, I would have personally chosen someone else other than the GIGN for the CT side given that Sierra Leoneans speaks English. Preferably, I would have the CTs be based on something like the Sierra Leone police, given that I think it would kind of cool for a map set in an "exotic" location to feature local factions as opposed to foreign ones. But that's my personal take.
  19. If you had taken a look at the Steam guide, you'll see that I recommend the math_counter method to randomize weapons in CS:GO. This is because having a single trigger_multiple for each side makes it much easier when you want to enable or disable random weapons depending on game mode. Suppose you want random weapons to be only enabled in custom. Also say that you want buy zones to be enabled in casual/competitive modes. To do this: Follow the steps in the previous post for weapon randomization, but this time, set the Start Disabled property for the two trigger_multiple entities to Yes. Create func_buyzone entities and give them a name such as buyzone_ent Create the following .nut VScript and place it somewhere in the in the CS:GO scripts folder (as usual, special thanks to @Kokopelli for providing the original code): function FixGameMode() { local nMode = ScriptGetGameMode(); local nType = ScriptGetGameType(); local nRounds = ScriptGetRoundsPlayed(); if (nMode == 0 && nType == 3) { EntFire("buyzone_ent", "Disable", 0, 0); if (nRounds == 0) { SendToConsole("mp_respawn_immunitytime 0; mp_roundtime 3; mp_maxrounds 30; mp_warmuptime 1; mp_timelimit 0; bot_chatter normal; mp_friendlyfire 1; ff_damage_reduction_bullets 0; ff_damage_reduction_other 0; mp_randomspawn 0; bot_quota_mode fill"); } //Allows cvars to be changed later EntFire("wep_spawn_t", "Enable", 0, 0); EntFire("wep_spawn_ct", "Enable", 0, 0); // custom. Random weapons } if (nMode == 1 && nType == 0) { SendToConsole("mp_warmuptime 1; bot_quota_mode normal"); // competitive. Changed bot_quota_mode } if (nMode == 2 && nType == 1) { SendToConsole("bot_quota 2"); // deathmatch. Changed bot_quota } } What the script above will do is disable the func_buyzone entities and enable the trigger_multiple entities when game_type is set to 3 (aka custom game mode). This code also sends commands to the console so that custom mode can feel more classic-mode like, but only sends those commands in round 0, so that you can still change cvars such as mp_maxrounds without those cvars resetting every round. Because I already set trigger_multiple to be disabled in Hammer, I do not need to send additional console commands for the other game modes to disable trigger_multiple. Back in Hammer: Create a logic_auto entity and and a logic_script entity. Name the logic_script entity to something like map_script Under map_script's Entity Scripts, add the .nut file you created In logic_auto's output table, create an output named OnMapSpawn, a target of map_script, a Via this input of RunScriptCode and a parameter override of FixGameMode(). Weapon randomization will now only work in custom mode I've made a map showing off these concepts here: https://drive.google.com/file/d/1O87dIP_xc7RTe5fttYW6sNsRKoRPqSRd/view?usp=sharing Or if you want a more complex map that utilizes these concepts, check out my map Showdown Planet.
  20. And for those who were wondering, here's the VScript code I used to enable random weapons in only specific modes (shoutout again to @Kokopelli for writing the original script): function FixGameMode() { local nMode = ScriptGetGameMode(); local nType = ScriptGetGameType(); local nRounds = ScriptGetRoundsPlayed(); if (nMode == 0 && nType == 3) { EntFire("buyzone_trigger", "Disable", 0, 0); if (nRounds == 0) { SendToConsole("mp_respawn_immunitytime 0; mp_roundtime 3; mp_maxrounds 30; mp_warmuptime 1; mp_timelimit 0; bot_chatter normal; mp_friendlyfire 1; ff_damage_reduction_bullets 0; ff_damage_reduction_other 0; mp_randomspawn 0; bot_quota_mode fill"); } EntFire("wep_spawn_t", "Enable", 0, 0); EntFire("wep_spawn_ct", "Enable", 0, 0); EntFire("spawn_1", "SetEnabled", 0, 0); // custom. Random weapons, allows up to 24 players } if (nMode == 1 && nType == 0) { EntFire("buyzone_trigger", "Disable", 0, 0); EntFire("wep_spawn_t", "Enable", 0, 0); EntFire("wep_spawn_ct", "Enable", 0, 0); EntFire("spawn_1", "SetDisabled", 0, 0); SendToConsole("mp_warmuptime 1; bot_quota_mode normal"); // competitive. Random weapons, limit to 12 players } if (nMode == 0 && nType == 1) { EntFire("wep_spawn_t", "Disable", 0, 0); EntFire("wep_spawn_ct", "Disable", 0, 0); // arms race } if (nMode == 1 && nType == 1) { EntFire("wep_spawn_t", "Disable", 0, 0); EntFire("wep_spawn_ct", "Disable", 0, 0); EntFire("spawn_1", "SetEnabled", 0, 0); // demolition } if (nMode == 0 && nType == 0) { EntFire("wep_spawn_t", "Disable", 0, 0); EntFire("wep_spawn_ct", "Disable", 0, 0); EntFire("spawn_1", "SetEnabled", 0, 0); // casual. Buyzones, allows up to 24 players. } if (nMode == 2 && nType == 1) { EntFire("wep_spawn_t", "Disable", 0, 0); EntFire("wep_spawn_ct", "Disable", 0, 0); // deathmatch } if (nMode == 2 && nType == 0) { EntFire("wep_spawn_t", "Disable", 0, 0); EntFire("wep_spawn_ct", "Disable", 0, 0); // wingman } } I'm pretty sure there's a lot of lines that are unnecessary in my script, but hey, this was my first attempt at VScript. Also, unless I completely screwed up my CFG files, I think all the default settings for custom gamemode are just horrible! It's like if deathmatch elements (time limits, buy time immunity) somehow got mixed up with competitive mode (solid players, spectate only own team etc.). Huge shame map specific CFG files don't work anymore.
  21. After a few weeks of work, I'll like to present my second aim_six_arenas spinoff map: Showdown Planet Download: Steam Workshop Gamebanana Like with aim_six_arenas, the game starts off as a series of six 1v1 duels. After 30 seconds, though, instead of doors unlocking to an interconnecting hallway, all surviving players get teleported to a seventh arena for a final showdown. Also, unlike in the original map, which mean to be a collection of six soundstages at a building complex, the six arenas on this map are meant to represent different locations on earth, which means the arenas in this spinoff are far more detailed than their aim_six_arenas counterparts. You can take a look at some comparison GIFs I made here. The initial six arena themes and weapon matchups remain the same, but Showdown Planet adds two new arenas to serve as the seventh arena. One arena is a hallway undergoing renovations, based off of aim_six_arenas' hallway. The other arena is a remake of the classic aim_map, this time set in space. The map randomly chooses between these two new arenas to serve as the seventh arena. This map supports up to 24 players, depending on game mode, which allows for 2v2 matchups in the initial arenas. Thanks to the wonders of Vscript, I've managed to make Showdown Planet play differently depending on gamemode: Competitive: Random weapons, limited to 12 players. Highly recommended if you only want to play 1v1 in the 6 arenas Custom: Random weapons, allows up to 24 players Casual: Buyzones, allows up to 24 players Demolition/Flying Scoutsman: Normal gameplay, allows up to 24 players. Credits @Kokopelli's Snowball Fight - Country House, for providing the Vscript template I used for disabling entities based on game mode @TopHATTwaffle's Real World Textures and Real World Textures 2 In addition to Valve's maps, this map also uses textures and models from de_studio, de_swamp and de_subzero Earth skysphere texture created in SpaceEngine Earth logo in thumbnail: https://www.clker.com/clipart-black-and-white-globe.html
  22. Just added a new way to randomize weapons to the guide. You can read how I did it on Steam, but I'll post the method here on Mapcore as well because it's always good to have a backup. So, suppose you want a round where the terrorists and counter-terrorists spawn with a Tec-9 and Five-Seven respectively, and another round where they spawn with a Glock and a USP-S. To do this, Create a logic_eventlistener entity and name it ListenRoundStart. Set "Event Name" to round_start. Create two filter_activator_team entities. Name one filter_t and the other filter_ct Create two math_counter entities. Name one counter_ct and the other counter_t. For both counters, set the minimum legal value to 0 and the maximum legal value to 20. Create four game_player_equip entities. Name them equip_ct_usps, equip_t_glock, equip_ct_57 and equip_t_tec9 For all four game_player_equip entities, make sure the "Use Only" and "Strip All Weapons First" flags are checked Disabling SmartEdit, add entries for weapon_knife for the four game_player_equip entities. Keeping SmartEdit disabled, add an entry of weapon_usp_silencer for equip_ct_usps, weapon_glock for equip_t_glock, weapon_fiveseven for equip_ct_57 and weapon_tec9 for equip_t_tec9. You should have two weapon entries for each game_player_equip, as shown here. Create a logic_case entity called counter_chooser and create two outputs for OnCase01 and two outputs for OnCase02 For the first OnCase01 output, set target entity to counter_ct and input to SetValue. For the other OnCase01 output, set target entity to counter_t. For both OnCase01 outputs, set parameter override to 10. Do the same thing for the two OnCase02 outputs, but set the parameter override value for those outputs to 20. The output table for counter_chooser should look like this. Create two more logic_case entities named logic_ct_chooser and logic_t_chooser Under class info for both logic_ct_chooser and logic_t_chooser, set the Case 01 value to 10 and the Case 02 value to 20, as shown here. Under logic_ct_chooser outputs tab, create an output for OnCase01 with a target entity of equip_ct_usps and a "Via this input" of Use. Because Use is not a default FGD input, the word "Use" will appear red. Don't worry about this, though, as CS:GO will recognize this input. Create an output for OnCase02, and do the same thing you did with OnCase01, but replace the target entity with equip_ct_57. The logic_ct_chooser outputs tab should now look like this. For logic_t_chooser, do what you did with logic_ct_chooser, but replace the the target entities of equip_ct_usps and equip_ct_57 with equip_t_glock and equip_t_tec9 respectively Returning to counter_t, go the output table and create an output named OnGetValue with a target entity of logic_t_chooser and a "Via this input" of InValue. Do the same for counter_ct, replacing logic_t_chooser with logic_ct_chooser. Keep the parameter override fields blank. Back at the ListenRoundStart logic_eventlistener outputs table, create an output named OnEventFired, set target entity to counter_chooser and "Via this input" to PickRandom. Now it's time to create the trigger_multiple brushes: Create a single trigger_multiple brush around CT spawn and a single trigger_multiple brush around T spawn. Name those trigger_multiples wep_spawn_ct and wep_spawn_t respectively. Once again, if you have multiple group spawns, simply copy the trigger_multiple brushes to the other spawn areas, keeping the same entity and filter names. The output table should look like this. Set "Filter Name" for wep_spawn_ct and wep_spawn_t to filter_ct and filter_t respectively Set "Delay Before Reset" to -1 In wep_spawn_t, set "My output named" to OnStartTouch, "Targets entities named" to counter_t, "Via this input" to GetValue and a delay of at least 0.01 seconds (this delay is necessary for the game_player_equip entities to work). Also make sure "Fire once only" is unchecked Do the same thing with wep_spawn_ct, but change "Targets entities named" to counter_ct. As you can tell, there's a lot of entities that need to be created to randomize player weapons round-to-round. Fortunately, I made a chart to visually show how all these entities relate to each other: I made a map that shows off all the concepts in this post. You can download it at the link below: https://drive.google.com/file/d/1GcBfx7_NaKbL025XegK3Kgzpp5znNGet/view
  23. I've been putting the finishing touches to my aim_six_arenas spinoff map (which I'm now calling Showdown Planet) and I though I could share some comparison GIFs between the original map and the spinoff map. As I mentioned earlier, while aim_six_arenas merely was a collection of six soundstage-like rooms connected by a hallway, Showdown Planet will consist of six separate arenas meant to represent different places around the world, which means the arenas in Showdown Planet will be far more detailed than their aim_six_arenas counterparts. Dust/Mirage arena: Aztec/Ancient arena: Swamp/Mill arena: Subzero/Monastery arena: Hallway, made more AIM friendly in the Showdown Planet version: I did not record camera positions when taking screenshots, hence why the GIFs aren't perfect comparisons.
  24. Learning more about the equirectangular projection, it turns out that if I wanted to properly texture a skydome, I should have only cropped the top half, as opposed to the top 3/4, of the panorama. For my upcoming map, though, I'm going to stick with the 3/4 method mentioned at the top. That's because the 3/4 method is able to capture a lot more of the horizon than the top half method, with the only tradeoff really being a slightly distorted skydome. Instead, I figured out that a much better use for the 1/2 cropping method is when I have to create a skysphere. Because I'm lazy, the "skysphere" in my map was really just two skydome models, with one of the skydome rotated along the Y-axis. A sphere was needed because the windows in the space-themed arena allowed players to look down. Unfortunately, I could not find a formula on how to adjust the bottom sphere's yaw so that it would match the upper sphere's texture, so I just had to eyeball it. You can see the results of my "skysphere" in the background of the screenshot below. Remember, this screenshot was taken on the same map as the screenshots I posted at the top:
  25. Talk about really randomizing your stuff: OrelStealth has just released a map with procedural generation: https://steamcommunity.com/sharedfiles/filedetails/?id=2362387875 Skimming through the decompiled files, it looks like most of the procedural generation was done through Vscript combined with a bunch of prop_dynamic entities.
×
×
  • Create New...