Talk:Dark Omen Wiki

From Dark Omen Wiki

Namespaces

How do we add namespaces to the wiki? I tried to add a "dict" (dictionary) namespace by simply prepending "dict:" to some articles I made but that made no difference (though on second thought it should be called "ref" (for "reference") instead). I was thinking of having the related information under the "ref" reference namespace, and WARTBED articles under a "wartbed" namespace, but I have no idea how to implement this. Mikademus 14:06, 21 February 2009 (UTC)

Some old discussion about something??

---

To take all of those picutres of the Dark Omen Maps, I used the NewBoids engine.

It was made by Andy Buchanan (Original Dark Omen Programmer) and he includes his C++ Source Code, if it could help us in any way.

Although it is only a viewer not an Editor but it can tell us the information contained in a Map.

I can also overwrite his M3D files with Dark Omen M3D files, such as the houses or the 3D animated Heads and replace the skins/images with Dark Omen Textures.

http://home.clara.net/obi/oldprograms.html

)

Mikademus replies:-

Yes, I have used that source code. However, a Dark Omen battle is defined in the .PRJ files. They consist of 11 sections, of which his source only covers four (the BASE mesh (the surface), the WATR mesh (water), FURN files (uxtra 3D objects placed on the map) and INST (the instances of the objects)). That is, they can load and draw the map, however, the two largest sections of the project file are the TERR (presumable "terrain") and ATTR ("attributes"?) blocks (and four others), and we have no info about them.

My assumption atm is that the TERR block contains surface abstractions for pathfinding, elevation, traversability and difficulty, among other things.

Also, the ATTR block seems critical, but that is even more difficult to map.

Conventions and definitions: “Byte” signifies a 1-byte (8-bit) integer “Long” signifies a Big-endian 4-byte (32-bit) integer (i.e. stored as “n¤¤¤”) “Array” denotes a literal sequence of characters “String” denotes a sequence of characters ended with a NULL (0x00) “¤” signifies a NULL (0x00) “·” signifies a space (0x20)

�1. The .PRJ Battle Project File Layout 1. Project file general layout

Section Notes 1 “Dark·Omen·Battle·file·1.10······” 32-byte file ID header 2 “BASE”-block Map socket base and terrain block 3 “WATR”-block Water mesh block 4 “FURN”-block Meshes used (“furniture”) block 5 “INST”-block Furniture instances block 6 “TERR”-block Terrain data entries block 7 “ATTR”-block Block - Terrain attributes? 8 “EXCL”-block Block - Exclusions??? 9 “MUSC”-block Block - Music? 10 “TRAC”-block Block -??? 11 “EDIT”-block Block -???

�2. Data layout of subsections.

General block layout

Offset Size Type Description 0 4 Array Data block type identifier (“ID”) 4 4 Long Size of data block (“BSIZE”, never less than 1) 8 BSIZE … Block data

ID is one of these 4-character literals

“BASE” – Map socket (“base”, map cut-away edges) “WATR” – Waterline? “FURN” – 3D object on map (“Furniture”) “INST” - ?? “TERR” - ?? Terrain data ?? ATTR EXCL MUSC TRAC EDIT

2.1 ID “BASE” block data layout The BASE block layout is minimal with only a string as data. The “base” in a Dark Omen map is the terrain and the socket surrounding it. These are saved in two separate flies with identical names but different extensions.

Offset Size Type Description 0 4 “BASE” Base data block identifier 4 4 Long Size of data block (“BSIZE”, never less than 1) 8 BSIZE String Filename of socket mesh (generally “base.m3d”)

The socket has the filename as written in the data (“base.m3d”), while the terrain filename is obtained by replacing the extension with “m3x” (“base.m3x”). 2.2 ID: “WATR” block data layout

Offset Size Type Description 0 4 “WATR” Water mesh data block identifier 4 4 Long Size of data block (“BSIZE”, never less than 1) 8 BSIZE String Filename of water mesh

2.3 ID: “FURN” block data layout The “FURN” (probably “FURNiture”) block contains the file name of all 3D models used in the scene. These models are then referenced by number (1-based, where “0” indicated NO model is used) in INST entries (next section).

Offset Size Type Description 0 4 “FURN” Water mesh data block identifier 4 4 Long Size of data block less 4×F 8 4 Long Number of furniture objects (“F”) 12 BSIZE Spec. List of filenames of furniture for map

Offset

Size Type Description

0

4 Long Size of string data

4

String size String Filename of furniture object

Repeat F times

Notice that the BSIZE element of the FURN block is off by 4 * F bytes. The block size was calculated using only the length of the strings, and the size of the string length element was omitted.

2.4 ID: “INST” block data layout The INST (probably “INSTances”) block details the objects to be instantiated in the scene and their attributes. Instantiated scene entities seems to be called “furniture” in the Dark Omen source code.

Offset Size Type Description 0 4 “INST” Furniture instances data block identifier 4 4 Long Size of data block (“BSIZE”, never less than 1) 8 4 Long Number of furniture object instances (“I”) 12 4 Long Size of each furniture instance (“FSIZE”, always 152) I×FSIZE bytes: “Furniture” composite data records. See separate description below.

Furniture record layout and description The furniture record seems to contain a mixture of data of relevance for game as well as of relevance only for a graphical level editor.

Notes: The position, orientation and extents vector items have been transformed into and stored as longs. To obtain the float values, divide each element in orientation by 4096.0f⁄2∏, and each element in the other vectors by 1024.0f. The mesh_slot and dead_mesh_slot items refer to the filename specified in the FURN block, but “1” indicated the first model and “0” signifies that NO mesh is used.

1. Offset Size Type Description

0 0 4 long ID_prev; //void * 1 4 4 long ID_next; //void * 2 8 4 long selected; 3 12 4 long exclude_from_terrain; 4‑6 16 12 long[3] Position (stored as longs: divide each element by 1024.0f) 7‑9 28 12 long[3] Orientation (stored as longs: divide each element by 4096.0f⁄2∏) 10‑12 40 12 long[3] Min extent (stored as longs: divide each element by 1024.0f) 13‑15 52 12 long[3] Max extent (stored as longs: divide each element by 1024.0f) 16 64 4 long mesh_slot; // used to store a mesh slot number in the SAVED project 17 68 4 long Mesh *pMesh; //long ID_mesh; //void * 18 72 4 long make_attackable; 19 76 4 long toughness; // used if the furniture is to be attackable 20 80 4 long wounds; 21 84 4 long Padding 22 88 4 long owner_unit_index; 23 92 4 long is_burning; 24 96 4 long SFX_code; 25 100 4 long GFX_code; 26 104 4 long is_locked; // cannot be dragged while locked 27 108 4 long exclude_from_terrain_shadow; 28 112 4 long exclude_from_walk; 29 116 4 long magic_item_code; 30 120 4 long particle_effect_code; 31 124 4 long dead_mesh_slot; // used to store a mesh slot number in the SAVED project 32 128 4 long Mesh *pDeadMesh; //long dead_mesh; //void * 33 132 4 long light; 34 136 4 long light_radius; 35 140 4 long light_ambient; 36 144 4 long Padding 37 148 4 long Padding

2.5 ID: “TERR” data block layout

Offset Size Type Description 0 4 “TERR” TERR (terrain?) data block identifier 4 4 Long Size of data block (“BSIZE”, never less than 1) 8 4 Long Number of TERR data entries (“T”) 12 4 Long Size of each TERR data entry (“TSIZE”, always 200?) T×TSIZE bytes: composite data records. See separate description below.

TERR Data record format not yet mapped!

2.6 ID: “ATTR” block data layout

“Rob” from http://darkomenworld.freeforums.org/looking-at-the-data-files-t33-15.html I figured out a bit of the ATTR block:

ATTR { char[4] 'ATTR' long BLOCK_SIZE long WIDTH_OF_MAP long HEIGHT_OF_MAP }

Then follows (width*height/2) bytes. Each tile has 4 bits of attributes and these are packed 2 to a byte.

Then there are 64 bytes, of which I can't make out much.

It looks like this is line-of-sight / accessibility information. attributes are 0 for 'ordinary' tiles, 2 for blocked ( i.e. unit can't move there ), 8 for passable water (such as fords), 10 (8|2) for impassible water.

There are probably more attribute values, its just a matter of looking at all the maps. I made a program which spits out the data as a bitmap, so I can just compare to the minimaps.

2. The M3D 3D Object File Layout

General layout

0 24 File header 24 96 * n Texture description Sub-object description

File header:

0 4 Long File ID 4 4 Long Magic 8 4 Long Version 12 4 Long CRC 16 4 Long NOT CRC 20 2 Short # textures 22 2 Short # sub-objects

Texture description entry

0 64 Char[64] Filepath (ignored) 64 32 Char[32] Texture filename

3D Sub-object Description

char name[32]; // object name short parent; // parent index M3DPOINT pivot; // origin for heirarchy short vertices; // number of verts. short faces; // number of faces long flags; long spare1; long spare2;

Geometry Geometry header List of faces List of vertices

i//////////////////|||||||||||||||||||¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦i¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦||||||||||\\\\\\\\i

UPDATE

Rob Replies:-

I figured out a bit of the ATTR block:

ATTR { char[4] 'ATTR' long BLOCK_SIZE long WIDTH_OF_MAP long HEIGHT_OF_MAP }

Then follows (width*height/2) bytes. Each tile has 4 bits of attributes and these are packed 2 to a byte.

Then there are 64 bytes, of which I can't make out much.

It looks like this is line-of-sight / accessibility information. attributes are 0 for 'ordinary' tiles, 2 for blocked ( i.e. unit can't move there ), 8 for passable water (such as fords), 10 (8|2) for impassible water.

There are probably more attribute values, its just a matter of looking at all the maps. I made a program which spits out the data as a bitmap, so I can just compare to the minimaps.

Back to top

Mikademus responds:-

Excellent work. And good, solidly testable hypotheses. Have you already tried changing these values to see what happens in the game?

Olly and Community respond:- Thank You Both :)

i////////////||||||||||||¦¦¦¦¦¦¦¦¦¦¦¦¦i¦¦¦¦¦¦¦¦¦¦¦¦¦||||||||||\\\\\\\\\\\\\\\\\\\\\\\\\\\\i

New Chapter

by Mikademus...he is explaining to me how binary attributes are mapped to filenames.

"You might have noiticed that all the .M3D files have strange filenames, like "_7WATER.M3D"

the underscore indicates that the next character is a gfx effect directive Most water is "_7", there is one battle which water is "_6"

I'd like you to take a look at filenames. See this (from my source)]

code:

// Render flags for a model are provided, believe it or not, in // the model's filename. If the leading character is an underline // then the following is a hash for a binary attribute map where // // 00000 ( 0) = no flags // 00001 ( 1) = translucency // 00010 ( 2) = animate texture UV coordinates // 00100 ( 4) = transparency // 10000 (16) = *unknown* // // The hash depends on character // // '0'..'9': flag |= char - 48 (==> 0 .. 9) // 'A'..'Z': flag |= char - 55 (==> 10 .. 35) // 'a'..'z': flag |= char - 87 (==> 10 .. 35) // // The most common filename prefixes (actually, the only ones // present in Dark Omen) are: // // "_4": 00000100 (transparency) // "_6": 00000110 (transparecy and animated texture coordinates) // "_7": 00000111 (transparency, animated texture coordinates, and transparency) // "_K": 00010100 (transparency and unknown effect)

I don't know what the dec16 (bin10000) toggle does

I also don't really know the difference between "translucency" and "transparency", as they use the words in Dark Omen.

//////////////////////////////////////////////////////////////////////////////////////

Could you rename some files and see if you figure out what effect it toggles?"

(So I have started to use the Dark Omen Map Viewer to see the effects it has when I rename the Water files)

This is B2_07 and its _6WATER.M3D

This is B2_07 but with it re-named as _7WATER.M3D and the other file _6WATER.M3X renamed to _7WATER.M3X

and finally this is renaming to _KWater

The results can't be seen in these pics but _K actually stop the water flowing.

// "_K": 00010100 (transparency and unknown effect)

unknown effect = Stops animation of water flowing

Ok, final piece here]

After 9 they use letters, so A is 10, B is 11 and so on.

Thus

"_A" --> 01010 (== dec 10) "_B" --> 01011 (== dec 12) "_C" --> 01010 (== dec 13) and dec 16 == 010000

so _K == 20 == 00010100 == the unknown at pos 16, and transparancy at pos 4

So working on this priciple, under the Guidance of Mikademus (many thanks) I then replaced all _4 with _K and vice a versa, on the First Mission

It effected the Trees

Now i renamed all M3D files to begin with _M and this is the result on the first mission.

The closest tree has moving textures.

"Ah, only one tree was animated? That explains why all water is contained in

a single mesh. It would indicate that the UV coordinates of one instance only of the same model is updated, or something Again, a strange limitation of the format/system"

Now we know how the 16-value bit works, and we understand texture coordinate animation a bit better, but the difference betwteen transparency and translucency is still unknown

Now with renaming with _6 all the M3D files.

it created Black under the Tree's Branches.

A change from K to 6 turned off the colour keying

My Next mission will be to start up my 2 old Win98 pcs with Nvidia Geforce2mx 32mb and FX5200 128mb pci cards and play Dark Omen in glorious 3D, to test the difference between "translucency" and "transparency", as they use the words in Dark Omen.

(I think Darkmancer plays in 3D on XP)