Seating Bug?

I have a vehicle that has a 2nd seat... worked great for the last two weeks - then today if anyone sits in it they end up in every other position but the 2nd seat. I have re-compiled the script, replaced it, even had a few people look at the script and they see nothing wrong with it.

Is anyone else having this problem now?
Is it a bug?

Thanks,
Sinatra

I'm seeing this bug too. A passenger seating script that worked perfect not too long ago is now officially broken in all of my vehicles.

-Bone

My experience with this is that the prims seem to be keeping memory..

Example #1 As you said, second seating no longer works. I had a vehicle that crashed at a sim line and when i jumped back into to game and took the vehicle back the second never worked again. I have since removed the script and added a new one and it still no longer works.

Example #2 In this same vehicle I have added a rotation script to the wrong prim.. I noticed this and removed the script. but the texture keeps rotating anyway.

Example #3 I created a new vehicle and had the sit text set as "Cruise" I decided to try another script that had a different sit text and it was still saying "Cruise" After this I removed all scripts and the vehicle still said "Cruise".

During all the initial seating errors I tried new scripts.. changing the link order.. completely unlinked and relinked the vehicles.. I even checked every prim to make sure they were script free. It still doesnt work. It would be bad If i had to redo the seats every time this happened but would be even worse if the vehicle had to be remade.

I cant sell stuff like that!..

My guess here would be that its not the actual vehicles that are effected by this, as you know our inventory is not stored locally but in some server. This server is more than likely NOT registering changes of scripts within prims. These problems started happening when we had the problem with the inventory server if i recall correctly.

Any Lindens able to clear this up? Or in the least let us know the exact problem so we can plan ahead to avoid it effecting us? Knowledge IS power.

PS The above is a GUESS.. dont quote me!

I found this today also. llAvatarOnSitTarget() returns some bogus UUID (no llKey2Name() string) even when there is nobody sitting. Tried resetting scripts, unlink, relink, everything I could think of. It is broke.

I'm not 100% sure, but I think I've had odd results with sit target in the past, if the rotation quadernion was not normalized.

BTW, to normaize it, all four numbers, squared, should add up to 1, ie <0,0,-llSqrt(0.5),llSqrt(0.5)>.

quadernions are weird...

anyone having any luck with 2nd seating postions?

I would expect that to be the case. If the quaternion isn't normalized, it isn't actually a rotation.

I recommend avoiding specifying quaternions directly, and using llEuler2Rot instead.

Slightly off topic, but noticed this tonight (more testing needed to actually see what's up.. just my quick observation)

If the rotation set in the llSitTarget() call is "out of bounds" (a float's value > 1) your av will be shot way across the map, and or up/down etc.

This occurred twice to me tonight (blurry eyed scripting is fun). First time I got shot up to about 100 meters. I could fall back down but hit an invisible plane (assuming it was the "ground", only that it was up around 50m or so).

Next time I got shot underground. Could run around some but that got boring fast.

Only fix was to log out (teleport home, teleporting to distant teleflopper hubs didn't fix my av's height).

Apparently your av's postion (z) gets whacked all to hell when this bug happens. llSitTarget() needs to first check the supplied rotation to insure it's a valid rot, and then if it is apply it to the function, else abort. The compiler could roughly check this, but it would also need to be checked during run time for dynamically supplied values.

Bos

I wouldn't say this is the compiler's (or the run-time system's) responsibility. llSitTarget expects a rotation, not an arbitrary quaternion. It's the programmer's responsibility to supply a valid rotation, either by normalizing it manually or using llEuler2Rot.

If llEuler2Rot returned an invalid rotation, then I would consider that a real bug.

"llSitTarget expects a rotation, not an arbitrary quaternion. It's the programmer's responsibility to supply a valid rotation, either by normalizing it manually or using llEuler2Rot"

-------------------------------------------------------------------


Alot of this is over my head - my 2nd seat worked for weeks and now it doesn't.

Is this a bug Linden's?

OK.. not rocket science. I cant play beause I'm 2 states away. Sinatra, Try this. unlink the seat. once unlinked make a crtl-d copy of it and relink the new one. If that fails try making a new seat. I have been wanting to try this but Im in NY. I live in PA.. pc=FAR Let me know when/if you tried.

Seeya!