Populating Inventory Database


I’ve got the inventory servers updating my database to identify what object has items to be delivered. I also have setup the web-based portion to allow me to start saving details about my products. Populating this data will take a long time. I started looking at vendor designs, playing around with lights and different shapes. I’m assuming that many malls may have issues about lights and the idea of lag, so i’m still working on other ideas. I’m not certain if I will go with a 1-prim vendor or add a few more for related information. I was also considering displaying web pages on the vendors to have more details, but I’m assuming media on a prim could lag people down.

Visit Applewood

Posted via email from dedricmauriac’s posterous

4 Responses to Populating Inventory Database

  1. I have a special prim I dump my inventory in. It sends the UUID and name to my server and I also drop in a same-named Image which it sends the UUID, and then deletes everything. CHanging and ad is as simple as dropping in a similar named image. The server stores both UUIDs, and I update the prices and and description there. One dispenser prim can hold 250 or so products, and also serves as an updater.

  2. Pretty cool. The way I have these setup, there is no inventory limit. Why would you send the UUID of the object to the server though? I don’t see what use it is – unless you only send them for images.

    I don’t like the whole image/object name matching. I prefer to specify the UUID’s manually for images and leave them in my own avatars inventory. It’s one less thing the in-world server needs to keep track of.

    I’m keeping track of version numbers in my database, so it will be pretty easy to send out updates once the system is completed.

  3. The UUID is all you need to know about anything in SL. Names can be duplicated. Versions can change. But a UUID is unique.
    Everything else can be found out from it. So if I want to send something to you, it sends back the UUID of what to send to an inworld script. It does in turn does a llGiveInventory(yourUUID, MyUUID), and the transaction is completed. There are no ‘255 object’ limits in the dispenser, as nothing is in the dispenser but a current UUID of the texture and the UUID of the object to give.

    For example, a texture organizer can only hold 255 items in the object. But the RAM can hold thousands of UUIDs. So when you drop a texture in, instead of storing it in the Object, get its UIUID, and store it in RAM or an external database, then delete the texture. For a vendor, all you need is to drop in a object and a texture. Matching the names isn’t important. As soon as a script finds 1 texture and 1 object, it can send the name of the object and the two UUIDs to the server. Then a remote vendor can display the texture and give the object and also know its name. I have encoded a price into names to handle the last step, so there is no need to have anything manually done in the database..

  4. Here is a sim-wide dispenser that uses one ‘server’ prim. It’s nowhere near as comprehensive as what you are doing. But it has some good use of the strided lists toward the very end of it, and everything is done in-world: It uses the object contents as a mini-datbase where the names contain prices.


%d bloggers like this: