Lacewing Blue was designed with a different philosophy than Relay.
While the two objects function very similarly in actual functionality, Blue has more features built in to make it easier for a Fusion developer to work with.
Names must be distinct across the server
In Relay servers, client names can be reused by different clients at the same time, the clients are simply forbidden from entering the same rooms as someone with their name. This can cause confusion and allow impersonation.
In Blue servers, client names cannot be reused, and always uniquely identify a client regardless of what channels they are on. Similarly, a channel named "Text" prevents anyone creating a channel called "TexT".
The matching system was expanded to simplified equivalent text, not just casing. More details under How selection is changed.
While Relay allows you to do a lot of nonsense with no complaints, Blue checks everything you do to be something that makes sense, and will create errors if not possible.
Here are example scenarios:
- Relay won't complain if you use "send message to peer", without having a peer selected; it will simply ignore the request. Blue will create an error.
- Relay won't complain if you select a peer by name, but don't find a peer with that name; it will select no one. Blue will create an error.
- Relay won't complain if you add a byte with value 300, it will truncate it to 44 instead. Blue will create an error.
Note that Blue will not create an error if you're not connected and attempt to send a message. This is just for efficiency.
If your name is not set, if the channel is not joined or selected, peer does not exist, etc, then you will get errors, so this will cover 99.99% of scenarios, as all developers should already have an On Disconnect event.
While this limit isn't hit often, Bluewing has a cap on how many events it will run per second, or more accurately, how many events it will run per frame.
This is normally 10 events per frame, which in a standard 60FPS app, will give you a whopping 600 events it can process per second.
If you're using Always: Send Position, as soon as you hit 11 players (10 peers x 60 messages each) the limit will be overloading, resulting in an error like this:
"You're receiving too many messages for the application to process. Max of 10 events per event loop, currently X messages in queue."
On a side note, this error does not occur if it overloads as a one-off; it must happen multiple times before the error is reported. It can happen during a long frame transition as events couldn't be run without an Extension to run them on, resulting in a long queue backlog building up.
For improvements on performance, refer to the performance under the Tips topic.
While most of the naming and functionality has been kept from Lacewing Relay for compatibility, some menus have been rearranged so the expressions/actions/conditions are easier to find.
Note this rearrangement does not affect the ability to replace MFX files, as internally Relay and Blue use the same A/C/E ID numbers.
Error messages include event numbers
Introduced in build 89 of Blue Client and build 16 of Blue Server.
The error messages in Blue will be prefixed with the Fusion event number that caused them. This won't include whether the number is in global, frame events or behavior events, as that will require parsing the whole event list.
(An update to DebugObject may include this, however.)
DarkEdif update checker
In the Fusion editor, both Fusion 2.0 and 2.5, Lacewing Blue objects quickly run online checks to see if there's any updates to the extension set. You can read more about it (and disable it if you want) here.
This update checker does not run in your built EXE files, only in the editor versions.
If there are minor updates, the default is to just change the icon, and not show a popup, but for major updates (such as crash fixes), you will get a popup.
The popup will include a change-log of fixes and added features, for example:
With the popup, you can choose to open the download page, or ignore it and continue working with your old version as usual; the objects will work like normal.
Also note in the frame editor, the icon will be changed to reflect that there is an update, which is also visible in screenshot above.
You will get a popup for Blue Client the first time you start using a Blue Client MFA with an old version of Blue Client installed, and the popup won't occur again for Client until all of the Blue Client MFAs are closed.
(You may get both Server and Blue Client popups if you're behind the times, though.)
All the added Actions, conditions, expressions and properties are documented under the Lacewing Blue Set section of this help file. The rest are documented under Relay.
There's plenty of modifications and improvements done to Blue, but if the a/c/e/p works with the same parameters and returns the same value usually, then the Relay Set topic will have notes about the difference appended to it, rather than a separate page being made.
This is covered under the See anything missing? topic.
As the time of this help file's revision 14 draft:
- Bluewing Client has 1 extra action, 3 extra conditions, 6 extra expressions, and 3 extra properties.
It is compatible with Android 4.4+, iOS 10.0+, Mac 10.13+, Unicode, HTML5 and UWP; Relay is only compatible with Android 6 and lesser, and Flash.
- Bluewing Server has 19 extra actions, 8 extra conditions, 10 extra expressions, and 4 extra properties.
It is compatible with Android 4.4+, iOS 10.0+, Mac 10.13+, and Unicode; and supports Android, iOS, Mac, Unicode, Flash, HTML5 and UWP clients.
Working out when a server is closing a channel, and saving any corresponding game data, is extremely difficult in Fusion events.
Blue handles that with a new condition; when the channel is closing down, for any reason outside of unhosting the server, it triggers the Channel > On channel close condition.
This means you don't have to check auto-close and master settings in each leave request and disconnect event to work out if a channel is closing.
Adding embedded files from Binary Data
Introduced in build 100 of Bluewing Client, and build 33 of Bluewing Server.
Embedded paths passed to Binary to send > Add file action (client, server) will be looked up from embedded data first, and if not present, then looked for on the hard drive.
In Blue Server, you can also use it for loading certificates, and Flash policy.
Lacewing has a limit on how many pending connections it can have at once. A malicious actor can use these up by never fully completing the opening process, which is called a TCP SYN flood attack.
Blue Server incorporates a limiter for pending connections per IP address, preventing malicious usage of all the pending connections.
This protection is not in Relay Server, and a SYN flood attack will result in the attacker using them up and legit clients not being able to connect to the server, although already-connected clients will still communicate with each other as normal.
Due to the process of being half-open normally lasting under half a second, you should not expect to hit the SYN flood limit, even if three people on your LAN connect on a game at the same time.
There is a separate limiter for simultaneous fully-open connections from the same IP – e.g. players in the same LAN trying to use an external server. This is capped at 5 clients by default.
If you need either limit boosted, contact the server admin, or if you're running your own server, contact Darkwire Software. The change is quick and requires only modifying a couple C++ lines.
In Blue Server, the actions, conditions, expressions and properties, and their associated menus, have been translated to French, and Portuguese.
Regretfully, the error messages and other content have not been translated. The A/C/E/P was done by simply translating the DarkEdif JSON file, but error messages are all over the extension and liblacewing's internals. So it may be done, but requires a code overhaul.
Blue Client has also not been translated.