FTE's built-in player physics changes are somewhat limited due to paranoia about breaking something that results in lots of prediction misses. Again.
There's a few pm_* cvars, and of course the applicable sv_* common to all engines, and a number of cl_* cvars too because gah.
(if I had any sense I'd go through those cvars and give them all pm_* alternative names... but mneh)

If you want full control over the physics then you may find you need to write your own.
https://sourceforge.net/p/fteqw/code/HEAD/tree/trunk/quakec/csqctest/src/common/pmove.qc contains some crappy example pmove code that you can change however you want.
In order to use it, the ssqc should implement an SV_RunClientCommand entrypoint, while the csqc should optionally do something like https://icculus.org/~marco/quakec/csqc/prediction.html but with the 'runstandardplayerphysics' call swapped out in favour of the pmove.qc code.
Obviously modifying this stuff is for people who are experienced with 3d maths, or have the time to get experienced with it.

Alternatively DP's SV_PlayerPhysics function will work, which is a little simpler.
Note that its use also auto-disables prediction, which is one less thing to worry about if you're trying to make a single-player game at least.

The reason I favour FTE's SV_RunClientCommand is because DP's SV_PlayerPhysics is basically impossible to replicate to give clientside prediction (on the plus side, you can migrate over to FTE's method later). If you don't care about that then there are more mods out there that use SV_PlayerPhysics, although they tend to not do much more than make movetype_fly respect pitch angles.