Raw directional input access from ZScript

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Raw directional input access from ZScript

Re: Raw directional input access from ZScript

by Graf Zahl » Sat Jan 05, 2019 8:00 am

That old code really has its bad spots... :?
Yes, surely these need to be handled as well.

Re: Raw directional input access from ZScript

by Gutawer » Sat Jan 05, 2019 6:54 am

Oh, awesome! This already helps a ton. I think the only thing left that's needed to solve my initial suggestion would just be the reliable way to detect if the player is sprinting.

EDIT:

Oh, and also, as a side note, doesn't TweakSpeeds need to be changed to adhere to these constants properly? Right now it has them hardcoded still, for example:

Code: Select all

		if (health <= RunHealth)
		{
			forward = clamp(forward, -0x1900, 0x1900);
			side = clamp(side, -0x1800, 0x1800);
		}

Re: Raw directional input access from ZScript

by Graf Zahl » Sat Jan 05, 2019 1:50 am

... and done.

Re: Raw directional input access from ZScript

by Graf Zahl » Sat Jan 05, 2019 1:02 am

Indeed. Those two should be configurable.

Re: Raw directional input access from ZScript

by Arctangent » Fri Jan 04, 2019 9:34 pm

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.

Re: Raw directional input access from ZScript

by Graf Zahl » Sat Dec 29, 2018 1:42 am

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.

Re: Raw directional input access from ZScript

by Rachael » Sat Dec 29, 2018 12:26 am

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.

Re: Raw directional input access from ZScript

by phantombeta » Sat Dec 29, 2018 12:01 am

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.

Re: Raw directional input access from ZScript

by Rachael » Fri Dec 28, 2018 11:36 pm

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.

Re: Raw directional input access from ZScript

by phantombeta » Fri Dec 28, 2018 11:34 pm

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.

Re: Raw directional input access from ZScript

by Rachael » Fri Dec 28, 2018 11:27 pm

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.

Re: Raw directional input access from ZScript

by phantombeta » Fri Dec 28, 2018 11:19 pm

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

Re: Raw directional input access from ZScript

by Gutawer » Fri Dec 28, 2018 3:52 pm

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.

Re: Raw directional input access from ZScript

by Guest » Fri Dec 28, 2018 6:45 am

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.

Re: Raw directional input access from ZScript

by gramps » Thu Dec 27, 2018 3:29 pm

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.

Top