Aura hotfix 3#25
Open
sabianroberts wants to merge 110 commits into
Open
Conversation
New votable cvars: * ag_fps_limit <0|number> - Default: 144. Set to 0 to disable, any other number for the actual fps cap * ag_fps_limit_auto <0|1> - Default: 0. Set to 1 to automatically calculate the fps that might fit best at any moment * ag_fps_limit_auto_check_interval <number> - Default: 10 (seconds). How often to calculate the fps limit New non-votable cvars: * ag_fps_limit_match_only <0|1> - Default: 0 * ag_fps_limit_steampipe <0|1> - Default: 1 * ag_fps_limit_warnings <number> - Default: 3 * ag_fps_limit_warnings_interval <number> - Default: 5 (seconds) * ag_fps_limit_punishment <slap|kick|ban> - Default: kick * ag_fps_limit_punishment_slap_intensity <number> - Default: 1 * ag_fps_limit_punishment_slap_interval <number> - Default:ag_fps_limit_punishment_ban_timeag_fps_limit_punishment_ban_time 1 (seconds) * ag_fps_limit_punishment_ban_time <number> - Default: 3 (minutes) Too long to explain them here. I have to add a wiki page or similar.
The command in question can be typed by a player on their client console while they're in an online server, and makes the server return info about the kernel and OS versions, which doesn't seem right. It's not info that a player would need, maybe an admin (AgAdmin) and still doubtfully. And it can be potentially used by people with bad intentions, to exploit some vulnerability or use the info in some other malicious way.
Defaulting it to enabled might take some people by surprise, some people won't care if there's a fps limit and others will want to set it to some other value than 144 anyways, so i think it's better to leave it off by default.
Server cvar, cannot be voted: * mp_intermission_skip_auto <0|1|2> - Default: 1 When enabled, it skips either the whole intermission or just the end of it, only if there's 1 player or none, excluding bots, but accounting for spectators and proxies. So if it's enabled and there's 1 player and 1 bot, it will be skipped. If there's 1 player and 1 spectator, it won't be skipped. This is for the case where a player joins a server and changes map while waiting for his mate(s) to join, so it changes the map very quick. Also when you're playing in a bhop server alone, and there's no point in waiting for the intermission, because the score is almost meaningless in that gamemode and there's no one to chat with at the end. If the score is meaningful, setting it to 2 might be bad; 1 would be better, so that in case there's a player practicing against a bot, the chattime is not skipped and they can see the score during that time, but the rest of the intermission is skipped automatically. When it's set to 0 it's disabled, so nothing changes. When it's set to 1, only the part after the chattime is skipped (the 2nd part of the intermission). When it's set to 2, the whole intermission is skipped, including the chattime.
sv_ag_max_spectators is the one used in AG
New vote commands: * agmaxtime - Extends the time limit to the maximum allowed * agmoretime - Extends the time limit by a certain amount of minutes, defined by server New cvar: * sv_ag_vote_extra_timelimit <0|number> - How much time the `agmoretime` vote will add, default 30 minutes. 0 to disable Quality-of-life votes. Tired of not knowing how much timelimit you can vote for? Afraid of getting the map changed because you might vote a lower mp_timelimit than the current one? These new votes come to resolve these issues. `agmoretime` can actually make the timelimit go beyond the maximum allowed, that's if it's allowed by `sv_ag_vote_extra_timelimit`. I think it's good to let the players extend it as much as they want, because otherwise they'll just reset the map to reset/overcome the limitation, so it's just dumb putting obstacles to voting the timelimit. `agmoretime` is designed to extend time by a limited amount, because the server owner might not want to have the server 24/7 with that map, in the end they set `sv_ag_vote_mp_fraglimit_high` for a reason. Having to actively extend the time every X minutes is not fun, but at least you can go over the max limit and continue playing, while probably still complying with admin's decision on the max timelimit, because they probably don't care if the map is still going on as long as people is actively playing on it; the problem is when it's left empty with that map for a long time, they probably want to have it changing so people see another map and join the server to play it, or whatever reason. `agmaxtime` will vote for the max mp_timelimit or will remove the timelimit altogether if it's allowed to. Classic case where you want to grind a map and you don't know how much time you'll spend on it. With this you don't have to learn every servers' max timelimit anymore.
Fixed mangled game description resulting in servers not appearing in "Find servers"
People used to crash servers by rapidly changing their model to long names containing "%", and we used to have a metamod module to fix this, so now it's in the server dll instead Metamod module: https://svn.aghl.ru:8443/!/#HLModules/view/head/agfix/trunk/engine_api.cpp
This happened when someone joined the server and it would say: * has changed to team 'blue' And you would do +showscores or check the console to see who has just connected. Note: the game does not always show that message when a player joins, this commit doesn't fix that. Player instances are reused and it probably has something to do with that, but i don't know.
New cvar: * sv_ag_gamemode_auto <0|1> - Default: 1 When set to 1 it will change automatically to CTF or DOM if the map fulfills the criteria for CTF or DOM. This is the classic behaviour. You can set it to 0 if you don't have the gamemode switching automatically, which is useful for servers running HLKZ or other custom games.
Only try to change fps_max when a warning is about to be issued
New cvars: * sv_ag_satchel_destroyable <0|1> - Default: 0 (indestructible) * sv_ag_satchel_health <number> - Default: 15 * sv_ag_satchel_solid <0|1> - Default: 1 (solid) Satchels only be destroyed with blast/radius damage. I have tried a few things (added a comment/fixme) but couldn't make them killable with hitscan or other damage types, so at the moment you cannot destroy them with e.g. a glock. Any help with that is very appreciated :))
New cvar: * sv_ag_bots_allow_vote <0|1> - Default: 0 (bots won't count towards votes)
-1 frag for the player who changes team while on agstart, to avoid abusing model change to get a better spawnpoint
* Added GitHub Actions CI * Monthly reporting from GitHub Actions
Requires clientside changes. The client has to read a byte at the end of the TextMsg message, after reading the strings. This byte tells what type of message it is, so it should have cvars to control whether to ignore these messages or not, and the damage and spawn types should be ignored by default, but more might be added in the future, e.g. to be able to ignore name and model change messages, or join/leave messages.
sv_ag_bots_allow_vote is now sv_ag_bot_allow_vote. I think it's slightly more correct
New vote: * spawnbot - Spawns a bot that doesn't move and respawns when you kill it New cvars: * sv_ag_vote_bot <0/1> - Default: 1. Allow adding bots with the spawnbot vote * sv_ag_bot_limit <number> - Default: 5. Limit the amount of AG bots in a map This is the AG implementation of MT Bots. A chat message will pop up when you kill a bot, telling where it has spawned, and another message every time you damage it. This will be sent to everyone in the server, which is not ideal, but it's a bit of a hassle to have say commands or similar for every type of message and stuff, and I don't think these messages should depend on a serverside cvar, because some players might wanna see while others won't. So it's up to the clients to implement ignoring capabilities upon the message types that are now sent on TextMsg Message types: -1: type is absent, normal message 0: spawn message 1: damage message
New cvars: * sv_ag_flood_name_cooldown <number> - Default: 2 * sv_ag_flood_name_spec_cooldown <number> - Default: 60 * sv_ag_flood_model_cooldown <number> - Default: 2 * sv_ag_flood_model_spec_cooldown <number> - Default: 60 These cvars control how many seconds you have to wait to change name/model again, and there's also specific cvars for when you're on spectator mode, because some people are very expressive when spectating matches and they can bother the ones playing the match. The default 1 minute cooldown for specs is meant to diminish the annoyance, not to remove spectator expressivity altogether, although some servers may increase the cooldown to 1200 seconds (20 minutes) to stop them from talking, but that's up to the admins, I think 1 minute is good for now, we'll see if it needs tweaking. The 2 seconds cooldown for players ingame (not spec) is meant to stop fast name/model changing scripts that have been seen crashing servers in some ocassions. Again, we'll see if it needs tweaking.
New cvar: * sv_ag_unlimited_uranium <0|1> - Default: 0 (normal) Set to 1 so that gauss and egon don't use any uranium. Useful for a Gauss% run of HL1 where you only use gauss. And for a new version of Instagib and a new egon-only gamemode for tracking aim practice. Any uranium-consuming weapons added by plugins should account for this cvar to decide whether to spend uranium.
New cvars: * sv_ag_selfdamage <number> - Default: 1 (no changes to damage) * sv_ag_selfdamage_boost <number> - Default: 1 (no changes to player speed) Both of these are factors, e.g.: `sv_ag_selfdamage 0.5` means you get half the damage from hurting yourself. `sv_ag_selfdamage_boost 2` means you get 2x velocity boost from damaging yourself.
Now it works without having to reload the map, so you can do `impulse 101` immediately after `sv_cheats 1`.
New cvar: sv_ag_say_on_changelevel_delay <0|1> - Default: 1 (print CLD in chat) When you're doing a changelevel delay, sometimes you prefer having in chat the info of when are you enabling the changelevel delay and when did you actually go through the changelevel trigger, or when did it get activated. So by default it will now print this info in chat when you're doing CLD, and you can set it to 0 so it only displays in console, or top left on developer 1 or more
* Don't allow to use entities if player not spawned * Specify windows-2019 to fix CI builds * See if player with FL_SPECTATOR flag instead of EF_NODRAW for safe check * Revert CI, since changes been splitted to several requests
Players no longer block spawn spots by being right below or above it, when there's a floor separating the player and the spot. Same when there's a wall in between. If there's just a small obstacle between the player and the spot then it depends on whether the player is closer than 128 units and they can see the head or arms of the spawning player in that spot This could lead to having a player spawning in the next 6th spot instead of the 5 ones that people are used to. That may still happen but it will be more obvious that a player has blocked a spawn spot
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.