I attached a little demo of a completely 'physical' (no raycast wheels) reverse trike vehicle. It shows a way to set up wheels and constraints to act like a vehicle.
You might have been running into some of the constraint basis setup issues in that first video. Here's a couple of common cases:
-If you create constraints connecting two entities and then later try to modify the relative orientations/positions of the involved entities without notifying the constraints, they will try to return to their original configuration.
-Many constraint constructors make simple guesses to help set themselves up. In many cases the guesses are correct, but when it doesn't quite do what you want, you'll need to configure the the constraint. In the attached ReverseTrike, this issue came up with the steering RevoluteMotor. It guessed the wrong axis to measure for steering angle, so I had to complete the configuration by setting the basis directly.
Stability for driving typically comes from a combination of sufficiently low center of mass (stopping constant rollovers), wheel friction (allowing steering and preventing sliding), and well-tuned drive forces (going into a wheelie and flipping yourself every time you go forward isn't very drivable). In the attached trike, I spread the front wheelbase out, lowered the body, and further lowered the body's center of mass. The wheels are also somewhat heavy to help with this and the mass ratio problem I'll explain in a minute. I increased the softness on the drive motors to prevent extreme acceleration. There's still some instability due to being a suspensionless, ultra-fast turning trike as opposed to a 4-wheel car and not spending much time on it, but that could be addressed.
When dealing with complex contraptions, the masses of individual pieces needs to be carefully managed. If a 'realistic' mass of 1000 was used for a car body and then masses of 1-20 were used for physical wheels, chances are the entire thing would jitter and behave awkwardly. The solver doesn't like really heavy stuff relying on/sitting on really light stuff. You could increase the iteration count to help the issue some, but it will always be a less robust simulation than if masses are kept in line. With unrealistically heavy wheels, the solver has a much easier time and usually the simulation ends up looking better since the car rolls less.
For the front wheels, I also used swivel hinges instead of revolute joints. Technically, one revolute joint could connect to a shaft which then has a second revolute joint with the wheel, so that it can both steer and roll. This would require an intermediate entity and more constraints and put a bigger load on the solver (potentially also causing mass ratio issues as outlined above). The swivel hinge approach cuts out the intermediate shaft and allows two degrees of freedom directly which can then be motorized independently.
how should I go about having the helicopter try to stay upright when it is made up of many components
If it's actually a bunch of separate entities bound together with constraints, this might be a little tricky. If it were a single CompoundBody, I'd just say use something like a SingleEntityAngularMotor in servo mode. You could target upright or slightly off upright orientations to steer the helicopter. The SingleEntityAngularMotor controls all three angular degrees of freedom, so you can use it to make it yaw around as well by changing the target orientation. You could use a similar approach for the 'bunch of entities bound by constraints' by attaching the SingleEntityAngularMotor to one of the heavier centralized objects in the structure. You might have to make it stronger since it has to indirectly rotate the rest of the helicopter.
There's also the more 'realistic' approach. Helicopters are pretty tricky to get flying in a stable manner in real life. Their rotor can pitch and roll a little and there are other flight controls in place to make it go where it needs to go. You could try emulating these systems through multiple physical interactions, though the development time required for that is more suited to a helicopter simulation game
It might be a little easier to simulate a realistic multi-rotor helicopter. With the right configuration, the torques would cancel themselves out and you'd be left with balancing a set of thrusters basically. This wouldn't really be directly controllable by a human, but it could have an assist which throttles up and down individual thrusters to keep things level or moving in the direction the player wants.
Though, when it comes to really complicated things, particularly on the Xbox, I'm a fan of just faking it.
Also how would I go about breaking apart compound bodys (can this be done?) I know that they can have objects removed from them so that I can handle (and creating the new object should be easy too) its more the issue of where the impact takes place and what should break… how on earth could I figure this out?
You could attach collision events (initial collision detected or contact created, for example) to the compound body or its subbodies. Each time the event fires, see if the collision pair's contact list has any contacts with high forces. Each contact's penetrationConstraint's normalForce would tell you how hard the impact is. If the normal force (perhaps summed normal force over all present contacts) exceeds some breaking limit, you could remove that entity from the compound body (or shatter the compound body completely).
Breaking only gets really tricky when you want to break procedurally (i.e. splitting a single non-compound entity into 2 or more entities on the fly) or if you want to do more analysis to see what chunk of an object would be removed given some physical impact. Usually, as far as game physics go, people aren't too good at distinguishing proper breaking physics from procedural tricks, but they are unfortunately very good at recognizing 'pre-break' patterns if they show up more than once.
If breaking only none, one, or all entities in a compound body is a little too repetitive looking, you could try taking advantage of the compound body hierarchy (you can nest a CompoundBody in another CompoundBody). This results in a CompoundBody 'tree' representing your object. When an impact hits a leaf entity, you examine the contacts. If it's a weak impact, you could do nothing or maybe knock out the leaf entity. If it's a strong impact, you could knock out the parent compound body, so instead of losing the one entity, you would lose two (or more). If it's really strong, you could go even further up the hierarchy, perhaps even knocking out half of the tree and splitting the object in two. You could still keep the removed objects in their respective compound body so that when you re-add them to the space, you have two complete rigid parts of the original whole. If for a certain piece that would look weird (such as if the pieces aren't touching), you could just split them into smaller parts or individual entities when adding it back to the space.
As long as the CompoundBody tree is organized so that spatially near pieces are close in the tree representation, that approach could make the player feel like it's a 'real' breaking system.
Our logic switch system is almost finished (mirrors little big planets but with some more features) so you can now script events and trigger things (particles, physics, lighting etc…) all using them (we actually realized that you could build a calculator if you had the time (and assuming that our game ran fast enough)
Anyway this is just an update of how we are going on our development and those questions above.
Thanks for all your help.
ps. We have added the path system into our game (about 70% done) and it works very very well amazing work norbo, we have added a visual wrapper around it so that paths and their options can be edited visually.
Great! The Blast videos are looking really nice. Things are coming along
Pps. What is the most stable way to create a half box (diagonally split to be a trangle) and a pyramid shape for use in a compound body?
A compound body built from triangle objects? Or just a convex hull? Or something else?
I would recommend a ConvexHull.