Bluewing Unicode in testing, monies visible

Hey folks,
Plenty of stuff to bring up today.

DarkEdif SDK now version 6, and more documented

DarkEdif SDK is now version 6, and it has several fancy settings that are a one-line change to switch the SDK's platform compatibility, whether it favours speed or size, etc.

It also has static analysis support, which is good news for anyone using vardiac functions (functions allowing as many parameters as you want, akin to Excel SUM() ) or devs wanting to check they're not leaking memory, or using the Unicode text where ANSI text is expected, etc. It will make porting existing extensions without bugs 10x easier, if you're able to use analysis.

All of the features have now been documented in the MMF2Exts wiki. One line in an INI file will enable and disable extension SDK features, and you won't even have to reload your project. Some features are even auto-detected on build, like use of FusionDebugger struct that will automatically update Fusion's debugger with variables from your extension.

Also there's fixes to the SDK float expressions, in unlikely scenarios. Objects that used float expressions were updated to fix that problem.

Other updates

DebugObject b14 was released, now reports the crashing extension name.

Bluewing Client b92 ANSI was released, improving close times and removing some bugs related to closing the program, and peer dis/connections.

Bluewing Server b24 ANSI was released, fixing a bug that would prevent the server from creating a channel with no master. That feature was added in build 22.

Bluewing Unicode

Bluewing Unicode now compiles and works great. Thanks to static analysis, there's no mixups of ANSI and Unicode.

However, there is a design conundrum. I've put in a portable UTF-8 validating and composing library.
(Unicode composing aka normalization: é can be stored as two chars, e + ´ (joining acute), or as a one-char é. Composing picks the shortest size via NFC, but both are valid Unicode.)

Bearing in mind any popular app will gain hackers and cheats – one look at Among Us will tell you that they will exploit Unicode name problems – then text input design issues show up, such as:

• Should emojis be allowed in channel names?
• How about Arabic channels in a game where moderator rules specify only English should be allowed?
• What if a corrupt name is specified, e.g. one of those 4-byte characters only has 2 bytes?
• What if user is using an decomposed name?
• They're using zero-width whitespace characters? Lookalike characters like ffi instead of regular ffi?
• What if user is using block characters █▓? Will definitely make writing /kick Player█▓ a bit hard.

Then there's the issue of Unicode text varying in byte size. In ANSI, 1 byte = 1 character. In UTF-8, 1-4 bytes = 1 character.

I've opted to use byte limits for channel/client names, so 255 bytes in end result name, because it lessens the chance of bad Unicode.
Users can still attempt to join a channel with a larger name, but server must rewrite it to <255 bytes before it's approved; that allows a user to specify all their channel setup in their join request, and user to respond appropriately, e.g.:
Client to Server = Request to join My Game Is Best|BlueMap|TeamDeathmatch|8|FF_ON...
Server = (stores details about game setup to send to new channel joiners)
Server to Client = Join success for Channel My Game Is Best.

(That's this action, by the way)

Now it's just about working out how to limit the names, while keeping an advanced Fusion developer in control, and not being too confusing for a intermediate user. We don't want a confused mod unable to boot mwahaffi due to /kick mwahaffi not working. Some fonts don't make as much distinction between characters as Patreon does.

Although, it should be mentioned that kicking/banning by ID should always be preferred over name. If you design so both can be used, what if a user names themselves 3 and their ID is 5? What does /kick 3 do in that scenario? Make sure you design so it's explicit.

Design for Server

On server side, all client names and channel names, both requested by client and any given by server program, will be validated and normalized with NFC.

Anything requested with invalid or decomposed Unicode will be rejected. There'll be new A/C/E to allow advanced name limiting, e.g. no emojis and the like.

As mentioned before, bytes will be used where Lacewing protocol limits names. So anything that's too long after shortening will be rejected.

Design for Client

On the client, Unicode will be validated/composed when outgoing; incoming messages will expect to use valid Unicode.

Invalid Unicode will only result in poorly displayed text (using replacement characters) , so it's not the end of the world if chat messages are distorted.
If you're concerned about chat messages, a malicious user could just put in a 1mb text message... have you checked for that? If you do wish to check text, it's recommended you do so on the server side.

Design for both

However, due to some users having custom text displays, I've added three ways of interacting with text:

One expression for composed characters, one for visible characters (graphemes), and one for bytes after composing, in case someone is using binary messages.

Closing note – see my monies 💸👀

Bluewing Unicode will be out soon, within this month. Development on Bluewing Android will be starting straight after.

I've opted to open my Patreon display to show income amounts. Feel free to compare to minimum wage (😛). I suppose I spend 20 hours a week on Patreon stuff, at least.

Marketing is just as important as product quality, arguably more important. So thanks a bunch for your support so far folks, and do invite others to become patrons during this trying season.

Cheers,
~Phi