Not only is this fixed in the internal codebase, but I deployed it to a limited set of regions in the Havok4 preview for the pre-halloween weekend: "Bug Island" and "Da Boom". I'd appreciate it if someone could make some preliminary testing to see if any of these problems are fixed, thanks.

#4 seems to be signficantly better and #8 seem to be fixed entirely

I also noticed that PSU CS199 is no longer part of the beta grid. Would it be possible to bring that sim back into beta, or any other racetrack sim?

Sandraday: DT scripts (if I'm thinking of the right set of scripts) are not standardized. There's several different versions, whereas there is only one current Dominus Shadow. As for testing on "Teller" I can try if you give me estate privileges. The other reason I test on PSU CS199 is that it is designed to be a no-lag sim. (Minimal content & scripts)

#6, #8, and #9 (rezzing doors) are fixed. That leaves us with:

#1 top speeds are different – might be fixable. I'm willing to try.

#2 stops too fast – this is primarily caused by differences between how H1 and H4 handle collision details. The "special magic for ground vehicles" that I've talked about in office hours and other bugs attempts to reduce this problem but doesn't work perfectly. I'm not very hopeful that I'll be able to fix this but I'll see if I can tweak things.

#3 understeers – I'll be needing more info on this.

#4 bounces on prim seams – There are dupes that are specifically about this bug (such as SVC-1213). This is also related to "special magic for ground vehicles". This was originally tested on large aligned boxes. Looks like I'll have to also play on the PSU racetrack to see if I can improve the magic.

#5 bad bounding box – I think this one is fixed.

#7 climb walls in 3rd gear – what? Why should a car climb walls? Does it actually drive on the wall? Or does it just hover up over the wall?

#5, #8, #9 are indeed fixed.

#6 - wheelstand behaviour is not fixed. When you launch the car in 3rd or higher gear, the car should "lift up" onto its back wheels (doing a wheelstand). It does this in havok1 but not havok4.

My thinking is the most critical bug in this bunch is #6 and #7 - they may actually be the same problem. I suspect that VEHICLE_LINEAR_MOTOR_OFFSET flag is not being respected - or possibly the vertical attractor is too strong.

#7 - the car is indeed designed to drive up walls. In old havok1 you can rez a 10x10x10 cube in front of yourself, drive at it in a Dominus Shadow, and you'll find yourself climbing it.
My thinking was that SL terrain sucks for cars. Things like small curbs and stairs seem to catch most cars. So my thinking was that if I can climb a vertical wall, there should be nothing in SL that can reasonably stop it. This behaviour is enabled for 3rd gear and higher.

#3 - Understeering. In havok1, the car is designed to be pretty nimble, and pretty willing to oversteer/drift/willing to let the tail hang out. In havok4, not so much. The car is much less willing to turn. Something I've just noticed - the behaviour for driving around a prim-based track and a land-based track are significantly different. On a land-based track, the car is signficiantly less responsive. On a prim-based track, the car is slower, but in the same ballpark.

I put a comment for this on another JIRA, but this one is pointed more towards the behavior of ground vehicles and the current bugs of Havok 4, so this would be more applicable than the other.

To see the bug I'm talking about...if you would...change the tires of the Dominus Shadow to either Tubes or Tori and attempt to drive it. Prim surfaces or ground doesn't seem to matter with this particular issue. As far as I can tell, it seems like the bounding box for those prims, and possibly prisms too though I haven't checked, appears to be off.

I have an avatar that can transform into a car, and it includes a hitbox to actually be able to drive the transformed mode. Since there wasn't a great need to save prims since everything on the car is an attachment for the avatar, I used Tori for the tires, and Tubes for the rims. In a Havok 4 sim, it feels like I'm driving a 3 ton whale at the beach. The car has a wobble as if one of the bounding boxes is not being correctly interpreted by the simulator, turning is almost non-existent at times, and the car will 'nose down' into the ground and lose all forward momentum for no apparent reason.

I further tested this by moving a box prim (which would be like the shadow prim on the Dominus) below the tires and driving on this instead of the tires and there was a marked improvement in performance and handling. Also, simply changing the tires to Cylinders, Cubes, or Spheres appears to have the same effect to where the car almost drives the same as it does in a Havok 1 sim.

If there is already a mention of this, then I apologize as I didn't see it, but I feel that this should probably be part of this JIRA instead of a separate one.

The normal friction setting is a per-object parameter and has only one value (there are not separate settings for "static" and "dynamic" friction). The true friction used between two colliding objects is actually the average between their two friction coefficients, so with a setting of zero vehicles don't actually have ZERO friction, but it is as low as it gets.

So, in the next update I expect #'s 6, 7, and 3 to be fixed. I think for #3 maybe the Dominus now rides even easier up walls.

Please test ground vehicles after the next update and enter NEW bugs for specific problem. The edges of the new code are roughest in the transition between zero and normal friction so maybe some of the vehicles out there have trouble stopping, slide too far when the throttle is released, or don't slide far enough.

Tiarnalalon Sismondi – regarding your car that is going nose down. This is caused by different (probably more physically correct) collision behavior in Havok4. I had to add the special zero-friction hack to all vehicles to compensate and keep legacy vehicles working close to how they did in Havok1. If you aren't using the llSetVehicle*() calls in LSL then your vehicle will not pick up the zero-friction stuff, and will basically scrape around like a normal dynamic object. For those who insist on NOT using the LSL vehicle API then a workaround might be to give your objects a "dummy" vehicle that doesn't push very hard, but DOES push a little bit (use long timescales on the vehicle motor) when you want the vehicle to go and DOES NOT push when you want it to stop – that will trigger the changes in friction. One note – the vechicle code expects FORWARD to be in the +X direction unless the VEHICLE_REFERENCE_FRAME is used (this is important since the new vehicle zero-friction magic sometimes adds back some asymmetric friction).

In general you'll get better results with simpler geometry on the collision side of vehicles. For best results I'd recommend using true spheres (not ellipsoids) or boxes for the collision shapes of wheels. Cylinders are about equal to ellipsoids but better than tori – concave shapes should be avoided when possible.

If new bugs pop up please enter new bugs rather than reopening this one and tacking them on.