Feature Request: Export/Import Mission State Between Characters.

[Xen0byte]

Completing the same missions multiple times (once per character) is quite laborious. It would be nice to be able to have a "main" from which to copy the mission state to the other characters.

[apocalyptech]

Yeah, I'd actually started on an implementation of this but quickly got into the weeds with how to properly deal with mission-related challenges and the like, and it became too much of a datamining exercise for me to want to finish it up. I've got a nascent function available in the backend library for it, though I make no promises as to if it actually works or not:

https://github.com/apocalyptech/bl3-cli-saveedit/blob/master/README-saves.md#copy-nvhm-state-to-tvhm

And an "unpackaged" CLI interface to it, over here:

https://github.com/apocalyptech/bl3-cli-saveedit/blob/master/bl3save/cli_copy_pt.py

I'm afraid that I just don't really care enough to take it any further on my own -- If someone was willing to put in the effort to fix it up and demonstrate that it Does The Right Thing and doesn't result in any janky weird saves, I'd be happy to get a PR merged in. Failing that, of course, folks can play around with editing the JSON exports to their hearts' content, so that'd be a way of doing it manually, at least.

[Xen0byte]

OK, dumping the save file to JSON, manually editing that, and then wrapping it back to *.sav format seems to work fine. I just managed to restart a bugged mission today, so thanks for pointing me in the right direction. I'll look into migrating the mission pool progress from one save file to another sometime within the next few days. Off the top of my head, I don't see how that would have any side effects, but I'll come back with a comment on my findings once I finish.

[Xen0byte]

Actually I ended up just cloning my most complete save file, changing the character class in the JSON, and migrating the gear via the bank. It was much less laborious than manually migrating the missions pool (which seems to work fine, by the way).

[apocalyptech]

Yeah, I don't doubt that it doesn't take a lot of work to do it, but it's the edge cases and all the damned testing which have continued to scare me off of it. Like the game seems to use those challenge lists to keep track of certain things, and I've heard that stuff like your active room on Sanctuary can get screwed up if you don't account for that, if you end up changing characters. But you probably don't want to just blindly bring over all challenges, so you've got to start developing a deeper understanding of those. And then there's the question of unlocked Fast Travels, map exploration data, and all that other stuff.

It's definitely the kind of thing that I wouldn't hesitate to fiddle with by hand, but when you start trying to wrap it up into an officially-supported feature then it's gotta be solid and thorough, and even just testing it out thoroughly so I'd feel comfortable releasing it feels like a monumental task. As I say, a PR with test cases well thought-out would go a long way to official implementation. I should really have unit tests in this thing anyway. :D

(I have have that TVHM-to-NVHM flag coded up for a couple days now, btw; I just haven't had the time to do the proper testing on that before committing it in.)

[Xen0byte]

Yeah, that makes sense. As a QA person who writes a lot of code, I really appreciate the amount of focus you put on testing new functionality. From what I could tell, the flags in the mission objectives array define whether some doors are open, fast travel stations are enabled, etc., however, I am not sure at this time whether those definitions are full or partial, and you are right that more analysis is needed.