Script Acting Different Due to Viewers?

[Czari Zenovka]

This one has me totally baffled!  A customer purchased an animated closet that I build, wanted to resize it  but couldn't even though it was mod/copy. (That is a whole other issue that has since been corrected.)  I met with the customer and, after seeing where she wished to place the closet in her home, told her I would create one with different textures to better blend with her decor in addition to making it the size she wished. 

The closet will either pull the user into it and put her through a series of animations as the door opens and closes or she can simply open and close the door without the animations.  I built a new closet using different textures and made it smaller.  The scripts are identical in both.  I sent a copy of the closet to my alt and tested to make sure it worked ok.  Everything was fine, until I delivered it to my customer.

Problem:

Closet A - original closet customer purchased

Closet B - resized/retextured closet

 

Closet A works as it should for the customer. 

Closet B works for the customer when she simply opens/closes the door; however, *after* she uses the animations function of the closet, then later tries to open the door, the door opens inwards instead of out.

We each rezzed the identical closet on her land.  The one I rezzed works fine in both situations.  When I transfer the closet to the customer, the door operates as above.

I would think I have something out of whack with the build if it wasn't that my alt does not experience the same issues as the customer.  The only difference is that I run Phoenix 1.5.2.1185 and my customer is using Firestorm 4.2.2.  I cannot test the closet on Firestorm with my alt because my PC will not run that viewer.  (Will be getting a new PC very soon.)

Could running different viewers affect a script???  I did pull out the original closet last night and checked the entire build, including scripts, to compare with the new one.  The only difference is the rotation of the door.  The original closet door has rotation on z axis at 90 and the new one is at 180.  I built the new one from scratch rather than just retexture the original one and the door rotation on the new one was to get it to open outwards, which it does...for me.

My plan is to now retexture and resize the original closet since it works for my customer and hopefully that will be the solution, but I am still completely perplexed as to why the new closet works differently for my alt than it does for my customer.

[Curious Hazelnut]

---

Czari Zenovka wrote:

This one has me totally baffled!  A customer purchased an animated closet that I build, wanted to resize it  but couldn't even though it was mod/copy. (That is a whole other issue that has since been corrected.)  I met with the customer and, after seeing where she wished to place the closet in her home, told her I would create one with different textures to better blend with her decor in addition to making it the size she wished. 

The closet will either pull the user into it and put her through a series of animations as the door opens and closes or she can simply open and close the door without the animations.  I built a new closet using different textures and made it smaller.  The scripts are identical in both.  I sent a copy of the closet to my alt and tested to make sure it worked ok.  Everything was fine, until I delivered it to my customer.

Problem:

Closet A - original closet customer purchased

Closet B - resized/retextured closet

 

Closet A works as it should for the customer. 

Closet B works for the customer when she simply opens/closes the door; however, *after* she uses the animations function of the closet, then later tries to open the door, the door opens inwards instead of out.

Did you have both copies of Closet B rotated the same way? It sounds like you might be using llSetRot() instead of llSetLocalRot() on the closet doors to open/close them.

We each rezzed the identical closet on her land.  The one I rezzed works fine in both situations.  When I transfer the closet to the customer, the door operates as above.

I would think I have something out of whack with the build if it wasn't that my alt does not experience the same issues as the customer.  The only difference is that I run Phoenix 1.5.2.1185 and my customer is using Firestorm 4.2.2.  I cannot test the closet on Firestorm with my alt because my PC will not run that viewer.  (Will be getting a new PC very soon.)

Could running different viewers affect a script???  I did pull out the original closet last night and checked the entire build, including scripts, to compare with the new one.  The only difference is the rotation of the door.  The original closet door has rotation on z axis at 90 and the new one is at 180.  I built the new one from scratch rather than just retexture the original one and the door rotation on the new one was to get it to open outwards, which it does...for me.

Definitely sounds to me like you missed a step in the math on the llSetRot() or llSetLocalRot() in the script. The 90 vs 180 degree start rotations are probably what is messing it up.

My plan is to now retexture and resize the original closet since it works for my customer and hopefully that will be the solution, but I am still completely perplexed as to why the new closet works differently for my alt than it does for my customer.

---

 To actually answer the question posed. llSetRot() and llSetLocalRot() run entirely in the region server and are not affected by the viewer. If you used llTargetOmega() to rotate the doors, that does run in the Viewer and could be affected by different viewers.

 

[Darrius Gothly]

Czari,

Edit Closet A, select "Edit Linked" and make a note of the Rotation for each prim in the Closet. Then do the same for Closet B. Any parts that have different Rotation settings between the two are suspect. See if you can set the Closet B prim parts to have all the same Rotations as the Closet A prim parts. This may require you resize and retexture some of the parts.

Also make SURE that the Root Prim in Closet B is the SAME Prim as that in Closet A. When you select and edit Closet A, the prim highlighted in yellow is the Root Prim. Double-check that the link order is the same and the Root Prim are the same between the two.

[Czari Zenovka]

Thank you for responding, Curious.  Scripts literally give me a migraine.  I know just enough about very simple scripts to tinker with them.

Did you have both copies of Closet B rotated the same way? It sounds like you might be using llSetRot() instead of llSetLocalRot() on the closet doors to open/close them.

When I checked last night, the Closet B door was rotated differently than Closet A. (A door has rotation on z axis at 90 and B at 180.)  I didn't think to check the main closet body rotation.  Will do that.  I will check the scripts when I go in world to see which Rot is being used.

Here's something else (didn't want to muddy up the waters with this since my main issue is the door working differently for my customer than my alt) - I originally used one script when I built the closet but that script would't allow the door to be open/closed independent of going through the animations.  I can't recall now how this came about, but somewhere down the line I added a second script for that purpose with a timer for how long the door will stay open.  The fact that I'm using two scripts in the door is likely because I couldn't figure out how to combine them and having both in them does what I want.  A bit muddy in scripting terms, but it works...lol.  After I figure this issue out, my next goal is to figure out how to combine the two door scripts.  I know the script with the timer is llSetLocalRot().  I don't have the foggiest idea of the difference between it and llSetRot(), which I am pretty sure is in the other door script.

(I have taken many, many classes on scripting during my time in SL, including a private one - meaning someone I knew who just offered to teach 10 of his friends - by a master scripter.  I understand and can write scripts until it starts getting, to me, complicated...which is very soon.  Point is..I really have tried to understand this.  My little brain just protests.)

Definitely sounds to me like you missed a step in the math on the llSetRot() or llSetLocalRot() in the script. The 90 vs 180 degree start rotations are probably what is messing it up.

Will start with correcting this part and pray that it works. 

To actually answer the question posed. llSetRot() and llSetLocalRot() run entirely in the region server and are not affected by the viewer. If you used llTargetOmega() to rotate the doors, that does run in the Viewer and could be affected by different viewers.

Oh man...I think there's a llTargetOmega() in one of the scripts too.  Guess I need to read up on the differences of all these. *See Edit

Thank you so much again for the detailed response.

ETA:  Looking at the scripts now and neither of them have llTargetOmega()  so that can't be the issue with the viewers (good info to know, though) - which is even more puzzling that my alt doesn't have the issue with Closet B.

I did find both llSetRot() and llSetLocalRot() in one of the door scripts.  Will post both scripts for the heck of it.  If anyone knows how to combine the two I would LOVE it!!!

 

[Czari Zenovka]

Hi there, Darrius   Thank you for responding.

---

Darrius Gothly wrote:

Czari,

Edit Closet A, select "Edit Linked" and make a note of the Rotation for each prim in the Closet. Then do the same for Closet B. Any parts that have different Rotation settings between the two are suspect. See if you can set the Closet B prim parts to have all the same Rotations as the Closet A prim parts. This may require you resize and retexture some of the parts.

Since Closet A works in all conditions for all people - could I just unlink it, do the resizing/retexturing on it, and then relink?  It seems that this method would work considering I'm not changing any of the rotations on Closet A; but after this...nothing surprises me...lol.

Also make SURE that the Root Prim in Closet B is the SAME Prim as that in Closet A. When you select and edit Closet A, the prim highlighted in yellow is the Root Prim. Double-check that the link order is the same and the Root Prim are the same between the two.

The Root Prim is identical in both; it has to be the back prim with the animations in it for them to work, so that is ok.  I do always link in the same order, so that should be ok as well.

---

Back to the drawing board.  

[Darrius Gothly]

Yup, you can unlink all the parts, fix the sizing/texturing/rotations then relink in the proper order. That will probably fix it.

[Czari Zenovka]

This is the original script I used with the closet.  It worked with the animation script but wouldn't allow me to open/close the door independently:

default
{
    link_message(integer sender, integer n, string s, key k)
    {
        if ( s == "OPEN")
        {
            llSetLocalRot((rotation)llEuler2Rot(<0, 0, 300>*DEG_TO_RAD));
        }
        else if(s == "CLOSE")
        {
            llSetLocalRot((rotation)llEuler2Rot(<0, 0, 180>*DEG_TO_RAD));
        }
    }
}

 

I then added this script to be able to independently open/close the door and be able to set a time interval:

// improved door script by Ezhar Fairlight
// features: automatic closing, workaround for rotating out of position,
// doesn't mess up when moved, adjustable direction (inwards/outwards)
// updated for SL 1.1 damped rotations, small bugfix

// ********** USER SETTINGS HERE **********
float       TIMER_CLOSE = 5.0;      // automatically close the door after this many seconds,
                                    // set to 0 to disable

integer     DIRECTION   = 1;       // direction door opens in. Either 1 (outwards) or -1 (inwards);
// ********** END OF USER SETTINGS **********



integer     DOOR_OPEN   = 1;
integer     DOOR_CLOSE  = 2;

vector      mypos;      // door position (objects move a tiny amount
                        // away from their position each time they are rotated,
                        // thus we need to workaround this by resetting
                        // the position after rotating)


SetLocalRot(rotation localrot) {
    llSetRot(localrot / ( (ZERO_ROTATION / llGetLocalRot()) * llGetRot()));
}

door(integer what) {
    rotation    delta;
    rotation    rot;

    llSetTimerEvent(0); // kill any running timers
    
    if ( what == DOOR_OPEN ) {
        delta = llGetLocalRot() * llEuler2Rot(<0, 0, DIRECTION * PI_BY_TWO> * 1.2);
        SetLocalRot(delta);
        
    } else if ( what == DOOR_CLOSE) {
        
        delta = llGetLocalRot() * llEuler2Rot(<0, 0, -DIRECTION * PI_BY_TWO> * 1.2);
        SetLocalRot(delta);
    }
}
        

default {   // is closed
    on_rez(integer start_param) { // reset, so we store the new position
        llResetScript();
    }
    
    state_entry() {
        mypos = llGetPos();     // remember where we're supposed to be
    }
    
    touch_start(integer total_number) {
        door(DOOR_OPEN);
        llMessageLinked(LINK_SET,0,"open",NULL_KEY);
        state is_open;
    }
    
    moving_end() {  // done moving me around, store new position
        mypos = llGetPos();
    }
}

state is_open {
    state_entry() {
        llSetTimerEvent(TIMER_CLOSE);
    }
    
    touch_start(integer num) {
        door(DOOR_CLOSE);
        llMessageLinked(LINK_SET,0,"close",NULL_KEY);        
        llSetPos(mypos);        // workaround for tiny movements during rotation
        
        state default;
    }
    
    timer() { // it's time to close the door
        door(DOOR_CLOSE);
        llMessageLinked(LINK_SET,0,"close",NULL_KEY);
    
        llSetPos(mypos);        // workaround for tiny movements during rotation
        
        state default;
    }
    
    moving_start() { // close door when door is being moved
        door(DOOR_CLOSE);
        llMessageLinked(LINK_SET,0,"close",NULL_KEY);
        
        state default;
    }
}

[Darrius Gothly]

Yup, the Rotation of the door prim is gonna make a difference on how it behaves.

[Czari Zenovka]

---

Darrius Gothly wrote:

Yup, the Rotation of the door prim is gonna make a difference on how it behaves.

---

Ok, really stupid question, but can you spell it out for me, please?  What rotation should go with what rotation in the door prim? 

ETA:  And since I don't see TargetOmega in those scripts, which is what Curious said was viewer-dependent...why don't I have a problem when my alt uses the closet?  *Tearing my hair out*

 

[Darrius Gothly]

---

Czari Zenovka wrote:

---

Darrius Gothly wrote:

Yup, the Rotation of the door prim is gonna make a difference on how it behaves.

---

Ok, really stupid question, but can you spell it out for me, please?  What rotation should go with what rotation in the door prim? 

ETA:  And since I don't see TargetOmega in those scripts, which is what Curious said was viewer-dependent...why don't I have a problem when my alt uses the closet?  *Tearing my hair out* 

---

The "problem" is even more insidious than you suspect. It has to do with the orientation of the closet when it's rezzed. When you rezzed it from your Alt, you no doubt left it sitting in the orientation it had on rez. But when you tested it with the customer, she and you most likely rotated it to fit into the space and location set aside for it. Combine the local orientation rotation with the way the script is written AND the rotation settings of the door prim and .. Presto! Total fuuuu .. ummm .. unexpected behavior.

Try rezzing it, leaving it in the on rez orientation .. and it'll work. Now rez more copies, each new one rotated 90 degrees more from the on rez orientation and watch what happens.

Then take a smoke break, glue some hair back on .. and cackle maniacally as the sanity dribbles from your ears.

[Rolig Loon]

You're putting yourself through a lot of trouble by worrying about the global rotation of the cabinet.  All that counts is the local rotation of the door, even if you turn the cabinet around.  Just keep track of what the local rotation is when the door is open and when it's closed.  There's no reason for having two scripts either, and one of them is way longer than it needs to be.  Here's Void Singer's simple door script, modfied (but not tested in world) by the addition of a timer that should close it automatically.  You ought to be able to just drop it in your door.

/*//( v7-D Simple Hinge Action )--//*//*//-- Works At ANY Angle --//*//*//-- NOTES: works in ANY single prim door, linked or un-linked works in multi-prim doors NOT linked to a larger structure Never needs reset (even after moving/rotating)//*//*//-- REQUIREMENTS: Root should either be a cylinder (to represent a hinge) or half cut prim; I suggest Box, pathcut start=.125, end=.625//*//*//-- CAVEAT: Single prim doors are limited to 5m width Treats current position as closed when reset//*/ /*//-- USERS MODIFY HERE v --//*/integer gIntSwing = 90; //This is the number of degrees through which the door should swing/*//-- use -# to reverse the direction of swing, eg. -90; --//*/float gTime = 5.0;  // This is the number of seconds before the door closes againrotation gRotSwing;integer gOpen;default{	state_entry()	{		gRotSwing = llEuler2Rot( <0.0, 0.0, (float)gIntSwing * DEG_TO_RAD> );		gOpen = FALSE;    }    	touch_end( integer vIntNul )	{		gOpen = !gOpen;		llSetLocalRot( (gRotSwing = (ZERO_ROTATION / gRotSwing)) * llGetLocalRot() );		llSetTimerEvent(gTime);	}	timer()	{		if (gOpen)		{			gRotSwing = (llEuler2Rot( <0.0, 0.0, (float)gIntSwing * DEG_TO_RAD>));			llSetLocalRot(gRotSwing * llGetLocalRot());			gOpen = FALSE;		}		llSetTimerEvent(0.0);	}}/*//-- IF Redistributing as-is:Please leave script full permissions & include all comments so that others may learn and use//*/

 

[Czari Zenovka]

THANK YOU, Rolig!!!  You've come to my rescue on more than one occasion.  I thought there must be a way to combine those two door scripts.  I even tried, but was apparently putting the timer in the wrong place on the smaller script.

Do I need to have the z door axis set to 90 to be consistent with the script, or does it matter?

(Whew...was worried there for a few - I don't smoke!!!)

Many thanks again, Rolig...can't wait to try it out!!!

[Rolig Loon]

Don't thank me.  Thank Void.  That script of hers has to be the easiest door script in SL.  You can add all sorts of bells and whistles to it, but the heart --- the stuff in the touch_end event -- is what really counts.  I can't get in world to test that timer I slapped in there, BTW, but it looks right.  The door should still respond properly to touches, but should also close automatically in 5 seconds if the last touch opened it.

Yes, you do have to have the door's Z-Axis as its rotation axis, because that's the only way you can do a path cut on a cube. The script will work fine if you change the rotation axis, but it will rotate the door around its center, like a butterfly valve.

[Czari Zenovka]

---

Rolig Loon wrote:

Don't thank me.  Thank Void.  That script of hers has to be the easiest door script in SL.  You can add all sorts of bells and whistles to it, but the heart --- the stuff in the

touch_end

event -- is what really counts.  I can't get in world to test that timer I slapped in there, BTW, but it looks right.  The door should still respond properly to touches, but should also close automatically in 5 seconds if the last touch opened it.

Yes, you do have to have the door's Z-Axis as its rotation axis, because that's the only way you can do a path cut on a cube. The script will work fine if you change the rotation axis, but it will rotate the door around its center, like a butterfly valve.

---

Thank you for posting the script here and I will definitely thank Void.   I've experienced the butterfly valve deal before...lol.

I just received an IM from a friend of mine who said that the Firestorm v. 4.2.1 was doing very odd things to doors and 4.2.2 addressed this as well as some other bugs.  My customer said she is using 4.2.2, however, so that shouldn't be an issue.

 

[Rolig Loon]

There's no reason why the viewer should make any difference to a door at all.  A script like this one or the ones you were using before does all of the work server-side, so your graphics card will see exactly the same movement that mine does, regardless of whether we are using Firestorm, V3, Catznip, Imprudence, or even 1.23.  That might not be true for scripts that depend on llTargetOmega or llSetKeyframedMotion, but even there I'd be surprised if we saw anything different.

[Czari Zenovka]

---

Rolig Loon wrote:

There's no reason why the viewer should make any difference to a door at all.  A script like this one or the ones you were using before does all of the work server-side, so your graphics card will see exactly the same movement that mine does, regardless of whether we are using Firestorm, V3, Catznip, Imprudence, or even 1.23.  That might not be true for scripts that depend on

llTargetOmega

or

llSetKeyframedMotion

, but even there I'd be surprised if we saw anything different.

---

That is what is so puzzling and led me to these forums for advice/help.  In looking back on the two scripts I was using, I don't see either of the two elements that could cause a viewer difference.  My customer and I were standing on her land side by side, facing the same direction.  Each of us rezzed Closet B facing us (thus both the same direction) but the closet I rezzed and used worked perfectly, while the one my customer rezzed (exact copy of mine) had the door go wonky, but only after going through the animation sequence.  If she didn't do that, then the door open and closed perfectly.  The same closet was rezzed by my alt on a different sim and it still worked perfectly.  That is what is so crazy-making about this situation.

Hopefully all will be well once I install the new script. 

[Xiija]

Just curious...

in a situation like this, could you add a listen, and if the chat is "reset"

have it llResetScript(): ...would that reset the position / rotation to a new base value?

[Curious Hazelnut]

Thanks for saving me the time. I was going help merge the scripts, too.

---

Rolig Loon wrote:

... There's no reason for having two scripts either, and one of them is way longer than it needs to be.  Here's

Void Singer's simple door script

, modfied (but not tested in world) by the addition of a timer that should close it automatically. 

...

[Czari Zenovka]

This is now 6 days and counting I've been trying to resolve this issue.  What has been tried to date:

1.  Took out the 2 door scripts and replaced it with the one posted above.  The door opens and closes nicely however, when selecting the choice to go through the animations the avatar is taken into the closet and goes through the animations...except the door doesn't open/close between each one.  That may be some issue with the door script and the animation script but don't want to get into yet another issue.  Have the above script tucked away for use on future doors/lids/etc.

2.  Sent a copy of the closet to a friend who tested it on the same viewer my customer uses (Firestorm 2.2.2) as well as the Zen viewer.  No issues.  This rules out the rotational value theory.

3.  Friend suggested that my customer try resetting scripts after the door goes wonky.  Customer tried that - didn't work.

4.  Friend suggested pathfinding as the culprit.  Customer is on an estate sim.  Contacted her to find out if pathfinding was turned on or off.  She wasn't familiar with pathfinding but researched it and later said that was something she could not do without the estate owner's permission, so still waiting on that theory.  However, even if it is a pathfinding issue, would I not also be experiencing the same issue when I tried the same closet (the copy I rezzed) on the same estate?

5. I find this very interesting - customer said the door went wonky after the first time she went through the animations, but when she did that a second time...with the door still wonky, it corrected itself, but when she thought it was now fixed, she went through the animations a third time and back to wonky door.  The fourth try corrected it again.  So the door works every other time during the animations.  I'm wondering if this could be corrected by a ||reset in the script as suggested by another poster.

6. Will be meeting with my customer again tomorrow.  In the meantime I am going to take the original closet that works for my customer (on the same estate land, pathfinding enabled or not) and just shrink it to the size required and retexture instead of building from scratch as I did with the one that works wierd (for her only).  Technically if the original closet works for her, then just stretching it as one piece and retexturing *should* work.  I may also fool around a bit with adding a ||reset on the original one for the heck of it.

Although this has been frustrating as all get out, I *have* learned a lot in the process that will be beneficial to future builds.  Thank you to everyone who has posted with help and suggestions.

[Czari Zenovka]

WOOT!!!!!  Issue solved today!

A friend and sister forumite offered to test out the closet on her sim with pathfinding turned on.  It was the first time someone else besides my customer got the wonky closet door issue.  Friend turned pathfinding off on the sim and reset it.  Meanwhile her assistant and I went to assistant's sim where the closet appeared to be working properly; however, friend joined us and had figured out the issue. 

The way the scripts were operating together depended on sequence.  For example if the closet door was opened and shut and then the animation sequence selected, when the door was clicked open afterwards, it went wonky - BUT - if one first went through the animation sequence and then opened the closet door, it worked fine.  My options at that point was:

1.  To add to the product description to not open the door before going through the animations, which is cumbersome to say the least

2.  Create two closets - one that simply had an open/close door and the other that was the "fun animations" style, but the closet door would not open/close independently.

My friend then suggested a script that she uses that can "call" to another script and that she thought would work.  I promptly purchased the script but, not being astute at understanding a lot of detailed (to me) scripting stuff, the script didn't work when I tried it.  However, my friend did say it would take some configuring and she would work on that.

Bottom line friend configured the new door script to correctly link to the animation script.  I now have a closet that works properly the way I had intended (and didn't realize it did not until this incident :matte-motes-bashful-cute:).

A huge thank you to everyone who responded to this thread.  Between the advice/scripts offered here, trying to trouble shoot the issue myself with my limited scripting knowlege, and the wonderful friend who solved the issue, I have learned a LOT that will be most helpful in future builds.

[Innula Zenovka]

---

Rolig Loon wrote:

There's no reason why the viewer should make any difference to a door at all.  A script like this one or the ones you were using before does all of the work server-side, so your graphics card will see exactly the same movement that mine does, regardless of whether we are using Firestorm, V3, Catznip, Imprudence, or even 1.23.  That might not be true for scripts that depend on

llTargetOmega

or

llSetKeyframedMotion

, but even there I'd be surprised if we saw anything different.

---

Point of Information -- as you surmised, it was the smooth door script, which uses llTargetOmega, that was borked recently  by some LL changes(which meant Firestorm, certainly, had to put out a fix to their latest release).   I've lost track, rather, of where LL's got to with llTargetOmega (each time they fix one thing about it, they seem to break something else in the process) but I think if people are experiencing difficulties, then it's only going to be with some of the beta  viewers or nightly builds.

[Rolig Loon]

Thanks, Innula.  I hadn't seen Tonya's recap of what went wrong with that Firestorm release, but it all makes sense.