GetPlayerInput with other buttons

[GleasSpty]

I am working on a mod that allows you to revive your comrades when playing coop (see http://forum.zdoom.org/viewtopic.php?f=3&t=51692). When incapacitated, the player is only allowed to use a pistol or fists. The way the code is currently set up is so that, upon incapacitation, the player automatically switches to the pistol, unless either they don't have a pistol or already are using fists, in which case it switches to their fists. I would additionally like to allow players to switch between these two options when incapacitated.

To implement incapacitation, I give the player the PROP_TOTALLYFROZEN property, which implies in particular that the usual change weapon keys won't work. The idea then is to manually implement the weapon switching using GetPlayerInput. The problem with this, however, is that, at least according to the wiki, it doesn't seem as if GetPlayerInput has access to the usual change weapon keys, and that the only workaround would be having another key be used to change weapons when incapacitated.

Can GetPlayerInput really not detect when any of the change weapon keys has been pressed? If so, any suggested workarounds?

[wildweasel]

The weapon keys are not seen as input, as such; the weapon slots are essentially an interface construct that handles the "use [weaponname]" commands. Because there are so many ways to select a specific weapon (slot numbers, mousewheel, inventory items or weapons calling A_SetWeapon, etc), what gets read is not the key being pressed, but the weapon being selected.

In short, you'll have to find another way to achieve the effect you're going for.

[kodi]

It *can* be worked around by binding a script puke as well as the normal weapon switching to the number key in keyconf though.

[Matt]

Wouldn't APROP_TOTALLYFROZEN stop you from turning and thus prevent you from aiming? It also seems horribly unnatural to be completely frozen like that... why not just reduce the player's speed and prevent switching to any other weapon than fist or pistol?

EDIT: would a morph possibly be appropriate? (The morph could also check to see if you have the real pistol, then give you a shitty pistol that bobs even while you're still and sprays all over the place that is then taken away when you are healed and unmorph.)

[randi]

GetPlayerInput already provides access to every button that is tracked over the network (and thus available to the game simulation―even in single player).

[Matt]

Even weaponslots!?

What about drop?


EDIT: If not, how exactly does the game check to see if someone's dropping something?

[Arctangent]

Weapon slots are abstractions for "use x" commands; they're not 1-to-1, because of the whole fact that you can have multiple weapons per slot, but no actual button command is processed over the network I'd imagine.

Same with drop; it's just an abstraction for "drop x"

EDIT: In hindsight, I'm not sure if I'm using abstraction correctly here, but I can't really think of another term and it makes sense to me so hopefully the point still goes across.

[GleasSpty]

"Wouldn't APROP_TOTALLYFROZEN stop you from turning and thus prevent you from aiming? It also seems horribly unnatural to be completely frozen like that... why not just reduce the player's speed and prevent switching to any other weapon than fist or pistol?" --- That's correct. To account for this, I had to code to manually change the player's view. (Actually, the code I wound up using was essentially due to Nash---see http://forum.zdoom.org/viewtopic.php?f=3&t=51770.)