Second Life Region crossings update

Updated region crossing code on the main grid should improve travelling by vehicle across the main grid

As I’ve noted in recent Simulator User Group updates, the Blake Sea regions were cloned to Aditi (the beta gird) in late July, to give users the opportunity to test regions running on AWS services (“the cloud”). Among the more significant tests carried out (for many users) was for physical region crossings via vehicle.

Initially, things did not go well; it was almost impossible to complete more than two or three region crossings without encountering insurmountable problems – and some users (myself among them) couldn’t even get through a single crossing whilst driving a vehicle. Thanks to the data gathered, the Lab made some updates to the Aditi / Blake Sea region crossing code, and Simon Linden set-up the Blake Sea Challenge so that further data on region crossings could be obtained (see: 2020 Simulator User Group week #31 summary & the Blake Sea Cloud challenge).

Preparing for a high-speed run with my Foilstream with foils lowered…

All of this work resulted in a set of updates to the region crossing code for the Aditi regions, and on Tuesday, August 11th and Wednesday August 12th, these updates were included in the simulator deployments made to Agni (the main grid)¹.

So how are things now working?

Well, first and foremost, it is early days and less than 24 hours since the RC deployment. However, people are already reporting appreciable region crossing improvements with the updated code. While far from a comprehensive test, I took a number of my boats and aircraft out for a a series of runs across a total of 55 region crossings (east to west from Second Norway to Nautilus and around part of Blake Sea, then back again) to see how things faired. The vehicles I tested were:

  • Bandit 50/3 sailing cruiser.
  • Piaggio KV23H Foilstream (version 3.2c).
  • Spijkers MD900 Explorer
  • TBM Kronos (version 6).
…. And multiple regions later, still going at speed without loss of control, and able to orbit camera for photos 🙂

I selected these four as a mix of both medium and high performance craft. Both the Bandit 50/3 and the MD900 made the round trip without real incident. Crossings for both resulted in zero vehicle slewing, with the Bandit (always good on region crossings with 2 avatars on-board) being pretty much perfect throughout, and the MD900 making each crossing with control recovery in about a second, and only very slight camera issues.

The Foilstream was going to be a tougher proposition because of its sheer speed: when running with hydrofoils deployed and full throttle, it can cross a region in 7 seconds, so multiple back-to-back crossings inevitably lead to issues at some point, while even at lower speeds the boat was subject to loss of control on crossings lasting seconds and frequently subject to the camera slewing and becoming locked in the side of the boat. The Kronos is not particularly fast compared to other aircraft, but it is exceptionally manoeuvrable and aerobatic, so complex manoeuvres that cross regions have in the past led to issues of control loss and camera slewing.

Things still can go uncomfortably wrong – if you push too hard, as I did with repeated loops through a region crossing at speed

With both of these vehicles, region crossings were considerably improved, other than when carrying things to extremes.

The Foilstream managed so 25 region crossings at full speed with no real loss of control before I found myself on the sea floor sans boat (compared to about a dozen previously before running into problems  – loss of vehicle, camera slewing), while the only issue with he Kronos came with intentional aerobatics back and forth over a region crossing. In this latter case, I will say that when it did go wrong, it did so quite spectacularly, with total loss of control  and the ‘plane tumbling with no recovery at all, with the map showing it trying to continue forward.

Beyond my basic tests, others have been carrying out tests. One of these is colleague Luca lucagrabacr, who recorded her own tests using a range of craft and vehicles. Wo can catch her results in the video below.

Again, while it is early days, fresh after a restart of the entire grid, etc., so gremlins may still climb out of the woodwork, but on the whole, region crossings by vehicle should generally be a lot smoother and easier. Of course, the code doesn’t mean all region crossings are solved – if you push things really hard, things can still go wrong (as with me and repeated Kronos loops back and forth between regions at high speed.

  1. For clarity: this is a code update to the simulators within the Lab’s co-lo data centre, it does not mean Agni regions are now running in the cloud.

SL project updates week 33/2: server recap, inventory, region crossings

Le Botanique, Mirriam Brown; Inara Pey, July 2014, on FlickrLe Botanique, Miriam Brown, July 2014 (Flickr)

I’m busy playing catch-up due to a number of things going on at the moment, so my apologies for late-running reports. The following notes were taken from the Server Beta meeting of Thursday August 14th.

Server Deployments week 33 Recap

  • On Tuesday August 12th, the Main (SLS) channel was updated with the server maintenance release previously deployed to the RC channels in week 32, so placing all four channels on the same simulator version
  •  There were no RC deployments for the week.

HUDs Detaching / Reattaching Following Teleport

Following the week 32 report on HUDs detaching / reattaching following a teleport and issues with attachments scripted to use llDetachFromAvatar to detach on a region change being reported as “worn on invalid attachment point” by the viewer, JIRAs have been raised on both issues (BUG-6925 and BUG-6908 respectively). Maestro Linden has been looking into both, with mixed results.

Maestro has difficulties in reproducing the HUD detaching / reattaching issue (BUG-6925) and so is working from logs supplied by the reporter. However, one line of thinking is that higher ping rates to the server might be indicative of the problem – those who have high ing rates (and those “longer” update times seem to be more readily able to reproduce the issue than those with lower ping rates.

The belief at the lab is that the BUG-6908 issue is likely to be a race condition, and investigations are continuing.

Gestures, Calling Cards and Region Crossings

During the discussion about BUG-6925, Maestro pointed-out that having a large number of active gestures associated with your avatar might be a contributing cause of region crossing issues. This is because the information on each active gesture has to be handed-over from one simulator to the next, and this might slow things down / interfere with things, possibly exacerbating things like HUDs dettaching / reattaching during a region crossing, etc.

While there was a degree of uncertainty as to whether it is the case or not, Calling Cards might also contribute to region crossing problems as they are updated between regions with the online / offline status of other avatars. Simon Linden is best placed to speak to whether this is the case, but he is currently on vacation.

Large numbers of active gestures (and Calling Cards) can also slow-down the log-in process (hence the often-given advice to delete unwanted Calling Cards from inventory).

 Inventory and Inventory Updates

A correlation between large “flat” inventories (i.e. inventories with relatively few folders beyond the system folders,  and each folder containing a lot of items) and log-in issues has been recorded. Oz Linden’s recommendation to reduce such issues is to have a relative deep tree of folders, with each folder containing fewer items.

As the inventory “skeleton” (which contains your inventory folder hierarchy) is only fetched by the viewer when you log-in, “flat” inventory structures don’t impact regions crossings. However, if you do feel you are experiencing a long log-in period, and you have a large, relatively flat inventory structure, you might want to consider re-organising things and seeing if that helps to improve matters.

A forthcoming viewer update, STORM-2034, contributed by Jonathan Yap, will provide support for “older than” inventory filtering, allowing users to filter their inventory either before or after a given age. This should make locating older inventory items a lot easier when it comes to wanting to delete or box items which are no longer used. There’s currently no ETA on when this change is liable to appear, but there is another Snowstorm viewer iteration due, so it might be in that, depending on the code’s current status.

The existing inventory filter options (l) and the proposed update to the time-based filtering option (r)
The existing inventory filter options (l) and the proposed update to the time-based filtering option (r)

Other Items

Avatar Bakes and  Rigged Mesh

A question was asked at the Server Beta meeting on whether it would ever be possible to apply to other objects, which quickly focused-down on using them in conjunction with rigged / fitted mesh. Responding to the question, Maestro Linden said:

It would be cool if you could stack layers of diffuse textures on objects, but it would be a pretty big project. Hmm. I guess that would depend on how it’s implemented … If you just had a way for an attachment to reference its owner’s currently baked texture, then that may not be too difficult, but I think that if you were to say “any object face can have multiple textures, which use the baking service, such that you can have up to ~150k baked textures in a region”, that would be a whole other beast :).

A suggestion was made to limit the number of bakes that could be applied, in the same way as texture layers are constrained on the avatar at the moment, prompting Maestro to agree, “if the object faces are just referencing the same textures which are already baked on an avatar, you could even implement that as a viewer-side change: ‘if object diffuse texture is $magic_uuid, render its owner’s upper-body baked texture on it (or maybe default to grey if the bake is unavailable)’.”

Avatar bakes are currently limited to 512×512. Whether that would be regarded as sufficiently high enough for use on rigged mesh is open to question. n the meantime, a JIRA proposing something similar, aimed at the removal of scripted appliers (BUG-5893) has already been triaged and accepted by the Lab for further investigation.

SL projects update week 48: region crossings, scripted camera and region restarts

Server Deployments week 48

As this is Thanksgiving week in the USA, it is a code freeze week with no scheduled deployments for the grid. Deployments will resume in 49.

It was a quite Simulator UG meeting in terms of news from LL due to this being Thanksgiving week (image: stock)
It was a quite Simulator UG meeting in terms of news from LL due to this being Thanksgiving week (image: stock)

SL Viewer

There are no planned RC releases or updates  for week 48, again because of the Thanksgiving code freeze.

Oz Linden is, however, working on getting another maintenance RC together in the near future, although it’s not clear exactly what this will contain at this point in time.

There have also been reports of issues with test versions of viewers built using the latest Sunshine External repository (the SSA “polish” code and AIS v3). The exact cause of the problems is not known, but it is leading to a high number of Current Outfit Folder mismatch issues on Windows. A request has been passed to the Lab to check the automated build process in order to help ascertain if there is a problem in the code, or whether an issue in merging the code is causing problems. These issues don’t affect any released versions of viewers, only those using the latest SAA / AIS v3 code for testing purposes.

Default Object Permissions

A number of TPVs include the ability to specify the default permissions applied to a new prim object (cube, cylinder, torus, etc.) on creation. A similar capability is being developed for the LL viewer (STORM-68) by Jonathan Yap, a long-time contributor to the viewer. However, this work also requires updates to server-side  capabilities, and Andrew Linden is now looking into this, and at the moment is specifically trying to figure out how to propagate the default perms through teleports and region crossings.

Other Items

Region Crossing Issues

The three RC channels are all running the same simulator version, which includes a fix for “Sim crossing on vehicle fails when parcel at opposite sim border is full.” (BUG-4152). Describing the issue at the Simulator User Group meeting on Tuesday November 26th, Simon Linden said, “The server was doing a parcel check at the wrong location … you’d cross, and at one point it would check a parcel based on the new region coordinates in the first region.   If that happened to be a full parcel, it failed.” This issue has been reported as occurring on Main channel regions as well, under a variety of  reports including SVC-8007. As such, it is hoped that when the package currently on the RCs is promoted to the Main channel in week 49, these issues may also be rectified.

In the meantime, and to test whether the fix may work for SVC-8007, the mainland region of Epirrhoe has been moved to the Magnum RC to allow vehicle crossings to be tested between it and the neighbouring region of Jodis, which has been a crossing which has experienced repeated issues with SVC-8007 for the SLRR.

llSetCameraParams([CAMERA_DISTANCE, x])

Many vehicles of all types in SL use llSetCameraParams to establish a “follow camera” which allows the vehicle to be effectively guided by the driver / pilot.  However, there has been a long-standing issue the CAMERA_DISTANCE  rule, which is clamped to distances far shorter than draw distance. This can make it next to impossible to create a scripted follow camera for very large vehicles such as realistically sized spacecraft, airships and ships.

Clamping with CAMERA_DISTANCE can lead to issues when trying to script a follow cam for very large vehicles using
Clamping with CAMERA_DISTANCE can lead to issues when trying to script a follow cam for very large vehicles using llSetCameraParams

The original JIRA (SVC-3499) was closed as “Won’t finish”. However, commenting on the matter at the Simulator User Group meeting, Andrew Linden said:

If we were to expand the clamp limits then some poorly written scripts will change behaviour. How much do we care about breaking such poorly written scripts? And… I wonder why it was clamped so tight? It would be nice to ask around to see if anyone remembers why some limits were set … Well, it would be possible to expand the distance limit and test to see how it works with different limits. If nothing breaks too bad, then perhaps we could ship it.

A new BUG report has been filed as a feature request for this to be looked at (BUG-4594), which is likely to be looked-at the next time feature requests are sorted, and quite possibly passed to Maestro Linden.

Region Restart and Visibility Issues

An unusual issues has been reported which appears to be related to region restarts and visibility, but it only noticeable on regions which have multiple neighbours, all of which are restarted at more-or-less the same time (within about a minute of one another). The problem can be broken down into a number of related points:

  • Observers are standing in region A, which is surrounded by regions B, C, and D – all of which are restarted at pretty much the same time
  • Following the restart, there is a high probability that some or all of regions B, C, and D will not be visible to those observers on region A (which was not restarted), and they show-up as red on the mini-map – something which has been confirmed on both the SL viewer and Firestorm
  • However, anyone entering region A after the restart will see all of regions B, C, and D as expected. Similarly, anyone on region A at the time the other regions restarted can resolve problems by relogging
  • Those observers who were in region A at the time the surrounding regions were restarted are able to fly into any of them which are showing as red on the mini-map, and although nothing physically renders for them, they will experience object collisions. Furthermore, it is possible to exit the “red” regions on the mini-map and fly into the void where no regions actually exist.

In tests with a specific set of regions, the above issues occurred in 8 out of 12 tries. That there is a unique problem with the regions on which the tests were carried out has been pretty much discounted. Whirly Fizzle, who has been poking at the issue with a number of people, provided a screen capture show how her alt managed to fly through a “red” zone and into the void where no region exists.

Following a region restart, Droom is shown in red on the mini-map, to observers located in Mote (lower left on the mini-map) at the time of the restart. However, these observers were able to fly through Droom, although nothing would render for them (but collisions would occur), and then into the void space where no region exists (image courtesy of Whirly Fizzle, click to enlarge)

Commenting on the matter, Simon Linden said, “It sounds like it’s getting confused and not realizing the old connection went away …  I’d bet on the timing.”

Agreeing with this point of view, Andrew added: “If Region A thinks your viewer can already see into Region B, it wouldn’t initiate the connection,” hence why relogging would appear to fix the issue for those experiencing the problem and those arriving in the region after those around it have been restarted: as you arrive in the region, it (re-)initiates the connection between the  viewer and the surrounding regions. This is also why people encountering the situation can enter void areas where no regions exist, as Andrew also explained: “The region you’re on expects the other region to inherit your avatar, o it lets you walk beyond the region boundaries until the other region picks you up. But if the exchange never completes, you get to walk around outside of the region boundaries for a while.”

This can be seen in the image Whirly supplied: while she is clearly in a void space where no regions exist, the title bar of her viewer still reports her as being in Mote (her “region A” during the test), because the “hand-off” between Mote and Droom (shown in red on her mini-map) never completed.

Andrew recently fixed another issue related to connections to neighbouring regions, and has offered to look into the matter himself to find out what is going on and how it can be rectified.

SL projects update week 40 (2): SSA, group ban list, upcoming bug fixes

Server Deployments – Week 40 Recap

As always, please refer to the week’s forum deployment thread for the latest news and updates.

  • There was no Main channel deployment in week 40
  • The three RC channels all received the same update, comprising a fix for a bug affecting group notice delivery to large groups whereby the notice randomly fails to reach some group members; a new JSON_DELETE option for llJsonSetValue(); interest list preparatory work for more correct sort order during scene load – release notes (BlueSteel).
Having fun at the Server Beta Meeting
Having fun at the Server Beta Meeting

Upcoming Bug Fixes

There are a number of upcoming server-side bug fixes due. It is hoped all of these will reach one or more RCs in week 41. However, this depends on them passing QA, etc. The fixes include:

llGetCameraRot() Issue

There has been a series of bug reports from across the grid being raised about problems with camera updates when operating in Mouselook with scripted objects using llGetCameraRot() (HUDS, weapons, etc), and which may also affect scripted objects using llGetCameraRot()  when in 3rd person view. Commenting on the issue at the Server Beta meeting, Maestro Linden had this to say:

There were a few bugs reported today [Thursday October 3rd] about llGetCameraRot() being ‘lazy’ about updates, which we’ve been able to confirm. If you’re aiming in mouselook and make subtle adjustments, the llGetCameraRot() rotation doesn’t change (but should) …

In any case, Andrew took a look at the bug and found the cause; one of the interest list changes affected how often the simulator updates the reported camera rotation value. He had added some hysteresis so that only large changes that would affect your interest list (cone of objects you’re seeing) would cause the value to update, not realizing that it affected llGetCameraRot(). There’s a fix pending, so we should hopefully have that ready for the next rolls.

Group Access to Parcel when “Sell Passes” Set

I reported on this issue in my week 39 updates. Essentially, if a region is set to group access and to “Sell Passes”, Group members ended up unable to enter the parcel at all. The problem was accidentally introduced with the recent parcel access updates, and while not widespread, is still recognised as a pain for those using the option.

Region Crossing Fixes

There are two upcoming fixes for region crossings.

The first is a fix for “‘Ghost’ avatars and vehicles sometimes appear to an observer at the sim border”. This is caused by an avatar or vehicle making a region crossing just at the limit of the observer’s  draw distance, so the simulator that the vehicle / avatar was leaving didn’t send an ObjectDelete message, since it figured the destination region would handle future object updates. However, as the observer’s viewer wasn’t connected to to the destination region, no update would be received, leaving the “ghost” image in view (“touching” it would cause it to vanish).

The second is a fix for “Vehicles which exit a region with a passenger are incorrectly autoreturned and ‘ghosted'”.  This is related to a vehicle being rezzed in a region with auto return set, and then “loitering” in the area before coincidentally trying to cross the region boundary at the time the auto return delay expired. during the crossing process, the vehicle would appear to be unoccupied to the region it was leaving – and thus be returned to the owner. In addition, the vehicle’s collision body would be “left behind” (marked as “pending delete” without actually being deleted) which could then be run into as a “ghosted” object by other vehicles.

Currently, a region restart fixes this issue.

SL Viewer Updates

There has been no promotion of an RC viewer to the de facto release viewer so far in week 40. The Maintenance viewer (support for new particle capabilities; automatic avatar render limit and feedback system) gained a further update on September 30th, with the arrival of version 3.6.7.281793.

Mac OSX 10.6 Viewer roll-back

As reported here, due to the recent Cocoa updates causing regression for users on Mac OSX 10.6, the Lab has opted to roll-back all users on that operating system to version 3.6.4.280048 (August 20th, 2013).

Interest List Viewer

It’s now believed that the Interest List viewer is around two weeks from appearing as either a project viewer or an RC viewer.

Continue reading “SL projects update week 40 (2): SSA, group ban list, upcoming bug fixes”

SL projects update week 39 (2): Server, viewer, region crossings

Server Deployments – Week 39

As always, please refer to the week’s forum deployment thread for the latest news and updates.

  • On Tuesday September 24th the main channel updated to the server project that was on Magnum last week, with the llXorbase64 (see my week 35 (2) update ), a number of JSON updates, the nerfing of recursive rezzing (outlined in my week 35 (1) report), a parcel access update (see below) and more – see the release notes for details
  • On Wednesday September 25th, all three RV channels (BlueSteel, LeTigre, Magnum) received the same update package as deployed to the Main channel.

Parcel Access Update Bug

At the Server Beta meeting on Thursday September 26th, Maestro revealed that the parcel access update, designed to enable users who are on a parcel’s “Allowed Access” list now correctly bypass other parcel restrictions (such as “Payment Info On File”) when entering the parcel, introduced an unexpected bug. He it as:

If you have a group-owned parcel, and the parcel access is restricted to group members, *and* “sell passes to..” is set, then group members can’t access the parcel, which isn’t good. My guess is that nobody noticed in RC because “sell passes to” isn’t widely used.

The classic behaviour was this one motorcycling sim had it set up; you could either join the group for L$300 and have permanent access to their roads, or alternatively pay L$100 for a one time pass to visit … With the bug, even the group members couldn’t access (though oddly they weren’t prompted to buy a pass either – entry just failed). It may have been that the viewer expected the classic behaviour, so didn’t prompt about a pass. Anyway, we do have a pending fix for the issue.

Maestro Linden's new meeting venue (complete with materials), which saw its debut at the Server Beta meeting on Thursday September 26th.
Maestro Linden’s new meeting venue (complete with materials), which saw its debut at the Server Beta meeting on Thursday September 26th.

Week 40 Deployments

While the final decisions on deployment packaged are not made until the start of the week in which they are due, Maestro Linden gave a hint of some of the items liable to see the light of day in week 40 (week commencing Monday September 30th)

  • A further LSL update for JSON support, which will see JSON_DELETE added as an option to llJsonSetValue() and allows you to delete an element directly
  • A fix for a group notice bug which causes a notice (possibly only in some groups, it’s not entirely clear) randomly failing to reach some group members

Commenting on the latter, Simon added, “That group one is kind of minor. There still seem to be issues with groups, even with this fix, but it may help … Group notices have gotten more reliable lately, thanks to Monty’s http work, I think, but I’m still hearing of notices getting lost sometimes, or the sender not getting one.”

Maestro also confirmed that there is a separate bug related to offline notices failing to reach people’s e-mails, with some at the meeting reporting they haven’t received any off-line notices for the past month.

SL Viewer Updates

On Wednesday September 25th, the Lab launched SLShare, and with it introduced a new RC viewer – version 3.6.7.281331 – with the new OPTIONAL share with Facebook capabilities.

The four tabs of the new SLShare floater, allowing people to share their SL times via their Facebook account if they so wish
The four tabs of the new SLShare floater, allowing people to share their SL times via their Facebook account if they so wish

Continue reading “SL projects update week 39 (2): Server, viewer, region crossings”

SL project updates Week 37 (1): server releases

Server and RC Deployments

As always, please refer to the week’s forum deployment thread for news, updates and feedback.

In a change to the usual server-side deployments, the Main channel and all three RC channels have had their deployments and restarts made on Tuesday September 10th. As a result, there will be no RC restarts on Wednesday September 11th.

The reason for the single pass – Main channel first, followed by the RCs – is to apply updates server-side relating to recent Vivox service maintenance.

  • Main channel: received an update related to the recent voice service maintenance and no other changes – release notes
  • BlueSteel and LeTigre: received a new maintenance package, comprising:
      • A fix for an issue where an avatar sitting at high altitude may appear to be located at 0,0 on both the world map and mini map (BUG-3332)
      • A fix for “llReturnObjectsByID breaks on string uuids”
      • Fixes for a number of JSON function issues:
    • Nerfing of recursive rezzing. Again, this was outlined in my week 35 (1) report. Under the new code, the copy of the original object will inherit the temp-on-rez and parcel time of the originating object and so be returned at the same time
    • Crash mode fixes
    • The update related to recent voice maintenance
    • These channels also no longer have Monty Linden’s HTTP updates on them).
  • Magnum remained on the HTTP update package deployed in week 36, and also received the update related to the recent voice maintenance.

Region Crossing Update

In addition to the updates listed in the release notes, Bluesteel and LeTigre also received a threaded region crossing update. This is not expected to have a major visible improvement on vehicle crossings, or as Andrew Linden put it at the Simulator User Group meeting on Tuesday September 10th, “It doesn’t mean the death of region crossing problems, but the data streaming on the way OUT of the region is now threaded, which doesn’t make the crossing any faster, but may reduce lag spikes as witnessed by everyone else.”

Kelly Linden added, “The threading change Simon mentioned moves vehicle serialization only into the same thread as agent serialization to fix a rare server crash mode due to a race condition serializing scripts in some very specific cases.”

SL Viewer Updates

On Monday September 9th, the Cocoa release candidate viewer was promoted to the de facto release viewer – version 3.6.5.280370 (release notes). This currently leaves just the materials updates as a release candidate viewer, although further viewer releases (either RCs or project viewers) are expected soon.

Group Ban Lists

Baker Linden is finishing-up the work prior to it going to RC (server and viewer), which is still a “few weeks” away. However, he’s planning / hoping on having the server code on Aditi by the end of the month, for which a “test viewer will be provided”.

Anti-griefing

Commenting on the update to the Auto-return capability to nerf recursive rezzing, Andrew indicated he took the discussion which followed his initial raising of the subject in the week 35 Simulator UG meeting back to the Lab, where there was discussion about limiting the functionality to “unattended” self-rezzing objects (i.e. those for who an owner is not present in the same parcel). He went on:

However after an internal discussion we decided to not open up that exception since it causes inconsistent behavior: different autoreturn times depending on whether the owner is present or not can lead to confusion, and also it would bypass the spirit of the autoreturn feature which parcel owners are expecting — that objects get autoreturned.

He went on to say that there is no single project at the top of his list,  and that the anti-griefing work is one of a number of projects he’s juggling with at present.