Skip to content
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

Feature request: Flag to allow export to continue on errors #90

Open
JMPZ11 opened this issue Sep 5, 2024 · 3 comments
Open

Feature request: Flag to allow export to continue on errors #90

JMPZ11 opened this issue Sep 5, 2024 · 3 comments

Comments

@JMPZ11
Copy link

JMPZ11 commented Sep 5, 2024

Spriggit is still catching up with BGS' changes to Starfield, but when it stops working, it's all or nothing.

I know the intention of Spriggit is source control, but it is useful for many other things - including simply being able to search vanilla esm's fulltext. (I also want to be able to track's BGS' changes...)

It is ok if there are a handful of things it can't convert -- I need it to not abort, and just keep going.

If such a feature exists, my apologies.

Thanks!

@Noggog Noggog added this to the Initial Release milestone Sep 5, 2024
@JMPZ11
Copy link
Author

JMPZ11 commented Sep 9, 2024

I feel like this could give people false positives. Even if there is an override button, people may not read the error and just simply continue. This should be a manual override flag in the CLI and not the front-end GUI. This type of error-swallowing can lead to disastrous effects in practice.

Agree that it shouldn't be arbitrarily simple, however I don't use the command line, and I use Spriggit primarily for analysis, repair and bulk data changes... and all of the involved paths are quite long, and include spaces.. I would end up making a tool to call the command line tool -- which seems a bit redundant when it comes with a UI.

A relatively simple safeguard would be to somehow flag the output so spriggit will not import without the files being manually edited in some way -- It seems like a reasonable regardless, eh?

@Noggog
Copy link
Member

Noggog commented Sep 9, 2024

For the UI, it'll probably be a off-by-default checkbox, /w a disclaimer warning tooltip, im thinking?

for the CLI, it'll probably be a boolean parameter you can add --ContinueOnUnknownContent or whatever

If the users turn those on without reading anything and then complain about content loss, well, that's on them

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@Noggog @JMPZ11 and others