ACWGC Forums

feature or bug?
Page 1 of 1

Author:  mihalik [ Sun Jun 10, 2018 12:47 pm ]
Post subject:  feature or bug?

Just noticed playing Petersburg scenario #23 Federal Advance that objective hexes show full their value during the Union turn but show 0 during the Confederate turn.

I'm wondering if this was a design decision, since the Confederates get zero points for holding them while the Union gets full points for taking them.

Author:  Berto [ Sun Jun 10, 2018 1:07 pm ]
Post subject:  Re: feature or bug?

Feature, not a bug, WAD.

As you say, the Union gets points for capturing the hexes, while the Confederates get zero points. Under the Extreme Fog of War optional rule, the Confederates will not know how valuable the objective hexes are for Union victory. Fog of war, right?

This is a feature, among others, in the new Variable, Asymmetric, Turn-Based Victory Points System. The changes.txt file says "[Available, but not really used yet.]." That is generally a true statement, except in this one aspect just described. Meaning to say the FOW aspect of this new system is already in effect in the CWB updates, even if the system is not otherwise employed in full. We will give a fuller description of this new system as it applies to CWB when, in future, it is fully utilized. In the meantime, you might read this

for a description of how the system applies in Panzer Battles. (In the main, the victory systems are identical between PzB and CWB.)

Note that when not using Extreme FOW, both sides will see the VPs as before.

Author:  Berto [ Sun Jun 10, 2018 1:42 pm ]
Post subject:  Re: feature or bug?

What the hey. Here -- from the (private) CWB Dev Forum (at WDS) -- is the initial write-up for the victory/objectives system as it applies to CWB. Note that any mention of "FOW not implemented yet" is no longer accurate. Subsequent to this write-up, I did implement FOW.

In the new objective points system, objective hexes can have any of five value types:

t-t[#] ...
t-t[#/#] ...

Let's consider each in more detail, one by one.


Exactly like traditional exit hexes.

Note: Before, in cwedit.exe, you could mistakenly enter negative values less than -1. Now, any negative less than -1 is rejected ("Invalid objective value(s)").


Where # is some positive integer. For example: 50.

This functions exactly like traditional objective hexes: The occupying side, first side only, accrues these points immediately (i.e., the Victory Dialog notes this immediately and doesn't wait until the end of the turn). These accruals are one time only (i.e., don't continue to pile up from turn to turn).

t-t[#] t-t[#] t-t[#] ...

Where # is some positive integer, for example 5; and t-t is a range of turns, for example, 1-8.

You can have a single t-t[#], in which case the first t should be 1, the second t the scenario maximum turn.

Or you can have a sequence of t-t[#], where the turn ranges must be ascending, with no gaps or overlaps. The turn ranges need not be uniform, i.e., the number of turns in each range may vary.

For example, assuming there are 30 turns in the scenario, this is valid:

1-4[10] 5-8[15] 9-10[20] 11-20[15] 21-30[30]

Note that the varying objective values need not ascend, or descend. Unlike the t-t turn specs, the objective values can be anything you want (so long as they are non-negative). The objective values need not be according to any formula. They can rise, fall, go to zero, etc. They can be completely arbitrary.

Is the following valid?

1-4[10] 5-20[0] 21-30[30]

Yes. Note that for some turns, the objective value can be 0. Value 0 is valid at the beginning, the middle (even in several turn segments), or at the end. Just so for some turns, at least, you have positive integer objective value(s).

Note that an objective value of


is equivalent to a simple objective value of


assuming the scenario has 20 turns. In the latter, simple case, 50 applies to all 20 turns, so the effect is the same.

If it's not clear, the t-t[#] ... objective hexes thus function much like traditional single-number objectives hexes -- with one-time awarding of points -- except the point values can vary by turn.


Where the # are positive integers, where the first # applies to the Union side, while the second # applies to the Confederate side. For example: 3/5.

This is a new type of objective value, where accruals add up each turn, and may accrue to either the Union or the Confederates.

In the example 3/5, for a ten-turn scenario, if the Union hold the objective for the first 4 turns, while the Confederate seizes and holds the objective for the remainder of the game, the net effect of this objective hex is

3 + 3 + 3 + 3 - 5 - 5 - 5 - 5 - 5 - 5 = -18

assuming the Union are the first side.

One or the other of the #/# may be zero, but not both. So for an objective hex value


the Union would accrue 4 additional points for every turn they hold the objective, while if the Confederates hold that objective, they gain nothing.



the Confederates would accrue 3 additional points for every turn they hold the objective, while if the Union hold that objective, they gain nothing.

0/0 is not valid, however, as such an objective value specification is pointless, has no effect, for either side.

Important: Unlike the earlier objective value types, which take effect immediately, the per-turn accruals only happen at turn's end. If you take an objective of this type, don't be surprised if there is no immediate change in the Objective Points box in the Victory Dialog. The change will only be reflected at the end of the second side, as the turn passes on to the next.

t-t[#/#] ...

Like the preceding type -- per turn accrual -- but varies by turn segment.

For the turn specs, the same rules apply (ascending, no gaps, no overlaps, last t in the sequence is the scenario file turn).

Likewise, the same rules apply for the #/#: One or the other, or both, must be positive integer(s). However, this is permissible:

1-3[0/0] 4-6[0/5] 7-10[5/5]

This says, for turns 1-3, neither side accrues points for holding the objective. For turns 4-6, the Confederate player (only) accrues 5 points each turn for holding the objective. For turns 7-10, both sides accrue 5 points for each turn they hold the objective.

So in the above example, if the Confederate were to hold the objective for the first five turns (and if they are the first side), while the Union hold the objective for turns six through ten, the total effect would be:

0 + 0 + 0 + 5 + 5 - 0 - 5 - 5 - 5 - 5 = -10

For the t-t[] types, in one value specification, it's either all #, or all #/#, not both.

For example, this is invalid

1-4[3/4] 5-6[3] 7-10[3/3]

because the [3] doesn't mix with the [3/4] and [3/3].

Like the #/# type, points accrue with the variable t-t[#/#] etc. type only at turn's end.

Important: Within each objective value segment, no spaces!

So these are all invalid, as they contain spaces:

- 1
2 / 4
3/ 6
1- 5[10]
6 - 10[3]
6-10[ 3 /4]

In the cases


they must be exactly as shown, without spaces. If you insert spaces in any segment, the editor will complain "Invalid objective value(s)".

Segments *must* be separated by one or more spaces, however.

For example, this is valid:

1-5[5/5] 6-10[4/5] 11-18[3/5] 19-24[2/5] 25-30[0/5]

This is invalid:


In the editor Set Objective Dialog, be sure to specify a Side (select something from the provided pick list). If you don't, if you leave the Side "No Side" (XNoSide), that in effect tells the editor to strike this hex from the objectives list. That is how you remove an earlier objective, by the way, by selecting --No Side -- from the pick list.

[to be continued ...]

In today's release, you will find the following test scenarios (all based on the 000 Getting Started.scn scenario):

Scenarios/ObjectiveTest1.scn [# type]
Scenarios/ObjectiveTest2.scn [-1 type]
Scenarios/ObjectiveTest3.scn [t-t[#] type]
Scenarios/ObjectiveTest4.scn [#/# type]
Scenarios/ObjectiveTest5.scn [t-t[#/#] type]

Those are scenarios for Campaign Petersburg, not Campaign Chancellorsville, please note.

In each of those scenarios, you will find one (or maybe two) objective hex only, one scenario for each of the five general types. Play around with those scenarios to give you a feel for how each of the objective hex types works.

The scenario


combines all five types in a single scenario, as shown in the .scn file

7 7 19 -1 1
7 10 11 3/5 1 -1 -1 -1 -1 -1 -1 -1
7 10 14 1-3[40] 4-7[30] 0
7 10 19 -1 0
7 11 10 50 1
7 12 7 1-2[3/2] 3-4[2/0] 5-5[0/4] 6-7[7/5] 0 -1 -1 -1 -1 -1 -1 -1

and as shown in this composite screenshot:


Play around with that scenario in the game engine (and also if necessary test scenarios 1-5) until you get a good understanding of how it all hangs together.

(I have tested that scenario exhaustively, doing all sorts of strange gives and takes, summoning the Victory Dialog frequently to doublecheck the Objective Points box; also saving and reloading often, to test the save/reload mechanism. It all seems to be WAD.)

In the above screenshot, note how those objectives display in the editor (also the game) Objectives Dialog (see the lower right box in the screenshot above).

Note that I had to widen the Objectives Dialog considerably in order to accommodate potentially long value specifications. Note too how I widened the Set Objective Dialog. Because the latter only deals with one objective at a time, the Value text is scrollable left to right (and back), implying that you can make the Value specification to be as long as you want (within reason, and within the scenario's maximum turns limit). Because the Objectives Dialog deals with multiple objectives, although the list is scrollable, up and down (as shown), the value specifications have a fixed display field width. For very lengthy value specifications, they might be truncated at the right edge of the dialog box. So beware. The only fix to this would be to widen the Objectives Dialog even further, but then it would look stupidly wide in most situations, and in any case only mitigates the problem, doesn't solve it in absolutely all cases.

Note: Thus far, there is no consideration given to Fog of War. Either in the Objectives Dialog, or in how objective values are displayed on map, or in the Unit List.

About the .scn file configurations (see above).

For an objective hex, the fields are (left to right):

7 [indicates this is an objective hex record]
xhex yhex [x & y map coordinates]
value spec
initial owning side [0 Union, 1 Confederate]

and optionally also

a series of integers

equal in number to the last turn, where -1 signifies No Side (or unknown), while 0 signifies the Union and 1 signifies the Confederates.

Note that in the .scn files, for the per-turn accrual types, initially all ownerships are

-1 -1 -1 -1 ...

that is, all None, all unknown, because no turn has ended yet (the scenario hasn't even started!), so no end-of-turn ownership assignments have been made.

For the ObjectiveTest6.scn, here is objectives portion of the save file near the end of the test game (at the last turn, just before game's end):

7 7 19 -83 1
7 10 11 3/5 0 1 0 0 1 1 0 -1
7 10 14 1-3[40] 4-7[30] 1
7 10 19 -630 0
7 11 10 50 1
7 12 7 1-2[3/2] 3-4[2/0] 5-5[0/4] 6-7[7/5] 1 0 1 1 0 1 1 -1

[to be continued ...]

In the Unit List, for the longer objective value types, I had to jettison "Pts" as in "3Pts/5Pts", which will instead display as "3/5".

Note that the on-map objective value displays, also the Unit List objective value displays, are dynamic, will change if and as objective values vary from turn to turn.

In the editor, Turn 1 value(s) will always display.


In this first version (second implementation, for CWB) of the new-and-improved objective hex system, I gave no consideration to Fog of War. Everything -- objective hex ownership, Union point value, Confederate point value, etc. -- it all displays fully. We might try some fanciness here, but I personally wouldn't take it too far.

Go ahead, give this a spin or two. If you don't understand something, if you have any questions, just ask.


Although there are broad similarities between the Panzer Battles objective hex system (the first implementation) and the Civil War Battles system, there are enough differences that finding them all, and debugging the glitches, was quite the challenge. I believe everything is WAD, but only further testing and actual production use will tell.

In the editor Set Objective Dialog, the input gatekeeping is robust and comprehensive, I think, should catch and reject almost every bad input; but beyond the generic "Invalid objective value(s)" (or maybe "Invalid turn value(s)"), the error messages are not at all detailed. You will need to understand and internalize the rules. If you don't, you might get infuriated: "What is wrong with this?! Why is this rejecting my input?!" If you can't figure it out, just ask.

Have fun with this early Christmas present, guys. It's a literal game changer.

[question:] I'm writing up my latest Blog post and I'm wondering whether the above VP iteration [the 't-t[#] t-t[#] t-t[#] ...' option] is redundant? If the only value that matters is at the end of the last turn, then every other variation is irrelevant?


[answer:]This option is for games that end early, in effect where one side resigns prematurely.

It might also be useful if we were ever to implement "sudden death", i.e., forced early game termination, where one side attains a VP threshold, automatic victory/loss is declared, game over, even though it's not the formal end turn.

But otherwise, yes, it is pointless.

At WDS, we are giving serious consideration to using the "sudden death" variant.

Author:  mihalik [ Sun Jun 10, 2018 3:23 pm ]
Post subject:  Re: feature or bug?

Thanks, Berto!

Hopefully a preview of coming attractions.

Author:  C. Hecht [ Sun Jun 10, 2018 4:56 pm ]
Post subject:  Re: feature or bug?

Very nice that this is already used without the need to rework the objectives.

Author:  Berto [ Sun Jun 10, 2018 6:42 pm ]
Post subject:  Re: feature or bug?

For sure. We did not introduce a system that would break the many hundreds of pre-existing scenarios across all games. The new system is totally backward compatible.

Page 1 of 1 All times are UTC - 5 hours
Powered by phpBB® Forum Software © phpBB Group