Talk:Physics Entity Overview

Just updated a couple of these descriptions for these reasons: phys_constraintsystem is not about performance, it's about stability of the interactions between constraints. phys_convert is only useful for converting an entity with some other behavior. For totally static stuff that you want to be physical later, you should use prop_physics or func_physbox with motion disabled, then trigger an EnableMotion input to make them physical. Also the previous description referred to prop_static which is not a real entity (it's equivalent to world geometry) and cannot be acted upon by any entity I/O so phys_convert cannot target one of those.

I would be a lot happier using motion disable if it also disabled the grav. gun playing the primary fire sequence when you try to punch the prop. Is that going to be fixed? Thanks. --TomEdwards 12:09, 28 Jul 2005 (PDT)

There aren't any plans to change this. It's easy enough to do in a mod though - you just have to make sure to check for the "motion enable on physcannon" behavior --Jay Stelly 15:47, 28 Jul 2005 (PDT)

---

I'm probably being really stupid here, but is there any way of connecting two physics props together with a variable-length rope? Something like a crane would be great, connecting a func_tracktrain to a prop_physics with the ability to change length depending on input. While still acting like a realistic pendulum. Any ideas? --Cargo Cult 12:22, 22 Sep 2005 (PDT)

Would faking it be acceptable? If so, you could hang a func_movelinear from a phys_ballsocket. It's rigid-body motion, so the pendulum equations wouldn't apply, but the movement of an attached rope might look reasonable to someone who isn't studying it in detail. —Maven ^(talk) 12:40, 22 Sep 2005 (PDT)

Until I read this question, I never knew what precisely the phys_pulleyconstraint was for. =D --Demented 13:21, 22 Sep 2005 (PDT)