This document is based on the experience I made while working with the managlore database files (.db3) needed for a level configuration. It was written as a short summary without being complete or eventually not being completely correct.
For a level in mangalore you will need to export something to display, Entities will be exported one by one (already known from nebula 2 as .n2 files). They are only referenced in the mangalore db file for further use and enriched by several other files for certain purpose for which I will give a short overview first.
Files and directories used
The following paths are relative to your development directory. For XML files please keep in mind that the files are parsed line by line, so saving an XML file as a character stream as some tools (open office has an option somewhere) do will break them for mangalore. The files you need for a level besided the world.db3 are (as far as I have used them or know something about):
The definitions of your entities are stored here (which property is used on which entity type) thus influencing which attributes/columns will be used on your entity and stored in the _entities table in the world.db3 file. The file is readable with a notepad as it is normal xml.
Not used so far by me. The file contains animation information, you should enter the level amations (perhaps for elevators uand such?) here. The file is an ms office xls sheet in xml format, readable with open office (if you remove the cell checks entries)
This file contains a listing of sounds used in your game. The file is an ms office xls sheet in xml format, readable with open office (if you remove the cell checks entries)
In my opinion all the files above are bulllshit and should be moved inside the .db3 as database tables. This would need some refactoring for the access classes but it would be more consistent to have all configuration in your database and not have one configuration no matter how many .db3 files you have :-(
In mangalore it is important that all path entries referenced from the db file are made up of a directory and a file entry (e.g. examples/myn2file), the loader uses the directory entry to group the files into catgories. The file entries in the orld database are normally omitting the file ending. So when you export your game assets you should always place them in a subdirectory, examples are following:
The animation sequences of your models are stored in this directory as .nanim2 files for example: examples\eagle.namin2 or myobject\my.nanim2
The standard .n2 load files are situated in this directory, they are used in the db file for model loading. The files must be in a subdirectory e.g examples\eagle.n2 or myobject1\my.n2
The nebula mesh definitions (.n3d2 or .nvx2) are inside this directory. The files need not to be placed in subdirectories (but it helps) as long as your .n2 file points to the correct mesh. The files herin are not referenced directly from the db.
In this directory the physics definitoins for your level entities are stored. Again the files must be in a subdirectory for example myobject1\myobject1_physics_representation.mxl. Physics definitions are xml files which are not really suited for manual editing if you have complex physics objects.
The nebula textures are found inside this directory. The files need not to be placed in subdirectories (but it helps) as long as your .n2 file points to the correct mesh. The files herin are not referenced directly from the db.
Normally only one world.db3 file exists (but your custom coded games could use several).
The file contains three tables per default:
_categories, _navigation, _entities
The .db3 world file
All entries regarding positionining are expressed in world coordinates. Thus all models should be exported around world center 0/0/0 or otherwise you will have to live with the offset beween local and world coords.
This table describes again the entities from blueprints.xml, I am not sure if this information is used or really needed anywhere in mangalore as the blueprints are parsed from the xml file on start.
I have not used this table so far, but guessing from the fields it is a simple listing of navmesh file and its position in the world (transform see _entities)
This is the table I use most. The important columns are _type, gui, _id, _level, _category, _transform, graphics, but that only could be my special case. Following is a description of the fields you find in the standard .db3 file. If you create your own properties new columns will be created when you are saving your entities and these propertiy attributes are configured as storable. Only writable attributes/columns get updated, these are only very few (like transform, etc.).
Stores if the entity is an INSTANCEor a TEMPLATE object. This is only neccessary if you are creating objects by code (createbytemplate). INSTANCE objekts are loaded as default for you level.
This column is a (hopefully) global unique id string, you could enter any bullshit as long as it remains unique as it seems sqlite does not support unique constraints.
A name string identifying your entity.
This entry defines to which level instance this entity row belongs as you could have several levels defined in your .db3 file
This entry is quite important as it determins which entity loader and entity template is to be used. Aktually the following categories exist: Actor, Simple, Light, Camera, .Level, _Environment
Actor is used for controllable entities, Simple for simple physical (optional) entities, Light for (guess) lights in your level, Camera for cameras as you can toggel between several cams in your level, .Level (please obey the dot) for level roots (one entry only per level) and finally _Environmentfor the static content (physics optional) in your level.
Importent column used for placement of entities in world coords in your level. Format is a4x4 matrix which means 8 floats comma separated analog to the normal nebula matrix used in code.
The string Point, Direct, Omni (or Ambient?)
rgba, 4 floats comma separated
range of light :-) one float
rgba (4 floats, comma separated) if row defines an Omni light empty otherwise.
true or false dependant upon the lightsource being used for creation of shadows or not
File containing an animation of the model, seems to be level animations, have nothing in common with the normal .n2 files (kyla for example has no entry but has animatin sequences) used for elevators, trains or similar.
String entry directory/filename_withoutn2ending from the export\gfxlib directory representing the graphics of the entity (mesh, tex, etc.)
Column center and extents
As far as I know this entry is only used for a .Level entry; center is the middle of the level, extents is the distance the level extends into x,y,z in world coordinates. Each one as 3 floats separated by spaces
Not really important, most of my levels run without this entry
Don't know what this is for
Column LE, AE, AT, PA
This already introduced the stats of the RPG game the dark eye (Das Schwarze Auge), not used by this code, columns can be deleted.
Another descriptive entry, ev. for ingame, but not really needed
Entry from anims.xml which model animations to use
Column inputfocus, camerafocus
true or false depending on the fact if the entity can have inputfocus or camerafocus makes only sense on actor or camera entites
Velocity of the entity, float
FOV value (camera viewport angle), float
Not really important for level creation, will be updated on save
That's it, hope it has shed some light on the what and where of the nebula/mangalore level file world.db3
Something missing? Mail to