Mangalore Level-Db
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):
data\tables\blueprints.xml
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.
data\tables\anims.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)
data\tables\sounds.xml
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 :-(
export
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:
export\anims
The animation sequences of your models are stored in this directory as .nanim2 files for example: examples\eagle.namin2 or myobject\my.nanim2
export\gfxlib
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
export\meshes
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.
export\physics
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.
export\textures
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.
export\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.
Table _categories
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.
Table _navigation
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)
Table _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.).
Column _Type
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.
Column guid
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.
Column _id
A name string identifying your entity.
Column _level
This entry defines to which level instance this entity row belongs as you could have several levels defined in your .db3 file
Column _category
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.
Column transform
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.
Column lighttype
The string Point, Direct, Omni (or Ambient?)
Column lightcolor
rgba, 4 floats comma separated
Column lightrange
range of light :-) one float
Column lightambient
rgba (4 floats, comma separated) if row defines an Omni light empty otherwise.
Column lightcastshadows
true or false dependant upon the lightsource being used for creation of shadows or not
Column animpath
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.
Column graphics
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
Column id
Not really important, most of my levels run without this entry
Column placeholderDon'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.
Column name
Another descriptive entry, ev. for ingame, but not really needed
Column animset
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
Column maxvelocity
Velocity of the entity, float
Column fieldofview
FOV value (camera viewport angle), float
Column timeNot 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
|