secondlife / jira-archive

2 stars 0 forks source link

[BUG-231634] [Feature Request] llGetObjectDetails() constant OBJECT_BODY_SHAPE_HOVER_HEIGHT #9076

Open sl-service-account opened 2 years ago

sl-service-account commented 2 years ago

Information

Attn: Rider or Vir

If you have any spare time please consider prioritizing the addition of the following constant to llGetObjectDetails():

OBJECT_BODY_SHAPE_HOVER_HEIGHT which points to ID # 11001, the "hover" parameter in a user's body shape data.

This should be the easiest thing to add since we already have OBJECT_BODY_SHAPE_TYPE which points to ID # 80, the "male" parameter.

The alternative name OBJECT_BODY_SHAPE_HOVER would also be acceptable.

I would be eternally grateful if this could be offered Soon™. ;)

Thanks in advance.

Other Information

We currently have no way to determine what amount of body hover height is in use and this value easily hits the 1.1 to 2.45 bounds reported by llGetAgentSize() which also isn't seen by ray casts or querying mass.

We have access to the UI slider value with OBJECT_HOVER_HEIGHT, which can add +/- 2 meters on top of the effects of the body hover slider value which is an additional +/- 2 meters, but currently cannot be read.

Lack of access is negatively affecting my products, particularly worn Animesh companions.

I was not aware that people prefer this hover height value over the UI hover height slider until I was made aware of it by several users.

Apparently I was not aware or completely forgot that, unlike the UI hover slider, the effects of the body hover slider are lost when a user sits, making it more ideal than having to adjust the UI hover slider every time one sits.

I was unaware because I never used it before and only used the UI hover height slider, but now I'm reconsidering.

Original Jira Fields | Field | Value | | ------------- | ------------- | | Issue | BUG-231634 | | Summary | [Feature Request] llGetObjectDetails() constant OBJECT_BODY_SHAPE_HOVER_HEIGHT | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Lucia Nightfire (lucia.nightfire) | | Created at | 2022-01-05T16:17:51Z | | Updated at | 2022-04-12T21:59:45Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2022-01-05T13:01:55.810-0600', 'How would you like the feature to work?': 'Attn: Rider or Vir\r\n\r\nIf you have any spare time please consider prioritizing the addition of the following constant to llGetObjectDetails():\r\n\r\nOBJECT_BODY_SHAPE_HOVER_HEIGHT which points to ID # 11001, the "hover" parameter in a user\'s body shape data.\r\n\r\nThis should be the easiest thing to add since we already have OBJECT_BODY_SHAPE_TYPE which points to ID # 80, the "male" parameter.\r\n\r\nI would be eternally grateful if this could be offered Soon™. ;)\r\n\r\nThanks in advance.\r\n\r\nOther Information\r\n\r\nWe currently have no way to determine what amount of body hover height is in use and this value easily hits the 1.1 to 2.45 bounds reported by llGetAgentSize() which also isn\'t seen by raycasts or querying mass.\r\n\r\nWe have access to the UI slider value with OBJECT_HOVER_HEIGHT, which can add +/- 2 meters on top of the effects of the body hover slider value which is an additional +/- 2 meters, but currently cannot be read.\r\n\r\nLack of access is negatively affecting my products, particularly worn Animesh companions.\r\n\r\nI was not aware that people prefer this hover height value over the UI hover height slider until I was made aware of it by several users.\r\n\r\nApparently I was not aware or completely forgot that, unlike the UI hover slider, the effects of the body hover slider are lost when a user sits, making it more ideal than having to adjust the UI hover slider every time one sits.\r\n\r\nI was unaware because I never used it before and only used the UI hover height slider, but now I\'m reconsidering.', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': '?', } ```
sl-service-account commented 2 years ago

Vir Linden commented at 2022-01-05T19:01:56Z

Is OBJECT_HOVER_HEIGHT already a supported param, for the +/- 2m value? Or are you getting that some other way?

We might need to tweak the name for the shape param to reduce confusion of an already confusing situation, but seems like a good idea.

sl-service-account commented 2 years ago

Lucia Nightfire commented at 2022-01-05T20:48:08Z, updated at 2022-01-05T20:55:45Z

@Vir

OBJECT_HOVER_HEIGHT reads the viewer UI hover height value, not the body Hover Height slider value.

The viewer controlled value does not modify the body shape Hover Height value, It adds +/- 2m on top of what the body Hover Height slider value outputs.

This means an avatar can have an actual +/- 4m hover height range, but only half of that can be seen by scripts.

Here is a video of me setting body shape hover to max for +2 meters, then changing the viewer slider for another +2 meters:

https://gyazo.com/c26c101db5692b92bd640346eeb50079

sl-service-account commented 2 years ago

Kyle Linden commented at 2022-01-13T17:37:51Z

Thank you for this suggestion. We may implement some version of this at a future date.

sl-service-account commented 2 years ago

Lucia Nightfire commented at 2022-03-16T04:02:07Z, updated at 2022-04-12T21:59:46Z

This has now extended to a request for access to all sliders that affect user height.

Here are proposed constants and target skeleton ids:

OBJECT_BODY_SHAPE_HEIGHT(33), OBJECT_BODY_SHAPE_TORSO_LENGTH(38), OBJECT_BODY_SHAPE_HEEL_HEIGHT(198), OBJECT_BODY_SHAPE_PLATFORM_HEIGHT(503), OBJECT_BODY_SHAPE_HEAD_SIZE(682), OBJECT_BODY_SHAPE_LEG_LENGTH(692), OBJECT_BODY_SHAPE_NECK_LENGTH(756), OBJECT_BODY_SHAPE_HIP_LENGTH(842), OBJECT_BODY_SHAPE_HOVER_HEIGHT(11001)

Reported output is the normalized 8 bit internal value for each, not the decimal internal value.

Use cases entail: