LL announce “first set” of advanced creator tools now live

Yesterday, as I reported, Linden Lab rolled-out the first pass of the advanced creator tools across the main release channel for the grid. These are the functions that lead to an outbreak of griefing when they were first rolled-out on the Magnum Release Channel back in June.

Since then, the code has been revised – and now includes a “master switch” that allows Linden Lab to disable the functionality should anyone try to get up to mischief using the tools. The code was in fact enabled on both LeTigre and BlueSteel last week without major incident, and so the code was rolled-out to the main channel in an enabled mode on July 31st.

Today, LL has formally announced this initial release of the tools via a new blog post. This initial release comprises three new functions:

• llAttachToAvatarTemp (integer attach_point) — allows objects to be attached to your avatar / screen without any corresponding inventory record being created for the item, which will disappear on being detached or on disconnecting (teleporting) from the region in which it is active
• llTeleportAgent (key agent_uuid, string lm_name, vector landing_point, vector look_at_point) — this allows a script to teleport an agent to either a local coordinate in the current region or to a remote location specified by a landmark (the landmark must be contained within the inventory of the object using the teleport script)
• llTeleportAgentGlobalCoords (key avatar, vector global_coordinates, vector region_coordinates, vector look_at) – this will teleport an agent to to a specific point within a region, with the agent facing a defined direction (vector look_at) on arrival.

These functions should allow a range of new experiences to be created, some of which are demonstrated in the Linden Realms game, wherein the attachment option is used to attach the game HUD to avatars and the teleport options are used in conjunction with things like the rock monsters.

Linden Realms HUD (top left): attached using the full experience tools

The functions are also designed to be used with a new permissions system, which has yet to be rolled-out across the grid. This means that until the new permissions are rolled-out, some of the functions will not operate as transparently as they eventually will. For example, rather than something like a HUD being automatically attached to your avatar (as is the case with the Linden Realms game, which does use the new permissions system), you will be prompted to accept the object first (thus making you the owner) in order for it to attach.

It’s not currently clear as to when the new permissions system will be rolled-out, but with the “master switch” at their disposal, Linden Lab are confident that the kind of issues that marred the June RC roll-out can be avoided.

The official blog post includes a video from Torley.

Land Impact change: “Is it a prim? Is it a sculpt? It’s a…”

Update May 14th: Speaking at the Simulator User Group meeting on May 1tth (transcript), Falcon Linden confirmed that under the new mesh accounting system, sculpts will be capped at 2: [16:43] Falcon Linden: Namely that sculpts will be capped at 2.0 streaming cost, not 1.0. (Note, that’s a CAP, so if they were less than 2.0 in new accounting before, they’ll still be less than 2.0).

Update May 5th: Nalates carries a very in-depth piece on the proposed Land Impact changes and pathfinding in general, written as a result of recent UG meetings.

Nalates Uirriah caries more on the proposed Land Impact changes which look as if they will be implemented as a part of Pathfinding – and the news carries something of a possible warning.

While the new accounting system promises to offer benefits with regards to prims, and help encourage scripting efficiency within rezzed linksets, just how it will impact sculpties is unclear.

Sculpts have always been something of a problem-in-waiting since their introduction. Like complex prims (tori, etc.), sculpts were given the same “impact” cost as “regular” prims under the old accounting (prim count) system. So wither you rezzed a cube, a torus or  sculpt, they all had an impact of 1. However, like mesh, sculpts are more complex than regular prims and could be said to be somewhat more complex than tori in terms of their download weight due to the need for a texture and a sculpt map to be downloaded and applied to the object.

When Land Impact (initially PE, or Prim Equivalence at the time) was introduced, sculpts continued to be treated as prims – although from comments made at the time, it was evident that, at least on technical grounds, some Linden Lab staff were unhappy with this. However, it is hard to see how the accounting system could have been adjusted to account for the extra “cost” of sculpt without causing mass upset and potentially some breakage across the grid.

The new accounting system that has been proposed, and was revealed in part last week by Falcon Linden as Nalates reported, is specifically to be applied to “legacy prims”.  However, whether sculpts are to be classed as “legacy prims”, it would appear, is still a matter to be determined within the Lab.

Speaking at Monday’s Content Creation Group meeting, Nyx Linden had the following to say on the proposed changes:

“The proposed streaming cost cap, if implemented and deployed (nothing is final until it is released), would affect legacy prims – streaming cost of meshes would not be capped. It would affect legacy prims even if they are linked to meshes (and thus fall under the new accounting system). Please note that this is a proposal, and we reserve the right to change any part of it if necessary before release.

“Whether sculpties will be considered “legacy” or not in this context is not 100% determined yet. Since they do require more texture data to display properly, we need to carefully consider exactly how to weight them. The proposed server cost change would be independent of prim type. It’s still in the early stages so bear with us if we end up needing to make tweaks between now and release, but we wanted to let everyone know that changes would be coming.”

After noting that the new accounting process will also be used for linksets using the new physics shape types as well as those containing meshes, Nyx concludes:

“I don’t want to speculate as to the exact status of sculpties under the new streaming cost rules, as we’re still discussing it internally, but your concerns are being considered when looking at the numbers and algorithms.”

The problem here of course is that LL are once again in something of a corner. Altering the impact cost of sculpts is going to have potentially far-reaching effects which are unlikely to be seen as positive. It may even negate the changes being made to llVolumeDetect(TRUE), given this hack is often used in linksets involving sculpts. At the same time, and has been pointed out by Chalice Yao, sculpts could be considered tori, so treating them as legacy prims would make the new accounting system even more worthwhile.

Similarly, Qie Niangao points out that currently, the LI calculations are somewhat biased with regards to mesh:

Yes, but on the other hand, the LI calculations are terrifically generous to Mesh content for exactly the reason that Nyx (bizarrely) mentions as a problem with sculpties: extra textures. Although it’s true that a sculpt necessarily involves a sculptmap as well as a (single) surface texture, a single Mesh can have eight 1024×1024 textures and still get a 0.5 land impact.

It is clear that things are in a state of flux – and that LL are considering options and concerns. Overall, the proposed changes are being regarded as being favourable to all at this time where script costs are concerned. Whether this remains the case will be dependent on what – if anything – needs to be changed in order to handle sculpts.

Related Links

• Pathfinding: llVolumeDetect(TRUE) and Land Impact changes (this blog)
• Sane accounting for mesh, llVolumeDetect hack and Pathfinding (SL Universe)
• SecondLife News week 18 (Nalates Urriah)

Pathfinding: llVolumeDetect(TRUE) and Land Impact changes

There are a couple of changes in the works relating to the forthcoming arrival of Pathfinding in Second Life.

llVolumeDetect(TRUE) Exploit

In the first, the use of llVolumeDetect(TRUE) to create partially phantom linksets will no longer work. Always something of a system exploit / hack, this approach has nevertheless seen widespread use across SL in buildings and vehicles. So much so that when it was discovered that the hack no longer worked in the Pathfainding test regions, it was initially reported on the JIRA as a Pathfinding bug (Pathbug-69).

However, as Falcon Linden points out in the “bugs” JIRA:

Thanks for your interest and passionate comments. First, let me address one of the root issues here: reliance on undocumented behavior that is known to be a bug. I realize that there are many cases of this in SL. I also realize that all of us, as game developers either in RL or SL, will do whatever it takes to implement a feature we want, even if that means exploiting known bugs or idiosyncrasies. The problem is that continued development of a platform (e.g., SL) often precludes backwards compatibility, particularly when systems have exploited “micro details” of the platform. 

Which is not to say Linden Lab is unsympathetic to the issue. Far from it; as in the same statement Falcon goes on to explain:

All of that being said, we as SL developers continue to try to preserve backward compatibility where we can. In this case, I have been able to find a compromise between new features and existing content. Here’s how it will work:

1) If a linkset uses the hack and also uses new accounting (aka mesh accounting or land impact), the first time it is rezzed on a pathfinding sim the hacked prim will be set to physics shape type none. Since the linkset already uses new accounting, this will not negatively impact land impact (in fact, it might reduce your land impact). It may affect a small amount of content that relies on link number of higher numbered prims in collision events by way of llDetectedLinkNumber()

2) If a linkset uses the hack and does NOT use new accounting, the relevant prims will be modified such that they collide only with the terrain. Other than that, behavior should be unchanged. This may impact some land vehicles that previously had hacked phantom prims which did not collide with the terrain.

3) No new linksets can be created that use the hack, and any linking or unlinking event (other than seating an avatar) will remove the hack on existing content.

This should address most of the concerns here. In the future, to create content where only some prims are involved in physics collisions, you will have to use the physics shape type feature.

Ergo, while the arrival of Pathfinding will herald a closure of the llVolumeDetect(TRUE) exploit / hack, LL are attempting to ensure that the impact of the closure in terms of content breakage will be minimal – if it is noticed at all.

Changes to Land Impact Calculations

Coupled to the above change is the announcement that Linden Lab is looking into changing how Land Impact is calculated as a part of the overall Pathfinding roll-out. Nalates Urriah was the first to break the news on the proposal, which  will bring a greater degree of granularity to Land Impact increases.

Under the current system, adding scripts to linksets can result in a sudden (and sometimes dramatic) leap in the Land Impact value. With the proposed changes, this will no longer be the case, with changes resulting from the use of scripts being more gradual. Speaking at the Simulator User Group meeting attended by Nalates, Falcon Linden explains the proposed changes thus:

[17:00] Falcon Linden: Changes to Land Impact that you’ll actually like for a change!
[17:01] Falcon Linden: We’re changing streaming cost for prims to be capped at 1.0 and we’re changing server weight to be: 0.5 * num_prims + (0.25 * num_scripts) but capped at num_prims
[17:01] Falcon Linden: so instead of going from half prim count to prim count by adding one script, it will be a more gradual change to encourage fewer scripts
[17:01] Falcon Linden: right now it’s not capped 
[17:03] Falcon Linden: okay
[17:03] Falcon Linden: here we go
[17:03] Falcon Linden: I have here a linkset of three distorted torii
[17:03] Falcon Linden: The two child prims are shape type NONE and the root is convex hull
[17:04] Falcon Linden: under the current scheme, its download weight is 13.7, its physics weight is 1.6 and its server weight is 1.5
[17:04] Falcon Linden: total LI 14
[17:04] Falcon Linden: under the new scheme, download weight will be 3, the other weights will be the same in this case, and the overall LI will be 3
[17:05] Falcon Linden: if I add one script to it now, the server weight will go from 1.5 to 3.
[17:05] Falcon Linden: In the new scheme it will go from 1.5 to 1.75.

It should be noted that the latter change is still very much a proposal, although it does appear that it is more than likely to go ahead, given it is beneficial to both Pathfinding and the platform as a whole.

With thanks to Nalates Urriah for her report on the Land Impact changes, and also to Innula Zenovka.

Code change impacts RLV functionality

Update 12th March: As can be seen from the comment from Trinity below, Brooke Linden has responded to concerns over this issue, and has confirmed that the code causing it will be rolled-back from LeTigre and BlueSteel this Wednesday (RC channel release window) and won’t be re-deployed until the problem is fixed.

Kitty Barnett reports via JIRA SVC-7748, that functionality related to the InventoryAPI maintenance project adversely impacts the widely used RLV / RLVa functionality within Second Life.

RLV provides a means by which, and under controlled conditions (the user “opts-in” to the process by clicking an acceptance button), a folder is created within the #RLV folder under MY INVENTORY. Items are then delivered into the new folder, wherein a script runs to attach the items to the recipient avatar.

While this functionality does have a direct use within the BDSM community, it can have uses elsewhere as well.  However, changes rolled-out to the BlueSteel and LeTigre RC channels this week as a part of the InventoryAPI maintenance project, have inadvertently broken the functionality – the required redirection to use #RLV doesn’t occur and the associated script fails – hence JIRA SVC-7748.

The degree of impact on RLV is debatable. As Marine Kelley states within the JIRA:

On a positive note, if LL decides not to do anything and leave things as is (i.e. in a broken state), the RLV could simply check what’s coming into the “Received Items” folder and move it automatically under #RLV if the name matches. This would be transparent to the user and would overcome this breakage. 

Nevertheless, it would be preferable for LL to ensure the functionality isn’t broken in the first place (as Marine herself goes on to state).

A potential problem here is that, despite Kitty’s own efforts to point out that Received Items itself is not the problem per se, many of the comments appearing on the JIRA are further critiques of Received Items rather than a discussion of the problem as identified by the JIRA itself.

As strong as feelings are around the subject of Received Items, what is more important here is that functionality that is key to a range of user expectations / desired experiences has been inadvertently broken within LeTigre and BlueSteel, and there is a risk that this could become more widespread if the fix is rolled-out beyond these two RC channels. As such, it is important that LL hear, read and understand the core issue itself (i.e. via use-cases where the update breaks things), in order for them to try to correct the matter.

Given it is the weekend, it will likely be a while longer before any response on this matter is heard from LL – which also gives people more time to submit specific examples on the issue that outline the problem. It’s also worthwhile pointing out that LL are prepared to reconsider proposed actions – as has been demonstrated around the concern relating to llGetAgentStatus (which Oz has indicated is on-hold as a result of the number of clear-cut use-cases received), and have shown a willingness to re-think elements of Received Items based on constructive feedback from users.