Options for scripted object transfers between two objects?

Hello all.

I'm seeking some advice on scripting object transfer between objects.

Summary:
"Have two objects, "A" and "B", both having the same owner. Object "A" is to give "B" another object, "G". This is the only way in which objects "A" and "B" are allowed to be modified."

What I have working at the moment is that "A" uses llGiveInventory to give "G" to "B", and "B" is set to llAllowInventoryDrop(TRUE). Whilst this works, it is not secure - using llAllowInventoryDrop allows *anyone* to drop objects into "B" by control-dragging to them.

Aside: "B" is a linked object, and it appears from my experimentation that llAllowInventoryDrop works on a per-prim, rather than per-object basis - can anyone confirm this?

A possible solution is to set llAllowInventoryDrop to TRUE only immediately before the transfer, and reset it to FALSE immediately afterwards. Are there any flaws with this approach?

The other, non-llAllowInventoryDrop approach I've tried is to simply grant mod-permission for "B" by the owner. This allows the llGiveInventory call to work, but eventually I hope this will be a for-sale product, and hence don't really want the owner to have that permission.

Perhaps I'm barking up the wrong tree entirely, and there is a better option than llGiveInventory?

For those brave souls who read this far - thanks! All suggestions will be most gratefully received.

Something that toggles the inventory drop and on off makes sense, but it isn't entirely foolproof and does require an always on listener probably.

If your receiver object has several prims you have some choices... you can filter it in the destination prim and then pass that on to a second prim, discarding things that don't meet your criteria (name, llGetInventoryCreator() etc.) with llRemoveInventory(). This can work nicely, and does for a product that I've made which filters out non-notecard objects. You can use link messages to toggle the allow inventory drop for the other internal prims, which is low drain on the sim and stops people dropping stuff in by random unless they're really good with the timing and they're expecting it...

Thanks for your detailed reply, Eloise, much appreciated.

The object transfer of "G" into "B" occurs in B's "update" state. I modified the script so that Inventory Drop is turn on in the state_entry of "update", and off in the state_exit. I also wrote a "PurgeByCreator" routine, called from state_exit. It scanned all objects in the inventory, and deleted any that did not have me (or my project partner, hereafter "Bob" ) as creator (using your llGetInventoryCreator() suggestion).

The script worked at the technical level, but alas the concept itself is flawed. Bob does all the prim-building and texturing, I do all the scripting. As a result, "G" is a joint-work, and its creator shows as "unknown)". I could include "unknown)" as an 'allowable-creator', but then any griefer with a friend could easily circumvent the security.

I could also give all my scripts to Bob, and have him rebuild "G" so that he appeared as creator, but "G" is non-trivial to build, requiring certains scripts in certain prims, etc. So, this option is do-able, but messy and inefficient.

In essense, I'm trying to find an object 'tag' that I can use to identify objects as "allowable". I do currently filter on object-name, but thats a poor tag for this purpose, as anyone can create an object with the same name. Using creator as a tag has the problem noted above. Any other suggestions for possible tags? I was wondering about keys, but I note that the LSL Wiki says the following about llGetInventoryKey - "if the object owner does not have modify, copy and transfer permissions on the inventory item being requested, then the function returns the NULL_KEY".

It could be something triggered by touch_start() if the person who touches the prim passes the security check... toggle the inventory drop and shut it down few seconds later or as soon as object is dropped inside, whichever happens faster ^^;;

Um, for a person dropping yes... the OP was for object to object giving though, and objects aren't so good at touching other objects.

Aye, but owners of items can do the touch thing when they want to initiate transfer between objects, too ^^; (it's rather difficult to get the picture from initial description, but i got the impression that transfer isn't something that has to happen 100% without the owner being around and at objects' own whim..?)

To clarify:

The user buys object "B", and sets it up somewhere. "B" dispences other objects in response to commands. The range of objects that "B" dispences can be increased if the user buys "updater packs" - these are the "A" objects referred to above. Currently, the user does the upgrade by rezzing the updater pack "A" near "B", and hits the "upgrade" button on "B". "A" then gives the required upgrade objects to "B", and deletes itself.

So, yes, the exchange does occur only when the user is around. "B" does some scans to find the "A" objects, and the "A" objects have an open listen to receive commands, but this is only for the 10 seconds it takes to do the upgrade. "A" then dies, and "B" switches back into a less CPU-intensive state.