Raw directional input access from ZScript

Moderator: GZDoom Developers

User avatar
Gutawer
Posts: 469
Joined: Sat Apr 16, 2016 6:01 am
Preferred Pronouns: She/Her

Raw directional input access from ZScript

Post by Gutawer »

ZScript's ability to override the base movement code in a player pawn is really useful but one major blocker that's always annoyed me is the awkward range of values given from cmd.forwardmove/sidemove that are presumably inherited from weird design decisions in the original source.

With forwardmove, sprinting gives 12800 on a keyboard+mouse while not sprinting gives 6400. Already this is kind of annoying because sprinting is tied to the movement system, but it gets worse when sidemove is considered. Sidemove while sprinting on KB+M gives 10240, while not sprinting gives 6144. 6144 is not half of 10240, so this gives an awkward inconsistent ratio of sprint/run speeds, causing even more annoyance.

On top of this, you have the effect causing SR50 where sidemove can be compounded by using the strafe modifier to exceed what the normal bounds on sidemove are, which *also* has to be accounted for by anyone trying to design a movement system that doesn't feel like Doom's (example: removing straferunning altogether). Trying to use all this to make a system that's also compatible with controllers is really annoying.

My point is, all this stuff is really awkward baggage from how Doom's movement system fundamentally works, and it'd be really useful to be able to access more raw data from the input system. My suggestion goes somewhat like this: new fields on UserCmd called rawYAxis and rawXAxis (there's probably better names but you get the point) which are float values guaranteed to be between -1 and 1. They should not be affected by sprinting, and there should be no difference between the two axes - with WASD, pressing W should make rawYAxis 1 as D should make rawXAxis 1, and there should also be no discrepancies between the two axes. Needless to say everything should also work fine for controllers. A system like this would make designing a custom movement system much less of a headache.

(As a side note, I'd try to do this myself and PR it, but I can't really find where input is handled in the engine.)
gramps
Posts: 300
Joined: Thu Oct 18, 2018 2:16 pm

Re: Raw directional input access from ZScript

Post by gramps »

This sounds really useful.

Just wondering, if W and D were both pressed (or analog stick pushed all the way to the upper-right), should you be getting back a unit vector, where X and Y are ~0.707 instead of 1? Don't have enough experience with analog sticks to know if they're normally capped like this, but it seems like this will need to be done at some point, and if it's left up to modder, it might never get done and you're back to running faster diagonally.

If capped to a unit vector, it would probably make sense to store it in a 2d vector instead of two separate components (otherwise individual components like you suggest here probably make the most sense).

Basically thinking something like velocityDelta = rotateVector(getRawDirectionalInput(), angle) * speed would be nice.
User avatar
Gutawer
Posts: 469
Joined: Sat Apr 16, 2016 6:01 am
Preferred Pronouns: She/Her

Re: Raw directional input access from ZScript

Post by Gutawer »

Normally an analogue stick is only capped by the physical boundary on the controller, the axes are often two separate potentiometers and therefore they could both report 1 as their values if the hardware was modified to allow the stick to go that far. I actually agree that this should be a vector, I just forgot about that when writing this, but I don't think it should be capped. For whatever reason someone might want to have straferunning and I don't think that should be blocked - it's easy enough to do the clamping ZScript side if it's wanted.
gramps
Posts: 300
Joined: Thu Oct 18, 2018 2:16 pm

Re: Raw directional input access from ZScript

Post by gramps »

I guess I'm just thinking if it's a vector, you could reasonably get away with capping the overall magnitude instead of capping each individual component. Either way it would be a useful feature.
Guest

Re: Raw directional input access from ZScript

Post by Guest »

Being able to access raw movement inputs as a vector with coordinates bounded between [-1.0, 1.0] would massively simplify input grabbing, and remove the ambiguity of whether someone's, say, running at 60% speed or walking at 100% speed. Ideally, this would be coupled with a boolean for run state, because at the moment you have to guess at that based off the preprocessed inputs (see: 60% run/100% walk).

Needless to say, yes I want this.
User avatar
Gutawer
Posts: 469
Joined: Sat Apr 16, 2016 6:01 am
Preferred Pronouns: She/Her

Re: Raw directional input access from ZScript

Post by Gutawer »

Yeah that'd be fairly useful too, you can kinda get that info from checking the BT_SPEED button and flipping it if cl_run is set for that player, but it's a bit messy and might not cover all edge cases, a boolean to say definitively if the player is sprinting would be nice.
User avatar
phantombeta
Posts: 2084
Joined: Thu May 02, 2013 1:27 am
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support
Location: Brazil

Re: Raw directional input access from ZScript

Post by phantombeta »

Gutawer wrote:Yeah that'd be fairly useful too, you can kinda get that info from checking the BT_SPEED button and flipping it if cl_run is set for that player, but it's a bit messy and might not cover all edge cases, a boolean to say definitively if the player is sprinting would be nice.
Uhm... Checking cl_run should never be done. It's a completely local CVar, so it'll cause an instant desync if someone has it on but someone else doesn't
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Raw directional input access from ZScript

Post by Rachael »

phantombeta wrote:Uhm... Checking cl_run should never be done. It's a completely local CVar, so it'll cause an instant desync if someone has it on but someone else doesn't
I don't know if that's the case without verifying it, but if it is, it definitely needs to be thrown in with the user serialization. I know it's technically not actually needed to drive player movement on the network since the network tracks the player's actual speed (since it's possible to move using purely the mouse), but all other input switches are thrown into the user stream because the player object WILL move differently based on their state if they are not in sync.

At any rate, the less CVARs we have out of the sync state, especially what I feel are critical input CVARs like this one, the better.
User avatar
phantombeta
Posts: 2084
Joined: Thu May 02, 2013 1:27 am
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support
Location: Brazil

Re: Raw directional input access from ZScript

Post by phantombeta »

It doesn't get synced and has never done so - none of the other CVars prefixed with "cl_" do, either.
I disagree that it should be added to the user serialization. First because it'd just make people more likely to do gross checks for it and make mods that break easily due to that. Second, it'd be inconsistent with the other "cl_" CVars - none of the "cl_" CVars are synced, and IMO it should remain that way.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Raw directional input access from ZScript

Post by Rachael »

I think the naming is a holdover from Quake which had a similarly named CVAR. If it bothers you that much, we can always rename the CVAR.

I am only expressing my own opinion, though.
User avatar
phantombeta
Posts: 2084
Joined: Thu May 02, 2013 1:27 am
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support
Location: Brazil

Re: Raw directional input access from ZScript

Post by phantombeta »

The naming is probably a holdover from Quake, yes - problem is, it'd make the usage of the prefix inconsistent. Right now you can tell if a CVar isn't synced just by checking the prefix - CL_? Not synced. GL_? Not synced either. VID_? Nope. R_? Also not synced.
Making one of the cl_ CVars synced would mess with that, which would be rather annoying, at least IMO... :\
Renaming also sounds possibly annoying, since people have it bound to keys - and thanks to GZDoom just binding "toggle cl_run" to caps lock and the "Toggle run" key in the menu also just binding that instead of an alias, that'd be a problem. (I don't mind changing it manually, myself, but I can see how it'd be annoying for others)
If there's some way for GZDoom to change/update things in aliases and keybinds, though, it shouldn't really be a problem, of course.

But IMO a better option would be to just to put a boolean indicating whether the player is running in the UserCmd struct - mods shouldn't care (or know) whether the player is running by using cl_run or not.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Raw directional input access from ZScript

Post by Rachael »

That is also a good idea, but a dangerous one, too, as expanding that struct will increase the size of both the network bandwidth and of demos, since it is sent for every frame for both, and an average game can have thousands of them. Arguably they're both quite small as it is, especially with compression, and would probably handle it gracefully - but I'd rather wait for Graf to respond to this to see what he thinks.

As for renaming the CVAR, I know it's a bad idea to use this system frivolously, but we have a system in place that converts config files from old versions. That was actually used when transitioning from a single CVAR for both the HQ rescaler type and size to splitting the CVAR in two. I'm fairly sure it can handle bindings too.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Raw directional input access from ZScript

Post by Graf Zahl »

If raw input is supposed to be used it will really open up a new can of worms, because the entire network traffic will have to be rethought.

Looking at the suggestion, for me it looks like the real problem is that the TweakSpeeds function is not virtual and cannot be overridden. Everything going beyond that would necessitate some rethinking of the network traffic and I really don't want to go there because it is code I do not really know.
Of course, if raw input is being used, the run state needs to be part of it. Not the cl_run CVAR and not the state of the 'run' key, but only the cumulative result of anything that can make a player run.

But as things stand, I choose to 'no' this request because I do not want to work on the network code.
User avatar
Arctangent
Posts: 1235
Joined: Thu Nov 06, 2014 1:53 pm
Contact:

Re: Raw directional input access from ZScript

Post by Arctangent »

One thing I feel like I should ask is whether or not changing the value of normforwardmove and normsidemove through, say, MAPINFO's GameInfo section would be feasible. That's probably the main issue here, rather than TweakSpeeds - the disparity between forwardmove and sidemove, especially in regards to how sidemove can't just be multiplied by, say, 1.25 in ZScript to match up due to the running speed only being 167% faster than walking, unlike how forwardmove where running is 200% faster.

Honestly, I don't even know if this sort of thing would even require direct number access through GameInfo - just a single boolean that makes sidemove's values 6400 and 12800 ( or even just 5120 instead of 6144 ) would be nice enough for my purposes.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Raw directional input access from ZScript

Post by Graf Zahl »

Indeed. Those two should be configurable.
Post Reply

Return to “Closed Feature Suggestions [GZDoom]”