version 2.09

[CapnDarwin]

I'm personally not a big fan of strategic scale, but who knows. You really have to start cranking up the level of abstraction as you go bigger in scale too. I would envision a modern adaptation of the SSI classic Red Lightning.

[governato]

ORIGINAL: Capn Darwin

I'm personally not a big fan of strategic scale,

Well, nobody's perfect [:)]

Another way of saying it is that the development of 'realistic' PC games was for a long time influenced by boardgames, where fog of war, logistics and C&C problems were not modeled properly. I think this is going away and it is a very good thing, although I have seen more progress at the scale of FPC than at the operation/strategic level.

[ivanov]

ORIGINAL: Tazak

"you can test it by changing low & high EW hindrance".

How do you change the EW hindrance in a scenario?

[cbelva]

The player cannot. That is set by the scenario designer. You can make some test scenarios in the editor and vary the EW and test it that way.

[IronMikeGolf]

ORIGINAL: katukov

ORIGINAL: Tazak

Katukov, your screenshot does show a unusually high amount of time to move 1 hex for a helicopter unit and the 'next action' timings seem 'off'

I use liberally order delays. During the turn 1, I set 3 waypoints for the units and keep delaying the second and third, so they cannot be reached by the end of the order cycle. Then I edit them further during the next turn.

Gosh, it looks like you are trying to circumvent the order delay mechanism.

[ivanov]

ORIGINAL: Iron Mike Golf

Gosh, it looks like you are trying to circumvent the order delay mechanism.

Is that supposed not to work that way? I was just trying to figure out ways of having the units on the move all the time, without having to issue the new orders [X(]

[cbelva]

When a commander changes the orders of a unit during a movement/operation the unit/formation will have to be halted, reorganized, and new orders issued. That takes time. In the game, you can issue new orders by moving waypoints, but expect penalties in the form of delays. Issuing orders on the fly is not a good way to play. You are not the Plt ldr or company commander. You are the battalion or brigade commander. You are not running around making minute changes to units movements. You issue your orders and trust your subordinates. These changes can also affect the command cycle and open your hq to being detected by EW by the enemy. Everytime you make a change you are increasing your radio transmissions. The game rewards good command decisions and punishes bad.

[IronMikeGolf]

ORIGINAL: katukov

ORIGINAL: Iron Mike Golf

Gosh, it looks like you are trying to circumvent the order delay mechanism.

Is that supposed not to work that way? I was just trying to figure out ways of having the units on the move all the time, without having to issue the new orders [X(]

See cbelva's post above, regarding feature vs bug.

The design intent, which is an attempt to model what happens in actual units doing these sorts of actions, is to mimic the fact that units do not respond instantly to orders.

Flesh and blood soldiers don't move continuously on the battlefield without limit without getting orders. And those orders are not executed instantly. In the game, this is called Command Cycle. Doctrinally, this is the OODA (Observe, Orient, Decide, Act) loop. Part of the operational art of a Commander and his Staff is to attempt to had an OODA loop that is shorter than their opponent's (this is called "operating inside the enemy's OODA). Doing so enables a Commander to seize and maintain initiative. Modelling this is a central design goal of this product and what raises it above many competitors.

What you are trying to do in the game would go like this on a real battlefield:

1. Commander: "Move to that road intersection and await further orders"
2. Unit gets 500 meters away from destination and receives a radio call: "No, no, no, move to that village and wait. I'll call you then."
3. Unit is almost at the village, and the radio crackles to life, "Oh, no. You must attack this hill and destroy all enemy!"

Now, actual soldiers getting the radio call in step 2 will do the following: consult a map, decide a route, pick a formation, tell everybody in the unit what the new plan is. That takes time. Step 3 above takes even more time as there is not only movement decisions, but now there is a fire and maneuver aspect: sectors of fire, who assaults and who supports, supporting indirect fire plan, etc. That is why an assault order has a longer delay than a hasty move.

Note that in none of the above sequence is there the notion of a magic time when the commander can pick up the radio hand set. By that, I mean, end of current command cycle. So, since your waypoint times are being tied to the game engine behavior and not being used to synchronize with other units' maneuver, it looks like you are gaming and not simulating. I am not saying that is a bad thing. But, I do think the designers (and a lot of users here) are more interested simulating reality instead of gaming the engine.

So, yeah, not being able to do what you are trying to do regarding changing orders is a Good Thing, in my book.

[ivanov]

ORIGINAL: Iron Mike Golf

So, yeah, not being able to do what you are trying to do regarding changing orders is a Good Thing, in my book.

If the things work like this due to the design, I'm absolutely fine with that. But I have a feeling that this is a bit of gray area in the game's functionality design. And grey areas tend to be exploited by the players. The game design should prevent the abuse of the system. I did some more testing and this exploit is possible to implement to some degree. If you set 3 waypoints for an unit and the first of them is supposed to be reached in the first or second minute of the next cycle, this would actually work. All 3 waypoints will be still available to edit during the next turn, but it won't be possible to delay the first of them. So at the beginning of the third cycle you'll still have 2 waypoints and if they are delayed, you can cancel the delay and move the units immediately anywhere you want, without having to issue the new orders. So you can adjust the waypoints delays and have the units moving and changing directions without having to issue new orders for quite a long time. In reality you can do that until you get into fire contact with the enemy. It's not that I'm an inherently perverted gamer. I've came with this up after seeing the gameplay of the AI, when it seemed to be able to issue new orders without any delay. So I thought that the players can do the same.

What was confusing to me about the waypoints delays, was that if for example you delay the second waypoint for x minutes, at the beginning of the first cycle, this waypoint will be still delayed for x minutes at the beginning of the next cycle, so effectively the ETA to the waypoint will be delayed each turn, unless you adjust the delay. Is that intentional, or in theory the estimated ETA to the waypoint should be the same as set during the first turn ( unsless it gets delayed by some external factors )?

[Mad Russian]

Then your feeling is, for the most part, wrong. The orders delays and execution delays have been in the game since day one. Each set of waypoints represents a planning session of varied length. You use 1 waypoint the session was short. Move to the intersection. You use three waypoints the session was longer. Assigning delays on the waypoints are part of the orders.

If I tell you to go to the road but not to leave until 30 minutes are up, then you wait. You have a delay on the waypoint.

If I then call you up and tell you to go now, the delay for that waypoint then disappears and the order is executed immediately.

This isn't magic. We tried to use common sense in the application of command and control. It's not perfect and we will continue to tweak things as we go but it serves the purpose.

Having said that, yes, Command and Control is a gray area. There are no hard and fast rules that govern how each unit responds to a given situation. We have done the best we can with our own experiences guiding the results.

Good Hunting.

MR

[pzgndr]

ORIGINAL: Mad Russian
Having said that, yes, Command and Control is a gray area. There are no hard and fast rules that govern how each unit responds to a given situation. We have done the best we can with our own experiences guiding the results.

And fairly well done overall. Order delays and execution delays add to the realism, and the realistic frustrations of orders flowing down from higher. The whole 1/3-2/3 rule, etc.

Gamewise, the thing that frustrates me is the uncertainty in phase length, not to mention the game is not play balanced for limited orders. I still don't quite get the phase length variability feature. I'd prefer some standard turn length, like 10 minutes or 15 minutes at this scale. Then define realistic order limits for NATO and WP. Then focus on the variability of delays. I think players could better understand that and anticipate future turns. Things like electronic jamming, weather and such could then reduce orders and/or increase delays. And this could possibly be adjusted further with game setting for different difficulty levels. But, not for 2.09, for the next version. Something to look forward to.

[CapnDarwin]

What works on the orders cycle is the dynamic timing. If you have static turns with variable orders that is not equitable to variable time with static orders (or limited). I want to be working to get inside the enemies cycle in order to respond faster. Having more orders just gives me more units I can move. I think with some refinement to both the limited orders calculations and use (group orders/battle drill) and more refinement in delays based on level depth from HQ, readiness, EW, training, etc., we will get a good realistic balance of command.

As too play balance I see little need to balance for limited. Mainly because the current and future system makes it almost impossible to know just how good or bad both sides (or more) C3I or C4I is going to trend over the course of a battle. The idea is to be able to place unbalanced forces on the map and do the mission. The final score takes into account the proportion of forces involved.

[ivanov]

Please take look at my tests concerning the waypoints delay. Wrong info regarding timing is displayed in the waypoint editor and on the unit display panel. It has nothing to do with the EW or the order delay.



It is 1300. The cycle ends at 1328.

I issue an assault order to the BMP company and set 3 waypoints:


sube fotos

Then I delay the first waypoint ETA by a random value of 32 minutes, so the unit is supposed to reach it at 1335:


subefotos

The turn cycle ends at 1328, so the first waypoint shouldn't be reached by the end of the cycle. The next action of the unit should take place at 1333, which would be already during the next cycle. I hit the start button.



At the beginning of the second cycle the waypoints ETA seem to be in order:


subirimagenes

Despite the fact that all three waypoint ETA are correct, if I go to the waypoint editor, the delay of the first waypoint is still shown as 32 minutes, instead of around 4-5 minutes. It is now 1328 and the first waypoint is supposed to be reached at 1335.


hosting imagenes


At the beginning of turn cycle 2, the ETA for all the waypoints are also editable. Let's try to change it by adding another 5 minutes to the first waypoint ETA. The first waypoint should be reached now at 1340:


hosting imagenes

This a moment when the information available to the player becomes really contradictory. In theory the waypoints should be reached at 1340, 1344 and 1350 respectively, but if you look at the unit display panel, it shows that the next action will take place at 1406...

The second cycle starts at 1328 and it ends at 1353. Effectively, after hitting the start button the unit doesn't move at all during the cycle and it won't move during the whole game, unless the delay will be cleared to zero from the waypoint editor.

So we're not talking about a bug here, but about the game's functionality and the wrong information being displayed.

[CapnDarwin]

Katukov, I'm missing something in your images. In the first one I see the three waypoints, assault order, added delay to WP1 and all the times look good. There is no "command" delay for initial orders, so they step right out. My problem is image #3 that shows the unit in question but with a single WP for the assault order. Did you reissue the Assault with a single waypoint?

The last picture does look like a bug and if the unit is not moving, then the units timing chain is broken. I will have Rob look into this in the morning when we review a number of new items.

Thanks for the images. That helps narrow the problem down.

[ivanov]

ORIGINAL: Capn Darwin
My problem is image #3 that shows the unit in question but with a single WP for the assault order. Did you reissue the Assault with a single waypoint?

You're right - I posted wrong image. I made so many tests that I got confused. I've amended the image and the correct one is posted now.

By the way, you'd probably need to run few tests yourself, because sometimes this issue causes the delay orders for the waypoints to be ignored. It's kind of difficult to tackle, because people may confuse it with the C3 issues or EW hindrance. But I'm pretty sure this is not intentional by design.

[pzgndr]

ORIGINAL: Capn Darwin

What works on the orders cycle is the dynamic timing. If you have static turns with variable orders that is not equitable to variable time with static orders (or limited). I want to be working to get inside the enemies cycle in order to respond faster. Having more orders just gives me more units I can move. I think with some refinement to both the limited orders calculations and use (group orders/battle drill) and more refinement in delays based on level depth from HQ, readiness, EW, training, etc., we will get a good realistic balance of command.

As too play balance I see little need to balance for limited. Mainly because the current and future system makes it almost impossible to know just how good or bad both sides (or more) C3I or C4I is going to trend over the course of a battle. The idea is to be able to place unbalanced forces on the map and do the mission. The final score takes into account the proportion of forces involved.

Like I said, I don't fully get the dynamic timing feature. Perhaps I just need to play more. I also haven't played any pbem games, so I don't understand if turns stop for the other player's command cycle when the times are different. I would argue that even with standard turn lengths, you can still get inside your opponent's decision loop by presenting more challenges for him to deal with than his limited orders allow. In this sense, limited orders are necessary to produce a realistic effect.

Another thing that's frustrating about the relatively long tactical command cycles (~30 minutes say) is that you may want a unit to pause and be on call to perform an action based on enemy COAs (NAIs, TAIs, etc. for those who get that). I may see that trigger early in a command cycle but cannot issue the execute order until the next cycle, which may be too late. So I don't like that. With shorter standard cycles players can better anticipate things and react. It's not a major showstopper in this game, but certainly something for you guys to consider down the road.

For 2.09b, the scoot logic seems better. At least I'm not cursing as much so that's a good sign. [;)] I note that artillery graphics appear odd, like the explosion graphic black background is set to opaque and not transparent? Otherwise, EET was playing fine for me last night; ie, no lockups.

[IronManBeta]

Katukov - Thanks for taking the time to capture these screen shots and mark them up for us. They illustrated perfectly what was wrong and I just fixed it. I think you will be happy with the results. It will now deduct the elapsed time from the remaining delay as you expected and all the times match up now the way you anticipated.

Thanks again! Rob

[governato]

tx for fixing this and especially to katukov for finding the bug. It was good detective work

[CapnDarwin]

We have spent the weekend bug fixing and testing. Including fixing a bug we created trying to fix another. This is the kind of fun bug hunting is in such complex code. We are hoping to post a Beta 2 soon. Hopefully, it will be more bug free than Beta 1.[;)]

[Tazak]

I'm still seeing the issue where the scenario editor is not seeing the official data files, I've deleted the FP_files.txt and replaced it with the one you uploaded a short while ago but still get problem where the editor isn't recognising data files