World logs

The Unity Console goes blind the moment a world leaves the Editor. Play mode is the last place your logging is easy to read, and play mode is not where worlds break: they break with eight people in them, on somebody else's connection, in a build you uploaded an hour ago.

Udonite → Open Window → Settings → Logging reads the client's log while you are in a world and puts your lines back in the Console.

The three settings, which are one setting

It starts on Udonite logs. The listener reads and never writes, and forwards nothing at all unless a world is running and logging.

All logs stops after two hundred lines from a single read and says how many it dropped. A busy world hands back thousands at once, and the Console slows to a crawl long before it refuses them.

Nothing will arrive unless full logging is enabled in VRChat's own settings, which is the commonest reason for an empty Console.

A forwarded line is the line you wrote

[combat] [Scoreboard.Award:14] hit for 3

That is what play mode shows and what a real world shows. Nothing is added on the way through: no clock, no severity word, no colour, no filter.

That is deliberate rather than unfinished. A line that reads two ways depending on where it ran cannot be compared with itself, and comparing them is the whole reason to forward one. The time is not lost either — the client stamps every line in its own file, and the Console stamps its own.

More than one client

Testing anything multiplayer means two clients on one machine, on one account. The display name is the same in both, and the world cannot tell you which window a line came from.

The client settles it without being asked: each one writes its own log file. So once a second client is heard from, the Console starts numbering.

[client 1] [Scoreboard.Award:14] hit for 3
[client 2] [Scoreboard.Award:14] hit for 5

Nothing is numbered while only one client is talking. A prefix that always reads client 1 tells nobody anything and costs every line the width of it.

The numbers go by which client logged first, not which launched first. One started and left standing at the join screen is not client 1 to anybody watching.

Lines already in the Console are not relabelled when a second client appears. Relabelling them is not possible, and guessing afterwards which belonged to which would be worse than leaving them plain.

When a behaviour faults

This is the worst thing that happens in an Udon world, and the quietest. The VM throws, the client catches it, writes one line, and disables that behaviour for the rest of the session. Nothing else happens. The door simply stops working, and the world goes on around it.

The Console reports it:

An Udon behaviour faulted and is disabled for the rest of the session.
System.NullReferenceException: Object reference not set to an instance of an object (program counter 812)

The program counter is an address in the compiled program, not a line in your source. Translating one needs a map from addresses to source that Udonite does not currently emit, so it is passed through as the client wrote it rather than guessed at. What the message names is usually enough to find the call, especially with your own Log lines around it showing how far the behaviour got.

The several hundred lines of stack and heap dump the client writes after it are left in the file, where they belong.