"Physics" thoughts ....

[Baker]

This might not be interesting at all but ... I've been trying to boil down "world interactions" into flags instead of "move types".

1. GIVE_INTERACTION: Does an entity directly influence other entity's movements? (No: Static entities like func_illusionary, particles although those are client side)
2. GIVE_ALTERATION: Water and liquids. They don't directly influence another entity, but they change the physics.
3. RECEIVE_INTERACTION: There *are* entities that receive but never give, say client-side sparks or bouncing particles. So they have to know something about the world.
4. RECEIVE_GRAVITY: No = flying or swimming monster or no clip player or static entity like func_illusionary or the "world".
5. RECIEVE_INTERACTION_TYPE: How does something react?

Ghost like func_illusionary or torches: Doesn't contribute to physics, isn't affected by physics.
World: Contributes to physics, isn't affected by physics.
World liquid: Contributes to the nature of physics, but otherwise doesn't interact and isn't affected.
Enforcer Laser: Doesn't contribute to physics, is affected by physics but not gravity.
Health box or a weapon sitting around: Doesn't contribute to physics, but is affected by physics including gravity.
Scrag or a door opening: Contributes to physics, is affected by physics but doesn't receive gravity.
Gibs or backpacks or a thrown grenade: Have specific reactions to interaction with a collision (i.e. they bounce instead of stop).

[Baker]

NetQuake Client sends the following small set of data to the server:

// cl_input.c in CL_SendMove

1) Time stamp as a float (of most recent client time received from server)
2) Angles x 3 (pitch, yaw, roll) as a byte in NetQuake or a short in, say, Fitz 666 (rounded short) or ProQuake (unrounded short)
3) Wish Movement Velocity x 3 (x, y, z) where forward speed will be cl_forwardspeed, etc. (*)
4) Button states a single byte (specifically +attack and +jump states). DarkPlaces, of course, has more button states since a byte can do 8 bits.
5) A single impulse.

(*) Unless player is also pressing +back.

Code: Select all

cl_backspeed        400 
cl_forwardspeed     400 
cl_sidespeed        350 
cl_upspeed          200

The server uses the following to adjust player speed

Code: Select all

sv_accelerate       10  // Quick to obtain wish speed, looks like full speed reached in 1/10th of a second with value of 10 (sv_accelerate/host_frametime) so lower = longer time
sv_friction         4   "You can use this command to lower the amount of friction on the map for the player's movement. If you set this variable to 0 you will turn the map into an ice and the player won't be able to stop"
sv_gravity          800 
sv_maxspeed         320 // Wish velocity received from client is scaled down to this maximum
sv_maxvelocity      2000 // Any velocity on a server is clipped to this
sv_stopspeed        100   "The velocity at which the player will start slowing down to stop his movement."

[ceriux]

what will converting them to flags instead of move types do? what would it affect and how?

[Baker]

The physics in the engine with collisions, how to apply gravity/acceleration/friction, moving everything one at a time, having to nudge stuff due to floating point precision limitations, etc --- is a bit involved.

I've been breaking down the physics in pieces and behaviors to study them, the order, the operations so I can understand it. I've been playing with the parts of the engine I don't fully understand or have ideas I want to play with. That's all.

[Spike]

the existing behaviour is probably too dependant on special cases for backwards compatibility to work.

if you're going with incompatible, I'd use a specific .float gravity instead of a gravity flag.
for interactions, I'd personally go with a bitmask of things that it can impact/be impacted by, but to each their own.

remember that movetype_none and fl_onground are quite important in terms of performance, you'll want to retain some similar behaviour so you can avoid doing anything if it needs nothing done.