• We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
Doesn't seem to be ABCDE related, as I removed combat_tactics.txt and am still getting crashes, plus the duplicate ID reports.
 
Duplicate IDs were from SELIN events (Numahr or whoever updated them stuck an R in the middle of the event IDs of the reformed religions, which is a no-no.) Crashes might have been from a buggy province event for Irminsul trees, have to see if it still crashes.
 
I had a CTD, don't know if it's ABCDE related. There's also a lot of duplicate IDs reported in error.log, the same two over and over. Again, I don't know if it's ABCDE related, but I can't find those IDs in the mod files.

Was getting the same problem. It kept happening on the same date over and over on a savegame, diagnosed it to be an unborn child by removing all events from said date one by one. The only notable thing about the parents was that the mother has some kind of a buggy graphic on her.

Had these lines in error.log:

[instanttextboxtype.cpp:92]: Not used, use maxWidth and maxHeight file: launcher/interface/main.gui line: 73
[instanttextboxtype.cpp:92]: Not used, use maxWidth and maxHeight file: launcher/interface/main.gui line: 90
[persistent.cpp:35]: Error: "Unexpected token: religion, near line: 22265
" in file: "common/dynasties/00_dynasties.txt" near line: 22265

150 times [id.cpp:83]: Failed to create id 664350 41. Already exists in game.

[texturehandler.cpp:181]: Couldn't find texture file: .
[spritetype.cpp:606]: Texture gfx\interface\minimap_area.tga have forbidden compression, have you tried DXT3?
 
Was getting the same problem. It kept happening on the same date over and over on a savegame, diagnosed it to be an unborn child by removing all events from said date one by one. The only notable thing about the parents was that the mother has some kind of a buggy graphic on her.

Do you still have the save? If you can provide it and indicate the characters involved it would help.

Had these lines in error.log:

[instanttextboxtype.cpp:92]: Not used, use maxWidth and maxHeight file: launcher/interface/main.gui line: 73
[instanttextboxtype.cpp:92]: Not used, use maxWidth and maxHeight file: launcher/interface/main.gui line: 90
Vanilla issue with the launcher, does not actually cause a problem.
[persistent.cpp:35]: Error: "Unexpected token: religion, near line: 22265
" in file: "common/dynasties/00_dynasties.txt" near line: 22265
Fixed (but there are other dynasty issues I'm working on)

150 times [id.cpp:83]: Failed to create id 664350 41. Already exists in game.
Issue with SELIN province tagging events for the reformed religions (Numahr used illegal event IDs). Fixed.

[texturehandler.cpp:181]: Couldn't find texture file: .
[spritetype.cpp:606]: Texture gfx\interface\minimap_area.tga have forbidden compression, have you tried DXT3?
Don't actually cause a problem.
 
Last edited:
Do you still have the save? If you can provide it and indicate the characters involved it would help.


Vanilla issue with the launcher, does not actually cause a problem.

Fixed (but there are other dynasty issues I'm working on)


Issue with SELIN province tagging events for the reformed religions (Numahr used illegal event IDs). Fixed.


Don't actually cause a problem.

Don't have the save itself anymore, but I do have the mother and fathers info from the backup text file I used while trying to find the problem.

Mother:
1743355=
{
birth_name="Alamanda"
female=yes
birth_date="1058.1.22"
spouse=1712016
attributes=
{
6 5 9 5 3 }
traits=
{
1 344 44 85 75 83 82 338 }
religion="catholic"
culture="catalan"
dynasty=0
dna="rzjdsczpnlb"
properties="0g0gfe00000"
fertility=0.800
health=6.000
prestige=292.750
piety=98.150
title="title_ruler_consort"
wealth=14.00085
employer=1712016
host=1712016
unborn=
{

{
mother=
{
id=1743355
type=46
}

father=
{
id=1712016
type=46
}

date="1086.8.26"
}
}
estimated_monthly_income=0.10000
estimated_yearly_income=1.20007
estimated_yearly_peacetime_income=1.20007
averaged_income=0.20001
ledger=
{
income=
{
0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 14.00085 0.00000 0.00000 0.00000 }
lastmonthincometable=
{
0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.10000 0.00000 0.00000 0.00000 }
lastmonthincome=0.10000
}
flags=
{
LE_ST=1084.8.18
}
modifier=
{
modifier="illumination"
date="1.8.18"
inherit=no
hidden=no
}
ambition_date="1082.8.9"
}
Father:
1712016=
{
birth_name="Ramon"
historical=yes
birth_date="1053.1.1"
father=722
spouse=1743355
spouse=1736707
attributes=
{
4 5 8 7 8 }
traits=
{
12 354 76 545 98 327 80 21 }
religion="catholic"
culture="catalan"
dynasty=100204
dna="hcrblqbgqii"
properties="clohck00000"
designated_heir=0
fertility=0.500
health=5.000
prestige=148.766
piety=477.240
demesne=
{
job_spymaster=no
job_marshal=no
job_chancellor=no
job_treasurer=no
job_spiritual=no
capital="b_lleida"
liege_troops=
{
light_infantry=
{
5 531 }
heavy_infantry=
{
5 332 }
light_cavalry=
{
4 447 }
archers=
{
0 80 }
}
raised_liege_troops=
{
15057 15058 15059 }
my_liegelevy_contribution=479
military_techpoints=0.000
economy_techpoints=0.000
culture_techpoints=0.000
liegelevy_reinforcements=
{
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 }
}
job_title="job_treasurer"
wealth=91.62344
employer=1712016
host=722
estimated_monthly_income=1.38922
estimated_monthly_expense=0.24423
estimated_yearly_income=16.67065
estimated_yearly_peacetime_income=16.67065
averaged_income=1.40676
ledger=
{
income=
{
79.08847 12.21212 4.53628 0.00000 7.39099 0.00000 104.00000 0.00000 0.00000 0.00000 }
lastmonthincometable=
{
0.80801 0.08120 0.00000 0.00000 0.00000 0.00000 0.50000 0.00000 0.00000 0.00000 }
lastmonthincome=1.38922
lastmonthexpense=0.24423
}
flags=
{
asked_spymaster_petition=1069.11.1
asked_marshal_petition=1070.5.28
liege_informed=1073.10.1
LE_ST=1078.3.17
asked_treasurer_petition=1081.1.2
successful_holy_war_ambition=1085.7.25
}
modifier=
{
modifier="stay_strong"
date="1.9.22"
inherit=no
hidden=no
}
action="action_advance_eco_tech"
action_date="1069.12.20"
action_location=153
ambition_date="1085.8.11"
}
 
Riknap, the new version of Validator can tell which tactic groups used in enemy blocks haven't been assigned tactics. Here's the report:
--- Error 1 of 18 ---
At <mod>\common\combat_tactics.txt [massive_longbow_volley_tactic\enemy\group] (Line 6432, column 3):
"sk_charge" is not a valid TacticGroup.
--- Error 2 of 18 ---
At <mod>\common\combat_tactics.txt [massive_longbow_volley_tactic\enemy\group] (Line 6428, column 3):
"sk_harass" is not a valid TacticGroup.
--- Error 3 of 18 ---
At <mod>\common\combat_tactics.txt [sk_sc_intricatecomplexadvance\enemy\group] (Line 2865, column 3):
"sk_mountedcombineddefensive" is not a valid TacticGroup.
--- Error 4 of 18 ---
At <mod>\common\combat_tactics.txt [sk_sc_intricatecomplexadvance\enemy\group] (Line 2861, column 3):
"sk_combinedarmsadvance" is not a valid TacticGroup.
--- Error 5 of 18 ---
At <mod>\common\combat_tactics.txt [sk_sc_intricatecomplexadvance\enemy\group] (Line 2857, column 3):
"sk_defensivetraps" is not a valid TacticGroup.
--- Error 6 of 18 ---
At <mod>\common\combat_tactics.txt [sk_sc_methodicaladvance\enemy\group] (Line 2822, column 3):
"sk_mountedcombineddefensive" is not a valid TacticGroup.
--- Error 7 of 18 ---
At <mod>\common\combat_tactics.txt [sk_sc_methodicaladvance\enemy\group] (Line 2818, column 3):
"sk_combinedarmsadvance" is not a valid TacticGroup.
--- Error 8 of 18 ---
At <mod>\common\combat_tactics.txt [sk_sc_methodicaladvance\enemy\group] (Line 2814, column 3):
"sk_defensivetraps" is not a valid TacticGroup.
--- Error 9 of 18 ---
At <mod>\common\combat_tactics.txt [sk_sc_generaladvance\enemy\group] (Line 2775, column 3):
"sk_mountedcombineddefensive" is not a valid TacticGroup.
--- Error 10 of 18 ---
At <mod>\common\combat_tactics.txt [sk_sc_generaladvance\enemy\group] (Line 2771, column 3):
"sk_combinedarmsadvance" is not a valid TacticGroup.
--- Error 11 of 18 ---
At <mod>\common\combat_tactics.txt [sk_sc_generaladvance\enemy\group] (Line 2767, column 3):
"sk_defensivetraps" is not a valid TacticGroup.
--- Error 12 of 18 ---
At <mod>\common\combat_tactics.txt [sk_sc_bungledadvance\enemy\group] (Line 2717, column 3):
"sk_mountedcombineddefensive" is not a valid TacticGroup.
--- Error 13 of 18 ---
At <mod>\common\combat_tactics.txt [sk_sc_bungledadvance\enemy\group] (Line 2713, column 3):
"sk_combinedarmsadvance" is not a valid TacticGroup.
--- Error 14 of 18 ---
At <mod>\common\combat_tactics.txt [sk_sc_bungledadvance\enemy\group] (Line 2709, column 3):
"sk_defensivetraps" is not a valid TacticGroup.
--- Error 15 of 18 ---
At <mod>\common\combat_tactics.txt [sk_as_arcedarrowassault\enemy\group] (Line 678, column 3):
"sk_ambush" is not a valid TacticGroup.
--- Error 16 of 18 ---
At <mod>\common\combat_tactics.txt [sk_as_indiscriminatebarrage\enemy\group] (Line 607, column 3):
"sk_ambush" is not a valid TacticGroup.
--- Error 17 of 18 ---
At <mod>\common\combat_tactics.txt [sk_as_heavyvolley\enemy\group] (Line 534, column 3):
"sk_ambush" is not a valid TacticGroup.
--- Error 18 of 18 ---
At <mod>\common\combat_tactics.txt [sk_as_lightvolley\enemy\group] (Line 480, column 3):
"sk_ambush" is not a valid TacticGroup.
 
One thing I've noticed is that battles are almost always decisive. The losing side is destroyed, unless it was very low morale and broke before taking serious losses.
 
One thing I've noticed is that battles are almost always decisive. The losing side is destroyed, unless it was very low morale and broke before taking serious losses.
this has probably something to do with how I lowered the threshold for the retreat phase to begin and also made it longer, thus casualties both within the battle and after the battle-proper are much higher. The intent was to make battles in LI more decisive, since our battles in general represent not one battle but a "campaign" of small-scale skirmishes and encounters (though I would indeed need to make tactics that switch to skirmish phase ... once I manage to get working on this project again)

of course, I'm not entirely sure how desirable this is. while it does eliminate ping-ponging in general, it also makes a single "battle" far more important than vanilla does, and might not exactly be desirable, depending on how exactly we want to design LI to be
 
Who are you playing as, and who are you fighting? What version are you playing?
 
I would favour battles being a rather indecisive business, in general, in LI. Big decisive battles are good for a Mod like Diadochi Kings but not for us IMO. In LI all steps to political unification ought to be frustrating and evasive... The world of LI seems to be full of Pyrrhic victories. But of course the problem of ping-ponging looms close so I recognize that this is a fine balance.
 
An example of ABCDE causing huge casualties:

Center flank of attacker taking 1614 casualties, using Collateral-Casualty Cavalry Charge against Raid Tactic. Leader of the attacking flank has 9 martial, tough soldier, no combat traits, leader of the defending flank is 23 martial, brilliant strategist, flat terrain expert and trickster. Defending flank takes 156 casualties while being attacked by another flank as well (Failed Advance Tactic, 12 martial, no combat traits)
 
that sort of makes... some sense, at least in paper. Also, collateral-casualty cavalry charge reduces the defence of your the attacking group as well, so it's sort-of understandable if they're going to take massive casualties.

of course, balance might need to be considered, but I'm fairly sure I made tactics not have exaggerated values, so it's probably the defines settings where I went overboard.

thanks for the heads-up.
 
Oh, that battle was on plains, as well.
 
The biggest contributor to incredibly bloody battles and general wonky battle results is the collateral casualty cavalry charge. It seems to fire on ~25-50% of all skirmish-to-melee tactics. It also essentially wipes out all of the heavy infantry and pikes in an army, which is usually around half the army. -100% is way too extreme, unless you have a cap of martial 5 on that tactic. -200% is nothing short of absurd.
 
indeed, it looks like I misunderstood the way those modifiers worked back then. I'll be scaling down most negative modifiers and much make them less likely to fire for average-high martial skill, when I manage to get back to modding (recently there are days wherein I don't even sleep at all to rush meeting deadlines, so I doubt that'll be anytime before this last semester ends by March's end)