Prim Resize - prim keeps reverting

[uk89201]

 

Hi All, 

I have some steel shutters that listens on a channel and will open/close if a keyword is detected on a channel (emitted by a separate object). I have four such seperate objects to surround the property, each one containing a script similar to the one below (just different PRIM_POS arguments...).

Here is the issue I have... on one of the blinds (prims) (the east facing one), if I close it then travel away from it for a while (walk around within the house so it's hidden from view) then eventually it appears like it's back to it's default "Open" position. Just one out of four blinds... If I re-log... they are all still closed. So some kind of weird graphics glitch.

Now I'm pretty new at this... could someone tell me if this is a common issue... is there solution to the problem through scripting, or is is a client issue (Firestorm for Mac) that I'm unlikely to be able to resolve?

 

integer BLINDS_OPEN = TRUE;

openBlinds() {
           BLINDS_OPEN = TRUE;
           
                                     
           // Door to open position
            llPlaySound("steelBlindsClose",1.0);
            llSetLinkPrimitiveParamsFast(0,[PRIM_POS_LOCAL, <128.97550, 247.33720, 35.87618>,
                                  PRIM_ROT_LOCAL, <-0.00000, -0.00000, 0.70711, 0.70711>,
                                  PRIM_SIZE, <10.93589, 0.04880, 0.27948>   
                                 ]);           
}

closeBlinds() {
           BLINDS_OPEN = FALSE;

           // Door to closed position
            llPlaySound("steelBlindsClose",1.0);
            llSetLinkPrimitiveParamsFast(0,[PRIM_POS_LOCAL, <128.97550, 247.33720, 33.52772>,
                                  PRIM_ROT_LOCAL, <-0.00000, -0.00000, 0.70711, 0.70711>,
                                  PRIM_SIZE, <10.93589, 0.04880, 4.97640>
                                     ]);   
}

default
{
    state_entry()
    {
     llListen(-2640,"",NULL_KEY,"");
     openBlinds();
    }

    
   listen(integer chan, string what, key who, string msg) {
    if(msg == "close") {
        closeBlinds();
    } else if(msg == "open") {
        openBlinds();
    }
   }
    
}

 

Many many thanks!!!

Rob

 

Edited August 12, 2020 by uk89201
Typo/clarification

[Profaitchikenz Haiku]

First thing that is noticeable is that the vector you are giving after PRIM_POS_LOCAL looks more like a region coordinate, change PRIM_POS_LOCAL to PRIM_POS. Also, PRIM_ROT_LOCAL is probably redundant.

My suggestion is to add a line to each of the two functions so that it tells you when it enters each of the two routines using llOwnerSay(). Tell the blind to close, observe that it has closed, then go around the other three blinds closing them. Come back to the first blind and observe it. If it looks open, tell it to open and see what both the visual result and the report from ownerSay gives you. Then close it and observe the results.

Is the order in which you go round the blinds closing them always the same? Does varying it change the behaviour?

To rule out Firestorm I'd suggest repeating the tests with the LL viewer, because if somehow you have discovered an issue with the server (or client) code it will help to establish if it is viewer-dependant. If you have indeed found a situation where a prim changes size and position but then reverts to an earlier size and position for no good reason this is definitely reportable.

[Rolig Loon]

I don't see anything inherently wrong with the script ... at least nothing that would cause that odd behavior.  Unless you are planning to be able to open the blinds individually (in which case, you will put a separate script in each set of blinds and will control them separately with "open" and "close" messages on different channels), it would be more efficient to link them all to the house and use one script to open/close them all at once.  To do that, you'll first need to grab their link numbers in state_entry and then you'll need to modify your two user-defined functions to loop through all the blinds, one after the other.  Or, more elegantly, create a slightly more complicated SLPPF command line that uses PRIM_LINK_TARGET to weld the commands for the separate blinds into a single long command.  None of that will solve  your immediate puzzling problem, but it will be a more efficient use of script resources.

[uk89201]

32 minutes ago, Profaitchikenz Haiku said:

First thing that is noticeable is that the vector you are giving after PRIM_POS_LOCAL looks more like a region coordinate, change PRIM_POS_LOCAL to PRIM_POS. Also, PRIM_ROT_LOCAL is probably redundant.

My suggestion is to add a line to each of the two functions so that it tells you when it enters each of the two routines using llOwnerSay(). Tell the blind to close, observe that it has closed, then go around the other three blinds closing them. Come back to the first blind and observe it. If it looks open, tell it to open and see what both the visual result and the report from ownerSay gives you. Then close it and observe the results.

Is the order in which you go round the blinds closing them always the same? Does varying it change the behaviour?

To rule out Firestorm I'd suggest repeating the tests with the LL viewer, because if somehow you have discovered an issue with the server (or client) code it will help to establish if it is viewer-dependant. If you have indeed found a situation where a prim changes size and position but then reverts to an earlier size and position for no good reason this is definitely reportable.

 

Thanks, I'll get the PRIM_POS and try using that instead. I did actually try the llOwnerSay() trick, closeBlinds() definitely not being trigged.

 

12 minutes ago, Rolig Loon said:

I don't see anything inherently wrong with the script ... at least nothing that would cause that odd behavior.  Unless you are planning to be able to open the blinds individually (in which case, you will put a separate script in each set of blinds and will control them separately with "open" and "close" messages on different channels), it would be more efficient to link them all to the house and use one script to open/close them all at once.  To do that, you'll first need to grab their link numbers in state_entry and then you'll need to modify your two user-defined functions to loop through all the blinds, one after the other.  Or, more elegantly, create a slightly more complicated SLPPF command line that uses PRIM_LINK_TARGET to weld the commands for the separate blinds into a single long command.  None of that will solve  your immediate puzzling problem, but it will be a more efficient use of script resources.

 

Thanks, I'll try linking them and the control objects together, and doing it this way, particularly if it's more efficient this way - thanks. 

 

Since I know the affected blind is in a closed state (since if I relog it's closed), I know it's some kind of weird graphic caching glitch. Like has been suggested, what I've not tried is using a different viewer/windows Firestorm via Bootcamp, I'll give that a go and see if I get the same results. Thanks!

[uk89201]

Upon further testing... it looks like this issue happens with Firestorm for Windows & Mac, but not the official LL viewer. 

[Profaitchikenz Haiku]

Is this a distance problem? Instead of using Say to chat the command, try a shout in case you are more than 20 metres from the centre of the particular blind.

[glen226]

2 hours ago, Profaitchikenz Haiku said:

Is this a distance problem? Instead of using Say to chat the command, try a shout in case you are more than 20 metres from the centre of the particular blind.

Thank you! Sadly no, it’s not a distance issue. I use llRegionSay on the object that sends the open/close messages, and can see that the all blinds close as intended. The issue is, if I move away the east facing one so I can’t see it for a while (I turn the other way and go into a room where the blind is out of view) then sometimes when the blind is back in view, it’s re-drawn as being in the default open state. If I relog, it’s actually still closed as intended. For others that keep the blind in camera view, it’s always closed as intended, so it is as if there is a caching issue/glitch with the prim. I’ll have a look through the Firestorm bug tracker as well just in case...

[uk89201]

The top image is when closeBlinds() is triggered, the second is what sometimes happen when I go out of view (eg. begin to walk downstairs then upstairs so that I don't see the blind and it's re-drawn from cache).

I would think "Hmm, clear cache and retry?" but since it's happening on two instances of Firestorm (mac/windows) I guess not.

[Rolig Loon]

That's a very odd sort of graphics glitch, if that's what it is.  Your script isn't doing anything that involves changing textures or alpha.  It's just resizing and moving things, so I can't see how your viewer is ever being put in a position of having to "remember" what a closed or open blind looks like.  The only scripted changes are all handled by the servers.  The only thing can imagine is that somehow that odd blind is being resized and moved when it's not supposed to be.  There's nothing in your script that should do that, but did you by any chance have a test object nearby when you were developing this thing?  And if so, did you forget to pick it up?  When I am working on a script like this, I tend to rez a prim nearby and stick a simple "Hello, Avatar!" script in it so that I can send trigger messages by just clicking on the thing.  If you made something like that, with a timer in it, or if you left another test script in a child prim of the linkset somewhere, it could be triggering your odd blinds.  Of course, that's never happened to me, but hypothetically it might happen.....  🙄

[uk89201]

2 minutes ago, Rolig Loon said:

That's a very odd sort of graphics glitch, if that's what it is.  Your script isn't doing anything that involves changing textures or alpha.  It's just resizing and moving things, so I can't see how your viewer is ever being put in a position of having to "remember" what a closed or open blind looks like.  The only scripted changes are all handled by the servers.  The only thing can imagine is that somehow that odd blind is being resized and moved when it's not supposed to be.  There's nothing in your script that should do that, but did you by any chance have a test object nearby when you were developing this thing?  And if so, did you forget to pick it up?  When I am working on a script like this, I tend to rez a prim nearby and stick a simple "Hello, Avatar!" script in it so that I can send trigger messages by just clicking on the thing.  If you made something like that, with a timer in it, or if you left another test script in a child prim of the linkset somewhere, it could be triggering your odd blinds.  Of course, that's never happened to me, but hypothetically it might happen.....  🙄

Thank you, I will triple check & confirm!

[glen226]

On 8/12/2020 at 5:01 PM, Rolig Loon said:

I don't see anything inherently wrong with the script ... at least nothing that would cause that odd behavior.  Unless you are planning to be able to open the blinds individually (in which case, you will put a separate script in each set of blinds and will control them separately with "open" and "close" messages on different channels), it would be more efficient to link them all to the house and use one script to open/close them all at once.  To do that, you'll first need to grab their link numbers in state_entry and then you'll need to modify your two user-defined functions to loop through all the blinds, one after the other.  Or, more elegantly, create a slightly more complicated SLPPF command line that uses PRIM_LINK_TARGET to weld the commands for the separate blinds into a single long command.  None of that will solve  your immediate puzzling problem, but it will be a more efficient use of script resources.

I’ve recreated the whole thing from scratch, and this time I’ve linked it all like you suggested, script on root prim using a bunch of 

llSetLinkPrimitiveParamsFast

commands. I’ve not been been able to replicate the issue (but in fairness not tested it thoroughly), but thanks for suggestion re efficiency, it does run a heck of a lot faster now than it did with llRegionSayTo commands.   

[Rolig Loon]

Congratulations.  At this point, it may not be important to figure out what was wrong before, unless you have time on your hands and are still vexed by it.  In the end, the goal is to get a script that works, and it looks like you're there.

[Bugs Larnia]

On 8/13/2020 at 1:41 AM, Rolig Loon said:

That's a very odd sort of graphics glitch, if that's what it is.  Your script isn't doing anything that involves changing textures or alpha.  It's just resizing and moving things, so I can't see how your viewer is ever being put in a position of having to "remember" what a closed or open blind looks like.  The only scripted changes are all handled by the servers.  The only thing can imagine is that somehow that odd blind is being resized and moved when it's not supposed to be.  There's nothing in your script that should do that, but did you by any chance have a test object nearby when you were developing this thing?  And if so, did you forget to pick it up?  When I am working on a script like this, I tend to rez a prim nearby and stick a simple "Hello, Avatar!" script in it so that I can send trigger messages by just clicking on the thing.  If you made something like that, with a timer in it, or if you left another test script in a child prim of the linkset somewhere, it could be triggering your odd blinds.  Of course, that's never happened to me, but hypothetically it might happen.....  🙄

It might be related (and might not), but a few months ago, I had similar issues, but without scripts.... I'd resize a prim manually and it would just revert. This could happen several times and sometimes also happened when I moved a prim using Edit; I'm guessing there might have been an issue in the server processing  the change. That might be what occurred here. The script, as Rolig said, looks ok.

[Kyrah Abattoir]

Reverts happen when your connection is losing packets typically.