hlsdk-portable
hlsdk-portable copied to clipboard
FWGS
Server Variable Features
1) Multiplayer Skill CFG
Permits the following vars in skill cfg:
sk_mp_suitcharger sk_mp_plr_crowbar sk_mp_plr_9mm_bullet sk_mp_plr_357_bullet sk_mp_plr_9mmAR_bullet sk_mp_plr_9mmAR_grenade sk_mp_plr_buckshot sk_mp_plr_xbow_bolt_client sk_mp_plr_rpg sk_mp_plr_egon_wide sk_mp_plr_egon_narrow sk_mp_plr_hand_grenade sk_mp_plr_satchel sk_mp_plr_tripmine sk_mp_plr_hornet
These allow you to override their respective beforehand hard-coded values for multiplayer. If left empty/0, retains the original hard-coded values.
2) sv_cheats Auto-Update
When the server emits a change in sv_cheats, this is now reflected immediately instead of at the start of the next game.
3) mp_disable_longjump
New multiplayer variable that allows you to disable longjump from being picked up.
Disclaimer
I barely comprehend C++, but thanks to the really easy waf compile process, I was able to continue bashing my head against these files until I got these working. That said, please carefully review what I've done, as I don't particularly know what I'm doing with C++.
Do we really need any of these changes in master?
I think we have this repo for the next reasons:
- Ensuring that it works on xash3d and widening the list of the supported platforms (android, etc.)
- Keeping the code up-to-date with Half-Life (e.g. latter cl_autowepswitch changes)
- Restoring Half-Life behavior that was removed at some point (e.g. there's a cvar to enable bunny-hop).
- Fixing bugs, leaks and potential crashes.
- Keeping mods in branches, making them easy to update by merging with master.
- Adding some nice singleplayer features (optionally enabled at compile-time) that a lot of singleplayer mods could benefit of, since they don't need to maintain the protocol stability.
Your changes don't fall into any of these categories. If you want them for your server, it's ok, just keep the branch in your fork and merge with master when needed.
I like the idea of sv_cheats autoupdate though. Other changes are just for more flexible server tuning.
That's fine. I saw them as harmless additions for, as you said, more flexibility than 'vanilla'.
Do you want me to make a separate PR for sv_cheats?
For future: 1 pull request for 1 feature
- Multiplayer Skill CFG
You can just change default cvar value without implementing special function. Like that:
cvar_t sk_mp_suitcharger = {"sk_mp_suitcharger","30"};
And even zero or negative value may be useful.
- sv_cheats Auto-Update I like the idea of sv_cheats autoupdate though. Do you want me to make a separate PR for sv_cheats?
What about god and noclip cheats?
I think new behavior can confuse players and need to have some bullet-proof in multiplayer.
- mp_disable_longjump
Such behavior can confuse players too and you can remove longjump from map using entpatch/ripent anyway.
You can just change default cvar value without implementing special function.
I don't think so. The multiplayer code always hardcode overrides the cvar values. What my function has done is create new cvars special for that MP override section that allows those overrides to be overridden.
Besides, I'm not trying to make a permanent change to the game. I wanted a config file that the server owner can freely adjust.
What about god and noclip cheats?
I'm not sure I follow this question. What does this have to do with my change?
I think new behavior can confuse players and need to have some bullet-proof in multiplayer.
sv_cheats auto-updating is already present in the Valve/Steam hl.dll. Launch a multiplayer game, type sv_cheats 1, and you'll be able to immediately use cheats. Before valve made that change, you had to reload the map. All my code does here is imitate what Valve has now.
Such behavior can confuse players too and you can remove longjump from map using entpatch/ripent anyway.
It's off (longjump enabled) by default. You have to go out of your way to disable longjump with this server command.
Again, for me to remove longjump from every map I play and have a second copy of a map just to decide whether or not longjump is usable is a lot more work than simply having a server variable that I can set in server.cfg.
For future: 1 pull request for 1 feature
I'm sorry. I can try to separate them, I'm just no git wiz. Sounds like realtime sv_cheats at the very least should be its own PR.
sv_cheats auto-updating is already present in the Valve/Steam hl.dll. Launch a multiplayer game, type sv_cheats 1, and you'll be able to immediately use cheats. Before valve made that change, you had to reload the map. All my code does here is imitate what Valve has now.
Ok, create separate PR then.
It seems xash3d already has fix for god and noclip cmds.
Ok, create separate PR then. Found a guide and working on it!
Since my other two changes don't fit your master branch requirements, what would you like to do with them? If nothing, feel free to close this PR...
I don't think so. The multiplayer code always hardcode overrides the cvar values. What my function has done is create new cvars special for that MP override section that allows those overrides to be overridden.
Besides, I'm not trying to make a permanent change to the game. I wanted a config file that the server owner can freely adjust.
Values from skill.cfg overrides default hardcoded sk_* cvar values.
Values from skill.cfg overrides default hardcoded sk_* cvar values.
Not in multiplayer on certain skills. See: https://github.com/FWGS/hlsdk-xash3d/blob/1737b8a8787f531d1063cbcdc7480d428c5b3b07/dlls/multiplay_gamerules.cpp#L140
cheats feature has been moved to #197. If there's desire for either of these other features somewhere, let me know. Otherwise, feel free to close this PR.
You can just register cvar with default value and use CVAR_GET_FLOAT callback to get value; If skill.cfg has custom cvar value, default value will be overriden.
cvar_t sk_mp_suitcharger = {"sk_mp_suitcharger","30"};
CVAR_REGISTER( &sk_mp_suitcharger );
gSkillData.suitchargerCapacity = CVAR_GET_FLOAT( "sk_mp_suitcharger");
You can just register cvar with default value and use CVAR_GET_FLOAT callback to get value;
I see what you mean now. We'd just want to note that the sk_mp* defaults are Valve's old override values. Makes sense.