When checked, this property enables multi-threading, allowing the Lacewing receive/send message events to run without being told to tick each frame by Fusion.


With this property not checked, if the Fusion event loop is paused or slowed down, for example:

  • another object running slowly
  • low frame rate
  • the app is paused by the user
  • a modal sub-application without a Blue Client is opened,
  • a popup message i.e. by Popup Message Object 2

… and the server attempts to contact the client, it will not get through fast enough as the Lacewing processing would have slowed/paused with Fusion.

With that delay, there is a high probability of a timeout (taking too long to respond to the server), causing the server to close its connection on their end.

How multi-threading works

When multi-threading is enabled, the Lacewing "message receiving" ticks over on a second thread, outside of Fusion's main thread, and queues any received messages/events for when Fusion main thread ticks.

This means when the server attempts to send a message to the client, it will always succeed because the second thread always receives it, and if the Fusion app lags temporarily, the second thread will keep going at regular pace, and just give the main thread a bigger queue of messages to run Fusion events for when it next ticks.


Red { indicates a single Fusion event loop, also called a tick, or one of the FPS. You can change the number of ticks per second in application properties.

Demonstration of multithreading. It shows Lacewing is processing messages constantly, queuing Fusion events behind an exclusive lock.


The same loop thread will be used throughout the program, and will stay running between frame transitions.

Should booting a thread on start fail, Blue Client will fall back onto regular single-threading automatically and instantly.