Welcome to PlagueFest.com! Log in or Sign up to interact with the Plague Fest community.
  1. Welcome Guest! to interact with the community and gain access to all the site's features.

Tutorial Per map fully working, relatively easy to make 'cvars'.

Discussion in Resources & Tutorials started by enviolinador, May 11, 2014

  1. May 31, 2012
    Posts
    As a mapper, one of the things I've always despised the most was not being able to tell the map as an admin to behave differently without a plugin. I've always thought that, given that each community has its own flavor when it comes to settings/gameplay mechanincs, server managers should be able to control a few things at will.

    Although we're not able to make this (at least, not at the desirable extent of, for example, setting paper_boss_hp_base to 500), we can do a little trick. It'll work as a real cvar if done well, being polled whenever you want (the system I built has a bit of delay so I use it per round but it could be tweaked to ensure that the delays are minimal and, thus, that the cvars can be polled per time interval within around to allow for real dynamic cvars). This system will simply interface one of the game cvars via the alias command so 'taboo_mode_enable' translates to a real game cvar that is linked to things in the map. When I first thought of it, I planned on using sv_gravity or phys_timescale but Cuni (who had a similar interest due to the dumb big models in his minecraft map) suggested phys_pushscale instead. Anyway, here we go:

    To build the system we need to define the commands first. Those commands will be the ones recognized as cvars by our map. For this, I've been making 'command definition' configuration files as the one that follows (the example is my taboo_command_definitions.cfg):

    Code:
    // Taboo command definitions
    // ------------
    // This file should be embedded within the map
    // to provide per map command configurations
    // for easy customization by server owners
    // ------------
     
    // Trace command (do not delete - it helps to find issues!)
    echo [ Taboo: Command definitions loaded ]
     
    // Command definitions
    // ------------
    // To create a custom map command we use the alias to create and store said command.
    // We will nest commands in order to provide a simpler use.
    //
    // Server admins would only need to add the first command (taboo_extra_tries_enable, taboo_items_enable
    // taboo_setting_taboo_mode in this case) and it would execute the second, 'hidden' command (which the map
    // will execute)
    //
    // This allows configs outside of embedded/map-referenced config files for ease (as otherwise,
    // if using the second commands -taboo_setting_multiple_tries as an example- they'd be overwritten
    // every time, every round and those configs would be needed).
    // ------------
     
    // Enable/disable multiple tries in Act II for each Act I win (5 tries with decrementing score
    // after every try as a punishment)
    alias taboo_extra_tries_enable "message_extra_tries_enabled; alias taboo_setting_multiple_tries phys_pushscale 2"
    alias taboo_extra_tries_disable "message_extra_tries_disabled; alias taboo_setting_multiple_tries phys_pushscale 1"
     
    // Enable/disable items in both acts (medikit and unlimitted ammo box)
    // Each time the weapons are used, a score penalty is applied.
    alias taboo_items_enable "message_weapons_enabled; alias taboo_setting_add_items phys_pushscale 2"
    alias taboo_items_disable "message_weapons_disabled; alias taboo_setting_add_items phys_pushscale 1"
     
    // Enable/disable Taboo Mode (higher difficulty with more NPCs and a different configuration)
    // The increase in the number of NPCs will cause the score to increase (as killing them
    // yields points). The map will not change much, but sure it will the config (specially
    // in the terms of zombie HP, zombie knockback and zombie speed, since all of these
    // parameters are applied a multiplier to be paired up with the slight difficulty changes
    // all across the map
    alias taboo_mode_enable "message_taboo_mode_enabled; alias taboo_setting_taboo_mode phys_pushscale 2"
    alias taboo_mode_disable "message_taboo_mode_disabled; alias taboo_setting_taboo_mode phys_pushscale 1"
     
    // Messages (for easier debugging)
     
    alias message_taboo_mode_enabled "echo [ Taboo: Taboo mode enabled ]"
    alias message_taboo_mode_disabled "echo [ Taboo: Taboo mode disabled ]"
    alias message_weapons_enabled "echo [ Taboo: Weapons enabled ]"
    alias message_weapons_disabled "echo [ Taboo: Weapons disabled ]"
    alias message_extra_tries_enabled "echo [ Taboo: Extra tries enabled ]"
    alias message_extra_tries_disabled "echo [ Taboo: Extra tries disabled ]"
    I like documenting my stuff so I added echo for when the commands are executed (I'd recommend you do to). The process is the following: first we give an abstraction layer for each command to be executed map-wise (example: alias taboo_setting_taboo_mode phys_pushscale 2). These commands will be called by the map (by simply adding an output to our point_servercommand like this: OnWhatever > ServerCommand > Command > taboo_setting_taboo_mode > 0.00). We then abstract the previous abstraction so that server admins don't have to type 'alias' in the configuration files. For this, we alias the exterior command that contains both the echo message and the map-called command like this: alias taboo_mode_enable "message_taboo_mode_enabled; alias taboo_setting_taboo_mode phys_pushscale 2". We can test that it works by executing this last command (we should get "[ Taboo: Taboo mode enabled ]'' in console) and then executing the map-command with the output I wrote earlier.

    How would we go on to link this to the map? Well, if you notice we've been changing the phys_pushscale value to 2. I used 2 because it was enough for testing purposes; a higher value could be enforced to reduce the delays. The idea is that every time you want to poll the state of a cvar you should:

    1. Set phys_pushscale or whatever your interfaced cvar is to a value that will NOT fire the output
    2. Execute the map-command, in this case, taboo_setting_taboo_mode via point_servercommand
    3. Run the 'cvar test' with entities that listen to the interfaced cvar. In my tests I used a physics object that would get pushed far enough to touch a trigger if the pushscale was 2, but that wouldn't if it was 1. You can follow any kind of logic that you want and that works but remember that, at least from my experience, source physics aren't deterministic so they do whatever the fuck they please at higher forces.
    4. If the entities fire the output (barrel touches the trigger, for instance) trigger a relay or something similar that starts whatever the cvar means inside the map.
    As always, because descriptions are both boring, complicated and dumb, I'll upload a little prefab (copypasted from taboo). It's kinda dirty (because I did stupid stuff to taboo and didn't really fix it properly) but it works. The file attached comes with the command definitions, too, for if you wanna start building your stuff from there. Note that I copypasted the cvar system only, to test it you'll need to build your own test room (calling the CvarDecodeRelay relay by triggering it)

    Attached Files:

    • Like Like x 2
    • Useful Useful x 1
    • Apr 9, 2007
      Posts
      I was under the impression you didn't want to ship external assets with maps? :s
    • May 31, 2012
      Posts
      The .cfgs can be packed too. I've been doing it since forever.