[George] In what order should I parse the XML files?

[pixelfck]

(Finally found some time to look at this again.)

A <Library> statement is a reference to a library, not an include directive (like a module).

The core engine keeps a list of all extensions (libraries, adventures, whatever) by UNID. When it sees a <Library> reference it just looks up the extension, makes sure it's loaded, and then pulls the list of entities. We never have to parse a library twice.

That's interesting.

Is this behaviour exclusive to libaries? or are adventures and extensions also only loaded/parsed upon first encounter?

~Pixelfck

[george moromisato]

Is this behaviour exclusive to libaries? or are adventures and extensions also only loaded/parsed upon first encounter?

We do this for all extensions. Basically, the process works like this:

1. We keep a table indexed by UNID, and pointing to an allocated structure which contains (a) the ENTITIES table defined by that extension, (b) all of the types defined by that extension, (c) the list of libraries we directly reference.

2. We load extensions recursively. If we see a library reference, we check the table above first. If it's not found, we load it and add it to the table. Once we have the library, we get its ENTITIES table and link it to our load process.

3. When we start (or load) a game, we go through a "bind" process. Binding determines exactly which types are defined for the game.

4. To bind, we generate an ordered list of extensions for the game. We start with the adventure. All expansions selected by the user are added AFTER the adventure in the ordered list. All required libraries are added BEFORE the adventure (in the order required). [Any unused libraries or expansions are not on the list.]

5. We process the list in order, adding all the types that we find in each extension. Because we proceed in a well-defined order, we can always (predictably) override a type.

6. At bind-time we also deal with dynamic types.