-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
--parse-check tra refs #178
Comments
The BAF parser is a bit particular in that it raises a parse error unless resolving strings return the expected result. You have to kick it just right to get it to stop. The D parser should not have exhibited this behaviour. Do you have an example? Regardless, this should be fixed in the next version. |
No, I just assumed they behave the same. D parser indeed skips trarefs. It does output warnings on missing action ids (for example, if used with
I'm not sure what's the best way to handle this, as mods can append to trigger/action.ids (tobex and stuff). On the other hand, it's rare. Maybe just leave it as is. |
The --nogame thing is more bothersome, since WeiDU loads no IDS files with --nogame, but the baf parser needs IDS files in order to successfully convert a BAF file into WeiDU's internal representation, and won't report success unless the BAF text can be successfully converted. D, on the other hand, needs not convert actions and triggers, since DLG files do not store these as byte code. |
Why does D report ERROR as above, then? |
Oh, that was because the D parser has some optional bits for verifying actions and triggers. It's been turned off for --parse-check in commit 6859343. The problem with BAF and --nogame, however, is that WeiDU does not have enough information to successfully parse BAF files without ACTION.IDS and TRIGGER.IDS, which are not loaded with --nogame. D files can be parsed with --nogame, because action and trigger strings can be completely opaque without affecting parsing. |
Ah, ok, I thought it only applied to trarefs. I just expect the parser to be consistent - if it says ERROR or WARNING, then a non-zero exit code must follow.
Yes, of course, I realize that. It's not that much of a problem per se, as I can just display a message to the user, requiring to enter a path to the game in the setting. |
Thank you for implementing this option. I made some tests, and there's one issue that makes it a bit awkward to use. Many D/BAF contain tra references, and obviously those aren't loaded in parse-only mode, however apparently parser expects them to be, and returns failure. (And for some reason, tp2/tpa with tra refs work fine).
I think it's safe to just skip tra checking in parse mode?
The text was updated successfully, but these errors were encountered: