GPQ: The 'Realistic' Orders Delay

[Templer]

CO2 "offers 'realistic' and 'painful realistic'.

Either something is realistic or not!

So what is the 'real' real life realistic setting now?

 

[Dave 'Arjuna' O'Connor]

Painfully realistic is probably the closest to real life orders delay but a lot of players find it a tad excessive and prefer a faster game, hence the 'realistic' setting below it.

 

[Kaunitz]

Hello!

First, I wanted to say that I’m very impressed by the series and it’s overall goal and design.

However, as it is the case with quite a few other simulation games, this series also suffers from a distinct lack of documentation. Many game aspects are shrouded in mystery and the manual and the forums don’t really help. Since I’m very serious about understanding a game before I fully jump into it, I do a lot of testing and I’m bristling with questions. And I also want to come up with a video tutorial some day. For a start, I took what I believe to be a quite detailed look at how orders are processed and especially command structures (order-delays).

Effect of force-delay

According to my tests, the effect of force-delay is as follows:

Whenever you give an order to a (HQ or normal/subordinate) unit, the unit uses its current force-delay stat (you can look it up in the unit's command tab) to set the starting time of all tasks that are based on this very order, according to the following rule:

Time at which the order was given (NOT processed! given!) + force-delay of the unit that has been given the order = starting time of all tasks based on that order (+/- 1 minute)

For example: At 20:00, you give an order to a battalion HQ which is in command of three subordinate companies. The battalion HQ has a force delay of 30. In this case, all the first tasks (of the HQ unit and each of the 3 companies) that are based on this order will have their starting time set to 20:30.

Similarly, if you give an order to a single company that has no subordinate unit, and the company has a force-delay of 15, and you give the order at 20:00, then the task that the unit assigns to itself based on your order will have its starting time set to 20:15.

Note that for units that have no subordinate units, force-delay always equals unit-delay.

I have no idea what unit-delay is used for. I suppose it’s part of the formula to determine force-delay (see below).

Open questions: What affects force delay?

Now for the more interesting implications: How to take an influence on the delay-stat? Even after some in-depth testing, it remains a big riddle to me how force-delay is calculated. Also, testing is very difficult because the data shown to the player does not seem to get updated automatically. Sometimes, changes in force- and unit delay only become apparent once you’ve given a new order to a (HQ)unit.

For what I believe to be force delay (not unit-delay), the manual mentions a number of factors on page 147-151. I have not yet seen any consistency that I could understand. However, from my observations, I think the manual is correct in stating that the force delay also depends on the respective unit’s superior unit! E.g. a battalion seems to suffer less delay if the battalion commander is command-overloaden (weighted 1/3 according to the manual) than if it’s superior, the regimental commander (2/3) is command-overloaden. Also, if you give a direct order to a unit and thus take it out of the command structure, it's force delay increases - presumably because it now gets it's orders by the onmap-boss which is on a higher hierarchy level with a higher base delay. But to be honest I was not able to see any kind of understandable pattern in the changes of delay that my adjustments to the OOB brought about. I would be very glad if this aspect could be explained by someone more knowledgeable than me.

Open question: Command-overloading the onmap-boss …

From my understanding, players are supposed to suffer increased delays if they give too many direct orders. The game is supposed to simulate this by increasing order-delay for overloading the onmap-boss? However, from my observations, overloading the onmap-boss is 1) hardly even possible, given the very generous command capacity of most onmap-bosses, and 2) has hardly any effect on the delay of his own unit and his subordinate (HQ)units at all? Is this a bug or the way it was intended?

To make my point clear, here is an example: version 5.1.28, Scenario = Highway to the Reich/Operation Garden Final Phase with “painfully realistic” order delay setting, initial delay-free period is already over; Onmap-boss = a divisional HQ, command capacity = 26
Load / unit delay / force delay
3 / 23 / 187
11 / 23 / 187
19 / 23 / 187
33 /25 / 153 (!) (since all units were now under his direct command?)

Giving orders to the onmap-boss

Why does giving an order to the onmap-boss result in an increase in his delay-stats? And then, I wonder why this increase doesn’t seem to affect the force-delay of his subordinate HQs and units? And why can't I "reattach" the onmap-boss?


PS: Some minor bugs/inconsistencies, unrelated to the topic
I just stumbled over the polder-terrain in the Highway to the Reich/Joe's bridge scenario and wondered why motorized units don't seem to be slowed down as much as I expected. According to the ingame-terrain-info, motorized units move with 5% of their speed, according to the manual it's 9%. The latter seems to be more accurate (moving through one grid/1km on perfectly flat polder took a tank unit (17 km/h offroad) about 34 minutes only; at 9% of 17km/h it should have taken me ca. 39 minutes, at 5% it should have taken me ca 70 minutes). So it still seemed quite fast.

Also, in some scenarios, the overlay-map-filters don't seem to work. PS: "Solved". Stupid me. I forgot they only work when the game is paused.

 

[Kurt]

Hi Kaunitz , Good to see a new player with passion and a new perspective . I can only answer the " minor inconsitencies " myself . Terrain effects on movement etc are speculative and are set / adjusted by individual scenario designers like me . For example , I have made road movement for motorised / armoured units more difficult in my Nordwind scenario's to reflect frozen , compacted snow which made the roads like ice rinks .

 

[Kaunitz]

Kurt! Thanks for the answer! So the terrain-info that plops up when you right-click on a point is always correct.

Do you happen to know where the effects of deploy-status (moving, taking cover, deployed, dug-in, entrenched, fortified) can be found? I could only find some example-values in the old matrix-board, stating that the effects are also terrain specific and quite variable. In the map-editor, I could only find information on the reduction of visibility per 100m of looking through terrain.

I'd also like to suggest to make the heightmap that you can view in the mapmaker available in the game. It's very hard and complicated to use the LOS-tools to get the information that the height-map could provide with a single look. Especially since the range-rings/colours most of the times (map-specific?) come in 10m in height intervals and there can be a lot of small bumps and LOS-blocking undulations in the ground within that 10m. Also, height-colours are often covered by terrain-graphics, so they're even harder to see.

 

[Kurt]

is this any clearer ? Mot ( motorised ) movement = 0% ( these woods are too dense for vehicles )
Foot movement =26% ( so foot movement is reduced to 26% or almost a quarter )
Direct hit = 15% ( these woods provide good protection against direct fire weapons )
Area hit = 120% ( mortar and artillery fire is more deadly because of tree bursts )

 

[Kurt]

The movement & incoming fire stats for deployment are not available , I agree they should be .
I agree that in-game we should be able to turn off vegetation layers so we can see the contours better .

 

[Kaunitz]

Thanks for the picture, Kurt!

I've done an introduction to reading the map in "Command Ops" in german (). The quality of the video is rather bad though and I'm planning to come up with a higher quality and more detailed english intro if I can cobble together more confirmed information here. I hope it's okay to turn this thread into a collection of explanations and questions on game aspects (apart from delay also movement, visibility/spotting, combat routines, orders).

Indeed information on the effects of deployment-status would be most welcome. Most of it would be pretty intuitive, I guess. But in my case, for example, I wondered whether troops would gain any positive effect from digging-in in polder terrain? They would be digging into groundwater? So I had to guess whether it is better to put up my defensive line in polder or in the woods.

The LOS-tool
Maybe the height-information that the LOS-tool provides is of any interest (see sketch in the video linked above at ca. 13:30): I've figured out that the game takes the value of the highest altitude(z)-point on the line that you've drawn and substracts the value of the lowest altitude-point on the line. This difference is 100%. All other altitude-points on the line generated by the tool are expressed as %-values of those 100%. So, the shape of the line that the LOS-tool generates is always relative to the difference between the highest and lowest value on the line. E.g. if you draw out your line further and thereby add a new "high-point" to the line, the shape of the line changes and minor differences in height might get blurred (and vice versa). Also, if the line you draw is very short, the high-point of your line will still have the same absolute length/height, as it is still 100% of the difference between the maximum and minimum height on that line. So the tool does not provide you with information of absolute heights, it just tells you the height of the points of the line in relation to each other. It's a bit hard to explain with my imperfect english.

If we had a heightmap-overlay, we wouldn't need to fiddle around that much with the LOS-tool. In daylight, the LOS-area tool helps to understand terrain a bit better. At night, however, you have to make due with the LOS-tool and with the height-contour-lines/colours. A heightmap would be so much more convenient.

 

[Kurt]

Agreed , your English seems fine to me . As the game develops then at some point the terrain effects will become more detailed to take into account factors like ground water and also how frozen the ground is , these factors obviously affect the ability to " dig-in " . I am impressed by your study of the game mechanics . Haben zie schnee im Vienna heute ?
liking the video , the sound is very low however . You could put your video in the " resources " page so others can access it easier .

 

[Kaunitz]

I'd still be very interested in any info on the issues highlighted in post nr. 3 above, concerning force-delay and the whole command-load-aspect, which doesn't seem to be working properly?