sl-service-account
commented
9 months ago Darksider Alex commented at 2023-10-17T19:25:00Z
This is a very comprehensive way to add a variety of useful new features to LSL. We really should be able to adjust the jump height, gravity, speed, and size of avatars, as is standard for every other game engine. The additional combat features are also helpful, as they add a new level of complexity to the existing LL combat system, which is still in use by hundreds of players. I'm not sure why we can't already adjust gravity settings, given that it would make the creation of sci-fi and fantasy worlds more immersive, as well as jumping puzzle games and other experiences.
How would you like the feature to work?
This LSL function would allow a script to control the last agent to be granted the PERMISSION_AGENT_PROPERTIES permission.
When worn, PERMISSION_AGENT_PROPERTIES would be auto-granted, much like PERMISSION_TRIGGER_ANIMATIONS. This permission should also be revoked and the agent's properties should be reset to the simulator's default behaviors.
Additionally, these behaviors could also be exposed to Estate Owners and Managers either via the management floater or simulator debug as a way to set the 'default agent behavior' of users on a sim or estate.
A mockup of this function is as followed:
llSetAgentProperties(list agentProperties); Where agentProperties can consist of one or more of these properties:
[AGENT_PROPERTY_GRAVITY, float gravity] Where: -gravity is the gravity constant
[AGENT_PROPERTY_WATER_BUOYANCY, float buoyancy] Where: -buoyancy >0.0 would cause the agent to float towards the surface of the water plane.
[AGENT_PROPERTY_JUMP_BEHAVIOR, float start_vel, float vel_decay, vector air_control_strength, vector air_decay_time] Where: -start_vel would be the initial velocity applied to the agent -vel_decay the time in seconds to decay to 0 force. -air_control_strength determines how much direction keys control can adjust movement while in the air, Z is unused. -air_decay_time determines how long in seconds until agent's X/Y air velocity decays to 0
The ability to fine tune jump behavior is a critical behavior and can vastly change the feel of a game. Jump behavior is often one of the most important factors to a level design, especially in platforms.
[AGENT_PROPERTY_WALK_SPEED, float walk_vel, float ramp_time] Where: -walk_vel determines the maximum velocity when walking -ramp_time determines how long, in seconds, it takes for the agent to reach walk_vel
[AGENT_PROPERTY_RUN_SPEED, float run_vel, float ramp_time] Where: -run_vel determines the maximum velocity when running -ramp_time determines how long, in seconds, it takes for the agent to reach run_vel
Currently, regardless of avatar size animations have to be tailored for the fixed 3 m/s walk and 6 m/s run speed. This can result in smaller avatars being forced to have a jogging or even running animation to make sense at 3 m/s, while large avatars either have to have very slow walking animations or throw out agent movement altogether to make their walking and running speeds make sense.
[AGENT_PROPERTY_FLY_SPEED, vector fly_vel, vector ramp_time]
[AGENT_PROPERTY_ALWAYS_UP, integer bool] By setting to FALSE, this allows the agent to freely rotate on all axises, rather than only on the Z axis. This is non-critical and may not be possible within how the agent object behaves. It also raises the question on how to handle these new axises of rotation and may require additional supporting LSL functions.
[AGENT_PROPERTY_MASS, float mass_kg] Where: -mass_kg Sets the mass (in Kilograms) of an agent. Apparent weight would adjust with AGENT_PROPERTY_GRAVITY.
[AGENT_PROPERTY_SIZE, vector agent_size] Where: -agent_size determines the bounding box of the agent Considerations: -Should this be controlled by LSL or should the bounding box be based on the avatar's octree or some other metric? Via LSL would be the most flexible option, though likely would need a minimum value -Where should the scaling be performed? Geometric center or from the bottom?
[AGENT_PROPERTY_COLLISION_SOUND, string collision_uuid, float collision_vol] Where: -collision_uuid would change the collision sound on impact with an object. "" or NULL_KEY would silence collisions, "default" would revert to 'Flesh' material. -collision_vol would change the collision volume
This is essentially a agent-specific version of llCollisionSound(), with additional functionality to revert to normal collision sounds.
[AGENT_PROPERTY_COMBAT_BEHAVIOR, float max_health, float health_regen_delay, float health_regen_rate, string hurt_uuid] Where: -max_health would determine an agent's max health -health_regen_delay would determine how long before an agent's health starts to recover -health_regen_rate would determine how fast an agent's health recovers to max_health -hurt_uuid determines the sound played when the agent takes damage, "" or NULL_KEY would use the old hurt sound behavior
Why is this feature important to you? How would it benefit the community?
Currently, the agent/avatar's behavior is one of the least flexible part of Second Life. This leaves most game systems in SL having to work around these limitations, either by using llSetForce or similar to adjust behaviors such as jump height or movement speed, or by throwing out the avatar movement system entirely in favor of sitting on an object. Neither of these solutions are as responsive as avatar movement and often require large amounts of additional work, such as re-implementing physics entirely or preventing undesired behavior.
How the character controls is a critical part of game design and dramatically changes many aspects of a game. By exposing these behaviors and properties to LSL, it allows for creators to have more predictable and controllable avatar movement that is currently impossible to achieve. It would also improve large, tiny, and non humanoid avatars by giving them a means to move at the avatar/creature's intended comfortable speed, rather than having to match the 3 m/s and 6 m/s speeds we currently have to work around.
Links
Related
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-234557 | | Summary | [LSL] Configurable Agent Behavior: llSetAgentProperties(); | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Created at | 2023-10-17T15:53:42Z | | Updated at | 2023-10-18T18:18:13Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2023-10-17T14:24:59.540-0500', 'How would you like the feature to work?': 'This LSL function would allow a script to control the last agent to be granted the PERMISSION_AGENT_PROPERTIES permission.\r\n\r\nWhen worn, PERMISSION_AGENT_PROPERTIES would be auto-granted, much like PERMISSION_TRIGGER_ANIMATIONS. This permission should also be revoked and the agent\'s properties should be reset to the simulator\'s default behaviors.\r\n\r\nAdditionally, these behaviors could also be exposed to Estate Owners and Managers either via the management floater or simulator debug as a way to set the \'default agent behavior\' of users on a sim or estate.\r\n\r\nA mockup of this function is as followed:\r\n\r\nllSetAgentProperties(list agentProperties);\r\nhere agentProperties can consist of one or more of these properties:\r\n\r\n[AGENT_PROPERTY_GRAVITY, float gravity]\r\nWhere:\r\n-gravity is the gravity constant\r\n\r\n[AGENT_PROPERTY_WATER_BUOYANCY, float buoyancy]\r\nWhere:\r\n-buoyancy >0.0 would cause the agent to float towards the surface of the water plane.\r\n\r\n[AGENT_PROPERTY_JUMP_BEHAVIOR, float start_vel, float vel_decay, vector air_control_strength, vector air_decay_time]\r\nWhere:\r\n-start_vel would be the initial velocity applied to the agent\r\n-vel_decay the time in seconds to decay to 0 force.\r\n-air_control_strength determines how much direction keys control can adjust movement while in the air, Z is unused.\r\n-air_decay_time determines how long in seconds until agent\'s X/Y air velocity decays to 0\r\n\r\nThe ability to fine tune jump behavior is a critical behavior and can vastly change the feel of a game. Jump behavior is often one of the most important factors to a level design, especially in platforms.\r\n\r\n[AGENT_PROPERTY_WALK_SPEED, float walk_vel, float ramp_time]\r\nWhere:\r\n-walk_vel determines the maximum velocity when walking\r\n-ramp_time determines how long, in seconds, it takes for the agent to reach walk_vel\r\n\r\n[AGENT_PROPERTY_RUN_SPEED, float run_vel, float ramp_time]\r\nWhere:\r\n-run_vel determines the maximum velocity when running\r\n-ramp_time determines how long, in seconds, it takes for the agent to reach run_vel\r\n\r\nCurrently, regardless of avatar size animations have to be tailored for the fixed 3 m/s walk and 6 m/s run speed. This can result in smaller avatars being forced to have a jogging or even running animation to make sense at 3 m/s, while large avatars either have to have very slow walking animations or throw out agent movement altogether to make their walking and running speeds make sense.\r\n \r\n[AGENT_PROPERTY_FLY_SPEED, vector fly_vel, vector ramp_time]\r\n\r\n[AGENT_PROPERTY_ALWAYS_UP, integer bool]\r\nBy setting to FALSE, this allows the agent to freely rotate on all axises, rather than only on the Z axis.\r\nThis is non-critical and may not be possible within how the agent object behaves. It also raises the question on how to handle these new axises of rotation and may require additional supporting LSL functions.\r\n\r\n[AGENT_PROPERTY_MASS, float mass_kg]\r\nWhere:\r\n-mass_kg Sets the mass (in Kilograms) of an agent. Apparent weight would adjust with AGENT_PROPERTY_GRAVITY.\r\n\r\n[AGENT_PROPERTY_SIZE, vector agent_size]\r\nWhere:\r\n-agent_size determines the bounding box of the agent\r\nConsiderations:\r\n-Should this be controlled by LSL or should the bounding box be based on the avatar\'s octree or some other metric? Via LSL would be the most flexible option, though likely would need a minimum value\r\n-Where should the scaling be performed? Geometric center or from the bottom?\r\n\r\n[AGENT_PROPERTY_COLLISION_SOUND, string collision_uuid, float collision_vol]\r\nWhere:\r\n-collision_uuid would change the collision sound on impact with an object. "" or NULL_KEY would silence collisions, "default" would revert to \'Flesh\' material.\r\n-collision_vol would change the collision volume\r\n\r\nThis is essentially a agent-specific version of llCollisionSound(), with additional functionality to revert to normal collision sounds.\r\n\r\n[AGENT_PROPERTY_COMBAT_BEHAVIOR, float max_health, float health_regen_delay, float health_regen_rate, string hurt_uuid]\r\nWhere:\r\n-max_health would determine an agent\'s max health\r\n-health_regen_delay would determine how long before an agent\'s health starts to recover\r\n-health_regen_rate would determine how fast an agent\'s health recovers to max_health\r\n-hurt_uuid determines the sound played when the agent takes damage, "" or NULL_KEY would use the old hurt sound behavior', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': "Currently, the agent/avatar's behavior is one of the least flexible part of Second Life. This leaves most game systems in SL having to work around these limitations, either by using llSetForce or similar to adjust behaviors such as jump height or movement speed, or by throwing out the avatar movement system entirely in favor of sitting on an object. Neither of these solutions are as responsive as avatar movement and often require large amounts of additional work, such as re-implementing physics entirely or preventing undesired behavior.\r\n\r\nHow the character controls is a critical part of game design and dramatically changes many aspects of a game. By exposing these behaviors and properties to LSL, it allows for creators to have more predictable and controllable avatar movement that is currently impossible to achieve. It would also improve large, tiny, and non humanoid avatars by giving them a means to move at the avatar/creature's intended comfortable speed, rather than having to match the 3 m/s and 6 m/s speeds we currently have to work around.", } ```