Sillygoy's Unit Stats Standardization, so you don't get annihilated by General's Bodyguards (for 096)

[Jurand of Cracow]

So beware ! Changing the statistics seems more subtle than you imagine !
By believing to do well maybe we completely unbalance the game ...

That said, my experience with Aragon against the Moors is really frustrating because my units, knights and militias seem weak in front of opposing lancers.

Well, the problem with too high melee rate is known and will be fixed into:
<melee-hit-rate>1.75</melee-hit-rate>

[sillygoy]

So beware ! Changing the statistics seems more subtle than you imagine !
By believing to do well maybe we completely unbalance the game ...

I don't know about that. I've taken all of Iberia as Aragon now using my rework the whole time and everything seems to make complete sense to me. I'm glad my Spear Militia aren't useless and I'm glad General's Bodyguards are no longer utterly destroying entire companies of braced spearmen in one charge. Fari Lancers are still a big threat and Berber Pikemen (as are all pikemen) are still nearly unbeatable from the front.

I'd even be so arrogant as to suggest that they officially incorporate this rework into the next version of SSHIP precisely because of how unbalanced combat in it is. Sure melee_hit_rate is a factor but really in practical effect it's just a multiplier for the stats, which are completely out of whack even for core, massively relied upon units such as your humble spear levies.

[Jurand of Cracow]

Example from RRRC20:

Altering melee-hit-rate has implications for stamina - if kill rates are too low then heavy armored units are at too great a disadvantage, they will tire too easily and be exhausted half way through the battle (the heat values are an attempt to depict the relative heat penalties of fighting in various armors, in various climates, carrying various weapons etc.)
The heat values in various climates can be globally adjusted in descr_climates, and they will have to be balanced for any changes made to melee kill rates.

[Dekhatres]

levies are supposed to bolster numbers in defence of settlements and shouldnt be relied upon on in the field nor should they be made to, sergeants and men at arms are, levies getting trashed is gameplay wise a good thing and historically accurate

if you like levies being that strong that they can effectively form the backbone of your armies that's absolutely fine it's your preference, but i dont think it should be implemented as default in sship

[Just let me post]

I don't know about that. I've taken all of Iberia as Aragon now using my rework the whole time and everything seems to make complete sense to me. I'm glad my Spear Militia aren't useless and I'm glad General's Bodyguards are no longer utterly destroying entire companies of braced spearmen in one charge. Fari Lancers are still a big threat and Berber Pikemen (as are all pikemen) are still nearly unbeatable from the front.

I'd even be so arrogant as to suggest that they officially incorporate this rework into the next version of SSHIP precisely because of how unbalanced combat in it is. Sure melee_hit_rate is a factor but really in practical effect it's just a multiplier for the stats, which are completely out of whack even for core, massively relied upon units such as your humble spear levies.

I would like to chip in just for a moment and say that I really like your work Sillygoy. Although (in my opinion) the changes you've made... are really extensive and might be controversial. I love the general idea.

But I looked into sship's EDU a bit and I think it's really quite ok. It's just spearmen that are completely, utterly, totally, absolutely, extremely and hopelessly worthless. Imho best solution would be to just add spear_bonus +4 and double their mass. Less is more would be my motto. Again, it's just my opinion.

[Jurand of Cracow]

levies are supposed to bolster numbers in defence of settlements and shouldnt be relied upon on in the field nor should they be made to, sergeants and men at arms are, levies getting trashed is gameplay wise a good thing and historically accurate

if you like levies being that strong that they can effectively form the backbone of your armies that's absolutely fine it's your preference, but i dont think it should be implemented as default in sship

I share this opinion. I've seen many campaigns won by milita armies - something that doesn't really feel right for our period (even if one takes into account that our sources are biased towards underscoring the role of the knights given whom the chronicles were written for).
How to make the player and the AI using militias in such a way? I may imagine that:
- in general, low availability (low refill rates) and high price/quality ratios,
- the player: free upkeep only for militias in the settlements will provide an incentive to keep the militias there (if there's no free upkeep then the player would disband militias and keep knights and sergeants),
- the AI: automatic garrisons through script - composed of militias.
Plus obviously the weakness in the field against the charges, I think that the <melee-hit-rate>1.75</melee-hit-rate> will still make it reasonable? Or should it be higher, in your eyes?

spearmen that are completely, utterly, totally, absolutely, extremely and hopelessly worthless. Imho best solution would be to just add spear_bonus +4 and double their mass.

Well, I think it's true in the field when heavy cav charges into militia spearmen. But what about settlement battles? If the cav cannot charge, even militia behaves better, isnt'?

[Just let me post]

Well, I think it's true in the field when heavy cav charges into militia spearmen. But what about settlement battles? If the cav cannot charge, even militia behaves better, isnt'?

I'm not sure I fully understand your notion.
For one, if cavalry cannot charge and gets into straight up melee fight with lots of spearmen, cavalrymen should be slaughtered. I mean militias might be poorly trained and unexperienced but they are people with very sharp sticks and they aren't idiots. They should by far have upper hand in that situation.

But currenty even that favourable situation isn't reflected ingame. Spear militias have 1, maybe 2 attack value with +2 horse bonus, which is nothing even compared to standing still hacking and slashing riders. Which is nonsense.

I know it's a game and there must be some compromises due to limitations in favour of cav, but unless spearmen are routed or overwhelmed, they should beat ANY cavalry (even elite knights) hard in melee, be it militas or better.

But yeah, I agree with you and Dekhatres that militias shouldn't be relied upon, rout easily and be piss poor in combat otherwise.

P.S. to me, 1.75 melee hit rate sounds good.

[Dekhatres]

I share this opinion. I've seen many campaigns won by milita armies - something that doesn't really feel right for our period (even if one takes into account that our sources are biased towards underscoring the role of the knights given whom the chronicles were written for).
How to make the player and the AI using militias in such a way? I may imagine that:
- in general, low availability (low refill rates) and high price/quality ratios,
- the player: free upkeep only for militias in the settlements will provide an incentive to keep the militias there (if there's no free upkeep then the player would disband militias and keep knights and sergeants),
- the AI: automatic garrisons through script - composed of militias.
Plus obviously the weakness in the field against the charges, I think that the <melee-hit-rate>1.75</melee-hit-rate> will still make it reasonable? Or should it be higher, in your eyes?


Well, I think it's true in the field when heavy cav charges into militia spearmen. But what about settlement battles? If the cav cannot charge, even militia behaves better, isnt'?

1.75 hit rate is perfect setting, i've actually played about a year with this setting and i liked it a lot, i'd say it was one of the best balances i achieved with it, only problem was that infantry battles were still too fast for my taste so i instead moved to 1.0 hit rate, but that's just my preference

agreed on all points

[XXZit]

After playing with this for a bit I find it very satisfying. It isn't perfect by any means, but it is a great improvement over vanilla SSHIP.
One thing that still bothers me though, is the auto resolve. While testing my campaign AI, I usually don't do anything with my faction except to form alliances with my neighbors and pay tribute to keep them happy, then just sit back and watch the factions war with each other. This has given me the opportunity to observe the greatly unbalanced auto-resolve; more often than not, I see armies win conflicts that they shouldn't have won. I think auto resolve needs some serious adjustments as well, it needed them before and it specially needs them now, after these EDU changes.

On another note, I just released another update for my editor program, that adds a sort of tutorial mode, where it guides you by the hand to perform the changes that you want. It can be started by simply double clicking the program and is much much user friendly. I also started writing a GUI, which ought to make it easier still but that won't be ready for a while. The most important feature though, is the addition of user-defined conditions.
You can now establish an unlimited number of conditions to establish what you want to modify. For instance, you can say, I want to increase the cost of all mercenary units, that use a spear as a weapon, that are heavy armored, that are trained or highly trained, that spawn at a specific era and that are available to a specific faction. Then you can simply add or multiply the base cost by a number of your choosing instead of using a flat value(but that you already could do before). Basically, you can use any and all attributes in the EDU -at the same time if you want- as a condition or prerequisite to perform your changes. I think you guys doing EDU edits on a grand scale would really benefit from this.

By the way @Jurand, did the script that other user talked about serve your needs, were you able to use it? I'm finally back into M2TW with lots of free time, so I can definitely cook something up for you if you still need it.

[Jurand of Cracow]

Autoresolve - I've never delved into the determinant of it. I only know that the heavy units (perhaps stat armour, maybe the whole defence?) score much better results. (this is one of the secrets of the Georgia success in most of the games: very heavy units with no direct strong neighbours)
If you're interested in this aspect and would devote your time to look for information and analyse it, it would be of great help for us.

I'll definitely look into your program onced dealing with the formula for prices.

Belovese tool - it does a great job for me for I can compare units, as below for urban militias. Once I get his improved version, I'll apply my formula and present my thinking to everybody to scrutinize.

[lequintal69]

I really like the idea of this mod,
cavalry has always been overpowered, wiping out full stack of foot elite soldiers in a single charge

I found somehting a bit off tho - french lancers have worst stats than Gendarmes, while being more expensive- My french ego is hurt !

[Jurand of Cracow]

I really like the idea of this mod,
cavalry has always been overpowered, wiping out full stack of foot elite soldiers in a single charge

I found somehting a bit off tho - french lancers have worst stats than Gendarmes, while being more expensive- My french ego is hurt !

As I've already mentioned: cav charges will be much nerfed in the 097.

Prices balance - this is something I still need to work on.

[lequintal69]

Thanks!

btw, is it possible to have different stats for the same unit (same name and model) depending on faction?

[Jurand of Cracow]

afaik, not. You need different units.

[Nemesis2345]

Thanks!

btw, is it possible to have different stats for the same unit (same name and model) depending on faction?

I dont think so , you would have to make an individual unit for the said faction and there is no space for those. Almost each faction has it's own unique soldiers though , English , french, imperial knights etc. those could be edited separately.

[XXZit]

Jurand, I love your spreadsheets man. They so detailed and organized they give me a nerd-gasm lol.

I'll definitely look at the auto-resolve. It is something that has bothered me for a while, yet I've other projects on my plate right now, so that will have to wait a bit.
Speaking of which, I've expanded my program with an "Export" functionality. Any file can be read and exported into CSV format, which can then be opened by any spreadsheet program. You have the ability to filter which records you want to export, the order in which you want them to appear, split values into columns and add custom names for those columns.

Not to take anything from Belovese's work, but if this can make your work easier all the better.

This is a rather rigid first draft, but I wanted to get it out quickly in case it might help you with the last minute edits. I've not added proper safe-guards yet, or tested it extensively, so I recommend not to steer too far away from the example commands I give here.

I'm thinking about adding the reverse functionality, export from CSV to file, but I haven't made up my mind yet. I've other things I want to do first, like refactor the code and finish the GUI. Plus I'm not entirely convinced of the value of such a feature.

Here's an example screenshot. You'll have to forgive my lack of creativity. It isn't as pretty or organized as your table




Behavior:
Records to export are passed to the program through an "Export" line, adhering to the following format:

-E "type, dictionary, stat_mental, cost, stat_pri, ownership, etc, etc"

The order in which you type the records here will determine the order the record will have in the CSV file.
Only records specified in this line will be extracted by the program. This makes it possible to obtain custom versions of a file, showing only specific, pertinent records. It is possible to further refine this by using section markers to limit the output to specific units, resulting in the retrieval of the records you specify but only of those units, for instance, only records of cavalry or infantry or heavy armored units.

The value of a record can be split into into multiple columns, and you can give custom names to each one. This is useful for records like stat_pri that have composite values. This can be done by telling the program to interpret a specific record as a composite record, then establishing a set of bastard records for that composite record:

-E "type, dictionary, {[stat_mental]unit morale, discipline, training status, disc_lock}, cost, {[stat_pri ]attack, charge bonus, missile type}, ownership, voice_type, etc, etc"

In the above case, both stat_mental and stat_pri will be parsed as composite records, with every name after "]" and before "}" being interpreted as bastards. Composite records are positioned in the same line as primary records, while bastard records are positioned one row below. The value of the composite record will be split according to the number of bastard records specified. If there are more fields in the value than bastard records, the remaining values will be dumped in the last bastard, whereas if there are more records than values in the composite record, the excess bastards will have no value.

Both primary records and composite records must written exactly as they appear on the text, or they won't be found. Bastard records can have any name since they are simple additions and not scanned in the text. The program shall issue a warning when it detects primary or composite records that can't be found in the text. Records that are found partially, like "voice" instead of the complete "voice_type" will not trigger such warning. For all intents and purposes, composite records with no bastards defined are interpreted as primary records.

EDIT: Bastard records can be marked as optional by using a "*" before their identifier as in

 {[...] , , , *record, , , ...}

Optional bastards will not be filled, unless the number of records matches the number of elements in a the value field.

By default, the program will clean all characters that aren't letters or numbers, including excess spaces. A list of characters can be passed with important characters that should not be deleted, in this fashion:

-p "-;,()"

Comment lines can be exempt from being exported by specifying a comment character. This does not affect comments after a valid line -which will always be exported- but only those lines starting with a comment:

-t ";"

The delimiting expression -used to parse the CSV by a spreadsheet program- can be set with the option:

-e "\t" -S

that sets the delimiting expression to be a tab, which is the most conflict free delimiter for a file like the EDU that already contains commas, and spaces.

Section markers must be specified. If there's no interest in filtering the output to particular unit or type, empty lines can be used as markers:

-m "\n\n" -n "\n\n" -S

That will parse the whole document in blocks separated by one empty line.

-m "category infantry class heavy" -n "\n\n" -S

That will parse (and export) only heavy class infantry units, in blocks starting from the point "category" is found, all the way until the first empty line at the end of the block.

The file to read is specified with the -f flag. The name of the output csv is specified with the -o flag.

Here's a functional complete example line, to export the EDU into csv, using tabs as the delimiting character (important to select tabs only when opening it in the spreadsheet program):

streditor.exe -m "\n\n" -n "\n\n" -S -E "type, dictionary, attributes, ownership, mount, {[stat_pri ]attack, charge bonus, missile, missile range, ammo count, weapon type, tech type, damage type, sound, effect sound, min delay, skeleton, bonus vs mounted}, category, {[stat_mental]morale, discipline, training}, voice_type, soldier" -f "export_descr_unit.txt"  -p"-;," -e"\t" -o "EDU.csv" -t ";"

Although, you'll have to type in quite a bit more records if you want to export everything, specially if you want to split all the composite records into multiple columns.

Hope this helps

PS: I've not added any of this to the program's documentation yet.

[Jurand of Cracow]

I was screaming for programs with functionality of moving from EDU to .csv for years, and now instead of one, we've got two!
I think it's a great starting point.

Over the last few days I've been using the Belovese program to find discrepancies in the EDU file. I've imported data and created my formulas to assess the value of the units. These are rough approximations, but it's better to be roughly right than entirely wrong.

The most recent EDU is here, I'm still making changes in it.

Working file with formulas is here. Obviously, work in progress.

If you play a game with the SSHIP, you may use the recording file that I'm using to compare my games between them.

[Belovèse]

@xxzit, so cool that you've put this fonction in your program, it is (as expected) much more flexible that what I could do. I think a GUI will garantee mass adoption!

@JoC, could you elaborate a bit on how you use your recording file?

[Jurand of Cracow]

While playing record at times (eg. every 30 turns) the "budget" table. I also like to know probabilities for education or which benefits I'll draw from a PT of certain province. I also record the situation in provinces. But it's up to any player how he like to play. To compare it's the budget table.

[XXZit]

Well the idea is to have a general purpose export functionality that works for any file, not just the EDU, hence all the typing required. I know that seems like a lot of work, so I took the liberty to export in full the latest EDU you posted, Composite fields are correctly split into multiple columns with optional values in their proper field. I gave the sub-columns placeholder names though since I don't know the correct ones, but I'm sure you can change that easily from a spreadsheet. Other than that, all records seem to be in order and error free.

I also exported the EDA from the last beta build you sent. With just the Ancillaries though, I noticed an impasse in the generic one-fits-all approach I'm using in my program that makes it problematic to parse the conditions in the triggers correctly, so I'll have to rethink things. Still, I hope the ancillaries alone can be of some help to compare things and catch errors.

By the way, the idea of keeping different records with metrics of played games is fantastic. I don't know how I never thought of that before. Your "recording" file will be most useful!