MOVETYPE_FLY movement different from Quake

[hemebond]

When using MOVETYPE_FLY, or MOVETYPE_FLY_WORLDONLY, movement is extremely slow unless you're touching the ground, and it's not possible to move up or down.

Can test by using the fly console command or by setting the movetype in QuakeC, the effect is the same.

[Baker7]

Can test by using the fly console command or by setting the movetype in QuakeC, the effect is the same.

Just tested the "fly" command and even going back to "DarkPlaces Classic" it does not quite work like Quake.

However, the "it's not possible to move up or down" -- in a true vanilla Quake you have to bind +moveup / +movedown to keys -- and I'm not seeing any difference in behavior with the moveup/movedown.

I guess I'm saying, it is different but is not something that was "broken" recently .. the behavior probably goes back 10 years +.

I don't think any knowledgeable person would use "fly" over "noclip" -- and just to mention -- the "noclip" in DarkPlaces absolutely sucks compared to a FitzQuake/Quakespasm derivative (that was an early "correction" I made in Zircon engine).

[hemebond]

Thanks, you're right, I wasn't using my moveup key. I guess the issue is just that movement is extremely slow unless you're holding movedown and running along the floor. Perhaps this is the intended behaviour.

In my case I want to use MOVETYPE_FLY_WORLDONLY for spectators and low-gravity situations but it's not really usable as-is.

[Baker7]

Thanks, you're right, I wasn't using my moveup key. I guess the issue is just that movement is extremely slow unless you're holding movedown and running along the floor. Perhaps this is the intended behaviour.

In my case I want to use MOVETYPE_FLY_WORLDONLY for spectators and low-gravity situations but it's not really usable as-is.

Makes sense.

Thing is .. I haven't tried it in a while, but KleskBY's objectn forces you to watch other players after you die in certain modes (maybe coop) and I don't recall the movement being an issue --- and I can't imagine it being something other than movetype fly -- unless it was movetype noclip.

Let's assume it was movetype noclip -- you could use that for now in a worst case scenario.

There might be a cvar to "fix this" -- it feels like extra friction or something.

(Add: what does Xonotic do for watching others play?)

[hemebond]

Xonotic doesn't use engine physics for players. I'll ask Kleskby what they use for spectators.

[Baker7]

See if the default for something with words like "air" "accelerate" or "air" "friction" is whacked.

[hemebond]

Okay, the speed issue was a simple cvar default:

sv_maxspeed is "320" ["320"] maximum speed a player can accelerate to when on ground (can be exceeded by tricks)
sv_maxairspeed is "30" ["30"] maximum speed a player can accelerate to when airborn (note that it is possible to completely stop by moving the opposite direction)

Increasing sv_maxairspeed makes it faster. There's no friction at all so it is very difficult to control. I don't see a cvar for air friction.

[Baker7]

cvars like cl_movement_airaccelerate -- there are about 20-30 of them. My gut instinct is that one of them could have defaulted wrong for 12 years and no one noticed because no one uses "fly" when "noclip" has been superior since Quake was released.

[hemebond]

cvars like cl_movement_airaccelerate

There are a lot of cvars like this that will "fallback" to another, e.g.,:

sv_airaccelerate is "-1" ["-1"] rate at which a player accelerates to sv_maxairspeed while in the air, if less than 0 the sv_accelerate variable is used instead
sv_accelerate is "10" ["10"] rate at which a player accelerates to sv_maxspeed

Friction is the remaining issue so I'm going to have a look through the source.

[hemebond]

I have confirmed with divVerent that this is working as intended. Mods will have to provide their own SV_PlayerPhysics in order to customise the behaviour.

[divVerent]

Tested a bunch:

• it's all about the FL_ONGROUND flag, as not being onground switches to the weaker air movement physics
• DP and FTEQW both always clear the FL_ONGROUND flag when in air, or even right when entering the fly cheat in Quake
• dosquake OTOH retains the FL_ONGROUND flag in fly cheat, even when flying upwards (but jumping does clear the flag, and moving into ground does set it)

This difference probably should be documented/explained/put behind a sv_gameplayfix cvar (unless it already is and I just didn't find it).

As for your mod, I recommend working around it by code or by cvar values; it's a real thing even in original Quake, after all.

[Farma1om]

why the fuck my comment was deleted?

[hemebond]

why the fuck my comment was deleted?

Because it had nothing at all to do with this issue.

[Baker7]

Messing with the onground flag might bust prediction and it might not be immediately noticeable without hosting a game.

I did a lot of work in Zircon trying to get it to Quakeworld better for Let's Coop QW server that has thousands of single player maps to coop -- this included adding fte extensions/chunked downloads/protocol extensions/spectate improvements -- and I discovered the onground flag has an outsized impact -- and if done wrong, gets stuttery movement.

This is my hazy recollection but I remember while working on it, I ended up understanding far more about the onground flag.

/Short version: Changing the flag server-side with a cvar? Not sure that won't have side effects -- DarkPlaces client-side prediction is hardcoded -- and the prediction is what kicks in with bad ping.