Napkin save behavior


#1

Hi,

This is just me sharing my experiences after having worked with Napkin for a while and after merging the app structure of Aura and the 4D engine.

Whenever Napkin is used to modify the app structure’s json file, it writes out all members known to rtti. While somewhat useful as a form of documentation inside the json of all the available properties for editing, there are a few problems with this,

  • It pollutes the json file. I see a lot of “ClipRect” entries for instance, in which I have zero interest of editing and being aware of,

  • It makes versioning more difficult. Since there is no distinction between properties left to their default, initial values or properties that were explicitly set to something else, it makes changing/upgrading property defaults more impossible. This is also a feature I guess, but can also come back to bite you’re setting up an archive of json data (as 4D probably will in the future),

  • It writes out auto-generated instance IDs for components. This is annoying when copy-pasting stuff from one app structure to another, as I had to do when merging the 4D engine’s app structure (for its resources) with Aura. There were A LOT of duplicate component IDs which I had to resolve manually. None of the IDs were actually set explicitly because they are used within the app, so the experience would’ve been much easier had they not been serialized. It would be nice if auto-generated IDs weren’t serialized by Napkin when saving.

  • Marcel


#2

For Napkin it’s difficult to know if something is a default or an edited value. Although from json objects can be loaded that have a default this is currently not supported by Napkin, I understand this is annoying but not something we can fix immediately, unless at some point we can diff on write if the value has changed from it’s default. @bas can maybe comment on this.

Regarding the ID of an object, NAP assumes that every object has a unique ID, it therefore generates one for you. You can change the ID using Napkin or in the json file itself. Simply omitting the id is not allowed, because it would mean that:

  • There is no way of retrieving the object at runtime
  • There is no way to resolve links between objects on load

Also, have you ever tried merging two distinct applications, say a game, into one? Being able to copy paste nap app resource files together is useful, but yes, you will have to resolve id’s. Try to give your objects distinct names, which will limit naming conflicts in the future.


#3

Yes, now that you mention it. I have merged entire triple-a games! Ohhhhhhhh the fun (and the horrors) of working at a game porting company. :scream: I avoided ever having to merge visual node graphs though. It’s the stuff of nightmares to ‘merge’ those.

Try to give your objects distinct names, which will limit naming conflicts in the future.

This is not really possible when the code comes from an external source or when you work in a team unaware of these issues.

I would prefer Napkin to write out random IDs or unique hash codes or something than the pretty names it currently produces. The component’s type name followed by a sequential number maximizes the odds of collisions.

You probably considered this, but… Another way to avoid collisions would be to use only fully qualified path names internally, so EntityX.ComponentY. Is there a design philosophy behind using a flat namespace for component/resource IDs?


#4

The resource manager considers every object in json as a unique resource, which is a design decision we made last year to get everything up and running within the scheduled time frame. Internally we do use object paths to resolve paths to resources, but this is a runtime construct only. Also, unique names make instance property overrides possible. Support for this in Napkin is coming soon.

Regarding names, maybe the generation of the id could be based on the name of the object in combination with a random number. This should limit collisions considerably and shouldn’t take much time.


#5

It’s easy to glue a UUID to every Object’s name in Napkin, but it’s going to look a little dirty.
Of course we can hide this prefix/suffix from the UI to still show nice names with out the UUID.

But that in turn raises another issue when creating pointers to objects that have similar names (point to Entity34A4BC23 or Entity344ABC23?),
although that might not be an issue because you’d probably want to sensibly name your resources anyway.

I’m okay with just appending a short UUID (8 characters?) to every newly created object for now to resolve the issue at hand.

What do you think?


#6

Heya,

UUID sounds good, the components that are of interest should be renamed anyway, at least that’s what I do always.


#7

I agree. For the resources I refer to I always rename them to something sensible.


#8

I’ve added this to the bugtracker