[BUG-7412] Object changes by script not showing up always to all users (color/alpha/text)

[sl-service-account]

Steps to Reproduce

I have seen this going on for a couple months now.

My customers have complained that after a user logs in or out of one of my tip jars the floating text does not change. It is supposed to change to say "Username's Tip Jar" when they log in, but instead on some user's screens it still shows as not in use, (which causes some avatars not to know they can now pay the tip jars and a potential loss of income to the user).

In addition to floating text, some of my tip jars change color when logged in and I have seen some of the prims not change on my screen, but other avatars in the room tell me they have changed. They have multiple prims and use llSetLinkColor to change color, but when I have changed it to llSetLinkPrimitiveParamsFast to test that I experienced the same issue. Even implementing multiple instances of llSetLinkPrimitiveParamsFast or llSetLinkColor in a row in the script it is not stopping this behavior.

More recently I have been experiencing problems getting llSetLinkAlpha and llSetLinkPrimitiveParamsFast to work every time while setting up a haunted house. I had only 14 prims linked together and attempted to make them disappear and reappear by script using these functions, but one out of every three or four times at least one or more prims failed to set transparent or visible. I have seen this posted on JIRA as BUG-1786 and BUG-7157, but wanted to mention it here as I feel it may be related.

Actual Behavior

Some object attributes changed by script are not working on everyone's screen all the time. Raising the max cache to 3000 seems to help fix the problem, but not entirely for everyone.

Examples of changes not occurring on everyone's screen:

llSetLinkPrimitiveParamsFast (most notably color and alpha)
llSetLinkAlpha (as seen in BUG-1786/BUG-7157)
llSetLinkColor (when using LINK_SET in my case)
llSetText

Expected Behavior

Color, float text, and alpha changes via script should be reliable on everyone's screen at all times. I do not mind seeing a delay in these functions, but to never see them change on some screens is becoming stressful and decreasing my credibility as a scripter.

Other information

Whirly Fizzle posted this workaround as a comment on BUG-7157, and while it has helped me and my viewer, some of my customers report the errors still happening even after making this change. And further, it shouldn't be required that everyone change the default settings of their viewer to get simple script functions to work as intended.

"There is a workaround for this bug though - if the user raises their maximum bandwidth setting under Me -> Preferences -> Setup then the effects of this bug pretty much disappear.
The default maximum bandwidth setting is 500 (or 700 - depending on the viewer).
Raising maximum bandwidth to 3000 should "fix" this bug (the server caps at 3000 so you gain nothing from setting maximum bandwidth higher then this)."

Attachments

• nochangeexample2.jpg 2014-09-30 10:53:03

Links

Duplicates

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

Original Jira Fields

Field	Value
Issue	BUG-7412
Summary	Object changes by script not showing up always to all users (color/alpha/text)
Type	Bug
Priority	Unset
Status	Closed
Resolution	Duplicate
Reporter	Alicia Stella (alicia.stella)
Created at	2014-09-30T14:53:03Z
Updated at	2014-10-01T23:02:40Z

{
  'Business Unit': ['Platform'],
  'Date of First Response': '2014-09-30T16:46:12.176-0500',
  "Is there anything you'd like to add?": 'Whirly Fizzle posted this workaround as a comment on BUG-7157, and while it has helped me and my viewer, some of my customers report the errors still happening even after making this change. And further, it shouldn\'t be required that everyone change the default settings of their viewer to get simple script functions to work as intended.\r\n\r\n"There is a workaround for this bug though - if the user raises their maximum bandwidth setting under Me -> Preferences -> Setup then the effects of this bug pretty much disappear.\r\nThe default maximum bandwidth setting is 500 (or 700 - depending on the viewer).\r\nRaising maximum bandwidth to 3000 should "fix" this bug (the server caps at 3000 so you gain nothing from setting maximum bandwidth higher then this)."',
  'Severity': 'Unset',
  'System': 'SL Simulator',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': "Some object attributes changed by script are not working on everyone's screen all the time. Raising the max cache to 3000 seems to help fix the problem, but not entirely for everyone.\r\n\r\nExamples of changes not occurring on everyone's screen:\r\n\r\nllSetLinkPrimitiveParamsFast (most notably color and alpha)\r\nllSetLinkAlpha (as seen in BUG-1786/BUG-7157)\r\nllSetLinkColor (when using LINK_SET in my case)\r\nllSetText",
  'What were you doing when it happened?': 'I have seen this going on for a couple months now.\r\n\r\nMy customers have complained that after a user logs in or out of one of my tip jars the floating text does not change. It is supposed to change to say "Username\'s Tip Jar" when they log in, but instead on some user\'s screens it still shows as not in use, (which causes some avatars not to know they can now pay the tip jars and a potential loss of income to the user).\r\n\r\nIn addition to floating text, some of my tip jars change color when logged in and I have seen some of the prims not change on my screen, but other avatars in the room tell me they have changed. They have multiple prims and use llSetLinkColor to change color, but when I have changed it to llSetLinkPrimitiveParamsFast to test that I experienced the same issue. Even implementing multiple instances of llSetLinkPrimitiveParamsFast or llSetLinkColor in a row in the script it is not stopping this behavior.\r\n\r\nMore recently I have been experiencing problems getting llSetLinkAlpha and llSetLinkPrimitiveParamsFast to work every time while setting up a haunted house. I had only 14 prims linked together and attempted to make them disappear and reappear by script using these functions, but one out of every three or four times at least one or more prims failed to set transparent or visible. I have seen this posted on JIRA as BUG-1786 and BUG-7157, but wanted to mention it here as I feel it may be related.',
  'What were you expecting to happen instead?': "Color, float text, and alpha changes via script should be reliable on everyone's screen at all times. I do not mind seeing a delay in these functions, but to never see them change on some screens is becoming stressful and decreasing my credibility as a scripter.",
  'Where': 'All sims I have tested in so far\r\n\r\nMy sim is named "ASD Studios"',
}

[sl-service-account]

Whirly Fizzle commented at 2014-09-30T21:46:12Z

In addition to the BUG-1786/BUG-7157 problem, which appears to be a serverside issue that will affect all viewers, those on interesting based viewers are possibly seeing BUG-7084. The llSetText issue sounds very like like BUG-7084.

Curious if you yourself have seen the llSetText problem Alicia. Youre using an older version of Firestorm viewer without the interesting changes.
The BUG-7084 set of problems will only affect those using the official viewer and Firestorm 4.6.7 release. Firestorm 4.6.5 does not have the BUG-7084 bug.

[sl-service-account]

Alicia Stella commented at 2014-09-30T22:26:33Z

Thanks for the info. I haven't been paying much attention to the new release, just to what my customers have been complaining about recently. I don't see the floating text issues on my v4.6.5 firestorm, but I do see the color/alpha issues. Users on the newer firestorm are the ones seeing the floating text issues so that makes sense. Hope a new viewer corrects that issue soon.

[sl-service-account]

Whirly Fizzle commented at 2014-09-30T22:34:18Z

Yeah pretty sure the floating text part of this problem is BUG-7084 then.
Anyone using the official viewer or a TPV that has merged in the interesting code will be affected by it, so thats likely to be a high percentage of your customers.

The colour and alpha problem is probably also partly BUG-7084 for those on interesting based viewers.
BUG-7084 will cause those on affected interesting viewers to have a high chance of not seeing the colour and alpha changes if they had their camera facing away from the objects when they changed their colour/alpha state and then turned their camera view to face those objects.
There is an even stranger part to BUG-7084 which will cause the colour/alpha state to randomly revert to an earlier state even when the state change was seen correctly at the time it happened - probably when the affected objects are out of view for a time and then come back into view.

[sl-service-account]

Alicia Stella commented at 2014-09-30T22:39:21Z

Haha, one of my customers thought he was going crazy because it only messed up when he was facing a certain way. He'll be happy to know if wasn't just in his head.

[sl-service-account]

Whirly Fizzle commented at 2014-09-30T22:42:26Z

One workaround for this bug that will help your customers on interesting based viewers - when they see an object with the wrong floating text or wrong colour/alpha, get them to try right clicking the affected objects. This does not always work. If it does not work, get them to change their active group tag - usually works.
However, be aware that if a user on an interesting based viewer changes their active group tag before all objects have loaded (soon after logging into that region or soon after teleporting into that region), then this will cause a lot of objects to never render and be invisible, which can only be fixed by a relog - this is BUG-6299

[sl-service-account]

Whirly Fizzle commented at 2014-09-30T22:43:12Z

Haha, one of my customers thought he was going crazy because it only messed up when he was facing a certain way. He'll be happy to know if wasn't just in his head.

lol no. He isn't crazy at all. This is a big problem with the interesting viewers :(

[sl-service-account]

Maestro Linden commented at 2014-10-01T23:02:38Z

I think Whirly is correct - all of the symptoms described in this bug can be explained by BUG-7084 and BUG-1786.