To box, or not to box, that is the question

[Tess Juel]

I'm working on a number of Market listings that each includes several - some of them more than a hundred - different items. I know from SL that some customers prefer to receive such collections boxed to keep their inventories less cluttered, others prefer to get them "loose" to make the items easier to access. I definitely belong to the boxed camp myself but what is your opinion?

[John Mela]

Unboxing is a pain, IMO. How about using sub-folders within the product contents to give folder organisation on delivery? I'm not sure how many levels deep you can go, but I've included a sub-folder in the latest RezMela product (for notecards with example scenes) rather than using a box that needs unpacking.

[John Mela]

Hi Tess,

Kitely Market direct delivers orders with their defined folders into Kitely avatar inventories and it automatically converts folders into boxes when delivering orders to third party grids. As a result, if your listing contains boxed items then your buyers will need to unbox them needlessly. It is therefore best to just use folders in your listings and let Kitely Market handle the boxing when it's required.

[Tess Juel]

it automatically converts folders into boxes when delivering orders to third party grids.

Oh, that brings up another qeustion: what happens to scripts when KM boxes them up. Will they start running when the box is rezzed?

And two more related questions: Is there a limit to how many items a listing can include? And is there a limit to how many listings we can have in a store?

[Tess Juel]

Hi Tess,

Oh, that brings up another question: what happens to scripts when KM boxes them up. Will they start running when the box is rezzed?

Yes, because scripts in prims automatically start running when the prim is rezzed.

And two more related questions: Is there a limit to how many items a listing can include? And is there a limit to how many listings we can have in a store?

There's no limit on the number of listings (products) in a store.

Within a product (well, within a variation to be precise), there can be up to 500 items per folder. So if you don't use folders then the product can contain 500 items. But if you do use folders then you can have far, far more items in the product. Note, however, that there's a problem with very large products: they take a long time to get delivered. This is mostly a problem when they're delivered to users on other grids (since this requires boxing the product), but it's a potential problem even when delivering to Kitely users. So we don't recommend creating products that contain thousands of items: it's better to create several variations and split the items between them.

[Tess Juel]

Hi Tess,

Oh, that brings up another question: what happens to scripts when KM boxes them up. Will they start running when the box is rezzed?

Yes, because scripts in prims automatically start running when the prim is rezzed.

Oh. That may be a bit of a problem. Is there a way for a script to reliably distinguish those boxes from the objects they are supposed to run in?

[John Mela]

You'd need to find something about the object that differentiates it. For example, if the object it's supposed to be in is a linkset, then:

Code: Select all

    if (llGetNumberOfPrims() == 1) 

would tell you if it's in a single-prim object. Or if your boxes all have the text "(boxed)" in their name, then:

Code: Select all

    if (llSubStringIndex(llGetObjectName(), "(boxed") > -1)

will be true if it's in a box like that.

The other issue is: what do you do to disable the script if it's in a box?

What I do is to have a special state called "Hang", that looks something like this:

Code: Select all

state Hang {
	on_rez(integer Param) { llResetScript(); }
}

and then switch to that state if I don't want the script to do anything, for example:

Code: Select all

    if (llGetNumberOfPrims() == 1)  state Hang; // do nothing in a 1-prim object

Then the script will remain inert until the object it's in is rezzed again.

This is far more reliable than using llSetScriptState(), by the way, which might seem at first glance to achieve a similar thing but is prone to weirdnesses.

Hope this helps!

[Tess Juel]

You'd need to find something about the object that differentiates it.

Yes, but which is the best parameter to check? Ideally we want one code snippet that works for all scripts rather than unique solutions for each.

llGetCreator( ); is the most obvious choice. Something like this:

Code: Select all

if(llGetCreator( )!=[whatever creator UUID the box has]){
	[code to execute]
}

But what is the creator UUID of the boxes generated by KM and is it consistent and reliable across the hypergrid mess?

Incidentally, I may have found a bug in the script engine while I was working on this. I tried to use llGetPrimitiveParams([PRIM_TYPE]); as the identifier since the boxes presumably are prim type 0 (box) while the objects are prim type 7 (sculpt/mesh). But it turns out that function returns some UUID for a mesh, not the prim type parameters.
If this is intended behaviour, it's actually a very good way for a script to distinguish meshes from prims and sculpts since it only has to count the number of items in the list returned but I assume this is a bug and one not in all the different script engines used by opensim.

(Edit: fixed typos)

[John Mela]

Yes, but which is the best parameter to check? Ideally we want one code snippet that works for all scripts rather than unique solutions for each.

If you're looking for a solution that covers Kitely boxes in particular, then I can't answer that from experience, but

llGetCreator( ); is the most obvious choice.

does sound like a good approach. You can find the UUID of the creator of the box by printing the value of llGetCreator() in a script inside a box.

Incidentally, I may have found a bug in the script engine while I was working on this. I tried to use llGetPrimitiveParams([PRIM_TYPE]); as the identifier since the boxes presumably are prim type 0 (box) while the objects are prim type 7 (sculpt/mesh). But it turns out that function returns some UUID for a mesh, not the prim type parameters.

Maybe best not to rely on this behaviour. The SL Wiki says: "PRIM_TYPE will silently fail when executed by a script placed inside a mesh", so while it's not a bug as such there's no reason to expect that the behaviour you're seeing will be consistent.

[Tess Juel]

does sound like a good approach.

It could have been but it turns out the box lists the seller as the creator so it doesn't work.

However, the text in the description of the test box I sent started with "https://www.kitely.com/market/product/". That seems like a very good identifier. I've sent Oren an IM asking him to confirm that this is conistent.