So, as the subject line states, this might be a stupid question, but I've only just started utilizing libraries and I was wondering if there were any sorts of limitations on how many could be included in one game. The reason I ask is that I'm working on a dialogue-heavy game and have made a library full of functions that get called when you talk to people, which is much nicer than having them all in the game file, but because of the volume of different characters and topics involved it would probably be easier to manage individual libraries for each character. Before I set all that up though, if I do, I just wanted to make sure that including a hundred or so libraries in one game (it's a bit of an ambitious game, I must say) wouldn't for some reason cause a problem, at least as far as anyone knows.

I can't give you an official answer, but I wanted to answer *something*. I don't think the <include> mechanism itself would have a limit, as it's just inserting your library text into the game. The only thing to be aware of is that it does track symbols, to know which library a function/object/whatever is in (e.g. if you change the filter on the bottom left to show library elements). I suppose it could cause a slowdown in the editor in such a case. I can't imagine it crashing or hitting a limit.

I can understand your desire to have a separate file for each character. I did the same myself. Just be sure you don't set a <parent> attribute on an character or object in one of the library files. Otherwise, when you save your game, Quest will pull a duplicate definition up into your main game file, which will then make it unloadable until you manually correct it. (Yes, I have run into this.) If you need to set parent rooms for your characters, do it in script.

Also note that you can include libraries inside libraries. I had a main Characters.aslx library that then included all of the character aslx library files.

Whoa...library-ception (topical!). Had not thought of that, but it does make sense. I'm still trying to wrap my head around the idea that types can inherit from other types, so that's another thing to add to the pile. As I've been getting my hands dirty with this game idea the last couple weeks have had some major Quest-related revelations for me.

I'm pretty sure I'm grasping the whole <parent> thing, but admittedly it's a little murky for me. I get the idea to not define an object's parent via attribute if it's in a library, though, so that's what counts. Presently I have all my character objects in the game file itself in a dummy room at the start since they'll be moved around from room to room throughout the game so I think I'm in the clear, but I might change that later since I'm still at a really early stage of development, so that'll be a good thing to keep in mind and might save me some hair-pulling down the road. Thanks for the reply!

another understanding for "Object Types" is a "group" (think of "baskets" of~holding~adding sub objects and~or attributes to the Object that the "group" ~ "Object Type" is attached~added on to)

<type></type> = the "type" tags are short for specifically an "Object Type"

if Object belongs to the "weapon_object_type" Group (Object Type), then said Object have these Attributes:

<type name="weapon_object_type">
-> <attr name="attack_rating" type="int">0</attr>
-> <attr name="physical_damage" type="int">0</attr>
-> <attr name="fire_damage" type="int">0</attr>
-> <attr name="water_damage" type="int">0</attr>
-> <attr name="earth_damage" type="int">0</attr>
-> <attr name="air_damage" type="int">0</attr>
</type>

if Object belongs to the "armor_object_type" Group (Object Type), then said Object have these Attributes:

<type name="armor_object_type">
-> <attr name="armor_class" type="int">0</attr>
-> <attr name="physical_defense" type="int">0</attr>
-> <attr name="fire_defense" type="int">0</attr>
-> <attr name="water_defense" type="int">0</attr>
-> <attr name="earth_defense" type="int">0</attr>
-> <attr name="air_defense" type="int">0</attr>
</type>

Computer (windows 7 OS):

("Object Types" ~ "Groups")

Organizational Unit (OU):
-> Administrators
->-> X
-> Users
->-> A
->-> B
-> Printing Operators
->-> C
-> IT Department
->-> D
->-> E
-> Financial Department
->-> F
-> Human Resources Department
->-> G
-> Etc
->-> Etc

------------------

if you need help understanding the concepts of "parent~child~nesting~indenting":

universe = (ROOT) parent object of all things below it
-> galaxy (milky way) = child object of "universe" and direct parent object of "star" and indirect parent of all things below it
->-> star (our sun) = direct child of "galaxy" and indirect child of "universe"
->->-> planet (earth) = .... get the idea now ???

planet.parent = star

and I can change ("move") the "planet" object to another object, the same way (only can set its direct~specific parent):

planet.parent = galaxy

universe
-> galaxy (milky way)
->-> star (our sun)
->-> planet (earth)

universe.parent=planet

galaxy (milky way)
-> star (our sun)
-> planet (earth)
->-> universe

---------

c:\\
-> programs
->-> quest

HK
-> HK's pants with pockets
->-> wallet
->->-> $1
->->-> $5