I'm fiddling around with my first library.

Just to make sure I've got it straight:

• Do not add an attribute to the game object (or any other object which exists in the main game file).
• Do not add an object with which you wish to interact.
• Do not attempt to add anything into a default script. (I.e., don't write a start script section into it. It will not add to the section. It will create a duplicate section and the game will not load.)

Correct.

Basically anything in the library with the same name as something in the main game will get over-ridden.

Groovy!

I just wrote a CSSLib for the game I'm currently creating.

I embedded a customized Base64 font in it, and you can switch the fonts back and forth in scripts using SetWebFont.

All I need to do in the editor is add the library and add the line in the start script. (Unless there's something easier that I overlooked while scouring all the documentation you've posted here and on GitHub. (Are you in BEAST MODE around the clock? Or do just wear your keyboard out in short spurts?))

I'm loving Quest! (And I probably only know how to do 1% of what it's capable of!)

Thanks, Pixie!

Pixie's guides handle how to use libraries and about them, but here's my own "2 cents" on them:

http://textadventures.co.uk/forum/quest/topic/9wbwdivscuuhiq8q-durng/error-running-script-object-reference-not-set-to-an-instance-of-an-object-solv#73c2c102-ea1d-49b6-a599-9a54a1073360 (after clicking on the link, you may also want to look at my post above my post that the link will take you to)

and a little extra explanation...

there's no difference between these below at all (they're the same thing)

I'm using a 'dragon' Object as the example, but it can be any other Element too (Functions, Verbs, Commands, Turnscripts, Timers, Object Types / Types, etc etc etc) and as much as you want as well. Libraries are just (separated/encapulated/compartmentalized out/apart from your game file --- nice for your organization and sanity for developing big games: you can use a library file for having all the code/content for each main area of your game, a library file for equipment, a library file for your magic, etc library files for handling the various aspects/systems/features/mechanics of your game. Basically, library files act as additional folders for your game code, instead of having your entire game code within your game file) code/content that is used by your game file (along with the code/content within your game file too) for when you play your game, including code that makes up the user-level quest engine for your game making and/or game (the default engine for english speakers is the 'English.aslx' library file and the 'Core.aslx' library file, haven't looked at the 'english.aslx' file if it's a hub to individual liibrary files like the 'core.aslx' library file is (if you actually look in the quest program folder, you can take a look at these library files to see how the user-level default quest engine works --- though don't mess with them and save over them if you don't know what you're doing --- or else you'll have to download quest again --- use the GUI/Editor as it forces you to 'copy' so you're not actually messing up these quest engine files' and their built-in code/content for quest, so you can create your own user-level engine for quest/game-making and your games!)

example_game_file.aslx, its code is below:

<asl version="550">
  <include ref="English.aslx" />
  <include ref="Core.aslx" />
  <game name="example_game">
    // blah Attributes
  </game>
  <object name="room">
    <inherit name="editor_room" />
    <object name="player">
      <inherit name="editor_object" />
      <inherit name="editor_player" />
    </object>
  </object>

  <object name="dragon">
    <attr name="parent" type="object">room</attr>
  </object>

</asl>

---------------------- AND / VS ---------------------------

example_game_file.aslx, its code is below:

<asl version="550">
  <include ref="English.aslx" />
  <include ref="Core.aslx" />

  <include ref="example_library_file.aslx" />

  <game name="example_game">
    // blah Attributes
  </game>
  <object name="room">
    <inherit name="editor_room" />
    <object name="player">
      <inherit name="editor_object" />
      <inherit name="editor_player" />
    </object>
  </object>
</asl>

plus...
example_library_file.aslx, (and it is in/at the same location as your game file, so quest/your-game-file can find/use it), its code is below:

<library>
  <object name="dragon">
    <attr name="parent" type="object">room</attr>
  </object>
</library>

Aha!

I couldn't interact with the object that was in my library because I didn't assign it a parent room! (Slaps self in forehead.)

don't mess with them and save over them if you don't know what you're doing --- or else you'll have to download quest again

Listen to HK, kids! He speaks the truth!

use the GUI/Editor as it forces you to 'copy'

This feature is the bee's knees!

the built-in 'parent' Object (reference/pointer) Attribute is what actually controls/determines the containment/child-parent heirarchy.

when you use the the helper Function (which is provided/used by the GUI/Editor's script options: add new script): MoveObject (NAME_OF_MOVING_OBJECT , NAME_OF_DESTINATION_OBJECT), it's just setting the 'parent' (reference/pointer) Object Attribute for you, hidden underneath (aka, done by) it:

NAME_OF_MOVING_OBJECT.parent = NAME_OF_DESTINATION_OBJECT

also directly nesting it in code is another way of doing it (its all the same thing):

<object name="NAME_OF_DESTINATION_OBJECT">
  <object name="NAME_OF_MOVING_OBJECT">
  </object>
</object>

containment/child-parent heirarchy:

grandfather
-> father
->-> son
->->-> grandson

as code scripting:

grandfather.parent = null // (actually/technically it's the 'asl' GAME OBJECT)
father.parent = grandfather
son.parent = father
grandson.parent = son

as code creation tag blocks/lines:

// the special 'asl' OBJECT/Element is the GAME OBJECT, it is your root parent, everything (all code) must be contained within the 'asl' OBJECT/Element

// Quest's 'Elements' are the user-level's OBJECTS of OOP/OOD (Object-Oriented Programming/Design) of its underneath engine/quest-sotware coding. Not to be confused with the sub 'Object' Element/OBJECT. I use 'OBJECT' for the underlying coding, and 'Object' for the 'Object' sub OBJECT/Elements. Ach I think I made it more confusing...

// let me try this instead:

(underlying quest software level coding)OBJECTS/CLASSES/DATA_TYPES (quest calls them as 'Elements'):
-> the types of Elements (user-level coding):
-> Objects
-> Functions
-> Verbs
-> Commands
-> Turnscripts
-> Timers
-> Object Types / Types
-> JS
-> etc etc etc

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

// using nesting:

<asl version="###">
  <object name="grandfather">
    <attr name="parent" type="object">null</attr> // quest doesn't show it when its null (asl)
    <object name="father">
      <attr name="parent" type="object">grandfather</attr> // quest doesn't show it when its nested
      <object name="son">
        <attr name="parent" type="object">father</attr> // quest doesn't show it when its nested
        <object name="grandson">
          <attr name="parent" type="object">son</attr> // quest doesn't show it when its nested
        </object>
      </object>
    </object>
  </object>
</asl>

// using the 'parent' Object (reference/pointer) Attribute:

<asl version="###">
  <object name="grandfather">
    <attr name="parent" type="object">null</attr> // quest doesn't show it when its null (asl)
  </object>
  <object name="father">
    <attr name="parent" type="object">grandfather</attr>
  </object>
  <object name="son">
    <attr name="parent" type="object">father</attr>
  </object>
  <object name="grandson">
    <attr name="parent" type="object">son</attr>
  </object>
</asl>

grandather is the root (main) parent of father, son, and grandson
grandfather is the direct parent of father
grandfather is the indirect parent of son and grandson

father is the direct child of grandfather
father is the direct parent of son
father is the indirect parent of grandson

son is the indirect child of grandfather
son is the direct child of father
son is the direct parent of grandson

grandson is the direct child of son
grandson is the indirect child of grandfather and father

grandson.parent = null
son.parent = grandson
father.parent = son
grandfather.parent = father

grandson
-> son
->-> father
->->-> grandfather

grandson.parent = grandfather
son.parent = father
father.parent = null
grandfather.parent = father

father
-> son
-> grandfather
->-> grandson

etc etc etc combinations....