If(KeyDown...

[Cutmanmike]

It's just a biiiiiiiiiiiiiiiiiiiiiiiiiiiig corner

[NiGHTMARE]

Like, say, a year ago?

My gut tells me that Doomscript is a myth - and will remain one.

Whenever I see Graf denounce Doomscript, I can't help but be reminded of Scuba Steve's continued statements that there would never be an Action Doom 2...

[HotWax]

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.

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. If the axis is unbound, you cannot check it with this function. 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.

[XutaWoo]

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."

[randi]

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.

a minor improvement of something that already exists

This is a feature that didn't exist, period, but it was very easy to add. It was not a significant time investment.

[Amuscaria]

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

[HotWax]

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.

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).

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?

[Demolisher]

who use the jump key to fly or swim up?

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

[Ryan Cordell]

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

[Amuscaria]

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

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).

[Demolisher]

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

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

[ThatOneZDoomer]

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?

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.

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"...

[Zippy]

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

[Macil]

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.

[ThatOneZDoomer]

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: Select all

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

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.