Cool VL Viewer forum

First Off, I would like to say THANKS Henri ! I have been using CV for quite some time as well as other viewers, most notably Hippo & MeerKat and some experimental ones as well... CV stands the test of time. ! GREAT STUFF !

I have a few suggestions in regards to the current Patch Set being deployed in CV which are becoming more & more necessary. As I am now exclusively working in OpenSimulator environments we have several things available to us which cannot be addressed by CV. Just some Thoughts & Input to consider.

4096 TP Bug
I think you may have already addressed this, but with Hypergrid-1 being used widely and the impending release of HG-2 the 4096 Teleport Bug will become a major issue. This patch has been applied in other viewers but I am posting the link to it for your reference. https://jira.secondlife.com/browse/SVC-2941

[BUILD] Prim Sizing (Movement & Rotations):
SL/CV only have accuracy to .001 for movement and rotations. While using only limited sized prims (10x10x10) the deviations are not readily noticeable as rotations and movements are only accurate to .001. In OpenSim we have full sized prims at 256x256x256. The Accuracy adjustment over a 100m prim can deviate as much as 33% which translates to large Gaps and alignment issues. This has been corrected in MeerKat, Imprudence and I believe in Emerald. The modified XML file is in attachment.

Mega-Regions:
We now have Mega-region capabilities. These mega-regions span beyond the 256mx256m ceiling of LL/SL. a Large portion of people are now using them and this is likely to increase. In fact, I believe that SL is also now looking at this ability and considering their own implementation. Essentially, 1 region can now extend to 512m or 768m etc.. in both XY directions. There really is no major change to teh Viewer as such but capping the viewer's Max Distance Draw limit @ 256m can be a bit of a problem. While it is dependent on the Clients Video Sub-System can this be increased to allow for a much larger Draw Distance ?, 512m max is more reasonable and implemented in others such as MeerKat and others.

Prim Linking Limits:
Addressed in Posting: http://sldev.free.fr/forum/viewtopic.php?f=5&t=173

Windlight Setting + from regions to Viewer:
There is presently some work being done to deliver Windlight Settings (Sky, Cloud, Water) textures to the viewer and allowing the various Region/Sim operators to set the "Full Environment".
Reference: http://opensimulator.org/mantis/view.php?id=4057 There are related links in that OpenSim Mantis.

OpenSim osFunctions:
In OpenSimulator, we have several extensions to the LSL language in the form of osFunctions which can be used in any LSL script provided that they are enabled on the server. I had prepared a patch for Meerkat which includes these functions so that when editing a script, they are highlighted with the syntax, just like the llFunctions. I have included that patch in the attched ZIP file. Note that it is somewhat out of date and incomplete at this time as more functions and cocumentation has been completed since I made that patch. I will be updating this file and I can forward it to you as it cmes available, sometime early in the new year.

Backup Systems
The XML Backup system is a terrific and often needed (should have always been there) function that many people are relying on these days. While this works for Objects it has inherent limitations. K\O\W\A (aka KROWA| of Meerkat has been working very hard on implementating the next generation of Backups which will hopefully be in the next iteration of Imprudence. (he moved over there). This system uses the HPA format which is considerably more capable and has more extensive abilities to store objects etc... While this is a large task in itself, it would be nice to se that implemented into CV as well... So just as a Heads Up that t's being worked on.
Reference: https://liferain.com/projects/hpa

Thanks for your Time ! Keep up the GREAT WORK !
WhiteStar

512m draw distance is already the maximum, though this is by no means an absolute maximum, as the draw distance can be further increased by using the renderfarClip debug setting. I used it to take a snapshot from the top of a 1km tall tower I found in the sim Suilven.

Glad you like it


The Cool SL Viewer has been supporting TPs up to 4096m since day one after the release of Havoc4... Not sure what is this bug you are referring to, but I never saw it happening myself. As for the patch on the JIRA, it looks like an ugly hack (truncating the value of a variable instead of looking into why its value could eventually get too large)...

I do not think of this "feature" as an improvement... For a start, even if the display of the build tool floater is limited to three decimals, you can actually enter more decimals for each parameter (it will appear as rounded after you hit ENTER, but the value you entered will be taken into account).
Beside, too many decimals make things look only more complicated and distracting while giving a false sense of accuracy (mind you, the accuracy of the LSL trigonometric functions is quite rough, and a three decimals accuracy is not even always possible: try to make an horizontal axis (elongated cylinder) rotate without precession in any other alignment than North/South or West/East for example, and you will be surprised...).
Finally, the best practice when building (and to obtain well aligned prims and builds) is precisely to do it by entering round numbers for coordinates and sizes.
If you really need more decimals, you can always edit the floater_tools.xml file since it's not a hard coded limit, but I don't think the majority of the Cool SL Viewer users would like (and even less need) to see more decimals in the build tools floater.

This involves a lot of changes and code review for a feature which is not even yet implemented or used anywhere... So, it's not worth implementing it for now. As for the maximum draw distance, it is capped at 512m (not 256 !) in the preference floaters, but you can manually set it to pretty much anything via the RenderFarClip variable.


Setting forcefully the Windlight settings of a resident's viewer is for me an hostile act... What if their video card can't handle a particular setting (bug or non-implemented OpenGL functions) ?... What if the user prefers speed to prettiness (when you crawl at 5 FPS, believe me, you don't care the least if you can't see the clouds in the sky but can gain 5 more FPS without them !) ?...
There is such a feature in RestrainedLife already (and therefore in the Cool SL Viewer), but it can be disabled by the user (I was actually the one who implemented the disabling flag and asked Marine to make it official in the RestrainedLife specs and following patches, which she did).

Like you admit yourself, the OS functions are a moving target... Beside, the keywords.ini file is not the only thing to change in the viewer to implement full support for them (it only controls the highlighting and tips in the script editor, but does not deal with script compilation, for example). I've got better things to do, so this will stay low priority on my ToDo list for now, I'm afraid.

For now, and until Linden Lab issues a policy about what is allowed or not when dealing with contents backup via third parties viewers, I'll refrain from doing more development on this type of features...

Sorry for the late reply, but your post was long and my real life busy... Enjoy the new releases I posted today and happy New Year !

Be happy: since it was after all an easy task to make the number of decimals adjustable in real time, I implemented it in today's release of the Cool SL Viewer: you may set the number of decimals for the Position, Size and Rotation parameters of the build too floater ("Object" tab) to anything between 0 and 5 decimals (inclusive). This setting can be changed from the "Cool features" tab (UI sub-tab) of the Preferences floater.

Enjoy !

It's good news that you addressed the 5 decimal point accuracy issue. Hopefully, the Gymbal Lock for rotation has been addressed too. Standard Viewer code will resolve 180 degrees to .001 so 180 degrees is corrected to 180.001 and often with 5 decimal XML fixes this is not adjusted. The simple test is to place a prim at 90,90,180 rotation and use the mouse wheel to change the degrees rotation, it would return to the gymbal point @ 90 / 180 degrees. It can always be manually overriden. I have not downloaded your latest patch as yet.

The patch does not affect in any way the precision of the rotation and of the associated internal calculations done by the viewer: only the display in the build tool floater is affected.

Like I explained in my earlier reply above, the precision of the calculations on the rotation is quite rough (and affected by the fact that being performed in radian and displayed in degrees, there is a systematic error during each back and forth conversion). A 0.001° precision is about all what you can hope, and the number of displayed decimals won't change this the least...