[Feature] Remove floaty, ice-skating movement

DecapitatedKneecap commented 6 months ago

GZDoom version

4.11.3

Which game are you running with GZDoom?

Other

What Operating System are you using?

Windows 11

If Other OS, please describe

No response

Relevant hardware info

No response

Is your feature request related to a problem? Please describe.

No

Describe the solution you'd like

Since first playing in the 90's, I've always hated Doom's slippery movement. There are mods that attempt to mitigate it such as nashmove, but they tend to break too many third-party mods such as:

The motorcycle jumps in Ashes (nashmove's author actually had to create a special nashmove just for Ashes)
The long slope you slide down to a final level boss in Elementalism (I forget the level, but it's a multi-headed hydra and nashmove causes you to get stuck at the bottom of the slope)
Any precision jumping such as the jump to the door to ep 1 level 3 in Rekkr or the jump to the platforms in the pits in CountryCide

Can we get a slider that lets the user decide the friction/floatiness of movement? It's time to fix this horrible design flaw once and for all. Seems like it would be a very simple change to make.

Describe alternatives you've considered

Nashmove. Eliminates floatiness, but breaks too many things.

Add any other context or screenshots about the feature request here.

No response

DecapitatedKneecap commented 6 months ago

Also, Nashmove's data is baked into the save itself. You can turn it off, but it won't affect your game until you change levels or edit the data out of the save.

DecapitatedKneecap commented 6 months ago

I just now discovered ZMove. Seems okay, but it was abandoned back in 2019, so who knows how long it will work. Also who knows what bugs exist or what mods it will break. Would be better to just put a basic slider in the source port itself, perhaps even porting into it the entire ZMove featureset.

RicardoLuis0 commented 6 months ago

This isn't planned as an engine feature, it can be done with mods and addons

DecapitatedKneecap commented 6 months ago

But, as I mentioned in my post, the mods are typically buggy, break third-party mods, and are baked into the save files so that you cannot remove them midgame. How hard could it be to at least make it configurable with a change to the ini file in a text editor? Seems like it's a simple change to make to the code.

madame-rachelle commented 6 months ago

What you call a "simple change to make in the code" is going to have precisely the same effect as the mods you mentioned - that they will break other mods, it will be buggy, and it will for sure break the games supported by the engine. Sorry but mods is the only path forward with this feature - ironically, for exactly the same reasons why you said it shouldn't be a mod.

DecapitatedKneecap commented 6 months ago

@madame-rachelle If it breaks any third-party mods, it would be mods that are specifically designed to work with the native algorithm, of which I bet none exist. Otherwise, it would "just work". On the other hand, writing mods that attempt to override the native behavior has adverse effects like I mentioned in OP (and recently discovered that ZMovement is buggy on moving floors). Plus, you could make it configurable so that the user could turn it off globally as opposed to the data being baked into the save. It's just a change that would affect how soon the player comes to a complete stop. I can't imagine how changing that would break anything.

madame-rachelle commented 6 months ago

What you are citing are issues with ZMovement, itself, which can easily be solved, but the mod has long since been abandoned by its original author. What you are dealing with is the limited tools that the author had at the time of creating the mod, either because the easy fixes we have for it now didn't exist back then or the engine was not very well documented and hence he was not aware of their existence.

GZDoom is saddled with enough technical debt as it is, and unfortunately this point alone is one that you cannot argue with the devs about. Let's simply face facts here: A lot of the features GZDoom has today, were created in a time when we did not have ZScript, and had it existed back then, they would never have been implemented into the engine in the first place.

I am sympathetic that this isn't the answer you wanted to hear - but even if I agreed with you I would not be able to talk the devs down from this stance anyhow, and it's not a whimsical stance to have to begin with. There are parts of the engine that are literally unmaintainable right now because of 2 and a half decades of features just like this being piled onto it without a second thought. No matter how "small of a code change it is" like you say, something like this requires a strong and founded justification which persuades that the engine is far worse off without this feature built in than with it - while still accounting for the technical debt and potential issues of having it.

coelckers commented 6 months ago

There is no chance this will be implemented engine side. All relevant code is now scripted and replaceable so such a move would be self-defeating.

ZDoom / gzdoom