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

[BUG-10459] Scripted alpha mode changes don't show up until after relog #786

Open
1 task
sl-service-account opened this issue Oct 12, 2015 · 2 comments
Open
1 task

Comments

@sl-service-account
Copy link

sl-service-account commented Oct 12, 2015

Steps to Reproduce

Writing a rather large and complex texture changer script that requires - among many other things - alpha mode to be switched on some faces. I couldn't figure out why it didn't work so I made the simple test script above to eliminate all possibilities of faulty code.

Actual Behavior

I made this simple test script:


integer AlphaMode;

default
{
touch_start(integer total_number)
{
AlphaMode=!AlphaMode;
llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_ALPHA_MODE,ALL_SIDES,(AlphaMode+1),12]);
}
}


A very simple script with no room for bugs but it doesn't seem to work. No matter how many time you click on the prim that contained it, it still shows up in red with alpha channel view on and checking the prim manually shows that it stays in alpha blending mode.

However, the script works just fine in Firestorm and if you relog, the prim shows up with the correct alpha mode.

Obviously what happens is that the viewer fails to update the data when alpha mode is swithced with a script.

Expected Behavior

I expected the viewer to show the object correctly.

Other information

Links

Related

Original Jira Fields
Field Value
Issue BUG-10459
Summary Scripted alpha mode changes don't show up until after relog
Type Bug
Priority Unset
Status Accepted
Resolution Accepted
Reporter RenateIsabella (renateisabella)
Created at 2015-10-12T10:17:43Z
Updated at 2017-05-08T23:45:57Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2015-10-13T06:31:34.085-0500',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'System': 'SL Viewer',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': "I made this simple test script:\r\n\r\n-------\r\n\r\ninteger AlphaMode;\r\n\r\ndefault\r\n{\r\n    touch_start(integer total_number)\r\n    {\r\n        AlphaMode=!AlphaMode;\r\n        llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_ALPHA_MODE,ALL_SIDES,(AlphaMode+1),12]);\r\n    }\r\n}\r\n\r\n-------\r\n\r\nA very simple script with no room for bugs but it doesn't seem to work. No matter how many time you click on the prim that contained it, it still shows up in red with alpha channel view on and checking the prim manually shows that it stays in alpha blending mode.\r\n\r\nHowever, the script works just fine in Firestorm and if you relog, the prim shows up with the correct alpha mode.\r\n\r\nObviously what happens is that the viewer fails to update the data when alpha mode is swithced with a script.\r\n",
  'What were you doing when it happened?': "Writing a rather large and complex texture changer script that requires - among many other things - alpha mode to be switched on some faces. I couldn't figure out how it worked so I made the simple test script above to eliminate all possibilities of faulty code.",
  'What were you expecting to happen instead?': 'I expected the viewer to show the object correctly.',
}
@sl-service-account
Copy link
Author

Ansariel Hiller commented at 2015-10-13T11:31:34Z

This is caused by https://bitbucket.org/lindenlab/viewer-release/commits/a79540758404b937ff5d28f97effce9e3ab6b83e

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2015-11-08T07:18:21Z

Bug also reproduces with manual alpha mode changes.

  • Login Avatar A & Avatar B on Second Life 3.8.6 (305981).
  • Avatar A manually change alpha mode on any object.

Observed

  • Avatar A correctly sees the alpha mode change.

  • Avatar B does not see the alpha mode change.

  • Avatar B will only see the alpha mode change after relogging.

  • Reproduces for all combinations of alpha mode changes between None, Masking, Blending & Emissive.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant