Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-11368] [Feature Request] - Created Agents: The solution for animated mesh pets, NPC's and more. #1572

Open
1 task
sl-service-account opened this issue Feb 8, 2016 · 25 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Feb 8, 2016

Please do not triage for two weeks. Give people time to comment. Thanks.

Problem

For years now, users have been asking for a way to animate mesh versus substandard methods such as alpha cycling and puppeteering.
There are jiras mentioning feasibility with custom skeletons, custom mesh and custom animations, but a much simpler means is possible: Created Agents

Solution

Created Agents are essentially the same as regular agents or bots, just without an internet connection to the server. They have their own inventory similar to an object's inventory, and can attach the same things a regular agent can, albeit with a much smaller attachment slot limit.
Created Agents are a new object type that can be rezzed with the Build menu just like prims or Linden plants. See Fig 1
You can choose a male of female base agent to create.
Once rezzed, you will see a default avatar using default animations specific to the gender you choose.
This created agent has a tag similar to agent's that displays "Created Agent" as well as their object name and can be right clicked for options such as:

If rezzed:

  • Edit

  • Take (since created agents are a new object type, they can be taken into inventory and re-rezzed or attached or put into objects to be scripted rezzed)

  • Take Copy

  • Attach (created agents can be attached like an object)

  • Attach HUD (created agents can be attached to HUD slots. This is for apps that use personal assistant mascots or for experience based HUD games that use 2D "in-game" characters, NPC's, monsters, etc.)

  • Delete

  • Return

    If attached:

  • Edit

  • Detach

    When using Edit, the created agent can be selected like an object and inside it's inventory you will see the default body shape, skin, body parts, alpha mask, mesh attachments currently attached in bold like your own inventory.
    You can right click these inventory items and detach, remove, drop in new items, right click and attach them.
    You can also create a New Script in this created agent's inventory or drop in already compiled scripts.
    New script functions are used to move and in-turn, exercise animations and animation overrides on created agents.
    New script functions are used to attach/detach items from their inventories.
    These functions must be called from a script in the created agent's inventory, not from their attachment's inventory or a rezzed object, etc. All targeted inventory items must be inside the created agent's inventory.
    No run-time permissions are necessary for these operations.

    Here are examples of the new functions that will be used:

Controls
llCreatedAvatarApplyControl() - Applies only U,D,L,R,F,B movement and L/R rotating controls. No mouse button controls. Control is active until changed. These controls exercise base and set animation overrides like a normal agent's. Movement can also be faked with llMoveToTarget().

Animations & Overrides
llCreatedAvatarStartAnimation()
llCreatedAvatarStopAnimation()
llCreatedAvatarSetAnimationOverride()
llCreatedAvatarResetAnimationOverride()
llCreatedAvatarGetAnimationOverride()

Attaching/Detaching
llAttachFromCreatedAvatarInventory() - All object type attachments function as temp attachments despite showing as bold in their inventory. No-copy items cannot be attached.
llDetachFromCreatedAvatar()
llAttachToCreatedAvatar() - this is attaching from world, only possible if target object and created agent have an experience set (BUG-11356)
llCreatedAvatarDropToPos() - only possible if created agent has an experience set (BUG-11356) and is over land with the same experience allowed
llCreatedAvatarGetAttachedList() - operates like llGetAttachedList()

Note: Since attaching is temp, there is no state saving of attachment link params or script memory on detach.
Removing an item from a created agent's inventory detaches it if it is attached.

Other
llCreatedAvatarSit() - only possible if created agent and target object/attachment have an experience set (BUG-11356)
llCreatedAvatarStand()
llGetCreatedAvatarInfo() - operates like llGetAgentInfo()

Other Points of Interest

Created avatars have a much smaller attachment allowance, only a dozen slots total compared to an actual agent's 38 and includes all item types including body parts.
This is to encourage primarily rigged mesh use and prevent resource abuse. No HUD slots are used.
Created Agents cannot attach created agents.
If attached, created agents have a base render weight value of 25000 with no attachments.
Created agents have a base land impact of 64 when rezzed.
Limit of 50 created agents allowed in a full region total. Once the limit is reached, users won't be able to rez or attach additional created agents nor be allowed to enter the region while wearing one or sitting on one.
Scripts in created agents can request run-time permissions or experience permissions just like normal objects.
Created agents can have their attachments sat upon by users. (SVC-6100)

Benefits

Substandard methods of mesh and body animation will be made obsolete.
No more render and resource heavy objects with dozens of complex mesh links and alpha cycling protocols.
No more resource heavy stored link position and rotation multi-link SLPPF() limb movement with interpolation ugliness.
No more devoted hardware and bandwidth for running bots with lacking and non-intuitive RegAPI.
Using an actual agent class object base will allow for the ultimate pets, breedables, ridables, NPC's, monsters, game enemies, target dummies, worn product demonstrations, mannequins or adult companion/interactive objects.

Thanks in advance for any consideration. Comments welcome.

Attachments

Links

Related

Original Jira Fields
Field Value
Issue BUG-11368
Summary [Feature Request] - Created Agents: The solution for animated mesh pets, NPC's and more.
Type Bug
Priority Unset
Status Needs More Info
Resolution Unresolved
Reporter Lucia Nightfire (lucia.nightfire)
Created at 2016-02-08T07:02:18Z
Updated at 2017-07-07T15:50:06Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2016-10-03T23:35:43.600-0500',
  'How would you like the feature to work?': 'Please do not triage for two weeks. Give people time to comment. Thanks.\r\n\r\nh1. Problem\r\n\r\nFor years now, users have been asking for a way to animate mesh versus substandard methods such as alpha cycling and puppeteering.\r\nThere are jiras mentioning feasibility with custom skeletons, custom mesh and custom animations, but a much simpler means is possible: Created Agents\r\n\r\nh1. Solution\r\n\r\nCreated Agents are essentially the same as regular agents or bots, just without an internet connection to the server. They have their own inventory similar to an object\'s inventory, and can attach the same things a regular agent can, albeit with a much smaller attachment slot limit.\r\nCreated Agents are a new object type that can be rezzed with the Build menu just like prims or Linden plants.\r\nYou can choose a male of female base agent to create.\r\nOnce rezzed, you will see a default avatar using default animations specific to the gender you choose.\r\nThis created agent has a tag similar to agent\'s that displays "Created Agent" as well as their object name and can be right clicked for options such as:\r\n\r\nIf rezzed:\r\n* Edit\r\n* Take (since created agents are a new object type, they can be taken into inventory and re-rezzed or attached or put into objects to be scripted rezzed)\r\n* Take Copy\r\n* Attach (created agents can be attached like an object)\r\n* Attach HUD (created agents can be attached to HUD slots. This is for apps that use personal assistant mascots or for experience based HUD games that use 2D "in-game" characters, NPC\'s, monsters, etc.)\r\n* Delete\r\n* Return\r\n\r\nIf attached:\r\n* Edit\r\n* Detach\r\n\r\nWhen using Edit, the created agent can be selected like an object and inside it\'s inventory you will see the default body shape, skin, body parts, alpha mask, mesh attachments currently attached in bold like your own inventory.\r\nYou can right click these inventory items and detach, remove, drop in new items, right click and attach them.\r\nYou can also create a New Script in this created agent\'s inventory or drop in already compiled scripts.\r\nNew script functions are used to move and in-turn, exercise animations and animation overrides on created agents.\r\nNew script functions are used to attach/detach items from their inventories.\r\nThese scripts must be called from within a script inside the created agent\'s inventory, not from their attachment\'s inventory or a rezzed object, etc. All targeted inventory items must be inside the created agent\'s inventory.\r\nNo run-time permissions are necessary for these operations.\r\n\r\nHere are examples of the new functions that will be used:\r\n\r\n*Controls*\r\nllCreatedAvatarApplyControl() - Applies only U,D,L,R,F,B movement and L/R rotating controls. No mouse button controls. Control is active until changed. These controls exercise base and set animation overrides like a normal agent\'s. Movement can also be faked with llMoveToTarget().\r\n\r\n*Animations & Overrides*\r\nllCreatedAvatarStartAnimation()\r\nllCreatedAvatarStopAnimation()\r\nllCreatedAvatarSetAnimationOverride()\r\nllCreatedAvatarResetAnimationOverride()\r\nllCreatedAvatarGetAnimationOverride()\r\n\r\n*Attaching/Detaching*\r\nllAttachFromCreatedAvatarInventory() - All object type attachments function as temp attachments despite showing as bold in their inventory. No-copy items cannot be attached.\r\nllDetachFromCreatedAvatar()\r\nllAttachToCreatedAvatar() - this is attaching from world, only possible if target object and created agent have an experience set (BUG-11356)\r\nllCreatedAvatarDropToPos() - only possible if created agent has an experience set (BUG-11356) and is over land with the same experience allowed\r\nllCreatedAvatarGetAttachedList() - operates like llGetAttachedList()\r\n\r\nNote: Since attaching is temp, there is no state saving of attachment link params or script memory on detach.\r\nRemoving an item from a created agent\'s inventory detaches it if it is attached.\r\n\r\n*Other*\r\nllCreatedAvatarSit() - only possible if created agent and target object/attachment have an experience set (BUG-11356)\r\nllCreatedAvatarStand()\r\nllGetCreatedAvatarInfo() - operates like llGetAgentInfo()\r\n\r\nh1. Other Points of Interest\r\n\r\nCreated avatars have a much smaller attachment allowance, only a dozen slots total compared to an actual agent\'s 38 and includes all item types including body parts. This is to encourage primarily rigged mesh use and prevent resource abuse. No HUD slots are used.\r\nCreated Agents cannot attach created agents.\r\nIf attached, created agents have a base render weight value of 25000 with no attachments.\r\nCreated agents have a base land impact of 64 when rezzed.\r\nLimit of 50 created agents allowed in a full region total. Once the limit is reached, users won\'t be able to rez or attach additional created agents nor be allowed to enter the region while wearing one or sitting on one.\r\nScripts in created agents can request run-time permissions or experience permissions just like normal objects.\r\nCreated agents can have their attachments sat upon by users. (SVC-6100)\r\n\r\nh1. Benefits\r\n\r\nSubstandard methods of mesh and body animation will be made obsolete.\r\nNo more render and resource heavy objects with dozens of complex mesh links and cycling alpha protocols.\r\nNo more storing link positions and rotations for various limb animations, also resource heavy.\r\nNo more devoted hardware and bandwidth for running bots with lacking and non-intuitive RegAPI.\r\nUsing an actual agent class object base will allow for the ultimate pets, breedables, ridables, NPC\'s, monsters, target dummies, worn product demonstrations, mannequins or adult companion/interactive objects.\r\n\r\nThanks in advance for any consideration. Comments welcome.',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': '\r\n\r\nPlease do not triage for two weeks. Give people time to comment. Thanks.\r\nProblem\r\n\r\nFor years now, users have been asking for a way to animate mesh versus substandard methods such as alpha cycling and puppeteering.\r\nThere are jiras mentioning feasibility with custom skeletons, custom mesh and custom animations, but a much simpler means is possible: Created Agents\r\nSolution\r\n\r\nCreated Agents are essentially the same as regular agents or bots, just without an internet connection to the server. They have their own inventory similar to an object\'s inventory, and can attach the same things a regular agent can, albeit with a much smaller attachment slot limit.\r\nCreated Agents are a new object type that can be rezzed with the Build menu just like prims or Linden plants. See Fig 1\r\nYou can choose a male of female base agent to create.\r\nOnce rezzed, you will see a default avatar using default animations specific to the gender you choose.\r\nThis created agent has a tag similar to agent\'s that displays "Created Agent" as well as their object name and can be right clicked for options such as:\r\n\r\nIf rezzed:\r\n\r\n    Edit\r\n    Take (since created agents are a new object type, they can be taken into inventory and re-rezzed or attached or put into objects to be scripted rezzed)\r\n    Take Copy\r\n    Attach (created agents can be attached like an object)\r\n    Attach HUD (created agents can be attached to HUD slots. This is for apps that use personal assistant mascots or for experience based HUD games that use 2D "in-game" characters, NPC\'s, monsters, etc.)\r\n    Delete\r\n    Return\r\n\r\nIf attached:\r\n\r\n    Edit\r\n    Detach\r\n\r\nWhen using Edit, the created agent can be selected like an object and inside it\'s inventory you will see the default body shape, skin, body parts, alpha mask, mesh attachments currently attached in bold like your own inventory.\r\nYou can right click these inventory items and detach, remove, drop in new items, right click and attach them.\r\nYou can also create a New Script in this created agent\'s inventory or drop in already compiled scripts.\r\nNew script functions are used to move and in-turn, exercise animations and animation overrides on created agents.\r\nNew script functions are used to attach/detach items from their inventories.\r\nThese functions must be called from a script in the created agent\'s inventory, not from their attachment\'s inventory or a rezzed object, etc. All targeted inventory items must be inside the created agent\'s inventory.\r\nNo run-time permissions are necessary for these operations.\r\n\r\nHere are examples of the new functions that will be used:\r\n\r\nControls\r\nllCreatedAvatarApplyControl() - Applies only U,D,L,R,F,B movement and L/R rotating controls. No mouse button controls. Control is active until changed. These controls exercise base and set animation overrides like a normal agent\'s. Movement can also be faked with llMoveToTarget().\r\n\r\nAnimations & Overrides\r\nllCreatedAvatarStartAnimation()\r\nllCreatedAvatarStopAnimation()\r\nllCreatedAvatarSetAnimationOverride()\r\nllCreatedAvatarResetAnimationOverride()\r\nllCreatedAvatarGetAnimationOverride()\r\n\r\nAttaching/Detaching\r\nllAttachFromCreatedAvatarInventory() - All object type attachments function as temp attachments despite showing as bold in their inventory. No-copy items cannot be attached.\r\nllDetachFromCreatedAvatar()\r\nllAttachToCreatedAvatar() - this is attaching from world, only possible if target object and created agent have an experience set (BUG-11356)\r\nllCreatedAvatarDropToPos() - only possible if created agent has an experience set (BUG-11356) and is over land with the same experience allowed\r\nllCreatedAvatarGetAttachedList() - operates like llGetAttachedList()\r\n\r\nNote: Since attaching is temp, there is no state saving of attachment link params or script memory on detach.\r\nRemoving an item from a created agent\'s inventory detaches it if it is attached.\r\n\r\nOther\r\nllCreatedAvatarSit() - only possible if created agent and target object/attachment have an experience set (BUG-11356)\r\nllCreatedAvatarStand()\r\nllGetCreatedAvatarInfo() - operates like llGetAgentInfo()\r\nOther Points of Interest\r\n\r\nCreated avatars have a much smaller attachment allowance, only a dozen slots total compared to an actual agent\'s 38 and includes all item types including body parts.\r\nThis is to encourage primarily rigged mesh use and prevent resource abuse. No HUD slots are used.\r\nCreated Agents cannot attach created agents.\r\nIf attached, created agents have a base render weight value of 25000 with no attachments.\r\nCreated agents have a base land impact of 64 when rezzed.\r\nLimit of 50 created agents allowed in a full region total. Once the limit is reached, users won\'t be able to rez or attach additional created agents nor be allowed to enter the region while wearing one or sitting on one.\r\nScripts in created agents can request run-time permissions or experience permissions just like normal objects.\r\nCreated agents can have their attachments sat upon by users. (SVC-6100)\r\nBenefits\r\n\r\nSubstandard methods of mesh and body animation will be made obsolete.\r\nNo more render and resource heavy objects with dozens of complex mesh links and alpha cycling protocols.\r\nNo more resource heavy stored link position and rotation multi-link SLPPF() limb movement with interpolation ugliness.\r\nNo more devoted hardware and bandwidth for running bots with lacking and non-intuitive RegAPI.\r\nUsing an actual agent class object base will allow for the ultimate pets, breedables, ridables, NPC\'s, monsters, game enemies, target dummies, worn product demonstrations, mannequins or adult companion/interactive objects.\r\n\r\nThanks in advance for any consideration. Comments welcome.\r\n',
  'What were you doing when it happened?': '\r\n\r\nPlease do not triage for two weeks. Give people time to comment. Thanks.\r\nProblem\r\n\r\nFor years now, users have been asking for a way to animate mesh versus substandard methods such as alpha cycling and puppeteering.\r\nThere are jiras mentioning feasibility with custom skeletons, custom mesh and custom animations, but a much simpler means is possible: Created Agents\r\nSolution\r\n\r\nCreated Agents are essentially the same as regular agents or bots, just without an internet connection to the server. They have their own inventory similar to an object\'s inventory, and can attach the same things a regular agent can, albeit with a much smaller attachment slot limit.\r\nCreated Agents are a new object type that can be rezzed with the Build menu just like prims or Linden plants. See Fig 1\r\nYou can choose a male of female base agent to create.\r\nOnce rezzed, you will see a default avatar using default animations specific to the gender you choose.\r\nThis created agent has a tag similar to agent\'s that displays "Created Agent" as well as their object name and can be right clicked for options such as:\r\n\r\nIf rezzed:\r\n\r\n    Edit\r\n    Take (since created agents are a new object type, they can be taken into inventory and re-rezzed or attached or put into objects to be scripted rezzed)\r\n    Take Copy\r\n    Attach (created agents can be attached like an object)\r\n    Attach HUD (created agents can be attached to HUD slots. This is for apps that use personal assistant mascots or for experience based HUD games that use 2D "in-game" characters, NPC\'s, monsters, etc.)\r\n    Delete\r\n    Return\r\n\r\nIf attached:\r\n\r\n    Edit\r\n    Detach\r\n\r\nWhen using Edit, the created agent can be selected like an object and inside it\'s inventory you will see the default body shape, skin, body parts, alpha mask, mesh attachments currently attached in bold like your own inventory.\r\nYou can right click these inventory items and detach, remove, drop in new items, right click and attach them.\r\nYou can also create a New Script in this created agent\'s inventory or drop in already compiled scripts.\r\nNew script functions are used to move and in-turn, exercise animations and animation overrides on created agents.\r\nNew script functions are used to attach/detach items from their inventories.\r\nThese functions must be called from a script in the created agent\'s inventory, not from their attachment\'s inventory or a rezzed object, etc. All targeted inventory items must be inside the created agent\'s inventory.\r\nNo run-time permissions are necessary for these operations.\r\n\r\nHere are examples of the new functions that will be used:\r\n\r\nControls\r\nllCreatedAvatarApplyControl() - Applies only U,D,L,R,F,B movement and L/R rotating controls. No mouse button controls. Control is active until changed. These controls exercise base and set animation overrides like a normal agent\'s. Movement can also be faked with llMoveToTarget().\r\n\r\nAnimations & Overrides\r\nllCreatedAvatarStartAnimation()\r\nllCreatedAvatarStopAnimation()\r\nllCreatedAvatarSetAnimationOverride()\r\nllCreatedAvatarResetAnimationOverride()\r\nllCreatedAvatarGetAnimationOverride()\r\n\r\nAttaching/Detaching\r\nllAttachFromCreatedAvatarInventory() - All object type attachments function as temp attachments despite showing as bold in their inventory. No-copy items cannot be attached.\r\nllDetachFromCreatedAvatar()\r\nllAttachToCreatedAvatar() - this is attaching from world, only possible if target object and created agent have an experience set (BUG-11356)\r\nllCreatedAvatarDropToPos() - only possible if created agent has an experience set (BUG-11356) and is over land with the same experience allowed\r\nllCreatedAvatarGetAttachedList() - operates like llGetAttachedList()\r\n\r\nNote: Since attaching is temp, there is no state saving of attachment link params or script memory on detach.\r\nRemoving an item from a created agent\'s inventory detaches it if it is attached.\r\n\r\nOther\r\nllCreatedAvatarSit() - only possible if created agent and target object/attachment have an experience set (BUG-11356)\r\nllCreatedAvatarStand()\r\nllGetCreatedAvatarInfo() - operates like llGetAgentInfo()\r\nOther Points of Interest\r\n\r\nCreated avatars have a much smaller attachment allowance, only a dozen slots total compared to an actual agent\'s 38 and includes all item types including body parts.\r\nThis is to encourage primarily rigged mesh use and prevent resource abuse. No HUD slots are used.\r\nCreated Agents cannot attach created agents.\r\nIf attached, created agents have a base render weight value of 25000 with no attachments.\r\nCreated agents have a base land impact of 64 when rezzed.\r\nLimit of 50 created agents allowed in a full region total. Once the limit is reached, users won\'t be able to rez or attach additional created agents nor be allowed to enter the region while wearing one or sitting on one.\r\nScripts in created agents can request run-time permissions or experience permissions just like normal objects.\r\nCreated agents can have their attachments sat upon by users. (SVC-6100)\r\nBenefits\r\n\r\nSubstandard methods of mesh and body animation will be made obsolete.\r\nNo more render and resource heavy objects with dozens of complex mesh links and alpha cycling protocols.\r\nNo more resource heavy stored link position and rotation multi-link SLPPF() limb movement with interpolation ugliness.\r\nNo more devoted hardware and bandwidth for running bots with lacking and non-intuitive RegAPI.\r\nUsing an actual agent class object base will allow for the ultimate pets, breedables, ridables, NPC\'s, monsters, game enemies, target dummies, worn product demonstrations, mannequins or adult companion/interactive objects.\r\n\r\nThanks in advance for any consideration. Comments welcome.\r\n',
  'What were you expecting to happen instead?': '\r\n\r\nPlease do not triage for two weeks. Give people time to comment. Thanks.\r\nProblem\r\n\r\nFor years now, users have been asking for a way to animate mesh versus substandard methods such as alpha cycling and puppeteering.\r\nThere are jiras mentioning feasibility with custom skeletons, custom mesh and custom animations, but a much simpler means is possible: Created Agents\r\nSolution\r\n\r\nCreated Agents are essentially the same as regular agents or bots, just without an internet connection to the server. They have their own inventory similar to an object\'s inventory, and can attach the same things a regular agent can, albeit with a much smaller attachment slot limit.\r\nCreated Agents are a new object type that can be rezzed with the Build menu just like prims or Linden plants. See Fig 1\r\nYou can choose a male of female base agent to create.\r\nOnce rezzed, you will see a default avatar using default animations specific to the gender you choose.\r\nThis created agent has a tag similar to agent\'s that displays "Created Agent" as well as their object name and can be right clicked for options such as:\r\n\r\nIf rezzed:\r\n\r\n    Edit\r\n    Take (since created agents are a new object type, they can be taken into inventory and re-rezzed or attached or put into objects to be scripted rezzed)\r\n    Take Copy\r\n    Attach (created agents can be attached like an object)\r\n    Attach HUD (created agents can be attached to HUD slots. This is for apps that use personal assistant mascots or for experience based HUD games that use 2D "in-game" characters, NPC\'s, monsters, etc.)\r\n    Delete\r\n    Return\r\n\r\nIf attached:\r\n\r\n    Edit\r\n    Detach\r\n\r\nWhen using Edit, the created agent can be selected like an object and inside it\'s inventory you will see the default body shape, skin, body parts, alpha mask, mesh attachments currently attached in bold like your own inventory.\r\nYou can right click these inventory items and detach, remove, drop in new items, right click and attach them.\r\nYou can also create a New Script in this created agent\'s inventory or drop in already compiled scripts.\r\nNew script functions are used to move and in-turn, exercise animations and animation overrides on created agents.\r\nNew script functions are used to attach/detach items from their inventories.\r\nThese functions must be called from a script in the created agent\'s inventory, not from their attachment\'s inventory or a rezzed object, etc. All targeted inventory items must be inside the created agent\'s inventory.\r\nNo run-time permissions are necessary for these operations.\r\n\r\nHere are examples of the new functions that will be used:\r\n\r\nControls\r\nllCreatedAvatarApplyControl() - Applies only U,D,L,R,F,B movement and L/R rotating controls. No mouse button controls. Control is active until changed. These controls exercise base and set animation overrides like a normal agent\'s. Movement can also be faked with llMoveToTarget().\r\n\r\nAnimations & Overrides\r\nllCreatedAvatarStartAnimation()\r\nllCreatedAvatarStopAnimation()\r\nllCreatedAvatarSetAnimationOverride()\r\nllCreatedAvatarResetAnimationOverride()\r\nllCreatedAvatarGetAnimationOverride()\r\n\r\nAttaching/Detaching\r\nllAttachFromCreatedAvatarInventory() - All object type attachments function as temp attachments despite showing as bold in their inventory. No-copy items cannot be attached.\r\nllDetachFromCreatedAvatar()\r\nllAttachToCreatedAvatar() - this is attaching from world, only possible if target object and created agent have an experience set (BUG-11356)\r\nllCreatedAvatarDropToPos() - only possible if created agent has an experience set (BUG-11356) and is over land with the same experience allowed\r\nllCreatedAvatarGetAttachedList() - operates like llGetAttachedList()\r\n\r\nNote: Since attaching is temp, there is no state saving of attachment link params or script memory on detach.\r\nRemoving an item from a created agent\'s inventory detaches it if it is attached.\r\n\r\nOther\r\nllCreatedAvatarSit() - only possible if created agent and target object/attachment have an experience set (BUG-11356)\r\nllCreatedAvatarStand()\r\nllGetCreatedAvatarInfo() - operates like llGetAgentInfo()\r\nOther Points of Interest\r\n\r\nCreated avatars have a much smaller attachment allowance, only a dozen slots total compared to an actual agent\'s 38 and includes all item types including body parts.\r\nThis is to encourage primarily rigged mesh use and prevent resource abuse. No HUD slots are used.\r\nCreated Agents cannot attach created agents.\r\nIf attached, created agents have a base render weight value of 25000 with no attachments.\r\nCreated agents have a base land impact of 64 when rezzed.\r\nLimit of 50 created agents allowed in a full region total. Once the limit is reached, users won\'t be able to rez or attach additional created agents nor be allowed to enter the region while wearing one or sitting on one.\r\nScripts in created agents can request run-time permissions or experience permissions just like normal objects.\r\nCreated agents can have their attachments sat upon by users. (SVC-6100)\r\nBenefits\r\n\r\nSubstandard methods of mesh and body animation will be made obsolete.\r\nNo more render and resource heavy objects with dozens of complex mesh links and alpha cycling protocols.\r\nNo more resource heavy stored link position and rotation multi-link SLPPF() limb movement with interpolation ugliness.\r\nNo more devoted hardware and bandwidth for running bots with lacking and non-intuitive RegAPI.\r\nUsing an actual agent class object base will allow for the ultimate pets, breedables, ridables, NPC\'s, monsters, game enemies, target dummies, worn product demonstrations, mannequins or adult companion/interactive objects.\r\n\r\nThanks in advance for any consideration. Comments welcome.\r\n',
  'Why is this feature important to you? How would it benefit the community?': '?',
}
@sl-service-account
Copy link
Author

Kadah Coba commented at 2016-10-04T04:35:44Z

Can the comments on this be opened on this for those without special access? There are a lot of creators that would invest in this type of feature for a variety of applications and it would be a shame if good input just ends goes to /dev/null instead.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2016-10-04T17:50:32Z

Others can comment on this issue now.

@sl-service-account
Copy link
Author

Kadah Coba commented at 2016-10-06T05:59:04Z

None privileged users cannot make comments still.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2016-10-06T10:42:09Z

Hmm it appears that feature requests in an NMI state can still only be commented on by the filer and those with extra JIRA privs. A Linden will need to fix the feature request workflow to fix that.
Bug reports in an NMI state can be commented on by everyone.

I'll move this over to a "bug" report & then everyone should be able to comment.
Hopefully it's ok to do that. LL already imported this feature request anyway.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2016-10-06T10:45:38Z, updated at 2016-10-06T10:47:32Z

Ok try commenting now :)
Don't click the "Information provided" button or comments will be locked again.

@sl-service-account
Copy link
Author

Stupid commented at 2016-10-07T02:37:29Z

Test

@sl-service-account
Copy link
Author

Jasdac Stockholm commented at 2016-10-09T13:29:06Z

Alright, here's some feedback:

  1. Controls: I would rather see the created agent function like any other prim. I think it would be silly to have created agents without the ability to use the LSL pathfinding tools, and forcing scripters to use the arrow keys to navigate NPCs seems like something more suited for the regular SL bots we already have today. You should also be able to use functions such as llSetRegionPos etc to move the NPCs around.

  2. Animations - Wouldn't it be easier to just use the built in permissoin system? llRequestPermissions(llGetKey(), perms)

  3. Attaching/detaching - Looks good to me

- Created avatars have a much smaller attachment allowance, only a dozen slots total compared to an actual agent's 38 and includes all item types including body parts.
- Created agents have a base land impact of 64 when rezzed.

Why? I'd expect them to work like a normal linkset. If the created agents don't use the stock body I would expect a land impact of 1. Then adding land impact based on the attachments like you would with any other linkset.

  1. Limit of 50 created agents allowed in a full region total. Once the limit is reached, users won't be able to rez or attach additional created agents nor be allowed to enter the region while wearing one or sitting on one.

This would make the feature completely useless for any games other than sim-locked experiences. If there should be a limit at all, let the region owner decide a max number.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2016-10-09T20:09:30Z

Since created agents will be quasi objects, it isn't impossible for them to have both agent and object qualities that will allow pathfinding functions to directly affect them as well.
The control functions are not for user interfacing so no one has the use arrow keys or anything unless they want to make some kind of keyboard controller. The controls are simply scripted inputs meant to trigger animations and animation overrides like they are with regular avatars without the need for a script to explicitly trigger them via agent info and environment feedback on a fast timer. Controls can jointly be used with pathfinding and/or explicit animations if necessary.

The land impact values, render cost, limit per region values were to deter render lag and crashes via abuse by numbers. Think of the render memory and FPS issues people currently have when entering a area with dozens of agents wearing dozens of complex rigged mesh. If LL can implement both https://jira.secondlife.com/browse/BUG-37668 & https://jira.secondlife.com/browse/BUG-40520 then such limits might not be as critical.

@sl-service-account
Copy link
Author

Jasdac Stockholm commented at 2016-10-09T20:30:54Z

I think I see what you mean with llCreatedAvatarApplyControl(), you mean it raises the control() event?

Render cost I have no issue with. Land impact still seems excessive to me. I see your point with the render memory bug, but having an arbitrary region limit allows people to easily rez a bunch of small created agents, denying anyone else from playing in that sim. Something I would say is an equally big issue. In that case I'd rather wait for LL to fix BUG-37668 & BUG-40520 before working on or releasing this, as a sim limit would significantly gimp the feature.

With 64 land impact today you can make some seriously good looking alpha stepping animations. In order to compete I don't think having a forced land impact of more than 32 would be reasonable.

@sl-service-account
Copy link
Author

Kadah Coba commented at 2016-10-11T06:49:37Z

"Created Avatar" is rather ambiguous, "Scripted Agent" would be more descriptive.

Preface, I am not an expert but I know and understand better than most users much of the sim-viewer communications and how agents are handled within the viewer. Most of my points here are taking in to account the technical standpoint of implementing this feature within existing platform design without massively ballooning the scope.

For clarification, by "rezable games" I mean a thing that is not experience based or locked to a physical grid location owned by the game. It would be a game or something similar which someone would rez themselves or as part of a HUD, either on their own land, friends' land, group land, or acceptable sandbox, with any of those potentially being on mainland or a private estate.

Creation and general stuff:
The simplest technical way I see working would be to make it an LSL function call to create a scripted agent is passed the name to a avatar shape asset within the calling object. The object this script is in, I will be calling their "root object".
"Male/Female" is a distinction of the the shape asset, the scripted avatar would not need to have a defined gender/sex.
Scripted agent would need to be bound to their root object (ie. derez root object, scripted agent also derezes).
I do not know if it would be technically possible for the root object to be physically part of the script agent, either as an attachment or as the actual body of it, or if they would be unlocked from the root object (eg. can move about freely from it). I would lean towards the former as this would allow for most of the scripting to happen with in the root obejct.
Scripted agent's inventory is that of their root object.

Land impact (LI):
Making the LI of a scripted agent the same as the total rezzed LI of all its attachments would kill it for a lot of uses. Example: as mannequin for displaying products for avatars for sale, unless there is a side intent to rein in the LI of attachments.
Making the LI a fixed number seems completely arbitrary.

Render Avatar Complexity:
If the concern isn't actually LI but is render lag, then using LI would be ill suited since RenderAvatarMaxComplexity and jelly dolls already exists for this purpose. Within the viewer, add a separate RenderAvatarMaxComplexity setting for scripted agents that's somewhat lower than the one for real agents and make scripted agents more likely to imposter than real agents.
Perhaps scripted agents have a sim imposed complexity limit? Maybe attachments would fail to attach if over the limit.

Region limits:
If there is a limit, it should not be possible for one land owner on a region to use all of the limit.
The limit should be high enough to make a detailed sim wide experience. 50 seems like it would be the absolute lowest for this.
If a use case for this is for breedables, then the limit would need to be quite high, upwards of 200.
Adding a configurable "scripted agent limited" to region settings may be out of scope, but if making the limit configurable via SimConsole would be within scope, that would be acceptable to me.
Perhaps a new impact score for scripted agents? Example, region would have a limit of 500, a scripted agent with a single rigged mesh would be a 1, while a scripted agent that is basically a mirror of a fully decked out avatar would get a score >1.

Permissions:
llRequestPermissions would work fine here. On attachment, own script get permission automatically already.
For external llRequestPermissions requests, there would need to be some method to handle this (like a new event, a method to set what defaults to always accept and what object owners, or something as simple as always accept all from the scripted agent's owner) or that it is a known limitation that only internal permissions will be granted.
Obviously PERMISSION_DEBIT, PERMISSION_SILENT_ESTATE_MANAGEMENT and PERMISSION_RETURN_OBJECTS would not be one that would be granted automaticly by any means and would prompt the object owner as usual.

Movement/controls:
Being able to make use of pathfinding would be nice, but should not be a requirement. Making it a requirement would kill its use for things like rezable games and possible breedables.
It should be possible to have them move just like any other object via LSL currently.
It should be possible to have them move just like an agent wearing a scripted attachment via LSL currently.
Exposing the "double-click move to" function to LSL would be nice.
New LSL functions to make scripted agent sit or stand would be nice since they won't have RLV. Perhaps limit trolling potential by only allowing them to sit on objects of their owner or at least have sit targets.
Where and how far the scripted agent can travel would most likely need to be limited. Should be at least bound to the sim their root object is in, with inter-parcel/sim movement limited by the existed "object entry" parcel permission.

Animations:
Why would new functions be needed?
Any of the existing LSL functions called from its attachments should work as expected when called from attachments. Example, scripted agent wears scripted AO, AO works as it would on a regular avatar.
LSL animation calls from the root object could be treated the same as an attachment or as if the agent was sitting on it.

Attachments:
Number of attachments allowed should be enough to display an average full outfit. 12 would be too low for many avatars that are not a comprised of mostly rigged mesh. Most non all-in-one furry avatars consist of 14 basic parts: Head; Jaw; Tail; Hail; Ear L,R; Eye L,R; Hand L,R; Foot L,R; Leg L,R.
Regarding new functions, see Animations above. Though a new function would be needed for detaching.
Attachments would be objects contained within the scripted agent prim.
Attach from world, I can't see a use case for needing this. Example, If the scripted agent needs to appear like its picking up something, it could just have a copy of the object within itself.
Drop, this would be standard llRezObject since the attachments would be objects within the scripted agent. No-copy would fail silently if attached.

As an attachment:
If the scripted agent is a separate entity from the root object, I can see this having its uses for rezable games.
Otherwise, unless LL is going to finally give the ablity to sit on other agents, this can't be a thing.

Wearables:
New function to apply a different shapes assets.
New functions to wear and take off other wearables would be needed if the default avatar mesh is going to be supported by scripted agents. IMO, I think we could live without this support (rigged mesh exists) and it would help limit the size of the project.
Not having system avatar support would remove requirement for scripted agents needing to use SSA to bake.

Name tags:
Either have no name tags at all or be optional. Scripted agent use with games or pets, or many other applications, could be decremented if name tags were required. Example, NPC zombie would be unable to hide in fog with a name tag clearly visible. Example, when I look down at my breedable puppy, all I see is its name tag in my face.

Editing:
Being able to access the inventory and edit the scripts of the root object would be a necessity.
I don't see being able to edit things attached to a scripted agent as being something that could be in the scope of this project. There exist no current means within the viewer to edit attachments worn by non-self agents. This would be a big project on its own.
Their attachments can be edited by wearing them on your own avatar, editing as needed, then copy/move the objects in to scripted agent prim.

Backwards compatibility:
Scripted agents would need enough info of standard agent for the viewer to understand and render them. Newer viewers would have additional code to handle them more properly. I do not know these sim-viewer messages well enough from memory to know if this wouldn't just ended up as one massive kludge.
Alternately, a new sim capability for scripted agents that would require a newer viewer in order to see them. Viewers that do not support it would only see the root object, if visible.

Physics:
It should possible for LSL to set physics type on the scripted agent to be that of an avatar, but not a requirement that it has to have it.
Being able to have a scripted agent that cannot be pushed/shoved would have its applications. As would giving them normal prim physics which can have various settable options.
(I know that a prim can have avatar physics already, though there exist no current means to create these and have never been an official way to create them (creation was caused by an after effect of an exploit from before my time, I think it was the "link to ground" one). These prims exhibit the same physical properties as an avatar, like being pushed, rounded, cannot fall over, etc.)

@sl-service-account
Copy link
Author

Kadah Coba commented at 2016-10-11T06:57:48Z

I know it would be helpful to have use cases exampled and detailed. They're "user stories", which fits in to the whole agile software development thing. Please add some. :)

@sl-service-account
Copy link
Author

Penny Patton commented at 2016-12-02T04:24:51Z, updated at 2016-12-02T04:31:57Z

Regarding Land Impact cost of agents, I agree that the LI cost should be the same as the combined LI of its attachments. If that kills its usefulness for content creators who want to use them as display mannequins than, well, I'm afraid we should be blunt about this. Those creators need to get better at optimizing their content. Just because avatars have no land impact limits doesn't mean content creators should go crazy with polygons. This is one of the reasons SL runs so poorly. Hell, introducing NPC agents and making their LI the sum of their attachments could be a good kick in the behinds of content creators to get smarter about optimization.

Any arbitrary limits on the number of NPC agents to a parcel/sim should be dismissed. Any such limits should be based on their impact on sim performance. I'm not a technical person, so I can't imagine what the impact would be. But if an unscripted, unanimated NPC agent has the same impact on a sim as an unscripted prim, then the only limit I would see would be their LI cost on the parcel. If adding scripts and animations adds a greater impact to the sim beyond scripting and animating prims, then the devs should figure the best way to handle that.

I'll add to that, anyone who owns land should be able to add NPCs to their land. Whether they own a solitary mainland parcel, or they rent from an estate. Being able to create, animate and script NPC Agents would be a game-changer for SL, giving us the ability to create a level of engagement and immersion that has hitherto been entirely impossible in SL.

@sl-service-account
Copy link
Author

Penny Patton commented at 2016-12-02T05:14:57Z

As for User Stories I can think of a lot of ways I'd implement NPCs in a sim. Currently, SL feels like a collection of dioramas filled with statues. When prim/mesh objects are animated in SL the result is very crude, like a badly made animatronic. It's not believable or engaging. NPC agents would change that.

Use case: Forest Sim
NPCs could be used to populate the sim with fauna. Rabbits running through the underbrush. Deer strolling some distance from the paths. The NPC animals could be scripted to react differently to live avatars. Rabbits and squirrels might run from approaching avatars, retreating to their homes. NPC birds might crowd a short distance away from avatars sitting on a bench, in the hope of getting food tossed to them (idea: scripted food tossing object you could pick up from a human NPC vendor in the park), but flying away if an avatar gets too close to them.

Use case: Tour Guide
An NPC could act as a tour guide to visitors, showing them around the sim by taking them on a scripted path with scripted events along the way where the NPC guide might stop to point something out, or give some flavour text about an item. This engages visitors, gives them a taste of what the sim has to offer. If it's an RP sim, such an NPC would be perfect to get new visitors immersed in the RP even if no one else is around at the moment. This sort of NPC could also be used for the SL new user experience, guiding a new SL resident through a series of short tutorials before sending them out into the world. One need only look at how NPCs are used in videogame tutorials to see how that could be applied to SL. A new resident could watch the NPC demonstrate the task they themselves are about to attempt, for example.

Use case: A better alternative to bots
Currently, bots are used in some RP sims, such as The Wastelands, to interact with visitors or be a part of scripted game experiences. The problem is, SL can't tell the difference between a bot and a live avatar. Fill a sim with a couple dozen bots and the impact on the sim performance will be painfully obvious because the sim is devoting the same resources to those bots that it would a live avatar. That's processing, bandwidth, etcetera that the bot doesn't need. Bots must also be hosted from separate servers, if the sims crash or the servers get disconnected from SL then the bots get disconnected. Often, these bots automatically relog only to end up in infohubs. Many of SL's infohubs are bogged down with crowds of these lost bots every day. Go to any Horizon infohub right now and you will see them. They end up being a laggy, spammy eyesore for actual visitors, driving them away.

@sl-service-account
Copy link
Author

Penny Patton commented at 2016-12-02T05:35:04Z

OH! Another use case: Rezzable NPCs

We should be able to rez and de-rez NPC agents just like we can already do with objects.
Example:

I own a mainland parcel, 4096sq.m., but I've used a holodeck system so I can swap active areas of my home. If SL were to gain NPC agents I'd love to be able to include NPC agents in my holodeck packages, so when you rez a particular scene, you also rez the NPC agents for that scene. I already do this with a mesh robot who floats around a scripted path when certain scenes are rezzed. Replacing the mesh statue with an animated NPC agent would make it a much more believable part of the environment.

Content creators could also use this to rez NPC agents who only appear during scripted events, so you don't need to have every possible NPC for a sim rezzed at all times, only when they're required to interact with visitors or perform scripted events. This would allow people more flexibility in how they use their NPCs, and put less of a burden on the sim by allowing NPCs to be de-rezzed when not needed.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2017-02-04T06:00:34Z, updated at 2017-02-04T09:19:23Z

Among the many things LL will be discussing at their big meet up all next week, this feature will be one.

It has been proposed that NPC's could use existing accounts with a scripted means of logging them on/off.

This would greatly ease the implementation process, but would severely hinder key applications.

With an NPC having only agent qualities and no object qualities, we won't be able to use them as attachable pets, nor will we be able to take them into inventory or sell/transfer them to others or create applications that incorporate NPC's into products.

This pretty much forces the remaining applications to be solely land ownership focused.

I don't agree with this approach. Taking the easy road here will only produce yet another lackluster feature that could have had an enormous impact on all manner of commerce in Secondlife if it was just taken seriously.

Yes, it would be a ton of work implementing NPC's that can use the existing avatar skeleton, existing rigged attachments, existing animations, existing AO's, use feature specific functions for control and can also perform as an object that can be rezzed, taken, worn, transferred or sold, but I think Secondlife is still worth the effort as users certainly still have interest in this platform.

This isn't something we should only push off to Sansar in hopes that it will give that platform some interest.

I told a developer to mirror these comments over to the MAINT jira for review when they bring this feature up for discussion.

If you have any opinions regarding/countering the use of existing accounts as NPC's, please let them be known.

@sl-service-account
Copy link
Author

Kadah Coba commented at 2017-03-17T00:08:32Z

I concur. If a resident account is required to make a single NPC, then the feature adds nothing that isn't already being done with bots, only moving where the bot is hosted. All that would do is make it slightly easier to do what some already do, but likely with far less features since I could safely assume that the LL hosted bots wouldn't support RLV or any of the custom exiting bot scripts (external script that run on the bot clients).

I don't think it would be all that much work to add object based agents. To the viewer they would be pretty much like any other agent but with extra flags and data to the effect that they are NPCs. Simulator side is another mater I cannot speak for, but I have the feeling it wouldn't be to massive even if they're would be limitations like unable to cross regions (though the idea of having rideable mounts like horses that actually look good and animate well without horrid sim performance would be nice to see and also an interesting new market).

It would be nice to be able to make experiences (or something like them since EXP is rather limited) filled with NCPs that look good and don't have to use most of the sim's script time and massive storms of prim update packets for primitive animations (pun intended).

@sl-service-account
Copy link
Author

Kadah Coba commented at 2017-03-21T22:46:39Z

This likely needs to be set to "Info Provided" but I think that will also block off access again.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2017-03-22T02:55:50Z

It would block access, but theres no need to set it to Info Provided since there is already a MAINT order for this request.

Animated mesh is now discussed at that Content Creator user group meeting.

@sl-service-account
Copy link
Author

Kadah Coba commented at 2017-03-24T23:33:59Z

Thanks for the update. I haven't been able to attend any user group meetings in years due to work hours conflict.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2017-05-12T00:01:32Z

Vir Linden announced that work has begun on animated mesh in the Content Creator UG today. Here is a video of the live stream:

https://www.youtube.com/watch?v=IStlohQHg7M

@sl-service-account
Copy link
Author

Extrude Ragu commented at 2017-06-02T08:38:14Z, updated at 2017-06-02T12:39:28Z

Hello,
I wanted to add to the suggestion:

If we are going to add 'Object-Agents' or 'Created Agents' , could you please let agents Sit on the attachment points of the created agent? (IE, RHAND, LHAND etc). This way we can bring some more unique content to SL that might not be obvious to SL Devs. Think for example of animated theme park rides. One could repurpose a bunch of the agent's bones for a Merry go around, or if you're really pushing it, one could go so far as to make a rideable roller coaster using bone animation, where the agent sits on an attachment point to be taken around. Which couldn't be achieved with any decent quality with the current tools available.

I also don't believe that the animation commands are necessary. Just use the existing animations for avatars, and auto-grant permissions requests from the owner. It also means that scripts are more interchangeable.

Please also consider making the tags above 'created avatars' optional or invisible, in case we would like to use them as non NPC's such as swaying trees and other things

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2017-06-02T20:08:33Z

@extrude Ragu

It appears animated mesh will be object based, not agent based so a new animation function will be necessary.

I don't think LL is going to invest in sitting on attach points any time soon.

I've been thinking of filing a request for a function that can temporarily rig a sitter to a bone ID with local position and rotation offset.

This will allow fluid movement feedback with animations played by the animated mesh the sitter is sat upon without the need to make custom rider animations that fake the movement which would be hard to keep synchronized.

You should attend the Content Creator UG to ask questions and submit ideas.

http://wiki.secondlife.com/wiki/Content_Creation_User_Group

@sl-service-account
Copy link
Author

Kadah Coba commented at 2017-06-02T23:48:25Z

Being able to set sit targets that are relative to bone positions on an animated object would be useful. There would be the caveat the an avatars actual server side position will not correlate to the apparent visual position since animations are client side.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2017-06-21T05:28:28Z

Filed a request for the function, llSetLinkSitRigging() at https://jira.secondlife.com/browse/BUG-100864

Feel free to comment there with any ideas.

@sl-service-account
Copy link
Author

Vir Linden commented at 2017-07-06T14:47:46Z

Our apologies, it appears this jira has been a victim of a spammer. We've cleaned up the offending comments, sorry for the mess!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant