Vehicles won't move when sitting or boarding

[Trouble Ahead]

A classical “ the chicken or the egg “ question, is physics engine malfunctioning or the viewer ?

Anyway, this seems not be possible to resolve, better tell people to move ships a bit than let them do clean installs with an older version of the viewer. I guess that wont make them happy.

— case closed—

Cheers

[Ilan Tochner]

Have you tried changing your world's physics engine (via the Advanced tab of that world's Manage World dialog)?

Alternatively, you can test the vehicles in a different world that uses a different physics engine. If that solves the problem then you won't need to tell people to use an old viewer or move anything to reset the desired behavior.

[Trouble Ahead]

The ships scripts we are using ( SPD ) are not working well on bulletsim. Does trying ODE will bring effords?

[Ilan Tochner]

ODE and UbODE are mostly the same but the differences between them may solve the issue you're encountering. It's worth a try.

[Trouble Ahead]

Tested ODE: ships don't sail.

I saw btw they are not offering the latest FS for opensim on the website, due to updating activities. I guess ther e will be an update of FS OS soon.

[Balpien Hammerer]

I noticed this problem last year during my July airshow. It rarely happens with avatar rezzed vehicles (I sat/stood 100x with no problems), but it happens almost every time with script-rezzed vehicles. The engine script in the vehicle is receiving control events since the sound effects are triggered as I press keys in my vehicle. I added debug code to my FX script in the jet to display the physics status (llGetStatus(STATUS_PHYSICS) every few seconds. It shows that the vehicle is supposedly physical when the script sets physics to true. And yet, the vehicle will not move. I believe this issue is not a script problem.

BTW, I tried with 6.5.3, 6.6.17, and 7.1.3alpha Firestorm, same results. This is looking more like some race condition in the region simulator with the physics engine. I did not expect any difference since the viewer does not do anything special with physics status. Movement is strictly based on the move/accelerate short message parameters sent by the simulator.

In my next test I raised the rezzer in the air. Then when sitting on the rezzed vehicle, the moment the engine script made the vehicle physical, it then fell to the ground, and no more problems. This suggests that (at least in ubODE (not yet tried bullet) that the physical object is physics asleep. Most physics engines will sleep an object (stop physics force resolving) when it detects the frame to frame motion drops below a certain distance. It is done to stop constant object squirming. My guess is that some time ago that threshold was raised a tad. I'll try to come up with a better mitigation for now. And, I'll go through the code to see why the object is not awakened whenever the vehicle motors are activated. Also, will write up a mantis bug report.
 
Addendum: for vehicles starting out on land, a rezzed object/vehicle will almost always not move when made physical if any part of physics mesh interpenetrates the road base aka a prim. Just raising the vehicle slightly above road base seems to work around this bug. I tested watercraft and the weirdest thing I saw was no movement upon physical when the vehicle's position (or possibly its physics shape) is below the water level. Making the rezzer rez the vehicle above water level makes it work every time.

What might be going on is that upon being made physical, if the object has no initial movement (or perhaps below the make-it-sleep range), the object stays asleep. This is quite peculiar because any of the force functions including activating vehicle motors should awaken a sleeping physical object immediately. I have to spend more time characterizing this because if I write these observations in a mantis, they'll get rejected. Maybe Oren could have a look too?