Sculpts Gone

[Barnard Smith]

see above...just cleaning up a little

[Barnard Smith]

Please see above...just cleaning up a little

[Oren Hurvitz]

Cleaning is good

I wasn't aware that this problem happened on sculpts that don't have the "Phantom Child 3” script. That's a communications problem: you showed the problem to Ilan, and he showed it to me, and the two sample prims that he happened to show me both had this script. I'd like to visit the world with you so that you can show me more examples.

Regarding your question about the mechanics of how this happens: the script operates in two steps. First, it changes the prim to a regular box. At this point the prim doesn't have the sculpt map anymore. In the second step the script puts back the sculpt map and changes the prim from a box to a sculpt. So if anything causes the script to fail after the first step then the prim will remain a box, which is the problem that we've seen.

I don't know why a prim that isn't related to this script would change from a sculpt to a box. I've been examining the OpenSim source code and I didn't find any reason why that would happen. So either there's a reason but I didn't see it, or the problem is in the viewer. As I've said, I will investigate further whether OpenSim is involved. It's possible that the script does have a bug but due to different server-side implementations in Second Life and OpenSim it was never a problem before.

Another thing that I will do is to add logging messages to OpenSim that indicate whenever a sculpt prim becomes non-sculpt. That way, if the problem returns it will be much easier to see when it happened, and hopefully why.

I wish I could point to a change in Kitely that is related, but there's nothing that is relevant. I think it's just a matter of bad luck. Similarly, the reason the copy of the world is faster than the original world is just because of whoever you're sharing that server with at that time.

About the world copy: I think you should delete it now. I created it because you said you don't have a backup of your world, but it would be better to use Export to create the backup. We will refund the KC that were used for its storage, of course; this was just a temporary safety measure.

[Ohn Lang]

Hi Barnard,

...If you can't unlink the prim, and you must use a script, then try using a different script. This page contains many variations of the phantom-child script, which might work better: http://wiki.secondlife.com/wiki/Phantom_Child. Try to use a script that doesn't change the shape to a box and back as that would be safer....

Just an FYI, the script under "New Functions" uses llSetLinkPrimitiveParamsFast, which is not fully/totally correctly implemented in opensim (see notes, search for function name in http://opensimulator.org/wiki/LSL_Status/Functions), plus that parameter, PRIM_PHYSICS_SHAPE_TYPE, is relatively new and I don't think its supported yet either, at least I get an error (does not exist...) when I try using it. This one I mean:

Code: Select all

default
{
    state_entry()
    {
        llSetLinkPrimitiveParamsFast(LINK_THIS,[ PRIM_PHYSICS_SHAPE_TYPE,PRIM_PHYSICS_SHAPE_NONE]);
    }
    
}

If that would work, it would be TOTALLY AWESOME!!!

later: oops, the on_rez was from my script not the original in the wiki, removed for accuracy

[Barnard Smith]

Hi Oren,

I’m sorry my message is so delayed but I needed some time to get my head on straight. Your explanation of the function and usefulness of the script, (in summarizing) ‘it may work well in other games, we don’t know their server side set up, but the script works in two phases, getting hung up in the first phase, and we don’t know why it worked here in Kitely, but suddenly it doesn’t anymore, and we don’t know why.’ This explanation doesn’t really set well with me. Why would this script be so useful in SL and Opensim, that operates without error suddenly be a problem in OSGRID-Kitley, and why would it become a problem only after two and a half weeks of flawless usefulness in Kitely? It doesn’t make sense, and so far any Sculpty-phantom-script I try in Kitely doesn’t currently function either.

You asked me to send you some examples of sculpts that were affected that did not contain the script. When I first walked Ilan Tochner around showing him all the damage with each build I brought him to a barn and pointed out that all the doors and windows were gone. This barn is totally made out of sculpt and had no script. Since the rollback to the pervious backup this barn is fixed and now has windows and doors but it didn’t when I had shown it first to Ilan. That was my best example, and today I will look for others.

What I would like to do is send to you 4 builds that were most heavily affected by sculpty malfunction. It will be 3 houses and the barn I spoke of above. If the builds I send you are like what I have seen taken from my own Kitely inventory they will be just as I built them with no sculpt deterioration. What I’d like you to consider doing is setting these builds on Sim that will get rezzed off and on like my own sim and see how long it takes for the builds to deteriorate to what we both saw in my world. My bet is that it will repeat my own experience, they will be fine at first and at some point later on sculpt deterioration will occur, but not just right out of the box. Please let me know if I can send the working samples. Thank you

[Ilan Tochner]

Hi Barnard,

I'll let Oren reply to your comment I just wish to make the following quick clarifications:

OpenSim and Second Life use two different server technologies with similar but different capabilities. As a result, there are things that work in OpenSim that don't work in Second Life and the other way around.

Avination, like Kitely, uses a modified version of OpenSim. They take the standard OpenSim releases and apply their own proprietary patches to them. They, like us, have added support for functionality that isn't included in OpenSim. Some of that functionality may include support and/or fixes for the functions that are required to get this script to work as intended. If so, as we haven't touched that code, that functionality will work differently there.

Kitely is not OSGrid, OSGrid is a different grid that uses OpenSim. Both Kitely and OSGrid use OpenSim but, like with Avination, some functionally differs (e.g. Kitely has its own proprietary inventory and asset systems and things such as Advanced Megaregions which don't exist in other OpenSim-based grids).

The way the script is written, if it is interrupted after it turned the prim into a cube but before it switched it back to be a sculptie then you will wind up with a cube. I can't say whether this is the cause of the problem you encountered but it could explain how this problem could be created. If this is the cause then it is entirely possible for the script to work for a long period before something interrupts it in mid operation. That said, if sculpties that didn't include this script were turned into cube prims then it's likely that something other than the scripts not completing their work was the cause.

[Barnard Smith]

Thanks Ilan, but why did the script work for nearly 3 weeks here in Kitely then suddenly stop? And why even now why aren't all the sculpt items in my world with the script are not currently affected? both you and Oran have seen it for yourselves with a set of sculpt stairs. And why can I set out fresh copies of these affected builds from my inventory and they aren't affected (looking like the day I built them) until my world is copied or backed up?

These builds aren't effected immediately only over time and with world copies and back-ups. I can send you a copy of the most effected build on my world and if it is like my experience, when you set it out the build there will be no damage.

I know this from personal knowledge. Read my texts..I told you at first when I noticed the damage I reset the whole build of a house with a new copy..then stopped when I noticed a larger effect going on and texted you in the forum. The old build I replaced was totally messed up but the new copy build had no damage...I told you all of this while you were standing in front of the same build on my world.

The unaffected build that replaced the majorly messed up build was not affected at all until you and Oran copied then reset my world. After reset the undamaged build returned to the same damaged state of the original build that had sat there before, but was not damaged before the copy back-up or reset.

Also while you were on my world I stood you in front of a large brown barn and I pointed out that it had no windows or doors that it had before. This barn was between a totally messed up Mexican house and a little stone cottage that was also messed up. The brown barn I showed you that had no windows or doors is totally made of sculpt and had no script inside it. It had no script and was still messed up. I pointed it out to you and you saw it at the time. Im sorry about my misunderstanding about Kitely being OSgrid but judging from your login address its a easy mistake to make http://osgrid.kitely.com:8002/
Let me know if you want samples. Thanks

[Ilan Tochner]

Hi Barnard,

Each prim that uses the script runs separately. One instance of the script can potentially be interrupted before it completed restoring the sculpties without other script instances being interrupted as well. Even if this script is the cause (which it may not be if prims that didn't have this script were effected as well), then the script instances could work just fine as long as they aren't interrupted. This would explain how your world would have looked okay for weeks before it got messed up. If you rerezz a scripted prim that was stored correctly then there wouldn't be any reason for it to be messed up when you rezz it. However, if the script is to blame for the problem you reported then eventually something might cause a similar interruption for the script which would then cause the prim to turn into a cube.

Please remember the script intentionally turns the prims it runs inside into cube prims and resets many of their values. That is what it is programmed to do. Then, if nothing interrupts it, the script turns those prims back to the shapes that you gave them. The script uses a risky hack that was designed to overcome an SL/OpenSim limitation. It may work okay most of the time but it is susceptible to problems if something prevents it from completing its operation. To give an analogy, it's like jumping out of your window in order to blow dry your hair with the wind from the fall and trusting that the trampoline you placed below the window will bounce you right back up. This might work great a million times and then, when there is a strong gust of wind or someone moves the trampoline, you end up in a very different shape on the ground than the one you had before you jumped out the window. Using a script that changes your prims to a cube and then changes them back is susceptible to the same shape-changing consequences when something unexpected happens to the environment.

The backups we restored were for the world state as it had been when the backups were automatically created. The first one we restored was apparently made after changes had already occurred in your world. We had to go back a few days before we found a backup that didn't include these problems.

As you've stated that you encountered problems with sculpties that didn't use this script it is very possible that the script isn't the cause of the world-wide problems. Which is why it could be helpful if you send Oren the linksets that suffered from this problem that didn't include the script. We would need to get the copies of how they looked before they were corrupted and copies of how they look after they have been corrupted.

Having said all that, and even if the script isn't the cause of these problem, the script is still dangerous and I personally wouldn't use it for anything I had built.

[Barnard Smith]

Thanks Ilan,

Who or what moved the trampoline. Who or what changed the environment from what it was before? I did not change these builds from the time I sat them out, and each had no defects, perfect in every way from the time I packed them away then set them out..they remained perfect for nearly 3 weeks in Kitely until this game changed them in a big way. In your analogy you seem to indicate that the Kitely system isn't stable that it will run one way a million times with a script then error when something unexpected acts upon it.

This is a builders script and is a popular and common script. it works well in SL and Opensim from personal experience. Avination is located on Opensim and it worked well there with no issues. It just doesn't work here...I get that.

The script is designed to work in the 2 phase function to "reboot" after a sim or region restart. Almost all phantom or sculpt-phantom scripts have to be manually "rebooted" after a sim or region restart, this script doesn't have to be manually restarted. The script isn't a "dangerous script" and is very common and one of the best I've found..it solves a great many builder issues.

If anything and I say IF it is a script malfunction it is due to the frequent restarts of the users world and the speed that Kitely loads trapping the script between phases, or frequent restarts, copy, back-ups and the speed that Kitely does these functions trapping the script between phase 1 and 2.

Your analogy doesn't explain a great many of my questions, but in part, why weren't all the sculpts with the script affected when at the same time mostly all the others that had the script included were..and why were some sculpts affected without the script but corrected when you replaced my world from a previous back-up date. And it doesn't explain my test build that was fine upon setting it out and world relogs and restarts..then destroyed when it was backed-up and restored. And what changed in the Kitely environment after 3 weeks of daily use to make the script error out in such a big way.

Don't worry I get it...not all scripts work here in Kitely that run in SL or Opensim...not all the scripts builder or otherwise work here. I don't know what I'm going to do yet because all of the sculpt-phantom and regular prim phantom scripts I have tried don't work here either. Some of it has got to do I think with the world restarts,were as the phantom script has to be manually restarted every time you come in...others just don't run. Thanks

[Adagio Greenwood]

Hi Barnard,

When we restore the world state from a backup everything returns to how it was when the backup was made. It doesn't matter what changes were made after the world was backed up, by whom (or what), or for what reason, all those changes would be lost and the world would be reset to the state it was in when the backup was made. The script could have been the cause but that wouldn't have changed the backups that were saved before the script messed things up.

As I've said previously, as you've indicated that sculpties turned into cubes even if they didn't have the script then it is very possible that the script isn't responsible for the problems you've encountered.

However, assuming that the script is responsible: not all prims with this script would have been affected because not all the scripts run at the same time. The prims that didn't have scripts running would not have been in the process of turning from a sculptie into a cube and back again into a sculptie - they would have just remained as sculpties. Even if a problem with the script exists it doesn't have to happen every time it is run nor does it have to affect every prim that uses it. The script needs to fail in a very particular point in time for this to happen.

All grids, including SL and OpenSim-based grids are affected by many various things throughout the day, e.g. the number of people currently connected to the grid, the load on the asset servers, network connectivity between the various server components and between people's viewers and the servers, etc. Every one of those things can effect the load on a server which can cause scripts to run slower than they usually do. If the scripts run slow enough and are not programmed to retry operations that take longer than expected then they can sometimes timeout and fail. Nothing has to break or change for this to happen, load variation is a given in any system that has changing usage patterns.

For example, load on the asset server when the script is run can make the changes to the prims slow down. If there is enough momentary load then the script will need to wait a long time for the changes to be saved before it can continue and OpenSim may decide the script is frozen and therefore terminate it. The changes to the prim would have already been stored at that time but the rest of the script that changes things back would not be called as the script would have been terminated before that code would be run. I'm not saying that this is what happened I'm saying that this is a possible way it could have happened if the script is the problem to begin with. This type of potential load-related problem isn't Kitely or OpenSim specific it could potentially happen in SL as well.

The fact that our system shuts down empty worlds and restarts them when they are needed will cause startup scripts to run a lot more frequently than they would run on other grids. This would obviously increase the chance of such scripts encountering problems. The more times a script is run the higher the chance that it will fail to complete at least once. In most scripts this will have no big effect, something small may just not work and will work again the next time the script is triggered. However, With a script such as the one you're using a script failing can cause a very big effect because the script actually changes prims inworld and, only if it completes, does it return everything it changed back to what it was. This particular script needs to fail just once before it leaves things permanently as a cube. The next time it will successfully complete it will turn the cube it was left as into a cube (as the script is supposed to do) and then turn that cube back into the original shape it was in before the script was run, which because it was a cube after the previous failed script completion, would be into a cube. In other words, once this script leaves something as a cube it will remain a cube no matter how many times the script runs without a hitch afterwards. Given enough time this will result in a growing number of sculpties turning into cubes and remaining that way.

As an aside, Kitely uses the latest stable release of standard OpenSim so if something works in the latest standard release of OpenSim it works in Kitely as well. That said, Avination and Kitely both include additional things that standard OpenSim doesn't include because they both add their own proprietary patches to it. As a result, there are things that work in Avination that don't work on standard OpenSim or in Kitely and there are things that work in Kitely that don't work in standard OpenSim or in Avination. Your experience on Kitely will differ from your experience on Avination (there are things we're better at and things they're better at).