Make an output fire BEFORE first player spawns?

  • Site Migration: See bugs? Report them here. Want something changed or have an idea? Suggest it here.

sharktemplar

L1: Registered
Feb 26, 2018
18
So essentially what I'm doing is using a point_clientcommand and logic_auto on an offline local host server to try and execute a command into my console the moment the map loads in and you see the Welcome/map rotation screen in-game. I've discovered that apparently OnMapSpawn and all its variations don't actually fire until the first player spawns in, but I specifically need this output executed BEFORE the player spawns in. I cannot use a .cfg file with the same name as the .bsp in order to have commands simply executed beforehand upon the map loading up, because the command must be executed in-game, not beforehand like a player/server-side convar setting.

Does anyone know a nifty trick I could use that would allow me to execute an output from an entity after the map has fully loaded, but before any players have actually spawned?
 

sharktemplar

L1: Registered
Feb 26, 2018
18
Might I ask which commands, exactly?
It's a cfg file with a string of commands I put in for experimentation. This is what it contains and executes:
sv_cheats 1;hidepanel all;wait 10;jointeam blue;wait 10;join_class medic;wait 10;mp_waitingforplayers_cancel 1;cl_drawhud 1;say I have executed!
hidepanel all removes the welcome/map rotation screen and the map preview/motd stuff automatically so the player does not have to click through it themselves. The other commands are simply to force-join blu and force-select medic as the player class, as well as remove the pre-round timer so you are ready to play the moment you spawn in.

It works perfectly when typed in manually from the welcome screen via exec <cfg file name> in console. I was trying to automate this.
 

ficool2

L4: Comfortable Member
Oct 28, 2017
162
Not possible, those commands are blocked from being used by clientcommand also
 

sharktemplar

L1: Registered
Feb 26, 2018
18
Not possible, those commands are blocked from being used by clientcommand also
It actually is possible, because it isn't executing those commands, it's executing a cfg file with those commands. I have tested this in fact. Triggering the point_clientcommand to execute the cfg with the commands I listed above works perfectly. All commands execute and even in the order they are meant to via the wait commands.
It is possible to get it to execute in-game, I'm just not sure if it's plausible to do it post-loading screen but pre-spawn-in.
 

ficool2

L4: Comfortable Member
Oct 28, 2017
162
It actually is possible, because it isn't executing those commands, it's executing a cfg file with those commands. I have tested this in fact. Triggering the point_clientcommand to execute the cfg with the commands I listed above works perfectly. All commands execute and even in the order they are meant to via the wait commands.
It is possible to get it to execute in-game, I'm just not sure if it's plausible to do it post-loading screen but pre-spawn-in.

Dedicated servers block .cfg files from executing, however it does work on LAN mode (which you are testing on if you are by yourself) and I'm pretty sure it can't be disabled because you can get RCON access using an exploit with .cfg files
 

sharktemplar

L1: Registered
Feb 26, 2018
18
Dedicated servers block .cfg files from executing, however it does work on LAN mode (which you are testing on if you are by yourself) and I'm pretty sure it can't be disabled because you can get RCON access using an exploit with .cfg files
You are correct, however, and this is something I've deliberately neglected to mention until my project is ready for a more official and detailed initial announcement...
The map I am making will be single-player, meaning players will always and only ever play it on an offline local host, so this problem is not one I need to concern myself with.
 

Werewolf

Probably not a real Werewolf
Apr 12, 2011
872
While its admirable to try and save a few steps for convenience, I don't think it's worth messing with the hud commands. People have to click though them on every other map, so they aren't going to miss anything.

As for having the player automatically be a Blue medic, you can do that with a trigger_hurt, a point_clientcommand and some filters.
  • The first filter you need is a filter_activator_tfteam, with the team set to Blue, the mode set to 'Allow' and given a name. (EG: Flt_Blu)
  • Second is a filter_tf_class, with the class set to Medic, the mode set to 'Allow' and given a name (EG: Flt_Medic)
  • The third is a filter_multi. This combines the effects of the other 2 filters, and needs to be set correctly. 'Negate Outcome' needs to be set to 'Yes', 'Logic type' needs to be set to 'AND', and the 2 previous filters must be set in the 'Filter 1' and 'Filter 2' fields. Finally, give this filter a name (EG: Flt_Blu_Med)
Now we move onto the trigger_hurt brush. Create one of these over your spawn point, set its damage to anything above 300 (enough to kill a heavy in one hit) and set the filter to your named filter_multi, in this case named 'Flt_Blu_Med'.
Then move over to the trigger_hurt's 'Outputs' tab, and give it these two commands:
Code:
OnHurtPlayer | <named point_clientcommand> | Command | jointeam blue | 0.00
OnHurtPlayer | <named point_clientcommand> | Command | join_class medic | 0.10
What all of this will do, is kill any player that is not a Blue Medic. If it does kill them, it will force the player to change team and class to a blue medic. Blue Medics are the only team + class that is immune to the trigger_hurt.
 

sharktemplar

L1: Registered
Feb 26, 2018
18
While its admirable to try and save a few steps for convenience, I don't think it's worth messing with the hud commands. People have to click though them on every other map, so they aren't going to miss anything.

As for having the player automatically be a Blue medic, you can do that with a trigger_hurt, a point_clientcommand and some filters.
  • The first filter you need is a filter_activator_tfteam, with the team set to Blue, the mode set to 'Allow' and given a name. (EG: Flt_Blu)
  • Second is a filter_tf_class, with the class set to Medic, the mode set to 'Allow' and given a name (EG: Flt_Medic)
  • The third is a filter_multi. This combines the effects of the other 2 filters, and needs to be set correctly. 'Negate Outcome' needs to be set to 'Yes', 'Logic type' needs to be set to 'AND', and the 2 previous filters must be set in the 'Filter 1' and 'Filter 2' fields. Finally, give this filter a name (EG: Flt_Blu_Med)
Now we move onto the trigger_hurt brush. Create one of these over your spawn point, set its damage to anything above 300 (enough to kill a heavy in one hit) and set the filter to your named filter_multi, in this case named 'Flt_Blu_Med'.
Then move over to the trigger_hurt's 'Outputs' tab, and give it these two commands:
Code:
OnHurtPlayer | <named point_clientcommand> | Command | jointeam blue | 0.00
OnHurtPlayer | <named point_clientcommand> | Command | join_class medic | 0.10
What all of this will do, is kill any player that is not a Blue Medic. If it does kill them, it will force the player to change team and class to a blue medic. Blue Medics are the only team + class that is immune to the trigger_hurt.
That is an interesting approach I didn't know about...
The way I was currently going about it was through the benefits I would get of having access to the player's console right from the get go, so using the command "mp_humans_must_join_team blue" will allow them to click the red team door, but this does nothing and automatically forces them onto blue. As for join_class medic, it works the same as if you were to open the class menu and click the class manually. If you try to change to a class you currently are playing as, it does nothing. If you do it playing as any other class, it changes immediately. So what I did was simply lock out access to the red team, and have a trigger_multiple that would OnStartTouch to execute the command "join_class medic" into the player's console each and everytime the trigger is touched. If they are the correct class, nothing happens. If not, it changes automatically.

The primary benefit to me trying to do all of this with console commands was in hopes of not needing to build any trigger-shenanigans to enforce the class requirement, as well as hide the beginning screens automatically, because later in my project there will be level loading zones that I want to be as seamless as possible in the source engine, akin to an actual single-player source engine game.
I'm quite bummed it seems this can't actually be done. I don't want people playing my maps to have to get into the habit of constantly clicking off of the 2 start-up screens and selecting a team and class that doesn't actually affect what they spawn as in the first place.

Thank you for the instructions though. Those may come in handy to me because I've legitimately never even touched a filter_multi.

...Would it perhaps be possible to create some sort of background cfg system where one cfg executes another but on a delay, and they go back and forth until a specific command is let through, which cancels this cfg ping-pong loop? If I tied that to the cfg that executes for a specific map upon it being loaded, maybe it would simply do nothing in the background endlessly until the map loaded, sort of a forceful queuing of commands? I'm not sure how I would write these cfgs with a delay though because the wait command is tied to fps, which doesn't even exist until the map loads in, and I know for a fact a system of cfg1 that executes cfg2 which executes cfg1 again is just an instant crash-to-desktop...

I really want it to be as clean as possible for anyone playing, as if I end up maintaining the motivation to work on this long-term, I will have numerous different maps all stringing together to provide people with a legitimate cohesive single-player experience in tf2.