Supply Paths

[Shannon V. OKeets]

ORIGINAL: Froonp

But you should write on your schema that the black lines are the part of the railway supply lines that are not on a railway. This would be clearer.
Also, you should add some note, maybe, beside the "contiguous sea areas" note, to say that those there are conditions for that sea areas to be usable.

There are many conditions (e.g., ZOCs) and I expect the tutorial to address them. But here I wanted the diagram to focus exclusively on the linkages between units, secondary sources, and primary sources showing the 3 types of supply paths (basic, rail, and overseas).

[Froonp]

There is another possibility not shown where the Secondary (e.g., an HQ) is in a coastal hex and connects directly to the Overseas Supply Path without going through a port.

This secondary HAS to be an HQ. The "e.g." commentary you put in brakets leads to think it can be another kind of Secondary supply source. Another secondary supply source would not work.

I mean, a coastal Capital City that has no port, would not allow to trace to the Overseas Supply Path.

Edit : So, indeed, on your graphic (that I consider pinning on the wall of our game room), should show "Port or HQ" instead of Port in the blue circle.

Can you show the updated graphic, so that I pin it on our wall ? [:D]

[Froonp]

What about this one ?
Expanding on yours, and showing the Railway supply path as able to trace 4 non rail hexes simplifies the graphic IMO.

[lomyrin]

I like the clarity of the chart shown.
 
Perhaps it should also point out that the port of arrival before it gets to the primary supply source does require a 1 charge against the 4 allowed basic hexes.
 
Lars

[Shannon V. OKeets]

ORIGINAL: lomyrin

I like the clarity of the chart shown.

Perhaps it should also point out that the port of arrival before it gets to the primary supply source does require a 1 charge against the 4 allowed basic hexes.

Lars

I was reluctant to add details like that because there are so many other factors that affect supply lines: terrain, ZOCs, friendly units, enemy naval air units, friendly naval air units, convoys/TRS/AMPH in sea areas, weather, hex control, neutral countries. Instead I focused the diagram on what I consider the most difficult to understand aspect of the supply rules: the linkage between units, secondary sources, and primary sources. If the player can understand how the linkages work (and do not work) then all the other details can be learned on top of that core concept. So, I kept all the side issues out of the picture. It's still fairly complex as it is.

For the supply tutorial, I plan on starting with the simplist cases and build upon that knowledge gradually. What I currently envision is showing both an abstract rendering (like those above) and a screen shot that corresponds to the abstract on the same page of the tutorial, with text on the side describing what is shown. I think of that as: Concept + Example + Description.

[Shannon V. OKeets]

ORIGINAL: Froonp
What about this one ?
Expanding on yours, and showing the Railway supply path as able to trace 4 non rail hexes simplifies the graphic IMO.

By adding more details, you have opened up more questions.

- The 6-3 implies that the unit is a land unit. Does it apply to air and naval units too?
- By saying 4 hexes, the question comes up as to the effect of hex and hexside terrain. And does that apply in all weather?

[I know the answers to those questions, but the novice might not.]

Instead of 'Shore', I would use 'Coastline', since RAW refers to coastal hexes. I had thought about using a hexagon for the port symbol, to indicate it is a hex. Perhaps that should be done and then the combat unit could also be placed inside of a hex and the hex labeled as a coastal hex. I would make the Port and HQ in a coastal hex two separate pictures, rather than combine the two as one element of the diagram.

For the Railway Supply Path, you might say "Same as Basic Supply Path plus a unlimited number of connected rail hexes." That way, the "4 hexes" reference can be left out.

Using a different line type for the rail supply path is an improvement. But I also want to show the actual rail lines too. I think it helps to explicitly show that a rail supply path is composed of both the basic supply path elements that traverse non-rail hexes plus hexes connected by rail lines.

[Froonp]

A second try.
This will be nice pinned on our WiF room ! [:D]

[Shannon V. OKeets]

Nice.

I suggest using the same color blue for the coastal hex as you used for the port, so it is not confused with secondary supply.

[Incy]

tracing a basic supply path overseas without any railroad path/secondary source inbetween is missing...

[Incy]

also, should emergency HQ supply be on the chart?

[Shannon V. OKeets]

ORIGINAL: Incy

also, should emergency HQ supply be on the chart?

Good point. I had thought about teh situation of expending a supply point to make an HQ a primary supply source, and did not include that because it's more or less covered by the Primary Supply Source icon. But emergency HQ supply is different since it only affects units within the basic supply path of the HQ.

[Jimm]

This is an excellent aide-memoir which I also intend to steal for personal use!

Is the option for limited overseas supply available and if so you will need to take into account?

[Shannon V. OKeets]

ORIGINAL: Jimm
This is an excellent aide-memoir which I also intend to steal for personal use!

Is the option for limited overseas supply available and if so you will need to take into account?

That's something I consider as a detail and not part of supply linkage per se. Bascially, there are times when supply can be traced through a sea area and times when it cannot. The optional rule Limited Overseas Supply changes the conditions under which it can/cannnot be traced.

[npilgaard]

(From another thread, but I think it suits this one better:)

ORIGINAL: Shannon V. OKeets
This monitor stuff is already annoying me in other places - and it is quite necessary in those other places. For example, changing who controls each hex whenever a player moves a land unit, and redetermining supply in the immediate vicinity whenever a unit moves. I am still puzzling over how best to do the latter. I would like the displayed supply status for each unit to be continuously correct, yet I do not want to have to redetermine supply for every unit on the map every time a unit moves. For instance, theoretically, moving a unit on one continent could put units on another continent out of supply.

I am not a programmer and don't have much experience with handling (potentially) large amounts of data in a fast way, but a few thoughts on this anyway:

Supply could be divided into basic supply lines (BSL) (most units) and railway supply lines (RSL)(secondary supply sources - SSS).

In general - when a hex (or sea area) changes control:
for the side which loses control of the hex: no supply needs to be checked for units already out-of-supply.
for the side taking control of the hex: no supply needs to be checked for units already in supply

Moving units:
Whenever a unit is moved from an enemy ZoC, supply needs to be checked, as enemy ZoC would then prevent supply to be traced through that hex. And vice-versa when moving into a previously empty hex within enemy ZoC
Whenever a SSS is moved, supply needs to be checked, as the SSS move may put some units into supply and some out of supply.

Combats:
Units been killed: if a SSS, supply needs to be checked.
hexes changing control and units moved - as above.


Some different approaches to the problem:

1.
Whenever a hex changes control, supply for every SSS which could have traced a RSL through the hex is rechecked. Depending on how fast the supply-path-check routine works and how many SSSs in play (late war maybe 50 or more (?) ) this may be somewhat timeconsuming.
Then check BSL for all units of that side within 4 hexes of the hex (or fewer, depending on wheather) to adjust for potentially new BSPs.
These checks could be made for one side first, and then for the other side, if preferred.
Advantage of this approach is that no data about supply paths need to be stored. Disadvantage: it may (quite likely) turn out to be to time-consuming.

2.
Store data about current supply path. Some ideas:
When 'main' check on supply is done (at least start of turn, but maybe at start of each phase), data about each units supply path is stored.
For non-SSS: to each unit, attach a list of up to 4 numbers, indicating the hexes of its BSL (maybe this is not necessary, since the BSL is only 1-4 hexes long, depending on wheather, and could probably be quickly determined directly without having to rely on stored data).
For each SSS: this is more difficult, since each RSL can potntially be very long, and cover a lot of hexes.
One way (a): to each SSS is assigned a list of hexes, like the one for non-SSS.
Another way (b): to each hex is assigned a list with the SSSs tracing a RSL through that hex (or for most hexes, no list is assigned, since no RSLs are traced through)

Whenever control of a hex is changed:
rechecking RSLs:
if (a): go through all SSSs lists and see if the hex is included - if it is, the RSL for that SSS needs to be recalculated.
(b): go through the list assigned to the hex, and recalculate for those SSSs.
In both cases: if a SSS traces to another SSS, which has been cut off, supply for the first SSS needs to be recalculated. If a SSS has been cut oos, recheck BSL for all friendly units within (up to) 4 hexes from that SSS.

After supply of SSS has been determined, BSL for each unit (not checked for already) within (up to) 4 hexes of the hex which changed control i checked.
If a list is attached to each unit, only check if the hex is on that list.

Moving units:
Since moving a SSS can lead to significant changes in supply, a list could be assigned to each SSS, indicating which units (including other SSS) have traced a BSL to it. When the SSS have been moved, BSL then has to be rechecked for those units (to see if they are still in supply), as well as for all currently oos units within (up to) 4 hexes from the new location of the SSS (to see if they get into supply).

With the lists mentioned above, maybe some kind of cross-reference are required, so both are available: a list for each SSS of which units it supplies, and a variable for each unit indicating from which SSS it gets its supply. That allows for quick changing of 'focus' from one to the other, eg when determinig a new supply path.

In general: when the 'main' check on supply is done (going through all units and determining each ones supply path), only one supply path is stored in the lists/data, even if there are many possible ones. The main thing here is to decide whether a unit is oos or not. Afterwards, as long as that supply path is not affected by movement, hexes changing control, combat losses etc. then that unit is still in supply, so no need to waste time on rechecking for that unit, every time.
Depending on how time consuming it is:
since 'main' check is not done during movement etc. maybe it would be worth it to find a 'good' supply path for a unit to be stored in the data set - ie. not just the first one which allows for supply, but maybe (if available) one that is less likely to be cut by enemy movement, combat etc. That will reduce the chance that this 'safer' supply path will be cut off during the impulse.

This is quite a complex problem - I probably haven't covered all possibilities in the above - and again, this is just some random thoughts - don't know how well they will work if implemented.

[Shannon V. OKeets]

Nikolaj,

Thank you for thinking this through and posting it.

Yes, the problem is difficult - which makes it interesting to me.

I will start with the list of possible supply paths (as we have discussed earlier in this thread) because any one of them might be in use. The Basic versus Rail supply path differentiation is not quite sufficient to handle all those cases, since secondary supply sources can trace to other SSS using a Basic supply path.

Storing the immediately previous successful supply path (even for units that are now out of supply) seems to be a good idea at all times.

I had already decided that the algorithm for determining supply paths should find the shortest path. Finding the least vulnerable is vastly more difficult, if for no other reason that defining vulnerable is hard to do.

Your comments led me to decide that storing whether a hex is currently being used for tracing supply (two pieces of information: one for each side) would be very helpful. It only requires 2 bits of storage for each land hex which is easy to provide. That way, when a hex changes control or has its ZOC status change, I can quickly check to see if there is any effect on supply for units currently in supply. I would still need to do a more thorough check for units previously out of supply to see if the change enables them to be put back in supply.

If the hex is being used for supply, then I can search through the stored current supply path for each in supply unit on the given side to see if it is using that hex for supply.

Expanding on this idea, I might stored the # of units using the hex for supply rather than a simple booelan (Yes/No). That would enable me to partially evaluate the importance of a hex for keeping units in supply (I am thinking of the code for the AI Oppoent's decision on where best to place a partisan). Cutting a supply path by taking control of a hex being used for supply by a lot of units would be a good choice.

[In the above I used the word hex, though I meant both hexes and sea areas.]

When I work this all out, I'll post it in this thread before writing the code.
EDIT: supply for all units has to be checked whenever the weather changes (practically this means if it changes for any weather zone).

[npilgaard]

ORIGINAL: Shannon V. OKeets
Thank you for thinking this through and posting it.

And thank you for the huge effort you put into this project!

ORIGINAL: Shannon V. OKeets
Yes, the problem is difficult - which makes it interesting to me.

I will start with the list of possible supply paths (as we have discussed earlier in this thread) because any one of them might be in use. The Basic versus Rail supply path differentiation is not quite sufficient to handle all those cases, since secondary supply sources can trace to other SSS using a Basic supply path.

Yes, I had forgotten about that one.

ORIGINAL: Shannon V. OKeets
Storing the immediately previous successful supply path (even for units that are now out of supply) seems to be a good idea at all times.

Yes - no need to lose the info, when time has just been spent cellecting it [:)]

ORIGINAL: Shannon V. OKeets
I had already decided that the algorithm for determining supply paths should find the shortest path. Finding the least vulnerable is vastly more difficult, if for no other reason that defining vulnerable is hard to do.

I don't have any idea of the time cost of calculating the shortest possible path for a unit, compared to just stopping when the first succesful path has been found (often the stored previously used path can probably be used - maybe always check that path first, to see if it is still useable). The later will save some time, but the former will probably often provide a 'better' path which can be reused more often eg in bad weather etc.

ORIGINAL: Shannon V. OKeets
Your comments led me to decide that storing whether a hex is currently being used for tracing supply (two pieces of information: one for each side) would be very helpful. It only requires 2 bits of storage for each land hex which is easy to provide. That way, when a hex changes control or has its ZOC status change, I can quickly check to see if there is any effect on supply for units currently in supply. I would still need to do a more thorough check for units previously out of supply to see if the change enables them to be put back in supply.

If the hex is being used for supply, then I can search through the stored current supply path for each in supply unit on the given side to see if it is using that hex for supply.

You are probably right that full lists of which units are using a hex for supply are not needed, since only one run through all units (and most of them have short supply paths) is needed for eg a land move, which will be handled quickly, even with 1000+ units.

ORIGINAL: Shannon V. OKeets
Expanding on this idea, I might stored the # of units using the hex for supply rather than a simple booelan (Yes/No). That would enable me to partially evaluate the importance of a hex for keeping units in supply (I am thinking of the code for the AI Oppoent's decision on where best to place a partisan). Cutting a supply path by taking control of a hex being used for supply by a lot of units would be a good choice.

Sounds like a good idea.
However, the number of a hex may not provide the 'true' supply value of the hex, since the paths chosen are always the shortest ones, many will probably go through the same hexes (eg for an entire front section). Then that hex will look crucial, even though supply may be available through (sometimes only slightly) different paths. Otoh, some hexes may be 'true' crucial, if a lot of units trace supply through that hex (or sea area) and no other paths are available.

ORIGINAL: Shannon V. OKeets
[In the above I used the word hex, though I meant both hexes and sea areas.]

When I work this all out, I'll post it in this thread before writing the code.
EDIT: supply for all units has to be checked whenever the weather changes (practically this means if it changes for any weather zone).

So, in most cases supply will be checked (for all units on map?) at the beginning of every impulse, since often the weather changes in at least one of the weather zones.
Sounds like a good idea, imho, to make a 'fresh' check at every impulse.

[Shannon V. OKeets]

Weather is rolled for only on odd numbered impulses.

[npilgaard]

Lol - yes, I didn't think about that [:)]

[bredsjomagnus]

Im not a programmer either but here is a question on the subject anyway.
 

 
I might stored the # of units using the hex for supply rather than a simple booelan (Yes/No). That would enable me to partially evaluate the importance of a hex for keeping units in supply (I am thinking of the code for the AI Oppoent's decision on where best to place a partisan). Cutting a supply path by taking control of a hex being used for supply by a lot of units would be a good choice.

 
Couldn´t this mean that some hexes get too important for the AI, so that wrong decisions might be the consequence? The situation im thinking of is that alot of units might use the same supply path even though they could use some other supply paths instead. A human player would see that there are alot of alternetivs to those supply paths while the AI just knows that these hexes supplies alot of units and therefor make these hexes disporporionatly important.
 
Just a thought.

[Shannon V. OKeets]

ORIGINAL: bredsjomagnus
Im not a programmer either but here is a question on the subject anyway.

 
I might stored the # of units using the hex for supply rather than a simple booelan (Yes/No). That would enable me to partially evaluate the importance of a hex for keeping units in supply (I am thinking of the code for the AI Oppoent's decision on where best to place a partisan). Cutting a supply path by taking control of a hex being used for supply by a lot of units would be a good choice.

Couldn´t this mean that some hexes get too important for the AI, so that wrong decisions might be the consequence? The situation im thinking of is that alot of units might use the same supply path even though they could use some other supply paths instead. A human player would see that there are alot of alternetivs to those supply paths while the AI just knows that these hexes supplies alot of units and therefor make these hexes disporporionatly important.

Just a thought.

When programming, or designing a program, I find selecting the right words and defining them precisely can make a big difference in both understanding and solving a problem. So,

- A Critical supply path would be one where no alternative path exists.
- A Critical hex would be one that: (1) is on a Critical supply path and (2) can not rerouted around.
- An Important hex would pertain to the current supply paths in use. Degree of importance measures the number of units using the hex for supply.
- A Vulnerable hex would be one that the enemy could render unusable for supply purposes, by either taking out control of it or by exerting a ZOC into it. The degree of vulnerability would measure the ease with which the enemy could render it unusable versus the ease with which we can prevent their so doing.

I have a long way to go in figuring this out. Perhaps vulnerability should be split into two parts: attackable and defendable.

A new thought (10 seconds old) is to think in terms of Critical Path Methodology (CPM) analysis. But it is late, and I'm tired. A good night's sleep oftentimes makes things much easier to understand.