Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

6 Neutral

About CarlaWetter

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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) {
  2. 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
  3. 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 ve
  4. 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 c
  5. 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?
  6. 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
  7. 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 fo
  8. @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!
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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
  15. 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.
  • Create New...