Taking a Chiso Preniv book creates a junk personal instance of Chiso Preniv

[dgelessus]

When an avatar collects a Chiso Preniv book in the Watcher's Pub, this triggers the xRegisterAge.py script to give the avatar a link to Chiso Preniv. That link doesn't point to the public instance of Chiso Preniv though - rather, xRegisterAge.py creates a new personal instance of Chiso Preniv owned by the avatar. This seems wrong - Chiso Preniv isn't supposed to have personal instances.

As far as I can tell, this has no negative effect on gameplay. Even though every avatar's owned Chiso Preniv link now points to a personal instance, the Relto bookshelf links to the correct public instance anyway, thanks to a special case in psnlBookshelf.py (see kHardcodedInstances). We just have a bunch of dead Chiso Preniv instances in our vaults now, which is never nice.

To fix this, I assume xRegisterAge.py needs to set the correct age instance UUID when adding the link. Currently it leaves the UUID unset, so the server generates a random UUID and creates a new instance with that. xRegisterAge.py probably needs a new attribute for the UUID - sadly this means we have to touch GreatTreePub and configure the UUID there. (We could instead look up the UUID in xRegisterAge.py, but that doesn't seem like a great solution.)

[Hoikas]

This is probably similar to city. Everyone has a copy of city, but there is a special case in the engine itself to avoid adding owners to the city vault, which would cause bad slowdowns on Cyan's legacy shard (ala "Hell Hood"). With that in mind, it might be better to just content ourselves with the junk personal instance.

[dgelessus]

Hmm, you're probably right that it would make everyone an owner of the public Chiso Preniv instance (with all the associated slowdowns), at least assuming we use the standard "register owned age" logic. That seems to be a purely client-side thing though, so we could create the Chiso link some other way that doesn't blow up the public Chiso Preniv vault tree. Of course, the question is whether implementing this is worth the effort.

[Hazado]

I designed it this way so that future ages could be added and registered to the vault correctly.

If we are so inclined, it could be changed to use an sdl instead.

Would mean additional sdl changes to personal age