Add obfuscation option for the TextInput component and use it to implement a streamer mode option to hide your IP addresses

[bagggage]

Adds the ability to hide the input text. Usage via the .obfuscate() and .deobfuscate() methods. To ensure uniform and consistent use of the same obfuscation character across other parts of the code, the global members TextInput.obfuscationChar and TextInput.obfuscatedStringBuffer are public.

This will be very useful for #1929. The implementation proposed in #1933 is broken, does not support Utf8, and constantly uses memory allocation to create a string of filler characters, which is precisely why I am proposing this implementation.

fixes #1929

[bagggage]

Visible:

Obfuscated:

[BoySanic]

Idk if it's just me but it looks a bit... Squished horizontally.

[MaxHobbyDev]

IMO the asterisk should be the default. However, it may conflict with the other markdown styling stuff?

[bagggage]

Idk if it's just me but it looks a bit... Squished horizontally.

That's how the • character looks like with the font used in Cubyz. Unfortunately we cannot use * character, because it's reserved as special symbol.

[BoySanic]

Perhaps we should consider fixing the font at some point, but if that's all it is, that could be a separate issue I'd guess

[MaxHobbyDev]

That's how the • character looks like with the font used in Cubyz. Unfortunately we cannot use * character, because it's reserved as special symbol.

TIL about asterisk variants... there is a thing called a heavy asterisk: ✱ (https://en.wikipedia.org/wiki/Asterisk#Encodings)

(Doesn't look any good in-game)

[bagggage]

TIL about asterisk variants...

This one ∗ is better:

And this low asterisk ⁎:

[IntegratedQuantum]

Every time I look at it to review, I come to the conclusion that it is doing too much.

Please explain why you decided against just obfuscating it during render. If "avoiding allocations" is the only reason (and I think all the other problems mentioned are easily fixable), then I'd say it isn't a particularly good one, since the stackAllocator is cheap, and if you want to optimize text rendering, then a rare case in a rare component is a pretty bad starting point. On the other hand the 80 extra lines you need here are possibly more error prone and introduce edge cases (→what happens if the user adds more than 512 characters).

[bagggage]

I wasn't aiming to optimize text rendering; all I wanted was to get the obfuscation working and ensure it handled UTF-8 correctly. But yes, I suppose at the time it seemed to me that performing obfuscation every single frame wouldn't be a good idea. Regarding memory, I agree with the buffer size issue, but in practice, the only purpose of obfuscation is to hide an IP address - and perhaps a password or username in the future, these will never exceed 512 bytes in length. I'm not saying the problem shouldn't be fixed, I'm just pointing out that this solution isn't that bad.

So, I don't see any problem to implement obfuscation in render.

[Argmaster]

these will never exceed 512 bytes in length.

Said the programmer 2 seconds before the text reached 513 bytes in length.

Trust me, @codemob-dev will paste whole Lord of the rings subtitles in Chinese into it just to mess with you.

[codemob-dev]

Trust me, @codemob-dev will paste whole Lord of the rings subtitles in Chinese into it just to mess with you.

Can confirm.

[IntegratedQuantum]

So, I don't see any problem to implement obfuscation in render.

Then please make it so.

[bagggage]

Then please make it so.

Done. And the stack allocator is used to allocate a temporary string with obfuscated chars.

I also added a Hide IP checkbox to the Multiplayer window, so you can test it.

[IntegratedQuantum]

I would suggest to move this to utils, it certainly doesn't belong buried deeply in a random gui component.

Also allocators should (except self) generally be the first parameter.

[bagggage]

I thought about this too, I just couldn't find a suitable place in the utils

[IntegratedQuantum]

Just put it at the end of the file then.