Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-7084] Prim properties visually revert to an earlier state since Interesting #14831

Open
5 tasks
sl-service-account opened this issue Aug 22, 2014 · 9 comments
Open
5 tasks

[BUG-7084] Prim properties visually revert to an earlier state since Interesting #14831

sl-service-account opened this issue Aug 22, 2014 · 9 comments
Labels
project:BUG

Comments

@sl-service-account
Copy link

sl-service-account commented Aug 22, 2014 •
edited by sl-issues-importer bot

Since the viewer-interesting changes were added to the viewer, objects that change state via script often appear visually in the wrong state.
For example, an open door that is set to fully transparent with llSetAlpha will visually appear closed and opaque or an object scripted to be a switchable light using PRIM_GLOW, PRIM_FULLBRIGHT and PRIM_POINT_LIGHT will visually appear to be emitting light when the light is switched off and vice versa.

I have not been able to find a simple setup to reproduce this bug reliably unfortunately.
The repro below is the best place I have found to reliably reproduce this problem. This is a maze with doors that can be individually opened and closed by clicking on a scripted controller.

Steps To Reproduce

  • Teleport to http://maps.secondlife.com/secondlife/Cataclysm/182/170/27

  • On the ground you will see the scripted controller for the doors - see Fig 1 attached.

    • Do not click R (reset) or S (Sync).
    • The red cylinders are the door switches to open and close the maze doors.
    • The door switches are red when the corresponding door is closed and green when the door is open.
    • Observe that the layout of the switches on the controller matches the layout of the doors in the maze.
    • When you start the test, you want all doors to be closed so the controller looks like it does in Fig 1.

  • If you had to close any of the doors before starting to test, relog before testing.

  • Use the door controller to open some doors to set a path through the maze - an example of which doors to open is shown in Fig 2.

  • Walk down into the maze and walk or run around the path through the open doors a few times and observe whether the doors that should be open visually appear to be open and the doors that should be closed visually appear to be closed.

  • Doors that should be open but visually look closed can still be walked through.

  • Doors that should be closed but visually appear open cannot be walked through.

  • If you cannot reproduce this bug, walk back or cam onto the controller and open some more doors and try again.

  • If you are having problems reproducing this, please ask me to demonstrate it inworld, it is much easier to actually show you and explain on voice then to explain it here ;)

  • It is helpful when testing to have an alt logged in on a pre-interesting viewer so you can easily see the correct state of each door when testing.

The script used in each maze door is this:

default
{
    state_entry()
    {
        llListen(-46284, "", "", "");
    }

    listen(integer channel, string name, key id, string message)
    {
        list input = llParseString2List(message, [","], []);
        if (llList2String(input, 0) == "setstatus")
        {
            if (llList2String(input, 1) == llGetObjectDesc())
            {
                if (llList2Integer(input, 2) == 1)
                {
                    llSetAlpha(0.0, ALL_SIDES);
                    llSetStatus(STATUS_PHANTOM, TRUE);
                    llShout(-46284, "status," + llGetObjectDesc() + ",1");
                }
                else
                {
                    llSetAlpha(1.0, ALL_SIDES);
                    llSetStatus(STATUS_PHANTOM, FALSE);
                    llShout(-46284, "status," + llGetObjectDesc() + ",0");
                }
            }
        }
    }
}

Observed Behaviour

  • The observed behaviour is horribly erratic and very strange.

  • After changing the open/closed state of the doors, often they will appear visually in the wrong state - you are able to walk through a door that visually appears to be closed and unable to walk through a door that visually appears to be open.

  • Often all the doors will appear at first to be visually in the correct state as you run around the maze. However after running around for a few minutes, suddenly doors that previously were visually in the correct state will change to be visually in the wrong state - this is totally random and the state change can happen even up to 5-10 minutes later.

  • Often you will see a door that is showing the correct state switch states right infront of your eyes.
    For example a door that you opened using the controller and correctly looked open on your first few runs around the maze will still appear correctly open as you turn a maze corner and it first comes into view but just as you are about to walk through the door, it will visually change to being closed right infront of you.
    Once a door changes to an incorrect state like this, as you continue running around the maze path, this door will briefly flash its correct state each time it comes back into view.
    This effect is really difficult to explain but hopefully you will see it.

  • See Demo Video at http://youtu.be/kK-ADRGeips

  • When a door is visually in the wrong state, editing the door does not correct its state.

  • When a set of doors are visually in the wrong state, changing your active group tag and moving camera a bit will often immediately fix all the doors and they will then appear in the correct state.

    Expected Behaviour

    Prim properties changed via script should not visually change to an incorrect state.

    Other Information

  • Please note that even though this door script is using llSetAlpha, this bug is not the same as the known issue with llSetAlpha and llSetLinkAlpha - ref BUG-4380

  • This bug only reproduces on post-interesting viewers.

    • 3.7.7.289441 does not reproduce the bug.
    • 3.7.7.289461 does reproduce the bug.

  • Please see http://jira.phoenixviewer.com/browse/FIRE-14394 for another example of this bug.

Attachments

Links

Related

Duplicates

Original Jira Fields
Field Value
Issue BUG-7084
Summary Prim properties visually revert to an earlier state since Interesting
Type Bug
Priority Unset
Status Accepted
Resolution Accepted
Reporter Whirly Fizzle (whirly.fizzle)
Created at 2014-08-22T00:02:56Z
Updated at 2023-11-07T14:31:06Z 
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2014-08-22T05:33:46.569-0500',
  'Regression?': ['Issue is a Regression'],
  'System': 'SL Viewer',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': '.',
  'What were you doing when it happened?': 'Filling in....',
  'What were you expecting to happen instead?': '.',
}
@sl-service-account
Copy link
Author

Antony Fairport commented at 2014-08-22T10:33:47Z

When a door is visually in the wrong state, editing the door does not correct its state

Are you finding that, when you edit a "wrong" door, it assumes the wrong properties? In my tests so far (cf FS JIRA mentioned above) I'm finding that the wrong state appears to be client-side only (properties as seen from a script in the object differ from what's seen in-world on screen) until I select the object (or possibly prim, or just face – I've yet to test it that far) and then the object appears to take on the wrong state (and so properties as seen by a script inside the object then match what's seen in-world).

@sl-service-account
Copy link
Author

Antony Fairport commented at 2014-08-22T11:41:49Z

Following on from my comment in http://jira.phoenixviewer.com/browse/FIRE-14394 where I expand on what I've been seeing, I just had the same situation happen again. The lights went off in my workshop as the sun came up, I cammed out and then back in and they all appeared to be on. I called the scripts to report how they saw the properties and they all told that glow, bright and point light were all off even though they appeared to be on in-world.

This time, rather than selecting them or bringing another avatar into the scene, I took the example from this report and changed group tags. That didn't appear to do anything, at least not right away. I then cammed out and back into the workshop and all the lights then displayed in-world such that they matched the properties that were reported by the scripts.

So, right now, my experience seems to be:

  • When the lights go wrong they appear in-world wrong but are seen by script as being in the right state.
  • If I select each prim in the linkset some or all of the "wrong" properties became the actual property of that prim (a subsequent check with a script shows that even it thinks the object as the "wrong" property).
  • If I don't select anything but change group tag and "unsee" then "see" the object it all goes correct.

Like with this report, and others, I'm still unable to recreate this at will with a very simple setup.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-08-27T08:33:02Z

Antony Fairport added a comment - Yesterday 08:51 PM +0100 - edited

It seems that this issue isn't just related to the more visual (glow, fullbright, colour, alpha, etc...) properties. A little earlier I had an instance of this affecting an object's location.

I was swapping a vendor board over in my shop and this happened:

  • I walked up to the vendor board that needed replacing. This object wasn't owned by me but I do have edit rights to the owner's objects.
  • I edited the object and copied its location and then dragged it forward a couple of meters.
  • I cammed over to the new board I wanted to put in its place (a distance of around 90m), edited it and pasted the location.
  • I cammed back to find that the old board was back in its original location.
  • At this point, rather than selecting it in edit to see if it caused the "wrong" properties to "stick" (see previous report with above with evidence of this happening), I decided to try the group-change that was mentioned to see if it had an effect (and to be fairly sure I wasn't just looking at some connection/lag issue). I changed my active tag from none to a random group and, after a moment, the original vendor board moved back to the correct position (the position I'd moved it forward into originally).

I think this is good evidence that position is another property that can go wrong. This also raises an interesting question: if seeing an object in its wrong location, and then selecting the object, causes the wrong location to became the actual location for the object, is this an inadvertent (if somewhat unlikely) way of a third party with no edit rights to "undo" recent moves/edits?

Unfortunately I still can't find a way to recreate this setup in a controlled environment so it's near impossible to test this.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-08-31T01:13:44Z

Tetsuryu Vlodovic added a comment - Yesterday 11:46 AM +0100

I too have observed this behaviour. What's also interesting is that I've noticed that also appears to affect particle emitters and object sizes.

  1. I have a pair of curtains scripted to open by moving and resizing the curtain parts, but on a couple of occasions, the curtains appear to have closed even though I opened them mere moments ago; as I tried to open them again, I got an error from it saying they were already open, so I tried to close them instead, and the curtain prims refreshed to their "open" state just so they could close again.
  2. Likewise I have a bunch of candles utilizing particle flame, and in addition to the lights suddenly disappearing after lighting them up, the flames had also disappeared, and I had to turn them off and on again.

Right clicking to refresh either did not work in this case like usual.

@sl-service-account
Copy link
Author

Lassie commented at 2014-09-11T13:57:09Z

This is also affecting the Mused Milk Made milk tanks.

Full tank, transfer some milk out to another tank, turn around for a few minutes, turn back and it shows full again. Transfer some more out and it'll show the correct amount again until the tank goes out of view again.

Relog fixes it until it hangs again, I haven't tested it with teleporting to another region and back.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-09-11T14:32:05Z

To reproduce the problem with the Mused Milk Made tanks, you will need: 1 interesting based viewer, 2 tanks, the milk HUD and the boobs from http://www.musedcreamery.com/products/
Inworld store to get these: http://www.musedcreamery.com/store-links/

The boobs produce milk at 0.19L/hr so if all the QA team get kitted out you should have enough milk to reproduce this within a few days :D
(Pics or it didn't happen)

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-10-03T01:29:07Z

Princess Zelmanov added a comment - 5 hours ago

I have large sim-size scenes that are rezzed when a person enters the sim ... and derezzed when they leave. Sometimes, very randomly, large portions of these scenes will persist in my viewer ... but are NOT visible to others! These objects can NOT be cleared using SHIFT CTRL R ... or anything else I've found. I can teleport to another sim, return, and they are still there.

If I REZ another scene, these persisting prims will merge into the new scene, creating a horrible mess of tangled prims.

These persistent objects can ONLY be cleared by RIGHT CLICKING each object. After the right click, they properly disappear.
These objects can also be cleared by relogging.

This issue hasn't seemed to garner much interest, but right now, it a horrendous problem on dozens of my regions! I can't think of an easy way to replicate it, as it appears to happen randomly on any region at at time.

Also ref: http://jira.phoenixviewer.com/browse/FIRE-14636 - Multiple Derezzed Objects Persists - Can Only Be Removed with Right Click

@sl-service-account
Copy link
Author

AndreyK ProductEngine commented at 2019-04-09T16:13:32Z, updated at 2019-04-09T16:16:23Z

Does this still repro?
I tried rezzing dozen doors and changing their state - nothing out of order. Tried making sure that they objects get cahched and restored at some point with updates arriving while objects are in cache, but had no luck reproducing this issue as well.

@sl-service-account
Copy link
Author

Anastasia Horngold commented at 2022-08-04T04:47:36Z

We still get occasional reports of this in Firestorm support group, just as a data point.

This was referenced Feb 14, 2024
Closed
Open
Closed
Closed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
project:BUG
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@sl-service-account