I do agree with Casi that allowing the user to recover from such issues using the editor, would definitely be helpful and personally I’m all for it.
However, the system was designed with a zero-error-tolerance and small footprint in mind. Making the deserializer more forgiving doesn’t immediately look like a big deal (I just dug through that code for a bit), but as Coen said, this might have hard to track side effects that may or may not be worth the tradeoff.
Also, Napkin uses NAP’s de/serializer and object structure, so its rules are practically as strict as the runtime.
But let’s consider:
We’d have to introduce one or more ‘Unknown’ types (UnknownResource, UnknownComponent, etc?) so we can display dummy objects, this should be fairly trivial.
Keep in mind: as it stands, after deserialization, the json data is discarded and any association between the file data and the loaded object structure is lost.
Existing pointers to the broken object can only be kept as long as the pointer type constraint is not too narrow. Eg. nap::Component is fine, but we can’t reasonably handle user types, so after saving such a project file, links to the previously broken object will be lost.
Properties cannot be deserialized as the object’s structure is not known. So its data will be lost, even when we restore the type using the editor somehow.
So then we’re left with no option other than to display the broken object and allow the user to delete it or replace it with the correct type without being able to restore its old data.
Alternatively, Napkin could offer the user to select the correct type prior to loading, patch the json and then load it again (correctly). I feel this is a hacky solution though.
I’m not sure, but in the light of renaming custom C++ resources/components, I think it’s only reasonable to have some way of also refactoring your existing references to that type in your json files.