Fighting Withdrawals

A new section for modding SOW Waterloo. Ask questions, post tips here.
Post Reply
mcaryf
Reactions:
Posts: 236
Joined: Fri Jun 12, 2015 8:19 pm

Fighting Withdrawals

Post by mcaryf »

I had a really enjoyable and interesting fighting withdrawal sequence in a recent game that had not occurred in any of my other experiences with SOW so I thought I would share it with you.

The sequence occurred in a new variant of Ligny I have just started testing that removes the various errors made by both sides in deploying their forces on the 15th and 16th June. Thus Bulow will arrive between 6 and 7pm to participate in Ligny but all the French forces will have been in position ready to start the battle at 11.30am. The available French force includes Lobau’s VI Corps whose units can be deployed (from Villers Perwin) either to Ligny or to QB early in the battles as the player decides.

In this sequence I had chosen to deploy just Simmer’s division and the Corps artillery to Ligny where they were positioned on the edge of the map East of Brye. The other two Divisions in VI Corps would be used to help Ney hold back Wellington’s army at QB as this would also be arriving earlier and in greater strength. My expectation was that I would use Simmer in conjunction with units of the Guard Light Cavalry, also arriving from the QB map but further south than Simmer (I excluded the 4 x Guard Lancer Squadrons that Ney did historically use). I expected this small force to make a nuisance of itself on the Prussian flank and hopefully distract a few reinforcements that might otherwise delay the critical French breakthrough at Ligny or St Armand which must succeed before either Bulow or possibly Wellington arrives.

The Prussian’s rapidly detected Simmer’s presence and sent most of the infantry from Pirch’s II Corps to deal with him. I had put a 2 hour random variation in the arrival time for the Guard Cavalry and it was nowhere to be seen as what looked like 30 or so Prussian Battalions and a dozen or so skirmisher units pressed forward against my 9 x battalions. I conducted a fighting withdrawal over quite a long distance southward to where the Guard Cavalry should eventually appear and also sent a brigade of Vandamme’s cavalry as reinforcements from some further distance away. Fortunately the AI neglected to bring artillery with the pursuing infantry force. As my two artillery batteries were about to be overwhelmed by skirmishers, the Guard Cavalry put in a belated appearance and drove the skirmishers back. By this stage I had 8 somewhat battered infantry battalions (I had sacrificed one to buy time for the others to withdraw) against what looked like three times that number but I now also had 5 squadrons of elite cavalry plus 4 artillery batteries including the Corps 12lb guns. Lobau himself had unfortunately been killed as I had concentrated on withdrawing the fighting units. It was a very close run thing but I just had time to use the all arms task force to create variations of Darkrob’ fort formations and held out until Vandamme’s additional cavalry reinforcements came. At that stage the remnants of the battered Prussians pulled back.

I was impressed by the way the AI initially pursued me with lots of skirmisher units but less so with it forgetting its artillery. I did lose one battery but that was to a sneak AI cavalry attack in another part of the battlefield whilst I was concentrating on Simmer’s desperate defence. I think the best way to make the AI a real challenge for a human is to get it to mount attacks in widely separated parts of the battlefield forcing the human to also use his own AI commanders. I will try to program more of that aspect into these battles as I develop them further.

When the situation first occurred and I expected that my lone division would be destroyed, I thought I should re-design the scenario so the Guard Cavalry would always arrive at the same time as Lobau. However, as I actually enjoyed the fighting withdrawal so much, I think I will leave that possibility as it is so the cavalry may be able to “come over the hill” at the last minute as it did for me this time.

This was only my first run through of the scenario so I have a fair bit more development and testing to do before I can publish it.

Regards

Mike
DarkRob
Reactions:
Posts: 352
Joined: Mon Aug 15, 2016 5:56 am

Re: Fighting Withdrawals

Post by DarkRob »

The AI would be so much better on the attack if it was just more aggressive with it's artillery. Part of the reason my formations are so devastating against it is simply that I do the things with my guns that the AI won't, but could.

If the enemy AI started moving batteries into ranges where it could start pounding away on the infantry formations that make up the Fortress, then I'd have to rethink everything.(which would be fun actually as I've really gotten bored of using my tactics because of how dominant they are) But it won't, so I don't.
Last edited by DarkRob on Wed Aug 22, 2018 3:45 am, edited 1 time in total.
mcaryf
Reactions:
Posts: 236
Joined: Fri Jun 12, 2015 8:19 pm

Rates of Fire

Post by mcaryf »

I am afraid this post does go into some detail about how the game seems to work, it will probably be of more interest to those who like to mod. The conclusion it reaches is that the standard game does not give better units enough advantage in artillery rates of fire. The issue is rather similar to that identified in my cavalry mod where melee outcomes were too random but in the case of artillery effectiveness the impact on game play is probably real but less immediately obvious.

I had been thinking about how I could make the AI a better opponent so I started looking at rates of fire values. My mod made artillery more lethal, especially for canister, so I originally implemented slower and I thought more realistic rates of fire. In the standard game the basic rate of fire for a 6lb gun is one shot per 30 seconds and one per 60 seconds in my mod. My new thought was that I could put the rates of fire back to the standard values for the AI but leave them at my slower rate for the human player. For those who do not do modding I should say that it is possible to set different rates of fire for each gun type by nationality.

I had not previously thought about why the artillery.csv file had two values "rate of fire" and "maximum rate of fire". For 6lb guns the maximum rate in the standard game is one shot every 23 seconds. So I started to wonder when the "maximum rate" would be applied. My first thought was that guns might fire quicker when threatened but I have never actually detected that happening. I then looked at the attributes that each unit has and discovered that units with higher experience ratings have attribute values that reduce the number of seconds between each shot and I assume that is where the maximum is applied. For elite units the maximum reduction in time between shots is 16 seconds. Thus in the standard game the elite units should take 16 seconds less between shots than an untrained unit. However if the best rate of fire is 23 seconds and the standard rate is 30 seconds then the maximum improvement possible is 7 seconds which is only 1 second shorter than "volunteers" in the standard game who get a 6 second reduction, even Militia get a 3 second reduction! So elite units only get a 4 second advantage in rate of fire for 6lb guns versus Militia! I then assumed that other attributes, such as fatigue, might also impact rate of fire so the better units would gain in that situation but actually no other attribute in the standard game effects rate of fire. In the standard game the differences between the maximum rates of fire versus the normal for all types of artillery is lowest for the 6lb gun at 7 seconds but it is never greater than 12 seconds so the better trained/experienced regiments do not really get much if any benefit from this attribute.

I have therefore added further changes in my artillery mod by making fatigue cause rates of fire to be lower but giving up to 4 seconds further improvement based on the firearms' proficiency attribute. The longer time intervals between shots in my mod do mean that elite units can take full advantage. However to give the AI a better chance I have adjusted all the AI rates of fire so they are faster than a human player whilst their elite units can still get full advantage from their ratings so all the AI guns will have their normal rates of fire set at 20 seconds above the maximum. Thus my human player will have 60 second between 6lb shots reduced to 40 seconds for elite units without fatigue penalties whilst the standard value for AI units will be 43 seconds which will be reduced to 40 seconds for Prussian Militia!

I hope this will help the AI to be a slightly better opponent although the main problem is that it does not bring its guns close enough. However, my much longer range canister does help it somewhat.

This might have been all rather complicated but if you are still reading I can tell you that the situation for muskets etc is not so bad as in the standard game the normal rate of fire is one shot per 40 seconds and the maximum is one per 20 seconds. Thus the elite units can take advantage of their better training for muskets.

For those of you who use the KS mod I should note that they also use longer standard intervals between shots so their elite units will perform better but they have not, in the versions I have looked at, made any other attribute such as fatigue impact rates of fire which I think probably should be done.

Regards

Mike
mcaryf
Reactions:
Posts: 236
Joined: Fri Jun 12, 2015 8:19 pm

Coding the AI

Post by mcaryf »

I am still working on routines to make AI artillery more effective.

I note that in the commands available to code the AI there are two which order units to withdraw 100 yards one is "fallback" which is described as falling back 100 yards whilst still firing and the other is "getaway" which just causes the unit to move back 100 yards.

My question is whether these commands also work for artillery and whether there is an equivalent AI command for artillery to withdraw by recoil?

By the way if the person who wrote the battlescript for Quatre Bras reads and posts here I have a couple of questions I would like to ask them.

Regards

Mike
DarkRob
Reactions:
Posts: 352
Joined: Mon Aug 15, 2016 5:56 am

Re: Fighting Withdrawals

Post by DarkRob »

I'm pretty sure Reb wrote both Quatre Bras scenarios.
User avatar
RebBugler
Reactions:
Posts: 4238
Joined: Sun Aug 03, 2008 12:51 am
Location: Ouachita Mountains, Arkansas

Re: Coding the AI

Post by RebBugler »

I am still working on routines to make AI artillery more effective.

I note that in the commands available to code the AI there are two which order units to withdraw 100 yards one is "fallback" which is described as falling back 100 yards whilst still firing and the other is "getaway" which just causes the unit to move back 100 yards.

My question is whether these commands also work for artillery and whether there is an equivalent AI command for artillery to withdraw by recoil?

By the way if the person who wrote the battlescript for Quatre Bras reads and posts here I have a couple of questions I would like to ask them.

Regards

Mike
Withdraw by recoil for artillery is the fallback for infantry equivalent, if that's what you're asking. The command "getaway", retreat 50 yards, doesn't work correctly with WL, it does with GB. It results with a 100 yard retreat, same as "Retreat", so just a redundancy thus useless.

The Grog Toolbar should guide you with which commands work with which Arm, they're tested tried and true.

I designed 2 of the 5 QB scenarios, the full battle ones.
Bugles & Flags Gettysburg - Toolbar, Flags, Scenarios, and More...
mcaryf
Reactions:
Posts: 236
Joined: Fri Jun 12, 2015 8:19 pm

Re: Coding the AI

Post by mcaryf »

Hi Reb

Thank you for your answer - I take you to mean that when I order a battery to fallback in the battlescript then it will actually withdraw by recoil.

My specific questions re your QB scenarios are in the final paragraph of this post the others are to explain to those who are not modders why this issue might be interesting.

I was very interested to see how you handled bringing artillery into range of the enemy by using the evtdisttarg command as generally this is one of the greatest weaknesses of the AI.

For those not familiar with the commands that direct unit actions used in the scenario Battlescript file, the game has an "event system" which causes a specified sequence of instructions to be issued when an event occurs such as the capture of an objective. The game continually monitors the "events" specified in the battlescript and executes the sequence when they occur. The command evtdisttarg initiates a sequence when the particular unit concerned gets within a distance from an enemy that is set by a parameter to the event. In QB Reb orders batteries to come forward with a destination such as Gemioncourt where the enemy is likely to be. Using the evtdisttarg he causes them to stop when they are detected to be within 300 yards of the enemy where they are then instructed to form up in line to fire. This works particularly well with my artillery mod as 300 yards is well within my canister range so these advancing batteries can cause real damage whilst not being at too great a risk themselves. This would also be relevant to those using the KS mod.

I am particularly interested in being able to have the AI repeat this method of approaching the enemy. The natural reaction of a human player might be to pull back any of their units that have come under canister fire or to send out skirmishers, as Rob does in some of his videos, to trigger the event and cause the batteries to halt prematurely. I am also interested in using the evtdisttarg command coupled with fallback to get the AI to pull its batteries back when threatened but carry on firing which is what a human player might do using withdraw by recoil.

My specific question to Reb is somewhat technical and I will not try to explain it in more detail than he will need to understand it. I note in QB that you use identical evtdisttarg events when you are using more than one random variant for the arrival of a new set of units. You also have the event code line embedded within the rest of the coding for this sequence. Does this cause that event only to be triggered within that sequence? Usually in the case of several variants for the same units I have my events separate with blank lines between them so that event will be triggered whichever of the random sequences are initiated. As mentioned above I would like to cause the artillery to advance again subsequently so if there are several iterations of the same evtdisttarg event would that cause it to repeat its action or would they all be triggered at the same time? I have a way round this, which I am experimenting with, which is to use each individual gun in a battery to be given its own event but over a range of distances from 350 to 210 yards. Currently I am using this series of events to cause the battery to fallback if threatened at ever shortening distances so I would prefer not to use the individual guns for advancing. My other question is whether the event would be treated as unique if it related to the same unit but had a different distance as the parameter. If that is the case then I can create a very large number of events to help batteries both advance and retreat and this code could be easily added to many scenarios and become a standard way of getting AI batteries to be both more effective and better protected against attack.

Regards

Mike
Last edited by mcaryf on Wed Sep 12, 2018 5:23 pm, edited 1 time in total.
User avatar
RebBugler
Reactions:
Posts: 4238
Joined: Sun Aug 03, 2008 12:51 am
Location: Ouachita Mountains, Arkansas

Re: Fighting Withdrawals

Post by RebBugler »

Here's what I've concluded from testing regarding the command 'evtdisttarg'

- It only works once, adding new distances to make it unique from a prior situation won't work
- It can't be timed or set in scripted sequences, it happens once within the duration of the battlescript
- If only assigned to one gun in the battery it won't execute when the enemy approaches if that gun is previously routed by enemy artillery fire

Since you like radical modding, try hiding (hideunit) guns and then showing (showunit) when you want their evtdisttarg command to kick in. The command 'altstart' can be used to move them to predetermined locations. Possibly make cloned/extra guns for evtdisttarg purposes only with zero fire power to maintain the historic content. Once they execute their command function hide them away.
Bugles & Flags Gettysburg - Toolbar, Flags, Scenarios, and More...
mcaryf
Reactions:
Posts: 236
Joined: Fri Jun 12, 2015 8:19 pm

Re: Fighting Withdrawals

Post by mcaryf »

Hi Reb
Thank you for clarifying issues re evtdisttarg. Actually I do not think I will have to try too extreme an approach to coding what I want because I have realised I can to some extent use the same coding to cope with artillery units that are either advancing or potentially needing to retreat. I can use each of the guns to trigger a distance event by using a range of different distances for each gun. Thus for 6 gun batteries I can provide 6 events and obviously 8 for 8 gun batteries if I choose to do so thus it is no great problem if one gun is routed. The going forward event has a sequence with a stop command and then bringing the guns into line and then telling them to fire canister. The retreating events have a fallback command plus a fire canister command. My artillery Mod has canister ranges of over 350 yards for 6lb batteries and over 450 yards for 12lb (similar to the KS Mod). Thus my going forward events will be triggered at 450, 410 and 370 yards for 12lb guns and 370 and 330 for 6lb guns. That leaves room for Fallback events at 300, 270, 240 and 210 and maybe an extra at 330 for 12lb guns.

This will mean I can typically create up to 3 commands to cause the AI batteries to advance towards where the enemy is likely to be with a degree of random intervals for the times of advances so that a player like Rob who tries to intercept the AI’s guns with skirmishers will not necessarily know when the advances will occur. There will still be the possibility of driving back the guns by following them but I would hope to make that costly as the guns should keep firing canister whilst withdrawing. Even if all the advancing events have been used the ones where the unit stops then falls back will still work for advancing units as they will end up within canister range albeit the deployment will not be a neat line.

I have tried this out two or three times by having the AI play itself with one of the AI’s having the benefit of these sequences and that one does a lot better. I have quite a lot of other things on at the moment so may not be able to play a long game myself to fully test it but I am encouraged so far that this will be a really good fit for the AI to be more effective using my mod for longer range canister.

I do not think it will be too difficult to add these routines to other scenarios as I can create a library for all the batteries in the game. I am not sure whether it would matter if I included them all every time as the events would just not be fired, however, there may be some limit to the size of the event list that the game can monitor.

I am actually thinking that I might include some of the sequences for the player’s own batteries. One of my styles of play with Waterloo itself is to push forward the French 12lb batteries to destroy the lighter weight Allied guns and their forward units. If I know that the guns will automatically stop when they reach a suitable range and withdraw if threatened then I can spend less time monitoring them. It is after all what a good battery commander should do so I do not think it is “gamey”.

I am currently developing my larger version of Quatre Bras where all the French and Allied units that could have reached the battle do so. However, once I have finished that I shall go back to Waterloo to add event sequences for the Prussian advance as that usually ends up as a bloodbath for the Prussians with their own guns playing a minimal role.

Thanks again for the way you coded QB as it was that that gave me the idea for this approach.

Mike
Post Reply