The problem with bots randomly going towards the same spot in podium was...
- If you failed a Sealed Star, K_UpdateGrandPrixBots wouldn't make the puppies non-spectators
- P_SpawnPlayer catches the spectator status...
- ...but it's in a loop that calls K_GetPodiumPosition...
- ...which ignores spectators...
- ...which means this is too late to catch it, so we simply have to do it earlier.
Also short circuits P_SpawnPlayer's and K_UpdateGrandPrixBot's attempts to set so the author of this commit can be certain what is being done is correct
Map things are writeable in Lua, which I am pretty certain is a mistake because mapthings are not sent over the network at all. I considered making them net-synced (it would be relatively easy), but it also aligns with another, more "philosophical" issue: Doom generally copies over properties from mapthing_t into mobj_t, and then only refers to it again when needing to respawn an object -- mapthing_t is not really intended to be referred to very often at runtime. At best it's slightly annoying since some objects rely on a spawnpoint for behavior changes, at worst it may make ACS more confusing in the future since Thing and Mobj tags are mixed together or less useful since they wouldn't be able to modify behaviors of objects that are based on args.
So I decided to solve these two issues at the same time; just treat mapthing_t as something to copy values from, like OG Doom does it. This basically just means that special and args are also part of the mobj now instead of the mapthing, which should fill any desire to edit this stuff from Lua, and reduces the number of instances where objects need to check for their spawnpoint to function properly.
These will always enter infinite loops in read_exact under correct use
when there is not enough data in them to read to the buffer, so we can
throw out early for EOF in those scenarios.
- Only show `Lap 0/Lap 1` if numlaps > 1, to match other circumstances where laps aren't real
- Only show player roundscore if gametype supports roundscore
- Otherwise accept a blank right side of the player bar in custom gametypes. (one day for Lua..?)
The intersection between processed buttons and raw keyboard data is a messy one and will probably never be perfect, but it is now consistent.
- Never overwrite a valid keyboard menuKey recieved this frame with a -1 if a different type of event is recieved as well.
- Store previous state of dpad_lr and dpad_ud on menucmd struct.
- Previously, if `a` was bound to Turn Left, it could produce a valid menuKey for one frame, then be considered a leftward input - switching from manual keyboard to Virtual Keyboard.
- It still only produces a valid menuKey for one frame... but we simply filter out leftward inputs that are older than this frame to keep things (relatively) clean.
- Show a textbox (with highlighted border) so the console font is more likely to be legible.
- Increases the width of the virtual keys to match this.
- Show menu entry name and tooltip on faded view (if they exist), for additional context for what you're writing
- Make the text entry and the virtual keys slide seperately
This function impl does not change any GL drawing state, and neither
should Vulkan, so the constraint that this function not be called while
a graphics context is active is not necessary.
This prevented hashing of non-const qualified types. The contract for
std::hash already implies that it is a callable for an lvalue reference
of the template type.
