CarlaWetter

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.

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".

While I still get those mails, someone has decided that they now should be sent as text/html exclusively with a single line body. Seriously?

We did some more vehicle tests with results that may perhaps shed some more light on the current issue. What happens is that sitters may not be linked to their vehicle after a crossing. That is, they are, everything would look fine but when a script tests for sitters they may not see them anymore within the total linkset. Link number goes down too while that state lasts. Sitters may arrive a bit late, but quite often they may only ever show up after another crossing. At no time you'll get a link change event. When you have multiple sitters as in crewed vehicles, their link order will change depending on the time of arrival, so you may end up with a skipper starting on the lowest link number and ending on a higher one. All that sure can cause some havoc for vehicle engines that try to be a bit clever and compensate for crossings going wrong. I can't of course say that this is the root cause for the current vehicle control problems but it may very well be so. Diagnostic script to display the link status of all sitters when changes are seen, no warranties whatsoever: /* say sitter names in link order whenever it changes */ string MySitters; string old; string FindSitters() { string out; list sitters; integer PrimsOnly = llGetObjectPrimCount(llGetKey()); integer NumOfAvis = llGetNumberOfPrims() - PrimsOnly; integer i = PrimsOnly + 1; if (NumOfAvis == 0) return out; else for (; i <= PrimsOnly + NumOfAvis; i++) { sitters += (string)(i - PrimsOnly) + ": " + llGetDisplayName(llGetLinkKey(i)); } out = "\n" + llDumpList2String(sitters, "\n"); return out; } default { state_entry() { MySitters = FindSitters(); } changed(integer change) { if (change & CHANGED_LINK) { MySitters = "Link change!\n" + FindSitters(); } if (change & CHANGED_REGION) { MySitters = FindSitters(); } if (MySitters != old) // something changed compared to last time { llSay(0, MySitters); old = MySitters; llSetTimerEvent(1); } } timer() { // re-test until something changes again or we hit the next crossing MySitters = FindSitters(); if (MySitters != old) { llSay(0, MySitters); old = MySitters; llSetTimerEvent(0); } } }

It affects different brands of vehicles differently. While I had partial control losses on a couple of Bandit and TMS sailboats, I can't seem to get any failures out of Trudeaus. What I did observe is that scripts that check if an avatar is still seated on (linked to) the vehicle after a crossing often seem to get told that the avatar is not there despite them very well having been put back on the vehicle. Any issues that come up then are perhaps because of vehicle scripts trying to do the safe thing and treat the driver as absent until explicitly re-seated. At least that's how it goes for my test cases, but to be fair, they are far from comprehensive. Just what I can see from my own script works. What commercial vehicle scripts see and do has to be everyones guess.

@Aishagain: The new object crossing code actually is what we got from the Blake-in-the-Clouds test into RC as *966 because it helps with the "uplift". Helps vehicle crossings without a cloud uplift tooalready, but it actually came to be because the old code wasn't really working on AWS.That was the most perceptible result of the Blake test in beta for us mere mortals. Bon apetit!

As far as I can tell it is in fact the version with improved object crossing support that got rolled to Main today. The same version that had been rolled to part of RC and the Blake Sea regions last week.

Starting out from Crows Nest just now, turns out that only the regions Nelson and Thunderer are still reachable from there. Every other region around those three regions has a bouncy border up. Spyglass and Travertine are another isolated group. Starting from Half Hitch indicates another connected group of regions, but I'm out of time for now.

Trailing Animats I had some more success now (4:30 - 4:35 SL) starting from Beagle in a Star Class boat heading east. Very smooth ride followed by complete boat loss upon hitting the crossing to China. Wortking crossings are indeed very fast, hardly noticeable. And if it goes wrong, it's always catastrophic.

Tried two times to sail out of Half Hitch, once into Binnacle, now into Lanyard. Both ended in boat loss. Guess I've chosen a bad start point Rezzed boat in Mainbrace now, instantly lost it to the crossing into Mizzen. Things just don't want to work for me I guess.

For the actual question, if you update to Maitreya 5.1 you won't have separate hands or feet anymore. Update is free as a redelivery available at the main shop. (5.x has a redelivery option in the Maitreya HUD) For sailors it's always a good bit of a no-no to wear multiple scripted attachments on the same attach point, it still has too much of a chance to ghost one of those attachments.

In the heydays of RLV this was a feature. Have a folder or item partly named like an attach point the item(s) would be put on the addressed attach point. But haven't really encountered that in ages. And I don't think it really was ever to work outside the #RLV folder hierarchy. Of course you'd expect the official SL viewer to be entirely immune to that effect. http://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLifeAPI#Shared_Folders

Not an expert in SL bans but it's likely a ban on the VMs MAC address. You may want to try redefining the MAC of the VM and see if that helps. Certain virtual machines default MAC address classes seem to have gotten a blanket ban for SL.

Actually you can do it by detaching and reattaching the attachments in need of an update. Mesh body autohide settings, navigation HUDs used for sailing or anything that would require an update. I'm not very regular about it but I do it usually for sailing cruises and it's usually just the body and the Nav HUD anyway, no big deal to do.

If I had to come up with a guess it would be an active gesture that replaces /me in chat with /4. Try disabling your gestures and see one by one which one does the replacing.