Script behaviour changes linked to vehicles and region crossing

[arabellajones]

In recent days, after building a mesh locomotive using the rather old VRC scripts, I have noticed some new errors on crossing from region to region. They seem to be a little more likely in region-corner situations, but don't seem to have any correlation with use of the Cloud.

The error message refers to llStopAnimation and says the Agent is not found. The vehicle movement stops, and there is no apparent change to the avatar using the vehicle.

I have seen somewhere a mention of the current  faster region-to-region transfer process leading to some events happening in an unpredictable order. This seems to fit. If the avatar is in an unknown state when the script does a check, I can see how what I see could happen.

Standing an re-sitting does fix things, but sometimes, while the "Stand" button and "Stand-Up" right-click option are available, they're not working for a few seconds.

The way that LSL works, I am not sure I could add a delay or other check to the script which would cover this situation.

I have seen similar events with other vehicles, using established scripts I don't have the permissions to read.

[Wulfie Reanimator]

Without doing any kind of tests myself, I would guess that a simple llGetAgentSize or similar avatar-specific function could be used to check whether the avatar is known to the region.

That might not work for many reasons, but if you just want a delay, llSleep will work. But there's no knowing what amount of delay is enough for all cases, and adding artificial lag back into your script kind of defeats the purpose of fast region crossings.

It's also possible that these issues could be avoided by writing a new script from scratch, but that's not always desirable either.

[Mollymews]

have a look here at what we have to consider with vehicle crossings animation and camera

the main thing is to poll for the agent when the vehicle crosses, applying animation and camera only when the agent is actually present on the region

[animats]

20 hours ago, Mollymews said:

the main thing is to poll for the agent when the vehicle crosses, applying animation and camera only when the agent is actually present on the region

Yes. You have to do all the work to check for all the avatars arriving, and then reset controls and animations. Avatars and vehicles cross separately and are re-connected after arrival. Those animation error messages can be completely eliminated.

[arabellajones]

We do really need the VRC scripts updating. The most recent I know of are 2015. I did make a wheel-animation script, using a timer loop, and there is a VRC-derived script being sold by a merchant, but the problem is new enough that I doubt there are fixes anywhere. I am not sure there are current reliable scripts for any vehicle yet

The different Bellisseria land permissions  also affect what's possible.

I am trying. I am wondering if the original script creators are still in SL. And a lot of vehicles are using badly-designed models  of dubious origin. I was able to modify one to get rid of a lot of detail. How many people want to drive around with a hidden high-detail engine? What I was using worked well, but it uses the everyday scripting that now seems to be broken.

 

[Rolig Loon]

I've had reason recently to look at some of those old RR scripts.  They were written well before we had mesh objects and before scripters had functions like SLPPF that let us address multiple links from a single script.  Keyframed motion, llRegionSay, llTextBox, and a host of other recent additions were not available then either. As a result, trains were script heavy and inefficient by today's standards.  To do the job right, someone needs to start over completely, designing a new generic script from the ground up instead of making piecemeal tweaks to the old ones.  In the best of all imaginable worlds, we would have grid-wide KVP available to us.  That would really open up some great options for a new generation of trains. I don't frankly have the time or incentive to do it myself, but some enterprising scripter could establish a new standard by taking on the challenge.

[animats]

I checked my logging, and on some region crossings there's a meaningless "CHANGED_LINK" event.

[animats]

12 hours ago, Rolig Loon said:

To do the job right, someone needs to start over completely, designing a new generic script from the ground up instead of making piecemeal tweaks to the old ones.

Take a look at the trains in Jane's Viking sim, Folkvang. Those are all keyframe animated. So are the trams in New Babbage, I think.

Keyframe animation will work well in overloaded sims, which is why I use it for my NPCs. Those appear to move like avatars, but they're really keyframe animation precalculated dynamically a few seconds ahead of motion. That's a good way to run trains, which follow predictable paths along tracks. Trying to do it by constant feedback is in theory better, but with script overload the new normal, precomputation is the way to go.

[arabellajones]

I don´t have the talents to sort out the scripting problems for vehicles. I hope some recent strips are getting updated, but some are very old, and may not be.

It seems very obvious to me that, however different the new generation is, it must be compatible with existing systems. The most obvious instance is the SLRR system, the Guide rails in general, and the modified system being built on Bellisseria

There has a lot been done since some of these systems were originally designed. There is Mesh, and a plethora of new scripting. In this thread I started by reporting on a new error. I could have made a wild guess as to what the problem is.

While I was throwing ideas around I noticed a few things about trains.

1:     The current guide code has to be in the root-prim of a multi-prim linkset. I could build a model as one mesh, but it wouldn´t work. It looks like it needs to be two prims.

2:     A good mesh model can still be only one prim, which should make some things enormously simpler. Even with a high LI, an item can still be only one logical prim for animation. 

3:     A mesh object can easily have half the LI of an equivalent old prim modem, and a lot of rail vehicles are prim models

[Rolig Loon]

FWIW, the rail system in Bellisseria follows the same standards for scale and guide prim placement as SLRR rail beds elsewhere on the grid, so SLRR-compatible trains should all run there with no problems. The few trains I have tested there all seem to work fine so far.

18 minutes ago, arabellajones said:

The current guide code has to be in the root-prim of a multi-prim linkset. I could build a model as one mesh, but it wouldn´t work. It looks like it needs to be two prims.

Yes, it would be hard to make a full-featured train as a single object, because you'd still need child prims for anything animated (like rotating wheels) or emitting particles (like smoke) or extra passengers, but you could certainly use way fewer links than the old prim-based trains.   With luck, that would translate into lower L.I. too, as you point out.

[animats]

Larson Logistics' quarry train and the streecar from Sumi at Burns seem to use newer scripts that work well.

I've run the quarry train the length of the Bellessaria line without problems other than those from defective signals.

"Model Railroading is Fun!" - old issues of Model Railroader

[arabellajones]

11 hours ago, Rolig Loon said:

FWIW, the rail system in Bellisseria follows the same standards for scale and guide prim placement as SLRR rail beds elsewhere on the grid, so SLRR-compatible trains should all run there with no problems. The few trains I have tested there all seem to work fine so far.

Yes, it would be hard to make a full-featured train as a single object, because you'd still need child prims for anything animated (like rotating wheels) or emitting particles (like smoke) or extra passengers, but you could certainly use way fewer links than the old prim-based trains.   With luck, that would translate into lower L.I. too, as you point out.

Animated parts is a different problem to what I described.

I can see a possibility with Mesh for simple wheels, for wagons and coaches. There are some things you can do with the UV mapping in mesh. I know I did this for four distinct areas on one model, UV mapped to the same complete square face. Two were opposite-handed and needed the UV mapping flipped left for right. Quite a few old prim-things use a rotating texture, and rolling-stock wheels are often not spoked. The Mansell wheel is one example of a disk-like wheel which could be modelled this way, but you have to do your research. There´s a gap in Wikipedia for types of railway wheels.

[arabellajones]

Mazidox Linden, on the Lab Gab, may have just described what is causing the problem. The older crossing code used to have the user and vehicle arrive in a predictable order. With the revised code, the slow half of the process can happen faster than the fast half, the two events happen out of order, and something breaks. This was very roughly half an hour into the Lab Gab. The context starts a little sooner, the shift from the very tightly-controlled data-centre network, but start listening at 30:00 and you get get what matters.

It will get sorted. They know about it.

It doesn't invalidate the old LSL code. Some of the problems described here from code still using old functions won't vanish but this bug will be sorted.

                      

Edited November 7, 2020 by arabellajones