Cool VL Viewer forum - View topic - Attachment not moving if changing coords in the edit floater

View unanswered posts | View active topics

It is currently 2024-04-20 02:04:48

Attachment not moving if changing coords in the edit floater

Page 1 of 1

[ 5 posts ]

Print view

Previous topic | Next topic

Attachment not moving if changing coords in the edit floater

Author

Message

ErikaThorkveld

Joined: 2011-12-13 14:11:38
Posts: 186

Attachment not moving if changing coords in the edit floater

I've been experiencing this little issue for quite some time now but I never took the time to find a way to reproduce it systematically: sometimes, when editing an attachment and trying to move it by entering coordinates in the 'edit' floater, the attachment actually doesn't move.
Here is a way to reproduce the problem:

Get this HUD from the MP: https://marketplace.secondlife.com/p/be ... r/14070621 (the HUD itself has no particular interest, I don't even use it myself, it's just free and causes the issue);
Unpack the HUD and wear it; its default position should be on the left side of the screen;
Edit the HUD, either by right-clicking on it on screen, or in your inventory;
In the 'edit' floater, go to the 'Object' tab and enter for example 0.5 in the y coordinate field;
Press 'Enter' to validate the new coordinate.

The attached images show the floater before & after pressing 'Enter'. The y coordinate does change, but not to 0.5. And the HUD doesn't move. Actually, the other coordinates also briefly change to something looking like world coordinates, but switch back to their previous value at once.
This also impacts moving the attachment with copy/paste. The copy seems to work, the pasting of size & rotation works as expected, but the position shows the same issue: the displayed coordinates change to some unexpected values, and the attachment doesn't move.
Again, this doesn't happen with all attachments: I tried with a simple box, and moving it via the floater works. But for some attachments, it just won't.

Not sure my system info and the log are really relevant, but here they are anyway:


	Quote: Cool VL Viewer v1.28.2.13, 64 bits, Mar 6 2021 21:35:37 Release notes You are at 107548.2, 403580.0, 2802.1 in West Cove located at simhost-0f960d4e154e1d254.agni.secondlife.io (54.184.237.92:13017) Alias: ec2-54-184-237-92.us-west-2.compute.amazonaws.com Second Life Server 2021-02-22.556255 Release notes: Retrieving... CPU: Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz (4001.62 MHz) Memory: 15837MB OS version: Linux-x86_64 v5.3.18-lp152.66-preempt #1 SMP PREEMPT Tue Mar 2 13:18:19 UTC 2021 (73933a3) Memory manager: jemalloc v5.2.1-20210221 Graphics card vendor: NVIDIA Corporation Graphics card: Quadro P3200/PCIe/SSE2 OpenGL version: 4.6.0 NVIDIA 460.56 Detected VRAM: 6144MB J2C decoder: OpenJPEG: 1.4.0.635f Audio driver: FMOD Studio v2.01.08 (PulseAudio) Networking backend: libcurl/7.47.0 OpenSSL/1.0.2u zlib/1.2.11 Embedded browser: CEF3 plugin v88.2.9+g5c8711a+chromium-88.0.4324.182 Packets lost: 129/2133 (6.0%) Built with: GCC v5.5.0 Compiler-generated maths: SSE2. Compile flags used for this build: -O3 -fno-delete-null-pointer-checks -fno-ipa-cp-clone -fno-align-labels -fno-align-loops -fsched-pressure -frename-registers -fweb -fira-hoist-pressure -DNDEBUG -std=c++14 -fno-stack-protector -fno-threadsafe-statics -fPIC -pipe -g -gdwarf-2 -gstrict-dwarf -fno-var-tracking-assignments -fexceptions -fno-strict-aliasing -fvisibility=hidden -fsigned-char -m64 -mfpmath=sse -fno-math-errno -fno-trapping-math -pthread -Wall -Wno-reorder -Werror -DLL_LINUX=1 -D_REENTRANT -DXML_STATIC -DLL_USE_JEMALLOC=1 -DLL_ELFBIN=1 -DOV_EXCLUDE_STATIC_CALLBACKS -DLL_FMOD=1 -DLL_OPENAL=1 -DLL_SDL2=1 -DLL_X11=1 -DLIB_NDOF=1


	Attachments: File comment: Log file CoolVLViewer.zip [27.1 KiB] Downloaded 99 times File comment: After pressing 'Enter' after.jpg [ 52.26 KiB \| Viewed 1218 times ] File comment: Before pressing 'Enter' before.jpg [ 51.65 KiB \| Viewed 1218 times ]

2021-03-10 08:47:27

Henri Beauchamp

Joined: 2009-03-17 18:42:51
Posts: 5546

Re: Attachment not moving if changing coords in the edit flo


	ErikaThorkveld wrote: I've been experiencing this little issue for quite some time now but I never took the time to find a way to reproduce it systematically: sometimes, when editing an attachment and trying to move it by entering coordinates in the 'edit' floater, the attachment actually doesn't move. Here is a way to reproduce the problem: Get this HUD from the MP: https://marketplace.secondlife.com/p/be ... r/14070621 (the HUD itself has no particular interest, I don't even use it myself, it's just free and causes the issue); Unpack the HUD and wear it; its default position should be on the left side of the screen; Edit the HUD, either by right-clicking on it on screen, or in your inventory; In the 'edit' floater, go to the 'Object' tab and enter for example 0.5 in the y coordinate field; Press 'Enter' to validate the new coordinate.

And it's working 100% fine for me... Cannot reproduce here.

Note also that, for HUDs, you cannot change the position coordinate perpendicular to the screen plane (i.e. the X axis/position), which is the expected behaviour.

The culprit is a transitory network and/or server issue. I can also see in your log several AIS errors like this:


	Code: 2021-03-10T08:24:05Z WARNING: AISAPI::InvokeAISCommandCoro: Inventory error: Gone - Result: <llsd>

This denotes an issue with the inventory server (and probably causes a reload of the attached item data, thus the "rollback" in the HUD position). You may temporarily work-around such an issue when it happens by disabling AISv3 (toggle in Advanced -> Network) and relogging (the relog is needed when the pending AIS operations retries keep coming with errors in the log: should they ebb away, the relog might be spared).

Please also note that the spurious rollbacks of edited objects parameters (and not just position, but also size, textures, etc) are a well known issue in SL (as old as SL itself !) and was never properly solved. It happens with all viewers and is a server-side issue (I would suspect a race condition due to out of order network UDP packets, but I cannot investigate or fix LL's server-side code).

2021-03-10 09:19:47

ErikaThorkveld

Joined: 2011-12-13 14:11:38
Posts: 186

Re: Attachment not moving if changing coords in the edit flo

Thanks for the answer. I must say I'm very surprised, because the behaviour I'm getting really seems to depend only on the attachment I'm moving, and not on anything else at all.
And I did try your workaround with the very same HUD, and disabling AISv3 didn't seem to have any effect: the HUD still would not move when I entered a new y coordinate in the floater.
I also tried - with AISv3 still disabled - to attach both the HUD I used in the original post and a basic cube prim attached as a HUD: the HUD still wouldn't move, but the cube did move when I entered coordinates in the floater, all of it in the same session. I'm attaching the log for this session too.
Couldn't there be any other reason for this?
Thanks.


	Attachments: CoolVLViewer.zip [54.28 KiB] Downloaded 93 times

2021-03-11 07:10:02

Henri Beauchamp

Joined: 2009-03-17 18:42:51
Posts: 5546

Re: Attachment not moving if changing coords in the edit flo

From your second log:


	Code: 021-03-11T06:57:21Z WARNING: LLAppearanceMgr::serverAppearanceUpdateFailure: Appearance update request failed with status: 400 2

And this repeats again and again...

Obviously you got network issues, and the viewer is for nothing in this.

It is quite possible that UDP packets (which are used during object editing for messaging from the viewer to transmit the changed parameters to the server) fail to pass in a timely manner, get lost, or received out of order, causing the issue for you (but again, I cannot reproduce it at all here).

2021-03-11 09:00:31

ErikaThorkveld

Joined: 2011-12-13 14:11:38
Posts: 186

Re: Attachment not moving if changing coords in the edit flo


	Henri Beauchamp wrote: Obviously you got network issues

Well, actually, my network is an issue.

It's a bit weird that it causes this kind of problem in such a consistent manner, though...
Well, I can live with that. Hopefully, this annoyance will disappear when I can get a faster and more stable internet connection.

Thank you!

2021-03-13 05:50:21

Page 1 of 1

[ 5 posts ]

Who is online

Users browsing this forum: No registered users and 55 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum