Jump to content

"WEREHOUSE" ???


Anakin Adonide
 Share

You are about to reply to a thread that has been inactive for 4585 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hi all! I'm trying to create an object, similar to a box where, the owner, can save objects from his/her inventory without dropping them into the content window by editing the BOX... The thing is that I don't know if that is possible.

 

But if it is, here's the global idea...

I wanna create a box to store 5 different class of objects, let's say... chairs, tables, tv's, desks and PC's... Also, I want to give some inteligence to the box... when you click it, it should give you the chance to store or withdraw items from it... something like, STORE - WITHDRAW options and CHAIRS - TABLES - TV's - DESKS - PC's options in both of them...

I hope i make my point clear, ty for helping!!! ^^

Link to comment
Share on other sites

You can always drop objects into a box if you have mod permission.  If you don't have mod perms but the box is scripted for llAllowInventoryDrop(TRUE), you still can do it.  You just have to remember to hold down the CTRL key when you drag an item from inventory to drop it into your box instead of onto it.

There's nothing about a chair or a table or a TV or a desk that identifies it as anything other than a collection of linked prims.  If you want to be able to store items in categories, you have to do something like put a key word in each object's Description field.  Once you've done that, your script just has to save the names of all objects with the same Description in a single list and then call up the list when you need it for something.

I suggest studying the options for managing lists in the LSL wiki.

Link to comment
Share on other sites

If you give the warehouse link permissions then it can link to the objects and move them inside.

They would still be rezzed and not in the warehouse's inventory.

If you asked it to store chairs it could do a sensor sweep by object name and try to link to any it finds.

If the objects (and the warehouse) are physical, you could detect collisions and try to link and store any appropriate object that collides with it.   This would somewhat approximate the behavior you might want for dropping an object on the warehouse (while the default behavior would be to leave the object sitting where it landed on the roof).

It can spit them out and unlink them when you ask for them back.

Rollig's way works too (and saves prims), but I bet a lot of residents don't know about control-drag.

 

Link to comment
Share on other sites

OK, so you can't use the object description, because you can't read it from an object in inventory (sorry about that), but you CAN read the object's name.  So add the identifier to the end of each object's name:  "Overstuffed Arm Chair (Chair)", "Glass-Topped (Table)", "Lamp, Tiffay-style (Lamp)", etc.   Then do something like ..

changed (integer change){     if(change & CHANGED_INVENTORY)     {          integer i= llGetInventoryNumber(INVENTORY_OBJECT);          while(~(--i))          {               string name = llGetInventoryName(INVENTORY_OBJECT,i);               if(!~llListFindList(gOldInv,[name]))               {                    integer idx = llSubStringIndex(name,"(");                    string type=llToLower(llGetSubString(name,idx,-1));                    if (type == "chair")                    {                        gChairs += name;                    }                    else if (type == "table")                    {                        gTables += name;                    }                    else if (type == "sofa")                    {                        gSofas += name;                    }                    else if (type == "lamp")                    {                        gLamps += name;                    }                    else                    {                        gOther += name;                    }                    gOldInv +=name;               }          }     }}

 .... being sure to make all those lists global (gOldInv, gChairs, gTables, etc.)

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Thank you so much Roolig! It worked ^^

Now I want to add a dialog to that "werehouse" so that, when the owner clicks it .. a menu pop up with several options...

WITHDRAW (to take an item out)

TOTAL (to set the total amount of items storaged)

SLOTS (to let the owner know how many items he/she can still store)

RESET (to reset all the scripts if any time error appear)

I've already set the maximum amount of items that can be kept using a script, which I called "Configuration Stock" and with another one.. "Configuration File" I established the list of different objects in the "werehouse"...

But I don't know how to set up a good dialog for these things...

The werehouse has only 1prim and I'd like to know if scripts can communicate with each others or should I group all of them together?

 

Link to comment
Share on other sites

It's almost always best to do everything in one script unless there's a good reason to keep some functions isolated from each other, or you have memory limitations.  Making multipage menus isn't really hard once you get the hang of it.  Study the LSL wiki's page on llDialog and then spend time digging through tutorials like https://wiki.secondlife.com/wiki/DialogMenus and the linked examples in it. 

The real challenge isn't syntax.  It's logic.  You need to have a clear idea of where you're going before you start writing a complex script or you'll get hopelessly twisted around.  LSL's structure of states and events actually helps a lot, by making it natural to divide a script into modules that you can write as related units.  So after you have played with examples enough to get confident, map out the set of decisions that your dialog pages will follow and dig in.  If you get stuck, come back and post the parts that give you trouble.

Link to comment
Share on other sites

Does it help to keep inactive scripts disabled?

My menu system keeps most of its scripts disabled, and enables the script associated with a function when it is selected.

The resulting smaller scripts can also be lsl instead of mono,  and since the state of disabled scripts is not preserved on sim crossings, it should not have to be sent to the new sim on a sim crossing.

 

Link to comment
Share on other sites

Generally no - inactive scripts still require memory.  There are a million things that can affect whether it 'helps' or not though - like LSL vs Mono as you say.

So, first, could any of those LSL scripts be combined within their 16k memory limit?  For each count you eliminate you save 16k.  Can 4 or more be combined into a single Mono script - which would run faster but have the sim-crossing issues that are still around.  As you know multiple instances of a Mono script in the same sim can share bytecode memory and we'll soon (?) have the functions to set exactly how much memory a Mono script uses, instead of the fixed 64k.

So much optimisation "depends".  I think the consensus is as few scripts as possible, except where frequent sim-crossing makes LSL more attractive than Mono.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4585 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...