Too many disconnects and unsits from vehicles on sim boarders
planned
TgBianca Resident
We did 11 races in January with all together 96 racers and have about 7-12 racers per race. A race takes normally max 40min. But there was not a single race in January all sailors finished without disconnects or thrown off the sail boat on crossing sim boarders
The region "Depace" is the worst sim in the last weeks. We crash there most of the times either on the crossing into Depace or out of Depace. It happens as well when someone sails alone there. There is not much underwater stuff that needs to be rezzed long. So there is no actual reason for these crashes there.
Check the sim Depace first and seriously and don't just look at some general parameters or values. Do a serious check including server address changes and all those things. The other sims start getting the same issues more and more. So the whole area is worth to be seriously checked.
and i talk about all these sims: Stodierski, Mautte, Paltiete, Mon Bayete, Degrand, Sarante, Petaccio, Rexach, Betacourt, Feraco, Repaci, Castrum, Palmerston, Rafeiraga, Valdivian, Couse, Gerache, Collhaytah, Port Pawtee, Maris, Conwy, Port Gonnornertnert, Quimadra, Depace, Lavaca, Val Encia, Benach, Coull, Oprince, Getachew, Wyrldmaker, Corpening, Geffers, Costagliola, Cottier
Log In
animats Resident
Worth noting: for non-physical vehicles moving across sim boundaries, there is a bug that can sometimes result in the vehicle ending up in the wrong region, hundreds of meters away. Worse, too much of that can crash a sim server. I filed a SEC bug on this years ago in the old JIRA, but I can't access it any more because the archiving of the JIRA made it inaccessibly to the reporter. Whirly Fizzle was able to replicate this bug with a very simple script, which rapidly caused sim crashes.
Physical vehicles, which most are, seem immune to this bug. This seems to be related to non-physical object moves across region boundaries using KFM.
Atomic Infinity
animats Resident I'm not using KFM because it has too many caveats - I find it far more reliable to just do the math and place the object with llSLPPF. Doing that means I can literally pin down the exact frame that the border handover will begin, which is how I came to my conclusions listed. So far I never ended up in the wrong region even when doing 4-way region corners at speed, so I guess I'm not doing whatever that bug is (or I'm lucky).
Atomic Infinity
Notes on region border crossing... Signal Linden Philip Linden
I have now completed a re-write of my LSL that runs my non-physical trains across region borders, with the aim to reduce the unsits and permissions script errors that the server throws up, despite perms being correctly held in the script. While I do occasionally still get errors popping up, they are now much less frequent. I will share what I have found just in case it helps your region border crossing review.
There are several places on the old mainland tracks that do pass through a 4-way region corner, and for the most part my code now also passes through these with far less incidents. Unsits can now be considered more rare, which is nice 🙂
My understanding of a border crossing summary :
The object moves beyond -1.0 or +257.0 metres coords, to trigger a handover. The server then gets very busy with a lot of stuff, during which -
- The scripts are suspended in the vehicle
- The avatar is separated from the vehicle
- The vehicle and avatar are passed over to the receiving region
- The avatar and vehicle are reunited as a single object
- The scripts are resumed, and it continues on its way
The errors that happen are all perms related : start/stop anim, control camera, and take controls, often with 'avatar not found'. The nature of the specific errors suggested to me that the scripts are being stopped after the avatar has already been separated from the vehicle, or has already left the old region, and then are being restarted before the avatar has arrived on the new region, or before they are re-seated.
Moving a non-physical object (train) is just maths, so I know exactly when in my script that my coords will trigger a region change. So in my script I now suspend all perms-related function
before moving the object out of region
, and it then waits for a CHANGED_REGION event.This event occurring is hopefully evidence enough that the vehicle has arrived in the new region (though a question remains : is this event triggered by leaving a region, or by arriving in a new one?)
When the change event occurs, a timer then polls for the local existence of the avatar. Once the avatar is detected to be in the new region AND confirmed sat once again on the object, it resumes normal functionality.
(see 1st reply for continuation.... because canny word limit sucks ;p)
Atomic Infinity
continued...
I believe the key part that makes this succeed is that :
The script continues to hold the permissions to act on the avatar, but is not actually animating, nor controlling cam, nor taking controls at the moment of crossing the border. If it is not
trying
to do these things, it can not generate an erroneous and unjustified script error when it can't find the avatar.So my LSL re-write is effectively a workaround for the synchronization problem of the suspend/resume of scripts not matching when the avatar and/or vehicle actually do change region and re-unite.
The script does not lose its permissions status at any point - what it 'loses' is the avatar it is supposed to be acting upon. The scripts are running when they are not supposed to be.
- Stopped scripts needs to be a pre-requisite before unseating the avatar, and being re-seated needs to be pre-requisite to starting them up again.
My code does not fix unsits, it avoids unjustified script errors. Avoiding these script errors is what fixes a lot of unsits.
I do still get some script errors occasionally, so somewhere my workaround is not 100% reliable at suspending / resuming function in the brief moment of border crossing, or detecting the avatar fast enough.
The users viewer also seems to be an influencing factor. When I do get script errors now on crossing a region border, it is most often when my viewer framerate is compromised, for example when approaching a built up area with a lot of content to load and render. Maybe the delay in my lower framerate still allows some stray updates to be sent while the script is trying to release cam & controls before the border, but this is just guesswork.
I was thinking I might try to do a similar process in some of my physical vehicle projects, but seeing what it took to improve in a non-physical, I’m not sure that is going to be possible. The non-physical movement is like precognition of when the crossing will happen, whereas physical movement is not so predictable. I guess I'll try it and see how that goes.
Anyway, hopefully this info is useful in the search to help fix border crossings for everyone.
Atomic Infinity
Addendum - These are the errors, and why they occur :
llStopAnimation: Script trying to stop animations but agent not found
The object is still in the OLD region, the script is running. The avatar is not sitting on it, and has already left the old region.
llStartAnimation: Script trying to trigger animations but agent not found
The object is in the NEW region, the script is running. The avatar is not sitting on it, and has not arrived in the new region.
llStopAnimation: Script trying to stop animations but permission not set
The object is still in the OLD region, the script is running. The avatar is NOT sitting on it, but is also still in the old region. (Anim perm is auto granted when sitting, therefore avatar is not sitting)
llStartAnimation: Script trying to trigger animations but permission not set
The object is in the NEW region, the script is running. The avatar has arrived in the new region, but is NOT yet sitting on it. (if the avatar was sitting, anim perms are auto granted)
Camera control currently only supported for attachments and objects on which you are sitting.
To me this one is the most obvious example of the problem. I was sitting on it in the old region, and I’ll be sitting on it in the new region. The only time I am not sitting, is while the server hands me over.
The common denominator in all these, is that the scripts are still running when the avatar is unseated, and have started up again before the avatar is re-seated.
And then there’s that random pop up box that happens sometimes :
Cannot create requested inventory.
[OK]umm.... whut? yeah ok, but I have no idea what that means :D
animats Resident
Atomic Infinity Scripts for vehicles have to recognize that being in transit across a region boundary takes time. There is an in-transit period during which some things won't work. Upon arrival in the new region, you have to detect that all avatars are properly seated (vehicle is parent of avatar, avatar is child of vehicle). Then re-acquire permissions. Then re-establish controls, animations, etc. See my code at https://github.com/John-Nagle/lslutils/tree/master/motorcycle
A few years ago, one of the server Lindens suggested stopping vehicle script execution during region crossings. That way, scripts never see what's going on during a region crossing. But if the server stops scripts, you can't steer or throttle during a crossing, and slow crossings result in runaway vehicles. That would make things worse.
Atomic Infinity
animats Resident I can see it is complicated yes, but it needs to happen in a controlled order. If they can't be in a controlled order then they should disable the script error pop-ups that have no basis in fact. Its highly likely that the server is basically causing unsits by tripping over itself sending wrong script errors out that are entirely out of the scripters control.
Plus it is massively disheartening to have a vehicle you
know
holds correct permissions constantly telling you on border crossings that it doesn't, and suggesting your work is substandard....edit : maybe I am not expressing it that well, but I am talking about suspending scripts at the moment of actual handover only at server level, not some time before you get to the border. Control inputs 'during crossing' are moot anyway if the avatar is not seated, unless you asked for and secured perms manually from the avatar before they sat down.
Atomic Infinity
So I figured do some lsl investigating, to see if scripts really do lose permission and need it re-acquired after a crossing, and how long it takes for the process to happen, how long is the avatar removed for, etc. I added this script to a physical vehicle, then drove it over a lot of borders. 3 seconds after each border crossing it reports how many timer events happen with each of the 3 conditions tested, then resets the values.
key avatar;
key vehicle;
integer no_perm_count;
integer not_same_region;
integer not_sat_on_me;
integer report;
default
{
changed(integer change)
{
if(change & CHANGED_LINK)
{
avatar = llAvatarOnSitTarget();
vehicle = llGetKey();
if (avatar != NULL_KEY)
{
llRequestPermissions(avatar, PERMISSION_TRIGGER_ANIMATION);
llSetTimerEvent(0.02);
//yes I know the timer is too fast
//just want to check as many frames as possible here
}
else llSetTimerEvent(0.0);
}
if(change & CHANGED_REGION)
{
llResetTime();
report = TRUE;
}
}
run_time_permissions(integer perms)
{
if(perms & PERMISSION_TRIGGER_ANIMATION)
{
llOwnerSay("Granted permission to animate.");
}
}
timer()
{
if(!(llGetPermissions() & PERMISSION_TRIGGER_ANIMATION))
{
//the script does not have permissions held
no_perm_count += 1;
}
if(llGetAgentSize(avatar) == ZERO_VECTOR)
{
//the avatar is not in the same region as script
not_same_region += 1;
}
key check_root = llList2Key(llGetObjectDetails(avatar,[OBJECT_ROOT]),0);
if(check_root != vehicle)
{
//avatar is not sitting on vehicle
not_sat_on_me += 1;
}
if((llGetTime() > 3.0)&&report)
{
//3 sec after a border cross
llOwnerSay("\nEvents with no permission : "+(string)no_perm_count+
"\nEvents with no avatar : "+(string)not_same_region+
"\nEvents not sat on vehicle : "+(string)not_sat_on_me);
no_perm_count = 0;
not_same_region = 0;
not_sat_on_me = 0;
report = FALSE;
}
}
}
Atomic Infinity
Typical Results -
- Events with no permission : always zero
- Events with no avatar : typically 3 to 7 events
- Events not sat on vehicle : typically 8 to 13 events
In typical results there was always 5 more ‘not sat on’ events than there are ‘no avatar’ events. If I recall, a timer event is likely to throttle at 0.044 seconds per event. If that is correct, then per crossing on average the avatar is not seated for 11 x 0.044 = 0.484 seconds, and the object and avatar are in different regions for 6 x 0.044 = 0.264 seconds.
Extreme results with an unsit -
- Events with no permission : 0
- Events with no avatar : 12 to 75
- Events not sat on vehicle : 63 to 78
In other unsits that became viewer disconnects, the results were lost in the crash. A delayed arrival of the avatar in the new region perhaps makes an unsit more likely.
So it seems re-acquiring permission is not needed, but the script has time available to produce errors because the avatar whom it needs contact with is not present & seated.
I originally thought scripts were stopped in a crossing, but I guess that assumption maybe is wrong. It would certainly be worth testing crossings that
do
stop scripts in 'sat on' objects before separating the avatar - 4 homesteads in a square on the beta grid so you can drive round in circles and through a 4-way corner, to see what happens.Skyler Pancake
Has been noted within the pony community as well, though we're all pretty used to it. It's treated a bit as a joke to see how many crashes you managed to survive to do the route.
Beyond the crashes, I've been having issues with regions just simply not loading? Just big empty hole in the world. Relog will solve the issue, but annoying to have to relog every 10-15 regions. Is this something anyone else has been experiencing?
KyliaDaden Resident
Skyler Pancake Well, that does happen to me sometime, but thankfully Kokua Viewer has "Refresh Scene" menu item that forces a refresh of the visible region. Anyways, I think there's another Canny feedback about this ...
Lisa Hyandi
If you want to investigate in a specific sim please take a look to Quimadra
It is the 3rd time that without any specific reason i got unseated / disconnected or boat becomes unresponsive in that region. And it happens also to many others who race with us crossing that region.
Also tonight our race decided by a crash of the leader there.
We all race for fun ok. not a big drama but frustration is real
.. Please check if that sim is just unlucky or what can be the specific issue that makes it many times worse than any other sim in that area.
Please note another very interesting detail.. We crash when we anter in Quimadra leaving Ooprince. but this happen when this specific cross follows teh same cross in the other direciton
Let me try to explain better:
We enter Oprince From Quimadra and this kind of cross never gives an issue
We turn around Oprince gate and we enter in Quimadra leaving Oprince in less than 30 seconds after the first cros.. And this time we crash very very often (20% of the times?)
This is quite strange.. and let me suspect that there is something different if we cros teh same border twice in a limited time
AWalphaomega Resident
As a creator and scripter of most types of vehicles in SL, I have to say I am extremely interested in this topic. I too have found a consistent degradation of performance in sim crossing over the last several months. This is most evident on roads, but it happens on water and air passages as well. I have done extensive study of this issue and have a few ideas (but no concrete theories as of yet). One of the more compelling bits of evidence points to the massive inrush of http data from all of the high resolution textures as you get in range of them. This does not account for things like strange script errors or bizarre unsits on slow crossings into sims that otherwise are functioning normally. I would like to propose a vehicle roundtable. This is something I would gladly make time for if possible, and would very much like to participate in.
UPDATE - now, based on the current state of the grid on 4/1/2025, I find it is the worst I have ever experienced. This must be dealt with soon!
Lisa Hyandi
Great
Thank you for listening to us and for the live tracking dome
Looking forwardi to the solution
Signal Linden
planned
Philip Linden
We are going to solve this, and agree that these are critical and frustrating problems.
Esmelyn Resident
I was one of the victims of these races. You can see my video within Bianca's race report. I dont understand how I can have a healthy 2 or 3 practice laps.. nothing changes and then half an hour later the race happens and all hell breaks loose. I do all the things asked of me and beyond and this still happens. I have lowered my graphics, I have removed all my mesh and gone to a basic avi.. i even purchased a second internet provider that only my computer was linked to in my house to try and improve connection and communications at my end and yet this still happens.
I spend so much time in SL along with many other users who practice and work hard to be ready and able to race yet these races are no longer fair.. its not the best people win anymore. its whether Second life chooses you to finish unscathed.
This last race I was in a solid podium position only for second life to decide "no.. not today. i think I will award this too someone else." Its not fair on me or anyone else who is kicked out and its not nice for the people who do succeed knowing they got their positions through second life and not through merit.
This is not a complicated request, its very simple.. just make the sims hand over your details in a safe, fast and secure manner.
I am a highly invested simulator gamer inside second life and outside in other games.. DCS.. Sailaway.. Star citizen.. worlds where you can travel for hundreds.. even thousands of miles and not a single glitch in connection. Why then.. why.. is this fundamental and basic need so hard to get right?
Sorry for the rant but I and many others invest their time and energy in this world.. we love it. but right now our time spent is just being wasted
TgBianca Resident
Tuesday the new server software release was rolled out on the Second Life Server and we had a race in our race area with only sims on Second Life Server a couple of hours later. We all were curious, if we will see any improvements.
I am sorry, but i really have to add water into you party wine. You can read my race report including videos here:
The few practice hours before the race, the race itself and the first day after the race on the hotlap course in this same area showed the same number of disconnects, of script errors after disconnects and no noticeable real improvement.
Sorry but i think your plaster stopped the first bleeding a bit, but the leg is still broken and needs still to be fixed.
Load More
→