ZDoom

Feel free to use this in your mods! No need to ask for my permission.

A mod that attempts to reduce the slippery player movement in Doom. This mod is fully written in ZScript and works universally with any other mod.

NOTE: The player speed calculation might be completely off. I only tested with the default Doom player. Will update the mod once I get some better ideas.

Changelog:

19/03/2013: Initial release
20/03/2013: Fixed a bug that would affect jumping
09/12/2013: Added missing library declaration, updated download link in OP
26/05/2018: Full ZScript rewrite

Wow, great work with this. But... ewwwww. You made Doom feel... realistic.

I got so used to the slippery thing in the player movement in Doom, that this feels.. weird at first. It takes a bit to get used to.

Thanks for sharing, though.

This feels horrible, horrible! Die monster! You don't belong in this world!

Interesting concept however, heh. (But seriously, moving feels so bad with it.)

Nice idea but you seem to stop very abruptly with this. A real human moving quickly (not Doomguy quickly, of course) would have difficulty stopping that abruptly all the time I think. I'm sure a happy medium could be found somehow.

Interestingly, Graham Jackson added more abrupt stopping to Risen3D a couple of years ago. He has quite a few players that are used to more modern engines and some of them had asked about it. I tried it for a while and, as an experienced Doom player, it had a noticeable negative effect on my playing. I wasn't particularly aware that I did this but, for example in MAP01 I tend to turn as I am rounding the corner in the corridor before the final big room and at some point take my finger off the move button, letting the slide put me in the desired position. With the non-slippery movement in Risen3D I would end up not actually getting around the corner but standing facing the wall instead. The feature wasn't popular and it was removed.

Enjay wrote:Nice idea but you seem to stop very abruptly with this. A real human moving quickly (not Doomguy quickly, of course) would have difficulty stopping that abruptly all the time I think. I'm sure a happy medium could be found somehow.

This can be addressed by balancing out the Player.*Move speeds and the FRICTION_FACTOR constant so that the desirable amount of deceleration is achieved.

(Mind you, in games like Morrowind and Oblivion, the player stops even more abruptly, despite moving so fast. :O And such was also the case with Wolf3D, if I recall)

Regarding the other comments about how it doesn't feel like Doom: that is to be expected... with such a huge change in the movement dynamics, of course it's not going to feel like Doom anymore. :P

Anyway, that's kind of the point - and also why I made this (so that I don't feel like I'm playing Doom anymore) so... mission accomplished, I guess. XD I'm sharing the code here because I'm sure it will be of interest to TC authors who are making mods that aren't related to Doom... plus, I recall a few people have requested a tutorial so this was long overdue anyway...

It's all cool beans, and the Doom was never meant to be played with jumping in mind either... but as you stated, you wanted to give the modders and TC-makers some more edge. The thing is, when you jump, you loose your speed so abruptly that I end up in some maps not being able to cross a small gap. As I increased player speed, it still feels wonky to suddenly stop in midair. I guess one can check for the floor during jump, and deactivate the script on that time.

I'm calling it now. Every single shitty realism mod released for the rest of the year will have this code slapped in haphazardly simply because the mod maker is too poor to go buy the game he REALLY wants to play, so he just makes Doom into a mockery of both Doom and the game in question*cough*RGA*cough*.

Meh, I don't really see this becoming the nashgore of movement code... as I've said in my first post, this will perform like crap in internet multiplayer games, so bad that it makes the games unplayable online and shouldn't even be considered to be implemented into online mods which seems to be the biggest market for these realism mods...

Heh, neat. I remember looking at this ages ago to potentially add some sort of "Player.Inertia" variable for this purpose, but I couldn't wrap the math around my head at the time. I might try that again later, though I guess that would sorta obsolete all your work here.

Nash wrote:Meh, I don't really see this becoming the nashgore of movement code... as I've said in my first post, this will perform like crap in internet multiplayer games, so bad that it makes the games unplayable online and shouldn't even be considered to be implemented into online mods which seems to be the biggest market for these realism mods...

You think that would stop someone who wanted to make a shitty realism mod?

you can make the bobbing go back to normal if you change the true at the end of the scalevelocity function to a false, the last argument of SetActorVelocity determines whether or not velocity changes affect weapon bobbing

Xaser wrote:Heh, neat. I remember looking at this ages ago to potentially add some sort of "Player.Inertia" variable for this purpose, but I couldn't wrap the math around my head at the time. I might try that again later, though I guess that would sorta obsolete all your work here. :(

I actually would prefer an in-engine solution! :D I don't really like this ACS-based "hack" because

A) the multiplayer performance issues
B) the other caveats mentioned in this thread

you could also disable z scaling if you only wanted to change horizontal velocity and leave the vertical velocity alone.

just change the FixedMul(scale,GetActorVelZ(TID)) to GetActorVelZ(TID).

Whoa, I totally didn't realize what was going on because I never tested jumping. Turns out it was borked because I made a typo in spawning the collision checker. Jumping should be fixed now.

File in first post updated.

Also renamed ScaleVelocity to ModifyPlayerFriction because it has been modified to leave out the Z scaling and therefore can't be used as a generic velocity scale function.