[BUG-233430] New function: llToHex()

[sl-service-account]

How would you like the feature to work?

Function signature:

    string {*}llToHex{*}(integer {*}number{*}, integer {*}uppercase{*});

Returns the number but in hexadecimal, *without* leading "0x".

Parameters:

• uppercase – if TRUE, return hexadecimal using uppercase letters. If FALSE, use lowercase letters.

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

  Many compression/encoding algorithms users have created in the Community Forums require encoding to hexadecimal. And because there is currently no function to do that, all of them have to implement a custom, home-brew encoder that consumes valuable codespace.

  By implementing this function, scripts can run quicker with less memory usage and less needs for garbage collection, ultimately resulting in lower script load on a sim, and thus help reduce lag.

  (On the flip side, converting from hexadecimal to decimal is easily done by prepending "0x" and typecasting to string. So, there's this asymmetry in numeric translation facilities, and that's in my opinion is quite ... weird.)

   

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-233430 | | Summary | New function: llToHex() | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Created at | 2023-02-19T18:38:13Z | | Updated at | 2023-03-01T19:04:34Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2023-02-19T23:03:32.093-0600', 'How would you like the feature to work?': 'Function signature:\r\n\r\n string llToHex(integer number, integer uppercase);\r\n\r\nReturns the number but in hexadecimal, **without** leading "0x".\r\n\r\nParameters:\r\n - `uppercase`: if TRUE, return hexadecimal using uppercase letters. If FALSE, use lowercase letters.', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': 'Many compression/encoding algorithms users have created in the Community Forums require encoding to hexadecimal. And because there is currently no function to do that, all of them have to implement a custom, home-brew encoder that consumes valuable codespace.\r\n\r\nOn the flip side, converting from hexadecimal to decimal is easily done by prepending "0x" and typecasting to string. So, there\'s this asymmetry in numeric translation facilities.\r\n\r\nBy implementing this function, scripts can run quicker with less memory usage and less needs for garbage collection, ultimately resulting in lower script load on a sim, and thus help reduce lag.', } ```

[sl-service-account]

JIRAUSER341305 commented at 2023-02-20T05:03:32Z

I'd like this.  It's not particularly hard to do yourself…  So is it worth it?  Not sure.

But, I'd like it with one change; string llToBase(integer number, string alphabet)

• binary: llToBase(number, "01");
• octal: llToBase(number, "01234567");
• hex (upper): llToBase(number, "0123456789ABCDEF");
• hex (lower): llToBase(number, "0123456789abcdef");
• alpha-token: llToBase(number, "abcdefghijklmnopqrstuvwxyz");

• base-64: llToBase(number, …you get the idea… ⁽¹⁾

  And of course, a matching llFromBase function to go the other way — you'd just take care of case yourself where necessary, eg. llFromBase(llToLower(hexString), "0123456789abcdef").

  ⁽¹⁾ There are issues with using this for base64 (bytewise vs numeric, lack of base64 padding)…  But also advantages, too (url-safe vs. url-unsafe alphabets, lack of base64 padding).

[sl-service-account]

Spidey Linden commented at 2023-03-01T19:04:31Z

Issue accepted. We have no estimate when it may be implemented. Please see future release notes for this fix.