Research Hub

**Augustus Lucifer** · September 27, 2009, 06:55 AM

This thread is intended to be used for research into various undiscovered or undetermined facets of M2 modding, particularly involving text files, since we were trailing off in other threads.

This thread is not intended to be about any one specific thing, but rather a platform for trying new things. I'll try to keep this OP updated with any confirmed new discoveries.

building_factions (EDB Conditional)

info_pic_dir & card_pic_dir (EDU Additional Lines)

Defensive Reinforcement Behavior (config_ai_battle.xml)

Enhanced Logging

destroy_units by custom attribute

**Augustus Lucifer** · September 27, 2009, 06:56 AM

(Don't want to clog the OP, so made a new post)

This is a continuation from this thread.

Originally Posted by Archaon

@gigantus, While looking into the .exe further i see possible options to use in the descr_strat or maybe in CS for spawn_army..

we have these;
ambush – set the spawn_army to ambush stance… or in the desc_strat make it ambush on first turn.
sec_weapon – maybe used with weapon_lvl ???
pri_weapon – as above.
soldiers – if this is what I think it is! We can set a unit of 4 men to 1 man (quarter strength)!
Level 1 – there is a 3 digit variable following, not sure what this is. Requires testing.
quantity – might be related getting to siege_equiptment working in CS or it might be something completely unrelated to siege_equipment…

Also I see the section for spawn_army that tells you you need to have an army for the general and finish with ‘end’ then it has ‘none’ and ‘relative ‘ but this may relate to the descr_strat

And to my amazement I see things I didn’t conceive possible!

reinforcement_time
supporting_armies
no_withdraw
battle_pos
turns_owned

Have no clue how to use them yet, but I am going to try everything I can think of !!!

So based on a look at the descr_battle for the Battle of Otumba, I can conclude that:

no_withdraw ~ Defined on the army line in a custom historical battle, I think it's pretty self-explanatory of what it *should* do, though I haven't tried observing what happens with and without it.

supporting_armies ~ Also defined on the army line in a custom historical battle, I've yet to see any value other than 0 so not sure what it does if set to something else.

reinforcement_time ~ Defined for a reinforcement army in a custom historical battle. Listed as 0.083, not sure if that's 8:20 minutes or some sort of modifier.

battle_pos ~ According to this recent post, appears to define the location of a city on the battle map, but the numbers as with all of those wacky descr_battle numbers I wish I knew more about.

turns_owned ~ Can't seem to find any reference to it, likely goes on a settlement line along with year_founded and the like. Will have to test that, it's possible there's some hidden acclimation bonus received when you've owned a city for a long period of time.

soldiers ~ It is what you think it is, sort of, it's used in all of the descr_battle files at any rate.

The rest I'm not sure about right now, it seems ambush has been tested on the unit line and didn't produce any results. Perhaps it would better be substituted in place of sieging / end to generate an ambush battle from the start, as that seems to make more sense.

It also might be worth looking into if the "battles section" of the descr_battle can be applied to the descr_strat. I imagine it can, and recall hearing things to that effect, but haven't seen it used in a mod that I've looked in.

---------------------------------------------

Another thing I'm curious about is 'ancillary unit types'. ancillary is defined as a potential capability in the EDB, and it seems to recognize it since it throws up a relevant error, but I haven't found any clues as to what it means. I try putting in this line:

Code:

ancillary Song_Zhanmadao  0  requires factions { song, }

And I get this error:

Code:

03:53:27.421 [script.err] [error] Script Error in auh/data/export_descr_buildings.txt, at line 450, column 27
Unknown ancillary unit type specified: Song_Zhanmadao

I've tried using unit type, ancillary, and ancillary type(like 'military'), but none of those have worked so far. One thing I noticed is it doesn't want a space in the entry, since when I entered it like a recruit pool it didn't read past the space.

It's not entirely uncommon for deprecated code to be lying around, but even the Rome recruit capability(as opposed to recruit_pool) seems to read functionally, and just doesn't seem to actually do anything from cursory tests. So there must be something this capability wants to be referencing, legacy or not, which at least would make it passive, perhaps more.

**Archaon** · September 27, 2009, 07:23 AM

missed this post;

Originally Posted by Augustus Lucifer

Keep in mind that the descr_strat has a lot in common with the descr_battle. I also saw those and a couple others, but they struck me as something which would go in a custom battle file. It's entirely possible they will work though.

battle_pos reminded me of setting the location of the settlement with respect to where the playable map area is on the battle map. I recall something to this effect with custom tiles that didn't get resolved for M2.

reinforcement_time might impact the time it takes in a siege before they appear, though it seems again rather weird outside of the context of a custom battle.

Some other irregulars:

card
rand_seed
settlement_tax
triumph
tile
founding_faction
capital

Those may not all be lines but they were in a similar context, so worth a look. There's also plan_set and package_path which we know what does but aren't really well documented, and the former we have no idea how to change for M2 as far as I know.

and the below alpaca has not included in his odds and ends which i need to test..

Here are some more building capabilities;

Code:

agent merchant 0 ; therefor spy, assassin, diplomat, princess, priest, heretic, witch, inquisitor will all work also.
agent_limit merchant 1
armour 1
farming_level 1
recruitment_time_bonus_naval bonus 1
road_level 1
weapon_bladed 1 
weapon_missile 2
weapon_siege bonus 1
weapon_simple 1

I am most interested in recruitment_time_bonus_naval bonus 1 because if the naval part can be changed to infantry, or cavalry, ect it would allow so many new options!

**Augustus Lucifer** · September 27, 2009, 07:50 AM

That would be interesting, though only the _naval one is indicated, so it seems unlikely. Really with recruitment times we can apply them via the recruit_pools by just varying their replenish rate. But on that subject I haven't really seen any in-depth research into some of the more curious building effects lines, especially the recruit pools. There's a lot of recruit pool properties and what-ifs that I'm not informed enough on to develop a methodology.

I started doing tests on recruit pool properties some time ago but then got sidetracked by other things. One of the tests I did was seeing what happens when two recruit pools are present and active in a building at the same time, and I concluded:

After reviewing the test results and making a few edits and testing it more myself(mainly by making sure that the sum of A and B doesn't equal B), I've concluded that when two pools of the same unit in the same building are active at the same time, the game will read the latter pool and ignore the former, at least in terms of replenish rate.

I've also concluded that the game either stocks the pools before running the FactionTurnEnd event(possibly at the SettlementTurnEnd event), or that somehow the counter isn't read by the EDB as being active until after the pools are stocked. This is instanced by the fact that the second pool should activate on the first end turn(and it is active the next turn as shown by the experience), but you only gain 1 unit, which is the replenish rate of the former pool.

The above was done using an event counter set at FactionTurnEnd. I also concluded that a unit seems to still build if it has been queued before a recruitment pool is inactivated. Further, if another pool of the same type is activated while the unit is building, once it has built it will take on the attributes of the pool active at the time(ie. experience). A few people corroborated this but more affirmation or refutation on those points is always welcome. A couple other things I want to figure out in that vein:

- Does a pool add its base stock whenever a building upgrade is built that has it as an active capability? Or is it a one time thing whenever the first recruit pool of that unit in a settlement goes active? Or does it happen every time a recruit pool goes active?

- When a multitude of pools for the same faction, settlement, and building are present as capabilities, do the inactive pools exert any action despite being disabled as far as their conditions are concerned? Particularly pertaining to event counters. As in:

Code:

;; When these pools are toggled through, which replenish rate will be applied the following turn.
;; Will it max out at 5 even if only the first pool is ever made active?

recruit_pool Unit 0 0.3 1 0 requires factions { all, } and event_counter 1 and not event_counter 2 and not event_counter 3
recruit_pool Unit 0 0.5 2 1 requires factions { all, } and not event_counter 1 and event_counter 2 and not event_counter 3
recruit_pool Unit 0 0.7 5 0 requires factions { all, } and not event_counter 1 and not event_counter 2 and event_counter 3

**Eothese** · September 27, 2009, 10:10 AM

Originally Posted by Augustus Lucifer

soldiers ~ It is what you think it is, sort of, it's used in all of the descr_battle files at any rate.

And only descr_battle, sadly not descr_strat

Code:

Script Error in mods/akthross/data/world/maps/campaign/imperial_campaign/descr_strat.txt, at line 566, column 46
Tried to specify number of soldiers in campaign script; it's only legal to do so in a battle script.

**Augustus Lucifer** · September 27, 2009, 04:05 PM

Makes sense, it's likely the pri_wep and sec_wep are similarly used and also unavailable. Realistically it'd be weird if you could add things to the strat map which deviate from their prescribed values or assignable values.

**Archaon** · September 27, 2009, 07:54 PM

I was considering it for CS rather than descr_strat..
There wont be any free time for me this week, so testing will need to wait until Saturday morning.

**Augustus Lucifer** · October 04, 2009, 01:42 AM

I've done some testing with the building_factions conditional after looking into it. It's a conditional gleaned from the EXE for use in the EDB. The EXE gives a hint that it should be used on capabilities lines, but not much else. Thankfully the error log and some trial and error fill in the gaps.

Turns out what it lets you do is define capabilities based on who the creator of a building is. So for example:

Code:

building church
{
    religion catholic
    levels church_1
    {
        church_1 city requires factions { all, }
        {
            capability
            {
		religion_level 1 requires building_factions { england, }
            }
            material wooden
            construction  1 
            cost  1000 
            settlement_min village
            upgrades
            {
            }
        }

So now if you were to create this building as France, it doesn't actually provide any religious conversion. On the other hand if you were to capture a settlement owned by England, where they had built a church, the religious conversion would be active.

To test this try building something with the building_factions being set to another faction and see if it works(or rather, doesn't work). Then add this line to the descr_strat for whatever settlement you want, and make sure the creator matches up with the building_factions and is not your selected faction:

Code:

	building
	{
		type church church_1
		creator england
	}

It should now start effecting it. I'd like a few other people to test this in order to confirm my findings. Keep in mind the capabilities will still show on the building details scroll regardless of if they are in effect. Just end turn a few times and see if the religion % changes, and make sure to have a good test environment, as other buildings or priests might give the wrong results.

The building_factions also works the same as factions, so it will accept faction names, culture names, and all. It'd be simple then to say requires factions { england, } and building_factions { france, moors, scotland, russia, spain, byzantine, turks, hre, papal_states, milan, venice, hungary, poland, } (I probably missed some, since I don't use vanilla faction names), or potentially requires factions { england, } and not building_factions { england, }, which would cut it down to one line for the building being built by any foreign faction.

So what does this mean if it works?

It means that when we use the same trees for multiple cultures in different ways, we can change the effects based on who owns it. Gauls capture the Roman-made Coliseum? They probably won't be holding gladiatorial games though it'd likely boost other bonuses. It also means we can force players to rebuild buildings which don't represent finite structures. So if I capture a building which is intended to represent cultural assimilation in a settlement, using this condition I can null all the bonuses and add some negative bonuses to prompt the player to destroy it and start building up their own iteration of the assimilation building.

Essentially, any building which is intended to represent something intangible can be killed upon capture(at least in terms of it actually doing anything). This could be done previously, but it involved potentially extensive event counters or separate trees for each faction.

So if people get a chance, try this out and report back so we can confirm it works as specified. I already have a few uses in mind for my mod if it does!

EDIT: I don't know if this will work with Rome. I can't seem to look in the Rome files as easily as the M2 ones, it's all showing up as gibberish in a Hex Editor. Might be worth a try though. The EDB thread on the Org which is for Rome states it doesn't work, but the discussion on page 2 seems to state that it does.

EDIT #2: There's also the question, if it does work, if it is only being made to work due to the creator line in the descr_strat, and will not work in the course of a campaign. This is a bit harder to test.

EDIT #3: Okay so I did more of a test this time. I created one building through the descr_strat and gave it to Shaoxing with 'taira' as creator. Then I built another in-game and processed cq, which had my home faction as creator('song'). Here's the EDB entry:

Code:

				religion_level 1 requires factions { song, } and building_factions { taira, }

And here's the results of the test over 10 turns:

Spoiler Alert, click show to read:

As you can see, the one I created never got a religion change, whereas the one that had the specified faction as creator kept getting religion changes. Something else curious in this test, is that my mod uses a 4tpy script, and religion_level is doing some really odd things. On Turn 9 and Turn 6 you'll see that it adds up to 101%, and by the 9th turn end it had essentially gained 6 points is what it seems to be saying. This is really odd. Is it possible that religion level only applies on a summer turn or something? That's something worth looking into, as 4tpy seems to do a hell of a lot of wacky things that don't appear as wacky on the surface as they really are.

EDIT #4: As suspected, initial tests with recruit pools haven't turned up as good of results. Going to try a few other things. What I'm finding, as briefly touched on in this post, is that it seems to be treating building_factions as if it were just factions when on a recruit_pool line. For instance, the following lines are in the capabilities section:

Code:

recruit_pool "Xian Bowmen"  5   0.5   8  0  requires building_factions { east_asian, song, }
recruit_pool "Song Zhanmadao"  5   0.5   8  0  requires building_factions { pacific_asian, taira, minamoto, }

Now playing as song, I can build Xian Bowmen in both buildings I've created, and buildings someone else has created. On the other hand I can't build Song Zhanmadao in any buildings. More curious though, is if that were the case I should be able to recruit Song Zhanmadao playing as taira and building it there, yet I cannot. That's curious because both lines should be treated the same, yet for the second one it doesn't yield anything at all.

EDIT #5: Oh! Now here's something interesting. I changed the above line from { pacific_asian, taira, minamoto, } to just { taira, } and now it works for taira recruiting the unit. What I seem to surmise from this, is that unlike the factions condition which looks for any of the ones listed, the building_factions wants all of the ones listed. Going to do further tests to see if this is true. Nevertheless it still doesn't seem to work with capturing another faction's building, as I can still build the one I shouldn't and not build the one I should be able to.

EDIT #6: I've had no luck with pools, but it should be noted that it does work with recruitment_slots, so you can effectively kill all recruitment in a region assuming you only have one building providing the recruitment slots at any given time.

**Theodotos I** · October 14, 2009, 10:57 AM

The line "recruitment_time_bonus_naval bonus 1 " itself does not show when inserted into the capabilities of a building, nor does it have any discernible impact. Is it possible that this is a typo? The line "recruitment_cost_bonus_naval bonus 1" works excellently. And incidentally, cannot be exchanged with infantry or cavalry.

**Augustus Lucifer** · October 14, 2009, 10:16 PM

From all the links I've visited, people didn't seem to have a resolution for the lines info_pic_dir and card_pic_dir in the EDU, and they aren't included in the few mods I've checked, so I'm counting this a new discovery in relation to the community at large.

The lines are much simpler than previous attempts have tried to utilize them. The game already assumes that /ui/unit/ or /ui/unit_info/ are the preceding directory to whatever you enter. Adding the lines in red:

Code:

type             Naginata Shinobe
dictionary       Naginata_Shinobe      ; Naginata Shinobe
category         infantry
class            spearmen
voice_type       Light
banner faction   main_spear
soldier          Naginata_Shinobe, 60, 0, 1
attributes       sea_faring, hide_forest, can_withdraw
move_speed_mod   1.0
formation        1.2, 1.2, 2.4, 2.4, 3, square
stat_health      1, 0
stat_pri         5, 0, no, 120, 50, melee, melee_blade, piercing, none, 25, 1
stat_pri_attr    short_pike
stat_sec         no
stat_sec_attr    no
stat_pri_armour  4, 8, 2, flesh
stat_sec_armour  0, 0, flesh
stat_heat        0
stat_ground      0, 0, 0, 0
stat_mental      8, disciplined, trained
stat_charge_dist 30
stat_fire_delay  0
stat_food        60, 300
stat_cost        1, 500, 150, 100, 100, 500, 1, 200
armour_ug_levels 0
armour_ug_models Naginata_Shinobe
ownership        minamoto, taira, champa, daiviet, dali, goryeo, jin, khitans, khmer, mongols, pagan, song, tibet, xixia, ghurid, challenge, scripting, slave
info_pic_dir	 minamoto
card_pic_dir	 minamoto
recruit_priority_offset    0

This causes the game to look for the info pic at /ui/unit_info/minamoto/naginata_shinobe_info.tga and the card pic at /ui/unit/minamoto/#Naginata_Shinobe.tga.

These cards and info cards are workable across all factions. So while the unit has 18 factions listed as having ownership, all 18 factions look for the card and info card in one central location, greatly reducing the number of images which have to be put in these folders for utilization of AOR. So if the same EDU unit has separate 'textures' and subsequently separate cards based on which faction it's a part of, you probably don't want to use this functionality for those specific units. For all AOR units though this is highly recommended, as it exponentially reduced the number of files which need to be stored.

It should be noted that these lines supersede faction folders, so if you have one in another faction folder which is specific to that faction, it will take the one listed in the EDU before it. This is my observation as of this time, and may be disproved from further exposure.

Furthermore, it doesn't matter what you put there, it doesn't have to be a faction or culture name. In my first test of this functionality I put nubpics there instead of minamoto, and it looked for the files in /ui/unit_info/nubpics/. I have yet to try appending trailing slashes to the folder name, but then I also fail to see why they'd be necessary when you can already specify separate folder names ad infinitum.

--------------------------------------------------------

A further observation about attaching scripts to the descr_strat. The line at the bottom of the file does accept folders preceding a file name, in the following format:

Code:

script
scripts/test_script.txt

This is useful for anyone who wants to try out things and not use the campaign script directly. Just make a folder in imperial_campaign called scripts and store all your miscellaneous scripting files there, and you can easily switch out the descr_strat references.

**konny** · October 15, 2009, 04:28 AM

Originally Posted by Augustus Lucifer

Code:

ancillary Song_Zhanmadao  0  requires factions { song, }

And I get this error:

Code:

03:53:27.421 [script.err] [error] Script Error in auh/data/export_descr_buildings.txt, at line 450, column 27
Unknown ancillary unit type specified: Song_Zhanmadao

Is Song_Zhanmadao the name of the ancillary or its type? In the first case I would try the AncType instead.

On the other hand we know that these error messages often don't say what they mean, so the error might be elsewhere: What is the "0" for? Usually ancillaries would not require an integer because it's always "1" to get.

If this could be made working this could be a great help when setting up regional titles system or the effects of education when entering a settlement with a certain building.

**Augustus Lucifer** · October 15, 2009, 10:02 AM

Originally Posted by konny

Is Song_Zhanmadao the name of the ancillary or its type? In the first case I would try the AncType instead.

On the other hand we know that these error messages often don't say what they mean, so the error might be elsewhere: What is the "0" for? Usually ancillaries would not require an integer because it's always "1" to get.

If this could be made working this could be a great help when setting up regional titles system or the effects of education when entering a settlement with a certain building.

Song Zhanmadao is a unit, not an ancillary or an ancillary type. As I mention after that "I've tried using unit type, ancillary, and ancillary type(like 'military')", the first thing I tried was an ancillary type(military, sex, entertain, etc.), then I tried the name of the ancillary itself, and then I tried a unit. All of them don't work however, and throw up that same error. The 0 is there because that's the same format as recruiting agents, if it was the problem the error log would have said "Expected requires or nothing, found: 0".

What's important is the log doesn't say ancillary, it says ancillary unit. The impression this gives is something akin to what plugins are to buildings, except for units.

**konny** · October 15, 2009, 11:10 AM

Originally Posted by Augustus Lucifer

What's important is the log doesn't say ancillary, it says ancillary unit. The impression this gives is something akin to what plugins are to buildings, except for units.

Now I am clueless too...

What could be an "ancillary unit"? May be they wanted to make acquisition of ancillaries legal for units too? In this case either "unit" should appear somewhere as a requirement in EDA or "Ancillary" as a possible attribute in EDU.

**Germanicu5** · January 29, 2010, 09:10 AM

I keep forgetting to post this finding and since today is my "forum activity" day... I announced the discovery a good few months ago in my thread (here) and I had been using it in my releases since August, but I think it'll become better-known if I put it somewhere other modders can see. Anyone can use this solution as long as they refrain from unnecessary authorship claims.

There's a separate section that can be put in config_ai_battle.xml and it controls reinforcements defensive behaviour by setting operating range of units. Normal value put in this place by built-in (hardcoded) AI is, according to my tests, "0". If we set it to some reasonable value, reinforcements set do defensive stance will defend more actively, setting it to excess value will result in relatively chaotic attack at a large range.

<config>
<support-armies>
<defend-terrain>
<radius>15</radius>
</defend-terrain>
</support-armies>

I'm also attaching xml file with proper layout, it contains only the section.

Regards

**Augustus Lucifer** · January 29, 2010, 09:52 PM

Thanks. Added link in the OP. I'm also going to copy my enhanced logging thread here, since I just realized it wasn't here and I don't believe I posted that information anywhere more visible.

---------------------------------

Originally Posted by Augustus Lucifer

Well since I needed to start setting up Bug Report mechanisms in our team since we'll have a playable alpha internally soon, I was presented with the debacle of being able to check two different types of comprehensive log files at the same time. Both the *script* and ai.ltgd options provide valuable information about what exactly is happening right before a CTD occurs. But until now I had thought it was only possible to log one type at a time, because this thread states that a subsequent log line will supersede the former, so I naturally assumed, in the TW modder spirit of not breaking the equilibrium, that it made sense.

That isn't the case though. This might not be a new discovery, but if it's common knowledge then it sure as hell isn't posted anywhere and I've never seen it in a .cfg or cfgfixer, so shame on whoever knew this for not posting it. It is possible to log both ai.ltgd which shows what decisions the AI is making, and script which shows what triggers are firing, combined with trace, so every little thing is logged. It's also pretty easy to separate them. After trying about 50 combination's of same-line logging since I accepted the multi-line as fact, I got multi-line running after a few tries. This is what my CFG looks like:

The ai part is necessary to enable the ai.ltgd logging method. The to line has been used for a long time, this is where the entire log file is generated with all of the pieces in one big clunky file. The two level lines, with the syntax shown above, log both. I'm not sure if it works with *script* instead of game.script* but I see no reason to try it since this works and does the same thing. Lastly, the two file lines split the AI logging and Script logging into two separate files, so that you can check them separately. Note that they don't remove them from the main log file, they just carbon copy them to the specified directory.

Optionally you can add in another line: level = * trace (This will make the output file ~9,000 KB and log pretty much every file it loads, even the ones in the .exe it seems. Good for pinpointing hard to catch errors but maybe not useful all the time.)

Hopefully this enhanced logging will help someone find a CTD easier, and then I'll be glad I wasted 30 minutes bashing my head against it.

As for why Trajan or whomever experienced the results in the Config thread linked to above, I think this has to do with the non-conditional log level. The plain * seems to indicate it isn't using any advanced logging methods, so since both are * obviously only one level of * can be logged. On the other hand when you have the two advanced logging methods, they don't overwrite since the levels are being applied to different log methods.

Originally Posted by wilddog

@Augustus Lucifer
Excellent info I didn't know about the use of the command

[ai]
ltgd_logging = true

or the breakdown of the log files.

and plus rep

One thing though, you may want to consider amending your log entry slightly as you can miss some info (I was only checking the script bit for now). As you were using "game.script.*" you end up missing the info collected in "game.script"(see below) which would include any comments using the log always command. Also some trait warnings messages I received were missed as they are formatted like "[game.script] [warning] Trigger parsing warning in mod". The "game.script*" option will pick them all up (but having the ability to split them out can be useful as well). Hope that helps you.

[log]
to=logs/auh.system.log.txt
level = * trace
file = game.script.* logs/pkh.script2.log.txt
file = game.script* logs/pkh.script.log.txt
file = game.script logs/pkh.scriptoutput.log.txt
file = ai.ltgd logs/pkh.ai.log.txt

**Augustus Lucifer** · April 03, 2010, 01:54 AM

Added a link to Rozanov's thread documenting the usage of the destroy_units commands.

**Gigantus** · November 26, 2010, 12:53 AM

Originally Posted by Augustus Lucifer

From all the links I've visited, people didn't seem to have a resolution for the lines info_pic_dir and card_pic_dir in the EDU, and they aren't included in the few mods I've checked, so I'm counting this a new discovery in relation to the community at large.

The lines are much simpler than previous attempts have tried to utilize them. The game already assumes that /ui/unit/ or /ui/unit_info/ are the preceding directory to whatever you enter. Adding the lines in red:

Code:

type             Naginata Shinobe
dictionary       Naginata_Shinobe      ; Naginata Shinobe
category         infantry
class            spearmen
voice_type       Light
banner faction   main_spear
soldier          Naginata_Shinobe, 60, 0, 1
attributes       sea_faring, hide_forest, can_withdraw
move_speed_mod   1.0
formation        1.2, 1.2, 2.4, 2.4, 3, square
stat_health      1, 0
stat_pri         5, 0, no, 120, 50, melee, melee_blade, piercing, none, 25, 1
stat_pri_attr    short_pike
stat_sec         no
stat_sec_attr    no
stat_pri_armour  4, 8, 2, flesh
stat_sec_armour  0, 0, flesh
stat_heat        0
stat_ground      0, 0, 0, 0
stat_mental      8, disciplined, trained
stat_charge_dist 30
stat_fire_delay  0
stat_food        60, 300
stat_cost        1, 500, 150, 100, 100, 500, 1, 200
armour_ug_levels 0
armour_ug_models Naginata_Shinobe
ownership        minamoto, taira, champa, daiviet, dali, goryeo, jin, khitans, khmer, mongols, pagan, song, tibet, xixia, ghurid, challenge, scripting, slave
info_pic_dir     minamoto
card_pic_dir     minamoto
recruit_priority_offset    0

This causes the game to look for the info pic at /ui/unit_info/minamoto/naginata_shinobe_info.tga and the card pic at /ui/unit/minamoto/#Naginata_Shinobe.tga.

These cards and info cards are workable across all factions. So while the unit has 18 factions listed as having ownership, all 18 factions look for the card and info card in one central location, greatly reducing the number of images which have to be put in these folders for utilization of AOR. So if the same EDU unit has separate 'textures' and subsequently separate cards based on which faction it's a part of, you probably don't want to use this functionality for those specific units. For all AOR units though this is highly recommended, as it exponentially reduced the number of files which need to be stored.

It should be noted that these lines supersede faction folders, so if you have one in another faction folder which is specific to that faction, it will take the one listed in the EDU before it. This is my observation as of this time, and may be disproved from further exposure.

Furthermore, it doesn't matter what you put there, it doesn't have to be a faction or culture name. In my first test of this functionality I put nubpics there instead of minamoto, and it looked for the files in /ui/unit_info/nubpics/. I have yet to try appending trailing slashes to the folder name, but then I also fail to see why they'd be necessary when you can already specify separate folder names ad infinitum.

.

Please note that the attribute mercenary_unit supersedes the pic_dir entries, eg the pictures will be sourced from the merc(s) directories.

.