Stormcaller's PropHunt Starter Kit And Tutorial This kit contains everything you need to create a PropHunt map, as well as all the elements necessary to get started on randomized props for your PropHunt map. Furthermore, I've made it into a compilable map so that you can experiment with the randomization elements and make sure everything works out fine. I even got rid of fullbright. Because you're worth it. The Necessary Elements Of A PropHunt Map There are three things that you need for a PropHunt map, at absolute minimum, beyond the usual spawn points and so on: A prop_dynamic with the control point base world model A tf_logic_arena A properly filled-out .cfg file You do not have to do anything with the prop_dynamic except have it on your map. No spinny thing, no trigger_multiples, nothing. Put it in your map and forget about it. In fact, you can just forget about it outright; I already put one in there. The tf_logic_arena does not need to be modified either- leave it blank. You will notice that I created a custom visgroup for this; that's for testing purposes. Because Arena maps will not start until two or more people are present, you can't test a map with a tf_logic_arena (as far as I'm aware). So you can just disable that visgroup until you're at the final compile step. Finally, the .cfg file. This config file has to have the same name as your map. This is why I have cunningly named it mapnamehere.cfg in the starter kit. My genius knows no bounds. In addition there are two subsections inside the .cfg that are relevant. Neither are particularly complex; we'll get right to it. First is the Props section. This is a list of the world models that a player on the RED team can spawn as. I've already filled in one as an example. I am unaware of a maximum number of world models per map, and I am unaware of a minimum. Delete or add more double quotes and brackets as necessary to match the number of props you want people to be able to spawn as. Do not add the control point base. This is automatically added by the PropHunt mod, and adding it to the list will cause problems. To my knowledge no other props cause these kinds of issues, but I haven't seen every prop tried, and I've no idea how it will react to ragdolls. Supposedly some maps have included a civilian Pyro prop. I have not seen this myself. Second is the Settings section. There are three boolean settings and one numeric. As you are all as genius as I am, I'm sure you can figure out which ones are which. Doors - A 1 will open all func_doors at the end of setup Relay - A 1 triggers a logic_relay named 'hidingover' at the end of setup Round - the time in seconds for the round; standard is 175 Freeze - 1 to freeze BLU team during setup; may be nonfunctional The final option, 'alt,' has been declared by the creator as not doing anything. So ignore it. You will note that the starter kit map already includes a logic_relay named hidingover, which has no outputs. I'm just considerate like that. Once you have your map created and your .cfg file properly filled out, you can load your map onto a server with a PropHunt mod and it will work properly. How To Have Randomized Props You will note that one half of the map looks like the most godawful attempt at adding props to a map you have ever seen. This is intentional, and it represents one portion of the randomized props function- specifically the randomized props. I will now explain how the whole thing works. First I'd like to give credit where credit is due: this is based off of Geitegg's tutorial, with the exception that I have attempted to make it more user friendly in terms of how it functions. There are five parts to the randomization: logic_auto logic_relay 'clear_props' logic_case 'section_1_props' logic_relays 'set_1_1' through 'set_1_4' props named 'prop_1_1' through 'prop_1_4' These five parts work in sequence. First and foremost, the logic_auto performs two functions: it calls clear_props to do its thing, and tells the logic_case to pick a random case at round start. Next, clear_props disables anything with a name that starts with 'prop_' along with disabling collisions and shadows. Once this is done, there is a superfluous and utterly unnecessary 1 second delay before the logic_case picks one of the four cases, and triggers the associated logic_relay (Case1 = set_1_1, Case2 = set_1_2, and so on), which in turn proceeds to enable all props with the associated name, along with collisions and shadows. Because of the clear_props relay, no props from previous rounds will remain in the current round (except the control point, which is unnamed and thus isn't listening) which ensures no strange overlapping of props. Because of the way the logic_case and logic_relays are set up, a minimal amount of outputs are necessary. And on top of that, it's all very easy to scale. You may note that all props with a given name share the same world model. This is for ease of illustration only; it is not necessary. You may also note they are all prop_dynamics. This is also unnecessary. Prop_static is perfectly viable, and in fact may be preferable. The only restriction that I can find so far is that you cannot use the orange cone prop in the randomization, as it will not appear on the map. It is traditional that PropHunt maps do not have these in the map even if you are able to be one. Now you know why. Scaling Upwards In order to scale the randomization upwards, the simplest thing to do is to create clones of the existing logic_case and associated logic_relay entities and then alter the names appropriately. In my own standardization of terms, a 'section' is a given area of the map and a 'set' is one possible group of props that can appear in a section. Because a logic_case function can only handle 16 cases, it is impossible to have more than 16 sets per section without having additional logic_cases. You can get around this by having one logic_case output to additional logic_cases; the rough equivalent is plugging several power strips into another power strip, thus exponentially increasing the number of available outlets. Thus you would end up with something like: logic_case 'section_1_top' OnCase1 PickRandom 'section_1_a' OnCase2 PickRandom 'section_1_b' (etc.) logic_case 'section_1_a' OnCase1 Trigger 'set_1_1' OnCase2 Trigger 'set_1_2' (etc.) logic_case 'section_1_b' OnCase1 Trigger 'set_1_17' OnCase2 Trigger 'set_1_18' (etc.) In all honestly this should not be necessary. Too many permutations will make it very difficult for players to remember what should and should not be present, leading to frustration for the BLU team as. It's worth noting that because of the way that clear_props is set up, it does not need to be altered for future expansion, as it will work fine so long as all props have names that match the wildcard (i.e., 'prop_*') and no other entities do so. You could also alter the logic_auto to do the same, replacing the call to 'section_1_props' with a call to 'section_*' which would make it unnecessary to add outputs for additional sections. I did not do so, although I likely should have. Further Tips On PropHunt Design Keep in mind that PropHunt maps work akin to arenas- very little health or ammo, no respawning, and no changing classes after the initial (pre-setup) timer. The mod also strips out any additional mods on the server, as well as various map elements such as resupply cabinets, respawn room barriers, and so forth. This means that if you have an existing Arena or KotH map, you should be able to convert it to PropHunt use with minimal effort (specifically the .cfg file, if I'm not mistaken), although you may want to ensure there's plenty of props scattered around. Suggested map size for PropHunt is 6000x6000, although I believe that should be thought of as akin to square footage (or square cm, if you prefer), as multiple, smaller floors can work just as well. Props have no weapons, so running and double-jumping are their only means of defense once discovered. This, along with the default gravity setting of 300 (standard is 800) means that you will want particularly high ceilings to allow for mobility. It is best if your map has fairly open sightlines, but the BLU spawn has little or no view of the map prior to round start (the Doors setting in the .cfg is useful for aiding in this) in order to allow RED team to hide, but then making it difficult to run without being spotted by someone. Finally, try to balance the size and shape of your map to the time limit. A longer time limit benefits the BLU team; a larger map benefits the RED team. Similarly, lots of walls that block flames or bullets will make it harder for BLU to sweep an area, while too few props will make it harder for RED to blend in. As always, if you have any questions, feel free to ask and I'll do my best to assist.