Napkin fails to open project after renaming resource


After renaming a resource type that is being used in the current project, napkin fails to open the project with the following error:
“Unknown object type [old type name here] encountered.”

I have to open the app_structure in a text editor and remove or rename the resource manually in order to be able to open the project again.

I think the preferred behaviour would be for Napkin to still open, but mark the unknown object type as invalid (by displaying it in red for example).


This is a good suggestion but could have many (code) design implications. For example, what happens with resolving paths when the type is not known to the system? And does the editor allow you to continue editing the file when types are missing / unresolved? Game editors allow this, resulting in crashes and half initialized scenes. I feel this needs more thought in order to implement correctly. Any ideas @bas. I currently prefer the hard: ‘I can’t resolve this type so no’ approach.


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.