Request: any kind of non 0 ExitCode when parsing tp2

[AL|EN]

If it won't be too much trouble, please also change ExitCode to non 0 if weidu encounter syntax error when parsing tp2.

[Wisp]

Should be possible.

[AL|EN]

Thanks, it's for rare cases when people name their files as tp2 but in reality those files aren't mods at all: https://github.com/UnearthedArcana/refinements/blob/master/refinements/languages/english/armor/human_readable/ident.tp2
Checking exitcode is faster way of checking "is this is valid tp2 mod file" then scanning each line and look for weidu specific keywords.

[DavidW]

Out of curiosity, what's the scenario where this could cause confusion? The only active tp2 files are either (a) in the base game directory or (b) with the same name as the mod folder. I really doubt anyone is putting non-legit tp2 files in the base game directory.

[AL|EN]

It's the "weidu relative execution" problem when you miss component names during --list-components-json combined with the fact that I don't relay on exe location because many mods don't have them and I support infinite amount of extra directories inside a folder where player extracted mods. It's possible to 'exclude' lower-level folders when I detect first tp2 file but someone could put several tp2 files directly inside mod folder with only one of them as actual weidu mod. The only effective way which I found is to try to parse it via weidu and check if it produce syntax error (and get non-zero exitcode from weidu) so I could exclude all tp2 files which aren't mods. Scanning tp2 file content is not effective for such cases as I have to scan entire file line by line. The best is to assume and require that tp2 files are definitions for actual mods which could be installed and not a placeholders for extra stuff because those can have different file extension.

[Wisp]

So I take it you want parse failure to be distinguishable from installation error (i.e., different return values)?

[AL|EN]

That would be even better. But I wonder:

Right now, I'm spawning new process for each mod component like this:

Code: [Select]

Setup-MyMod.exe --no-exit-pause --noautoupdate --skip-at-view --language 0 --force-install-list 100
suppose that I will improve installation routine so the --force-install-list have multiple components at once, for single process:

Code: [Select]

Setup-MyMod.exe --no-exit-pause --noautoupdate --skip-at-view --language 0 --force-install-list 100 101 102
now, let's say component 100 was installed correctly, 101 failed with installation error, 102 was installed correctly.

I assume that the exit code would still be 'installation-error' error code because of the single component failure?

[Wisp]

Yes, the return value is for the process. WeiDU prints more granular install status to STDOUT, but it's not in a very machine-friendly format.

[AL|EN]

Getting back to this topic:

when using "--force-install-list 100 101 102" aka two or more components for single weidu proces, there is no way for weidu to pause non-interactive installation when component 101 will produce error, correct?

so currently, the only way of correctly matching error occurrence with component ID is to spaw new process for each mod component, correct?

[Wisp]

No, WeiDU does not pause or await further instructions when a component fails to install.