Author Topic: Improving the auto resolve system  (Read 7527 times)

0 Members and 1 Guest are viewing this topic.

Mordachai

  • Squire
  • *
    • View Profile
  • Faction: Neutral
Re: Improving the auto resolve system
« Reply #15 on: April 01, 2009, 09:36:35 PM »
Yes, there is a 48hr timer that checks for lords of an active faction, looks for a walled center of that faction that isn't under siege, and then spawns said lord with a new party there.

Nemeo

  • Sergeant at Arms
  • *
    • View Profile
  • Faction: Neutral
Re: Improving the auto resolve system
« Reply #16 on: April 01, 2009, 09:52:13 PM »
I looked at the damn code after the inflict_casualties_to_party_group operation, and it checks the strength of the party. If the strength is null, the battle ends and the battle resolution script starts. But I can't get rid of that last guy! He is in a stack of wounded soldiers, so there's no reason he doesn't get hit as well.

How do you improve the auto resolve system without tweaking that script ?
Seigneur, s'il y a un seigneur, sauvez mon âme, si j'ai une âme. - Ernest Renan (1823-1892)

kt0

  • Knight
  • *
    • View Profile
  • Faction: Swadian
Re: Improving the auto resolve system
« Reply #17 on: April 02, 2009, 04:25:25 AM »
Step 1: folks complain about auto-resolve (it sucks).
Step 2: folks think about how to improve it and quickly hit wall realizing that most of the important information such a function needs is not in MS - no way to know armor value of armor, or weapon damage values of weapons, so hard to write anything that takes these into account
Step 3: Rubik solves for how to bring this info into MS using Python & slots trick.
Step 4: <- You are here...

 8-)
Ok, Mord, that's twice now you've used your Ebil Jedi mind tricks on me to make me write a bunch of code.  Knock it off.  (You should have a talk with my boss :P)

If you want to mess with this stuff, please take the time to figure out what it does.  There are going to be bugs.  Let me know where they are.  This will slow down both your compile times and your game init times.  Also, read the trailer below:  there will be more code.

BLAM!

Stick this at the top of your module_scripts.py:
(click to show/hide)

Stick this at the bottom of your module_scripts.py:
(click to show/hide)

New slot values in module_constants.py, I stuck them after the rebellion changes:
(click to show/hide)

In an ideal world, I would have gotten home at a reasonable time from work and would have had time to parse all the item values as well.  That's not the world I live in.  (For those wondering, this is exactly what I meant when I kept talking about "hacking up the compile code", rubik just beat me to it ;))

This is just groundwork; the better thing to do which I will explore tomorrow after work (provided I'm home at a reasonable hour) is to do the strength and defense calculations at compile time where the auto-gen code lives rather than trying to do it in script.  It will be much faster.  Then I can go back to the strength calculation and do something sane.  That plus the strength calc code I posted the last time I posted code and a quick jaunt through all six instances of autoresolving completes the deal. 

WATCH THIS SPACE!

edit:  needed more BLAM

Twan

  • Sergeant Knight
  • *
    • View Profile
    • SoD Auxiliarii Variant
  • Faction: Neutral
Re: Improving the auto resolve system
« Reply #18 on: April 02, 2009, 07:51:32 AM »
Wow so it's possible to use a generic system instead of 500 lines of tries to fill the bonuses slots.

I think a complete storing of units attributes etc... isn't needed anyway as most of the factors are already included in troops level and autoresolve hasn't be so detailed that it makes difference between 2 usefull skills or attribute (I mean there are 2 stats and 6 skills usefull in combat, it's interesting to know if an unit has a bonus in these compared to other units of equal level, not necessary to know which stat/skill exactly is better, or the value of stats having no effect in combat).

More needed is to analyze the items an unit is (or may be) carrying as gear especially armor quality make more difference than skills, and as weapons categories are the main factor to give a relevant bonus for each kind of fight (I guess it's doable with an init giving slots to items first, then for each unit making a calculation based on the values of items it may carry ; the problem here is the fact the item list is a potential so if say an unit may have 5 different weapons/armors the value should be either an average or based on a probability).

ps :

Quote
Only cowards and whoremongers use autoresolve! The mighty Frodogorn commands this heresy to cease!

The main goal of changing autoresolve is to make fight between AIs when the player is not there give about the same results as a 3d fight, ie making archers more deadly in sieges situations or a force of cavalry fighting an infantry one in plain able to win easily.
For fights with player's army the best way to improve battle simulation is just to completely remove autoresolve, like it's done in sword of damocles (instead of being forced to autoresolve when you are knocked out, you are allowed to watch the end of the fight).
« Last Edit: April 02, 2009, 09:29:08 AM by Twan »

+Knight

  • Regular
  • *
    • View Profile
  • Faction: Neutral
Re: Improving the auto resolve system
« Reply #19 on: April 02, 2009, 11:53:38 AM »
You men are making the world better :D As the battles are the essence of M&B and improving them is the primary task of the strange guys prefering modding the game to playing it (it's haunting me, I've never finished STALKER:SHOC because of writing scripts for it, and now the same story with M&B, I've been playing it for a couple of weaks maybe :shock:).

2 Nemeo
I did't get what is your goal in redirecting  from inflict_casualties_to_party_group to  inflict_casualties_to_party. Do you want the AI lords to die in battles occasionally and their parties to disband? Maybe make them deserters instead of disbanding?

instead of being forced to autoresolve when you are knocked out, you are allowed to watch the end of the fight.
Yes, this is must have!

I have a question about realtime battles. The archers act quite intelligently: they are firing at distant enemy while hiding their bows and trying to fight the close enemy with their penknives :) And what about cavalry? AFAIK they randomly choose between spears and say swords from their inventory. Ideally, they should always charge with spears, and change them to something more handy if they get stopped, surrounded by infantry or unhorsed. Is it just me or cavalry AI is acting inefficiently? If I am correct, is it possible to make it the proper way?
« Last Edit: April 02, 2009, 11:56:25 AM by +Knight »
NOT PEACE BUT A SWORD

Nemeo

  • Sergeant at Arms
  • *
    • View Profile
  • Faction: Neutral
Re: Improving the auto resolve system
« Reply #20 on: April 02, 2009, 12:24:57 PM »
The wounded ratio seemed a bit high to me. And the battle were a bit slow to me. I doubled the parties strength before the battle, which doubled the speed of the fight (I think), and I'll do with the high wounded ratio. Now I'm just curious about how this damned game works in autoresolve. Why this single guy survive everytime, when his fellows in the stack all died? I mean, all stacks are hit, which means that they are all affected by the inflict casualties. And in other stacks, every soldiers died, which means that the range of the condition is ok. This makes no sense to me. I think that this **** is the reason why the battle never ends, the party never triggers the 0 strength condition.

My last request and I promise (or at least I'll try to) I leave this forum in peace.

Could anyone be so kind as to point me to me every instance directly involved in the autoresolving processes ? What I want to do is "simply" to add a template to all archers, and bonuses to their strength in siege. Simply. :lol:

edit: nevermind, I've found them six. The battle calculation is simplified but I find it quite satisfying for my mod. Defender strength is multiplied by 2.5. Except when the player is defending (x2 only, thanks for taking care of us armagan ;) )

but isn't this a problem:

           (store_div, ":defender_strength", ":defender_strength", 20),
           (val_min, ":defender_strength", 50),
           (val_max, ":defender_strength", 1),
           (store_div, ":attacker_strength", ":attacker_strength", 20),
           (val_min, ":attacker_strength", 50),
           (val_add, ":attacker_strength", 1),

Doesn't this limit strength to 50? 60 huscarls would be enough to reach this cap. Or Am I wrong?

Another problem: AI vs AI on the map, castle defenders only have x1.5 while it's 2.5 when the player party is involved.
« Last Edit: April 02, 2009, 02:16:50 PM by Nemeo »
Seigneur, s'il y a un seigneur, sauvez mon âme, si j'ai une âme. - Ernest Renan (1823-1892)

kt0

  • Knight
  • *
    • View Profile
  • Faction: Swadian
Re: Improving the auto resolve system
« Reply #21 on: April 02, 2009, 03:48:50 PM »
Wow so it's possible to use a generic system instead of 500 lines of tries to fill the bonuses slots.
Technically it's still a set of 500 lines, just not 500 lines that we have to write ourselves. 
Quote
I think a complete storing of units attributes etc... isn't needed anyway as most of the factors are already included in troops level and autoresolve hasn't be so detailed that it makes difference between 2 usefull skills or attribute (I mean there are 2 stats and 6 skills usefull in combat, it's interesting to know if an unit has a bonus in these compared to other units of equal level, not necessary to know which stat/skill exactly is better, or the value of stats having no effect in combat).
For the task at hand, yes, storing all stats and six skills is probably overkill but other than a small investment in time it isn't likely to break anything either.  I also don't doubt that someone along the line will find the above useful, and if I've saved someone the trouble, that's a win in my book.  I do believe that some of the information we're trying to divine at compile time should be available through the module system but it isn't.

Quote
More needed is to analyze the items an unit is (or may be) carrying as gear especially armor quality make more difference than skills, and as weapons categories are the main factor to give a relevant bonus for each kind of fight (I guess it's doable with an init giving slots to items first, then for each unit making a calculation based on the values of items it may carry ; the problem here is the fact the item list is a potential so if say an unit may have 5 different weapons/armors the value should be either an average or based on a probability).
Compile time analysis of equipment is on the way.  Either I'll get to it this evening/tomorrow or someone else will, though I wouldn't disregard the influence of skills on unit toughness so readily.  An ideal solution in my eyes for posting this kind of code is to show people what's possible and a sample implementation that they can hack up for their particular needs.

Mordachai

  • Squire
  • *
    • View Profile
  • Faction: Neutral
Re: Improving the auto resolve system
« Reply #22 on: April 02, 2009, 03:49:52 PM »
the 1.5 and 2.5 type stuff is good to move to constants.py - put that sort of stuff there, and you can tweak your compile to generate the numbers you want - and by using the constants in all six autoresolves, then they become consistent.  Just a thought ;)

kt0

  • Knight
  • *
    • View Profile
  • Faction: Swadian
Re: Improving the auto resolve system
« Reply #23 on: April 02, 2009, 04:11:54 PM »

Quote
but isn't this a problem:

           (store_div, ":defender_strength", ":defender_strength", 20),
           (val_min, ":defender_strength", 50),
           (val_max, ":defender_strength", 1),
           (store_div, ":attacker_strength", ":attacker_strength", 20),
           (val_min, ":attacker_strength", 50),
           (val_add, ":attacker_strength", 1),

Doesn't this limit strength to 50? 60 huscarls would be enough to reach this cap. Or Am I wrong?

Another problem: AI vs AI on the map, castle defenders only have x1.5 while it's 2.5 when the player party is involved.
If you have questions about how the autoresolve does its thing, it's probably worth it to read through the original thread as posted above.  I go through what all the stuff does and even posted some code that tries to fix some of its shortcomings.  Of particular note I go through what the strength calculation is and how it's (mis)used in the solver and how the normalization steps screw up strength calculations for very large and/or skilled armies.

In response to your particular question, yes, the normalization effectively puts a cap on how many troops factor into the strength calc on a level basis.  If you hunt around in the code you'll find lots of places that aren't consistent like your 1.5 and 2.5x.  Some of thes are probably intentional but the authors didn't leave us any notes as to their intent.

Of other note, you might also turn off the thing where autoresolve troops won't fight at night  :mrgreen:

Twan

  • Sergeant Knight
  • *
    • View Profile
    • SoD Auxiliarii Variant
  • Faction: Neutral
Re: Improving the auto resolve system
« Reply #24 on: April 02, 2009, 04:27:00 PM »
Technically it's still a set of 500 lines, just not 500 lines that we have to write ourselves. 

Was an allusion to the (rather long and uneleguant) code I've used to give terrain bonuses in my mod.

(something like
Code: [Select]
(try_for_range, ":troop_no", soldiers_begin, soldiers_end),

(try_begin),
(eq, ":troop_no", "trp_blabla_1"),
(assign, ":bonus", x),
(else_try),
(eq, ":troop_no", "trp_blabla_2"),
(assign, ":bonus", y),

(etc... for all troops)
(try_end),
(troop_set_slot, ":troop_no", slot_bonus, ":bonus")

(was even more complex as I was giving each unit several notes based on weapons used, armor etc... to then calculate a different bonus for each terrain)

Quote
For the task at hand, yes, storing all stats and six skills is probably overkill but other than a small investment in time it isn't likely to break anything either.  I also don't doubt that someone along the line will find the above useful, and if I've saved someone the trouble, that's a win in my book.  I do believe that some of the information we're trying to divine at compile time should be available through the module system but it isn't.

You are right. Was just thinking of the immediate use for autoresolve.

Quote
Compile time analysis of equipment is on the way. 

Thanks a lot for all this work. You just saved people like me who don't understand python out of the functions used in module system, but are sufficiently crazy to make a code with 462 (else_try) to get this kind of value from deadly headaches. ;)
« Last Edit: April 02, 2009, 04:31:03 PM by Twan »

MartinF

  • Squire
  • *
  • Down Under
    • View Profile
  • Faction: Neutral
Re: Improving the auto resolve system
« Reply #25 on: April 02, 2009, 05:55:01 PM »
if you're going to do compile time analysis of skills and equipment for use in a script like this, it might be worth looking at some sort of classing system. That would slim the code down considerably.

if you're going to use a rock/paper/scissors type model for the auto-resolve, you could define the base types for use in that at compile time and then when you're actually going to resolve, you can just read one slot to get the type, rather than having to go through try blocks.

Similarly this could be something to be used for improved formation scripts (which is something that's on my to-do list)

so 'spearman', 'swordsman', 'archer', etc. Or branch it out a bit more, would have to think for a reasonable system that's not too convoluted but covers the basics.

Mordachai

  • Squire
  • *
    • View Profile
  • Faction: Neutral
Re: Improving the auto resolve system
« Reply #26 on: April 02, 2009, 05:55:51 PM »
Quote
Compile time analysis of equipment is on the way. 
Rubik has done some of that in his Autoloot enhancement kit.

I have taken that a bit further in SoD, including multiple data points for imods.  I'll try to publish a kit later today based on my current Autoloot, which will give you all the item data you could possibly want ;)

Also, its easy to extend these things and add additional tables of information that have nothing to do with the MS code - purely for your own autoresolve - perhaps specifying a "classification" for each troop type, as Martin is essentially suggesting.
« Last Edit: April 02, 2009, 05:58:43 PM by Mordachai »

kt0

  • Knight
  • *
    • View Profile
  • Faction: Swadian
Re: Improving the auto resolve system
« Reply #27 on: April 02, 2009, 07:17:10 PM »
Quote
Compile time analysis of equipment is on the way. 
Rubik has done some of that in his Autoloot enhancement kit.
Yep, I've been all through rubik's stuff to see what he was doing.  I was talking more about applying such thoughts to troop calculations.  This stuff generally isn't really that hard.  I just wish I had more time to futz with it :)

My general thoughts were to chug through all the item data and build an aggregate value for gear.  From there, do more maths and write an offense and defense value to specific slots and use that in the autoresolvers.  Trying to divine the class of a troop from skills and equipment is an interesting problem which I might put some thought into for other purposes, but I'm not sure I'd use more than very basic info during autoresolve either way ("is always mounted" for instance).  That should suit my purposes well enough.  I'm less interested in making it fun for the computer than I am making it at least somewhat more fun for the player  :mrgreen:

kt0

  • Knight
  • *
    • View Profile
  • Faction: Swadian
Re: Improving the auto resolve system
« Reply #28 on: April 03, 2009, 04:27:15 AM »
BLAM! (Part deux)
In this installment of "kt0 uses his least favorite scripting language next to Perl", I've parsed and mungified the item data for each item on a given troop into two values for Offense and Defense and have stuffed them into appropriate slots.  I've made other modifications as well like not filling out the slots that aren't important to the calculation.  Tomorrow (the fates willing) I'll get to the strength calculation and autoresolve changes though astute readers should be able to fill in the blanks appropriately.

I've made a lot of assumptions and fudges here not limited to:
  • assuming how the item picker works esp. if tf_guarantee flags aren't specified
  • increasing blunt damage by 25%
  • increasing pierce damage by 50%
  • giving weird weights to lots of stuff like horse charge and armor

If you try to use this code, you will find bugs.  As always, let me know where they are.  Other than that, feel free to modify to your particular needs. 

This stuff goes at the top of module_scripts.py:
(click to show/hide)

Stick this at the bottom of your module_scripts.py which is the same as last time:
(click to show/hide)

New slots in module_constants.py but not all of them used now:
(click to show/hide)

Data generated from Native troops for your perusal (name, o_val, d_val, old strength value):
(click to show/hide)

On a somewhat related note, why the crap does the code tag kill spacing?!  Especially bad for python   :?

MartinF

  • Squire
  • *
  • Down Under
    • View Profile
  • Faction: Neutral
Re: Improving the auto resolve system
« Reply #29 on: April 03, 2009, 05:50:24 AM »
nice work.

Just some feedback from a quick look at your numbers there. Obviously I don't know exactly how you're going to do the calculations in the script so I might be speaking out of turn.

Seems to be atm that mounted troops are not getting much in the way of an offensive (or defensive) bonus. Again, perhaps you are going to fix this in the scripts in which case you may disregard this, but for example vaegir knight vs nord champion. Similar defenses but the champion has about 1,5 times the offense rating.

in MNB especially, mounted units have a huge advantage in missions due (in part) to the poor combat system. So this is not really a realistic representation of that.

This list also explain why rhodoks = lose :)