OCMOD4

The discipline of balancing units without upgrade costs yields its own insights. Production time can be changed of course and also the actual unit costs of the units. For example, armored pikes in OCMOD4 cost wood, gold, iron and coal to produce (but no coal cost to fight obviously). The coal reflects the smithy costs of forging armor.

But the real balancing comes with changing unit capabilities in the field which I think is what you refer to in talking about the battle system. For example, preventing firing through friendlies means new tactics (linear tactics) have to be better utilized. The new firing system of OCMOD4 increases range as well as increasing reload times. It also makes more use of the headshot (instant kill). Changing unit speeds would also help. The dragoons definitely should be faster than heavy horse and cuirassiers but not as fast as hussars. Giving them an intermediate speed (between hard horse and fast horse) would enable them to have extra uses. But I haven't been able to crack the problem of changing primary unit speed. I could bring back General WVPM's formations bonuses system into OCMOD4 (and may do so) which at least enables formations to have changed speeds.

The other thing I thought of was giving dragoons extra range like sharpshooters but that might make kiting (using Parthian tactics) with them too annoying altogether. If they could kite non-shooters, including heavy cavalry, with extra speed and not extra range, that would be micro-heavy enough. To be consistent, lancers also would have to get the intermediate horse speed. This would lead to hardhorse (armored horse), intermediate horse (lancers and dragoons) and fast horse (hussars). Now, if only there were an easy way of changing horse speed.

 

Cossacks 3\data\animations\acl

acl.lib
....
section.begin
Name = cuirassier
FileName = .\data\animations\acl\hardhorse.acl
section.end
section.begin
Name = dragoon
FileName = .\data\animations\acl\hardhorse.acl
section.end
.....

hardhorse.acl
...
global : struct.begin
Action = actTrackPoint
TrackPointMoveStep = 0.0525 //velocity
TrackPointTurnStep = 11.125
TrackPointIdleName = idle0
TrackPointMode = mmDoTrackOnce
TrackPointPreset =
struct.end

fasthorse.acl //Hussars

global : struct.begin
Action = actTrackPoint
TrackPointMoveStep = 0.09
TrackPointTurnStep = 11.125
TrackPointIdleName = idle0
TrackPointMode = mmDoTrackOnce
TrackPointPreset =
struct.end

You create a file based on hardhorse.acl, such as middlehorse.acl
You change all values from 0.0525 to 0.0712 (for example)
Then you edit the string in the acl.lib

....
section.begin
Name = cuirassier
FileName = .\data\animations\acl\hardhorse.acl
section.end
section.begin
Name = dragoon
FileName = .\data\animations\acl\middlehorse.acl
section.end
.....

 

Thank you Awar, I will look into that very soon... as soon as I manage to digest my Christmas dinner. Having a third constant horse speed should help me balance horse. Will I have to speed up the animation too in unit.script? I mean like the way the swordsmansco is given objprop.walkintervalfactor := 1.12;?

The way some of the horse in State vs Country speed up for the final charge is marvelous. I won't be trying to get effects that good, at least not yet. I'll work on basic changes first. I've had the thought (for State vs Country) that when cavalry commence movement from a stationary start (and maybe when they turn) there could be an acceleration phase instead of them jumping off immediately at full speed. Or maybe you have already done that? I must re-check State vs Country in the In-game editor. By the way is there a way to turn Peace Mode off for State vs Country in the In-game Editor? Ctrl-W seems to be assigned to another function.

One change I particularly like in State vs Country is when the attack command for a formation is placed on another formation. Instead of bunching towards the attack point there is a "move in proper formation spacing to attack point and then attack" command in effect. How did you achieve that? I would really like to add that to OCMOD4 if you don't mind me copying the use of that command.

This leads me to the whole issue of unit spacing. Why do C3 melee units (C1 did it too) bunch so severely in attack (and also allow formation stacking)? They are not just "standing on each others toes". In virtual space terms their bodies (really their unit boxes) are overlapping. What parameters control this unit spacing? I've tried various experiments with no success. I can't find the key parameters. It seems to me there could be a couple of ways to prevent this excessive clumping. One way would be to change the unit box "overlapping" permissions somehow and not allow this overlap. But it seems quite possible that this would create major pathing problems with other units and through landscape and building obstacles. Another way might be to prevent melee units somehow reaching through units with weapons to attack other units further back in the formation though I am not sure if this idea makes any sense at all. I would be very interested in your ideas about this.

 

No.

You can use any part of the code as you like.

Important parameters are the dimensions of the units
dmscript.global

gc_collision_mass_default = 1;
gc_collision_mass_stand = 1.5;
gc_collision_mass_attack = 3;
gc_collision_radius_default = 0.16;
gc_collision_radius_stand = 0.1;
gc_collision_radius_attack = 0.1;

Parameters that affect the formation
gc_obj_radius_formation_default = 8;
gc_obj_radius_formation_horse = 12;

 

Awar,

1. Thank you. Yes, I created a draghorse.acl file and made the other changes as suggested. The animation of trotting looked perfect and the speed chosen was perfect as it is half way between the speeds of hard horse and fast horse. When the horses turn it sometimes looks a little odd. I might look into those parameters which might be turning parameters. In terms of effects on tactics I won't know if it is a success or not until it is game tested.

2. I have already experimented with all the parameters you name with no success. Maybe I did not try big enough numbers. I will try some of my experiments again with much bigger numbers. I am aware that if it works I might then get formation problems and pathing problems. Also, if they can't stand close enough then certain weapons with short ranges might not even reach the enemy, lol. I guess the idea is to achieve as much as possible for stopping bunching without wrecking other actions and processes.

 

Further experiments with the radius parameters are interesting if somewhat inclusive. If I increase the default, stand and attack radii too much then formation forming is interfered with. Troops won't line up properly. The farthest I can push it without bad side-effects is to set:

gc_collision_radius_default = 0.2;
gc_collision_radius_stand = 0.2;
gc_collision_radius_attack = 0.2; // Ftoomsh

and

gc_obj_radius_formation_default = 10; // Ftoomsh
gc_obj_radius_formation_horse = 15; // Ftoomsh

Crushing in combat is reduced a bit . Some crushing is okay as per "push of pike".

https://en.wikipedia.org/wiki/Push_of_pike


The strange thing is that even with these parameters, two formations can be stacked. Even three can be stacked but they start expanding a bit by jostling each other. I need to experiment more with these and other parameters.

 

I've been looking into which file determines how many peasants can build a given structure. I now want 10 peasants to build a mine, since OCMOD4 mines start at 10 capacity (for eco balancing purposes and also to reduce the number of mine upgrades needed).

I've found the builder points in objcustom.cfg. By doing some transpositions of the relevant values, I have been able to get 10 peasants to build a mine and enter it. This code puts 10 peasants nicely around the front half of a mine to build it.

sid = eurgol
BuilderPoints : struct.begin
[*] : struct.begin
x = 2.45
y = 0.97
struct.end
[*] : struct.begin
x = 2.45
y = -0.97
struct.end
[*] : struct.begin
x = -2.45
y = 0.97
struct.end
[*] : struct.begin
x = -2.45
y = -0.97
struct.end
[*] : struct.begin
x = 1.95
y = 1.5
struct.end
[*] : struct.begin
x = -1.95
y = 1.5
struct.end
[*] : struct.begin
x = 1.325
y = 2.15
struct.end
[*] : struct.begin
x = -1.325
y = 2.15
struct.end
[*] : struct.begin
x = -0.6
y = 2.7
struct.end
[*] : struct.begin
x = 0.51
y = 2.7
struct.end
struct.end

 

Stone walls and buildings: bug fix for muskets shooting right through. I have finally fixed the firing through stone wall bug in OCMOD4 using Awar's _misc_IsBuildingInRay2 routine. I have to apply it in a different way because muskets in OCMOD4 are the only weapon that cannot fire into or through friendly units.

_misc_IsBuildingInRay only checks for bodies and iron (cannon) now:
var mmask : Integer = (1 shl gc_obj_material_body) or (1 shl gc_obj_material_iron);

It only ray checks for the bullet or projectile going over land and water:
if (gObjProp[cid, id].media=gc_obj_media_water) or (gObjProp[cid, id].media=gc_obj_media_land) then... etc.

The _misc_IsBuildingInRay2 routine is an exact copy of Awar's routine.

In unit.script, the logic has to be altered to suit my weapon.script setup. It's probably inelegant code but I am not trained in programming.

var FriendOnLine : Integer;
FriendOnLine := 0; // Ftoomsh initialises
var UnitBoxAdjustment: float;
var unittype : Integer = _misc_GetUnitType(goHnd);
UnitBoxAdjustment := 0.93; // For infantry three rank fire
if (unittype=gc_result_unittype_cav) then
UnitBoxAdjustment := 1.0; // For cavalry three rank fire
if (TObjProp(pobjprop).weapon[weapon].weaponid=0) or (not gWeapons[TObjProp(pobjprop).weapon[weapon].weaponid].bcheckfriendonline) then
FriendOnLine := 0
else
FriendOnLine := _misc_IsBuildingInRay(goHnd, px, py+UnitBoxAdjustment, pz, tx, ty+0.5, tz); // Ftoomsh changes py for 3 rank fire
if (FriendOnLine = 0) and ((TObjProp(pobjprop).weapon[weapon].weaponid=0) or (gWeapons[TObjProp(pobjprop).weapon[weapon].weaponid].bcheckfriendonline)) then
FriendOnLine := _misc_IsBuildingInRay2(goHnd, px, py+0.5, pz, tx, ty+0.5, tz);


Strangely enough, I did not have to alter any processing in ontagstates.inc. Awar altered processing in ontagstates.inc for his ray changes and friendonline tests but it doesn't seem necessary for my changes. I have no idea why this is the case. I can't see that I am causing my mod any problems by leaving ontagstates.inc as vanilla.

I have taken wooden fences out of my mod. They are not part of the peasants' fixed produce repertoire at the moment. Now that I have a fix stopping muskets from shooting bullets through solid objects, I can probably set up fences to allow for shoot through (or not) depending on what I decide for wooden fences. But first I will have to rationalize the material codes for stone walls and wood walls as Awar has done in his dmscript.global. Are there other scripts that need changing when doing this, I wonder?

Added Note: I have begun to wonder if I need the code change in ontagstates.inc to prevent the muskets from trying to take shots through the stone wall. That results in jerky approach behavior between enemy formations when a stone wall is between them.

 

Cannon now cost 1,000 gold each instead of 400 gold each in OCMOD4. Cannon have other costs too but gold is the most important one. On the standard setting it will cost 1,000 gold to make each cannon and 750 gold to make each howitzer. These are significant costs. The expensive artillery setting now increases artillery costs by 4 times in OCMOD4. At this setting each cannon costs 4,000 gold which is the same as the vanilla expensive cannon with a cost of 400 gold x 10 = 4,000 gold.

I have also increased cavalry costs and decreased 18th C infantry costs in OCMOD4's latest update. All these costs plus the cannon costs are based on statements by Carl von Clausewitz in his works on unit costs in the era. He stated it costs about equally as much in outfitting and maintenance costs to raise and keep in the field 800 infantry or 150 cavalry or 8 x 6 pounder cannon. Now, the costs in OCMOD 4 closely match these criteria, at least for 17th C troops:

800 infantry cost 8,000 gold.
160 cavalry cost 8,000 gold.
8 cannon cost 8,000 gold.

Now, for 18th C;

800 infantry cost 16,000 gold.
160 cavalry cost 16,000 gold.
8 cannon still cost 8,000 gold.

Without an 18th C cannon, I cannot give a new cannon at 2,000 gold cost. I can possibly take an 18th C cannon model from Awar's & Demoul's mod with a bit of work, if they didn't mind. If I did that I would weaken 17th C cannon capabilities and make 18th C cannon about equal to the current OCMOD4 cannon. The player would likely have to melt down (delete) 17 th C cannon to build the better 18th C cannon.

Artillery towers are also made more expensive and the expensive artillery setting affects them too. Towers are buffed but are still not value for gold really. They are what you build finally when you have no better use for the gold.

Artillery numbers in OCMOD4 are controlled by (in order);

(1) The inflating cost of depots (very heavy iron costs);
(2) The production limit of units in the depot;
(3) The high gold cost of cannon (even without expensive cannon setting which multiplies them by 4).

None of these limitations are new, they are all in vanilla but in OCMOD4 are set differently. It is the parameter used for each limit and the cost relativities across the units which control unit mix, especially when armies are in the thousands.

A good player will realize at these gold costs that other units (infantry, cavalry and the buildings to make them) are the first priority. The heavy (relative) gold cost of cannon is a natural controlling mechanism encouraging the player to delay production of artillery until after sufficient infantry and cavalry are on the scene to protect the artillery. As von Clausewitz wrote: Infantry are the arm most able to operate alone and artillery are the arm least able to operate alone. This refers to the theory of combined arms operations for infantry, cavalry and artillery.

I don't believe in excessive gold costs for cannon and I think the expensive cannon setting is excessive. However, it's still there as an option to use.