I don't see any way for the CLEF_CMD_FAILED or CLEF_GENERATING_WORLD flags to become set?

Could this leak passwords or other personal data?

Company passwords aren't game commands, but part of the network protocol itself. Server connection passwords aren't game commands either. The command log could contain any string entered for things like vehicle names, group names, signs, etc., i.e. nothing that wouldn't also be stored in the savegame.

CLEF_CMD_FAILED and CLEF_GENERATING_WORLD are handled at src/command.cpp:398-399.

This does not store text/strings, as these are rarely of any use for debugging. It only stores a flag indicating the presence of a non-empty text parameter.

Passwords and (private) personal data should not go via DoCommandP calls as these are replicated to all clients in multiplayer.

@JGRennison How useful is this actually in resolving issues? Any examples where this has been the primary lead?

Removed "backport requested" as I think we should not add new code to RCs. This could potentially do more harm than good. Lets run this in 1.10, and bring it in from there.

@nielsmh It's been quite useful in debugging desyncs and crashes/assertion failures involving map or data structure corruption. What commands were recently executed usually provides a big clue as to the cause of the issue.
Conceptually it is similar to the recent news section, though I've been unable to find a use for that so far.

Generally when I receive a crash log I look at: the crash reason lines, scope logging lines, which thread it is, the decoded stack traces, which OS/compiler, AI/company config, the command log and if relevant the game date and lang, blitter, font config. The rest of it is rarely of any use.

Is there a way to make this log AI commands as well?

AI commands are as human commands usually, so they are probably already included in the log.

@glx I thought so but my crashlog only contained AI startup control commands

Ok, AI uses DoCommandPInternal() directly, so bypasses the logging in DoCommandP()

The flags are now all set in one place.

I've moved the logging point to be within DoCommandPInternal, this does change the semantics a bit.
As DoCommandPInternal has multiple return paths, the early error paths where the test command is never executed aren't logged any more, and the logging takes place after the test command is done, before any local command execution with DC_EXEC.
Is this reasonable, or should the logging entry be made/updated after any DC_EXEC execution (in the edge case where the results differ)?
DoCommandP's only_sending flags isn't saved any more, but that is probably no great loss.

Hi, there's been no activity on this for nearly 4 months. If this PR is not updated in the next week or so, it will be closed