Lacewing Help

This is for Blue Server. Relay Server has the same expression which was removed, here.

S        In Blue Server, this protocol implementation is usable, and will read the Blue Client's implementation protocol.

If requested before it is valid, or from a Relay Client, the expression will return blank "".

If requested when no client is selected, this expression will return "(no client selected)".

The implementation is requested immediately after connection approval message is sent, in the same C++ function.

So it won't be valid during the Connection > On connect request event, but is normally valid during a Client > On name set request event, assuming it's a Blue Client.

Bluewing Server does not prevent old versions of the client from using the server, even when security flaws are known about in old versions. You can implement that yourself if needed, using the below expression with a Client > On name set request event.

Implementation expression format

Typical Blue Client implementation strings are in the format:

"Bluewing Platform Charset … bBuildNum"

Examples:

Bluewing Windows Unicode b97

Bluewing Windows ANSI b97

Bluewing Android b97

Bluewing iOS b97

Bluewing HTML5 b100

Bluewing UWP JS b100

Bluewing Macintosh b103

This does not match with the Bluewing Client's Lacewing version string expression, which includes detail about the liblacewing version used.

How to read

The format above is a standard will be used in all Bluewing versions.

However, note that a Bluewing Server does not enforce a standard, and can use any format by searching for keywords like "Windows" at any location.

The standard format will always start with Bluewing, and will always end with the build number in format "bXXX". The build number may be more than 2 digits.

You can extract the build number of any number of digits this way:

Val(Mid$(Client_Implementation$( "Lacewing Blue Server" ), ReverseFind(Client_Implementation$( "Lacewing Blue Server" ), "b", 1000) + 1, 20))

There may be extra data between the Charset/Platform and the BuildNum.

If the Charset is missing, it is implied to be Unicode, as nearly all exporters use technology that has Unicode support expected.

There is in fact only one platform that still uses ANSI; Windows, specifically MMF2, as CF2.5 has Unicode by default.

Windows

Windows comes in Unicode and ANSI variants, as the early Windows OSes predated Unicode standards.

ANSI supports less characters than Unicode, and which characters it supports depends on the regional language of the system.

If you're using Clickteam Fusion 2.5, the Windows runtime is Unicode only, so you will be using the Bluewing Unicode variant, always.

Fusion 2.0 is ANSI by default, but has a Unicode add-on, so you could use either dependent on if you're running via the Unicode add-on.

Android, iOS, Macintosh, HTML5, UWP are environments that are Unicode natively, so they are always able to decode Unicode; their built apps/packages/websites will support Unicode even when built in Fusion 2.0 without the Unicode add-on.

As a server owner, there's not anything you can do to better help ANSI Bluewing Clients use your server. You may safely ignore the charset setting.

Both Bluewing Client and Server will do their best to accommodate an ANSI variant on the other side, but it will usually be a futile endeavor, as the ANSI end will correctly decode the messages, but the ANSI Fusion runtime means it cannot pass it through the runtime to other extensions in Fusion; some characters will be converted to "?" or similar replacement characters.

It's worth noting an ANSI Bluewing Server will work as if Unicode internally, i.e. exchange Unicode messages between clients without mangling them, and permit Unicode names, even though it will not be able to properly return those texts in the basic expressions like Client > Name.

Use of the Unicode allowlist will let you keep an "ANSI" server running with Unicode support and no issues translating (because all characters outside the ASCII set are banned), but obviously that's a huge restriction that prevents foreign users from using native languages and you should be using Unicode instead.

For more on how ANSI/Unicode works, see Unicode notes.

Technical breakdown

Windows ANSI is effectively non-Unicode Bluewing. The messages sent to a b97 will still be in Unicode UTF-8 format; they will just be converted to the current codepage, if possible, which it generally isn't, since the system codepage is too small to hold UTF-8.

The messages sent from an ANSI Bluewing – that is, Bluewing Client b94+ running in Fusion 2.0 without the Unicode add-on – will be converted properly to UTF-8, and so the ANSI clients can talk to each other provided they share the same system codepage. Naturally, the server will also understand the UTF-8 messages.

The above only applies to build 94+, since Unicode was introduced in build 94.

Bluewing Client before build 94 will be using plain ANSI messages, and will not be able to handle UTF-8 fully, nor will they convert their sent messages to UTF-8, which will often result in corrupt text messages, which could resort in the server taking action against them, e.g. refusing due to them violating the server's Unicode allowlist, or kicking them for using invalid Unicode.

Old implementation version strings

For obvious reasons such as security, stability and performance improvements, we do not recommend using old Bluewing versions.

For the sake of completeness, however, we'll document it here.

In Bluewing Clients before b97 where cross-platform was introduced, the format is only:

Bluewing Windows ANSI b96

Bluewing Windows Unicode b96

Same as above, but no chance of a iOS/Android/Mac build 96.

In Bluewing Client before build 94 where Unicode was introduced:

Bluewing Windows b93

This is ANSI by default, not Unicode.

In Bluewing Clients before build 70, where implementation messages were introduced, the implementation expression will be blank "", same as Relay Client.