get_player_control() (probably bits as well) should work also when dead

[Zughy]

Luanti version

5.10

Summary

Title

Steps to reproduce

Either..

1. Join AES
2. Play either Block League or Fantasy Brawl
3. Hold down E: you can see the leaderboard
4. Die (both the minigames have a custom deathmenu: there's no formspec and players automatically respawn after a while)
5. Hold down E: nothing happens

Or.. (didn't test but it should work)

core.show_death_screen = function(player, reason) return end

core.register_globalstep(function()
	for _, player in pairs(core.get_connected_players()) do
            if player:get_player_control().aux1 then
                core.chat_send_all("Pressed") -- doesn't work when dead
           end
       end
end)

[sfan5]

Working as designed as far as we're concerned. If the player is dead they can't move, interact or press any keys.

[Zughy]

The fact I'm dead it doesn't mean the engine shouldn't check whether I'm pressing some keys. It's plenty of games out there where you can perform actions whilst dead, e.g. checking the leaderboard (usually with Tab). Practical example: Xonotic's clan arena, where if you die you must wait for the next round.

There are nodes that prevents you from jumping, but as far as I know we keep track of the jump key anyway. Which is what I expect

[MisterE123]

"Dead" is a theoretical construct that should be entirely under the control of the game, including what actions can be performed while in that state.

[sfan5]

Right now it isn't, so that would be a feature request.

It's not obvious how to change this in a backwards incompatible manner, too.

[Zughy]

It's not obvious how to change this in a backwards incompatible manner, too

Why? Custom death screen wasn't a thing until 5.10, players had no chance to press keys whilst dead (as there was a formspec)

[appgurueu]

Why?

Can't say for sure what sfan5 is thinking here, but I'd say because until now we have effectively ¹ guaranteed this, so mods may rely on it and not validate controls from a dead player.

Footnotes

1. Yes, technically this hasn't been explicitly documented (I think), but this is important enough that I would consider the effective, observed, relied upon behavior to practically carry some weight here. ↩

[Zughy]

mods may rely on it and not validate controls from a dead player

Which is ironic, as two mods out of two (made by two different people) expected precisely the opposite :P

(Yes, two people working on the same server, but we implemented the custom death screen at two different times without really talking with each other)

[sfan5]

No, it's because just dropping the "dead players can't do anything" code trivially opens up a cheat where the client just ignores death.
And even if you wanted to update MTG the old behavior is not easy to get back (with current APIs).

If this were to be configurable the default should continue to be freezing players on death.

[Zughy]

I must say, this is highly frustrating. @immagiov4 and I spent days to clean up our fake death system so as to swap it with the built-in one (due to the new function), to only find out, after we implemented everything, that it can't be a substitute of what we had, even if there is no mention of such behaviour in the docs. Then, after reporting it, it gets labeled as a feature request and the problem is sent back at us, where we'll enjoy finding out how to revert the change without losing the features that we built upon in the meanwhile (as we didn't notice immediately). I mean, it's not like bug = instant fix, so we'd have to find a hacky solution anyway, but now we also have to hope for a concept approval.

If I have to guess, more people will stumble upon this issue (only after having implemented everything)

[sfan5]

The root cause here is that we do not document all the hardcoded stuff the engine does.

[Zughy]

Which is ironically good in this case, because documenting it would have resulted in asking for a breaking change, making a thing that common games do even more unlikely to be featured (who knows when LT 6.0 is getting a release)

To any core dev reading: do NOT document this

[realmineplayer]

I‘m not sure whether my idea would belong to a mod or to the core, but here is it:
Wouldn’t it be possible to create something like “player states” where you can define for each which options the player has (so like can he move, jump, look around, …) which can be modified by mods? I think this can be implemented without problems with backward compatibility so it would solve the problem of @sfan5.

[sfan5]

To explain my 😕 reaction: Documenting things is good, because it avoids surprises like this one (for people who read the docs). And we can absolutely document things without giving guarantees.

I think this can be implemented without problems with backward compatibility so it would solve the problem of @sfan5.

Sounds to me like it would work fine.