A_WeaponReady: WRF_USER1 (etc.)

[NeuralStunner]

The four User# inputs are, like Reload/Zoom, natively supported and would offer a lot of expansion to weapon behavior. For example, I often alias User1 for grenade throwing. However, I have to use a combination of [wiki]GetPlayerInput[/wiki] and inventory-based "flags", which becomes a complete mess if the weapon's ready state is animated at all.

This would practically clone the Reload/Zoom behavior, with User1-4 states. The result should be enough built-in buttons to do just about anything.

I would also suggest a "dummy" flag that combines all four, E.G. WRF_USERBUTTONS, to keep code more concise.

[Major Cooke]

EDIT: Pull Request

New flags available, WRF_USER# (1-4) and WRF_ALLUSER.

Each flag allows the pressing of the keybind associated with the user button number.

The states as such are, inside of the weapons:

User1
User2
User3
User4

[Major Cooke]

EDIT: Nevermind this post.

[Arctangent]

... So is every weapon-related binding, excluding anything related to weapon switching.

Heck, didn't reload and zoom start are purely ACS-based binds?

[Major Cooke]

Nope. Randi commented that those would be implemented into zdoom weapon functionality eventually. Xaser finished the job.

[Gez]

Can a mod move this to Code Submissions please? I'll be uploading a pull request shortly.

Why not ask for a move after the pull request is made?

[Graf Zahl]

Why was this even moved. There's nothing here right now!

[wildweasel]

Why was this even moved. There's nothing here right now!

Cooke asked me to move it on IRC, I assumed he had a reason for it.

[Graf Zahl]

But no link. Please only move threads with linked code. Otherwise there is no submission so it should remain where it is.

[Major Cooke]

Sorry, that was my fault. I did have a link but after talking with Blzut, I took it down for several reasons thinking there was no point, and that Blzut was going to close it anyway after I realized this is pretty much ACS only.

Onto the problems themselves with this request, and here's the link (don't bother moving it again, it's pretty much a no in this regard):

https://github.com/MajorCooke/zdoom/tree/WRFUserStates

For starters, apparently Randi intended user1-4 to be acs only it appears. I found out why too, the comments explicitly say they'll be ignored on purpose, so it's not really possible as I don't know how to sift through those BT_ flag handling processes. I imagine it'd require a lot more work than what I have here.

https://github.com/rheit/zdoom/commit/5 ... fbc92eadca

Here is when Randi stated it's basically for ACS only.

Added GetPlayerInput() for examining a player's inputs from ACS. Most buttons are now passed across the network, and there are four new user buttons specifically for use with this command.

[Graf Zahl]

Yeah, but why shouldn't the same buttons be usable from weapons. As has been said, the reload action was intended just like this, too, untlil some external contributor changed it.

[Xaser]

Is there somewhere in the gamesim code that's ignoring any button presses with a byte 256 or higher? Unless there's some sort of filtering of the sort going on, I can't imagine why we couldn't do the same for the User# buttons as Reload/Zoom; the latter two were just unimplemented ACS-Only stubs as well until the A_WeaponReady handling was added.

[Major Cooke]

Yeah, but why shouldn't the same buttons be usable from weapons.

I completely agree. Hopefully blzut will speak his part on it. I still would like to have it happen.

As has been said, the reload action was intended just like this, too, until some external contributor changed it.

Not quite. Randi set this up originally with the intention of it being recognized from the getgo. Everything below that comment, however, is not registered and I don't know how to change that. I even basically just did what Xaser did off the getgo, but that right there says something deeper has to be modified, and I don't know what it is.

Is there somewhere in the gamesim code that's ignoring any button presses with a byte 256 or higher? Unless there's some sort of filtering of the sort going on, I can't imagine why we couldn't do the same for the User# buttons as Reload/Zoom; the latter two were just unimplemented ACS-Only stubs as well until the A_WeaponReady handling was added.

Yeah, I think roughly around here. Weird thing is, the highest is 128, not 256, it appears.

Another point of interest is this.

[edward850]

None of that relates to the buttons not being usable. If ACS can read them, the playsim already has them. There's no half-measure, as you cannot read arbitrary interface inputs.

Edit: ˅˅˅ Indeed, that's just a variable length encoder, just in a fairly raw form. It allows the button integer to be compressed to its shortest, differenced representation. If that wasn't working, GetPlayerInput would not be able to read those inputs.

[Xaser]

That piece of code looks like it's reading 4 bytes individually and saving them to the buttons var - i.e. reading everything. There's some goofy bitmasking going on, but the gist of it is that it needs to check them one by one since each 8th bit represents that there's another set of bits to read in (so as to send as little data as possible). Nothing in there suggests discarding a byte.

tl;dr: we should be fine.

[EDIT] Ed-sniped. His description is much more friendly than my bitwise ramblings anyway.