How do we want to handle legacy binary assets?

[goblinJoel]

The new editor already can do saving and loading for all of the different assets, as far as I am aware. Moving this into the assets pipeline is just a matter of changing how the save/load functions are called and moving the asset-specific (de)serialization logic into Serializer objects. So, that shouldn't be difficult.

This is really a policy question: Should users be able to save using the old binary formats?

My take is that users should be able to load them, but we should deprecate them. This can be enforced by rerouting the saving into a different serializer. I'd have to check to see where the most logical spot for that would be. I'm wary of actually removing the save code entirely, but I guess that's what repos are for if we ever want it back. But do we want to encourage users to move to newer formats (like JSON), and if so, how should the user experience for that work?

[chutchinson]

I think we should allow them to load and save legacy assets as if they were native to the environment; however, I feel the best user experience would be to implement a "converter" application that can convert legacy assets of old projects to the new editor. It should be made quite clear that the new system is not backwards compatible.

Any decision made here is irrelevant to the engine because of the asset pipeline (which would also be used extensively for the mentioned project conversion application).

[swordmaster2k]

I think a standalone converter is the way to go, rather than bloating the editor with code that is likely to become quickly deprecated. The migration will only affect current users of 3.2.1 which is relatively few. After that it will be 4.0 and onwards.

A lot of TK 3.0 editor's code was bloated with legacy stuff dating well back to TK 2.0 support.

[goblinJoel]

I do imagine being able to add custom fields to various assets (like character stats), which would be trivial to do in JSON and, I assume, use in RPGCode. It's a feature I always wanted in the old TK. This, however, would not work in the legacy format, so we would still need code that checks whether the current format is capable of adding custom fields and changes format or complains or disables things accordingly.

Is this different from what you guys are envisioning?