These behave identically to llAttachToAvatar() and llDetachFromAvatar() except that they do not enforce the PERMISSION_ATTACH check
Intended for use in completely controlled dedicated environments where these checks are more a UI hinderance than a help.
Threat level high.
This makes it consistent with other parts of OpenSimulator that are treating ESTATE_MANAGER and ESTATE_OWNER as different entities.
As per opensim-dev mailing list.
Change threat level on osSetRegionSunSettings and osSetEstateSunSettings from nuisance to high to match similar functions.
If you had enabled these functions but had relied on the hardcoded god check in the code, then please adjust your OSSL permissions config.
Thanks to Oren Hurvitz for pointing this out.
are osReplaceString(string source, string patter, string replace, integer count, integer start)
The count parameter specifies the total number of replacements to make, -1 makes
all replacements.
This allows NPCs to be sensed as agents by LSL sensors rather than as a specific NPC type (which is currently an OpenSimulator-only extension).
Wiki doc on this and other recent NPC functions will follow soon
llGetOwnerKey() could also be extended but this does not allow one to distinguish between an unowned NPC and some other result (e.g. 'no such object' if NULL_KEY is the return.
Also, any future extensions to LSL functions by Linden Lab are unpredictable and OpenSim-specific extensions could clash.
The osGetGrid**** functions will now get the grid settings from the GridInfoService. Set the GridInfoURI in your ./bin/config-include/GridCommon.ini [GridInfo] section.
no need for these checks just use Allow_osTeleportAgent = PARCEL_OWNER
also increased function to severe threat level to make it harder to
accidently enable it for everyone.
An owned NPC is one that only the original creator can manipulate and delete.
An unowned NPC is one that anybody with access to the osNpc* methods and knowledge of the avatar id can manipulate.
This is to correct an oversight I made in the original reimplementation where I mistakenly assumed that avatar IDs could be treated as private.
I am not anticipating that many people were deliberately making use of unowned npcs due to their insecure nature.
If you do need an unowned NPC please call the new overloaded osCreateNpc() function with the option OS_NPC_NOT_OWNED.
This will be documented soon. Options can currently be
OS_NPC_CREATE_OWNED - creates a 'creator owned' avatar that will only respond to osNpc* functions made by scripts owned by the npc creator
OS_NPC_NOT_OWNED - creates an avatar which will respond to any osNpc* functions that a caller has permission to make (through the usual OSSL permission mechanisms).
options is being added to provide better scope for future extensibility without having to add more functions
The original non-options osNpcCreate() function will continue to exist.
osParseJSON uses hand-crafted decoding that has two issues
* does not seem to handle top-level JSON lists
* does not seem to handle unicode text
thanks otakup0pe!
from previous commit which sort out which iterator is used are left
intact. A discussion is needed as to what constitutes an avatar vs a
ScenePresence.
the 3 iteration functions so more of them are using the correct
iteration for the action they are performing. The 3 iterators that seem
to fit all actions within OpenSim at this time are:
ForEachAvatar: Perform an action on all avatars (root presences)
ForEachClient: Perform an action on all clients (root or child clients)
ForEachRootClient: Perform an action on all clients that have an avatar
There are still a dozen places or so calling the old
ForEachScenePresence that will take a little more refactoring to
eliminate.
PARCEL_GROUP, PARCEL_OWNER, ESTATE_MANAGER and REGION_OWNER can be combined with the existing agent uuid option to limit ossl functions to agents and owner classes.
Signed-off-by: BlueWall <jamesh@bluewallgroup.com>
Format is osNpcSit(<npc-uuid>, <target-uuid>, OS_NPC_SIT_IMMEDIATE)
e.g. osNpcSit(npc, llGetKey(), OS_NPC_SIT_IMMEDIATE);
At the moment, sit only succeeds if the part has a sit target set.
NPC immediately sits on the target even if miles away - they do not walk up to it.
This method is in development - it may change so please don't trust it yet.
Standing will follow shortly since that's kind of important once you're sitting :)
This is to prevent the aborting of attachment script threads on teleport from aborting the one actually doing the teleport.
This allows OSSL teleport functions to work when invoked on scripts in attachments (and huds, I assume)
It's never possible for SOG to have no RootPart, except in the first few picosends of the big bang when it's pulled from region persistence or deserialized
The only times when ParentGroup might be null is during regression tests (which might not be a valid thing) and when scene objects are being constructed from the database.
At all other times it's not possible for a SOP not to have a SOG parent.
Default for this function is now not to automatically land.
This allows better control by scripts when an avatar is going to be landing on a prim rather than the ground.
Stopping the avatar involves faking a collision, to avoid the pid controller making it overshoot.
A better approach would be to gradually slow the avatar as we near the target
this is to allow walking on prims. it will be up to the script writer to be sure that there is a continuous path.
currently implemented in osNpcMoveToTarget(), but none of this is final.
This works by serializing and deserializing NPC AvatarAppearance to a notecard in the prim inventory and making the required baked textures permanent.
By using notecards, we avoid lots of awkward, technical and user-unfriendly issues concerning retaining asset references and creating a new asset type.
Notecards also allow different appearances to be swapped and manipulated easily.
This also allows stored NPC appearances to work transparently with OARs/IARs since the UUID scan will pick up and store the necessary references from the notecard text.
This works in my basic test but is not at all ready for user use or bug reporting yet.
This is a slight adaptation of the patch in http://opensimulator.org/mantis/view.php?id=4568 which doesn't apply directly since the underlying code was changed by earlier makopoppo patches.
Thanks makopoppo!
Even though we don't use the results, just getting the regions may have side effects in making hypergrid links available for the later World.RequestTeleportLocation()
Remove the too coarse CanEditParcel method in favor of a CanEditParcelProperties
method that takes a GroupPowers argument to specify what action is to be
taken. Also, make the method to set parcel data much more granular. Permissions
in a deeded setting should now work.
Added the following replacement functions for compliance to the OSSL standards stated on the wiki:
osGetTerrainHeight
osSetTerrainHeight
osGetSunParam
osSetSunParam
osSetPenColor
The functions that do not comply to the standard give a warning when used but work normally otherwise.
The graphics primitive drawing command "PenColor" has also been added as well as dynamic texture parameter "bgcolor" as an alternative to "bgcolour".
The following two functions have been renamed because they are not enabled yet aynway:
osWindParamSet => osSetWindParam
osWindParamGet => osGetWindParam
This provides the same functionality as osTeleportAgent but without the griefing potential. Region owners need not be concerned about the use of this function because it only allows to do what is already possible with the world map.
The intended use is with HUDs. For example, a list of (hypergrid) destinations could be made available for quick access.
Signed-off-by: Melanie <melanie@t-data.com>
Set the projection parameters in the host prim ...
osSetProjectionParam(bool Enabled,
key TextureMaskUUID,
float FOV,
float Focus,
float Ambiance);
Set the projection parameters in a target prim ...
osSetProjectionParam(ikey target uuid,
bool Enabled,
key TextureMaskUUID,
float FOV,
float Focus,
float Ambiance);
Threat Level very high
Signed-off-by: Melanie <melanie@t-data.com>
refers to prim OWNERS. A new option set, Creators_, is added to allow
selection by script creator. For existing installs, this means no functional
change. The warning from my prior commit doesn't apply anymore.
would be the IDs of the prim owners in whose prims these functions would
run. This changes it so the UUID is the SCRIPT CREATOR instead. Further,
osfunctions limited by uuid will not run if the creator and owner differ
and the owner has mod rights on the script.
There is still a danger in passing moodifiable scripts to others, as they
can insert a harmful function, then remove the mod rights to make it runnable.
As before, care needs to be taken, but where it was modable prims that were
the risk before, modable scripts are the weak spot now.
In cases where prim owner == script creator == script owner, nothing will
change.
dahlia