Description
Map Rewards allows you to create custom entities around the map. In theory, you are free to customize these entities to the full extent that Hammer/Source SDK allows.
These entities are also able to detect when touched or hurt by a player and run a defined command on the server. This command can contain two special strings in the definition: #player to use the touching player as targets and #reward to resolve to the ID or name (if the reward was named) of the triggered reward. As well as #inflictor for hurt events only, resolves to the actual entity that inflicted the damage.
Also provided with Map Rewards are two seemingly unrelated commands, sm_exec2 and sm_teleplus, they are included because these types of commands are commonly used as the reward for the entities.
Cvars
Spoiler
Quote:
sm_mrw_version - Plugin version
Quote:
sm_mrw_enable - (Default: 1.0) - If disabled (0.0), rewards will not be spawned. Rewards can still be added, however.
Quote:
sm_mrw_respawn_time - (Default: 5.0) - Default seconds until a reward will respawn.
Quote:
sm_mrw_cleanup - (Default: 8) - When to release and kill all rewards. OR desired values together:
0 = never
1 = plugin end
2 = map start
4 = round start
8 = before auto loading
16 = before every manual load (through sm_mrw_cfg_load)
Internally, at round start all rewards are killed and respawned. At plugin end and map start all rewards are killed and released.
Quote:
sm_mrw_autoload - (Default: 2) - When to auto load map or server cfg saves. OR desired values together:
0 = never
1 = map start (maprewards/server.cfg)
2 = map start (maprewards/<map>.cfg)
4 = round start (maprewards/<map>.cfg)
8 = round start (maprewards/server.cfg)
Quote:
sm_mrw_autosave - (Default: 0) - When to auto save map cfg. OR desired values together:
0 = never
1 = plugin end
2 = map start (basically map end; internal data is still intact until cleanup)
4 = round start (basically round end)
8 = before cleaning up
16 = save every edit/addition that's not from the server
32 = save all removals of rewards
64 = always backup first (format for backup files: "cfg/maprewards/backup/<map>.cfg.<time>)
Quote:
sm_mrw_flag_basic - (Default: "i") - Admin flag required for basic mrw commands.
Quote:
sm_mrw_flag_create - (Default: "m") - Admin flag required for creating or modifying rewards.
Quote:
sm_mrw_flag_extended - (Default: "m") - Admin flag required for all sm_mrw_cfg_* commands except for load and list.
When setting values for cleanup, autoload, and autosave, simply add all the values you want together, so if you wanted to autoload on both map starts you would add 1 and 2 together to get 3.
The flag cvars can be more than one flag. So if you wanted to make all mrw commands require the custom flag "r", but you still wanted the default flags to be present, you could use "ri" for sm_mrw_flag_basic and "rm" for both of the others.
Commands
Spoiler
Quote:
sm_mrw_info - sm_mrw_flag_basic - Displays info about a specific reward spawn point.
Usage: sm_mrw_info <#id|name>
You may need to run this command from your game console to see the full response.
Quote:
sm_mrw_add - sm_mrw_flag_create - Sets a spawn point on the map for a reward.
Usage: sm_mrw_add [OPTIONS ...] [command ...]
At least model or entity_type is required.
If entity_type is prop_physics_override (default), model is required. command is a full command to run when a player touches the reward.
If present, #player will be replaced with the target string of the client who activated the reward. OPTIONS: -h Display this help text. -A <health>
Set an internal health amount for the reward.
Only used when respawn_method is kill to kill the reward after it takes this much damage. -b <#reward_id|name>
Uses the provided reward as a base to copy data from.
This switch should appear before anything else as it overwrites all the data.
The origin coordinates will be set to this reward unless the origin is set. -c <X Y Z>
Coordinates to spawn the entity at, can be relative to origin using ~'s.
If not provided, origin will be used. -d <respawn_method>
Must be one of the following: pickup: When a player touches it, it will disappear until the respawn time is up. static: The reward will stay, but will be inactive until the respawn time is up. constant: The reward will stay and never deactivate. hurt: The reward will trigger when a player hurts it. kill: The reward will trigger when a player kills it. notouch: The reward will not trigger when a player touches it. Can be used after other settings to remove the touch event. nohook or nopickup: Default. Just an entity, nothing special about it. -D <#reward_id|name>
Set the origin coordinates to a reward's location. -e <entity_type>
The type of entity you wish to create. If not provided, prop_physics_override is used.
You may use model aliases defined with sm_mrw_model_add. -l <R G B A>
Set the color overlay. -L <integer_color>
Set the color overlay. integer_color is an RGBA value in integer representation. -m <model>
The path to the model file you wish to use.
You may use model aliases defined with sm_mrw_model_add. -n <name>
Allows you to define a name for the entity, which can be later used when referring to this reward.
If not defined, the name will default to its corresponding ID number. -o <X Y Z>
Origin coordinates. If not provided client's location will be used. -O <#userid|name>
Set the origin coordinates to a player's location. -p <entity_property_script>
Allows you to define a series of entity properties using this format:
[prop_type:]key,[type=]value prop_type must be 0 for Prop_Data (default) or 1 for Prop_Send. type may be one of the following: int float string ent or vec.
For vec, value must be a series of 3 floats separated by commas.
Multiple key,value pairs can be separated by &'s.
Please do not set m_iName here. Use the -n switch to set a name.
You may use script aliases defined with sm_mrw_script_add. -r <RX RY RZ>
Rotations for the entity. Cannot be relative. -R Automatically release the reward from the plugin immediately after spawning it. -s <script>
A series of variables dispatched to the entity as an overridescript or individual keys to trigger.
A value of null will erase the script defined by a provided model alias.
Format: overridescript?key[,[type=]value] type may be one of the following: int float or string.
Multiple key[,value]'s can be separated on the right side of the ? by &'s.
You may use script aliases defined with sm_mrw_script_add. -t <respawn_time>
The fractional seconds until the reward respawns.
A value of 0 will never respawn.
A value of -1 will use the value of sm_mrw_respawn_time. -T <SX SY SZ interval>
Set the reward to rotate every interval. interval is in fractional seconds. -Umodel, script, and entity_property aliases will not be evaluated until spawn time. -u Unsets the -U switch, causing all aliases to be evaluated now. -X Changes the command parameter to set the command that will be run when the reward is hurt or killed.
The following shortcuts for respawn_method will only remove conflicting options, so multiple can be used to create the desired effect. -P Sets respawn_method to pickup. -S Sets respawn_method to static. -C Sets respawn_method to constant. -H Adds hurt to the current respawn_method. -K Adds kill to the current respawn_method. -N Removes touch events from the current respawn_method.
Quote:
sm_mrw_modify - sm_mrw_flag_create - Modify a reward spawn point.
Usage: sm_mrw_modify <#reward_id|name|list> [OPTIONS ...] [command ...] OPTIONS is exactly the same as sm_mrw_add with the following exceptions: -o - Origin coordinates default to the reward's if not specified. -r - Rotation angles can now be relative. -h - No help switch, because it breaks the flow of this command.
Use sm_mrw_add -h for a detailed paragraph about the OPTIONS.
If any combination of options that result in a conflict are used, an error explaining why that specific option could not be set will be displayed. Other options will still be applied.
If any multi-argument options are missing arguments, the command will stop where the error occurred. This might cause undefined behavior, and you will need to manually sm_mrw_respawn the reward.
Quote:
sm_mrw_remove - sm_mrw_flag_basic - Removes rewards on the map.
Usage: sm_mrw_remove <#reward_id|name|range ...>
Quote:
sm_mrw_removeall - sm_mrw_flag_basic - Removes all rewards on the map.
Usage: sm_mrw_removeall
sm_mrw_model_add - sm_mrw_flag_basic - Adds a model alias. Does not save.
Usage: sm_mrw_model_add <name> <model> [entity_type] [overridescript] [entity_properties]
"null" or "0" can be provided for any argument you want to ignore.
If you are using an entity_type that does not need a model, use "null" for model.
See sm_mrw_add -h under -s and -p for overridescript and entity_properties format.
Quote:
sm_mrw_model_save - sm_mrw_flag_basic - Saves the current model aliases to 'cfg/maprewards/aliases.cfg'.
Usage: sm_mrw_model_save
Quote:
sm_mrw_model_list - sm_mrw_flag_basic - Lists all current model aliases.
Usage: sm_mrw_model_list
sm_mrw_script_add - sm_mrw_flag_basic - Adds a script alias. Does not save.
Usage: sm_mrw_script_add <name> <script> script can be either an overridescript or entity_properties_script, but not both, when using, you will need to know which it is.
Quote:
sm_mrw_script_save - sm_mrw_flag_basic - Saves the current scripts to 'cfg/maprewards/scripts.cfg'.
Usage: sm_mrw_script_save
Quote:
sm_mrw_script_list - sm_mrw_flag_basic - Lists all current scripts.
Usage: sm_mrw_script_list
Quote:
sm_mrw_cfg_save - sm_mrw_flag_extended - Saves current reward spawn points to a cfg file for later reuse.
Usage: sm_mrw_cfg_save [OPTIONS ...] <file.cfg> file.cfg is the cfg file to save to. It will be stored within "cfg/maprewards/". OPTIONS: -E <reward_id|name|range>
Exclude reward_id from the cfg.
Allows a range: #..#, ..#, or #..
Ranges do not accept reward names, only their ID numbers.
Multiple -E switches are accepted. -f
Force the saving of the file, even if a file with the same name already exists. -o <X Y Z>
Set the origin coordinates. Only used if the -R switch is also set.
The origin will default to your location (or 0,0,0 for the server) unless this option is present.
Relative coordinates can be used to offset from your current coordinates. -O <#userid|name>
Set the origin coordinates to a player's location.
May be used in conjunction with -o to offset from a player as long as -O is provided first. -D <#reward_id|name>
Set the origin coordinates to a reward's location. -R
Save the rewards with coordinates relative to the origin.
If this switch is not present, the -o, -O, and -D switches will be ignored.
Quote:
sm_mrw_cfg_load - sm_mrw_flag_basic - Loads a saved maprewards cfg file.
Usage: sm_mrw_cfg_load [OPTIONS ...] <file.cfg> file.cfg is the name of a previously saved cfg file stored within "cfg/maprewards/". OPTIONS: -E <#reward_id|range>
Exclude reward_id from being loaded.
Allows a range: #..#, ..#, or #.. reward_id can only be numbers that correspond to the reward in the order they appear in the CFG, starting with 0.
Multiple {green}-E{default} switches are accepted. -o <X Y Z>
Set the origin coordinates. Only used for rewards in the cfg that were saved with relative coordinates.
The origin will default to your location (or 0,0,0 for the server) unless this option is present.
Relative coordinates can be used to offset from your current coordinates. -O <#userid|name>
Set the origin coordinates to a player's location.
May be used in conjunction with -o to offset from a player as long as -O is provided first. -D <#reward_id|name>
Set the origin coordinates to a reward's location. -N Not relative. Does not set the origin coordinates, useful for cfg's that have dangerously long commands.
Quote:
sm_mrw_cfg_list - sm_mrw_flag_basic - Lists all saved maprewards cfg files.
Usage: sm_mrw_cfg_list [directory] - directory starts in 'cfg/maprewards/'.
If directory is not provided the contents of "cfg/maprewards/" are listed.
Quote:
sm_mrw_cfg_delete - sm_mrw_flag_extended - Deletes a saved maprewards cfg file.
Usage: sm_mrw_cfg_delete <cfg_file> - Path starts in 'cfg/maprewards/'.
sm_mrw_tp - sm_mrw_flag_basic - Teleports player to a reward.
Usage: sm_mrw_tp <#reward_id|name> [#userid|name] [X Y Z] [RX RY RZ] [VX VY VZ]
If a target is not provided, the calling player will be teleported instead.
Coordinates, angles, and velocity can be relative to the reward using "~".
Quote:
sm_mrw_kill - sm_mrw_flag_basic - Kills an entity by its edict ID. To be used with entities after releasing them.
Usage: sm_mrw_kill <#entity_id>
Quote:
sm_mrw_respawn - sm_mrw_flag_basic - Respawn or reactivate a reward early.
Usage: sm_mrw_respawn <#reward_id|name|range ...>
Quote:
sm_mrw_trigger - sm_mrw_flag_basic - Triggers a reward remotely.
Usage: sm_mrw_trigger <#reward_id|name|list> [OPTIONS ...] [#userid|name]
If a target is provided, they will be used as both #player and #inflictor in the triggered command. OPTIONS: -R Do not kill and respawn the reward. -t <respawn_time>
Temporarily override the reward's respawn_time setting. -X Treat the trigger as a hurt or kill event.
Quote:
sm_exec2 - ADMFLAG_SLAY - Executes a cfg file provided as the second argument. Accepts a first argument, but is ignored unless the third argument is '0'. If the third argument is anything else, it will be used instead of the player's name. Any additional arguments will be used instead of the default message. If only two arguments are provided, no message will be sent.
Usage: sm_exec2 <#userid|name> <cfg_file> [custom_name] [message ...]
Executes cfg_file as the server.
If custom_name is 0, the message "has earned a reward!" will follow the username of the target.
If message is provided, it will be used instead.
If custom_name is set to anything other than 0, it will be used instead of the username.
Quote:
sm_teleplus - ADMFLAG_SLAY - Teleport a player to a set of coordinates with optional rotation and velocity. Relative coords, angles, and velocity are allowed.
Usage: sm_teleplus <#userid|name> <X Y Z|#userid|name> [RX RY RZ] [VX VY VZ]
Relative arguments should be preceded with a "~".
Any of the X Y Z arguments allow @aim, instead of a set of coordinates, to use the location the player running the command is looking. This will only work if a player runs the command.
Parameters containing "..." mean that any following arguments, even without quotes around them, will be treated as one whole argument for that parameter.
In the case of "OPTIONS ...", when no more switches (or their arguments) are provided, or "--" is found, this parameter will end.
If you wanted to spawn an ambulance at your current position that spins horizontally and gives a player godmode when they touch it, you could use this command:
-n god sets the name of the entity to "god". You can now use "god" in any command that asks for a reward ID. -m models/ambulance.mdl defines the model of the entity to "models/ambulance.mdl". -s ?DisableMotion&DisableShadow defines a script that will disable motion and shadows on the entity. If you are using the provided scripts.cfg, you can simply use -s np. -T 0.0 5.0 0.0 0.1 sets the entity up to rotate 5 degrees on the Y axis every 0.1 seconds. Intervals will be rounded up to the nearest tenth of a second by sourcemod internally. -P sets the entity in "pickup" mode. This means when a player touches it, the command will run, and the entity will disappear. You can also use -d pickup instead. -t 10.0 set the respawn time after the entity is picked up until it comes back to 10.0 seconds. If this option is missing, the value of the sm_mrw_respawn_time cvar will be used. sm_god #player is the command to run when the entity is picked up. #player will be replaced with the ID of the player who picked up the reward.
Since -e was absent from the command, the entity_type defaults to prop_physics_override.
Now let's say you wanted to move this same reward 100 units upward:
Code:
sm_mrw_modify god -c ~ ~ ~100
If you did not specify a name when originally adding the reward, you can use its ID # instead. When adding, the command will respond with the ID #.
Now if you wanted to spawn a simple shipping crate at a specific set of coordinates with rotation that did not run a command or anything when a player touches it:
I'll only cover new options here. -c 200 100 250 sets the coordinates of the entity to be 200,100,250. -r 0 70 50 gives the entity a rotation of 70 degrees horizontally on the Y axis, and 50 degrees vertically on the Z axis. -d nohook sets the reward to not have any kind of touch event. This is default behavior and not required. -s np is the script alias for "?DisableMotion&DisableShadow". It is defined in the provided scripts.cfg file.
Now if you wanted to spawn a chinese takeout box 110 units above the crate (roughly the height to make the box appear as it is sitting on the crate, I think, might be mistaken...):
-D crate sets the origin coordinates to that of the "crate" reward. -m takeout is the model alias for "models/props_junk/garbage_takeoutcarton001a.mdl". It is defined in the provided aliases.cfg file.
Notice we are not providing a script for this reward. It will have normal physics properties and be movable when hit.
We also are not defining a respawn_method so it will default to "nohook".
If you want to kill off the old entity and respawn it, in case it gets moved too far away or something, you can use sm_mrw_respawn takeout.
To spawn a reward that is not a prop_physics_override, you can set what type it is with -e:
Code:
sm_mrw_add -n pump -e tf_pumpkin_bomb
Because it is not a prop_physics_override, we do not need to set a model.
The only problem with this command is that tf_pumpkin_bomb's explode when hit. This means maprewards will not be able to make it respawn normally, and you will have to manually sm_mrw_respawn it.
To fix this, we can add the -K switch as well. This will add a kill event for the entity, without a command set it will simply allow it to respawn normally.
If we wanted this pumpkin to slap a player when they shoot it, we could add a command with this:
Code:
sm_mrw_modify pump -X sm_slap #player
Since this reward does not have a pickup event, the -X switch is optional. The -X switch sets whatever COMMAND is entered to be only for hurt and kill events.
Rewards that have no hurt/kill command set will use the normal command if it is set.
Now if we wanted this pumpkin to push a player upward when they touch it and do nothing when it is shot, but still allow it to respawn, we will need to run two commands:
This requires two separate commands, because both types of COMMAND may not be provided at the same time. -X null is a special command that tells maprewards not to run a command during the hurt/kill event. This is the only way to make the normal command only run on pickup events.
Now when the pumpkin is touched, it despawns, if this is undesired, the best option is to add static to the respawn_mode:
Code:
sm_mrw_modify pump -S
This may not be exactly what you desire either though.
Rewards that have both static and kill will trigger when killed and respawn normally, but if they also have pickup then when touched they will trigger without despawning and will be inactive for the duration instead. If the reward is currently inactive when it is killed, it will still trigger and respawn normally.
Now if we wanted this pumpkin to not explode we could do this two different ways, the easiest would be to make it constant and kill, but the better way would be with an entity_property script:
-d pickup will unset all the modes and set it only to pickup. -p m_takedamage,int=0 sets an entity_property script. In this case we are setting the EntProp m_takedamage to 0 as an integer. Without int= it will be treated as a String. If the entity has properties that do what you desire, try to use them before using maprewards features as they will not perform as optimally as source engine built ins.
To remove all rewards except for the first five, you can use this command:
Code:
sm_mrw_remove 5..
This will ignore 0-4.
You can also do #..# or #..
Ranges are always inclusive.
sm_mrw_modify can also apply changes to multiple rewards at the same time. The format for selecting which rewards is the same as the rest, except you can separate multiple selections with commas and use exclamation points before the selection to remove the rewards from the final set:
This will select the first 10 rewards, the nearest reward to you, and the reward with the name pump. Neither the reward you are looking at or "crate" will be selected. If neither of those rewards were in the selection in the first place then nothing will change. -l 0 0 255 127 will set all the selected rewards' glow color to blue and they will all be half visible. Format is -l <RED> <GREEN> <BLUE> <ALPHA>.
If you wanted to quickly undo any glow colors you can use [/B]-L -1[/B]. -L allows you to pass the integer representation of the RGBA values, and -1 just happens to be the representation of 255,255,255,255.
About the CFG files
Spoiler
The .cfg files that the sm_mrw_cfg_save command creates are actual server cfg files. They can be executed with the exec command to load them.
If you load the same file twice without removing the rewards in between, there will be two copies in each place, unless they are named.
Rewards with names will fail to load if one already exists with the same name.
You can modify these files to include other commands as well. Even if using the sm_mrw_cfg_load command with non generated cfg files will succeed, and it will know which commands are from itself. It will still run the other commands too though.
When generating the cfg file, the most minimal/efficient command configuration to create the same entity will be used, this may create commands that differ from the original.
Except when it comes to scripts and aliases. These will always be fully evaluated. In the case that the configuration changes, the entities will not.
If sm_mrw_autoload is enabled for map start (server.cfg) (OR'd with 1) then when a map loads, the file "cfg/maprewards/server.cfg" is loaded if it exists. It is just passed to the exec command, so any kind of commands can be here. I'm really not quite sure why I added this feature...
If sm_mrw_autoload is enabled for map start (map.cfg) (OR'd with 2) then when a map loads, the file corresponding to that map within "cfg/maprewards/" with a .cfg extension, will be loaded if it exists. For example: ctf_2fort will be "cfg/maprewards/ctf_2fort.cfg".
To make a file load automatically for ctf_2fort, you can use the sm_mrw_cfg_save ctf_2fort.cfg command. This will save all current rewards to the file. You also need to make sure sm_mrw_autoload is either set to 2 or can be &'d by 2.
When saving, you can use the -E switch as many times as you want to exclude certain rewards or ranges of ID's of rewards. Ranges are always inclusive.
About the different respawn_methods
Spoiler
There are four different types of rewards you can spawn. nohook or nopickup is the default if not specified and doesn't setup any kind of hooks when a player touches them, it cannot ever run a command. It may contain a command though, in case you want to activate/deactivate it by changing its type with the sm_mrw_modify command. pickup acts similar to health or ammo pickups around the map. When a player touches them, or picks them up, they will disappear until the specified (or default sm_mrw_respawn_time if not specified) amount of time has passed, then it will respawn. hurt triggers when the entity takes any damage. If static and constant are not set, this will forcibly kill the entity. kill triggers when the entity takes damage and no longer exists or when its health has reached 0 if -A was used.
If health has been set with -A, then the entity will be forcibly killed.
If the type of entity allows m_iHealth then you should set that with the -s switch and not use -A.
If the entity will be killed naturally after taking damage (like exploding barrels), kill should be used.
notouch is not actually a respawn method. Instead it removes the touch event for the reward. This allows you to set static or constant with hurt or kill without triggering when a player touches it. static similar to pickup except the entity will not disappear. Instead, it will be inactive until the respawn time has passed. constant will never disappear, while a player is touching it, the command will run constantly. Useful with sm_teleplus commands.
Shortcut switches act differently from the -d switch. Most of the shortcuts combine to create the desired effect while the -d switch will overwrite. There are a few exceptions.
Here is what each one does internally:
-d pickup sets just pickup.
-d static and -d constant will also set pickup.
-d nohook will remove everything.
-d hurt will only add the hurt event to whatever settings are already present.
-d notouch will only remove the touch event from whatever settings are already present, so notouch by itself is the same as nohook.
-d kill will also set hurt.
-P will only add pickup without affecting the other settings.
-S will remove constant and add static without affecting the other settings.
-C will remove static and add constant without affecting the other settings.
-H will only add hurt without affecting the other settings.
-K will add both hurt and kill without affecting the other settings.
-N will remove pickup without affecting the other settings.
You can also simply provide the bitmask of the desired settings to the -d switch (this is how rewards are saved to cfg):
HOOK_DEACTIVE is used internally when a static reward is in its disabled state. You can use this value only upon creation or modification to make it wait respawn_time before appearing or activating.
HOOK_TOUCH must be used to hook when a player touches the reward. With no other values, this acts the same as -d pickup.
HOOK_HURT must be used to hook when a player damages the reward. With no other values, this acts the same as -d hurt.
To re-create -d kill you need to OR HOOK_HURT with HOOK_KILL to get -d 36.
See version 0.172 in the changelog at the bottom of this post for examples.
About sm_exec2 and sm_teleplus
Spoiler
These two commands are useful to use as the commands for rewards when you want to execute more than one command, teleport/rotate a player, or give them a speed boost.
Usage for both of these commands is described in detail above.
Here are a few examples used in video #2 above:
Code:
sm_exec2 #player freedom 0 has eaten the Freedom Pretzel!
This is the exact command used on the pretzel. It executes "cfg/freedom.cfg" and displays the message: "#player has eaten the Freedom Pretzel!".
Code:
sm_exec2 #player grapple_on 0 has raided Batman's grappling hook stash!
This is the command used on the ambulance (Bat Mobile). It executes "cfg/grapple_on.cfg" and displays the message: "#player has raided Batman ' s grappling hook stash!".
Because of how sourcemod processes argument input, I've yet to fix the extra spaces around the single quote :(
Code:
sm_exec2 notused grapple_off Batman has recovered his stolen grappling hooks!
This command isn't shown in the video, but inside of the grapple_on.cfg file, there is a command that schedules that command to run after 15 minutes.
When it runs that command, it executes "cfg/grapple_off.cfg" and displays the message "Batman has recovered his stolen grappling hooks!".
Code:
sm_teleplus #player ~ ~ ~ ~ ~ ~ ~1000 ~ ~
This is the command that is used on the two red crates above spawn in video #2 that create a sort of player cannon. It keeps the player's coordinates and angles, but adds 1000 to their X velocity.
Code:
sm_teleplus #player ~ ~ ~ ~ ~ ~ ~ ~ ~9999
This is the command used on the dome at the end of video #2 that launches the player up high into the air. Like the previous command, keeps the player's coords and angles, but adds 9999 to their Z velocity.
This is the command used on the spy target from video #2 that teleports the player to the bottom of the end and makes the screen shake. The coordinates are set to specifically, the angles are kept intact, the X and Y velocity is set to 0, and their Z velocity is decreased by 9999 shooting them directly downward.
This one I'm showing the full command, to show how to properly add horizontal momentum without friction coming into play.
The respawn_mode for this reward is pickup with a 1 second delay before respawning. This gives the player enough time to be launched away before coming back and either being inside the player, or applying friction. The teleplus command simply adds 3500 units of velocity to their negative X and adds 150 to their Z acting as an almost half jump upward.
Code:
sm_teleplus #player @aim
This one can only be used by players and it acts similarly to sm_tele #player from the funcommands plugin, teleports the target(s) where you are looking. You can also include rotation and velocity after @aim if you like.
About models
Spoiler
Anywhere a model is accepted is expecting the full path to the model file, including extension. This can be anywhere the game looks for models, meaning in the base game or the current mod. You can also use custom models as well.
Provided in the package is an aliases.cfg file of a couple handfuls of models I have found that work in TF2. Some are probably not limited to TF2 though.
About scripts, overridescript and entity_property_script
Spoiler
An overridescript is a series of variables dispatched to the entity as an overridescript or individual keys to trigger.
Format: overridescript?key[,[type=]value] type may be one of the following: int float or string.
Multiple key[,value]'s can be separated on the right side of the ? by &'s.
On the left side of the ? is all one string sent to the entity as a overridescript, this can often simplify a series of key dispatches in one go.
For all other key,value dispatching, you may provide individual ones on the right hand side of the ?. Only the first found ? is evaluated, so if you need to send one in a key,value pair, this will be fine as long as it appears after the initial ?.
If you need to dispatch a key that does not have a value (accept entity input), simply do not include a , (comma).
An entity_property_script allows you to define a series of entity properties.
Format:
[prop_type:]key,[type=]value prop_type must be 0 for Prop_Data (default) or 1 for Prop_Send. type may be one of the following: int float string ent or vec.
For vec, value must be a series of 3 floats separated by commas.
Multiple key,value pairs can be separated by &'s.
Please do not set m_iName here. Use the -n switch to set a name.
This format is exactly the same as the right side of the ? for an overridescript.
The difference is that these key,value pairs are sent using a different method, SetEntProp[type].
The reason for not setting m_iName here is because internally, the plugin will always set a name (whether one was provided or not), to ensure the correct entity was found when killing. If you set it here, the plugin will never be able to locate the entity.
I am not very familiar with Hammer/Source SDK, but I believe this allows you to set just about every piece of data any entity may ever need.
Provided in the package is a scripts.cfg file with a couple of scripts to get you started. np short for "no physics" disables all physics and shadows for the entity. Shadows tend to cause more lag when you have a lot of them, so for constant map-like entities or structures, this script should be used. dreidel gives the entity sort of "dreidel" like physics, it will spin like a top when hit and is fairly difficult to move in any given direction.
About Reward ID's and Names
Spoiler
Anywhere a command accepts an argument as reward_id|name you can provide either the ID # that the reward was assigned when created or the name given to it with the -n switch either when created or modified.
Names are limited to 31 characters in length and may not begin with a number, this includes negative numbers. They may not contain spaces, commas, @ symbols, or two periods in a row anywhere within them. Example: "invalid..name".
In some commands, you can also provide an ID range. An ID range allows you to select multiple rewards by ID # only.
This is used in the -E switch within sm_mrw_cfg_save and as the parameters of sm_mrw_remove. For these special parameters you can also use them just like normal with either a single ID or name.
Format for ranges is an optional number followed by two periods (..) followed by another optional number. At least one of the numbers must exist. The ranges are always inclusive.
If you leave the beginning number off, 0 will be used. And if you leave the end number off, the max reward ID will be used. Ranges don't care if the ID slot is actually in use or not, only active ones will be selected.
Examples: ..5 Will select the first 6 rewards. 10..19 Will select the ten reward ID numbers, 10 through 19. 26.. Will select the reward with ID number 26 and every reward following it.
There are also special reward selectors you can use: @n and @aim. @n will select the nearest reward to you, whether it is currently active or not. @aim will select the nearest reward to your looking coordinates, whether it is currently active or not.
If the reward is active, it will use its actual coordinates, if it is inactive, it will use its spawn coordinates to determine the closest one.
If these are used by the server, it will produce an error.
You can also use -1 to automatically select the most recently created reward. There is only one small issue with using this though. If the most recent reward if removed or released, then the reward with the highest ID number will be considered the most recently added one until a new one is added. In most cases this will not really be an issue, until you start removing and adding a lot of rewards in random order as the lowest available ID number is used upon creation.
The first parameters of sm_mrw_modify and sm_mrw_trigger allow a special reward selection format. This format can be any number of combinations of ranges, ID's, names, or selectors described above separated by commas. You can also remove rewards from the selection by prefixing them with an exclamation point.
Examples: ..10,@aim,@n,couch will select the first 10, whichever reward you are looking at, the nearest reward to you, and the reward with the name couch. 0..,!10..16,!couch,13,!@n,!-1 will select all rewards except for 10, 11, 12, 14, 15, 16, couch, the nearest, and the newest.
The 0.. part is necessary if you want to select all rewards that are not certain ones.
The final selection is processed in the order provided, so having a range at the end might end up re-adding some rewards that were previously deselected.
Dependencies
There are no longer any dependencies for Map Rewards. :)
Installation
If you wish to use the included aliases.cfg or scripts.cfg you can place them in the cfg/maprewards/ folder.
Neither of these cfg files are required, but aliases.cfg defines a lot of models for TF2 and scripts.cfg adds a couple useful entity scripts to get you started. Primarily np should really be used on any entity you don't want to have physics. It also disables shadows for the entity which can be a source of lag for some users.
Changelog
Quote:
1.001 - 1/28/19
Fixed bug with sm_mrw_cfg_load. Loading large files causes the server command buffer to overflow, only loading part of the cfg file.
Introduced a new bug in the process. Now when loading a cfg file, some bits of garbage data seem to be sent to the server. It is seemingly harmless and all the proper data is still processed and sent to the server correctly. Will require further investigation.
1.000 - 1/28/19
First officially stable release!
Reward names can no longer contain '@' or '..'.
sm_teleplus now accepts a target as the second argument.
Removed the following commands in favor of sm_mrw_modify:
sm_mrw_add_custom
sm_mrw_copy
sm_mrw_copyhere
sm_mrw_move
sm_mrw_turn
sm_mrw_release
Better code organization.
Integrated strplus.inc internally, so the separate include is no longer needed.
Removed colors.inc. Now color is handled internally.
Fixed sm_teleplus bug that incorrectly processed XYZ arguments as a target client string.
Fixed sm_mrw_trigger bug automatically setting the -X switch when a target is provided.
Optimized colors in chat.
Hopefully fixed sm_mrw_add help message being cut off.
Removed error output when trying to kill an incorrect entity.
sm_mrw_info is now more comprehensive and colorful.
Decreased precision of -T settings to 2 decimal places when saving rewards.
Now the -X switch in sm_mrw_modify will unset the hurt command if no command is provided.
Pre Stable Versions (240 builds)
Quote:
0.223 - 1/21/19
Added sm_mrw_trigger command.
Triggers a reward or set of rewards remotely.
If no target is specified, the executing client will be used.
Some minor code clean up starting preparations for a stable v1.0 release. v0.223 seems very stable and bug free, but most of the new alias evaluating is still mostly untested.
0.222 - 1/19/19
sm_mrw_add/modify switch changes:
-P no longer unsets static and constant.
-S no longer sets touch (pickup).
-C no longer sets touch (pickup).
Fixed error output from sm_mrw_modify.
Fixed bug with respawn_method not disabling the reward on spawn if spawned with -d 11 (static, pickup, HOOK_DEACTIVE).
Now reward names cannot contain spaces or commas, and cannot begin with a digit.
Now anywhere multiple rewards can be selected, multiple reward selectors may be provided by separating them with commas:
sm_mrw_modify ..10,@aim,@n,couch ... will select the first 10, whichever reward you are looking at, the nearest reward to you, and the reward with the name couch.
Added inverted reward selectors, to exclude them from the selection. Prefix the reward id/range/selector/name... with an exclamation point:
sm_mrw_modify 0..,!10..16,!couch,13,!@n,!-1 ... will select all rewards except for 10, 11, 12, 14, 15, 16, couch, the nearest, and the newest.
Doing !couch will not automatically select everything except for couch. You must first select everything (0..), then invert the ones you don't want.
The order of the segments is preserved in the final result.
All reward selectors are now allowed everywhere, including in sm_mrw_add, and they all work properly and as expected.
sm_mrw_add -b <@aim|@n|-1|id|name> is now allowed.
In places where only one reward can be selected (like -b), ranges nor the new format are allowed.
In places where multiple reward arguments are allowed, like -E (exclude) switches or sm_mrw_remove 1 2 3, the new format is not in place. The new format will probably replace it in a coming update though.
sm_mrw_modify/turn commands now allow multiple reward IDs like sm_mrw_move.
For conflict prevention, sm_mrw_modify will ignore the -n switch if multiple rewards have been specified.
Added glow rgba colors for rewards. Similar to the sm_colorize command.
Added new switches to sm_mrw_add/modify:
-l <R G B A>: Set a color overlay on the entity.
-L <integer_color>: Set a color overlay on the entity. 0 is fully transparent and -1 is full color and fully opaque.
-u: Unsets -U, causing the current definitions to be evaluated now. Does nothing if -U wasn't already set. Also does nothing with sm_mrw_add unless -b is used with a reward that had -U set.
sm_mrw_cfg_save/load now accept @aim as an argument for the -o switch.
Complete rewrite for how reward aliases are evaluated.
Now if both entity_type and model arguments are aliases and -U is used, the first appearing alias will resolve all options, then the next alias will only resolve for itself and any options that were not set by the first.
The old behavior stopped after the first alias was found.
Updated strplus.inc to v0.007, which adds the following functions:
StrFindFirstOf - Searches source for the first occurrence of any character within search.
StrSwap - Swaps the contents of two Strings.
0.195 - 1/13/19
Fixed bug with StrFind from strplus.inc not returning properly.
Fixed bug with sm_mrw_cfg_load failing to load relatively.
Fixed bug with reward ID range in the format of #.. where the end point would incorrectly be 0.
Fixed bug with sm_mrw_copy* commands not copying the turn interval from the -T switch, effectively making them not turn.
Fixed -b switch in sm_mrw_add and sm_mrw_modify not copying -T options.
Now sm_mrw_respawn can accept multiple reward ID arguments and ranges, just like sm_mrw_remove.
Now sm_mrw_move accepts reward ID ranges.
Added new switch for sm_mrw_add and sm_mrw_modify, -U, to make script, model, and entity_property aliases evaluate at spawn time.
Added new switch for sm_mrw_cfg_load, -N, will not add the origin to the commands before sending them to the server. Useful for cfg's with dangerously long commands.
Made string sizes consistent throughout the plugin, hopefully fixing various bugs due to limited "fake" size constraints.
This, combined with the new -N switch, seems to have fixed a weird bug with sm_mrw_cfg_load that certain configs wouldn't load every reward. (Don't get me started on this bug.. It makes no sense at all.)
Increased max command length to 1024 (from 128), however it will be impossible to actually use the entirety of this space, the largest possible command is realistically 1007.
Increased max reward limit to 512 entities.
0.191 - 1/7/19
Now commands like sm_mrw_move that reposition an entity have better checks in place to ensure it is the correct entity.
Allowed @aim to be used in sm_teleplus as second argument for client's looking coordinates.
Added sm_mrw_autoload option for loading maprewards/server.cfg on round start.
Fixed bug in the autoload function causing the cvar's bits to be ignored if any one bit for the given event is set. This bug was only present for the autoload cvar.
Round start event changed to teamplay_round_start so that the 5 second delay before spawning rewards could be removed.
Cleaned up code a bit.
0.188 - 1/2/19
Fixed bug improperly saving CFG files if a reward has multiple commands separated with semicolons in it.
Added a new -f switch to sm_mrw_cfg_save to overwrite existing files. Without the switch, an error will appear if the file already exists.
Added a new -E switch to sm_mrw_cfg_load, works exactly as the -E switch in sm_mrw_cfg_save except it only allows numbers and number ranges corresponding to the rewards in the file. Starts at 0, so to skip the second reward in the cfg you would use -E 1.
Anywhere a filename or path is accepted in a command no longer allows ".." to be present anywhere in the path. This makes these commands much safer.
Added new cvars that are used to control the admin flag permissions of each of the various sm_mrw_* commands, split into three categories:
sm_mrw_flag_basic - Controls all the basic commands not listed below.
sm_mrw_flag_create - Controls sm_mrw_add, sm_mrw_add_custom, sm_mrw_modify, sm_mrw_copy, and sm_mrw_copy_here commands.
sm_mrw_flag_extended - Controls all sm_mrw_cfg_* commands except for list and load.
All of these cvars accept only the character representation of the flags. So "m" for rcon, for example.
These flags can contain as many flags as you like strung together and the client must have all of them (or root) to use the commands. Example: "rm" would require the custom4 and rcon flags.
Separated the command that rewards run into two parts. The normal one is when the reward is touched and the new one is for hurt events.
If the new command is not provided then the old method will still apply. Both touching and hurt events will run the same command.
If you would like to hook hurt events without them running a command (in the case of exploding entities or something that naturally dies and needs to respawn) you can set the hurt event command to "null" and no command will run when it is hurt.
To set the hurt event command, you need to provide a new -X switch in either the add or modify command, this will make whatever command you enter be set as the hurt event command.
If you want to set both commands, you will need to set one command in the add command and the other in the modify command.
If you only set a regular command, it will run on both touch and hurt events.
If you only set a hurt event command, it will not run a command when touched.
0.179 - 12/23/18
Added @aim for use anywhere a set of coordinates are used. (Currently only -c and -o)
Will use the location where you are looking.
Example: sm_mrw_add -m woodcrate -c @aim -s np
Added a new switch -A <health> for sm_mrw_add and sm_mrw_modify.
Sets the reward to have this much health before being killed and triggering.
Only takes affect when the respawn_method is set to kill.
After countless failed efforts to make this work simply with entity_property_script and different entity types, I decided to just make it with the plugin. It works rather nicely.
Setting this to 0 is the same as not setting it at all. The plugin will never kill it due to damage.
Specific entities that work correctly with m_iHealth should use that instead. This option is for the rest of them.
Note that entities or models without physics properties or proper collision groups will not be able to take damage.
0.173 - 12/23/18
Fixed sm_mrw_cfg_save so the HOOK_DEACTIVE flag is no longer saved.
Added new usage response for new options added in v0.172.
0.172 - 12/23/18
Added new reward respawn methods (-d):
hurt shortcut -H - Sets the trigger method to when the reward is hurt by a player.
kill shortcut -K - Sets the trigger method to when the reward is killed by a player.
notouch shortcut -N - Removes any on player touch events for the reward.
The actual respawn methods will still apply for when a reward is activated, whether it be by touch or hurt.
constant will allow a hurt reward to never be killed.
static will allow it to be killed only if enough damage is dealt, otherwise, while it is deactive, the reward cannot be killed. When it is hurt, but still alive, touch will also be deactive until the respawn time is up.
pickup does not affect hurt or kill, both will work independent of each other.
Using shortcuts will now only remove conflicting settings, using multiple shortcuts can be used to combine options:
-C -H -N will create a reward that can only be triggered when shot and will never die or despawn.
-S -d constant -N -d kill will only apply -d kill. All -d options except for hurt and notouch completely reset to the provided option.
-d static -N -d hurt will apply all three in the order provided, it will be static activate when touched, disable activation on touch, enable activation on hurt.
All of the old options automatically apply on touch while hurt and kill automatically apply on hurt. With only hurt or kill set, it will respawn as if pickup had been set without touch.
hurt will kill the entity (unless static or constant is set), so for something that explodes, for example, use kill.
Even if you don't want to run a command for the entity, you can still use kill in case the entity is killed, so that it can respawn on its own.
You can also use -d # where # is the set of desired values OR'd together:
HOOK_DEACTIVE is used internally when a static reward is in its disabled state. You can use this value only upon creation or modification to make it wait respawn_time before appearing or activating.
HOOK_TOUCH must be used to hook when a player touches the reward. With no other values, this acts the same as -d pickup
HOOK_HURT must be used to hook when a player damages the reward. With no other values, this acts the same as -d hurt
To re-create -d kill you need to OR HOOK_HURT with HOOK_KILL to get -d 36.
Added another special string for reward's command definition: #inflictor will resolve to the entity ID of the entity that directly damaged the reward.
Only gets evaluated if the reward was triggered by a hurt event.
#player will always be the player that caused the damage. The value of both #player and #inflictor will be the same unless the damage was caused indirectly.
0.168 - 12/22/18
Adjusted the admin flag requirements to ROOT for security purposes of the following commands:
sm_mrw_cfg_save - Can be abused to overwrite unwanted files.
sm_mrw_cfg_delete - Deletes files, can be abused to delete unwanted files.
sm_mrw_cfg_purge - Deletes specific files, cannot be abused, but still risky to allow non root admins permission of this.
0.167 - 12/22/18
Allowed @n within sm_mrw_cfg_save. I can't think of any real reason I didn't do this in the first place.
0.166 - 12/22/18
Fixed bug with sm_mrw_tp relative velocity being relative to 0,0,0 instead of player's velocity.
sm_mrw_tp now teleports to the reward's current coordinates instead of their spawn coordinates.
Added a special option @n which will automatically select the closest reward to you.
Works anywhere a reward ID or name is allowed, except within sm_mrw_add or sm_mrw_cfg_save, because it might select the incomplete entity it is currently creating.
Does not work if ran by the server.
Does not work within reward ID ranges.
Added another special string for reward's command definition: #reward will resolve to the ID or name (if named) of the triggering reward.
0.161 - 12/20/18
Fixed bug with rotation timers (-T) not naturally decaying.
0.159 - 12/17/18
Initial Release
Additional notes
Quote:
Originally Posted by Disclaimer
This plugin has some very sensitive syntax, but I have tried
to make it intuitive.
An amount of care should be taken when summoning certain
entities with certain property values. Incorrect or careless
values could result in server and/or client crashes.
Map Rewards is released without warranty of any kind.
In all of my testing I have yet to witness a crash of any sort, just be cautious of what you are attempting to do. This plugin only affects the current session, so if the server crashes it should be fine when it comes back. If you have auto-saving enabled and manage to add a server breaking entity, you may need to manually delete or modify the cfg file so the plugin doesn't attempt to re-create it; the entity in question should end up as the very last line of the cfg file.
This is the first plugin like this I have made, and I am not very familiar with entities or their datamaps so please don't hesitate to point out any errors I might have made.
And although I am rather familiar with SourcePAWN, I don't actually know the language, so there may be some parts of my code that could be simplified.
Changes
Fixed a bug causing timers in charge of rotating entities created with the -T switch to incorrectly apply garbage rotations to unrelated entities.
Dude this seems really cool, I kinda was looking for something like this to for instance place custom props (like pots) around the maps that when either broken or touched (maybe the TF2 gift models) that it would give credits for the Store plug-in I am going to run. This sounds like a really fun thing if I'm reading the description correctly. I am definitely going to check this out.
Dude this seems really cool, I kinda was looking for something like this to for instance place custom props (like pots) around the maps that when either broken or touched (maybe the TF2 gift models) that it would give credits for the Store plug-in I am going to run. This sounds like a really fun thing if I'm reading the description correctly. I am definitely going to check this out.
Yep, this can do that. Except for the breaking part. I plan to add in a means for determining if an entity's lifespan has ended, like when a tf_pumpkin_bomb gets shot, but I've got no real idea how I'm going to go about that yet.
This update adds some exciting features, now entities that can take damage can trigger commands when they are hurt or killed. They will also respawn automatically using whichever respawn method you have selected.
Full changelog:
Quote:
0.173 - 12/23/18
Fixed sm_mrw_cfg_save so the HOOK_DEACTIVE flag is no longer saved.
Added new usage response for new options added in v0.172.
0.172 - 12/23/18
Added new reward respawn methods (-d):
hurt shortcut -H - Sets the trigger method to when the reward is hurt by a player.
kill shortcut -K - Sets the trigger method to when the reward is killed by a player.
notouch shortcut -N - Removes any on player touch events for the reward.
The actual respawn methods will still apply for when a reward is activated, whether it be by touch or hurt.
constant will not allow a hurt reward to never be killed.
static will allow it to be killed only if enough damage is dealt, otherwise, while it is deactive, the reward cannot be killed. When it is hurt, but still alive, touch will also be deactive until the respawn time is up.
pickup does not affect hurt or kill, both will work independent of eachother.
Using shortcuts will now only remove conflicting settings, using multiple shortcuts can be used to combine options:
-C -H -N will create a reward that can only be triggered when shot and will never die or despawn.
-S -d constant -N -d kill will only apply -d kill. All -d options except for hurt and notouch completely reset to the provided option.
-d static -N -d hurt will apply all three in the order provided, it will be static activate when touched, disable activation on touch, enable activation on hurt.
All of the old options automatically apply on touch while hurt and kill automatically apply on hurt. With only hurt or kill set, it will respawn as if pickup had been set without touch.
hurt will kill the entity (unless static or constant is set), so for something that explodes, for example, use kill.
Even if you don't want to run a command for the entity, you can still use kill incase the entity is killed, so that it can respawn on its own.
You can also use -d # where # is the set of desired values OR'd together:
HOOK_DEACTIVE is used internally when a static reward is in its disabled state. You can use this value only upon creation or modification to make it wait respawn_time before appearing or activating.
HOOK_TOUCH must be used to hook when a player touches the reward. With no other values, this acts the same as -d pickup
HOOK_HURT must be used to hook when a player damages the reward. With no other values, this acts the same as -d hurt
To re-create -d kill you need to OR HOOK_HURT with HOOK_KILL to get -d 36.
Added another special string for reward's command definition: #inflictor will resolve to the entity ID of the entity that directly damaged the reward.
Only gets evaluated if the reward was triggered by a hurt event.
#player will always be the player that caused the damage. The value of both #player and #inflictor will be the same unless the damage was caused indirectly.
Awesome plugin, but I prefer to write plugins for such things instead of using something limited like this.
Thanks for the feedback, but as much as I agree with you on that for those specific cases, this plugin is for everything else. This plugin aims to easily create rewards on the map and on the fly. In almost every case, this plugin far exceeds the needs to do that.
With each update, more and more limitations are being lifted. You can fully customize the entity itself as much as you can in SourceSDK and there are tons of customizable options and combinations to configure the entity's interactions to your liking. With the most recent update, you can safely create something as unique as a tf2 pumpkin bomb that copies itself upward each time it explodes:
Now you have an infinite pumpkin ladder that climbs as it's broken.
This was possible in older versions, but it's actually tested and working properly as of v0.188. I think there were some slight problems with this similar setup before.
And of course, if you can think of anything else you think I should add, please let me know.
Edit: Actually, after some consideration, this would be a simpler way to achieve the same thing:
Fixed bug wtih StrFind from strplus.inc not returning properly.
Fixed bug with sm_mrw_cfg_load failing to load relatively.
Fixed bug with reward ID range in the format of #.. where the end point would incorrectly be 0.
Fixed bug with sm_mrw_copy* commands not copying the turn interval from the -T switch, effectively making them not turn.
Fixed -b switch in sm_mrw_add and sm_mrw_modify not copying -T options.
Now sm_mrw_respawn can accept multiple reward ID arguments and ranges, just like sm_mrw_remove.
Now sm_mrw_move accepts reward ID ranges.
Added new switch for sm_mrw_add and sm_mrw_modify, -U, to make script, model, and entity_property aliases evaluate at spawn time.
Added new switch for sm_mrw_cfg_load, -N, will not add the origin to the commands before sending them to the server. Useful for cfg's with dangerously long commands.
Made string sizes consistent throughout the plugin, hopefully fixing various bugs due to limited "fake" size constraints.
This, combined with the new -N switch, seems to have fixed a weird bug with sm_mrw_cfg_load that certain configs wouldn't load every reward. (Don't get me started on this bug.. It makes no sense at all.)
Increased max command length to 1024 (from 128), however it will be impossible to actually use the entirety of this space, the largest possible command is realistically 1007.
Increased max reward limit to 512 entities.
I'm trying to prepare the code to transition into a better reward ID system that will allow better control over multiple entities at the same time, it should be ready soon!
Several bugs have been smashed thanks to a lot of major code rewrites. Also aliases are evaluated much faster and smarter, most commands allow targeting multiple rewards at the same time, and you can colorize and even make rewards invisible now!
Check out the full changelog for v0.222 in the OP for all the details and usage examples.
Linear Mode
