Skip to content
This repository has been archived by the owner on Oct 31, 2023. It is now read-only.

Custom (Additional) Save format for Runtime #43

Closed
Seneral opened this issue Feb 18, 2016 · 5 comments
Closed

Custom (Additional) Save format for Runtime #43

Seneral opened this issue Feb 18, 2016 · 5 comments

Comments

@Seneral
Copy link
Owner

Seneral commented Feb 18, 2016

Description: Current save format, ScriptableObjects, cannot be created and saved at runtime nor saved externally. So, a new save file format for runtime is needed. It should be optional for the Editor but essential for Runtime.
Maybe Binary, but more likely XML, just like Substance's .sbs.

State: None. Along with it there should be an attribute-based tagging system for extra variables that need to be saved in each Node/NodeKnob subtype. The rest is hardcoded as it is known what to save, obviously.
Please notify me before working on this to discuss some details:)

@Seneral
Copy link
Owner Author

Seneral commented May 1, 2016

** Removed off-topic node creation discussion **

@Seneral
Copy link
Owner Author

Seneral commented Jun 22, 2017

New update: I'm finally working on this:)
State: Aleady far in, most stuff stands and is integrated:)

The goal is to allow fast and easy implementation of own formats, even for custom databases. So as with most systems, it is fully modular, just extend the ImportExportFormat base class and program the IO routines:) Also, you can easily add an interface if you need, say, special access to a custom database to import/export to. No big deal, just a few lines of code in the format declaration itself.

Also, the NodeCanvas is optionally served in a seperate, linked and structured data format which makes it easier to interface with alot of formats like XML. It removes the need for caring about unique IDs, linking and also finding custom node variable data.
Variables are fetched from the nodes just like any other serialization system does, accounting for public/private and the [System.NonSerialized] and [SerializeField] attributes.

So, in the end, most work is lifted off the actual format-specific implementation. As with many systems in the framework, it only needs a single additional class to implement a custom data format, be it as complex as you want:)

I'll finish the custom knob system #74 first though because of the obvious structural changes it comes with. Don't want to modify the format right after implementing it:)

As always, feedback appreciated.
Seneral

@Seneral
Copy link
Owner Author

Seneral commented Jun 30, 2017

Finished this part aswell, import system is now fully functional with an XML format as a base:)
Once again, this can easily be extended to own formats or even custom database access:)
Will create a PR tomorrow...

Seneral pushed a commit that referenced this issue Jul 2, 2017
- Implemented modular IO system for custom formats
- Added XML IO format using that system (theoretically working at runtime to save canvas between sessions)
- Specify custom format location through Selector or GUI
    - Allows for custom database access and similar for import/export
- Option between extending ImportExportFormat or StructuredImportExportFormat when implementing custom formats
    - Structured adds a layer of abstraction on the Canvas Data easier for file-based formats
        - Handles IDs, Serialized Fields, Creation and Access of the complex NodeCanvas structure
@Seneral
Copy link
Owner Author

Seneral commented Jul 2, 2017

This too is finally merged and committed, would love to hear your feedback:)
Will keep this open for some days...
Seneral

@Seneral
Copy link
Owner Author

Seneral commented Jul 11, 2017

Alright, seems to run fine now:)
IO Formats have full support (see XML Format)...
Although I did not get feedback from users implementing custom formats or database accesses yet, I think it should prove fine:)

@Seneral Seneral closed this as completed Jul 11, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant