Cool VL Viewer forum

Hi Henri,

Just found out that the standard SL viewer interprets SLURL links and shows a clickable 'named' link instead of the full string. I tested on Marines latest, since that was handy and very close to the basic LL version. We still see the normal fully expanded link in Cool. I would normally say who cares... but OpenCollar is now using this in the menus. so if you pull up a an OC 4.1 menu and select the 'hug' animations, you get a huge list of fully expanded list of slurl's instead of names. So, my personal thought about all this aside, is it even possible to make the interpreter work in Cool, or is this based on a deeply entrenched and maybe proprietary LL feature? Seems like a pain in the butt...

quick example of what we seen in Cool:
secondlife:///app/agent/311a5bc3-9cef-4870-b332-3c04aa4e7283/about

How it appears in Marines viewer (LL):
Lycia Undercroft

Thanks,
~Lycia

This is not a bug in the Cool VL Viewer but its expected behaviour. Whenever such an SLURL is encountered in chat text, the viewer first checks for the avatar name cache to see whether it finds a corresponding name for the UUID in the SLURL. If so, it immediately replaces the SLURL with the name of the avatar. If it does not, it simply prints out an SLURL that you can click to get the profile of the corresponding avatar and, concurrently, the viewer requests the avatar name for that UUID to the server, so to be able to replace the SLURL with the avatar name whenever it will be printed/used again (meaning that if you issue two commands that print the same SLURLs, the second time, the names will be seen, provided the server replied before the second command is issued).

LL's viewer v3 (and TPVs that use its code base) is using a "trick" to replace the SLURL *after* it was printed, with the name *once* it got fetched. The printed SLURL/name is in fact a full text UI widget structure, (which uses a lot of memory when compared to the plain text link used by the Cool VL Viewer) and a callback that gets invoked whenever the name fetch completes, so to replace the SLURL with the plain name. While I could implement such a feature in the Cool VL Viewer, it would slow down *all* the text UI widgets (and there are really many !) and increase the memory consumption, for a feature that is barely ever used, but for a few rogue scripts... Sorry, but I don't intend to do this.

Now, I so far only saw such SLURLs used in scripts' chat/IM text, not in their menu (that's really lazy scripting... I mean, these scripters never heard about the llKey2Name() and llGetDisplayName() LSL functions ?)... I could add the same feature for script menus, if it's what you meant.

Yes this is clearly not a bug in Cool, hope I did not imply that it was. Also, I was afraid the implementation would be something like you described... a massive sluggish API (which turned out to be the full text widget you explained). Did not expect the LL implementation to be as much of a 'trick' as you described though... So.. ugh. I would never script something like that menu text personally, it seems like enormous overhead just for a name... Anyway, I think if you could get the slurl's converted back into names for the menu text like you described, it would solve the real issue of not understanding what the options being presented are.

I have a fear we will see more of this as the new OC code gets out further into the environment, it probably gets hijacked for all sorts of things.

if you want to take a look at the behavior, i would recommend getting one of the new OC collars from the temple and just clicking through to the hug menu so you can see how they are attempting to display names these days. After that you could decide if there is a feature worth implementing for it. I would send you one of the collars so you wouldn't have to bother with the trip, but oddly the artwork these GPL2 scripts are in is all non-trans... go figure.

Thanks for explaining!
~Lycia

The SLURLs to name translation in script menus is ready for next release; it is also a full translation (including for names not yet in cache when the menu is pulled down), done via a callback to the notification class itself so that there is no need to impact the UI at the text elements level like LL did with viewer 3...

I also improved the chat translation, here again via a callback at the chat floater level: lines containing name SLURLs that cannot be immediately translated are now slightly delayed (1 second delay, or when all names get resolved, or until another chat line arrives, whichever occurs first) before being printed, reducing the occurrences of untranslated name SLURLs.

Wow Henri, that was really quick! Sounds like a good fix too! Looking forward to trying it out on your next release. Thanks!

In fact, I wrote an even better code... I made it so that it is now possible to replace text in the chat history coloured-text editor (which was not possible initially, because each "segment" that holds the offset to the start and end of each coloured/URLized text segment were not updated by the replace text command). As a result, I do not need any more to delay chat printing when SURLs appear in the text, and I can replace the name SLURLs in the callback, meaning 100% of the SLURLs get replaced with names in the end...
I also implemented the replace text feature for the chat console, still with segments updating.

So, in tomorrow's releases, you'll get the same feature as in LL's viewer v3, but without the code and memory bloat that comes with and impacts the latter...

Sweet! I didn't fully understand you had redirected those things to the chat Console, so it took me a second when i saw a mostly empty text area, and then another second to realize you had managed to place hints on the menu buttons as well. Awesome black magic Henri! Noticeably faster than the LL implementation too.

Thank You!

~Lycia

I was wondering what was going on with the viewer profile links for the last few months. Before I posted this I finally discovered that /inspect does what I had been using /about for.

Viewer links like secondlife:///app/agent/b43c4b76-3816-49ce-933d-e1a4eef3226e/about had been getting replaced with the avatar name, making them useless.

I noticed them being replaced by the name inconsistently for a few months, but didn't know if it was something the viewer was doing. Now it's happening consistently with the latest version since it doesn't rely on the cache anymore, so I was going to post here asking if it was still possible to see the profile links somehow. I thought only a few options like secondlife:///app/agent/agent/b43c4b76-3816-49ce-933d-e1a4eef3226e/username were supposed to get replaced with the respective values. So I checked http://wiki.secondlife.com/wiki/Viewer_URI_Name_Space again, and now I'm glad that we can still use /inspect to do the same thing that /about used to do. I tested the other ones like /im and /pay and they still work too, it's only /about that gets replaced. I hope this helps anyone else who is wondering the same thing.

Edit: Some of the /inspect links were still getting replaced with the avatar name and end up like "Henri Beauchampinspect" for something like secondlife:///app/agent/agent/b43c4b76-3816-49ce-933d-e1a4eef3226e/inspect. It was inconsistent, so I tried clearing my cache. Now /inspect links are getting replaced to look like "Henri Beauchampinspect", but it appears to only happen with llOwnerSay. It doesn't seem to be a problem with llRegionSayTo like it was for /agent.

I'm afraid there is no simple solution since this issue is due to lazy scripting by some, who, after noticing that newer v2/3 viewers (IIRC it happened around v2.4) were replacing SLURLs with names (this was originally implemented only for the UI of the viewers, for text boxes, but since the text box and text editor classes are now sub-classes of a LLTextBase class which itself got the SLURLs translation mechanism, the latter got extended to text editors such as the chat history), decided all of a sudden to emit SLURLs in script chat/IM (and even now, menus !) instead of using the llKey2Name() and llGetDisplayName() LSL functions and emit the resulting names, like all scripts used to do in the past...
Now, either the viewer translates everything to names, or it lets the SLURLs "as is": there is no other alternative... I was not aware that /inspect could also be used, so I'll implement this for next release, as a non-translatable SLURL (i.e. it will not be translated into a name), but for /about, it's more problematic, since that one was already used (before /username /completename and /displayname SLURLs were created by LL) as a (hackish/unofficial) name translation facility by scripts... I suppose I could add a setting to choose whether to translate /about or not, but your best bet is to complain to those lazy scripters about their incompatible scripting habits (text clients can't translate those, for example...) !

I found a solution which, I think, represents the best compromise. All /username, /dipslayname, /completename and /about SLURLs will be (in next releases) translated into their corresponding name counterparts (complete name for the /about SLURLs) but, in the chat history floater, the name will retain a link that will open the avatar profile when clicked.

I also updated the SLURLs support and added support for /mute, /unmute and /requestfriend ones.

The /inspect SLURL will also link to the Cool VL Viewer avatar inspect floater instead of the profile floater (you may still open the profile from the inspect floater).

Hopefully this will cover all usages (legit ones or pure script kiddy hacks).