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

Discussion and support for the Kitely Market
User avatar
Tess Juel
Posts: 267
Joined: Sun Sep 11, 2016 4:24 pm
Has thanked: 249 times
Been thanked: 438 times

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

Post by 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?
These users thanked the author Tess Juel for the post (total 2):
John MelaIlan Tochner
User avatar
John Mela
Posts: 91
Joined: Tue Feb 04, 2014 9:50 pm
Has thanked: 139 times
Been thanked: 127 times
Contact:

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

Post by 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.
These users thanked the author John Mela for the post:
Zed deTremont
User avatar
Ilan Tochner
Posts: 6503
Joined: Sun Dec 23, 2012 8:44 am
Has thanked: 4942 times
Been thanked: 4454 times
Contact:

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

Post by Ilan Tochner »

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.
These users thanked the author Ilan Tochner for the post (total 2):
John MelaTess Juel
User avatar
Tess Juel
Posts: 267
Joined: Sun Sep 11, 2016 4:24 pm
Has thanked: 249 times
Been thanked: 438 times

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

Post by Tess Juel »

Ilan Tochner wrote:
Fri Jul 09, 2021 9:54 pm
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?
User avatar
Oren Hurvitz
Posts: 361
Joined: Sun Dec 23, 2012 8:42 am
Has thanked: 19 times
Been thanked: 499 times
Contact:

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

Post by Oren Hurvitz »

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.
These users thanked the author Oren Hurvitz for the post (total 2):
Tess JuelJohn Mela
User avatar
Tess Juel
Posts: 267
Joined: Sun Sep 11, 2016 4:24 pm
Has thanked: 249 times
Been thanked: 438 times

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

Post by Tess Juel »

Oren Hurvitz wrote:
Wed Jul 21, 2021 9:14 am
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?
User avatar
John Mela
Posts: 91
Joined: Tue Feb 04, 2014 9:50 pm
Has thanked: 139 times
Been thanked: 127 times
Contact:

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

Post by 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!
These users thanked the author John Mela for the post (total 2):
Ilan TochnerTess Juel
User avatar
Tess Juel
Posts: 267
Joined: Sun Sep 11, 2016 4:24 pm
Has thanked: 249 times
Been thanked: 438 times

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

Post by Tess Juel »

John Mela wrote:
Wed Jul 21, 2021 2:20 pm
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)
User avatar
John Mela
Posts: 91
Joined: Tue Feb 04, 2014 9:50 pm
Has thanked: 139 times
Been thanked: 127 times
Contact:

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

Post by John Mela »

Tess Juel wrote:
Wed Jul 21, 2021 9:55 pm
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.
User avatar
Tess Juel
Posts: 267
Joined: Sun Sep 11, 2016 4:24 pm
Has thanked: 249 times
Been thanked: 438 times

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

Post by Tess Juel »

John Mela wrote:
Thu Jul 22, 2021 5:40 pm
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.
Post Reply