Downloads and Support

Post edited 1:05 pm – Oct 7, 2009 by dutchglory

OK   thank you very  much for trying to fix it.   

It appears that there are multiple problems with OpenSim 0.6.7.  At this point, I have seen all of the symptoms that Dutch reported except for the Taper thing.

Several things changed in OpenSim between 0.6.6 and 0.6.7.  Unfortunately, I still don't know what they are.

Still working on it…

Words cannot express how tired and frustrated I am right now.

Okay, I think I have another piece of the puzzle.  Somewhere between 0.6.6 and 0.6.7, OpenSim imposed some Linden-style distance rules on child prims.  By itself, this wouldn't be a bad thing, but the rules seem bugged.  I need to do some more testing to be sure.

There are at least 2 more issues that I still can't pin down.  Honestly, sometimes it feels like the scripts are operating in a totally different universe now.  The behavior is just bizarre.  But I'm getting closer.

It is very likely that at least 2 bug reports will come out of this and we'll need to wait for those to be fixed in OpenSim.  I can't recommend 0.6.7 at all.  Hopefully, the next version will work better.

I've just released Prim Composer 1.3.6 which has my best effort to fix LSL rezzing problems in OpenSim 0.6.6 and 0.6.7.  See the ticket for my complete notes.

0.6.7 has a change in it that limits the distance that child prims can be moved by LSL (0004228).  This problem is so huge for the LSL rezzer that I have abandoned further testing on 0.6.7 and trunk until this is fixed in OpenSim.

0.6.6 is much slower than previous versions.  I don't know what it is, but it is very noticable on a large build.  Perhaps because of this, 0.6.6 also exhibits a tendency to abandon LSL scripts to limbo.  For example, I have seen a script stop executing in the middle of a call to llSleep().  I don't know what happens to the script.  I don't know if it is killed or if it simply gets lost, but it never resumes and I have not been able to find any error messages to explain it.  There is clearly an OpenSim bug here, but I don't have enough information to report it yet.  So, 0.6.6 is unreliable and there doesn't appear to be anything that I can do about it.

0.6.5 works very well but does have one problem that I had forgotten about.  When scripts kill themselves, they don't completely die.  If you open the statistics window in the viewer (shift-control-1) and look at the number of Active Scripts, then you will see that the number continues to grow without bound when the LSL rezzer is running.  If OpenSim were working correctly, this number should grow and then shrink back to what it was before the rezzer was started.  It doesn't.  And when the number of active scripts exceeds 1000, then the LSL rezzer starts breaking.

The only way to get rid of these active "ghost" scripts is to restart the OpenSim server.  I reported this problem in May (0002929), but no one has taken an interest in the problem and so it has not been fixed.  This problem affects all versions: 0.6.5, 0.6.6, and 0.6.7.  What this means for the LSL rezzer is that you probably can't rez more than 1000 prims at one time and that you will have to restart the server before rezzing more.

Maxport 1.3.6 includes several improvements to the LSL rezzer, but none of them can overcome the issues listed above.

I've done the best that I can for now.  I'll return to this after my vacation next week.

Please continue to post about what you're seeing.  Every bit of information helps to develop a better understanding of what is happening.

I haven't looked at OSGrid at all, since there doesn't seem to be any point when things aren't even working in Standalone now.

Build Pack scripts such as Builder's Buddy and Rez Faux work differently from the way that the Prim Composer LSL rezzer currently works.

With a build packer, you take the already rezzed linksets, put a script in them, and then drop them in the rezzer.  As a result, there is 1 script per linkset.

In the current version of the LSL rezzer, the build is represented as data in notecards.  The rezzer reads the data and then rezzes an unformed linkset with the same number of prims as specified by the data.  Then, each prim has to read the data that describes it and transform itself into the appropriate shape.  Each prim will start out as a cube and then transform itself into a sphere or a sculptie as required by the data.

Thus, instead of having 1 script per linkset (as in build packers), there is 1 script per prim in the Prim Composer LSL rezzer.

This puts considerably more stress on the scripting engine and the server as a whole.

In addition, because build packers already have the fully formed linksets inside them, the rezzed child prims don't need to move relative to the root prim.  They are already in their correct position.  Thus, a build packer would not be affected by the child movement restrictions in 0.6.7.

Both techniques have advantages.  There are three steps to importing a packaged build into Second Life or OpenSim: uploading, packaging, and rezzing.

The build packer technique has advantages in rezzing.  It rezzes faster and puts less stress on the server during rezzing.  However, uploading and packaging takes longer.

A notecard-based rezzer such as the current LSL rezzer is faster and less stressful on the server during the upload and packaging phases, but is slower and more stessful during rezzing.

I plan to implement both techniques eventually, but the notecard-based rezzer is what we have now.  The reason that I started with this technique is because it can dramatically speed up uploading and packaging for builds with thousands of prims.