ZDoom

[quote="Agent ME"]You can bind a key to one of them, and the ACS command can detect when you press them. Actual functionality might be added to those button presses later.[/quote]
This is the reason I cringed when I saw what the code was doing there. The command doesn't do anything [i]yet[/i], but it can still be checked by GetPlayerInput now? So basically if some modder (e.g. the previous couple posters) were to check for it in a mod they make today, it'll work exactly as they expect it to, since they're implementing all the actual reloading manually.

Now what happens in a few months/years when randy/Graf want to actually add functionality to that button? It'll break any mods that use the reload key made today that expect nothing to happen when the player presses it.

@ZDoomer: If you want to be safe with future versions of ZDoom, use one of the userX keys instead, and provide the player a custom bind in KEYCONF which binds to it. Checking (for example) BT_USER1 instead of BT_RELOAD means you're guaranteed that no unwanted behavior will be added to the control in a later patch.

[quote="ThatOneZDoomer"]Being an analog controller + mouse user, I fear that 95% of mods using this ACS coding will only check for key presses and not analog movement.[/quote]
Note that the buttons actually trigger both inputs (i.e. pressing the move forward button sets the BT_FORWARD control and sets INPUT_FORWARDMOVE to max), which means checking the axes is actually more reliable than checking the buttons. Hopefully mod users will realize this and use the axis inputs whenever possible.

@randy: I'd recommend that analog axes also set buttons in the same manner. The only potential issue I see is deciding at what threshold the buttons should be set. As I see it, any input that translates into player action in the game should set the button, thereby avoiding potential "cheating" by, for example, moving so slowly that the button input doesn't set and the ACS script misses it.

script 100 (void)
{
	if(GetPlayerInput(-1, INPUT_BUTTONS) & BT_RELOAD && CheckInventory("Bullet") < 8) setresultvalue(1);
	else setresultvalue(0);
}

  Ready:
    PISG A 1 A_WeaponReady
    PISG A 0 A_JumpIfNoAmmo("Reload")
    PISG A 0 A_JumpIf(acs_executewithresult(100, 0), "Reload")
    loop

it won't work for old shit but new shit can
[code]script 100 (void)
{
if(GetPlayerInput(-1, INPUT_BUTTONS) & BT_RELOAD && CheckInventory("Bullet") < 8) setresultvalue(1);
else setresultvalue(0);
}[/code][code] Ready:
PISG A 1 A_WeaponReady
PISG A 0 A_JumpIfNoAmmo("Reload")
PISG A 0 A_JumpIf(acs_executewithresult(100, 0), "Reload")
loop[/code]

int buttons = GetPlayerInput(-1, INPUT_BUTTONS);
 
 if (buttons & BT_RELOAD)
 {
     print(s:"You are pressing the reload key.");
 }

So this means all mods with reloading weapons can now share one universal reload key instead of rebinding for every one of them or am I reading into this wrong? Would it just be a matter of using an ACS function in a ready state of a weapon to run a script that checks for the +reload key instead of the current use of dummy items? Once +reload is implemented, will the following script work?

[code]int buttons = GetPlayerInput(-1, INPUT_BUTTONS);

if (buttons & BT_RELOAD)
{
print(s:"You are pressing the reload key.");
}[/code]

Hope I'm not being annoying, I just want to make sure I fully understand this till mods start making use of this function.

Edit: Hmm... this feature already gives me some ideas. This could lead to even more complex melee weapons like changing the attacks based on what direction keys you pressed.

You can bind a key to one of them, and the ACS command can detect when you press them. Actual functionality might be added to those button presses later.

It means they're there and defined in case they receive an official implementation.

I'm thinking that some huge things can be done with this? Does this also mean things like guided missiles will no longer require it's only movement keys?

[quote="randy"]Movement made with the mouse does not translate into button presses, though you will get the axis readings from it. Movements with an analog controller stick do not generate button presses either; this may change, so that this system doesn't end up locking out people who want to play solely with a controller. Oldbuttons is a copy of buttons from one tic ago, so if you monitor input every tic, you can catch the moment when buttons are pressed and released by comparing oldbuttons against buttons.[/quote]

Being an analog controller + mouse user, I fear that 95% of mods using this ACS coding will only check for key presses and not analog movement. I feel like most mod creators wouldn't want to take the time to code for analog input movement when most players might be using the WASD standard. I'm not blaming you or anything (why would I since you made this possible in the first place?), but it's just something I'm worried about down the road.

For the r1215 change log, what exactly does the following mean: "Also defined +zoom and +reload for future implementation"...

[quote="Blade Nightflame"]Infact, it makes me wonder how (and why) nobody made a sort of swimming state yet through the use of A_JumpIf..[/quote]

I made a script, that if you used the lightning gun underwater, you gibbed...
And custom moving sounds for different water levels.

[quote="Blade Nightflame"]Infact, it makes me wonder how (and why) nobody made a sort of swimming state yet through the use of A_JumpIf..[/quote]

Was going to. But wasn't sure if it would work since I can't change the height of the player. And the way Zdoom handels crouching makes it problematic (crouching in water seems kinda strange).

Infact, it makes me wonder how (and why) nobody made a sort of swimming state yet through the use of A_JumpIf..

[quote="HotWax"] who use the jump key to fly or swim up?[/quote]

Add a waterlevel check, and perhaps something that would check if flymode is on.

[quote="randy"]Roll can be considered "reserved for future expansion". Admittedly, that will probably never happen, but it's part of the struct that this command reads, so it's there for the sake of completeness. Roll is exactly what Project Dark Fox described it as.[/quote]
Thanks for the clarification. And just so everyone knows, I'm not an idiot who can't figure out what "roll" means in this context. That's why I commented that it would make perfect sense in Descent (where you can rotate your ship in all 3 dimensions). :P

BTW, I notice that the keys for invnext, invprev, invuse, invuseall, weapnext, and weapprev are unsupported. Also, while you can check the strafe modifier key, you can't check mlook or klook. Any reason for not including these (other than the apparent limit of how much you can send across the network)?

@Eriance:

How would you make a "jump" state? Have ACS checking the player input constantly and force a state change when they press the jump key? Didn't Graf say that could cause problems when used in player classes? What about those players (like me) who use the jump key to fly or swim up?

I'f im interpreting this correctly, I can now add a Jump state to Hellion players. :D

Roll can be considered "reserved for future expansion". Admittedly, that will probably never happen, but it's part of the struct that this command reads, so it's there for the sake of completeness. Roll is exactly what Project Dark Fox described it as.
[quote="Michi"]a minor improvement of something that already exists[/quote]
This is a feature that didn't exist, period, but it was very easy to add. It was not a significant time investment.

I think roll's just a thing randy put in as a joke. I wouldn't be surprised that the code for that part is just a comment that says "This does nothing. Don't bother using it."

[quote="Caligari_87"]More likely it's a way of tracking the three-axis input for joysticks. Forward-Back, Left-Right, and Twisting. For the mouse and keyboard it won't do anything.[/quote]
From what I can tell, this function doesn't allow you direct access to any input device. It only allows you to check the results. For example, if your have a joystick axis bound to "Move forward/back", then pressing the joystick forward alters the value returned by INPUT_FORWARDMOVE. If the same axis is bound to "Fly/swim up/down", then pressing the joystick forward alters the value returned by INPUT_UPMOVE. [i]If the axis is unbound, you cannot check it with this function[/i]. Therefore, INPUT_ROLL cannot just be some arbitrary axis available only to certain joysticks -- that axis has to be set to something in the config menu to do anything at all. And yes, this is exactly the way it should work. (We want the modder to have access to the controlled input through ZDoom, not directly to the player's devices!)

From my testing, this is what I found each axis corresponds to (From the Joystick/Mouse menus):

INPUT_PITCH -- The analog value for mouse forward/back delta (if mouselook is on), and the Look Up/Down axis in the Joystick setup menu.
INPUT_YAW -- The analog value for mouse left/right delta (if mouselook is on), and the Turn Left/Right axis in the Joystick setup menu.
INPUT_ROLL -- ?????
INPUT_FORWARDMOVE -- The Move Forward/Back axis in the Joystick setup menu.
INPUT_SIDEMOVE -- The Strafe Left/Right axis in the Joystick setup menu. (I assume this can also be mouse left/right delta if the strafe modifier key is used)
INPUT_UPMOVE -- The Fly/Swim Up/Down axis in the Joystick setup menu.

Each of these will also report values when the appropriate key bindings are pressed, so for example pressing the key bound to "+forward" results in a positive value reported from INPUT_FORWARDMOVE. (Which means it's actually safer to check the analog input, since nothing will be reported by INPUT_BUTTONS if the user has Move Forward bound to a joystick)

I still have no idea what INPUT_ROLL is for. Future expansion? I tried all the different controls and every available axis and was unable to get anything but a 0 from it with randy's test WAD.