Image Adornment Not Replicated as part of a Prototype


(Tommy Mancino) #1

I have built a prototype that contains an image within its map. When I create a new instance of that prototype, the image does not copy. I predict I am missing a setting as I am sure this is intended behavior?

Tommy


(eastgate) #2

If a prototype has children (including adornments), and if that prototype is adopted by another note that doesn’t have children, then the prototype bequeathes clones of its children to the new instance. (This can be disabled by setting $PrototypeBequeathsChildren to false).

You’re right: if the child is an image adornment, the bequeathed clone lacks the image. I think that’s a mistake; a fairly unusual feature (image adornments) used in an unsual context (PrototypeBequeathsChildren). We’ll take a look.


(Tommy Mancino) #3

Thanks…should I be doing this a different way than an adornment image, is there another kind? My use case:

I have a note called Map, which contains an image (a game map) and pieces to the game as other notes. I was looking to be able to spawn other versions of the game via adding a prototype of the “Map” note.

I may be making this much harder :wink:


(Paul Walters) #4

That seems like a useful case – and I can see its applicability outside gaming. A writer or scenarist who uses images to define a world and wants to use a prototype that bequeaths image adornment clones as a starting point for new scenes. An economist using image adornments to display starting points for modeling different game-theoretical outcomes.

Very nice invention, @tmancino.


(eastgate) #5

Sure – this is a sensible scenario. For now, just replicate the image adornment in the new container; it’s not that much work!

If you wanted hundreds of these, that would mean the file would contain hundreds of copies of the image. That might be a bad thing. But you probably don’t need hundreds…