Sailing "body" Animation Issue's After Crossings

[Vicious Hollow]

I reported this bug on Jira earlier, but it was closed being seen as a duplicate issue, in which I don't feel  is the same issue that was associated . The issue being worked on before was for "parts" freezing up, as in propellers and whatnot, and vehicles stopping momentarily at crossings. This may be in the same family issues, or related in some way, but I just see it as whole other issue and in need of being investigated more.

 

Here's the short version, as I'm sure a lot of sailors have experienced this - 

On a boat, when tacking starboard or port, your avi leans (sometimes automatically, sometimes you have to control) with the boat. When the first "new" crossings code that was tested on the beta server was rolled out, things we're heaps better...one could fantastic. A short while in, complaints started to come in from some who experienced their passengers being ejected from their boats. A fix was soon after rolled out, which worked but then this new issue mentioned above started and has been there since. 

 

The crossings don't matter, meaning they can be smooth, or bumpy, it's totally random on when this occurs. To make it even more so odd, it doesn't happen on every single boat. Where it happens on the Bandit IF or 55, it doesn't happen on the Bandit 22 LTE. On the Flying Shadow, Star or Laser it doesn't happen directly, but you get an animation box request, which can throw the animation or position off a little, and yet on the Bandit 170 you see no issue at all.

 

To add to this even more, while on Bandit 55, after the freeze up/lock up/sailor pose stops, when I click in the boat to get the pose menu and select a pose or hit default it tells me something along the lines of "You must be seated on the boat, before you can chose a pose" even though visibly I'm still sitting on the boat.  Which is what I want to add, to this being "different" then what's been reported, because everything continuers to function on the boat - sails and lower, and tighten and loosen on command, steering isn't effected either. Even the boat physics will continue to act like the sailor is moving from side to side, though visually one is frozen. 

 

The creator of Wind Compass Pro Kim Farleigh, has sent out to the group, an AVSit fix, which appears to be working,  be it a temp fix,  but there are a number boats still be effected by this that don't use the same AVPose or AVSit scripts. 

 

I don't mean to sound rant-y about all of this, especially this early in the morning/afternoon, but I really feel like this is an issue, that again may be in the same family as those reported before, but still not the exact same thing, and in need of being looked into.  

[Whirly Fizzle]

Your bug BUG-229687 sounds the same as Maestro describes in his comment HERE on BUG-229214.

Maestro filed an internal bug report for this bug : SL-13785

Quote

Maestro Linden added a comment - 18/Aug/20 1:59 AM

I took a look at the "Big WhooperGTFOF 4av 126li - rez water pgdn start" boat, and drove it around the Blake Sea regions for a bit at top speed (Throttle=5). At my usual latency of ~60ms 'ping sim' time, the boat appears pretty smooth on region crossings. However, if I artificially add 160ms of extra roundtrip latency (for ~220ms total), I do encounter rotational 'lurches' in the boat across it's x-axis, briefly listing the boat ~20 degrees before it recovers. I'm not sure what's going on here, but it seems to be caused by the viewer's extrapolation of the boat's 'rolling in the waves' motion as it crosses, since the effect is only visible with higher viewer<> simulator latency. Is your 'ping sim' statistic fairly high, usually?

I sometimes see another issue with this vehicle; sometimes, this error pops up on crossing:

 

llStartAnimation: Script trying to trigger animations but agent not found

llStopAnimation: Script trying to stop animations but agent not found

 

I believe this is caused by the vehicle scripts crossing and starting on the new sim before the agent has fully crossed, causing the vehicle scripts to briefly not see any seated agents. I have this filed internally as SL-13785. Luckily, this issue case doesn't cause CHANGED_LINK to trigger in the scripts, which would cause most vehicles to stop, but it does cause intermittent 'agent not found' errors and such.

 

[Vicious Hollow]

To keep from getting whacked on the knuckles for being difficult or argumentative 😝 I agree it's similar and in the same "family" of issues, but at the same time, I think there's still a difference.  

This is the script error that's been seen - 

Quote

"Camera control currently only supported for attachments and objects on which you are sitting."

Which again I admit may be in the same family to the issue being discussed, however, *covers his knuckles* the problem the lot of us are seeing, now, has nothing to do with the boats or vehicles motions or actions or lurching or reaction  on crossings, and one isn't being  thrown from the boat like in the past, but more so what happens to the avi's pose in general. One just stops moving (as in from side to side with the lean of the boat) all together..You continue to sail on with the boat, but with no ability to adjust the position or pose. 

 

Again I'm not trying to be argumentative or difficult, and if it is seen as the same thing by those who know better then I, in the end, who am I to debate it (more then I already have lol ) It's just been really frustrating for a lot of us out on the water, and we're all hoping to see that this will be resolved and remedied soon.  

 

 

Edited November 17, 2020 by Vicious Hollow

[AlettaMondragon]

41 minutes ago, Whirly Fizzle said:

Your bug BUG-229687 sounds the same as Maestro describes in his comment HERE on BUG-229214.

Maestro filed an internal bug report for this bug : SL-13785

 

 

Especially this is very frequent and serious in this issue, which he also mentioned in his comment:

"llStartAnimation: Script trying to trigger animations but agent not found"

And the same with acting on control inputs. In both cases, the best thing you can do is to stand up from your vehicle, and sit back, so that it will do the permission request again without failure, and you can go on. When you're flying or sailing, it's not easy or possible to stop after every single crossing, and it makes sailing and flying impossible to enjoy, or impossible at all, if your craft all are really prone to this issue. If they lose control input, good luck to even stop, if they lose animation permissions, you will be probably stuck in a weird pose, half out of your boat or aircraft or car.

I experienced some improvement on this in the last two weeks when crossing from one uplifted region to another uplifted region, but it doesn't entirely eliminate this issue. I hope a fix for this is in progress, because it's really like there's no point to take off with an aircraft now just to have to delete the craft 2 sims away and tp back to the airport and take off again, hoping it won't get messed up on the first or second crossing again.

 

@Vicious Hollow This is actually the same sort of issues, because all of them came up after the crossing code updates in August, and their source is somewhere in the object and the avatar taking different amounts of time to be transferred, the object is considerably faster, and when the script would check for anything - control inputs, animation permissions, camera controls, etc - that needs the avatar sitting on the object, it won't find the avatar and throw the error. I'm still convinced that it's not even just that the avatar crosses much slower than the object, but that the destination simulator server has "no idea" of where the avatar is, at all, for an excessive amount of time, which then results in these issues with vehicles, and also the issue where you cannot see what you send in group or personal IM conversations for about 30s-1min after crossing a region, and where you usually have to come to a complete stop, wait for several seconds, and then you are able to see the messages you send to a group chat, as if it would take that long for the affected service to "catch up" with the position of the avatar. LL apparently rejected this suspicion, but I haven't heard a better guess as to what happened during and after those code changes that resulted in all these issues.

Edited November 17, 2020 by AlettaMondragon

[animats]

2 hours ago, Whirly Fizzle said:

However, if I artificially add 160ms of extra roundtrip latency (for ~220ms total), I do encounter rotational 'lurches' in the boat across it's x-axis, briefly listing the boat ~20 degrees before it recovers.

Well, yes. Extra round trip delay will do that. Add a full second and double region crossings fail almost every time.

Region crossings extrapolate movement during the stall which occurs at every region crossing. Region crossings require a round trip handshake with the viewer (the underlying cause of many problems), so adding network latency and you will slow down region crossings.

Are you running a current version of Firestorm? Firestorm does, in fact, limit bogus rotations at region crossings to 20 degrees and position error to about half a meter. Technical discussion here. Without that, you'd sometimes roll much further or momentarily go underwater, if you were pitching or rolling or moving vertically going into the crossing. On "smooth water", you should get smooth crossings. Should be better on AWS sims, because the region crossings are faster.

 

1 hour ago, AlettaMondragon said:

"llStartAnimation: Script trying to trigger animations but agent not found"

That's a common problem with vehicle scripts. You have to check that you still have animation permissions after a region crossing, and not do anything avatar-related until the avatar arrives in the new sim. When you get the CHANGED_REGION event, the vehicle has crossed but the avatar(s) are usually still catching up. A recent fix made objects cross regions faster, and now it's more likely that you see avatar delay. So scripts have to wait for the avatars. The way to check is to call llGetObjectDetails on the avatar's key and ask for its root prim. If that's the same as the vehicle's root prim, the avatar is properly seated. To make this less frequent, LL recently put in a delay so that scripts don't restart after a crossing until either the avatars have arrived or something like half a second has elapsed. This makes that problem less frequent, but it really should be fixed in scripts.

It's important that scripts restart after a crossing even if the avatars haven't arrived, because during that period you can't steer but may still be moving. Scripts need to take appropriate actions, like stopping. This is more of a problem for land vehicles, where you're not far from going off-road or hitting something. There's one curve in Satori near GTFO HQ with a double region crossing, and many vehicles go off the road there. There's also a jog on Robin Loop like that, where region crossing problems with naive vehicles regularly result in landing in someone's yard. Fortunately the resident there isn't in much.

You have to manage region crossings in LSL, annoying though this is. Really, though, with most crossings now down to 500ms or so, the viewer and scripts can mostly cover for the delay and you barely see it.

 

[AlettaMondragon]

14 hours ago, animats said:

That's a common problem with vehicle scripts. You have to check that you still have animation permissions after a region crossing, and not do anything avatar-related until the avatar arrives in the new sim. When you get the CHANGED_REGION event, the vehicle has crossed but the avatar(s) are usually still catching up. A recent fix made objects cross regions faster, and now it's more likely that you see avatar delay. So scripts have to wait for the avatars. The way to check is to call llGetObjectDetails on the avatar's key and ask for its root prim. If that's the same as the vehicle's root prim, the avatar is properly seated. To make this less frequent, LL recently put in a delay so that scripts don't restart after a crossing until either the avatars have arrived or something like half a second has elapsed. This makes that problem less frequent, but it really should be fixed in scripts.

The vehicles I've been using had nearly no problems before these changes, right after it the rate of producing an error was close to 100%, and now between two uplifted sims it's about 50% with some vehicles, still above 70% with others. Something has to be done on server side to fix it entirely, because many vehicles won't be updated to work around this issue. Especially not those whose creators have left SL for various reasons over the last few years.

[arabellajones]

OK, I was asking about this "family of problems" a while back. Things improved. Several people were saying "you have to change the scripts", and a lot of vehicles use script packages without permissions to change the scripts. And some of the people saying that saying nothing at all about how the details could be changed.

This time around, somebody said enough to point me in the right direction, still maybe not enough.

You use a changed event with the CHANGE_REGION flag

OK, I'm not a smart programmer like some of you folk, but the number of vehicle-program samples I found which bothered with a changed event can be counted on the fingers of one foot. The Linden Vehicle Tutorial doesn't even contain the words "region" or "crossing".

Gentlemen, you disappoint me. Are URLs so hard to include?

Anyway, it looks as if the root-prim script that has the changed event needs to have stored the UUID of the vehicle and the driver, and llGetObjectDetails gets the OBJECT_ROOT of the driver. If the driver is sitting properly on the vehicle, the UUID returned is that of the vehicle, root prim of the linkset.

[CarlaWetter]

The issue I kept noticing on boats was that we'd get a CHANGED_LINK event after a crossing which might indicate to vehicle and especially sit scripts that a sitter changed. And right enough, it's usually triggered because the avatar has not yet finished crossing over, so any checks on the avatar showed their absence. How a vehicle reacts to it varies. Some boats just stop, others are  more patient and more or less ignore the event. Not many sit scriptsets have this luxury, which is why some people came up with a workaround for the often used AVsitter 1 to either wait out some seconds after a crossing before acting on a CHANGED_LINK event or to just throw it away, giving the whole procedure some more time to finish off.

My tests using previously vulnerable boats with such a patched AVsit were pretty positive, but it isn't a fix, it is a workaround.

For all the vehicles that are no longer actively maintained (and I am afraid that's the overwhelming majority) we can only hope that we soon get region crossings without random CHANGED_LINK events popping up. Those events need to be reliable especially for sit scripts, so hacking around this issue inworld can only be a temporary help and should not be made the new "expected behaviour".

[Mollymews]

11 hours ago, AlettaMondragon said:

The vehicles I've been using had nearly no problems before these changes, right after it the rate of producing an error was close to 100%, and now between two uplifted sims it's about 50% with some vehicles, still above 70% with others. Something has to be done on server side to fix it entirely, because many vehicles won't be updated to work around this issue. Especially not those whose creators have left SL for various reasons over the last few years.

Linden updated the network protocol so the transfer goes faster than it did

in the slow old days there was a race between the agent/avatar and the vehicle scripts. A slow old race that agents used to win pretty much all the time, so the agent was already registered with the destination region before the vehicle script instantiated

with the new fast protocol the vehicle script is winning the race pretty much every time now.  So the script can't find the agent (because it hasn't arrived yet) and throws a runtime error

Linden are looking into what could be done about this.  I heard anecdotally on here (animats I think it was who said in another post) that Linden are looking to delay script instantiation until the agent does arrive but am not sure what the state of that effort is

 

Edited November 19, 2020 by Mollymews
[]

[arabellajones]

19 hours ago, CarlaWetter said:

The issue I kept noticing on boats was that we'd get a CHANGED_LINK event after a crossing which might indicate to vehicle and especially sit scripts that a sitter changed.

That's picked up by the same changed event that I pointed to. I can't figure out how you could usefully test for both happening at the same time, how they persist. Can two different triggers be tested for as a single event, or do you have to detect trigger_A, set a flag_A, and if trigger_B happens then check flag_A. Two different runs through the changed event. Does the order of the triggers matter? If you have a driver and passengers, and a passenger un-sits you will get a CHANGED_LINK, and nothing has gone wrong.

I know vehicles focus on the driver, they often need to be the owner or have specific permission, and there can be pilot/co-pilot control transfers. So watching for a CHANGED_REGION, checking the currently-designated driver is in place, and handling that problem, may be a better answer than dealing with all the possing CHANGED_LINK options.

[CarlaWetter]

44 minutes ago, arabellajones said:

So watching for a CHANGED_REGION, checking the currently-designated driver is in place, and handling that problem, may be a better answer than dealing with all the possing CHANGED_LINK options.

Thing is that due to the law of "how it always was" we can't get rid of certain scripts handling CHANGED_LINK events, it's their job. Sitter scripts in particular. It's not a question of choice we have. There's lots of sailboats using AVsitter and if we wait for them to come up with an update we'll be bitterly disappointed. As vehicle scripters we can act on CHANGED_REGION events to figure out if the crossing went fine, but when we only sometimes get a CHANGED_LINK with an avatar lost or arriving just a tiny bit late and no such event happens when the avatar arrives and gets put back on the vehicle, we're going to have a bit of an information deficit, to put it kindly. This can perhaps be handled but in the end we have to rely on the correctness of the events our scripts register.

For no mod vehicles that haven't been maintained in ages and are still in widespread use this all is of course entirely academic. They just break. Not too much of a big deal probably for bikes as you rarely have those with multiple seats and several dozen animations, at least not on the road. That's quite different for boats which in the most part have a pretty big set of animations and usually multiple seats as well.

Oh, and I'm not discussing strategies here how to make vehicles safer for crossings, in particular close to region corners. That's one for all you vehicle engine scripters out there.

[Mollymews]

11 minutes ago, CarlaWetter said:

 CHANGED_LINK

a FYI on this

when the agent(s) arrives then it is re-linked to the vehicle when the vehicle is present. The vehicle script CHANGED_LINK event is not fired on this occasion. We have to test for agent on CHANGED_REGION. Typically with a polling loop: while (some_time_has_not_elapsed && agent_is_not_found); // wait until some_time_has_elapsed OR agent_is_found

[animats]

18 minutes ago, Mollymews said:

a FYI on this

when the agent(s) arrives then it is re-linked to the vehicle when the vehicle is present. The vehicle script CHANGED_LINK event is not fired on this occasion. We have to test for agent on CHANGED_REGION. Typically with a polling loop: while (some_time_has_not_elapsed && agent_is_not_found); // wait until some_time_has_elapsed OR agent_is_found

That sounds right. If the avatar arrives before the vehicle scripts turn back on, there probably isn't a CHANGED_LINK event. If there's any delay in avatars arriving, a CHANGED_LINK event probably occurs.

That creates some problems. In my vehicles, I stop all movement by turning off physics at each region crossing, then turn it back on and apply the pre-crossing velocity when the avatars show up. If they don't show up, the vehicle is frozen, and after 30 seconds, it gives up, turns off, and reports it's stuck.

If you don't want to stop motion like that (the typical delay is < 100ms, so it's not very visible) there's a problem distinguishing between "avatar got off" and "avatar failed crossing".

After "Uplift" is done (and all sims are now in "the cloud") we all need to beat on LL to actually fix region crossings. Not just tweak their timing a little, FIX THEM. I'm tired of coding workarounds.

[CarlaWetter]

28 minutes ago, Mollymews said:

a FYI on this

when the agent(s) arrives then it is re-linked to the vehicle when the vehicle is present. The vehicle script CHANGED_LINK event is not fired on this occasion. We have to test for agent on CHANGED_REGION. Typically with a polling loop: while (some_time_has_not_elapsed && agent_is_not_found); // wait until some_time_has_elapsed OR agent_is_found

Thanks for pointing this out, it's precisely what I say. Issue is that it SHOULD NOT fire, but it often does. That's what breaks Vicious' sailing experience because the sit script considers the avatar lost and will not be informed about a later arrival. I'm not discussing what should be best practice, I point out why we keep hearing about a lot of vehicles randomly failing, either completely or partially. Vehicles like the Loonetta sailboat moor, which is not unreasonable if the skipper gets lost, but is pretty bad when the skipper just arrives a couple of milliseconds late and never knows why they have to re-sit to convince the boat that yes, they are around.

[Mollymews]

5 minutes ago, animats said:

That sounds right. If the avatar arrives before the vehicle scripts turn back on, there probably isn't a CHANGED_LINK event. If there's any delay in avatars arriving, a CHANGED_LINK event probably occurs.

i haven't seen this in the testing I have done

for the purpose of region crossings the script server seems to work on the basis that the agents are linked (even tho technically they are not until both are present on the same region)

the only time CHANGED_LINK is fired is when the agent is actually unsat (unlinked) as a consequence of being prevented from crossing. In this situation when we teleport (cross to the destination region) then the agent is not automatically re-linked to the vehicle, as it is under normal conditions

[CarlaWetter]

I don't routinely run this script on my vehicles, especially not since I've resorted to a patched AVsitter in my most vulnerable boats but here is a little test script and the results on two pretty nice tours. If the script would chat its findings out as soon as it sees them I'd not hear its local chat because I still was travelling the wires...

Logging all CHANGED_LINK within 5 seconds after a crossing is pretty generous, you rarely get a late arrival of >1 second in my experience.

integer count;
integer xings;
integer lastx;

default
{
    on_rez(integer s)
    {
        count = 0;
        xings = 0;
    }

    changed(integer change)
    {
        if (change & CHANGED_REGION)
        {
            xings++;
            lastx = llGetUnixTime();
        }
        
        if (change & CHANGED_LINK)
        {
            if (llGetUnixTime() < lastx + 5) count++;
        }
    }
    
    touch_start(integer n)
    {
        llRegionSayTo(llDetectedKey(0), 0, "Link Change Events near region crossings: " + (string)count);
        llRegionSayTo(llDetectedKey(0), 0, "Crossings counted: " + (string)xings);
    }        
}

--

chat-2020-11-06.txt:[2020/11/06 09:53:27]  liferings: Link Change Events near region crossings: 5
chat-2020-11-06.txt-[2020/11/06 09:53:27]  liferings: Crossings counted: 62
--
chat-2020-11-06.txt:[2020/11/06 10:01:14]  liferings: Link Change Events near region crossings: 6
chat-2020-11-06.txt-[2020/11/06 10:01:14]  liferings: Crossings counted: 67

[arabellajones]

1 hour ago, Mollymews said:

a FYI on this

when the agent(s) arrives then it is re-linked to the vehicle when the vehicle is present. The vehicle script CHANGED_LINK event is not fired on this occasion. We have to test for agent on CHANGED_REGION. Typically with a polling loop: while (some_time_has_not_elapsed && agent_is_not_found); // wait until some_time_has_elapsed OR agent_is_found

This is the sort of detail which I would regard as inadequately documented.

[Mollymews]

31 minutes ago, CarlaWetter said:

Ia little test script

i made a little mod of your script and stuck it my bike. It just counts all CHANGED_LINK events fires
 

integer count;
integer xings;

default
{
    on_rez(integer s)
    {
        count = 0;
        xings = 0;
    }

    changed(integer change)
    {
        if (change & CHANGED_REGION)
        {
            xings++;
     
        }
        
        if (change & CHANGED_LINK)
        {
            count++;
        }
    }
    
    touch_start(integer n)
    {
        llRegionSayTo(llDetectedKey(0), 0, "Link Change Events near region crossings: " + (string)count);
        llRegionSayTo(llDetectedKey(0), 0, "Crossings counted: " + (string)xings);
    }        
}

running up and down Route 10 then count = 0

[13:22] pink race bike SW 1.21: Link Change Events near region crossings: 0
[13:22] pink race bike SW 1.21: Crossings counted: 26
[13:23] pink race bike SW 1.21: Link Change Events near region crossings: 0
[13:23] pink race bike SW 1.21: Crossings counted: 30
[13:27] pink race bike SW 1.21: Link Change Events near region crossings: 0
[13:27] pink race bike SW 1.21: Crossings counted: 40

 

it might be that the regions along the route are all now on AWS. Some of the crossings were a bit bumpy but my bike script recovered ok.  Am not sure what the conditions would be to reproduce a situation where CHANGED_LINK would fire on a region crossing

maybe when you get time, you could run your route again and say the region name(s) when count changes. I would quite like to be able to reproduce this if is happening on AWS regions, so I can mod my bike to account for it should it happen to me

 

[animats]

I think I see how this could be fixed server side.  I was just driving the little Infinity Freight quarry train around Bellessaria, and kept getting the usual errors:

[20:32] llStopAnimation: Script trying to stop animations but agent not found
[20:32] llStartAnimation: Script trying to trigger animations but agent not found
[20:32] Camera control currently only supported for attachments and objects on which you are sitting.

When you think about it, all that's wrong here is that the LSL calls were made too soon. What's needed is to queue animation and camera change requests made during region crossings until the avatars catch up, instead of reporting errors. This would make these LSL calls Just Work, without any special action in scripts.

This ought to be do-able. It's all in one sim, the "gaining" sim (the one you're entering). The gaining sim knows when all the avatars have arrived; Simon Linden implied that at Server User Group.

Second Life is supposed to be a consistent-eventually system - when sims and viewers get out of sync, they should get themselves back into sync without problems. So doing this server-side moves towards that design goal.

[Mollymews]

1 hour ago, animats said:

What's needed is to queue animation and camera change requests made during region crossings until the avatars catch up, instead of reporting errors. This would make these LSL calls Just Work, without any special action in scripts

 

agree that the this should all be done server side

another way might be to strengthen bounds checking in the LSL API code. Something like:
 

start_animation()
{
   if (agent_with_perms_found)
   {
      .. start animation
   }
}

stop_animation()
{
   if (agent_with_perms_found)
   {
      .. stop animation
   }
}

set_camera()
{
   if (agent_with_perms_found)
   {
      .. set camera
   }
}

 

[Mollymews]

thinking more about the LSL API

i have never seen the LSL API code but am pretty sure that it is written with try catch throw exception (or similar). Which from a API development debugging pov is a good thing

is not so good from a LSL scripter's run_time pov, when the LSL scripter can't catch the thrown exception from within LSL, to take remedial action including suppressing the debug error output

i think it would be helpful to LSL scripters for there to be a LSL callback exception event

example:

default
{
   state_entry()
   {
      llStartAnimation("hello");
   }

   exception(integer exceptionnum, string message, integer cancel)
   {
       if (exceptionnum == EXCEPTION_ANIMATION)
       {
           cancel = TRUE;  // setting cancel to TRUE stops the error message being said on the debug channel
                           // cancel is FALSE by default
                           // if there is no exception event in script then the script error handling remains as
                           // it is now. Which should allow all existing scripts to run as wrote
       }
   }
}

 

[animats]

You can sort of do that now. My NPCs have a listener in one prim of the linkset listening on DEBUG_CHANNEL for messages from the same linkset. If anything crashes, I get an email, and all the scripts in all the other prims get reset. This is to catch major problems, mainly stack/heap collisions, not something that trips in normal operation.

[arabellajones]

An update: the VRC/Hobo train script does use a CHANGED_REGION to update some information. I am struggling to script a better check for this problem, but adding an llSleep(0.2); makes a huge difference to the error rate. Not zero, and the incidents are correlating with regions that have a very high script load. I also suspect avatar concurrency is a factor. I did make a very long train run, Bhaga to Yucca to Tuliptree, and the errors were few enough to be tolerable.

(I am grumpy about that script, I am still trying to figure out how to remove the "Bell" and "Horn" buttons from the menu)

 changed(integer iChanged)
    {

        if (iChanged & CHANGED_REGION)
        {
            llSleep(0.2);
            gsRegionCurrentName = llGetRegionName();
            gvRegionCurrentCorner = llGetRegionCorner();
            LocomotiveDisplayUpdate();
        }

There is a version of Avsit which has a bugfix, but I can't figure out how it works.

AVsitter bug-fix for vehicles

 

This needs a Linden-level fix.

[arabellajones]

I have been struggling with LSL for months. I have managed to solve a few problems I have had, replacing old chunks of code with some of the new methods. I have had help from some talented people.

But this is a problem I am bouncing off, hard. Maybe I am a fool for even thinking it can be fixed in the rather antiquated open source scripts for the SLRR. Or is it that I am the only one taking the trouble to pass on what I have learned. This is a thread about a problem with boats, there are fixes which have been devised for boats, and it was pure chance that I learned about them elsewhere.

Well, now you know what I do. But how many of you are there? Are these forums worth bothering with, or is it just futile shouting into the wind?

[Logan Elf]

13 minutes ago, arabellajones said:

Well, now you know what I do. But how many of you are there? Are these forums worth bothering with, or is it just futile shouting into the wind?

This particular forum is the Server one, so scripting people may not read it. I've never written or modded vehicle scripts, so just following this thread out of interest. You may get better luck (and I stress "may") in the Scripting forum.