To debug a Lacewing app, you should use deduction by omission, to make sure if it's a receiver bug or sender bug, or even a server bug or client bug.

Is it an extension/runtime bug, or your fault?

If your Fusion app:

  • crashes,
    (causing a pop-up with a Send Report button, or "has stopped working" text)
  • unexpectedly closes (and not due to a Storyboard > End Application action),
  • freezes entirely for several seconds, or
  • goes Not Responding,

then it is likely a extension/runtime bug.

Crash, or unexpected close

In the case of a you should consider adding DebugObject into frame, as it will tell you what extension is causing the crash, for example:

Crash occured in the Fusion program. A thread running code inside Bluewing Client.mfx was denied access to read from address 0x000100DC.

Notice the MFX name inside the error message.


Extensions should never crash, even if you misuse them, so if you get a crash, first double-check you're on the latest version, then go straight to the bug reporting section below.

Not Responding/freeze

A Not Responding or a freeze for several seconds may be the extension in a deadlock, where several threads are waiting for each other to release something for them to use (like two people grabbing the last item in a grocery store), or it may be too many loops.

Fusion effectively "pauses" when running fastloops and other loop types (like Lacewing's loops), and the pause remains until all the loops are done. You can read more details under the How loops work guide.

Gradual slowdown

If your app is getting gradually slower, not randomly getting extremely slow, chances are it's not a bug with an extension, but you looping through things in a slow way, and as the number of things you're looping grows, the performance impact grows with it.


There are a lot of performance tips under the Tips article.


If you have the CF2.5+ DLC, you can use the profiler to narrow down where the slowest parts of your code are. You can enable profiling in first tab of application properties.


If you think you have found an extension bug, try using the process of elimination described below to determine if it is a Relay-only or Blue-only bug.

If for some bizarre reason you're using Relay against all advice, then check the list of known Relay bugs.

Clients getting disconnected unexpectedly?

Read up on the server's ping timer and how connections can be closed for inactivity, or not responding fast enough, under the Appendix topic.

If you're running your own server, you should be able to read the On Error events and see if the server is kicking them. If there is no error right before disconnect, the client is disconnecting by themselves. You can also disable the inactivity timer if you wish.


If you're connected to public servers, make sure you read the welcome message on connect. They may tell you more about limitations of using the server, and if the server will message you if you are violating them.

Peers not appearing or not being destroyed?

Read the maintaining a peer list example.

Also read the creating player objects and selecting player objects examples as well, as they have a couple subtle scenarios where things can go wrong.

Too many player objects reacting to a message?

Read the selecting player objects example, and the creating player objects example too.

No player objects reacting to a message?

There are two not-very-obvious ways selection can fail. Read the selecting player objects example.


If you're selecting correctly, confirm you're creating all the peer objects when needed, by reading the creating player objects example, and the maintaining a peer list under the Examples topic too.


If you still aren't getting the results you expect, follow the process of elimination example below.

Message bugs

If your app isn't responding to messages consistently, follow this guide:


First, always have an On Error event in every frame that Lacewing is in.

This is especially important for Blue, which will usually describe exactly why you can't do what you're trying to do.


Second, make sure that On Error event is accumulative, so if two errors are reported from one thing, you get both errors. Instead of setting a string to an error, try adding to a list instead.


Third, it helps a lot to have an unrelated Lacewing app that will tell you plainly what is going on; one that logs everything!

The creator of Lacewing Blue has written two apps for those purposes, called Tester Lacewing Client (download), and Tester Bluewing Client (download).


Be sure to check the version of the Bluewing Client version in the Tester.

These apps are very simplistic and not meant to handle a flood of messages, so if you're sending your position multiple times a second, deactivate that event temporarily while you use the Tester to investigate.

(If the bug is with position messages, then make the position messages less frequent.)


If you're connected to public servers, make sure you read the welcome message on connect. They may tell you more about limitations of using the server.

Process of elimination

In a process of elimination, you replace parts of a system, swapping out a part, testing, putting original part back, then swapping out a different part, and so on until the system works fine; when it does work, the last part you took out was the cause of the failure.


Demonstration:

For example, let's say you're sending a X/Y position, but it's not updating on the receiver's screen.

This could mean you're not sending it right, or you're not receiving it right.


  1. Swap out a Tester Client for your sending program; i.e. make a Tester Client act as the sender, and use it to send the message to your receiver app instead.


  1. Does your receiver app react properly?
  • If the receiver did react to the Tester Client's sent message, then clearly your sender client, i.e. the thing you replaced, is the broken one.
    Check your sending events:
      • Are you selecting the right channel/client beforehand?
      • Is the sending subchannel correct, matching the receiver's code?
      • Is it the same send/blast choice out on both receiver and sender?
      • Are the group of events active for the sending events?
  • If your client is not reacting to the message, move on to step 3.


  1. Go back to your original sender, and use a Tester Client for your receiver instead.
    Does the Tester Client receive the message as expected?
  • If yes, then it's evident the thing you replaced, the receiver client, is the broken one.
    Check your receiving events:
      • Is the receiving subchannel correct, matching the sender's code?
      • Is the type of message correct? 
        Is the receiver set to read a channel message when it should be a peer message?
      • Is send/blast correct, matching the sender?
      • Is the number/text/binary type of message correct, matching the sender?
      • Are you looking for a server message, when it should be a server channel message?
        Or looking for a peer message, when it should be a channel message?
      • Are the receiving event in activated groups of events?
      • Are other conditions in the receiving message event not true?
        Make a simplistic "on message" event without other conditions to check.
      • Are you selecting the wrong peer object, or not selecting correctly?
        See the selecting player objects example, there's a couple easy mistakes.
  • If the Tester Client is not reacting to the message, move on to step 4.


  1. You've now deduced you're not sending or receiving properly. Which means something subtler is going wrong.

At this point, assume everything you've think your app is doing correctly is not happening, until you check and prove otherwise.

The brain likes to make shortcuts to speed up its work, and by doing so can skip things. So having this skeptical mindset is very necessary.


You'll need to check everything that leads up to the channel join that you assume is happening, and check your application settings as well.

After all, if it was doing all the things you expected, you wouldn't have a problem.

Move on to step 5 to start off the checking everything.


  1. Did you not turn on Run while resizing/Run while minimized app properties?

With both of those unchecked, when the user switches to a different app instead of your Lacewing one, the Lacewing app can be disconnected.

More tips on getting a consistent connection are available under Tips; make sure you have done all of them, particularly the Denied conditions.


  1. Did the name sets work?

Check the Tester Client's logs, both sender and receiver; did both always manage to set their name, when you used it to replace the sender, and later, to replace the receiver?

Remember, names can't be reused, so if you run two clients (one sender, one receiver) and use the same Set name to "testclient" in both, the second will get its name denied, as the "testclient" name is already in use.


  1. Are the clients joined to the channels they're meant to be?

Check the Tester Client's logs again, make sure when they joined there was a peer already on channel, or that the peer connected.


  1. Is it the server you're on?

Try changing both the sender and receiver to a different server.

Darkwire Software runs two free public servers you can use. If you're using one of those, switch to the other. A bug occurring on one server but not the other suggests a server bug, so jump to the "report a bug" section below.

If it's a custom server, you'll have a harder time, but that also allows another form of testing, by enabling the intercept message conditions and checking sender/receiver on your server side.


  1. If you have tested everything, is it a bug with Relay Client/Server?

Some have been noted in Known Relay bugs section, but others may exist.

Blue Client/Server may have bugs too, although it has been tested very thoroughly over the years.


Use the same process of elimination by using the Tester Clients above; if Blue Tester works as expected in both sender and receiver, but Relay Tester doesn't, then you know Relay is having a bug.

Be very careful you've not missed something when using the Testers, though. Remember, the brain likes to make shortcuts, so it will be happy to tell you you've done something in the Tester when you haven't.


Although Relay bugs can't be fixed, reporting them to Darkwire will result in them being added to later revisions of this help file, so it's worth doing.

Likewise, if a Relay Tester works as both sender and receiver, but Blue Tester doesn't, then that indicates Blue has a bug.


Note that different behavior doesn't mean Blue has a problem. After all, Blue behaves more strictly, and so will prevent strange behavior that Relay allows.

For example, Blue won't let you set your name to what it already is, and Relay will allow it. Code that depends on sending these unnecessary messages will not work.

Continuing that example, if your lobby code always waits for a name set to succeed before it continues, then there's opportunity for an issue; e.g. your game round finishes, you jump back to the lobby frame, but lobby frame attempts to connect and set name before it displays a channel list.

The name set will obviously fail for Blue as the name is already set, resulting in no name set event, so your app won't continue.

How to report a bug

Relay cannot be fixed, as the source code has been lost.

Blue is still maintained actively, and likely will be for years to come.


You can report Blue bugs on the official Clickteam Discord; before you do, try to isolate your example to the minimum amount of events necessary to cause the bug. This will make less work for the developer.

Ask for user Phi on the Discord chat, and you'll usually get a same-day response, and usually a same-day fix as well.


(If the Clickteam Discord invite link above does not work, it will be linked on the sidebar of the Clickteam forums.)