llSetPrimitiveParams borked in 1.23.1 (119104)?

Ok, I've just seen llSetPrimitiveParams([PRIM_FULLBRIGHT,ALL_SIDES,TRUE]); not working in the new 1.23 viewer. the full bright will change, but only if the item is right clicked. I've used this script successfully in the previous rc release and NEVER had a problem using this script. any thoughts?

I've just confirmed this is a problem with the new RC viewer, used the same script and watched with an older viewer and it works perfectly.

default
{
state_entry()
{
llListen(3332143,"",NULL_KEY,"";
}

listen(integer channel, string name, key id, string message)
{
if ( llGetOwner() == llGetOwnerKey( id ))
{

if (message == "day"
llSetPrimitiveParams([PRIM_FULLBRIGHT,ALL_SIDES,TRUE]);//Full Bright on;

if (message == "night"
llSetPrimitiveParams([PRIM_FULLBRIGHT,ALL_SIDES,FALSE]);//Full Bright off

}
}
}

The problem repros here, even though show updates shows that the viewer knows about the change :/

I don't see a JIRA entry for this one yet.

just checked my script with an older viewer, it works fine. seems like the rc is borked. I wonder if ALL prim paramaters are borked or just the fullbright.

Well I just tried I script I have that sets the LIGHT and GLOW paramters that way,and those seem to be working fine. So it does indeed seem to be FULLBRIGHT only. Or at least Light and Glow can be excluded.

I tested FULLBRIGHT in the RC 1.23 viewer.
Not with ALL_SIDES but on a single side and that does NOT confirm your findings.
It works as normal.
I find no face attributes failing.

I should have added I did indeed see Fullbright failing with ALL_SIDES. so that's two confirms.

Definitely a glitch here in the new viewer.
I tried selecting a side, no, it doesnt work. it will work ONCE. but then the off and on doesnt work again even with one face. so its full_bright function is borked. same problem persists, it requires actually touching the face with a right click to change it.

Also discovered if you have two prims linked, or unlinked, turning on fullbright with script (or off), when it fails to perform, you can touch one prim and both prims will function properly the way the button was set. hmmmmm

FULLBRIGHT has always been glitchy... turning off and on by itself with prim updates... it's probably in how the property is stored transferred and read... doesn't surprise me it's even more glitchy now.

Void, I've been using this script with no problems for quite some time without any glitches. now its totally messed up with the new rc client

my point was it's a viewer issue, and there have been (and still occasionally are) glitches with full bright.

at a guess I'd say it's somewhere in what is and isn't included in partial vs full prim updates and how the viewer handles both... by all means, send it to jira if you can get a reliable reproduction

Be sure when you post this issue that you upload a copy of the log file. I suspect that different viewer graphics settings may be causing this (and explain the non-confirm).

Now I can confirm it is not showing the fullbright state.
Using this toggle script:

// Studio Dora Flash Light script, Dora Gustafson d.2008-01-27

float toff_unit = 2.0;
float ton_unit = 1.0;

switch( integer lights_on )
{
    llSetPrimitiveParams( [ PRIM_FULLBRIGHT, ALL_SIDES, lights_on  ] );
}

default
{
    state_entry()
    {
        llSetTimerEvent(toff_unit);
        switch( FALSE );
    }

    timer() { state lightOn; }
}

state lightOn
{
    state_entry()
    {
        llSetTimerEvent(ton_unit);
        switch( TRUE );
    }

    timer() { state default; }
}

I see no fullbright toggling...
but when I open the inworld texture editor I can see the check mark toggle
It works correct on the SL standard viewer: 1.22.11 (113941)

just describe that the visual is not showing, but that the edit panel does show the correct fullbright state and make sure the client version is listed in the versions affected space. make sure you file it as a VWR bug too.

I've seen just about all llSetPrim~ changes not taking effect unless an outside measure is taken, such as clicking, selecting, moving, walking, and so on. Also, llSetAlpha would go full opaque, but, not full alpha. Setting fullbright off will work, on won't. And, even the selection outlines, they'd come up while editing, but not go away when done. (>_<

I think ~this ~ Jira is the start of a potential meta issue on the subject. (^_^)

https://jira.secondlife.com/browse/VWR-13097

Not just fullbright, but I have also seen this issue with an objects scripted shine settings.

I can confirm this same problem with llSetAlpha() too.

I was trying to figure out why some things weren't disappearing properly (pieces of "animating" avatars, etc.) so I tested it out.

Link 4 prims together and put this script in the root prim:

default
{
    state_entry()
    {
        llListen(0, "", llGetOwner(), "");
    }

    listen(integer channel, string name, key id, string message)
    {
        if(message == "1")llMessageLinked(LINK_SET, 1, "", "");
        else if(message == "2")llMessageLinked(LINK_SET, 2, "", "");
         else if(message == "3")llMessageLinked(LINK_SET, 3, "", "");
          else if(message == "4")llMessageLinked(LINK_SET, 4, "", "");
        
    }
}

Then put this script in all 4 prims:

default
{
    link_message(integer sender_num, integer num, string str, key id)
    {
        if(num == llGetLinkNumber())
        {
            llSetAlpha(0.0,ALL_SIDES);
            
        }
        else 
        {
            llSetAlpha(1.0, ALL_SIDES);
            
        }
        
    }
}

To set each prim's alpha to 0 and the other prims to 1, you just say its number (1,2,3 or 4) on channel 0.

I noticed pretty quickly that this wasn't working very well, so I thought I'd use hover text to show me what was happening. I copied the linked set of prims and replaced the scripts in each prim with this one.

default
{
    link_message(integer sender_num, integer num, string str, key id)
    {
        if(num == llGetLinkNumber())
        {
            llSetAlpha(0.0,ALL_SIDES);
            llSetText("Alpha 0", <1,1,1>, 1.0);
        }
        else 
        {
            llSetAlpha(1.0, ALL_SIDES);
            llSetText("Alpha 1", <1,1,1>, 1.0);
        }
        
    }
}

The only difference is llSetText() has been added, but the prims display properly when this script is used.

sounds like they demoted it to only be read into the viewer on full prim updates....

similar to the problem with small rotation changes only showing up when they passed a cumulative threshold in the viewer

as a temp workaround, anything that trigger a pull prim update should work to get it showing correctly (although, alpha used to be one of the things that would trigger it.)

Void, as a scripting illiterate could you give me an example of a full prim update as related to trying to toggle fullbright off and on? thanks so much

Hi Blaze. I am not Void but can tell you how to make it work, show updates is in the debug menu. Red triangles are full updates and blue triangles are part updates.

This is one way to make it happen. Text is a space and it can't be empty or it won't work. Color has the time in it too because llSetText has to be different before the sim sends updates.

llSetText(" ", <1.0/llGetTime(), 0.,0.>, 0.0);

Woops. I fixed a typo.

never in a million years would I have figured that workaround out. thanks so much cerise.

Woops, no I am a dummy. That division won't change the text color when llGetTime turns into a large number so try another number that changes and really means it.

float gColorHack = 1.0; // global


// in the script bowels
llSetText(" ", <gColorHack = 1.0 - gColorHack), 0.0, 0.0>, 0.0);

ok adding the text script worked GREAT for an empty box. Now, my build requires a rotation script for the box. Your workaround wont work with the additional rotation script in it. Any suggestions for that?


Just using this simple targetomega rotate script:


default
{
state_entry()
{
llTargetOmega(<0,0,1>,0.1,1.0);
}

}

I would suspect that forcing full updates increases network traffic to some degree.

I'd suggest tracking this in JIRA so you can take the extra update out if it's fixed.

Argent, you're damned if you do and damned if you don't. Adjusting products because of a fault in the RC viewer. You never know how many people are using the rc and have your item borked. You never know if Lindens will ever get around to fixing the problem. Or if its simply a change they've made to have a more "predictable" SL experience

Personally, as a builder and scripter and seller, I don't adjust my stuff for an RC unless I'm pretty damn sure that the change is permanent. And if there's a problem in the RC I let people know and ask them to vote on the JIRA and promise a free upgrade if the bug's not fixed when it goes to release.
That's why you track the JIRA.