For the first released version we will concentrate on Hovercraft support, to get Nexuiz Onslaught mode rolling (to hovercraft I also count helicopters, cause they are similar in implementation). Second release will at minimum support cars and tanks, including rolling objects unless it isn't already implemented. Further releases should support planes, boats and other experimental vehicles. All other features are optional to implement at any point

priority | topic | description
* = done
f = failed/ignored (provide reason)
(name) = person working on (very optional)
__________________________________________

HIGH   | Bug		| Fix Matrix2Euler, it is twitchy
HIGH   | Bug		| Add singularity exceptions to Matrix2Euler
HIGH   | Bug		| Fix CountRotations, it rotates in opposite direction in unknown yet consistent cases
HIGH   | Bug		| Make .origin be the current position, not the old one. This is to make sure pushing the particles has the desired effect. This will have the downside of all forces being applied to the particles must be applied negated to the old position, but it's worth it

MEDIUM | Collision	| When an object (can be a client, or anything) with non-point size bounding box collides with a physics object, clamp the point of impact towards the physics object (exactly what part of the physics object is up for discussion. Two good ideas are the middle of the object, as well as the middle of the two closest particles. I prefer the latter)
MEDIUM | Collision	| When a force is applied on a BSP hitmodel of a physics object (a particle hits it, or perhaps a weapon), the force should be divided between the objects particles based on the distance from the point of impact to the particles, with the closest getting most of the source, while the farther away ones getting less. In the case of the opposite, when the BSP hitmodel of a physics object registers a touch (IE it was moving and hit something), put together the velocities of all the object's particles, dividing it based on distance to the impact point, and apply the force inverted to the particles of the BSP models physics object, divided between the particles from closest to farthest, and multiplied by the bounce factor of the particles. The BSP model already pushed the particle of the opposing object.
			  In most cases, the BSP model won't even hit anything in an opposing physics object, cause the particles trace before the BSP model, so they already hit it, bounced off and applied force, and the BSP model came after to the new position, bounced off ready and all. If it does however, the particle will get extra motion from the push (awesome side-effect of verlet) and the BSP model needs to get some kind of reaction from this.
			  This might require flagging for when a hit was made on a per-frame basis, so that double hits can't happen in cases like entity hitting the BSP model registering a touch on the BSP model, resulting in the BSP model transferring force that has already happened except inverted (I've seen this, it looks like the objects are stuck on eachother), or if a particle of a physics object also hits after the BSP hitmodel of the object has made a touch, resulting in double force on the opposing object. This sounds like heavy stuff, so if it feels unclear, either discuss it before starting to work on it, or let me (Urre) do it
LOW    | Collision	| Stick collision. A complex feature, which might not work consistently, very experimental. Up for discussion. I have an idea for how to do it, which should work, but could potentially be (too) slow

LOW    | Constraints	| Non-stiff springs on sticks, with values for max/min extended positions
LOW    | Constraints	| Scaling force for pulling/pushing particles on sticks, with min values for when to activate force (requires above feature), and optional spring direction/plane towards targeted particle, the particle gets pushed/pulled in this direction, independent from the stick direction
LOW    | Constraints	| Limiting particle positions to planes
LOW    | Constraints	| Angle constraints between sticks

MEDIUM | CSQC		| Figure out CSQC, important for better input interpretation on vehicles, and camera work

MEDIUM | Editor		| Make editor much easier to use, mouse driven and stuff, and with password checking so that one can't go in and mess up the server's objects (Urre would specificly like to work on this himself)

HIGH   | Engine		| An unblockable type of MOVETYPE_PUSH, one that goes through the object it tries to push but fails, instead of stopping movement. This is to prevent hitmodels and particles to come out of sync. It would generally be an uncommon thing to happen, but just to be safe rather than sorry

MEDIUM | File format	| A scalable (and generally better) physics object file format, for when new features are added. Perhaps by versioning

HIGH   | Optimization	| Disable constraints on all particles but the first three after more than 5 frames of flight. Position the rest of the particles based on the first three every frame, and wake up constraints on contact/forces (Urre)
HIGH   | Optimization	| Disable all movement when three or more particles are resting on floor, wake the object up on contact/forces (Urre)
HIGH   | Optimization	| Just general optimization :P

LOW    | Physics/Editor	| Configurable and saved sticks, important for many features. This includes manual stick creation, with the ability to completely skip sticks between certain particles if one so wishes

HIGH   | Physics	| Thrusters on particles, with their own vector for direction, two types, one that sends a trace in its thruster direction and only pushes if it hits something (hovercraft and more), and another without the required trace (airplanes?)
HIGH   | Physics	| Euler-to-Verlet conversion for velocity, and Verlet-to-Euler, for easier pluginability and more
HIGH   | Physics	| Non-sliding friction. That is, so that things can stand still on a slope. IIRC very hard to do, but none the less important
MEDIUM | Physics	| Particle rotation. Important for particles to get rotation without a third particle to check against. Also good for faking various cool stuff, like round objects rolling on the ground, and must also work in cases of 2 particles (object rotates based on the fastest moving particle, limited to the plane between them), for tube shaped objects (like a grenade rolling on the floor, made up of just 2 particles). Midair the object will continue to rotate freely based on previous rotation. In other words this means the ability to flag which angles to limit to other particles, and which can rotate freely
LOW    | Physics	| "Airplane vector" on particles, which makes pitch apply upward/downward force on the particle (based on orientation) depending on how fast it is moving towards the "airplane vector" direction
LOW    | Physics	| Velocity rotation. Rotates the velocity of the particle to the direction specified, with planes for when to become active. Also with flag for onground, and choice between accelerating rotation (rotates faster the closer it is to the direction) or rotation speed (percentual, 100% being instant rotation, effectively limiting velocity to this direction). Required for tyres and more, multiple directions with individual settings supported
LOW    | Physics	| Directional friction. Depending on how close towards this direction it is traveling, the more it will apply this particular friction. If it goes outside its plane, it won't have any effect at all, unless it has a doublesided flag, which makes it mirror the effect on the negative side. Multiple are supported, important for tyres

HIGH   | System		| Figure out a good system for making physics objects interactive in a simple to use way for qc coders. Required for vehicles (ability to enter/exit vehicles, input interpretation) and more
HIGH   | System		| Make physics run from StartFrame instead of the object's .think function, since it's more accurate to the server timing
MEDIUM | System		| Make orientation configurable, let the user choose which particles to get orientation from, and add orientation handling for non-stiff sticks (get orientation from extended position each frame)
MEDIUM | System		| Work on pluginability
MEDIUM | System		| Make physics system work on dynamic framerates
LOW    | System         | Make vehicles require very little qc alterations, if any, all is handled by the editor and file system, so it's easy to implement new vehicles without knowing how to code
