OpenSimulator - User contributions [en]

OSSLNPC

2011-08-19T20:54:41Z

Casiasfalta: /* Questions/Comments */

=Introduction=

Since 12th August 2011 in the Git master development code branch, OpenSim had provided a number of functions for creating and manipulating NPCs. These replace the previous functions, that had stopped working by OpenSim 0.7.1.1 (possibly broken since OpenSim 0.6.9).

The general philosophy in creating these new functions is to

# Give script writers the simple tools needed to create more sophisticated behaviour.
# Avoid duplicating existing LSL and OSSL functions. For instance, finding out what state an agent is in can be done through llGetAgentInfo() rather than creating a special NPC function.

NPCs are controlled via a script which must be in the same region as the NPC. This could be housed in an attachment that is attached to the avatar.

NPCs created user these scripts cannot leave the region in which they were born. If you want region crossing behaviour, please look at the options on the [[NPC]] wiki page.

NPC appearance is saved and loaded by serializing the appearance data structure to a notecard present in the same prim as the script. The required textures should be preserved when an OAR is saved and loaded.

This functionality is at an early stage and method signatures could change, certainly before the release of OpenSim 0.7.2. However, we hope to avoid this.

=Enabling=

To use these functions, in the OpenSim.ini file you will need the following config

# Enabled = true set in the [NPC] section.
# Enabled = true set in the [XEngine] section.
# AllowOSFunctions = true in the [XEngine] section.
# OSFunctionThreatLevel = VeryHigh in the [XEngine] section. The functions osAgentSaveAppearance(), osAvatarPlayAnimation() and osAvatarStopAnimation() need this level. If you don't need these functions, then a "High" level will suffice.

=Notes=

When using your avatar to model appearance before saving, you will need to wait a few seconds before invoking any save appearance command. This is because appearance saving currently operates on a timer in order to manage multiple appearance updates from the viewer.

=Functions=

==Create and Remove==
===[[osNpcCreate]]===

osNpcCreate(string firstname, string lastname, vector position, string cloneFrom):key

cloneFrom may be:

* Name of the notecard containing a serialized avatar appearance, or
* Asset UUID of the Notecard, or
* UUID of an avatar logged into the same region. However, please note that this appearance will not be persisted unless osNpcSaveAppearance() is called.

If the NPC is successfully created, then its UUID is returned, which is required for all subsequent functions. Example is available at [[osNpcCreate]]

===[[osNpcRemove]]===

osNpcRemove(key npc):void

Remove the given avatar from the region. Example at [[osNpcRemove]].

==Get and Set==
===[[osNpcGetRot]]===

Gets the rotation of the avatar. Only the rotation around the Z plane in Euler rotation (horizontal rotation) has any meaning.

osNpcGetRot(key npc):rotation

===[[osNpcSetRot]]===

osNpcSetRot(key npc, rotation rot):void

Set the rotation of the avatar. Only setting the rotation in the Z plane in Euler rotation will have any meaningful effect (turning the avatar to point in one direction or another). Setting X or Y Euler values will result in the avatar rotating in an undefined manner.

===[[osNpcGetPos]]===

osNpcGetPos(key npc):vector

Return the current position of the NPC.

===[[osNpcMoveTo]]===

osNpcMoveTo(key npc, vector position):void

An older function that performs an osNpcMoveToTarget() by flying and landing at the target.

===[[osNpcMoveToTarget]]===

osNpcMoveToTarget(key npc, vector target, int options):void

Move the avatar to a given target over time. How the avatar will get there depends on the following options.

* OS_NPC_FLY - Fly the avatar to the given position. The avatar will not land unless the OS_NPC_LAND_AT_TARGET option is also given.
* OS_NPC_NO_FLY - Do not fly to the target. The NPC will attempt to walk to the location. If it's up in the air then the avatar will keep bouncing hopeless until another move target is given or the move is stopped
* OS_NPC_LAND_AT_TARGET - If given and the avatar is flying, then it will land when it reaches the target. If OS_NPC_NO_FLY is given then this option has no effect.

OS_NPC_FLY and OS_NPC_NO_FLY are options that cannot be combined - the avatar will end up doing one or the other. If you want the avatar to fly and land at the target, then OS_NPC_LAND_AT_TARGET must be combined with OS_NPC_FLY. For instance,

osNpcMoveToTarget(npc, llGetPos() + <9,9,5>, OS_NPC_FLY|OS_NPC_LAND_AT_TARGET);

===[[osNpcStopMoveToTarget]]===

osNpcStopMoveToTarget(key npc):void

Stop a current move to a target.

==Communication==

===[[osNpcSay]]===

osNpcSay(key npc, string message):void

Get the NPC to say the given message.

==Appearance==

NPC appearance is manipulated by saving and loading appearance data to notecards from the same inventory as the invoking script.

===[[osOwnerSaveAppearance]]===

osOwnerSaveAppearance(string notecard):key

Save the owner's current appearance to a notecard in the prim's inventory. This includes body part data, clothing items and attachments. If a notecard with the same name already exists then it is replaced. The owner must be present in the region when this function is invoked. The baked textures for the owner (necessary to recreate appearance on the NPC) are saved permanently.

===[[osAgentSaveAppearance]]===

osAgentSaveAppearance(key agentId, string notecard):key

Save an arbitrary avatar's appearance to a notecard in the prim's inventory. This includes body part data, clothing items and attachments. If a notecard with the same name already exists then it is replaced. The avatar must be present in the region when this function is invoked. The baked textures for the avatar (necessary to recreate appearance on the NPC) are saved permanently.

===[[osNpcSaveAppearance]]===

osNpcSaveAppearance(key npc, string notecard):key

Save the NPC's current appearance to a notecard in the prim's inventory. This includes body part data, clothing items and attachments. If a notecard with the same name already exists then it is replaced. The avatar must be present in the region when this function is invoked. The baked textures for the avatar (necessary to recreate appearance) are saved permanently.

===[[osNpcLoadAppearance]]===

osNpcLoadAppearance(key npc, string notecard):void

Load appearance from a notecard. This notecard must contain appearance data created with one of the save appearance functions.

=Example=

This is a rough example script for most of the current NPC functionality. Please feel free to improve it.

<source lang = "lsl">
key npc;
default
{
state_entry()
{
llListen(10,"",NULL_KEY,"");
}

listen(integer channel, string name, key id, string msg)
{
if (msg != "")
{
if (msg == "create")
{
osOwnerSaveAppearance("appearance");
npc = osNpcCreate("Jane", "Doe", <115, 165, 23>, "appearance");
}
else if (msg == "remove" && npc != NULL_KEY)
{
osNpcSay(npc, "You will pay for this with your liiiiiivvveeessss!!!.....");
osNpcRemove (npc);
}
else if (msg == "say" && npc != NULL_KEY)
{
osNpcSay(npc, "I am your worst Nightmare!!!!");
}
else if (msg == "move" && npc != NULL_KEY)
{
osNpcMoveTo(npc, llGetPos() + <9,9,0>);
}
else if (msg == "movetarget" && npc != NULL_KEY)
{
osNpcMoveToTarget(npc, llGetPos() + <9,9,5>, OS_NPC_FLY|OS_NPC_LAND_AT_TARGET);
}
else if (msg == "movetargetnoland" && npc != NULL_KEY)
{
osNpcMoveToTarget(npc, llGetPos() + <9,9,5>, OS_NPC_FLY);
}
else if (msg == "movetargetwalk" && npc != NULL_KEY)
{
osNpcMoveToTarget(npc, llGetPos() + <9,9,0>, OS_NPC_NO_FLY);
}
else if (msg == "rot" && npc != NULL_KEY)
{
vector xyz_angles = <0,0,45>; // This is to define a 45 degree change
vector angles_in_radians = xyz_angles * DEG_TO_RAD; // Change to Radians
rotation rot_xyzq = llEuler2Rot(angles_in_radians); // Change to a Rotation
rotation rot = osNpcGetRot(npc);
osNpcSetRot(npc, rot * rot_xyzq);
}
else if (msg == "animate" && npc != NULL_KEY)
{
osAvatarPlayAnimation(npc, "stabbed+die_2");
llSleep(3);
osAvatarStopAnimation(npc, "stabbed+die_2");
}
else if (msg == "save" && npc != NULL_KEY)
{
osNpcSaveAppearance(npc, "appearance");
}
else if (msg == "load" && npc != NULL_KEY)
{
osNpcLoadAppearance(npc, "appearance");
}
else if (msg == "clone")
{
osOwnerSaveAppearance("appearance");
}
else if (msg == "stop" && npc != NULL_KEY)
{
osNpcStopMoveToTarget(npc);
}
else
{
llOwnerSay("I don't understand [" + msg + "]");
}
}
}
}
</source>

=Questions/Comments=

Please feel free to write any questions or comments you have about OSSL NPC functionality here.

I am assuming that we should add a NEW section called [NPC] to the opensim.ini file with the line Enabled = true.

[[Category:OSSL_Functions]]

OSSLNPC

2011-08-19T20:53:52Z

Casiasfalta: /* Questions/Comments */

=Introduction=

Since 12th August 2011 in the Git master development code branch, OpenSim had provided a number of functions for creating and manipulating NPCs. These replace the previous functions, that had stopped working by OpenSim 0.7.1.1 (possibly broken since OpenSim 0.6.9).

The general philosophy in creating these new functions is to

# Give script writers the simple tools needed to create more sophisticated behaviour.
# Avoid duplicating existing LSL and OSSL functions. For instance, finding out what state an agent is in can be done through llGetAgentInfo() rather than creating a special NPC function.

NPCs are controlled via a script which must be in the same region as the NPC. This could be housed in an attachment that is attached to the avatar.

NPCs created user these scripts cannot leave the region in which they were born. If you want region crossing behaviour, please look at the options on the [[NPC]] wiki page.

NPC appearance is saved and loaded by serializing the appearance data structure to a notecard present in the same prim as the script. The required textures should be preserved when an OAR is saved and loaded.

This functionality is at an early stage and method signatures could change, certainly before the release of OpenSim 0.7.2. However, we hope to avoid this.

=Enabling=

To use these functions, in the OpenSim.ini file you will need the following config

# Enabled = true set in the [NPC] section.
# Enabled = true set in the [XEngine] section.
# AllowOSFunctions = true in the [XEngine] section.
# OSFunctionThreatLevel = VeryHigh in the [XEngine] section. The functions osAgentSaveAppearance(), osAvatarPlayAnimation() and osAvatarStopAnimation() need this level. If you don't need these functions, then a "High" level will suffice.

=Notes=

When using your avatar to model appearance before saving, you will need to wait a few seconds before invoking any save appearance command. This is because appearance saving currently operates on a timer in order to manage multiple appearance updates from the viewer.

=Functions=

==Create and Remove==
===[[osNpcCreate]]===

osNpcCreate(string firstname, string lastname, vector position, string cloneFrom):key

cloneFrom may be:

* Name of the notecard containing a serialized avatar appearance, or
* Asset UUID of the Notecard, or
* UUID of an avatar logged into the same region. However, please note that this appearance will not be persisted unless osNpcSaveAppearance() is called.

If the NPC is successfully created, then its UUID is returned, which is required for all subsequent functions. Example is available at [[osNpcCreate]]

===[[osNpcRemove]]===

osNpcRemove(key npc):void

Remove the given avatar from the region. Example at [[osNpcRemove]].

==Get and Set==
===[[osNpcGetRot]]===

Gets the rotation of the avatar. Only the rotation around the Z plane in Euler rotation (horizontal rotation) has any meaning.

osNpcGetRot(key npc):rotation

===[[osNpcSetRot]]===

osNpcSetRot(key npc, rotation rot):void

Set the rotation of the avatar. Only setting the rotation in the Z plane in Euler rotation will have any meaningful effect (turning the avatar to point in one direction or another). Setting X or Y Euler values will result in the avatar rotating in an undefined manner.

===[[osNpcGetPos]]===

osNpcGetPos(key npc):vector

Return the current position of the NPC.

===[[osNpcMoveTo]]===

osNpcMoveTo(key npc, vector position):void

An older function that performs an osNpcMoveToTarget() by flying and landing at the target.

===[[osNpcMoveToTarget]]===

osNpcMoveToTarget(key npc, vector target, int options):void

Move the avatar to a given target over time. How the avatar will get there depends on the following options.

* OS_NPC_FLY - Fly the avatar to the given position. The avatar will not land unless the OS_NPC_LAND_AT_TARGET option is also given.
* OS_NPC_NO_FLY - Do not fly to the target. The NPC will attempt to walk to the location. If it's up in the air then the avatar will keep bouncing hopeless until another move target is given or the move is stopped
* OS_NPC_LAND_AT_TARGET - If given and the avatar is flying, then it will land when it reaches the target. If OS_NPC_NO_FLY is given then this option has no effect.

OS_NPC_FLY and OS_NPC_NO_FLY are options that cannot be combined - the avatar will end up doing one or the other. If you want the avatar to fly and land at the target, then OS_NPC_LAND_AT_TARGET must be combined with OS_NPC_FLY. For instance,

osNpcMoveToTarget(npc, llGetPos() + <9,9,5>, OS_NPC_FLY|OS_NPC_LAND_AT_TARGET);

===[[osNpcStopMoveToTarget]]===

osNpcStopMoveToTarget(key npc):void

Stop a current move to a target.

==Communication==

===[[osNpcSay]]===

osNpcSay(key npc, string message):void

Get the NPC to say the given message.

==Appearance==

NPC appearance is manipulated by saving and loading appearance data to notecards from the same inventory as the invoking script.

===[[osOwnerSaveAppearance]]===

osOwnerSaveAppearance(string notecard):key

Save the owner's current appearance to a notecard in the prim's inventory. This includes body part data, clothing items and attachments. If a notecard with the same name already exists then it is replaced. The owner must be present in the region when this function is invoked. The baked textures for the owner (necessary to recreate appearance on the NPC) are saved permanently.

===[[osAgentSaveAppearance]]===

osAgentSaveAppearance(key agentId, string notecard):key

Save an arbitrary avatar's appearance to a notecard in the prim's inventory. This includes body part data, clothing items and attachments. If a notecard with the same name already exists then it is replaced. The avatar must be present in the region when this function is invoked. The baked textures for the avatar (necessary to recreate appearance on the NPC) are saved permanently.

===[[osNpcSaveAppearance]]===

osNpcSaveAppearance(key npc, string notecard):key

Save the NPC's current appearance to a notecard in the prim's inventory. This includes body part data, clothing items and attachments. If a notecard with the same name already exists then it is replaced. The avatar must be present in the region when this function is invoked. The baked textures for the avatar (necessary to recreate appearance) are saved permanently.

===[[osNpcLoadAppearance]]===

osNpcLoadAppearance(key npc, string notecard):void

Load appearance from a notecard. This notecard must contain appearance data created with one of the save appearance functions.

=Example=

This is a rough example script for most of the current NPC functionality. Please feel free to improve it.

<source lang = "lsl">
key npc;
default
{
state_entry()
{
llListen(10,"",NULL_KEY,"");
}

listen(integer channel, string name, key id, string msg)
{
if (msg != "")
{
if (msg == "create")
{
osOwnerSaveAppearance("appearance");
npc = osNpcCreate("Jane", "Doe", <115, 165, 23>, "appearance");
}
else if (msg == "remove" && npc != NULL_KEY)
{
osNpcSay(npc, "You will pay for this with your liiiiiivvveeessss!!!.....");
osNpcRemove (npc);
}
else if (msg == "say" && npc != NULL_KEY)
{
osNpcSay(npc, "I am your worst Nightmare!!!!");
}
else if (msg == "move" && npc != NULL_KEY)
{
osNpcMoveTo(npc, llGetPos() + <9,9,0>);
}
else if (msg == "movetarget" && npc != NULL_KEY)
{
osNpcMoveToTarget(npc, llGetPos() + <9,9,5>, OS_NPC_FLY|OS_NPC_LAND_AT_TARGET);
}
else if (msg == "movetargetnoland" && npc != NULL_KEY)
{
osNpcMoveToTarget(npc, llGetPos() + <9,9,5>, OS_NPC_FLY);
}
else if (msg == "movetargetwalk" && npc != NULL_KEY)
{
osNpcMoveToTarget(npc, llGetPos() + <9,9,0>, OS_NPC_NO_FLY);
}
else if (msg == "rot" && npc != NULL_KEY)
{
vector xyz_angles = <0,0,45>; // This is to define a 45 degree change
vector angles_in_radians = xyz_angles * DEG_TO_RAD; // Change to Radians
rotation rot_xyzq = llEuler2Rot(angles_in_radians); // Change to a Rotation
rotation rot = osNpcGetRot(npc);
osNpcSetRot(npc, rot * rot_xyzq);
}
else if (msg == "animate" && npc != NULL_KEY)
{
osAvatarPlayAnimation(npc, "stabbed+die_2");
llSleep(3);
osAvatarStopAnimation(npc, "stabbed+die_2");
}
else if (msg == "save" && npc != NULL_KEY)
{
osNpcSaveAppearance(npc, "appearance");
}
else if (msg == "load" && npc != NULL_KEY)
{
osNpcLoadAppearance(npc, "appearance");
}
else if (msg == "clone")
{
osOwnerSaveAppearance("appearance");
}
else if (msg == "stop" && npc != NULL_KEY)
{
osNpcStopMoveToTarget(npc);
}
else
{
llOwnerSay("I don't understand [" + msg + "]");
}
}
}
}
</source>

=Questions/Comments=

Please feel free to write any questions or comments you have about OSSL NPC functionality here.

I am assuming that we should add a new [NPC] section to the opensim.ini file with the line Enable = true.

[[Category:OSSL_Functions]]

OSSLNPC

2011-08-19T20:48:57Z

Casiasfalta: /* Questions/Comments */

=Introduction=

Since 12th August 2011 in the Git master development code branch, OpenSim had provided a number of functions for creating and manipulating NPCs. These replace the previous functions, that had stopped working by OpenSim 0.7.1.1 (possibly broken since OpenSim 0.6.9).

The general philosophy in creating these new functions is to

# Give script writers the simple tools needed to create more sophisticated behaviour.
# Avoid duplicating existing LSL and OSSL functions. For instance, finding out what state an agent is in can be done through llGetAgentInfo() rather than creating a special NPC function.

NPCs are controlled via a script which must be in the same region as the NPC. This could be housed in an attachment that is attached to the avatar.

NPCs created user these scripts cannot leave the region in which they were born. If you want region crossing behaviour, please look at the options on the [[NPC]] wiki page.

NPC appearance is saved and loaded by serializing the appearance data structure to a notecard present in the same prim as the script. The required textures should be preserved when an OAR is saved and loaded.

This functionality is at an early stage and method signatures could change, certainly before the release of OpenSim 0.7.2. However, we hope to avoid this.

=Enabling=

To use these functions, in the OpenSim.ini file you will need the following config

# Enabled = true set in the [NPC] section.
# Enabled = true set in the [XEngine] section.
# AllowOSFunctions = true in the [XEngine] section.
# OSFunctionThreatLevel = VeryHigh in the [XEngine] section. The functions osAgentSaveAppearance(), osAvatarPlayAnimation() and osAvatarStopAnimation() need this level. If you don't need these functions, then a "High" level will suffice.

=Notes=

When using your avatar to model appearance before saving, you will need to wait a few seconds before invoking any save appearance command. This is because appearance saving currently operates on a timer in order to manage multiple appearance updates from the viewer.

=Functions=

==Create and Remove==
===[[osNpcCreate]]===

osNpcCreate(string firstname, string lastname, vector position, string cloneFrom):key

cloneFrom may be:

* Name of the notecard containing a serialized avatar appearance, or
* Asset UUID of the Notecard, or
* UUID of an avatar logged into the same region. However, please note that this appearance will not be persisted unless osNpcSaveAppearance() is called.

If the NPC is successfully created, then its UUID is returned, which is required for all subsequent functions. Example is available at [[osNpcCreate]]

===[[osNpcRemove]]===

osNpcRemove(key npc):void

Remove the given avatar from the region. Example at [[osNpcRemove]].

==Get and Set==
===[[osNpcGetRot]]===

Gets the rotation of the avatar. Only the rotation around the Z plane in Euler rotation (horizontal rotation) has any meaning.

osNpcGetRot(key npc):rotation

===[[osNpcSetRot]]===

osNpcSetRot(key npc, rotation rot):void

Set the rotation of the avatar. Only setting the rotation in the Z plane in Euler rotation will have any meaningful effect (turning the avatar to point in one direction or another). Setting X or Y Euler values will result in the avatar rotating in an undefined manner.

===[[osNpcGetPos]]===

osNpcGetPos(key npc):vector

Return the current position of the NPC.

===[[osNpcMoveTo]]===

osNpcMoveTo(key npc, vector position):void

An older function that performs an osNpcMoveToTarget() by flying and landing at the target.

===[[osNpcMoveToTarget]]===

osNpcMoveToTarget(key npc, vector target, int options):void

Move the avatar to a given target over time. How the avatar will get there depends on the following options.

* OS_NPC_FLY - Fly the avatar to the given position. The avatar will not land unless the OS_NPC_LAND_AT_TARGET option is also given.
* OS_NPC_NO_FLY - Do not fly to the target. The NPC will attempt to walk to the location. If it's up in the air then the avatar will keep bouncing hopeless until another move target is given or the move is stopped
* OS_NPC_LAND_AT_TARGET - If given and the avatar is flying, then it will land when it reaches the target. If OS_NPC_NO_FLY is given then this option has no effect.

OS_NPC_FLY and OS_NPC_NO_FLY are options that cannot be combined - the avatar will end up doing one or the other. If you want the avatar to fly and land at the target, then OS_NPC_LAND_AT_TARGET must be combined with OS_NPC_FLY. For instance,

osNpcMoveToTarget(npc, llGetPos() + <9,9,5>, OS_NPC_FLY|OS_NPC_LAND_AT_TARGET);

===[[osNpcStopMoveToTarget]]===

osNpcStopMoveToTarget(key npc):void

Stop a current move to a target.

==Communication==

===[[osNpcSay]]===

osNpcSay(key npc, string message):void

Get the NPC to say the given message.

==Appearance==

NPC appearance is manipulated by saving and loading appearance data to notecards from the same inventory as the invoking script.

===[[osOwnerSaveAppearance]]===

osOwnerSaveAppearance(string notecard):key

Save the owner's current appearance to a notecard in the prim's inventory. This includes body part data, clothing items and attachments. If a notecard with the same name already exists then it is replaced. The owner must be present in the region when this function is invoked. The baked textures for the owner (necessary to recreate appearance on the NPC) are saved permanently.

===[[osAgentSaveAppearance]]===

osAgentSaveAppearance(key agentId, string notecard):key

Save an arbitrary avatar's appearance to a notecard in the prim's inventory. This includes body part data, clothing items and attachments. If a notecard with the same name already exists then it is replaced. The avatar must be present in the region when this function is invoked. The baked textures for the avatar (necessary to recreate appearance on the NPC) are saved permanently.

===[[osNpcSaveAppearance]]===

osNpcSaveAppearance(key npc, string notecard):key

Save the NPC's current appearance to a notecard in the prim's inventory. This includes body part data, clothing items and attachments. If a notecard with the same name already exists then it is replaced. The avatar must be present in the region when this function is invoked. The baked textures for the avatar (necessary to recreate appearance) are saved permanently.

===[[osNpcLoadAppearance]]===

osNpcLoadAppearance(key npc, string notecard):void

Load appearance from a notecard. This notecard must contain appearance data created with one of the save appearance functions.

=Example=

This is a rough example script for most of the current NPC functionality. Please feel free to improve it.

<source lang = "lsl">
key npc;
default
{
state_entry()
{
llListen(10,"",NULL_KEY,"");
}

listen(integer channel, string name, key id, string msg)
{
if (msg != "")
{
if (msg == "create")
{
osOwnerSaveAppearance("appearance");
npc = osNpcCreate("Jane", "Doe", <115, 165, 23>, "appearance");
}
else if (msg == "remove" && npc != NULL_KEY)
{
osNpcSay(npc, "You will pay for this with your liiiiiivvveeessss!!!.....");
osNpcRemove (npc);
}
else if (msg == "say" && npc != NULL_KEY)
{
osNpcSay(npc, "I am your worst Nightmare!!!!");
}
else if (msg == "move" && npc != NULL_KEY)
{
osNpcMoveTo(npc, llGetPos() + <9,9,0>);
}
else if (msg == "movetarget" && npc != NULL_KEY)
{
osNpcMoveToTarget(npc, llGetPos() + <9,9,5>, OS_NPC_FLY|OS_NPC_LAND_AT_TARGET);
}
else if (msg == "movetargetnoland" && npc != NULL_KEY)
{
osNpcMoveToTarget(npc, llGetPos() + <9,9,5>, OS_NPC_FLY);
}
else if (msg == "movetargetwalk" && npc != NULL_KEY)
{
osNpcMoveToTarget(npc, llGetPos() + <9,9,0>, OS_NPC_NO_FLY);
}
else if (msg == "rot" && npc != NULL_KEY)
{
vector xyz_angles = <0,0,45>; // This is to define a 45 degree change
vector angles_in_radians = xyz_angles * DEG_TO_RAD; // Change to Radians
rotation rot_xyzq = llEuler2Rot(angles_in_radians); // Change to a Rotation
rotation rot = osNpcGetRot(npc);
osNpcSetRot(npc, rot * rot_xyzq);
}
else if (msg == "animate" && npc != NULL_KEY)
{
osAvatarPlayAnimation(npc, "stabbed+die_2");
llSleep(3);
osAvatarStopAnimation(npc, "stabbed+die_2");
}
else if (msg == "save" && npc != NULL_KEY)
{
osNpcSaveAppearance(npc, "appearance");
}
else if (msg == "load" && npc != NULL_KEY)
{
osNpcLoadAppearance(npc, "appearance");
}
else if (msg == "clone")
{
osOwnerSaveAppearance("appearance");
}
else if (msg == "stop" && npc != NULL_KEY)
{
osNpcStopMoveToTarget(npc);
}
else
{
llOwnerSay("I don't understand [" + msg + "]");
}
}
}
}
</source>

=Questions/Comments=

Please feel free to write any questions or comments you have about OSSL NPC functionality here.
I am assuming that we should add a new [NPC] section to the opensim.ini file with the line Enable = true.

[[Category:OSSL_Functions]]

Talk:Virtual World Model

2011-08-19T17:12:44Z

Casiasfalta: /* OSGrid and trust domains */

== Simulator Trust Domain definition==

It currently states: "One or more simulators that completely trust each other, operated by one single authority." Does it really need to be operated by a single authority? Could I not say I fully and completely trust sims operated by John Smith and/or he fully and completely trusts sims operated by me? --[[User:DaveCoyle|DaveCoyle]] 11:40, 20 April 2009 (UTC)

Yes, you are right. I changed the definition. Basically, I think what you're getting at is that each simulator, or each seed trust domain, can extend trust to other trust domains, and this is not transitive: you trust W, but you don't necessarily trust the sims that W trusts. Needs more thinking. --[[User:Diva|Diva]] 07:50, 20 April 2009 (PST)

== OSGrid and trust domains ==

There seems to be continued disagreement regarding OSGrid and trust domains, so let's discuss it here. Charles, you removed the sentence "For example, OSGrid has, by nature and intent, several hundred simulator trust domains." I disagree with its removal, and based on the -dev list thread everyone doesn't seem to be on the same page on this point. So let's talk it out.

I am a region operator on OSGrid. I fully trust sims operated by myself. I fully trust sims operated by a handful of others who I believe will not do anything nefarious to me, my communications, my inventory, etc. I neither trust nor don't trust sims operated by most others, as I neither know them nor have reason to believe they'll do bad things. I do not trust some regions (e.g. DNCH).

Sounds like multiple trust domains to me. --[[User:DaveCoyle|DaveCoyle]] 11:31, 20 April 2009 (UTC)

I would really like to hear more from the OSGrid community about wishes for the future, 1 year ahead. The only reason why I am making that subtle distinction between Grid and Trust Domain is OSGrid. I mention LL grid, but, really, I have no idea what their plans are, that's just speculation. OSGrid, however, exists. Unifying the concept of Grid with that of trust domain will make the model a whole lot simpler and easier to implement, so if that is what's on the map for OSGrid, it would be good to know. --[[User:Diva|Diva]] 09:45, 20 April 2009 (PST)

We have 15 regions on osgrid and our role is one of applying the tech that others are developing. When i need to explain what a grid is to an end-user it is a "world of regions" - the world map is my metaphor. Also, as an "application provider", I would probably prefer grid "safety" to be controlled as much as possible by the person who is providing the opensim.exe instance rather then the grid manager. Just my thoughts. Casias Falta Aug. 19, 2011

== The meaning of ''safety'' ==

There seems to be an important reference left undefined in this useful page. Various paragraphs refer to "safely exchange messages", "unsafe teleports", and "safe simulator connectivity", but nowhere is the meaning of "safety" explained or illustrated. I can imagine a variety of possible considerations that can give rise to a verdict of "safe" versus "unsafe", such as the desire to safeguard assets, or protect system integrity, or prevent abuse, or simply to disallow unauthorized access, but which of these were intended here? Perhaps all of them? Or does "safety" have a specific meaning in this context?

I think it's worth spending a little time defining what is meant here, because the foundational idea of "trust domain" is currently being described in terms of a fuzzy concept that obscures rather than explains. Yes, we all love the motherhood and apple pie implied by "safe", but what does it actually mean in this specific context, for the purposes of model definition? :-) [[User:Morgaine|Morgaine]] 12:37, 10 June 2009 (UTC)

Talk:Virtual World Model

2011-08-19T17:11:44Z

Casiasfalta: /* OSGrid and trust domains */

== Simulator Trust Domain definition==

It currently states: "One or more simulators that completely trust each other, operated by one single authority." Does it really need to be operated by a single authority? Could I not say I fully and completely trust sims operated by John Smith and/or he fully and completely trusts sims operated by me? --[[User:DaveCoyle|DaveCoyle]] 11:40, 20 April 2009 (UTC)

Yes, you are right. I changed the definition. Basically, I think what you're getting at is that each simulator, or each seed trust domain, can extend trust to other trust domains, and this is not transitive: you trust W, but you don't necessarily trust the sims that W trusts. Needs more thinking. --[[User:Diva|Diva]] 07:50, 20 April 2009 (PST)

== OSGrid and trust domains ==

There seems to be continued disagreement regarding OSGrid and trust domains, so let's discuss it here. Charles, you removed the sentence "For example, OSGrid has, by nature and intent, several hundred simulator trust domains." I disagree with its removal, and based on the -dev list thread everyone doesn't seem to be on the same page on this point. So let's talk it out.

I am a region operator on OSGrid. I fully trust sims operated by myself. I fully trust sims operated by a handful of others who I believe will not do anything nefarious to me, my communications, my inventory, etc. I neither trust nor don't trust sims operated by most others, as I neither know them nor have reason to believe they'll do bad things. I do not trust some regions (e.g. DNCH).

Sounds like multiple trust domains to me. --[[User:DaveCoyle|DaveCoyle]] 11:31, 20 April 2009 (UTC)

I would really like to hear more from the OSGrid community about wishes for the future, 1 year ahead. The only reason why I am making that subtle distinction between Grid and Trust Domain is OSGrid. I mention LL grid, but, really, I have no idea what their plans are, that's just speculation. OSGrid, however, exists. Unifying the concept of Grid with that of trust domain will make the model a whole lot simpler and easier to implement, so if that is what's on the map for OSGrid, it would be good to know. --[[User:Diva|Diva]] 09:45, 20 April 2009 (PST)

We have 15 regions on osgrid and our role is one of applying the tech that others are developing. When i need to explain what a grid is to an end-user it is a "world of regions" - the world map is my metaphor. Also, as an "application provider", I would probably prefer grid "safety" to be controlled as much as possible by the person who is providing the opensim.exe instance rather then the grid manager. Just my thoughts.

== The meaning of ''safety'' ==

There seems to be an important reference left undefined in this useful page. Various paragraphs refer to "safely exchange messages", "unsafe teleports", and "safe simulator connectivity", but nowhere is the meaning of "safety" explained or illustrated. I can imagine a variety of possible considerations that can give rise to a verdict of "safe" versus "unsafe", such as the desire to safeguard assets, or protect system integrity, or prevent abuse, or simply to disallow unauthorized access, but which of these were intended here? Perhaps all of them? Or does "safety" have a specific meaning in this context?

I think it's worth spending a little time defining what is meant here, because the foundational idea of "trust domain" is currently being described in terms of a fuzzy concept that obscures rather than explains. Yes, we all love the motherhood and apple pie implied by "safe", but what does it actually mean in this specific context, for the purposes of model definition? :-) [[User:Morgaine|Morgaine]] 12:37, 10 June 2009 (UTC)