Cool VL Viewer forum

Ok since many people (including myself) seem to have a problem with SLURLs using the Coolviewer, I figured a post was in order. (Thanks to Henri for pointing me to the boards!)

From all the blog comments I've read, there MAY be a difference of functionality between Operating Systems.. I can only comment on the Windows (and specifically XP SP3) functionality.

Note: I may edit this as replies are provided in case I screw up and provide wrong info.. I am posting it as sort of a FAQ outline which will be filled in later as more info becomes available.

------------------------------------------------------
A few definitions for those not familar:
1) SLURL - A hyperlink provided either ingame or on the internet which corresponds to a particular Sim's coordinates in the Second Life world. More info can be found in detail at: http://wiki.secondlife.com/wiki/SLURL

2) Inworld Behavior - Typically refers to the behavior of the Viewer when you click on an SLURL provided within the viewer. (Such as an SLURL given by an instant message, chat room, or object).

3) OutWorld Behavior - Refers to the behavior of the viewer when you click on an SLURL from the Internet Web Browser. Behavior may be different if your client is currently running or not-running.

Some further notes:
My system is Windows XP SP3, Running Firefox 3.0.8. I have both the standard LL Viewer (Version 1.22.11.48405 reported on the Secondlife.exe) and Coolviewer (Viewer 1.22.11.0 R4 as reported on blog)

Note: Up through Cool Viewer 1.22.11.0 R4, the Inworld click behavior seems to be the same between both viewers for me.. Both open up a teleport window which functions as normal.

----------------------------------------------------
Default Behavior of LL When using an Outworld SLURL
----------------------------------------------------
When clicking a link from the internet, the Windows/Browser associations look up the client specified and if it is not already running, opens up the client for initial launch. If the client is already running, it opens a teleport window within that client to the address specified within the SLURL.


----------------------------------------------------------------------------------------
Default Behavior of CoolViewer When using an Outworld SLURL and Restrained Life DISABLED
----------------------------------------------------------------------------------------
Need expected behavior info

----------------------------------------------------------------------------------------
Default Behavior of CoolViewer When using an Outworld SLURL and Restrained Life ENABLED
----------------------------------------------------------------------------------------
Need expected behavior info



If your SLURLs are not behaving as indicated above.. the following configuration settings may prove helpful:
Need further testing

Ok replying to my own post so that a discussion can be started as to the PROPER functionality and how to correct inproper installations.

From what I can gather from the Blog Comments there is some confusion about what is Expected Behavior from Coolviewer and what is Wanted behavior.

According to Boylane on Jan 12, 2009, a comment was posted:


This appears to make it seem as if Coolviewer ONLY will function with SLURLs in that it will open another client instance and will not open a teleport map as the official viewer does. No mention was made of whether this is with RLV turned on or off.

A few weeks later around Jan 31st, a comment was made:

and reply by boylane


Overall this is basically saying the same as the first quote, however it appears that one can modify the registry so that SLURLs can function (I'm assuming the original poster wasn't getting any functionality of any kind when clicking an SLUR). Reference is made here to the fact that Restrained Life is the cause. No indication of whether or not unchecking the RLV featureset will revert behavior.

Henri actually clarifys this by saying

Which seems to indicate that the Expected behavior of SLURLs when RLV is enabled is that they do not function at ALL, and that when RLV is disabled, the functionality is limited to opening up a new client instance and not a teleport map as the official viewer does.

I'm not going to post any further quotes as many of them are the same answer over and over with slight text changes, but a few things seems clear after I've read about 200+ comments.

1) There seems to be confusion as to what behavior is expected from the end user after being used to previous versions of Cool Viewer and LL viewer, and what behavior is expected from those who know more about the programming and how it relates to Restrained Life.

2) Some of the posts seem to imply that some people have gotten Cool Viewer to behave Exactly like the official viewer (perhaps only in Linux from what I noticed) where it will open teleport windows and not multiple instances.

Either way.. if either Boylane or someone else who has extensive knowledge of Restrained Life and Coolviewer could clarify once and for all what is the Expected Behavior per the Programming changes CoolViewer/RLV have implemented, and whether or not the above registry change is the only configuration needed if you get no functionality. (I Could have sworn there were Firefox configuration changes but I can't seem to find them atm...)

Anyway.. hope this thread can help others clear up the SLURL fun

OK, let's get it straight:

• The Cool SL Viewer does not modify any code or behaviour related to SLURLs, excepted whenever RestrainedLife is enabled (in which case, SLURLs cannot be used at all to prevent cheating and escaping RestrainedLife devices). So, if you are using RestrainedLife, read no further: SLURLs are not for you. Period.

• The Cool SL Viewer comes in (at least) two flavours: the legacy renderer one, based on v1.19.0.5, and the Windlight renderer one, based on the current official viewer (to which is added an experimental branch when appropriate, based on official RC viewers). The two branches (legacy and Windlight) got different behaviours and different ways to invoke options in the command line (example: -multiple (with one dash only) for v1.19.0.5 and --multiple (two dashes before the option name) for v1.22).

• Under Linux, v1.19.0.5 cannot (by design) make two instances of the viewer communicate, and the only thing you can get when clicking on a SLURL in your web browser is to get a new instance launched and get logged in to the SLURL location. As a result, you must use the -multiple option in the script used to launch the viewer from your browser.
  I honestly do not know what is the behaviour under Windoze (I banned Windoze many years ago from my computers and the SL viewer fails to work in virtual machines), or MacOS X (I don't have MacOS X to build a virtual machine from it)...

• Still under Linux, v1.22 does allow to get SLURLs passed to a running instance. What happens is that when you click on a SLURL in your web browser (and provided the latter is properly configured), a new instance of the viewer is launched, but instead of initializing fully, it checks if another instance is already running, and when it is the case, it uses the dbus messaging system to pass the SLURL location to the running instance before committing suicide (note that --multiple is not even necessary since this option is only checked later in the code and the viewer commits suicide before reaching it).
  For the user, it looks like the running instance got the SLURL directly from the browser and they don't even notice a new instance was actually launched to do the communication work.
  Here again, I do not know what is the actual mechanism used under Windoze, but one thing is certain: it should not be different from the official viewer.

Cool thanks for the Linux info..I'll add it to my first post shortly , bit too tired now to trust my editing skills

I did a bit more testing on Windows with the 1.22 version of CV tonight.. and it seems there is in fact a difference between the OS's which is what I think was causing the confusion among people. Again I only tested with RLV Disabled.

As you mentiond, for Linux users, using the --multiple option works, via that suicide technique you mentioned above.

I don't know much about the codebase for any of the versions, but your description of what happens with Linux using the --multiple command 'seems' like what the Official LL viewer does under windows. I've noticed a real fast 2nd instance appearing and closing before the SLURL gets passed to the existing instance. (Though I can't be sure that what I'm calling a 2nd instance is in fact a second official SL client, or just some other windows API window, it goes by REAL fast on my screen even when I'm watching the process manager).

I can say however that the CoolViewer behaves differently than what you are seeing under Linux. And differently than the official LL version.

Using the --multiple option under Windows, there is no such suicide of 2nd instance, and instead a full 2nd client launches, however the "Start Here" location is listed under the login info is populated with the location within the SLURL that the user clicks on. If you don't do anything the window never closes and you are stuck with a 2nd instance at the login screen. If you do decide to attempt to log in using a Username/Password as normal, since you are already logged in will provide you with the standard error saying to wait while it logs you out of the region (on your 1st instance).

Without the --multiple option, you get the message stating CoolViewer is already running of course.

So I guess the question now is.. Are we seeing a 'bug' in Windows, or is this simply a part of RLV that is unable to be disabled under windows OS installations. I'm guessing we'll need Boylane to provide that answer.

Ok time to log off.. the screen is starting to move on it's own....

NOTE: Is it me or is the reply function acting funny.. I've hit Submit and nothing happens... seems I MUST preview first for it to take effect...

I guess the issue you see happening under WIndoze only is because Boy Lane renamed the Cool SL Viewer executable file into "CoolViewer.exe" instead of letting the normal "SecondLife.exe" name, but there is no proper renaming patch in the code itself... Since Windoze is particularly dumb an OS, it might not detect the first instance if it's not properly named (and appears as "CoolViewer.exe" instead of "SecondLife.exe" in the task manager).

Try this:

• Delete the SecondLife.exe file from the installation directory (it's useless anyway, since it can't work with the modified XML files of the Cool SL Viewer).
• Rename "CoolViewer.exe" into "SecondLife.exe".
• Make sure your registry and shortcuts point to SecondLife.exe instead of CoolViewer.exe.
• Make sure all old CoolViewer.exe instances are closed and start again the viewer.
• Try again the SLURLs mechanism.

To Boy Lane: please, do not rename the Cool SL Viewer neither its executable. There is no license issue at all with LL and should there be one some day, I would produce the proper patch so that the renaming does not prevent the viewer from working properly.
Also, the name of the viewer is "Cool SL Viewer", not "Cool Viewer": please make sure it is advertized with the right name and channel as LL is trying to get statistics about the usage of third parties viewers and all the Cool SL Viewers should be advertized with the "Cool SL Viewer" channel name, regardless of the OS they run on.

Please *DO NOT* rename CoolViewer.exe and *DO NOT* screw around with your registry. It won't change anything as the viewer works properly as it is. You can use SLURLs and it was explained many times. If you do so the viewer starts a new instance, that is either it starts from scratch when it wasn't running before or it tries to start another instance. This is working in the Windows version, so please don't mess around with it .

@Henri
LL is pretty clear about usage of their trademarks, here SL and SecondLife. I removed the SL from the name and renamed the binary as well as all installation locations. That is done properly in the source itself. That's not to disregard your work and I explained this to you before. Details with examples are not open for interpretation:
"This is NOT OK:
[...]SL Viewer Software[...]"

"Do not use in the name of your business, organization, product, or service, and do not register as a trademark, service mark, or business or organization name, any Linden Lab trademark or any words or symbols virtually identical or confusingly similar to a Linden Lab trademark. This includes, but isn't limited to, our Second Life® brand name [...]"

So no, I'm not going to use either SL nor Secondlife now or in the future and by doing so violate any trademark or law.

Boy, you are wrong there: the normal and expected behaviour in v1.22 is not to start and log in with a new instance, but for the second instance to send the first the SLURL and then bail out. The fact it does not work properly with the windoze build is obviously because of the savage renaming you did.

Please, folks, do try what I posted in the previous message, and report any success or failure.


*I* am the author of the Cool SL Viewer. *I* am the upstream for it. If anyone at Linden Lab is unhappy with the licensing, do not worry, I will take it personally and will provide for an adequate solution.

By the way, there has already been a heated discussion on the sldev mailing list about licenses, and never ever did LL come to me to say I was violating any license (while some people did point out my viewer, among others, as possible violators, so I assume the Cool SL Viewer case was actually examined by LL already). Do not be paranoid about it all. The third parties viewers which are published by residents as free and Open Source software are certainly not going to be sued by LL: they need us too much to find and fix bugs, and cope with the vocal minority of unhappy residents.

For now your solution only leads to break things and make it unclear for LL what actual viewer code base corresponds to what channel name. For a proper re-branding of the viewer, way more many things need to be changed in the code. I will do it only if actually necessary.

@Henri

It doesn't break anything that would have worked before. Simply because I did not rename a resulting binary, but the whole source and building environment is changed.

I'll compare that with the Linux version and see if and how this behaves different.

No, compare it with the official LL viewer under Windoze. They must behave exactly in the same way as long as RestrainedLife is disabled.

It'll be great when its working right, as a content creator, Slurls are very useful in guiding folk to my sim, from inside and outside SL