Revert "Remove a lot of p_* vars"

[sweet235]

This is an open source game. Once the cheat police takes over, we might as well depart.

[DolceTriade]

I don't think this is that exploitable, so I'm ok with merging this, but let's wait a few days before we do.

[Gireen]

what are the risks/benefits?

from what i see an read in the discussions p_hp and p_ammo are the only problematic ones with the use of auto reload and auto medikit.

If that functionality is desired why not enable it by default for all players instead of having it as a hidden enhancement for scripting players.

When its not wanted that everyone can do this, then it should also not be allowed for scripts.

[DolceTriade]

I mean I don't consider any of those are exploits and if someone were to make a PR with nice UX implementing them, I think it would be fine 🤷‍♂️

[slipher]

My philosophy of preventing cheaty actions with the vanilla software is similar to the idea that locks on doors are not for keeping out determined criminals, but rather nosy neighbors. Locking the lock demarcates a clear boundary so that someone who violates it is clearly doing bad, not just curious or something. It has value even if local burglars have super skeleton keys.

So ideally binds would not be excessively powerful and anything that is possible to do with binds would be a clearly permitted action that a player need not feel guilty about. But modifying the software to automate game-playing actions would be clearly crossing the line like breaking a lock.

p_hp is the primary cvar here I see "cheating" potential for. I think automatically using the medkit if you have less than 20 hp would almost always be advantageous and you would be able to save effort during fights this way. So I oppose bringing back p_hp.

In the commit message I mentioned a couple of others having potential but they're not terribly concerning to me :

• With p_ammo you could do something reload the rifle if you have less than 3 bullets and haven't fired in 2 seconds, or something like that. I doubt you could make reliably good and advantageous decisions this way though.
• p_credits could be used to automate purchasing decisions based on the number of credits, but you can do this to some extent without that anyway e.g. I have binds like buy bsuit; buy marmour; buy larmour which will automatically buy the best affordable armor. So p_credits doesn't make much difference compared to the already massive advantage of buy binds.

[slipher]

There was another motivation for removing these which was that according to @illwieckz, all the Cvar::Set calls had a noticeable impact on performance. If needed we might be able to work around this by concatenating a bunch of set commands together and sending it to trap_SendConsoleCommand.

I just checked the origin of the p_availableBuildings thing and it actually was intended for binds. Although I doubt whether having it omit locked buildings is desirable. I think people would just want to memorize "armory is 3 clicks up" not "armory is 3 clicks if the rocketpod is unlocked or 2 clicks if it's not".

commit 9e168b0
Author: Darren Salt devspam@moreofthesa.me.uk
Date: Thu Jun 20 20:20:53 2013 +0100

Set p_availableBuildings according to team, stage & class.
Buildings are listed in the order in which they're defined in enum buildable_t.

This is intended for use in bindings, e.g.
bind mwheelup "toggle building \$p_availableBuildings\$; build \$building\$"
bind mwheeldown "toggle - building \$p_availableBuildings\$; build \$building\$"

[illwieckz]

If I'm right this PR fixed the performance issue:

• Optimize p_* cvar setting #2986

[slipher]

If I'm right this PR fixed the performance issue:

* [Optimize p_* cvar setting #2986](https://github.com/Unvanquished/Unvanquished/pull/2986)

But a lot of the stuff is not going to work now without reverting #2986, since the function is only called on class or team change. Ammo and HP change frequently.

[illwieckz]

Ah yes!

Also in general I'm not supper happy with the idea of turning the bind system into a complete language (which maybe already is). I always found weird to stumble on some old wiki page explaining extensive programmable bind design as the pinacle of what a game would give to user so they can program their own build to start getting something usable. At the same time we did not have access to simple things like cycling the weapons with the mouse roll, and weapons were things you have to cycle in a selection list and they activate like you would buy something…

My opinion is that we would better implement usable binds than to implement a programming language each user can use to fix the game. And that's what we did (we implemented weapon cycling, improved buildable marking and deconstruction, etc.).