[Warhammer Dark Omen Forum]

Warhammer Dark Omen Forum

Ever wondered how the lighting LIT file is created?
The tool is part of the engine!

Untested, no Dark Omen installed here but looks promising.
History: I found the array that contains the keyboard keycodes and then I found this function which reads numpad and other random keyboard keys, so this made me suspicious what it is.

Search in EngRel.exe for the byte sequence "33C0A3F4F04B00". Change the 33C0 to 9090.
Load a map. The lighting should be different, same as if the LIT file is missing.
Use all of the numpad, F, T, S, D, +, -, =, / (+, - and = try on both normal and num keyboard), LCTRL, RCTRL, Backspace, Numlock, Home, Insert,
Press Num-Enter to save the LIT file, you should see a chatmessage saying that the map was saved.

The save destionation is "j:\\paulb\\LiteEdit\\%s.lit". The path must exist, if you don't have a drive J: search this string and hex edit it to something you have (but don't make the path longer! Terminate with 0x00 byte). Only the %s is important.

I messed up the offset calculation.
Font height is determined in the header via:
Word @ Offset6 + Word @ Offset 8

Text width is calculated via: For every char in the text do:
Word @ Offset4 in the Header + Width from glyph info block + 1


More stuff just by looking at the file.
In the header:
The 0x1090 I mentioned earlier is in the header at offset 0xC.
Afterwards there are actually two color tables with 16 entries. You can see FF00FF00 twice. I guess one is for either "label disabled" or "label highlighted". Or a historic left over, seems to be two times the same but the code uses the 2nd color table.

Glyph info block:
I forgot that this is little endian byte order so the high byte is to the right.
Looking at this 16 byte per "glyph info" starting at 0x90 again you can see patterns:

Word at offset 12 (starting from 0) must be the offset in the pixel data. This number increments with each non-CD-glyph.

Proof: For MENBG the first value is 0x0 and last value is 0x56E0, with 0x1090 offset this gives 0x6770 which is almost the end of the file.

2 16bit-Values must be width and height. We know the offsets between the glyphs so this can be determined by trial and error:
E.g.:
0 to 10 is 16 width. Candidates are 1, 4, 3 and 8. 4 * 8 gives 32 and we have 4bit per color -> 16.
Same works for the other rows.
Result:
Word at offset 4 width.
Word at offset 8 height.
Word at offset 0 maybe enabled. For a few glyphs it is 2, but usually 0 when CD, otherwise 1.

Doesn't fully work for the last glyph:
There are 272 bytes left to file end but it takes 280. (bug in the file maybe)

That info should be enough to write scripts for handling these files.


Still unclear:
glyph info at offset 2: Maybe a bit field, could be partially determined by just unsetting bits and checking ingame what happens.
glyph info at offset 7: Must be width-related, usually equals width or width-1.
Header at offset A.

Some partial reversing of the font:
At 0x8 is the width of any glyph and if I didn't miscalculate there is an additional per glyph extra width at 0x9a + 16*charOrdinal.
I guess 0xA is the height.
From 0x50 contains 16 colors (4byte per color). The format is the same as in SPR (RGBA?).

Then my educated guess is that starting from "0x90" is some kind of glyph information block (16 byte per char). When you just scroll down until it starts to look "different" (at 0x1090) and you calculate the distance / 16 it gives: 256. So 256 chars, would make sense.

From 0x1090 I guess you have the pixel data. I suggest to just overwrite stuff after 0x1090 with FF and start the game and see what happens.
I would expect that unused glyphs do not require space in the pixel data (The first without CDCDCDCD in MENBG is '). So when you just overwrite like the first 100 byte starting from 0x1090 you should see a change in the apostroph ('). I suggest using F_MENBG.FNT, is the title screen font and simply hexedited e.g. "New Campaign" in EngRel to contain a '.

But I can't find the font rendering routine. ALso this 16 color stuff doesn't make complete sense as there is no value for "draw transparent" here (000000FF).

I have no idea why there is a patched EngRel.exe distributed instead of just adding the dgvoodoo code patches to the DLL.... o.O
The new version of the DLL applies now the patches.
Happy new year.

Needs hardware cursor (not crashing anymore, wow) enabled to fix flickering cursor issues when resolution is forced.

No idea how the Fon format looks but assuming it is a normal pixel font it should consist of the following attributes:
Is it a monospace font (all glyphs have same width?) in that case there is probably a glyph width/height in the header. When not monospace there must be the width per glyph somewhere.
A single glyph is likely encoded as a bitfield: Bit set - Pixel, Bit not set - Blank. Additionally I would expect a 8bit alignment (e.g. when the glyph width is 12 then you have 8 bit, 4 bit and 4 0-bit), then the next row (2 bytes) follows, etc.
I just tried this but in the visual output (black box for 1, nothing for 0) I see noting that represents text :/

[A) Increase var_xx up to 32 (or more)]

It's summer so I'm highly unmotivated but I like the ideas.

I kindly request the following features for WHMTG scripting

Right, new features for WHMTG scripting are also possible.

A) Increase var_xx up to 32 (or more)
It's currently maxed at 24 total, var_00 to var_23. Very easy to run out of vars in more advanced mods.

If you just use them for flags (0 or 1): You can store 32 flags in one variable (think binary, 1, 2, 4, 8, etc.) but there are no good function to handle bitflags.

Well extending them is possible, just have to relocate where it is stored in memory like I did to fix the multiplayer map list.

B) CaseSwitch for var_xx
I only tested var values up to 32 but this already leaves so many possible values that the simple var check

Code:

ReadVariable var_00 
IF == 0
<do this>
ENDIF
IF == 1
<do this>
ENDIF
and so on

This is complecated because this is a new code-flow feature in the WHMTG interpreter. Wasn't <= and >= also supported as operators?

C) Add/Sub value to/from var_xx
There is currently only SetVariable var_xx Y.
This means that to add a value, like 22+1, currently all possible values need to be checked first, to then set the var one greater/smaller.

That sounds easy

D) Unit deploy limit
PC default is 10, ps1 uses 8. Would be nice to have this flexible for certain battles.
I know its possible to do this with CTL script but it would be much better used here for easy modding.

The problem is that this will be incompatible with the current code because currently I reset the deployment limit when the battle begins loading.
Maybe I can move it to the battle end handler, then this problem is solved.

What I could also propose is a "Read WHMTG Variable" function which reads a WHMTG variable into a CTL global variable and then using this to set the deployment limit.

E) Remove x-gold with check for 0/overflow
Current max gold is 2^16-1, to subtract gold we have to add 2^16-1-"value to subtract".
There is no check for 0/overflow.
Would also be nice so that if gold is added over the cap it's to be "ignored", or lots of gold is lost.

Sounds good

F) Modify some basic unit stats
Would be nice if we could change current/max number, alive/dead, armour, stats M,WS,etc
For example SOTHR has a mission where units with armour below 3 get +1 armour

That's also a WHMTG feature I guess? Otherwise this would be chaos when possible in live battle

G) Add exp to unit

Well basicly the same as the feature before.

Don't add new units to the files in 1pbat.
The game expects a fixed size for this file and it will crash or not work. Same applies for savegames.

12 years of Dark Omen Fansite! (funded 5 Feb 2007)

Interestingly the following CTL commands are never used:

Code:

#24 add_global_r_i
#26 (called automatically each time the CTL script executes)
#27 (called when #26 set the true-flag)
#31 wait_unit_flag2_clear
#32 wait_unit_flag2_set
#37 wait_unit_flag3_set
#42 send_event_to_self_if_label_exists
#56
#57
#67
#68
#6f broadcast_event_to_enemies
#8a
#90 nop_90
#91 nop_91
#9a
#9e
#a0
#a4 find_enemy_simple
#a5 find_enemy_simple_visible
#a8 find_enemy_nth
#a9 find_enemy_nth_visble
#aa find_enemy_unittype_nth
#ab find_enemy_unittype_nth_2
#bb
#be
#c8
#c9 clear_last_event
#cb
#ec test_other_unit_r_eq_i
#f0

The following are only used in the tutorial (SPARE9):

Code:

#d9 test_user_action
#da ui_indicate
#db (this seems to check if you attack the training dummies)
#dc 
#dd set_unit_r_direction
#de test_unit_at_node
#df test_unit_attacking
#e1 test_other_unit_flag3
#e2 test_unit_selected
#e3 test_any_spell_selected
#e4
#e5
#e6 test_mapmode
#e8
#e9
#ea test_sound_playing
#eb test_other_unit_flag1
#ed end_mission
#ee test_event_from_unit

Which means the following used opcodes have unknown purpose:

Code:

#14
#2b
#3c
#45
#46
#47
#48
#49
#4a
#4b
#4d
#4f
#50
#51
#5e
#5f
#60
#61
#62
#63
#64
#66
#6c
#7a
#7b
#7c
#7d
#7e
#7f
#80
#81
#83
#84
#85
#87
#88
#89
#8b
#8c
#8e
#8f
#95
#96
#9b
#9c
#a1
#ad
#b0
#b1
#bc
#c5
#c6
#ca
#cc
#d6
#db
#dc
#e4
#e5
#e8
#e9
#ef

Unknown OpCodes by popularity (funcs >= 100 are only counted once because they are always the same):

This means these are useful for map scripting in general.

Code:

406 #14
374 #3c
252 #d6
157 #50
145 #2b
101 #48
 86 #47
 78 #43
 60 #7e
 59 #9b
 45 #51
 34 #89
 29 #64
 26 #80
 24 #87
 15 #7f
 10 #e8
 10 #a1
 10 #5e
  9 #62
  8 #dc
  7 #81
  6 #7d
  6 #46
(rest omited)

When counting including all funcs >= 100 in all maps (shows which unknown opcodes the standard library uses alot)

Code:

 990 #14
 813 #9b
 580 #2b
 536 #48
 461 #3c
 389 #50
 300 #5e
 282 #43
 270 #62
 252 #d6
 210 #81
 180 #7d
 180 #46
 176 #7e
 155 #a1
 150 #9c
 150 #8f
 150 #7a
 150 #6c
 150 #4d
 120 #ca
 120 #8e
 120 #8b
 120 #7b
  90 #c5
  90 #95
  90 #8c
  90 #60
  90 #4f
  90 #4a
  90 #49
  86 #47
  84 #80
  60 #bc
  60 #b0
  60 #ad
  60 #85
  60 #83
  60 #66
  60 #61
  60 #5f
  60 #4b
  60 #45
  45 #51
  34 #89
  30 #ef
  30 #cc
  30 #c6
  30 #b1
  30 #96
  30 #88
  30 #84
  30 #7c
  30 #63
  29 #64
  24 #87
  15 #7f
  10 #e8
   8 #ee
   8 #dc
   5 #db
   2 #e9
   2 #e5
   2 #e4

Also merry christmas from me!

I found a backup of old Dark Omen websites on one of my old harddisks and there is no reason to keep this for me: Download

- www.ovotech.com (The oldest known Dark Omen forum)
- darkomenworld.freeforums.org (This was basicly our rival, but in the end we are the only website that survived)
- lazydog (still online, an old DO website)
- warhammer.alfaspace.net (Russian DO website)

Most pages can be navigated by opening the index.html with your webbrowser.

To view the Dark Omen Ovotech forum use the index.html in www.ovotech.com/Forums/DarkOmen/

Some folders are likely not reachable by simple browsing, so go on treasure hunt!

Wow, a new mod? this is unexpected

Maybe this gives me a reason to play Dark Omen again next year

Also happy holidays to you!

Recently a friend got Ancestors Legacy, the game looked inspired by Total War & co. (but also some very casual base building).

It gets some stuff right, e.g. it has real line of sight, like Dark Omen and a concept of cover (in high grass...). Also night mode which reduces the line of sight, that's also well done. When you charge from the side or the rear you cause extra casualties.

When in Close combat other orders are ignored, thats also good.

There are also indicators for different unit states but they are not as obvious as in Dark Omen where you have this colored arrow (simple but good) instead you have complecated pictograms which have no tooltips, so I still don't know what some of them mean...

At least it has the concept of regiments with banners and formations but there are only 5 different types per nation and there are archers and balistas and even friendly fire by them.

But then the disadvantages start:

- This super useful showing of banners at the scren corner so you know the relative direction is missing.
- All infantry/cavalry units play the same, you usually just attack
- All characters are boring, you don't care about losing troops, death is not permanent. Dark Omen just has the best story telling.
- Usually the best strategy is just spamming as many units as you can have and doing close combat, no tactics needed because there is no reason as in Dark Omen to keep casualties low.
- There is a retreat option but it is never auto-invoked, they all fight until death.
- The archers have no button to hold fire when you give a manual shooting command, you must give a move order to stop them...
- The game runs too fast (or the line of sight is too short). Usually everything is just a mess because 5-10seconds after seeing the enemy close combat already starts, so the archers are in most cases useless because they are in CC before they can shoot twice...


Therefore I would call it "Dark Omen for Casuals". The basic concept is there but they stopped half-way to make it amazing :/.
Maybe I'm too skilled because of my DO-experience, my friend told me he already has problems on Easy and I rushed through the first missions on the highest difficult with no issues...


About the link to reddit:
I agree with this user, I found Total War battles really boring, I never had real tactic in there.
This game can be only so popular because not all know Dark Omen

Die deutsche Dark Omen Version wird nicht unterstützt. Die ganzen Texte sind fest in der EngRel.exe reinkodiert, daher wäre es ein Riesenaufwand, den Mod Selector mehrsprachig zu machen.

Du kannst aber die Deutsche Sprachausgabe bekommen, dazu musst du im Sound-Ordner SP_DEU nach SP_ENG umbenennen.

That darkpatch.dll won't work with the German version. You have to take the EngRel.exe provided in the mod package of which converts the game to English. But the sound samples should still be German, only the text will be English.

Do you also see entries of ".CUR" or ".ANI" files in "Dark Omen\Graphics\Cursors" redirected? FindFirstFile is usually part of the "Your DO install is incomplete" check.

Looks like Cursors are created with "LoadCursorFromFileA" and if this doesn't go indirectly through CreateFile or MapViewOfFile it's not redirected.

And looks like the cursors are only initialized on Dark Omen startup, so changing the mod would not change them back.

Actually I like that they aren't redirected because this is imo a user decision which kind of cursors they want.

Ah, thats a side effect of too many maps? Okay, because my test file contained 100 .
Good then I will know that I fixed it ^^

Should work now. I updated the "latest version" link in the 1st post of the topic.


https://github.com/Ghabry/Dark-Omen-Mod-Selector/commit/0ab78f307a240db003055328ee02863916a2561d