…og entries

This reverts commit d4e4808.

Updating develop branch on my end

This reverts commit e03289b.

…Say dialog entries"

This reverts commit 5cad400.

Updating the branch on my end

Also did a little reorganizing of what's in the Fungus Save script folder

Thanks to the new view system, they're no longer necessary

All the tests have passed at the time of this writing

…to SaveDataCreationTesting

…architecture

Added an Encode func to NumericVarSaveEncoder that can take an IList of vars, returning an IList of said vars encoded. I know that Fungus would normally return just a regular List, but I felt it'd be better to go with IList here due to how it's good practice to code more to interfaces than to concrete implementations.

Especially in this case. If the client really wants a regular List of the encoded results, they can easily make their own by passing said results to the regular List's constructor.

One that lets subclasses decide which var types they can support. This should cut down on boilerplate code we'd otherwise make when working on other var encoders.

Also deleted the sound tests, since we're quite a ways off from testing that stuff

FlowchartSavingTests was getting a bit big, and I felt that testing other var type encodings would take similar amounts of code. Hence, I made FlowchartSavingTests an abstract class for various suites that each focus on certain var types or groups.

Hence the new FlowchartNumSavingTests suite.

To cut down on code duplication, I created a testing extensions script. I may have to do something about the code duplication in the string var tests as they are now...

Will need to add back in the tests that check to make sure that invalid inputs get rejected

That test suite was set up only for var-encoding, so naming it "FlowchartSavingTests" was a bit misleading

As jsons don't work with all var types, I refactored the encoders to be more flexible about whether their values get encoded as json strings or regular strings

Renamed a couple flowcharts to reduce confusion, too

It's shorter and more intuitive, considering this is a Save/Load system

I feel that rather than relying on StringPairs to be the save data units, there should be different classes handling the job for different types of state.

I find this approach a lot more extensible, flexible, and as a result, more user-friendly.

Of course, this means that the unit tests may need to be restructured. New tests will be written as the restructure continues.

Currently expecting VarSaver to become obsolete and its subclasses to be reworked to fit the new ISaveCreator interface

Also reworked the unit tests

All variables are saved in units with the values stored as normal strings, after all

Turns out that simply saving every var as a string by applying ToString on their values doesn't always get the right results. Revised the architecture so that it lets you make more variable-specific savers without necessarily having to make new ones for each variable type.

With the first stage stuff to save being the states of the portraits

PortraitSaveState now saves the name of the position instead of the point in space said position is in. Makes things more flexible, like for when the user decides to slightly change the coords of a Stage Pos.

It doesn't seem like it'll be necessary to record the sibling indexes of the portraits, hence the removal

…acter test

Given how not all the setup can be done in one function call, all the tests will need to be IEnumerators

…exes

Indexes are a lot less volatile than names, hence it should lead to less problems if we just record indexes there.

… Dude

Figured it might help code in backwards-compatible saves if we have the index AND the name registered, so...

Also, a couple tests broke due to adding the Character named Dude. Fixed those

I realized that given the purpose of save units, there is no need to have info structs and save units be separate classes. The latter were just working as needless wrappers for the former.

Some refactoring of the stage-saving tests was needed since the portrait state containers are now structs instead of classes.

- Deleted the old VariableSaveUnit class
- Renamed the info structs (VariableInfo, PortraitSaveState, etc) to reflect their roles as save units
- Refactored tests and savers to fit the above changes

- Added generic DataSaver
- Renamed PortraitStateSaver to PortraitSaver
- Had portrait tests use the above saver

These changes were applied to the save sys code involved in the tests I've made.

- Removed unnecessary usings
- Put things under a new namespace for better code organization: LionManeSaveSys
- Reorganized source files

I can't save the state of the Say Commands' execution counts when they're inaccessible from outside code, so I changed it into an auto-property

…on count

This definitely matters for the Menu Command's HideIfVisited field, since that there depends on block execution counts

Hide If Visited procs based on the blocks' execution counts, and as making sure that is saved should depend on the Block-specific unit tests...

What with how different Commands' states may need to be saved in different ways.

Before, it didn't properly check the block state before deciding whether the test was successful. And to make sure that the test passed, I had to alter the Block and Say Savers so they... well, properly had the command indexes saved.

Since the stuff for saving the state of say commands should be in CommandSavingTests. And that stuff for checking the execution counts of blocks should be in BlockSavingTests

…SaveSystem

…wer code

Since they can potentially hold thousands of bytes (the GameSaveData and UISaveData most likely will), which is too much for a struct

Any client code can also set the typenames in case there's any need to differentiate instances beyond just their class, like with VariableSaveUnit

…ewRefactor