Stormcaller's PropHunt Starter Kit And Tutorial

Stormcaller3801

L5: Dapper Member
Jul 5, 2009
249
28
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.
 

Nutomic

L11: Posh Member
Feb 7, 2009
888
177
Nice tut.

For testing an arena map alone, you just need a bot: enable cheats and write "bot add" into console.

€: In fact, the props have to be prop_dynamic, as you cant name prop_statics.
 
Last edited:

Stormcaller3801

L5: Dapper Member
Jul 5, 2009
249
28
As best I can tell that doesn't really apply here; the delay is superfluous anyways. It serves no real purpose other than making sure when you spawn you can see the new props appear. Beyond the tutorial aspect it does nothing of significance.
 

Geit

💜 I probably broke it 💜
aa
May 28, 2009
598
1,161
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.

  • There is no minimum and no maximum, although, maps that do not have enough props (and thus aren't fun to play) will not be approved by the prophunt team, and will not have demographics sent back to the global database.
  • Control point can be added without any problems, but it is not recommended as it will double the chances of getting the Control Point base.
  • Ragdolls would turn out like the AFK Pyro prop
  • AFK Pyro was removed, you will only see Gaming Masters' Admins using it frequently these days.


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
  • Why are you bothering with clear_props? Setting all the prop_dynamics that are assigned to sets to "Start Disabled" is a much more efficient way of doing it, IMO. -
  • That delay is also almost completely unnoticeable and is only there to help with Copy and Pasting + ordering.


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.
  • Prop_static is NOT networked, and therefore can't utilize entity I/O, making it completely useless for randomization.
  • The Orange cone can easily be used as a prop in randomization, it's intended to be a physics prop (These could be included in randomization), but for simplicity you can use prop_dynamic_override which is the same as prop_dynamic but allows physics props to be used.



This, along with the default gravity setting of 300 (standard is 800) means that you will want particularly high ceilings to allow for mobility.
Gravity is 500, not 300.

As always, if you have any questions, feel free to ask and I'll do my best to assist.
Or just head over to GamingMasters.co.uk and ask the creators.

Anyway, Nice expansion on my overviews. You may want to consider revising the "scaling" section as you appear to have made it unnecessary complex and overly-ambitious. (Looks like you forgot about the entity data limits, again.)
 

Darkimmortal

L1: Registered
Jul 16, 2009
11
5
tl;dr - anything like Sawmill or Farm is awesome imo. 2-3 levels of vertical gameplay and not too open or complex. Unlike Warehouse with its over 9000 levels of vertical gameplay and props everywhere.

Also I find it more fun hiding behind things, not blending in. Complex brushwork and buildings etc. > props everywhere.

Also I quite like Swamp (because I made it :p) but it's an example of a map which is much too small.



Also if you want to test locally, follow the normal installation instructions and comment out #define WHORE in the code to enable listen server support.

Also here is my listenserver.cfg, some of which may be needed:

Code:
mp_timelimit 0
mp_winlimit 0
mp_roundlimit 0
sv_lan 0
mp_teams_unbalance_limit 0
sv_cheats 1
wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;wait;
mp_waitingforplayers_cancel 1
tf_arena_max_streak 5
tf_arena_use_queue 0
tf_arena_preround_time 5

bot;
bot;
bot;
bot;
bot;
 
Last edited:

Stormcaller3801

L5: Dapper Member
Jul 5, 2009
249
28
  • Why are you bothering with clear_props? Setting all the prop_dynamics that are assigned to sets to "Start Disabled" is a much more efficient way of doing it, IMO. -
  • That delay is also almost completely unnoticeable and is only there to help with Copy and Pasting + ordering.

I included clear_props because you included clear props in your tutorial, and I assumed that there was a good reason why you did so rather than going with the 'Start Disabled' option.

The 1 second delay is, as stated, primarily to show that yes, the props spawn at the start of each round. Also as stated it's largely superfluous.

  • The Orange cone can easily be used as a prop in randomization, it's intended to be a physics prop (These could be included in randomization), but for simplicity you can use prop_dynamic_override which is the same as prop_dynamic but allows physics props to be used.

Gravity is 500, not 300.

On both points, I relied on the input of others. I was told certain props would cause problems, and attempting to identify the cause I found replacing the traffic cone with something else solved the issue. And someone else authoritatively stated gravity was at 300.

Having no good reason to assume that they had no idea what they were talking about, I took them at their word.

Or just head over to GamingMasters.co.uk and ask the creators.

It seemed rude to send people off to ask someone else questions about a tutorial that I wrote. Particularly when those individuals might not be aware of said tutorial.

Anyway, Nice expansion on my overviews. You may want to consider revising the "scaling" section as you appear to have made it unnecessary complex and overly-ambitious. (Looks like you forgot about the entity data limits, again.)

Not so much forgot as assumed that people would take them into consideration, and further expected that individuals' iterations were likely to go beyond anything I could think of, and thus expanding on things to the point of overkill was more likely to prove useful than if I assumed a narrow application and left everyone to figure out the rest on their own.