xstr debug filter

[MjnMixael]

While I was adding strings to the engine, it became obvious that there's no good way to have the engine output a list of a strings and string IDs from the engine because they are only handled when the code is running through a section with an XSTR call. Over the years SCP has added several new strings and IDs as well as allowing a few tables like controlconfigdefaults.tbl and sexps.tbl to define "built-in" strings. This made it tough to find what IDs are available to use. So my best idea was to add an nprintf (XSTR debug filter) for XSTRs that simply outputs to the log each string and string ID that XSTR handles as it handles them.

This is still not a fool proof way, but it's much simpler and more reliable than searching the code for 'XSTR' function references because some of those apply strings and IDs dynamically and that doesn't cover any added by tables. With this in place you can launch FSO, poke around each UI and run a mission or two. Then you'll have a reasonably complete list of strings and string IDs in the debug log.

[z64555]

I'm not familiar with nprintf and am still away from my main dev environment. Would you please give a short summary of its operation and how you used it here?

Also, have you considered making a function that can be activated by commandline that will activate a code path within XSTR calls to collect the string and string ID and then print everything to file?

[MjnMixael]

I'm not familiar with nprintf and am still away from my main dev environment. Would you please give a short summary of its operation and how you used it here?

Also, have you considered making a function that can be activated by commandline that will activate a code path within XSTR calls to collect the string and string ID and then print everything to file?

nprintf only prints to the log if the debug_filter.cfg has the first parameter active. So in this case it will only print if that file has +XSTR in it somewhere.

As for the other, I did consider it and it'd be roughly the same as this method. Using +XSTR and then -[EverythingElse] you could pretty much generate the file you're suggesting. This one however only takes a single line of code.

[z64555]

Ok, that makes sense. Do you have an example output of the current method?

A UI design issue is apparent here. There are currently other commandline options that generate files (lua scripting interface and the controlsconfig default preset files are two examples), so having the the XSTR printout done via the debug_filter.cfg would be potentially a hurdle for modders. If this feature is urgently needed, then I'm fine with merging it in and deferring the commandline path for later.

[MjnMixael]

Ok, that makes sense. Do you have an example output of the current method?

A UI design issue is apparent here. There are currently other commandline options that generate files (lua scripting interface and the controlsconfig default preset files are two examples), so having the the XSTR printout done via the debug_filter.cfg would be potentially a hurdle for modders. If this feature is urgently needed, then I'm fine with merging it in and deferring the commandline path for later.

I added this as a coder to assist in writing the SCPUI Options Localization PR because it's hard to tell what built-in XSTR IDs are used or not used with just a reference search in VS. This is not meant to generate a strings.tbl because it's unreliable. There's no way I can think of to confidently generate an entire strings.tbl without playing the game to force the code to run through every possible XSTR call that exists in the engine. Additionally, you would need a ton more code to to handle duplicate line prints. This is simply a log print when XSTR calls are made that prints the string and the ID that was passed. Nothing more, nothing less. It can be used to create a strings.tbl, but that is not its purpose.

If you're inclined to have this done as an actual feature to generate a full strings.tbl, then this can be closed without merging. I'm not going to expand the scope of this to create that. I simply thought this might be helpful to other coders in the future doing localization work within the engine.

[MjnMixael]

Ok, that makes sense. Do you have an example output of the current method?

Here is an example log with this debug filter turned on.
https://fsnebula.org/log/651052f514d712daada9581c

[TRBlount]

Just an important thing to note. In localize.cpp there is XSTR_SIZE which should be updated as new XSTRs are added. It's not ideal, but it can be used as a quick reference if needed.

This is a useful feature for modders, so as soon as stable hits it can be merged.

[MjnMixael]

Just an important thing to note. In localize.cpp there is XSTR_SIZE which should be updated as new XSTRs are added. It's not ideal, but it can be used as a quick reference if needed.

This is a useful feature for modders, so as soon as stable hits it can be merged.

I honestly forgot about that. It's commented out (and thus generally won't be brought up with reference searches) since the xstr map is not size limited anymore. But it would be good to keep that number updated as much as possible, yeah.