Strange behaviour when exchanging/updating vehicle scripts

[Chorazin Allen]

I first saw this when I started using an updating system for the scripts in my vehicle builds. However, this isn't specific to my scripts, it seems to be a generic vehicle behaviour. After replacing the script which manages the Vehicle settings, the vehicle seems to acquire a huge amount of mass causing the object to sink down when it next goes physical. The amount of pull is more than the vehicle engine can counter.

Here's a way to reproduce the behaviour without using the scripts I've been writing..

1) Take a simple boat such as BBX's Aqua which has modify permission

2) Go into edit linked on the driver's sitting position and take a copy of the Yacht Engine 1.0 script

3) Sit on that prim and observe that the boat drives normally (page up/down to change gears, up arrow to increase speed, down arrow to stop)

4) Stand up, go into edit linked, delete the Yacht Engine script

5) Put back the Yacht Engine script from the copy you took to inventory. Observe the chat output indicating that the engine script has initialised normally.

6) Sit on the driving position again. The boat will sink to the seabed and it either won't move at all or will move in directions other than the motor should be sending it. Larger vehicles will hardly move. Smaller vehicles like the Aqua can end up shooting off in unexpected directions contrary to the motor direction

My question is - what's causing this? The boat is only set physical whilst it is being driven, so it's not physical between steps 4 and 5

Second question - what can a script do to fix this effect?

Thanks in advance for answers...

--Chorazin

 

[Chorazin Allen]

A couple more points I forgot to mention.

If you clone the sinking boat with Shift-Drag, the copied version will behave OK.

Likewise, if you take it back to inventory and rez it again, it will then also be OK.

[Rolig Loon]

And if you simply reset the script. what happens then?

[Chorazin Allen]

If you reset the script without going through the remove and re-insert steps, it'll be fine. If you reset the script that was re-inserted from inventory, it stays broken.

[Rolig Loon]

It sounds like the script is written to make the vehicle physical on rez, but not in the state_entry event.

[Chorazin Allen]

You might be onto something here... when the boat is rezzed from inventory, only the rez event will fire and state_entry won't happen unless the rez entry decides to reset the script. When the script is added to the object from inventory, it goes through state_entry but not its rez handler - so there is the difference in behaviour I've been looking for

That said, it's not the case that the script in the example with the Aqua makes it physical on rez - that won't happen until someone sits on it to drive. The boat will rock, but that's non-physical motion by a different script (and the misbehaviour is exactly the same with or without that rocking script). Also, recall that the problem happens when the script is added to a rezzed object from inventory - in that scenario the rez handler isn't called.

I'll go take a look at my own scripts and see if there's anything adverse around entry getting called without rez getting called, ie the same test scenario.

[Chorazin Allen]

...just reminded myself what my own scripts do. They should be immune to this, unfortunately. My state_entry does various cold-start actions (but nothing to do with physics or vehicles) and then completes by executing the same routine that forms the on_rez entry.

[Chorazin Allen]

After more experimenting, the theory about state_entry and rez doesn't work...

The problem lies in the two things that can repair a broken object - copying it with shift-drag and taking it to inventory and re-rezzing it. In the first case, only state_entry will fire. In the second case, only rez will fire. Conclusion, the misbehaviour of the scripts isn't to do with which of state_entry or rez get called in either the Aqua or my own scripts.

[Chorazin Allen]

One more thing... I'm not 100% certain about this yet, but the problem seems to be specific to builds where the "motor" prim is not the root. (Yes, I know it would make more sense to have it in the root, but someone else built the objects)

[Rolig Loon]

Bu the vehicle script doesn't need to be in a separate prim. When I create a vehicle, I always drop the script in the root.  The child prims are only for the "cosmetic" extras (like wheels and seats ...).  If your creator made the vehicle with its forward axis pointing some wonky direction instead of +X, just use llSetVehicleRotationParam(VEHICLE_REFERENCE_FRAME) to reorient it.

[Chorazin Allen]

I know, but I'm stuck with it because of the way it was originally built. A child prim has the driver's seat with engine script, sit animator, sounds, settings notecard etc. At the moment, I have one new script that must go in the root and two that go wherever the old engine script was (whether that's the root or not).

It does look like child prims are the problem here. It seems like when the engine script is removed from a child prim some internal state on the object doesn't get cleaned up. I just tried flipping physics on and setting vehicle_type_none then turning physics off again in my pre-update code just before my script removes itself for updating however that hasn't solved it.

At the moment, it's looking like I need to insist on all my engine scripts going in the root and avsitter or similar gets used for the driver's seat.. either that or rejig my scripts so that the engine stuff happens in the script that always goes in the root instead of the one that goes in the driver's seat. The sounds, config notecard etc, will just have to get moved to the root unless I keep a small script in the driver's seat just to deal with the assets that are kept there

[Rolig Loon]

13 minutes ago, Chorazin Allen said:

At the moment, it's looking like I need to insist on all my engine scripts going in the root and avsitter or similar gets used for the driver's seat.. either that or rejig my scripts so that the engine stuff happens in the script that always goes in the root instead of the one that goes in the driver's seat. The sounds, config notecard etc, will just have to get moved to the root unless I keep a small script in the driver's seat just to deal with the assets that are kept there

That does seems like the best solution. You don't need anything as fancy as Avsitter for a car seat, so you can probably write a basic adjustable seat script in 3/4 hour or so. Move the engine script and the configuration script to the root so that it's easy to communicate with all of the appropriate child prims.  The rest of the script operations can either be put in small local scripts (for things like turning wheels) or built in the main vehicle script and controlled by SLPPF.

Edited November 28, 2017 by Rolig Loon

[Chorazin Allen]

In general, my aim with this rescripting is to get rid of all the many individual scripts for doors, idle rocking, particle effects, lights/light switches, moving items like flags and radars etc etc. While three scripts might sound excessive for a vehicle, they're replacing 10-20 scattered all over the linkset, if not more. Unfortunately reading a notecard located in a child prim is one of the things that's still not possible from a different linkset prim.

Anyway, yes... it looks like the direction to take is clear now - thanks for helping to bounce ideas around!

[Rachel1206]

Just remember, any given scripting depends on the given task ahead - stipulating 3 scripts are excessive, does not make sense unless we are talking about a very simple boat script. To distribute sub-scripts into logical entries often make sense - and a single badly written script can cause more impact, havoc than an elegant solution with say 128 scripts!

 

 

Edited November 29, 2017 by Rachel1206

[Ruthven Ravenhurst]

18 hours ago, Chorazin Allen said:

Unfortunately reading a notecard located in a child prim is one of the things that's still not possible from a different linkset prim.

Not entirely true. I have an object that a has a sensor script in one of the child prims. it reads some settings and names from a notecard. to make editing the notecard easier, i have it in the root prim, and a script in the root prim communicates the notecard's uuid to the script in the child. the same could be done in reverse. if you have the uuid of the notecard, the notecard doesn't have to be in the linkset at all. it can even just reside in your inventory

Edited November 29, 2017 by Ruthven Willenov

[Chorazin Allen]

 

9 minutes ago, Ruthven Willenov said:

Not entirely true. I have an object that a has a sensor script in one of the child prims. it reads some settings and names from a notecard. to make editing the notecard easier, i have it in the root prim, and a script in the root prim communicates the notecard's uuid to the script in the child. the same could be done in reverse. if you have the uuid of the notecard, the notecard doesn't have to be in the linkset at all. it can even just reside in your inventory

Oooh, I'd missed that GetNotecardLine can be quoted a uuid too. Now that's interesting...

[Love Zhaoying]

On ‎11‎/‎29‎/‎2017 at 11:02 AM, Ruthven Willenov said:

it can even just reside in your inventory

..really..?!?!? This sheems shushpishush!

[Ruthven Ravenhurst]

6 minutes ago, Love Zhaoying said:

..really..?!?!? This sheems shushpishush!

Yes, but it gets a new UUID each time it's edited and saved. So you'd have to update the UUID when you edit it. I used the new UUID method in the script to detect which/if notecard was edited in the object's inventory

[Love Zhaoying]

On 11/30/2017 at 12:23 PM, Ruthven Willenov said:

Yes, but it gets a new UUID each time it's edited and saved. So you'd have to update the UUID when you edit it. I used the new UUID method in the script to detect which/if notecard was edited in the object's inventory

If NOT in the object's inventory, I assume it would have to be "full perm" in order to work even if you have the UUID.

[animats]

I've seen that too, working on my own script for my own simple test vehicle in a mostly empty sandbox. I had to create a new script, copy the text from the old one, paste it into the new one, delete the old one, and rename the new one. Then the script worked again. "Reset scripts" didn't help.

I'm doing a lot of region crossings in tests, and that may affect this.