Cool VL Viewer forum

Hi Henri,

2 issues - (tested v1.26.7.6 also - same issues)

1. The dots to resize something are very tiny - hardly to see them at all. Next time they are bigger than the prim.

2. Attachments which are changed, stay at their position and don't move with the AVA.

Let me try to explain it - Situation:

- I step on a posestand - T-Position
- Move a bracelet a little bit.
- When I jump off the posestand some parts of the bracelet are still in the T-Position...floating in the air.

Sometimes the whole attachment is still there.

Another guy reported that parts of his vehicles don't move with him. Seems to be the same issue.



Cool VL Viewer 1.26.4 (49) Jan 19 2013 12:10:57 (Cool VL Viewer)
Release Notes

You are at 199281.3, 248144.2, 21.9 in Mumbai located at sim10205.agni.lindenlab.com (216.82.49.71:13021)
Second Life RC Magnum 13.01.11.268951
Release Notes

CPU: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz (3399.93 MHz)
Memory: 8192 MB
OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTS 450/PCIe/SSE2
Windows Graphics Driver Version: 9.18.0013.0697
OpenGL Version: 4.2.0

libcurl Version: libcurl/7.21.1 OpenSSL/0.9.8q zlib/1.2.5 c-ares/1.7.1
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.750000
Qt Webkit Version: 4.7.1 (version number hard-coded)
Packets Lost: 44/14187 (0.3%)

Built with MSVC version 1600

Compile flags used for this build:
-DNDEBUG -DLL_RELEASE=1 -DLL_RELEASE_FOR_DOWNLOAD=1 /O2 /Oi /arch:SSE2 /MD /MP /D_SECURE_SCL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DWIN32 /D_WINDOWS /W3 /EHsc /GR /Oy- /GS /arch:SSE2 /fp:fast /TP /W2 /Zc:forScope /Zc:wchar_t- /c /nologo /DLL_WINDOWS=1 /DDOM_DYNAMIC /DUNICODE /D_UNICODE /DWINVER=0x0501 /D_WIN32_WINNT=0x0501 /DLL_USE_TCMALLOC=1 /DLL_NEW_HTTP_CORE=1 /DLL_MEDIA_ON_PRIM=1 /DCARES_STATICLIB /DCARES_STATICLIB /DLIB_NDOF=1

This is in no way a bug !... It allows to resize mega-prims that are much longer than they are wide (the "normal" (LL's) resize handles are then so large that they all overlap, making it impossible to use them); the new handles sizing algorithm is camera-zoom-dependent instead of avatar-to-prim-center-distance-dependent. If you don't like the new handles, you can revert to the old ones by un-checking Advanced -> UI -> "Zoom Dependent Resize Handles", but the proper way to see them at a proper size is simply to zoom with the camera (ALT-left-click-move-mouse-forward) on the face they surround.

Yes, I could reproduce this bug that seems to be the result of one of LL's latest "fixes" (that was supposed to plug an issue with edited child primitives not moving until deselected). I'll revert that buggy fix in next releases.

That could be due to another of LL's "fixes": a proper bug report with a repro procedure is needed to make sure, so please ask "that other guy" to file a proper bug report.

hello,

same here, when i edit Attachments which i wear they will optically destroy after finalizing when i move the Avatar.
Only a reattach let me see the Attachments correct again.
The Grafik-Bug i see with and without Posestand.
I am using CoolVLViewer-1.26.7.6-Windows-Setup.exe

sincerely yours
Dae

Like I already wrote, this bug has already been found and fixed for the next releases.

The attachments and vehicles issues should now be fixed in v1.26.4.50, v1.26.6.7 and v1.26.7.7.

Looks good so far.

meh!

the bug with the physical vehicles leaving prims behind is still active for me on the latest release version Cool VL Viewer 1.26.6 (10). with the "usenewmovingprimfix" true or false it does not make a difference on my screen (restarting viewer after changing the setting) . additional note: the prims left behind will autofix themselves, when you cross over a simborder with the vehicle, of course that won't work on a 1 SIM racetrack

screenshot



the prims in the front remained where i rezzed the vehicle and stay there no matter where i physically move the vehicle inside the SIM. reproduceable with basically any physical vehicles for me.

Yes, but fixing this bug causes other, even more annoying bugs to creep back up (moving, resizing or rotating child primitives out of the field of view stop being updated and are off their actual state when you look back at them, like closed doors still appearing as open, etc).
LL is aware that their whole code for this child primitive issue is crippled and would require a full rewrite. I'd bet they are working on it. The Cool VL Viewer will get the proper fix implemented as soon as it is made available by LL.

In the mean time you could try this: what happens if you switch to mouse look (and stay in it) before sitting on the vehicle object ?... It could well be a workaround (not sure, because I myself pretty much never use vehicles in SL and the couple of vehicles I got in my inventory don't seem to be affected by that bug).

the vehicles usually dont have a left click sitter, so you have to rightlick and chose "sit", afaik theres no way to activate that menu in mouselook?
tried it with the mouselook spoof, didnt change anything. hmm.
i just compared it to the latest firestorm release and didnt experience it there, but i have to say, even on my funky new computer cool vl viewer is still giving me more FPS with basically the same graphic setup, and i still like the v1 interface

for me its just a little annoyance but no dealbreaker bug.

True... I must admit I never use mouse-look...

The mouse-look spoofing is to make believe to the server and (more specifically) to the scripts running on it, that you are in mouse-look while you are not (this is to make some stupid, stubborn, invasive scripts work while keeping your freedom as to what view you want to have on your screen), but it won't cause the viewer to stop rendering objects behind your avatar's mouse-look FOV (since you are actually not in mouse-look), which is what I suggested this trick for...

Because Firestorm didn't (yet ?) implement my fixes to LL's buggy code, so they suffer the same bugs as LL's viewers (failure to update moving, rotating, rescaling child primitives) instead of having the vehicle bug (for now, you got one bug or the other: there's no modern viewer that manages to render things properly in all cases: only antiquated viewers (v1.23 and older) do it right !).

This said, I've got a new idea for a possible fix: no promise, but I'll have a try at it and see what happens...