Formatted campaign modeldb files for all campaigns - Kingdoms & Vanilla 1.5

[Gigantus]

That's great stuff - I'll see if I can update my upload with this over the weekend, that way it won't get lost.

[Absolutex]

The log is completely blank after using Hex's patched files so there's still an issue somewhere, probably on my end.

[Gigantus]

Version Update

Version History

• 11th June 2015 - included the alternative formatter and checker as per Hex35's post

[Hexdragon]

Hi Gig

Thanks for taking time to check it.
As soon as I can, will post an update for FormatModelDBFile.py
The next one comes with a GUI and performs all the relevant line breaks.

Output files works well with the game (tested on Kingdom's British_Isles ModelDB file)
Yet, the syntax checker no longer handle the newest files.

The protoype tool will include option for generating output files that keep compatibility with the checker.

====

Here a few commented examples about the updated syntax, for the output ModelDB files
(comments based on both testing and collected in info from forums):
I know I am not "discovering the powder", but hope examples would be helpful.

We could clasify content among five types:

-Counter - "Characters in Line": Shown in Red
-Counter - "Lines below": Shown in Blue
-Counter - "Groups of Lines Below" : Shown in Orange
-Normal Data Line: Shown in Black
-Special Data Line: shown in Green

----
Normal datalines are always preceded by a "characters in line" counter and blank space
Normal datalines are always followed by a blank space

If a mandatory dataline is empty, the "characters in line" counter appears anyway (value zero) followed by its own blank space as weell as the line's final blank space
The infamous zero plus double space

====
Edit: May 15th, 2021
Group's size and structure is hardcoded:

Groups related to main figure textures are composed by 4 mandatory lines:
- Faction name
- Diff texture filepath
- Normal texture filepath
- Sprites filepath

Groups related to attachmentsets textures are composed by 4 mandatory lines (**)
(**) 4th mandatory dataline is empty. This is the first case of zero plus double space

Groups related to Mounts/Animations begins with 3 mandatory lines (**). Then two sub-groups follow.
(**) 2nd and/or 3rd mandatory datalines may be empty. This is the second case of zero plus double space
- Each sub-group begins with a "lines below" counter with value 0, 1 or 2.
- This pair of sub-groups is mandatory but one subgroup (or both) may have no datalines (when "lines below" counter = 0)
====

-Special datalines are not preceeded by "characters in line" counters
-Special datalines are always followed by a blank space
-The single number special data line is unknown for me (see update at the end of this post )
-The bottom special dataline is said to be related to the "Torch offset values":

From source linked below:
.... <Torch>
........ <Bone>bone_lhand</Bone>
........ <OffsetX>-0.09</OffsetX>
........ <OffsetY>0.0</OffsetY>
........ <OffsetZ>0.0</OffsetZ>
........ <WorldOffsetX>-0.35</WorldOffsetX>
........ <WorldOffsetY>0.8</WorldOffsetY>
........ <WorldOffsetZ>0.6</WorldOffsetZ>
.... </Torch>

Source: (ancient one )
http://forums.totalwar.org/vb/showth...syntax-checker
http://forums.totalwar.org/vb/showth...e-from-Caliban

(*) Note:
Bone Index Number for Left Hand = 16
----

Let's go for the examples:


13 norse_archers
1
4
60 unit_models/_Units/EN_Peasant_Padded/norse_archers_lod0.mesh 121
60 unit_models/_Units/EN_Peasant_Padded/norse_archers_lod1.mesh 900
60 unit_models/_Units/EN_Peasant_Padded/norse_archers_lod2.mesh 2500
60 unit_models/_Units/EN_Peasant_Padded/norse_archers_lod3.mesh 6400
3
7 denmark
79 unit_models/_Units/EN_Peasant_Padded/textures/EN_Peasant_Padded_denmark.texture
78 unit_models/_Units/EN_Peasant_Padded/textures/EN_Peasant_Padded_normal.texture
52 unit_sprites/denmark_Dummy_EN_Archers_ug1_sprite.spr
4 merc
77 unit_models/_Units/EN_Peasant_Padded/textures/EN_Peasant_Padded_mercs.texture
78 unit_models/_Units/EN_Peasant_Padded/textures/EN_Peasant_Padded_normal.texture
49 unit_sprites/merc_Dummy_EN_Archers_ug1_sprite.spr
6 norway
78 unit_models/_Units/EN_Peasant_Padded/textures/EN_Peasant_Padded_norway.texture
78 unit_models/_Units/EN_Peasant_Padded/textures/EN_Peasant_Padded_normal.texture
51 unit_sprites/norway_Dummy_EN_Archers_ug1_sprite.spr
3
7 denmark
60 unit_models/AttachmentSets/Final Danish_denmark_diff.texture
60 unit_models/AttachmentSets/Final Danish_denmark_norm.texture
0
4 merc
57 unit_models/AttachmentSets/Final Danish_merc_diff.texture
57 unit_models/AttachmentSets/Final Danish_merc_norm.texture
0
6 norway
59 unit_models/AttachmentSets/Final Danish_norway_diff.texture
59 unit_models/AttachmentSets/Final Danish_norway_norm.texture
0
1
4 None
11 MTW2_Bowman
14 MTW2_Swordsman
2
19 MTW2_Bowman_Primary
14 fs_test_shield
2
18 MTW2_Sword_Primary
14 fs_test_shield
16 -0.090000004 0 0 -0.34999999 0.80000001 0.60000002

14 voulge_militia
1
4
58 unit_models/_Units/LN_Lmail_Hmail/voulge_militia_lod0.mesh 121
58 unit_models/_Units/LN_Lmail_Hmail/voulge_militia_lod1.mesh 900
58 unit_models/_Units/LN_Lmail_Hmail/voulge_militia_lod2.mesh 2500
58 unit_models/_Units/LN_Lmail_Hmail/voulge_militia_lod3.mesh 6400
1
6 france
72 unit_models/_Units/LN_Lmail_Hmail/textures/LN_Lmail_Hmail_france.texture
72 unit_models/_Units/LN_Lmail_Hmail/textures/LN_Lmail_Hmail_normal.texture
45 unit_sprites/france_Voulge_Militia_sprite.spr
1
6 france
67 unit_models/AttachmentSets/Final European Light_france_diff.texture
67 unit_models/AttachmentSets/Final European Light_france_norm.texture
0
1
4 None
20 MTW2_Halberd_Primary
22 MTW2_Halberd_Secondary
1
17 MTW2_Pike_primary
1
17 MTW2_Pike_primary
16 -0.090000004 0 0 -0.34999999 0.80000001 0.60000002

13 saxon_general
1
4
73 unit_models/_Generals_and_Captains/Early_Generals/saxon_general_lod0.mesh 121
73 unit_models/_Generals_and_Captains/Early_Generals/saxon_general_lod1.mesh 900
73 unit_models/_Generals_and_Captains/Early_Generals/saxon_general_lod2.mesh 2500
73 unit_models/_Generals_and_Captains/Early_Generals/saxon_general_lod3.mesh 6400
2
6 saxons
84 unit_models/_Generals_and_Captains/Early_Generals/textures/early_general_hre.texture
91 unit_models/_Generals_and_Captains/Early_Generals/textures/early_general_hre_normal.texture
0
5 slave
84 unit_models/_Generals_and_Captains/Early_Generals/textures/early_general_hre.texture
91 unit_models/_Generals_and_Captains/Early_Generals/textures/early_general_hre_normal.texture
0
2
6 saxons
60 unit_models/AttachmentSets/Final General_saxons_diff.texture
60 unit_models/AttachmentSets/Final General_saxons_norm.texture
0
5 slave
59 unit_models/AttachmentSets/Final General_slave_diff.texture
59 unit_models/AttachmentSets/Final General_slave_norm.texture
0
4
4 None
15 MTW2_Non_Shield
0
1
18 MTW2_Sword_Primary
0
5 horse
18 MTW2_HR_Non_Shield
0
1
18 MTW2_Sword_Primary
0
8 elephant
18 MTW2_Elephant_Crew
0
1
18MTW2_Sword_Primary
0
5 camel
18 MTW2_HR_Non_Shield
0
1
18 MTW2_Sword_Primary
0
-1 0 0 0 0 0 0

====

Edit: May 15th, 2021
The "max distance" number that trails the mesh filepath is also a special dataline
As such, the "lines below" counter that precedes the mesh filepaths is actually a "groups of lines below" counter

This is however the only case where readability improves when lines are not split, thus the examples kept the mesh
filepath and max distance number as one composite data line, regular + special.

Edit: May 15th, 2021
The single number special data line is said to be a scale factor related to descr_mounts.txt (thanks to Jojo00182 !!)

====

@Absolutex
Probably the problem is not on your side.

The syntax checker seems to be very sesitive to the way the Model DB file was formatted ( both extra line breeaks and missing line breaks )
Maybe we could try to adjust the checker to the specific file you are working with (or the one from the original mod you are using).

====

[Gigantus]

Your efforts in looking into this matter is much appreciated, there have been modelDBs out there that were simply impossible to check, neither with this tool or the EDU editor.

If memory serves right then the checker has a problem with blank lines and with zeros in the next line, particularly the ones after attachment lines plus the numbers preceding the mesh are in one line, I believe the first one is the "characters in line" counter followed by the "Lines below" counter. I have not tested it, but I would assume having twelve mesh lines would then require 2 12 as entry.

5 slave
55 unit_models/sanguo/textures/hanlightattachments.texture
60 unit_models/sanguo/textures/hanmediumattachments_nor.texture 0
1
4 None
15 MTW2_Fast_Spear 0
2
18 MTW2_Spear_primary 14 fs_test_shield
0
16 -0.090000004 0 0 -0.34999999 0.80000001 0.60000002
19 han_light_spear_ug2
1 1
48 unit_models/sanguo/han_light_spear_ug2_lod0.mesh 6400
20
6 sicily
45 unit_models/sanguo/textures/han_light.texture
49 unit_models/sanguo/textures/han_light_nor.texture
46 unit_sprites/sicily_han_light_spear_sprite.spr

[Hexdragon]

Many thanks for your feedback

I believe the first one is the "characters in line" counter followed by the "Lines below" counter. I have not tested it, but I would assume having twelve mesh lines would then require 2 12 as entry.

19 han_light_spear_ug2
1 1
48 unit_models/sanguo/han_light_spear_ug2_lod0.mesh 6400
20
6 sicily
45 unit_models/sanguo/textures/han_light.texture
49 unit_models/sanguo/textures/han_light_nor.texture
46 unit_sprites/sicily_han_light_spear_sprite.spr

I also believed for long time that first 1 was a character counter
But now i am positively convinced is not

Note that mounts have 1.12 instead of 1 for the first number. Not suitable for a character counter

In addition the second 1 is a "lines below" counter.
Basically those counters are not preceded by "characters in line" counters, hence we can expect with confidence that an entry for 12 meshes could take this form:
1 12

or even better
1
12
When split this pair in ModelDB worked fine when once in game, yet it seems (as you suggest) that available syntax checkers are not prepared to handle that split

5 slave
55 unit_models/sanguo/textures/hanlightattachments.texture
60 unit_models/sanguo/textures/hanmediumattachments_nor.texture 0
1
4 None
15 MTW2_Fast_Spear 0

.
Being a character counter we can split that 0 at the end of the line
Yet, again the game will handle well while the syntax checker not.

It seems we need to start a project for a syntax checker which is not so dependant on how lines had been split (I mean with "valid" splits) on already formatted files.
I think is possible to get that, yet not a trivial effort.


Regards

[Gigantus]

A thought just crossed my mind: there is a function in Notepad++ (Edit\Blank Operations\Remove Unnecessary Blank and EOL) that converts any text document into a single line - the original form of the modelDB.

Would it be possible to incorporate that into a tool as a first step and then have it format that single line into an 'easy to edit' layout for use with the tool?

[Hexdragon]

A thought just crossed my mind: there is a function in Notepad++ (Edit\Blank Operations\Remove Unnecessary Blank and EOL) that converts any text document into a single line - the original form of the modelDB.

Would it be possible to incorporate that into a tool as a first step and then have it format that single line into an 'easy to edit' layout for use with the tool?

A good Idea Indeed.


It have a secondary benefit, aside from its application for an improved checker.
Someone who experiences problems with the current available syntax checkers (both the standard and the patched one) could use the unformatter
Then format again with a pattern which is complatible with the available checker.


I have worked in a standalone unformatter for a proof of concept (attached at the end of the post):


----


Now some good news:
The update for the patched formatter is ready
-It adds 14 patterns (28 variants) to the original 8. <<< Edited, as per comments in posts # 105
-In addition I have integrated your idea (unformatter) in the tool.

Attached at the end of the post, together with the pacthed syntax checker.


New Version includes:
-User Interface
-Three Format options <<< Edited, as per comments in post # 103
-One Unformat option


Formatt Options Edited, as per comments in post # 105
-Extra Patterns I ---> Format with 8 KE´s original patterns plus 11 additional patterns/variants
-Extra Patterns II ---> Format with above mentioned patterns plus 3 additional patterns/variants (split before "-1")
-Extra Patterns III ---> Format with above mentioned patterns plus 14 additional patterns/variants (specific for that weird first mount "pony" entry )
-No Patterns ---> This one triggers the unformatter


Compatibility:
-Extra Patterns I ---> Compatible with Patched Syntax Checker (only)
-Extra Patterns II ---> Compatible with Patched Syntax Checker (only)
-Extra Patterns III ---> Not compatible with Syntax Checkers, but works well with the game


Coded With:
Python 2.7.8


Use:
1 -Select Format Option
2 -Select ModelDB file ---> Select Button
3 -Execute Task ---> Execute Button


Output file after Format:
"formatted_battle_models", just like the original KE script


Output file after Unformat:
"unformatted_battle_models"


Visuals


-Switch message text font pressing key "F"
-Switch background color pressing key "T"


----


Attachments:

EDIT (25-Jun-2015):
Updated to version 0.55a, as per comments in post # 103 and # 105

-Integrated Tool (Patched Formatter-Unformatter):
ModelDB - Tools - v0.55a.zip

-Standalone Unformatter
ModelDB - Un-Formatter v0.55a.zip

Also replaced older versions on post #80:

EDIT (55-May-2021):
Updated to version 0.56
https://www.twcenter.net/forums/down...o=file&id=4622

Regards

[Gigantus]

The unformatting works fine - however the formatting just has the DOS window open for a short moment and then nothing else happens.

I took the modelDB from from RodG and tested it in a separate folder - unformatting with the stand alone python script appears to be working, but no joy with the formatting, never mind checking.

[Hexdragon]

Strange

Which python version do you run ?

I took the modelDB from from RodG and tested it in a separate folder - unformatting with the stand alone python script appears to be working, but no joy with the formatting, never mind checking.

I shall made somethhing, you are missing the best part

Please, if posible, try running the formatter from IDLE (the python GUI) it will provide more info about any existing problem.

[Gigantus]

Never ran python files (got 2.6.6 I think) via IDLE, only direct or via a BAT file - how do I do that?

[Hexdragon]

Right click on the script
You will find an option called: "Edit with IDLE"

Left click on it
IDLE will be open

You will find the option called "Run" in the menu bar.
Select it.
A combo menu will expand. Select the option "Run Module"

----

The tool was coded an tested with python 2.7.8

At the top of IDLE GUI you will see python version
I you are running Python 2.6.6, I expect you could find some red text displaying details of a given error, when run


Anyway I guess I can install your python version and recode for retrocompatibility.

[Gigantus]

The reason for using that version is based on the fact that python scripts available here are based on versions below 2.7 - anything higher and they don't run. I actually have my standard 'use 2.7' advice here:

Make sure you have a Python version less then 2.7 installed, else install from the applicable download link
Windows x86 MSI Installer (2.6.6) - for 'regular' operating system
Windows X86-64 MSI Installer (2.6.6) - for 64 bit operating system

Running IDLE (Run Module) gives me this error (shortened the path in the first two 'File' lines):

IDLE 1.2.4      ==== No Subprocess ====
>>> 
Traceback (most recent call last):
  File "C:\...\Downloads\FormatModelDBFile - 3rdParty Patch v0.50.py", line 1909, in <module>
    FBM_Window00()
  File "C:\...\Downloads\FormatModelDBFile - 3rdParty Patch v0.50.py", line 788, in FBM_Window00
    Button( frame010, text = 'SELECT', width = 12, command = Select_File, font = ('Old English Text MT', 10), bg = 'slate blue3').grid( row = 2, column = 0, padx = 10, pady = 10, sticky = NW)
  File "C:\Program Files\Python254\lib\lib-tk\Tkinter.py", line 2012, in __init__
    Widget.__init__(self, master, 'button', cnf, kw)
  File "C:\Program Files\Python254\lib\lib-tk\Tkinter.py", line 1942, in __init__
    (widgetName, self._w) + extra + self._options(cnf))
TclError: unknown color name "slate blue3"
>>>

And all I am getting is a small window that allows File\Exit and Help\About in a heavy Gothic font

[Hexdragon]

Solved

Uninstalled 2.7.8
Installed 2.6.6.

It was the color name: 2.7.8 supports a blank space in the color's name, 2.6.6 don't

As dumb and trivial as it may sound, the only change I needed to execute was:
'slate blue3' changed to 'slateblue3' (without the space)
'royal blue3' changed to 'royalblue3' (without the space)

Tested change in python 2.6.6 and worked
Then uninstalled 2.6.6. and returned to my beloved 2.7.8.
The change works in 2.7.8 as well

I have updated download links in both post #80 and post #88

[Gigantus]

I am one step further (I am using python 2.5.4 - will upgrade to 2.6.6), but regardless which method I am using I come up with this formatting error (after unformatting):
The mesh distance number is in the line below
The faction count number is merged with the line count number
It may be noted that the original entry did not contain the usual 1.12 line prefix, but I tried with it and the formatting remained like this.

37 banzai_mount_scythed_chariot_seleucid
1
1
42 unit_models/banzai/mount_chariot_lod0.mesh
40000
37 england
46 unit_models/banzai/chariotseleucid.tga.texture
46 unit_models/banzai/chariotseleucidnorm.texture
69 unit_sprites/england_banzai_mount_scythed_chariot_seleucid_sprite.spr
4 merc
46 unit_models/banzai/chariotseleucid.tga.texture
46 unit_models/banzai/chariotseleucidnorm.texture
66 unit_sprites/merc_banzai_mount_scythed_chariot_seleucid_sprite.spr
6 norway
47 unit_models/banzai/chariotseleucid1.tga.texture
46 unit_models/banzai/chariotseleucidnorm.texture
68 unit_sprites/norway_banzai_mount_scythed_chariot_seleucid_sprite.spr
0
1
8 Elephant
11 fs_chariot2
0
0
0
-1 0 0 0 0 0 0

I will try later with the 2.6.6 version and try other modeldb files as well.

[Hexdragon]

I am one step further (I am using python 2.5.4 - will upgrade to 2.6.6), but regardless which method I am using I come up with this formatting error (after unformatting):
The mesh distance number is in the line below
The faction count number is merged with the line count number
It may be noted that the original entry did not contain the usual 1.12 line prefix, but I tried with it and the formatting remained like this.


I will try later with the 2.6.6 version and try other modeldb files as well.

Yesterday I have got something similar with BattleModel from Custom Campaign Mod 2
http://www.twcenter.net/forums/showt...Mod-2-Released

The problem was in the BattleModels file itself:
-There was missing blank space at the end of the special "torch line" of one unit (Spanish Dragons if I recall correctly)
-Thus the unformatter merged the last number in the "torch" line (0.60000002 ) with character counter in the next unit name (6) when eliminated the line break
-Later when formatted again the character counter appeared as 600000026

It seems you are getting roughly the same.

EDIT:
Verified, there is a missing blank space in your original file, after the faction count
All you would need is to add the missing blank space before unformatting
It should also solve the "distance number" issue (tested)

Hence, I guess you may run the tool with Python 2.5.4 too

====

Let me switch for another, yet related, topic:

The problem with Kingdom's "Americas" BatleModels file that you commented in post # 1 (uncompatibility with the standard checker) comes from entries for "Saxon General" and "Saxon King".

In that file, both entries lack factions and texture data.
Yet, believe or not, the syntax you will see there is actually correct

[Gigantus]

I just ran the checker via idle as well and my conclusion is also that missing spaces at the end of a line causes the mess. I spend 2 hours with the modeldb from RodG and I am giving up as so far I am not even past a third of the entries.

Is there a way to add a space to the end of each line before unformatting? The unformatting should remove surplus spaces in case there are two or more.

I also noted that nearly every model entry did not have a split here, which causes the checker to exit without message:

--- version 1 ---
16 -0.090000004 0 0 -0.34999999 0.80000001 0.60000002
32 Knights_of_chaos_of_Slaanesh_ug1 1.1 1
80 unit_models/_Units/warhammer/Chaos/model/Chaos_knight/Chaos_knight_ug1_lod0.mesh 6400

--- version 2 ---
16 -0.090000004 0 0 -0.34999999 0.80000001 0.60000002
32 Knights_of_chaos_of_Slaanesh_ug1
1.1 1
80 unit_models/_Units/warhammer/Chaos/model/Chaos_knight/Chaos_knight_ug1_lod0.mesh 6400

[Hexdragon]

I just ran the checker via idle as well and my conclusion is also that missing spaces at the end of a line causes the mess. I spend 2 hours with the modeldb from RodG and I am giving up as so far I am not even past a third of the entries.

Is there a way to add a space to the end of each line before unformatting? The unformatting should remove surplus spaces in case there are two or more.

There is a way. Yes
For that specific, the tricky part would be how to avoid removing the valid double spaces (those that came after zeros).
Yet I think it can be done

On the other hand, I was thinking on alternate approaches, and ended with experimental version of the standalone unformatter (attached at the end of this post)

This is the rationale behind the update:

The file is transformed to string made of hexadecimal digits (2 digits: "1 byte")

The original unformatter (version 0.10) evaluates each time a block composed by 2 bytes:
It looks for hexadecimal signature of line break ("0d0a").
-If the above is found, the unformatter skips the whole block
-If no line break is found, then the unformatter adds the first byte (*) and goes to the next byte in order to repeat evaluation

(*) When said "adds", I mean append the byte at the end of a new string which is the basis for the new unformatted file.

----
EDIT (25-Jun-2015):
On version 0.55a (see post # 105) functions described below had been transfered to separate script "ModelDB Blank Space Fix"
Unformatter script returned to it's initial function just as described above
----

Now, the updated unformatter (version 0.14) evaluates each time a block composed by 3 bytes:
It looks for hexadecimal signature of line break ("0d0a") in the 2nd and 3rd byte AND hexadecimal signature of blank space ("20") in the first byte
-If the above ("200d0a") is found, the unformatter adds only the blank space ("20") and then skips the whole block
-If only the line break ("0d0a") is found, the unformatter adds the first byte (which is something different than "20") and then adds a blank space ("20"), and then skips the whole block
-If no line break is found, then the unformatter adds the first byte (*) and goes to the next byte in order to repeat evaluation.

Performed light test only, but it seems to work.
I expect It will work well as long as the missing blank space is not in the "zero plus double space"

Attachment
Updated Standalone Unformatter:
ModelDB - Un-Formatter v0.55a.zip

EDIT (25-Jun-2015):
Updated to version 0.55a, as per comments in post # 103 and # 105

EDIT (15-May-2021):
Updated to version 0.56
https://www.twcenter.net/forums/down...o=file&id=4622

[Gigantus]

That looks way better - in fact all that is seems to be needing now is getting the checker to accept the double number entry as I detailed in my previous post.

Edit: Extra Pattern 1 appears to work fine in that regard - it does however come up with the odd faction count number in the wrong line:

3
75 unit_models/_units/warhammer/empire/mount/armoured_horse/Order_AH_lod0.mesh 121
75 unit_models/_units/warhammer/empire/mount/armoured_horse/Order_AH_lod1.mesh 1225
75 unit_models/_units/warhammer/empire/mount/armoured_horse/Order_AH_lod2.mesh 10000 12
12 papal_states


and a bit weird, but I guess it's due to the 0.85 entry:

15 Dire_Wolf_mount 0.85 1 71 unit_models/_units/warhammer/Orc&goblins/mount/wolf/Dire_Wolf_lod0.mesh 10000
2
7 hungary 73 unit_models/_units/warhammer/Orc&goblins/mount/wolf/textures/wolf.texture 80 unit_models/_units/warhammer/Orc&goblins/mount/wolf/textures/wolf_normal.texture
47 unit_sprites/hungary_Dire_Wolf_mount_sprite.spr
5 slave 73 unit_models/_units/warhammer/Orc&goblins/mount/wolf/textures/wolf.texture 80 unit_models/_units/warhammer/Orc&goblins/mount/wolf/textures/wolf_normal.texture
45 unit_sprites/slave_Dire_Wolf_mount_sprite.spr 0

One other thing - the checker cannot handle special characters (nor can the formatter): Orc&goblins - bit silly by the modders to use that as folder name (even though it works) but easily corrected: Orc_goblins

Once corrected the above dire_wolf_mount gets formatted nearly correct with just the 0.85 in the wrong line:

15 Dire_Wolf_mount 0.85
1
71 unit_models/_units/warhammer/Orc_goblins/mount/wolf/Dire_Wolf_lod0.mesh 10000
2
7 hungary
73 unit_models/_units/warhammer/Orc_goblins/mount/wolf/textures/wolf.texture
80 unit_models/_units/warhammer/Orc_goblins/mount/wolf/textures/wolf_normal.texture
47 unit_sprites/hungary_Dire_Wolf_mount_sprite.spr

I am starting to wonder if that number has got anything to do with relative model size, eg 0.85 = 85%

[Gigantus]

I kept on going through the file and about 90% of errors (loads of those) were related to the faction count number in the wrong line