Preventing client velocity/angles input

[mankrip]

Is there any way to make the server physics completely ignore the velocity and/or angles input from the client, without reimplementing SV_PlayerPhysics in QC through the DP_SV_PLAYERPHYSICS extension? I'm using FTE.

If I could just set something like an hypothetical self.phys_cl_input_flags = NO_VELOCITY|NO_ANGLES; filter, while still being able to read the client's intentions through self.movement, that would be perfect.

The only other way I could think of doing this would be to stuffcmd the movement cvars (backspeed, forwardspeed, etc.) to zero, but this would be too unreliable.

By the way, is there a .movement equivalent extension for the angles?

[Spike]

the engine kinda forces it.
There's not much you can do, as the movement must match the values in the client or prediction breaks, thus any change must be client-visible.

you can use .float maxspeed; set that to something small and the player won't be able to move much. They can probably still stop, however.
Regarding angles, you'll just have to reset the angles value to what you feel it should be within PlayerPostThink, which will work for what other people see them as but that won't affect their own viewing angle (unless you fixangles it, which gets very spammy and thus bad).

Angles are sent as an absolute value, so v_angle _is_ the equivelent of .movement... Its just absolute instead of relative. You can track the differences between updates in PlayerPreThink or whereever.


You can also change the prediction code itself (a bit like DP_SV_PLAYERPHYSICS, but more comprehensive thus bypassing the drawbacks). This is the ssqc version:
void() SV_RunClientCommand =
{
input_angles = theanglesthatIwanted;
input_movement = someoverriddenmovement;
runstandardplayerphysics(self);
};
Note that csqc and ssqc both have the same 'runstandardplayerphysics' builtin available, which reads input_* globals, which are set by the engine before SV_RunClientCommand is called.
Thus, you can either implement your own physics, or you can just directly use the engine's player physics with a few input modifiers overriding what the client sent.
But beware, those input modifiers WILL BREAK PREDICTION.
This will not change the angle the player is looking in, nor even the angle of their model. For that, you'll have to explicitly set self.angles to change the angle of their model (save off their v_angle in PlayerPostThink and use it in SV_RunClientCommand perhaps), and self.fixangles=true to get the server to tell the client to force its view angles to match the angle their model/entity is looking in. Which is often a bit weird because v_angle_x is 3 times the angles_x value...

To avoid breaking prediction, you'll need to use csqc instead.
CSQC is the best option for keeping player angles locked as well, as it does not require fixangles spam.
If you're okay with csqc, you can make a really small mod, with just a void() CSQC_Input_Frame; function in it, within which you can override the values of the various input_* globals. This will completely override anything that it sent to the server. Note that there is latency between when some presumably-stat-based flag is set on the server and when the client receives notification of that, so you'll likely want to consider code in both places, to keep server physics correct and to keep them smooth.
You can also explicitly override the view angle in either your draw function, or by calling setproperty(VF_CL_VIEWANGLES, yourforcedangle); both of which will remove the need to spam fixangles.

[ceriux]

i do this is playerprethink to stop velocity so my player doesnt move during a menu.

if(self.menu > 0)//*ceriux*
{

self.velocity_x = 0;
self.velocity_y = 0; // if the menu is up you cant move *ceriux*
self.velocity_z = 0;

}//*ceriux*
you could also set self.angles or something to be static i believe.

[mankrip]

Does setting .maxspeed also break prediction? It's the only thing I'm not sure if I understood.

But thanks a lot for the tips. Right now I'm using .movement, .maxspeed and spamming fixangles, but I'll eventually switch to csqc at the end of the project.

Setting .maxspeed to zero doesn't work (it seems to mimic the .alpha standard of "only use non-standard features on entities that explicitly sets them"), and setting it to very low values wouldn't be accurate enough for me, but setting it to negative values does the trick.

On a side note, the horizontal scale of the numbers in the intermission screen in FTEQW is wrong:

[Spike]

maxspeed is networked, so there might be a small hitch when its changed, but should not persist.
maxspeed = 0 means no extra limit (ie: sv_maxspeed), like alpha. if a negative value works better than a small value, go with it.

will fix the intermission alignment next time I commit.

[ceriux]

why do you want to change max speed? isnt that a global on the server? i still think spamming velocity is the best way to alter movement maxspeed effects all players.

[Spike]

the sv_maxspeed cvar affects all players.
.float maxspeed; is specific to the player. it just stops them from being able to move, in a way that does not result in prediction messing up.

[Seven]

Thank you mankrip, Spike and ceriux.

I am currently working on a new monster implementation in Quake and needed your input regarding player movement.
The new monster has a ranged attack which will temporary 'freeze' the player if he got hit by it.
Your .float ideas in playerprethink work like a charm.

Thanks again,
Seven

[ceriux]

couldnt you have just set the players self.nextthink to like time+x or something then reset it after time +x?

or does the player not have a nextthink?

[gnounc]

think points to a function, its for ai routines (monsters and items).
i dont believe the players movements rely on thinks as they dont rely on ai,
so setting its nextthink to something higher than time wouldnt restrict anything at all.

however, you can see an example of the player using thinks to change level during intermission screen

[Seven]

Yes, I think gnounc is right.
The players physics and stuff are called every frame.

Regarding my post:
The player must be able to look around and shoot, when he is "stuck" to a place by the monsters ranged attack.
It is a spider who spits out a net (to be specific) which holds the player at its place for a short time.
So ceriux´s idea with self.velocity_x/y/z = 0 in playerprethink is ideal for that.
I set/control the "frozen_time" via a specific .float function (analog to: self.pain_finished for example).

If the player would not be able to do anything at all, it would be too hard...
This way it is fun to play against this new monster, which moves fast and does other tricks as well.

Thank you again.

[r00k]

What is your purpose for it?, Can you just keep updating the angle u want to force in playerprethink and postthink
when u try moving the mouse the view just blurs a little as it snaps back.

[Seven]

Hello r00k,

The purpose I described in the above posts:
A new monster (= spider-like creature) in Quake has a ranged attack (= spits out a net).
When the players gets hit by this net, he will be stucked to the ground (unable to move).
But he still can look around and shoot (otherwise it would be too hard).
This way he is able to still shoot the monsters around him, but he cannot move (only for a short time).

If I dont allow him to look around, he will not be able to "defend" himself, because he cannot aim.
That would be too hard I guess.
The spider would continue to spit nets and goes over to melee attack mode --> player is dead
The spider can also do the demon jump (very far jump) towards the player.
That is his 2nd attack mode.
I am not quite sure how to determin which attack mode is the best for each situation.
Maybe depending on the distance I will randomly choose between "net" and "jump".
Meele attack is clear though (like the demon has). Spider has 3 different meele attack types.

Here are some animation frame screenshots:
walk:

spit out net:

behind:

emerge from the underground:

bite:


The model is from Psionic. I would never be able to create such a beauty.

[ceriux]

awesome model did you make it?

[frag.machine]