halcyongrid / phlox Goto Github PK

Second Life includes a number of "god" functions which require admin mode in order to compile and use. While InWorldz never had any intention of implementing these functions, smaller grid owners running Halcyon may be interested in them.

The documented functions include llGodLikeRezObject(), llSetInventoryPermMask(), and llSetObjectPermMask(). Though, as I have been informed, this is only the tip of the iceberg, as Second Life includes a much larger number of undocumented god functions.

EDIT: A configuration option to disable such functions should be available, in case a grid owner doesn't want them to be used at all.

I was having trouble with a common library used in SL, and started digging into why it was failing. After writing some simple unit tests in SL's LSL and testing that they pass in both LSO and Mono modes, I got them into a Halcyon instance running Phlox and found the following tests were failing:

• where a = -10 the expression (a = 23) + a is evaluated as 46. Expected 13.
• where a = 0 the expression (a = 23) + a is evaluated as 46. Expected 23.
• where a = 10 the expression (a = 23) + a is evaluated as 46. Expected 33.
• where a = -10 the expression a + (a = 23) is evaluated as 13. Expected 46.
• where a = 0 the expression a + (a = 23) is evaluated as 23. Expected 46.
• where a = 10 the expression a + (a = 23) is evaluated as 33. Expected 46.
  (Edited for clarity 12/3)

Pretty sure the problem happens with any other operator than + as well as I initially found and extracted this problem from a formula that was using the bitwise | operator instead.

Workaround is to reverse order of operations when transferring scripts from SL that use this technique.

This proposal is to extend current bot functionality to provide an instanced bot's appearance based on items provided for it in a prim/object inventory. This will make bots a lot more useful and have many applications.
Proposed Additional Functions: *

botOutfitAdd(botID/botOutfit-Name, "contentsName"[,attachmentpoint])
Where botID is the integer ID of the instance existence of a bot OR string botOutfit-Name to be applied to.
contentsName would be the item name in the object inventory. Item must be there, and must have the same owner as the prim. (I do not know of any possible case where the owner would have any content in the object that was not also owned by the same.)
[,attachmentpoint] This does indicates where that item is to be worn or attached. I would suggest this be an optional parm where it is not self evident as in the case of attached items using the attachmentpoint number or its constant name.
This function will not copy any item to the owner's inventory. It merely assigns the referenced item to be worn by the bot instance that uses the designated bot outfit name. A bot does not have any inventory. It only requires the inventory item UUID and AssetID to wear or attach the item. The item UUID reference for this proposal may come from owner's inventory or an object's inventory.

botOutfitRemove(botID/botOutfit-Name, "contentsName") This would remove the item from the bot outfit assignment based on the prim inventory item name if it was found to be worn on the bot outfit. NOTE: some worn items may only be replaced such as skins, standard clothing etc.. Attached items may be removed. Proposal would apply this function to attached items only.

botOutfitSaveAs(botID/botOutfit-Name, "newOutfitName"); This function would provide a way to save the current botID outfit or outfitName as a new bot outfit. The limit of 40 max bots per owner would apply.

• suggestions posted to me by Appurist. Comments are mine.

The proposed functions would include permission checks, but since can only be applied by script to an object which is the owner's, and the inventory also belongs to the same owner, this is a bit redundant. If the items may be worn by the owner, they may also be applied to the owner's bot outfit designated. There are no options for applying these functions to someone else's inventory items or content in an object that is not also owned by the same owner. So the permissions only applies to the owner of their own contents.

Since these functions would make it possible to create outfits for bot use as defined products that may be exchanged or sold, the functions in the scripts may only apply in the context of the active owner. The object inventory may be worn by the new owner's bot. Any items that a bot is wearing may not be transferred by script to the new owner's inventory anyway. I do note that there is no way to prevent object inventory from being copied to the new owner's inventory. Bot worn items are a one way direction from owner to bot. These functions extend that to also include an object's inventory, making possible use of vendor models showing worn products, ride-able creatures with bento shapes, breedables of any description, and a lot more applications. What may be done with an avatar could also be done with a bot.

llGetMaxScaleFactor, llGetMinScaleFactor, and llScaleByFactor are not implemented. These functions are utilized by resizer scripts.

A while back, Linden Lab added a number of functions related to memory profiling, which include llGetSPMaxMemory(), llScriptProfiler(), and llSetMemoryLimit(). The first two may be useful for scripters wishing to debug the memory usage of their larger scripts.

The latter one, llSetMemoryLimit() is of no worth for reducing script memory usage even in SL because Mono and Phlox both use dynamic memory allocation for script memory. If llSetMemoryLimit() is implemented at all, it should just be as a non-functional implementation so that scripts from SL can compile.