"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]

[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.