Jump to content

CarlaWetter

Resident
  • Posts

    28
  • Joined

  • Last visited

Posts posted by CarlaWetter

  1. I was about to register our Marina, but the categories for locations held me back. We're not really a hangout, we're certainly not commercial although we offer lots of free maritime items, we don't RP, we're not even bothering with adult activites. Too bad that doesn't make us educational, the only thing is that we've never made a profit with any of it.

    We welcome visitors, especially those who like to travel by boat. One could see our place as public rez zone of sorts I guess. And other suggestions?

    • Like 3
  2. I think the dress is Kodaya by [Glitzz], but likely only available inworld as I can't really see it on MP. No idea about the boots, they are not a regular part of the outfit.(Neither are the ones worn on the snapshot.)

    Kodaya.png

  3. We already have an arms race of sorts. Bots have a timeout of a month after creation to circumvent age restrictions. Of a horde of 30 or 40 bots only a third or so get used some weeks, then the next charge deploys to account for manual bans. The overall number of bots make the use of parcel ban lists awkward at best. Or orbs too, a widely used orb only takes up to 100 names for memory reasons.

    Putting up banlines doesn't solve the bot problem at all, enough of them travel high to be unaffected. Parcel ban lists have their limits and are awkward to manage with large numbers. Orbs, well, they often have a management issue too in the end, be it memory or awkward addition of names in greater numbers. Age restrictions? Pointless, a lot of bots are older than most of us. What actually works is to set access to payment info on file. And if you run an open place, a marina, if you just have a mainland parcel that occasionally sees legitimate air traffic you'll hurt legitimate users. I don't want to see them hurt just to handle abuse by a bunch of bots.

    My personal solution was to write an experience KVP storage based blacklist that I can deploy on our places and keep updated wherever I am and can run the experience. It's wasteful but it works and keeps at least administration overhead on my side low. We run a number of open places and a bunch of people who don't care to openly document or defend their actions won't make us close up or kick legitimate users without payment info out.

     

    • Like 1
  4. I think it does Gridsurvey quite a disservice to get associated with these hordes of roaming bots that are travelling SL day for day. On a coastal mainland region we see between 20 to 30 of those bots every day. Whatever they "survey" has to be a truly badly organized venture.

    And I take care to exclude roaming bots with a documented purpose in their profile. Just those who keep their profile carefully devoid of any indication of their activities and purpose. Over the years one could assemble a list of 240 or more names and of those about 110 showed up just in the last month at the places I have an eye on. If they are of such a benign disposition, why can't their herders indicate so in their profile?

    • Thanks 2
  5. Oh dear, never remembered that one and of course FS Support is the only group where I'd want the chat and not the notices. Usually it's the other way around if at all. Yes, it was set and probably carried along through my settings backup routine. Never mind me, I'll be out now.

    • Like 1
  6. On 5/21/2021 at 11:05 PM, CarlaWetter said:

    And I haven't seen a lifesign from Firestorm Support English chat at all the last 13 days. Peaceful days, but not what I'd expect from that group chat.  Did mute notices around that time in FS, but chat still shows as unmuted.

    Some more testing seems to support at least my intial suspicion that on Firestorm 6.4.13 (63251), when I mute group notices I won't receive any group chat in the Firestorm Support English group. With notices enabled again, FS chat tends to pop up within minutes after login.

    Obviously this is anecdotal evidence for not much at all, but may at least be some further vector to look in one day.

    • Like 1
  7. Sounds at least in good parts as if you got hit by the sporadic and random bug that your vehicle scripts get a link change event before the sitters finish their transit. Many vehicles that use some version of AVsitter are particularly vulnerable.

    There are some AVsitter scripts available on MP that have some workaround included for the link change bug.

    https://marketplace.secondlife.com/p/AVsitter-129-fix-for-vehicles/20869617

    https://marketplace.secondlife.com/p/Cs-region-crossing-patches-for-AVsitter22-3/21179378

    Note, the bug as such is serverside and these scripts, meant to replace the AVsit respective [AV]sitA and [AV]sitB scripts in your vehicles can not really provide a fix, they only help to "hide" the issue for a short time after a crossing.

    • Like 1
  8. 31 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?

    The issue we 'boat people' have worked around - I'm not going to call it a fix - is that we try to teach scripts that are vulnerable to the occasional unwarranted link change event on region crossings to ignore them respective sleeping over them if they come up within, say, 0.5 seconds after a region change event. I have yet to see a single LEGITIMATE case of a link change event triggered by a region change. It could of course happen if

    - a sitter chooses the very moment of the crossing to actually stand up, really tough luck

    - the region figures out that the avatar in question really got lost in transit

    The latter traditionally happened a lot in the old days and in those corner crossing cases when your vehicle manages to leave into the next transit before your avi finished the first. That's the famous unsit and @animats suggested vehicle side workarounds of stopping the vehicle after a crossing and only continue once the avatar shows up. But you'd be surprised how far a vehicle an go before its scripts get back into a state to figure out what happened. So he's absolutely right in calling LL for a serverside fix of sorts. Oh, and funny enough, usually those unseats won't even trigger a link change for the vehicle, which for years has been not necessarily the nicest behaviour but at least it's been what would be called "expected behaviour,  JIRA closed". Transit processing has never been completely aware of the full "vehicle plus passengers" state, which would probably be a requirement for crossings to be 'totally' reliable serverside.

    I for one would already be happy if those stray link change messages would go away once LL gets a chance to tie up all the loose ends we have everywhere. We may be able to patch up some vehicles when they use open source scripts that cause their vulnerabilitiy. Namely AVsitter 1, which is often used for boats to provide seatings that go beyond a single avi car driving pose.

    • Like 1
    • Thanks 1
  9. 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

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

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

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

    • Like 1
  13. 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);
            }
        }
    }
    

     

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

    • Like 2
  15. @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! ;)

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

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

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

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

  20. 22 hours ago, ChinRey said:

    Come to think of it, the item I had simialr problems with was in a folder named "Top". As convoluted as the SL Viwer's code seems to be, it wouldn't surprise me at al if it has trouble keeping track of what is folder name and what is attachment point...

    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

×
×
  • Create New...