new SLURLS !?!

[Quistess Alpha]

So I just looked at the 'Viewer URI Name space' page and noticed a lot of things that definitely weren't there last time I looked.

Specifically the /keybinding domain; it's not 100% clear how those are supposed to work, how do you describe the key that is to be bound to the action? (if that's what they do?) which print the key that the user's viewer expects to perform the given function.

Edited September 5, 2023 by Quistess Alpha

[Wulfie Reanimator]

Those were added last week by @Atlas Linden, though I did not find references to those in the viewer source from a quick search.

Edited September 5, 2023 by Wulfie Reanimator

[Qie Niangao]

Seems like @Fenix Eldritch's jira and @Nadnerb Tebaldi version which shows up in the Release Notes for the recently updated "6.6.15.581557 - Maintenance-V" viewer (that I have yet to download).

[Quistess Alpha]

4 hours ago, Qie Niangao said:

@Fenix Eldritch's jira

Ahh ok, it's not clear on the wiki page, but according to that they're supposed to resolve to the key that is bound to that function for the user's viewer. That's a pretty nice and sensible design idea!

[Fenix Eldritch]

At least, that was the intent when I filed the feature request... However looking at the listed URIs, a few of them seem odd if they are indeed following my suggestion. Like, what would "stop_moving" return? Some generic "release the held key" label?

[Quistess Alpha]

1 minute ago, Fenix Eldritch said:

what would "stop_moving" return

I'd have to have the viewer remap window in front to confirm or deny, but perhaps that function prematurely stops the "walk_to" action? (By default I think walk_to is unbound, I usually bind it to 'q', rarely useful, unless you're used to runescape style controls; could be useful in a setup where a script forces an overhead camera view.)

[Fenix Eldritch]

Ah that could be. My mind was focused on the basic keyboard inputs and forgot about the alternate auto walk to functionality and the like.

[Qie Niangao]

I finally downloaded that Maintenance V viewer and tried it out. The output I see includes the corresponding line from the keybinding table, so it names the "Action" and any Primary, Alternate 1, and Alternate 2 key to which it's bound. So this dippy little script:

default
{
    state_entry()
    {
        string controlToken = "stop_moving";
        llOwnerSay(controlToken+" is bound to key "
            +"secondlife:///app/keybinding/"+controlToken+"?mode=0"
            );
    }
}

generates this:

and the clickable text pops open the Preferences window with the Controls tab, apparently scrolled to the position it had when last open. I'm not sure how this feature was intended to work, so I'm not sure whether I'm doing something wrong, or if this is what was expected.

[Bleuhazenfurfle]

Think I'd prefer it if they dropped the "Stop Moving:" prefix…  you can add that yourself if you want it (as you did there), but you can't readily get rid of it if you don't. That could be particularly annoying if you want to show the controls for an aircraft or something, with more appropriate terms like roll instead of turn, or strafe instead of slide, etc.

I guess that could be there to match with the official key binding name…  but still.

Edited September 6, 2023 by Bleuhazenfurfle

[Fenix Eldritch]

Ah the spacebar... or as I like to call it the "avatar handbrake". How silly of me to forget it. That does seem to be working more or less as what I would expect.

Save for the extra label/prefix for the target control - I'm in agreement with Bleuhazenfurfle, it's a bit too verbose. I wouldn't mind an extra suffix to these URIs to add or suppress it.

[Love Zhaoying]

Can someone help me understand a use-case for the new methods?

My initial guess was:  If I want to create an "external" web app, or use web calls from an LSL script, or create an "internal" Web app (which I finally did yay) - then this gives a way to fetch the data without LSL calls...?

 

[Fenix Eldritch]

Dynamically referencing generic controls, no matter what the end user has configured locally on their viewer. This becomes very useful now that the viewer allows us to remap so many of the keybindings.

An in-world product/tutorial can now accurately tell the user what key to use instead of assuming the classic "Press W to move forward" kind of deal.

Edited September 6, 2023 by Fenix Eldritch

[Love Zhaoying]

2 minutes ago, Fenix Eldritch said:

An in-world product/tutorial can now accurately tell the user what key to use instead of assuming the classic "Press W to move forward" kind of deal.

Now..if only LL would add a "modern embedded tutorial" to the viewer..!!

You know, the kind with bubbles and pointers to "try this next", etc.

[Qie Niangao]

1 hour ago, Love Zhaoying said:

My initial guess was:  If I want to create an "external" web app, or use web calls from an LSL script, or create an "internal" Web app (which I finally did yay) - then this gives a way to fetch the data without LSL calls...?

Just to make sure it's clear (and to repeat what Fenix already said), this is all local to the viewer, the only place these URIs can be decoded. These internal and external web apps, then, cannot generate html incorporating these URIs for display in a browser window, for example, but can incorporate them in text delivered to an LSL script that presents it in the viewer's chat window.

I'm not sure whether the URIs on that page are decoded anywhere other than the chat window by any viewers. I could imagine it being useful to display the decoded text in dialog box text[*] for example, or even hovertext, but have no idea whether that's even remotely plausible. It would surely be useful in notecards, or MoaP even, but those seem really difficult (at least to somebody with no knowledge of the viewer internals).

[* ETA: It does work in dialog box text. I thought I was testing it before, but I was in the wrong window, using a viewer other than the Maintenance V viewer. So maybe it works elsewhere, too.]

Edited September 6, 2023 by Qie Niangao

[Love Zhaoying]

17 minutes ago, Qie Niangao said:

Just to make sure it's clear (and to repeat what Fenix already said), this is all local to the viewer, the only place these URIs can be decoded. These internal and external web apps, then, cannot generate html incorporating these URIs for display in a browser window, for example, but can incorporate them in text delivered to an LSL script that presents it in the viewer's chat window.

I'm not sure whether the URIs on that page are decoded anywhere other than the chat window by any viewers. I could imagine it being useful to display the decoded text in dialog box text for example, or even hovertext, but have no idea whether that's even remotely plausible. It would surely be useful in notecards, or MoaP even, but those seem really difficult (at least to somebody with no knowledge of the viewer internals).

Internally launched page (launched from LSL script) and/or MOAP is what I meant. Darn!

[Fenix Eldritch]

49 minutes ago, Qie Niangao said:

I could imagine it being useful to display the decoded text in dialog box text[*] for example, or even hovertext, but have no idea whether that's even remotely plausible. It would surely be useful in notecards, or MoaP even, but those seem really difficult (at least to somebody with no knowledge of the viewer internals).

Slight tangent, but that reminds me of a feature I'd been thinking of proposing. It's basically a LSL function that resolves a given UIR into a regular string so that it could be put into other elements that don't normally resolve UIRs, like hovertex for example. This could also be beneficial since a resolved URI still counts as the full url text for the purposes of string length. So getting just the resolved final text could be helpful in dense readout messages where the user doesn't care about clicking on the resulting URI text. Thoughts?

Edit: I'm not sure it it's even feasible, given the local nature of the URI. I suppose the local result would need to transmitted back to the server to be serialized into a regular string?

Edited September 6, 2023 by Fenix Eldritch

[Quistess Alpha]

1 hour ago, Qie Niangao said:

These internal and external web apps, then, cannot generate html incorporating these URIs for display in a browser window,

The in-viewer web browser can resolve SLURL links (anchors) in HTML, but I'm not sure if it can do the pretty formatting.

for example:

<a href="secondlife:///app/agent/8645873d-1306-4f22-a60c-4f2bc3bb9ca2/about"> Tessa's profile </a>

creates a clickable link to my profile if viewed as (X)HTML in the in-viewer web browser.

It would be really useful if app/chat links weren't blocked for some generic 'security reason'. but that's off-topic. . .

Edited September 6, 2023 by Quistess Alpha

[Wulfie Reanimator]

2 hours ago, Qie Niangao said:

[* ETA: It does work in dialog box text. I thought I was testing it before, but I was in the wrong window, using a viewer other than the Maintenance V viewer. So maybe it works elsewhere, too.]

All of these viewer URIs (old and new) should work everywhere where where text can exist, so local chat, group chat, IMs, profiles (avatar and group), dialog popups, etc.

Edited September 6, 2023 by Wulfie Reanimator

[Qie Niangao]

1 hour ago, Quistess Alpha said:

The in-viewer web browser can resolve SLURL links (anchors) in HTML, but I'm not sure if it can do the pretty formatting.

for example:

<a href="secondlife:///app/agent/8645873d-1306-4f22-a60c-4f2bc3bb9ca2/about"> Tessa's profile </a>

creates a clickable link to my profile if viewed as (X)HTML in the in-viewer web browser.

That seems very encouraging for MoaP then too but I'm stuck figuring out quite what to do with it. The following does something relevant:

default
{
    state_entry()
    {
        llSetAlpha(1.0, 1);
        llClearPrimMedia(1);
        string html = "data:text/html,<!DOCTYPE html><html><head><meta charset=\"utf-8\"><body>"
            +"<a href=\"secondlife:///app/keybinding/stop_moving?mode=0\"> foo</a>"
            +"</body></html>";
        llSetPrimMediaParams(1,
            [ PRIM_MEDIA_AUTO_PLAY, TRUE
            , PRIM_MEDIA_CURRENT_URL, html
            , PRIM_MEDIA_HOME_URL, html
            , PRIM_MEDIA_PERMS_CONTROL, PRIM_MEDIA_PERM_NONE
            ]);
    }
}

in that the MoaP surface contains that "foo" clickable link that does indeed open the viewer's Preferences / Controls tab exactly as expected, but I'm not sure how to even try to get the pretty formatting instead of my "foo" anchor text. I kinda hopelessly tried repeating the same URI that was used in the href element but unquoted, and that enclosed in square brackets, neither of which made sense so it's not surprising they didn't work.

[Quistess Alpha]

56 minutes ago, Qie Niangao said:

The following does something relevant:

I didn't know you could directly embed a (severely space constrained) page directly into the URL like that. Neat!

[Frionil Fang]

26 minutes ago, Quistess Alpha said:

I didn't know you could directly embed a (severely space constrained) page directly into the URL like that. Neat!

It works with more than just text MIME types; you could use the url "data:image/png;base64" to specify a base64-encoded png. Of course, images of any usable size will balloon up fast to be terribly useful in LSL scripts/any prim property field, but something like .svg might be more feasible. Cheeky example:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAQAAAD9CzEMAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAACAZJREFUWMPtl2tQVdcVx/+XV0UUNCiR4Dvq+MB0tCGKSiK0FMZJp2biaIxt02oVUxOjRq3PxqhomokaHauJwWiIL8Qn9wo+wVwFjVp8RUVQR0QRkOoFRJDXrx84nFxedjL52rU+nL332fv/P3vttdZeR/q//EwJ1EtNaPefD5skhxxy9KkJprG2qZRDDh2RVVZFa7bC5PFT4Me6Vy7DQSWV1ACVXMGGDTt27BwkmRSSiWMvSexgHn/GA48qXdAmjZPr/4Yf7Vd5iTrJYT+7uEUJhSRjx04K96kAnnLG1DKKSWI5/VGGXpPlWfC93fOPGeAl7MXKPfZg4zhXeAxAOVc4ZOymVm3YOcJFNlLFV/ijWLVsDt5VKYsN+NukkIONFBKdDLSOQzhLNlc4jp2jlBgj+YxGh+XZNEFId0qBGuLIJpUEdrGfMifAImKdeqe5RCHFQBkJ7DRGK3kVTWiaYOc8AGp4SCopbCSXhnLcqV3MVqdeLnXG/RjNbtI5vSk0p9/lAvepJJbZhBFMMFHE85QcJ8h041zq5AfjuRbFNYb/pSVjZYOvPUVPZOibLOVlBnDJ6f1lSkklmilMYQpZ5vgdPJ5qWAPrqyiEGGI4QAFgw0Ymfowh0CCYyFGqWMFzpJhA5YxGiJ6E0A0v/k0Cd7hOJntoU6nFTvCeRR+wlzzOksR3ZHKDHdxgLMNZRDwr2MYMXiCETXRlBQBn6EoQwoUBDGEqU1lFCXlcJI8MNnOVgCqNqIX3V95nHKSa92hFCCG04112md9pw490oIx/0ZeFhlfVcJLeTGrCDWA7e9jKanS0liB2IjZgPsPJBTZxi7/Sg17MZB5D6MRBmpZRJBmtW5RTwWK88cKDOdgo5jOULkmeLUrvYaeQtpwHimjNSaCCRFazmlhKaU7GMt/wo+m8SCheXKaMG8ziBA5iDAKv5wE7aQwFSvgHHWnHWE41gjtLMhN4n3KnTPUKvbkBlHOMGBLYzTQA8rjISnMHT3Kxk0Y/NtAWP6IoYgl+jOAY1cANI00k4c0q9lNdj3YknmYMwxaGUUge68jnPXSi9gzSj2GjCl9O4eAs7SgEHCzFnUAWct1YXIYPeQzBhy58bqaODgQxA5sRH39EfEM55/iSvuitWoLx3WpSOMEmDgMP8OY1UqgBnmc742lPR95lB6VMZhpxlHGe25SzjZsM4m/UUAOk8h9WYqE/0zjAbbZhyZJXXRxYPyCN/VwDIAELnoSSQg/DWb9nMS/jwhjWc9U41hIG4stcYydV2HgFL94mgCCggkA09sdA66BLwZwwLfkWY1hCAKIlB3gAwE1as5ZRdKY9/YgiihVsYQtb+JCRdOdF1uHHVkQQkIny61+jHXR5gUlwH39slNCZloiWvM1x4gk3fedLBrCRKN7Ehyjms4UINgBBnMOPIMCK9jZMdn6W7ASTIglfchjFHlbQAyE8+TXHKAAgmdcBeEQLY/5GRpCKGx2NHVjR9sb5dGKYk/stpxPtyQCq2c2HuGFBuBNCOL+iHeGEE44r4YTTBQ/czLzbPIGv+6Nz9Sh6YTd7PpxnNv64mEBNqxsRzRJICwbz0IniG9rzERXAPjoZAXaNefjRG/dG0Ba60ZJQlj+DwFXxETxyoshgMEGkMZwYc+wMoUAON5nJq2xmPZ6sYg6DmM7veY6MZxBIPvpqMI/YQQEXsFLNU1bhhwubKK5HUJtNvwWs9OMxXUlkEZ15B55JILlonT8nsBJPKYnsABxsJBRPhhPN1ywwCXqTykMGMYmPcKM3Lfm7EYZWlNh88ZWgo26FUWSwgz3ksZUEioFHbCaaPxFJX7ycdBiRjCcaG1Bl1kvKlUvT8CN0V23VWV/4Vi2hgFS2kcVhtpFGhbH8MXn19IlZC24EsqmknBdougb3Ua6mGe1gHQlgJhc5RRxH+Z5d2DjLXQq5Xk8dQBmpbOIpYKcMeKmW4C8NCQJUpRJ9alSX7hqs9a4PIkmlhCvYOUIMMcQ7VaV1d8UhHgAVWNlHTR1BPxU0JBgqNEw23dTvzDFvzXN9EEkaANU4OOtU+iaRZmoS3xpOXo4/6q7t+rQ+vJeWCx1QioqE0pSsZH2txXJVa821FESQRk2Di7SyntZJNDopi/IU4GyceD3UXaFZClKQhukHnVGIuuic4uQiyVtzlR/MEBZxoV5J3FD20eqJAuWqgh+vnMkq1Bp10jihSaqrl/bpknrIV9n6rekEbyhKa3WnA6F8znc4GuznNO9gyVaEpF7KlrskuWmDrqi/JGmccpVh/gh5KEoFGqdZsjXwahd11h/0hS61YSDjDB1DAMrUQrWVJPVSeq2zrFWKWhsLxylJqfWK7+HK1FLdVnAzYemr32ikqYH6hdPKShVJfVSk9uagvwo1QmUKdILorCw91NYGwBYFKFShClV/86+sp7zN92F6rEz5S68rvt7CFdqvsbqvN5yM0klZuuf0W9RC45WpfFlllVX5OqhIWdRXD1WqnfKUFKZ8bdVqSYrWJ/UI2uq6ZihSOUpSHydD3NI1DZEUoI+Vq+OKMC91H81RlmK0W9Fqo6P6RGHKV5iW1UZBtKY22Hwf5StcrbRMhdqvCRqoXuqlgk7IoUTlKFahjU7CX3uFpslHQ/VA9/S+pDiNappAGq4idZUUoOmKVbrSdVVojVYrW4lq1+RhhytbJ1WkIl3QKEmtVKh+tQQLm5i+SKfVwqk/2Tgpb61Rgf6pjo1WzNYqWbRIN4zonaBkWaT/AhVN9H0fVf20AAAAAElFTkSuQmCC

 

Edited September 6, 2023 by Frionil Fang

[Frionil Fang]

Had to check: the media URL is limited to 1024 bytes (including the data:<mimetype>, header), not great for images, but still might be useful for some esoteric ideas...

[Quistess Alpha]

6 minutes ago, Frionil Fang said:

still might be useful for some esoteric ideas

midi could be fun to play with, postscript would be awesome if it worked (doubtful)