PP: Set player and balance variables

[iamgreaser]

There's a few forces in play here.

The immediate requirement

It is currently not possible to individually set the number of blocks or the number of grenades that someone has. It is only possible to set the blocks to 50, the grenades to 3, the health to 100, and the reserve ammo to the appropriate reserve ammo for that weapon (packet 0x1A), and then the reserve ammo and health can be fixed up using a couple of other packets (0x1C for ammo, 0x05 for health).

The cryptoclover servers use infinite ammo and blocks, but finite grenades. So when one throws a grenade, a message pops up saying %d REAL grenades remaining . This could be kept for clients which do not support a packet to set the grenade count directly.

So, here's what I'd suggest as things to be set which currently cannot be set via any means other than restock:

• Current block count
• Current grenade count

While we're at it, the existing packets only support an unsigned byte, so you can't have, say, 1000 health and 500 ammo without more kludge. So I'd suggest also having the following:

• Current health
• Current clip ammo
• Current reserve ammo

All 32-bit of course. And if you really want to disable things, then 0 is a good number. Infinite would be more like (((uint32_t)-1)>>1) .

Speaking of infinite values... imagine an infinite ammo powerup that lasts 30 seconds or something like that. This can still be done with surprisingly not horrible workarounds, but that ∞ symbol is just too good to not use. ("It's like a sideways eight!")

Let's get semantical

Now, if we're supporting setting values of things, there's a few more values which could be set, and the difficulty would be resetting them when joining a new server... if you noticed the author of this issue you probably know what I'm going to suggest after this part :^)

A rationale would be that we could set the base value of each thing and then we wouldn't have to set them every single time. Furthermore, we could express a value meaning "an infinite number of these things", Which Would Make A Lot Of Sense.

So you'd have a base number of blocks, a base health, a base number of grenades... and then we're starting to hit the weapon structure. And there's plenty of goodies we can change there ;)

But sticking to quantities rather than Making This Game Actually Really Balanced This Time, Honest, here's what I'm suggesting:

• Spawn, restock health
• Spawn, restock blocks
• Spawn, restock grenades
• Clip size for rifle, SMG, shotgun
• Spawn, restock reserve ammo for rifle, SMG, shotgun

But if it's cleaner to set all those things on respawn, then I would thoroughly recommend at least having the ∞ value available.

Enough about quantity, what about quality?

This is the part where you realise who's writing this proposal.

This is also the part where you have to say "if you don't support this extension, then your experience will be degraded, and you should probably use an up to date modern AoS client".

There are various extra values we could actually set.

• Left click spade period
• Right click spade period
• Block placement period
• Tool switch period
• Grenade inter-shot period
• Left click spade damage
• Grenade base velocity
• Grenade fuse length

Weapons

But that's tools, what about weapons? Well, glad you asked! Or I asked, but whatever.

Here's what's handled serverside and thus no extension is needed:

• Damage per body part

Here's what can be kinda done serverside but should ideally be synced clientside as the effects are otherwise weird, and thus would be a candidate for an extension:

• Reload period
• Clip ammo
• Reserve ammo
• Reload style (rifle or shotgun)
• Inter-bullet period

Here's what's handled clientside and outright requires an extension:

• Pallets per shot
• Spread
• Recoil Y
• Recoil X
• Block damage

Once this PR is pulled [UPDATE: it was accepted 4 hours before I posted this proposal and I didn't notice, so now we're waiting for it to get merged and then for the 0.1.4 release], the values in OpenSpades will match the values in the vanilla client: yvt/openspades#766

Other things

There's a few more values which could also be visited:

• Player sprint, sneak, scope, crouch speed
• Gravity
• Player jump height
• Spread modifiers for sneak, scope, crouch, possibly per-gun but probably doesn't need to be per-gun

I'd need to learn more about how the physics actually works before proposing stuff in this department, so getting all of these modifiable is probably going to have to come later, and it's hinting strongly in favour of that bytecode VM idea I have lingering.

And now for some high-quality quantity

What if this could all be assigned on a per-player basis?

That would require a fair bit of restructuring, so I'm not inclined to inflict this on the people actually working on the code, at least at the moment. But it would be pretty sick, so it'd be worth bearing in mind for later.

And some things could be assigned per-player, too, and there would be no jankiness as a result. That would require effort on the server side, while letting the clients get up to speed with things.

So how much would I want to put into an extension?

Great question, me!

• Have the quantity set commands in the first part.
• Have the spawn/re-thing quantity set commands in the second part.
• Have the tool and weapon value set commands in the third part, but don't do the stuff in the "Others" section.
• Apply balances globally rather than per-player. Per-player can come later.

And as for the command set: I'd be tempted to have a single packet like this:

struct set_player_and_balance_values {
   uint8_t extension_id[2]; // = {0x80, 0x--}
   uint8_t packet_id; // = 0x00
   struct {
      uint16_t key; // from an enum of values
      int32_t value;
   } __attribute__((__packed__)) entries[];
} __attribute__((__packed__));

Then we can do things Atomically™.

Later versions could also add a packet which assigns things to a specific player, but for now this should be fine.

Thoughts?

[10se1ucgo]

👍 In their current state clients "assume" too much, any move in the direction of dumbing down clients and offloading these assumptions onto the server for better customization is good. In the same theme for the future I think another good move would be to generalize game modes rather than having the annoying specialized client code we have now. I've had ideas for this based on Matt's client (as usual) with some ugly code, but I think the idea in general applies. See here. (ignore the weird async inconsistencies, i was in the middle of ripping out a bunch of useless instances of "async") A good start for this would be something like #11