For details please see:
http://quest.codeplex.com/workitem/1258

I discovered the same problem and was basically told, "Don't do that." (That, basically, libraries are meant for code and not meant to include additions to the overall room topology, which should all reside in the main aslx file - something which I disagree with as an overall organizational principle, and I still consider this a bug).

I resorted to setting the parent in code instead of in data.

jaynabonne wrote:I discovered the same problem and was basically told, "Don't do that." (That, basically, libraries are meant for code and not meant to include additions to the overall room topology, which should all reside in the main aslx file - something which I disagree with as an overall organizational principle, and I still consider this a bug).

I resorted to setting the parent in code instead of in data.

As I suspected.

What I wanted to do is to have a new type which player and NPCs can inherit from, and which would add some objects to them by default. Those objects should have handling logic in the library but it should be customizable in the editor for each character.

Since it is impossible to add objects to characters this way (due to Quest just copying the code over and worse yet, not displaying the object which is added in the editor), I am at a loss as to how to solve this problem.

I could programmatically add the objects to the character when they inherit from certain type (that would probably require that I add game start script which would do the actual object creation), but then I cannot customize individual characters from the editor because those dynamically created objects don't exist in the code. Worse yet, I don't know how to add a script to the object I just created, not to mention how tedious would it be to loop through all the objects and add several scripts to each one of them.

It turns out that the only solution is to create objects in the editor and then inherit them from the object type. When you have 10 characters going around and adding several objects per character and then inheriting those objects from their respective types is much more tedious and error prone compared to simply being able to make characters inherit from a type and have the objects added automatically.

Furthermore, there should be a way to say that an object is a part of player and not in the inventory so it can be visible without having to create a player as an open container with all the problems which arise from that such as listing those objects together with inventory items and saying that the player is containing them. Inform 7 has a way to define objects which are part of something and that is really a missing feature here.

If you are curious why would I need such a feature, I am trying to create anatomically correct player and NPCs.

So let me try to get my head around this a bit.

First off, if you haven't realized, you can't add nested objects directly to types. That may not apply here, but I wanted to mention it just in case.

Second, Quest only pulls things into the main aslx file if you assign a parent to an object which is already in the Quest main file. So, for instance, you can build entire object hierarchies in your libraries, and they won't encounter this bug as long as you don't try to set a parent to something in the main game file.

You don't have to resort to dynamically creating objects just to have runtime assignment. One possibility is to inherit from the type as you are creating, and have the main object have a *list* of objects to be added. Then there would be a single script in the type that would iterate over that list and then either assign or clone the objects onto the character.

If that doesn't apply, then let's discuss further.

Yes I am aware about the parent thing.

The problem with runtime creation is obviously the inability to create custom descriptions and actions for various characters and to work in the editor in general.

Another thing to watch is say if you create object "beard" (khm) on the player and then on another character, the other one will be called beard1 and so on. I have no idea how could I programmatically process them.

Finally, there is a matter of how those objects will be displayed. If they are children of the player they will be in their inventory. Showing them for any interaction (so you could "pull beard" for example) would require all players and NPCs to be open containers which is really ugly, not to mention mixing of things that should be part of an object with the inventory items.

I must admit that I am still trying to wrap my own head around the problem and the more I think, the more I believe the problem is that Quest has no "part of" semantics for objects but instead treats everything as the children, causing all sorts of handling and visibility problems.

If you want to discuss what I want to do in more details, we could continue via PM, or even better, email.

With respect to "beard", "beard1", etc., that implies that you're using the object internal name for display. Set the object alias to "beard" and it will be beard regardless of the object's name. If you have a prototype object with alias "beard" and you clone it, the clone will have display "beard" as well since that's what the alias will be as well (at least, it better be!).

For the rest, let me think a bit more.

There is a corresponding concept for room-level obejcts - scenery. These are objects that can be looked at, etc but which don't show up in the "Places and Objects" list. Unfortunately, that doesn't work for held objects.

I'd say that woud be useful feature to add to Quest - something similar to "scenery" but for "held" objects - perhaps "adornment" or "facet" or something.

jaynabonne wrote:There is a corresponding concept for room-level obejcts - scenery. These are objects that can be looked at, etc but which don't show up in the "Places and Objects" list. Unfortunately, that doesn't work for held objects.

I'd say that woud be useful feature to add to Quest - something similar to "scenery" but for "held" objects - perhaps "adornment" or "facet" or something.

But they are not exactly scenery -- there should be a way of interacting with them as well as and showing and hiding them too (for example "chest" could be hidden by "t-shirt").

Maybe they could stay in the inventory window, but be shown grouped right next to player and with different (configurable) color?

Also, current inventory could use some tree-like indentation to better differentiate to which object something belongs.