Cool VL Viewer forum

Hi Henri!

After many many years in SL I started messing with the environment and day cycle tools... because PBR, burning retinas, and the vain hope I could do better.

I discovered that editing a full-perm day-cycle environment (ugh what a mouthful) from another creator causes the day-cycle to becomes no-transfer.

I can reproduce this by creating a new day-cycle, passing the object to an alt, then making a single change to it on the alt. I have not tested this with individual components like water or skys.

As a side note, the day-cycle editor is finicky for me and does not always like to load fully on the first try. Usually, picking the day-cycle to edit from the load dialog inside the tool works around that behavior. I thought about filing a second bug, but you will likely see this behavior if you experiment with the the no-trans issue. I can file this as a second bug if you like though!

Thanks Henri! Looking forward to your thoughts on this!
~Lycia

Day cycles use sub-assets: sky and water settings. Are you sure all the sub-assets in use are full perm ?

Note also that permissions can be overridden server-side, when the server detects a conflict. Can you reproduce this behavior in LL's official viewer ?

Hi Henri, I did more testing and found a couple things.

First, the details of the issue is different then I initially reported... dang it...
I am seeing the permissions getting automatically set to copy/mod/no-trans, but it happens after editing and saving the day-cycle, (transfer of the object has nothing to do with it, sorry, I need to stop doing this stuff at 3am).

I can trigger this behavior by extracting the "Layered Clouds" texture from the LL library into a non-library folder, and then dropping it into the 50% ground level keyframe, adjusting cloud density to 0.8, and saving. Changing either element alone did not seem to be a consistant way of invoking the behavior.

Second, this particular behavior does not occur on the standard LL viewer, (object remains full perm).

Finally, I created a New-Sky in Cool, and did not see this behavior, it remained full-perm.

Hopefully this is more a more useful description of what i am seeing

Thanks again Henri!

Cannot reproduce...

This might depend on your default permissions settings (see "File" -> "Set default permissions..."): for my viewer, the "normal permissions" for newly created items (scripts, note cards and snapshots excepted) is mod-ok, copy-ok, no-transfer, so a new env setting asset will be created as such, but you can modify it in the Properties floater (opened from the inventory context menu, for example) before editing it. Once the setting is full perm, I do not see it change back to no-transfer when modifying it...

Yeah, "Cannot Reproduce, will not fix" feels like the right answer to me at this point.

I checked my settings but I share enough objects that default is configured to full perm for me.

I tried a few things to put a better frame around what I am seeing:
- I cannot duplicate the problem on Linux, the environmental controls work flawlessly there. This is only happening on Windoze.
- Even on Windoze, I cannot duplicate the problem on my test alt. It seems localized to my main avatar.
- The most unique thing about my main, is inventory size... around 150K of hoarding over years and years of SL, seems unrelated but the asset servers could be choking on something in there.

At this point I agree, this behavior is not worth investigation unless it becomes more reproducible. I can use the standard viewer, Linux or an alt as easy workarounds.

I am going to leave some before and after screenshots as evidence I am not out of my mind though.

Again, thanks for the support Henri,
~Lycia

Did you try to fully clear the viewer cache for the affected machine/avatar combination ?

There is no reason that it would work fine under Linux and not under Windows (this part of the code is independent of the OS), short of a compiler bug, but then it would affect all avatars under Windows...

Honestly, the idea it was an local install problem didn't occur to me.

I did go back and try clearing the caches, but that was unsuccessful, so I went further and fully cleaned up and re-installed. The behavior still persisted, but it took significantly longer to show up... Reflecting on your comments about the OS agnostic nature of the code, I got suspicious and reran all my previous tests with more iterations.

The extra iterations revealed the permission changes happening in all cases, (Linux, Windows and with my alt). So, this is an intermittent behavior and I was not allowing enough repeats for it to appear. For some reason Lycia was literally getting lucky and seeing it so frequently it looked like a consistant behavior.

I have found that 'repeatedly twiddling a random setting and saving' seems to be an effective way of reproducing this, (there is no need to close out the editor). On Linux, it took 17 test cycles to appear. I ran 100 cycles on the LL viewer and never saw the behavior.

The only other thing i can add right now is... Intermittent problems are annoying.

Thanks for the suggestion and thoughts Henri, it sent me in a very revealing direction.
~Lycia

Try disabling AISv3 (only temporarily: AISv3 is pretty much a requirement now in SL) from the Advanced Networking menu, and see if you can reproduce the bug...

Disabling AISv3 did not prevent the issue, but it did prevent it from being propagated in copies of the object. I dont know if that was expected or not.

With AISv3 enabled, copying the object after the permissions were altered results in a copy that also has the altered inaccessible permissions, and is no-trans.

With AISv3 disabled, copying the object after the permissions were altered results in a copy that has accessible permissions, although the no-trans box is unchecked, so this state is recoverable. Or seems to be so far.

I attached Screenshots that show the final outcomes for copy-paste operations in both states.

Hopefully this is helpful, or at least interesting,
~Lycia