[BUG-229144] llGetAspectRatio() for huds

[sl-service-account]

How would you like the feature to work?

float llGetAspectRatio();

This would return the aspect ratio of the wearing agent's screen. For privacy purposes(i.e. preventing "fingerprinting"), this should only work on the agent wearing the object, and if the object is attached to the hud. The data would be pulled from the existing AgentHeightWidth packet, and would be the result of AgentHeightWidth.HeightWidthBlock.Width / AgentHeightWidth.HeightWidthBlock.Height.

This is currently possible, but in a tedious way. A resident must attach a object to one of the corners of the HUD with the following script:

default
{
    touch_start(integer total_number)
    {
        vector scale = llGetScale();
        vector off_point = llGetLocalPos();
        vector face_pos = llDetectedTouchST(0);
        vector screen_pos = llDetectedTouchPos(0);

        float screen_width = ((face_pos.x-.5)*scale.y-off_point.y+screen_pos.y)*2;

        llOwnerSay((string)screen_width);
    }
}

Example output:

Assuming the following block has been sent to the server:
AgentHeightWidth
    AgentData
        AgentID 796b1537-70d8-497d-934e-0abcc2a60050
        SessionID 00000000-0000-0000-0000-000000000000
    HeightWidthBlock
        GenCounter 0
        Height 1061
        Width 1920

And object's root is attached to ATTACH_HUD_*
Then the following should be true:
llGetAspectRatio() == 1.8096135721017907 //(1920 / 1061)

If not attached to HUD, or the simulator has no AgentWidthHeight cached, then return 0 or FALSE. This will be safe as no screen will can have a ratio of zero.

Why is this feature important to you? How would it benefit the community?

This would be great for dealing with multiple screen sizes, by allowing HUDs to dynamically resize and position elements so they fit the screen properly.

We currently know that the HUD will be exactly 1 meter tall, so this function will tell us how wide the screen is in meters.

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-229144 | | Summary | llGetAspectRatio() for huds | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Chaser Zaks (chaser.zaks) | | Created at | 2020-07-25T21:39:39Z | | Updated at | 2023-08-21T18:40:57Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2020-07-25T17:29:02.209-0500', 'How would you like the feature to work?': "{code}\r\nfloat llGetAspectRatio();\r\n{code}\r\nThis would return the aspect ratio of the wearing agent's screen. For security purposes, this should only work on the agent wearing the object, and if the object is attached to the hud.\r\nThe data would be pulled from the existing {{AgentHeightWidth}} packet, and would be the result of {{AgentHeightWidth.HeightWidthBlock.Width / AgentHeightWidth.HeightWidthBlock.Height}}.\r\n\r\nThis is currently possible, but in a tedious way. A resident must attach a object to one of the corners of the HUD with the following script:\r\n{code}\r\ndefault\r\n{\r\n touch_start(integer total_number)\r\n {\r\n vector scale = llGetScale();\r\n vector off_point = llGetLocalPos();\r\n vector face_pos = llDetectedTouchST(0);\r\n vector screen_pos = llDetectedTouchPos(0);\r\n \r\n float screen_width = ((face_pos.x-.5)*scale.y-off_point.y+screen_pos.y)*2;\r\n \r\n llOwnerSay((string)screen_width);\r\n }\r\n}\r\n{code}\r\n\r\nExample output:\r\n{code}\r\nAssuming the following block has been sent to the server:\r\nAgentHeightWidth\r\n AgentData\r\n AgentID 796b1537-70d8-497d-934e-0abcc2a60050\r\n SessionID 00000000-0000-0000-0000-000000000000\r\n HeightWidthBlock\r\n GenCounter 0\r\n Height 1061\r\n Width 1920\r\n\r\nAnd object's root is attached to ATTACH_HUD_*\r\nThen the following should be true:\r\nllGetAspectRatio() == 1.8096135721017907 //(1920 / 1061)\r\n\r\nIf not attached to HUD, or the simulator has no AgentWidthHeight cached, then return 0 or FALSE. This will be safe as no screen will can have a ratio of zero.\r\n{code}", 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': 'This would be great for dealing with multiple screen sizes, by allowing HUDs to dynamically resize and position elements so they fit the screen properly.\r\n\r\nWe currently know that the HUD will be exactly 1 meter tall, so this function will tell us how wide the screen is in meters.', } ```

[sl-service-account]

Lucia Nightfire commented at 2020-07-25T22:29:02Z

This is a "good faith" viewer data to LSL function means, just like hover height read by OBJECT_HOVER_HEIGHT, just like camera position/rotation read by llGetCamerPos() & llGetCameraRot().

I tried getting access to another "good faith" data return, Use Shared Environment read by llAgentInSharedEnvironment(), but no developer could wrap their head around it.

Good luck.

[sl-service-account]

Kyle Linden commented at 2020-08-05T17:46:47Z

Hello, and thank you for your feature request.

Incoming suggestions are reviewed in the order they are received by a team of Lindens with diverse areas of expertise. We consider a number of factors: Is this change possible? Will it increase lag? Will it break existing content? Is it likely that the number of residents using this feature will justify the time to develop it? This wiki page further describes the reasoning we use: http://wiki.secondlife.com/wiki/Feature_Requests

This particular suggestion, unfortunately, cannot be tackled at this time. However, we regularly review previously deferred suggestions when circumstances change or resources become available.

We are grateful for the time you took to submit this feature request. We hope that you are not discouraged from submitting others in the future. Many excellent ideas to improve Second Life come from you, our residents. We can’t do it alone.

Thank you for your continued commitment to Second Life.

[sl-service-account]

Signal Linden commented at 2023-08-21T18:40:58Z

I was chatting with some server team members about this earlier, and we think it would be rather dang useful and... not too terribly difficult to add this. Can't promise any date yet. :)