Matrix Games Forums

Sorry I didn't write it a little more clearly... it is difficult because it is a recursive process.

Honestly, I haven't followed this thread that closely so I may show that I am an idiot... I also realize it may be a processing time vs. memory consumption issue. So if this is moot, no problem.

I think my poor explaination has kept a key point from being conveyed. I will come at it from another direction.

I wonder if it is fruitful to carry a list of supply paths. This method allows each hex to know whether it is in supply or not. The units simply 'ask' the hex. Furthermore, this may be a little more graceful (and quick) in handling situations where a supply line is invalidated but there is another valid supply line to replace it.

The original algorithm came from letting supply 'organically ooze' from supply points. But when you have to do that every time something moves, it is ineffective. When a unit moves, two things can happen.

(sorry pressed the wrong button - adding another message instead of editing for those who get this in email or digest)

A) moving out of the hex affects supply
B) moving into the hex affects supply.

If there are other units already affecting supply so that neither of these occur, then nothing changes and supply is the same.

If either of these occur, you want the changes to cascade hex by hex (or sea zone as the case may be). Fortunately, this only has to continue cascading as long as there are changes being made. As each hex is tested, if it's status changes, then any hexes (or sea zones as the case may be) it touches that have not already been checked or are not checked during this iteration, will need to be checked on the next iteration. This iterative process (not really recursive as I said before) will allow the changes to the ability of a hex to pass on supply ooze until the situation is not changing any further.

I may be oversimplifying the problem and it may be that you already get what I am thinking. You may have found the dividing line where a hybrid of the two solutions is most efficient.

Good Luck and Happy to have helped.

You don't have to check along the way. Just the start hex, end hex, and any hex that changed control.
(The rules don't have any supply requirements WHILE moving)

You also have the problem that it is not the hex that is drawing supply but the untis in the hex. You can easily have a situation where the hex would be in supply for one type of unit but not another. Frex: A GE unit in a hex is being supplied through an IT HQ; But a Finnish unit in the same hex would be OOS.

For the list containing paths supply moves through, I think it would be best if it contains a list of all units tracing through the hex.
 
Possible memory structure:
 
Map supply_paths
key: hex_id/seazone_id
value: list of units tracing through that hex
 
You would only add the hexes to the next secondary/primary source. So a normal unit would only be in the list for up to 4 hexes. You would also have:
 
Map unit_supply_path
key: target_id (for primary or secondary source)
value: list of units tracing to target
 
You'd have a list of secondary supply sources that are OOS
You'd have a list of units to have their supply recalculated.
 
The algoritm would be:
after unit move completed
for the start hex, check if it now empty and contains an enemy ZOC.
If so, call searchSupplyMap (hex_id, ZOC_nationality)
for any hex which control was changed
call searchSupplyMap (hex_id, null) (no nationality because all units on other side will lose supply)
for any hex adjacent to end hex and not containing a land unit
if endhex didn excert ZOC and now excerts ZOC
call searchSupplyMap (hex_id, ZOC_nationality)
 
for each unit in recalculate_list that is a secondary source
delete all entries for it from Map supply_path 
recalculate supply path
if path found, add path to Map supply_path 
else set out of supply, 
lookup all units tracing to it in Map unit_supply_path,
add these to recalculate_list
 
In case of chaining secondary sources you might have to repeat this step until no change happens.
 
for each unit in recalculate_list that is not a supply source
delete all entries for it from Map supply_path 
recalculate basic supply path (max 4 hexes except for overseas paths)
if path found, add path to Map supply_path 
else set out of supply
 
 
function searchSupplyMap (hex_id, ZOC_nationality)
{
lookup hex_id in Map supply_path
for each entry, check if at war with ZOC_nationality.
If true, add unit_id to recalculate_list,
}
 
Finally, you'll need to check for units put back in supply, which I think is harder. Potentially a secondary source in siberia might be put back in supply by a hex in poland opening, and the path doesn't exist so it's not in any list.
 
I think the best algorithm for this is to check all hexes that have become available and try to 'expand the suply grid' into any new opening.
 
for each hex that changed control, and for the end hex if it was empty of landunits but now isn't and is in enemy ZOC 
attempt to trace a rail path FROM this hex along a shotest possible route:
variable LENGHT holds the number of non-rail hexsides crossed in this path
List tested holds allready tested hexes
create a Map supplyTest
add the hex_id of the tested hex to the map, with LENGHT as the value
for each hex in Map supplyTest
for each adjacent hex not in list tested
if adjacent hex can trace to tested_hex and is rail hexside, add to Map supplyTest with same lenght
if adjacent hex can trace to tested_hex and is not rail hexside, add to Map supplyTest with lenght = lenght+1 (+2 for desert), unless lenght now is 5
if there are units in hex, and lenght <= supply path lenght, and units&nbsp;are OOS and can cooperate, set units in supply
add to list tested
&nbsp;
if checked hex doesn't have a primary path, attemt to trace a basic path to a secondary source.
same algorithm as above, except lenght is always incremented regardless of rail.
&nbsp;
&nbsp;
&nbsp;
&nbsp;

ORIGINAL: Taxman66

You also have the problem that it is not the hex that is drawing supply but the untis in the hex. You can easily have a situation where the hex would be in supply for one type of unit but not another. Frex: A GE unit in a hex is being supplied through an IT HQ; But a Finnish unit in the same hex would be OOS.

What you said here is a key point about the hopelessness of maintaining the supply status of eaach hex on the map.

Even if we are just talking about the German player, some the units that he controls may be in supply and others in the same hex out of supply because of the supply rules. A simple example is a Rumanian city being a primary supply source for a Rumanian unit while a German unit sitting in the city could be out of supply.

ORIGINAL: Incy

For the list containing paths supply moves through, I think it would be best if it contains a list of all units tracing through the hex.

Possible memory structure:

Map supply_paths
key: hex_id/seazone_id
value: list of units tracing through that hex

You would only add the hexes to the next secondary/primary source. So a normal unit would only be in the list for up to 4 hexes. You would also have:

Map unit_supply_path
key: target_id (for primary or secondary source)
value: list of units tracing to target

You'd have a list of secondary supply sources that are OOS
You'd have a list of units to have their supply recalculated.

The algoritm would be:
after unit move completed
for the start hex, check if it now empty and contains an enemy ZOC.
If so, call searchSupplyMap (hex_id, ZOC_nationality)
for any hex which control was changed
call searchSupplyMap (hex_id, null) (no nationality because all units on other side will lose supply)
for any hex adjacent to end hex and not containing a land unit
if endhex didn excert ZOC and now excerts ZOC
call searchSupplyMap (hex_id, ZOC_nationality)

for each unit in recalculate_list that is a secondary source
delete all entries for it from Map supply_path 
recalculate supply path
if path found, add path to Map supply_path 
else set out of supply, 
lookup all units tracing to it in Map unit_supply_path,
add these to recalculate_list

In case of chaining secondary sources you might have to repeat this step until no change happens.

for each unit in recalculate_list that is not a supply source
delete all entries for it from Map supply_path 
recalculate basic supply path (max 4 hexes except for overseas paths)
if path found, add path to Map supply_path 
else set out of supply


function searchSupplyMap (hex_id, ZOC_nationality)
{
lookup hex_id in Map supply_path
for each entry, check if at war with ZOC_nationality.
If true, add unit_id to recalculate_list,
}

Finally, you'll need to check for units put back in supply, which I think is harder. Potentially a secondary source in siberia might be put back in supply by a hex in poland opening, and the path doesn't exist so it's not in any list.

I think the best algorithm for this is to check all hexes that have become available and try to 'expand the suply grid' into any new opening.

for each hex that changed control, and for the end hex if it was empty of landunits but now isn't and is in enemy ZOC 
attempt to trace a rail path FROM this hex along a shotest possible route:
variable LENGHT holds the number of non-rail hexsides crossed in this path
List tested holds allready tested hexes
create a Map supplyTest
add the hex_id of the tested hex to the map, with LENGHT as the value
for each hex in Map supplyTest
for each adjacent hex not in list tested
if adjacent hex can trace to tested_hex and is rail hexside, add to Map supplyTest with same lenght
if adjacent hex can trace to tested_hex and is not rail hexside, add to Map supplyTest with lenght = lenght+1 (+2 for desert), unless lenght now is 5
if there are units in hex, and lenght <= supply path lenght, and units are OOS and can cooperate, set units in supply
add to list tested

if checked hex doesn't have a primary path, attemt to trace a basic path to a secondary source.
same algorithm as above, except lenght is always incremented regardless of rail.

Your's was a long post I don't have the mental clarity to read through it clearly at the moment. I believe the code I have written does most of what you say, although I am not maintaining a supply status for each hex.

What I think is a quick and simple solution for re-determining supply is to check all the previous supply paths. That is done working backwards from the list of primary supply sources, secondary, tertiary, and lastly units. In the middle of that are the calculations about overseas supply.

I'm keeping a list of units supplied by each link, so if a link goes bad for some reason or another, I'll know immediately which units need to have their supply status determined afresh.

The place where this might not work so well is when the weather changes, reducing the basic supply path range, which can render a number of links infeasible.

The algorithm doesn't try to maintain the supply status of every supplied hex.
It just remembers actually traced supply paths.
&nbsp;
The only list of hex status it has is a temporary list whenever a new hex gains supply. This is because&nbsp;it tries to expand 'backwards' all possible&nbsp;paths&nbsp;through the newly supplied&nbsp;hex, to see if any OOS units can now be supplied this way.
&nbsp;
btw, you could split the stored list of traced supply paths by lenght.
one list for paths requiring 2 or less supply range, one for paths requiring 3, and one for paths requiring 4.
This approuach can get complex for chained routes involving several weather zones, though.
&nbsp;
You may also need to modify the 'reconnect' part of your algorithm (the part that checks if supply has been reaquired) to have it try to shorten paths that requires 3 or 4 hexes. Or else a path that previously required 3 but now has a lenght 2 path available&nbsp;would be calculated to be OOS in rain.
&nbsp;
If you can't make the algorithm work independent of weather changes you must recalculate all supply paths from scratch every time the weather changes. This might be acceptable, though.

btw, let me know if you want me to work more on the supply algorithms. You can post me the relevant code you already have, and I can make suggestions, or at least write pseudo-code more similar to your preferred language/coding convention

ORIGINAL: Incy

btw, let me know if you want me to work more on the supply algorithms. You can post me the relevant code you already have, and I can make suggestions, or at least write pseudo-code more similar to your preferred language/coding convention

Thanks for the offer.[:)]

As of right now the new supply routines are over 6300 lines of code - probably not a good idea to post them.[;)]

I'll remember your offer if I become puzzled with what I am coding for supply. For right now, I am stepping the code through the routines that I have written to validate that they are performing as intended. Slow going but very informative. Did you know the Japanese controlled sea areas can serve to transmit supply for German units most of the time? Not likely to occur but the rules permit that to happen.

Yes. I pop a japanese CP into the med at first opportunity as a standard practice. Makes life for Italy a lot easier.

ORIGINAL: Incy

Yes. I pop a japanese CP into the med at first opportunity as a standard practice. Makes life for Italy a lot easier.

Yes, but that supply can be blocked by the CW with a combat unit (air or sea) if the CW is at war with Italy.

ORIGINAL: Incy

Yes. I pop a japanese CP into the med at first opportunity as a standard practice. Makes life for Italy a lot easier.

It used to. The FAQ answers make it real simple for the Wallies to cut.

I finally got the code for overseas supply lines working for secondary supply sources. Here are two examples. Next up are tertiary supply lines (from 'secondary' supply sources that can not reach a primary supply source but can reach another secondary/tertiary supply source.
===

ORIGINAL: Shannon V. OKeets

I finally got the code for overseas supply lines working for secondary supply sources. Here are two examples. Next up are tertiary supply lines (from 'secondary' supply sources that can not reach a primary supply source but can reach another secondary/tertiary supply source.
===

Why is there a falco displayed in both screenshots ?

ORIGINAL: Froonp

ORIGINAL: Shannon V. OKeets

I finally got the code for overseas supply lines working for secondary supply sources. Here are two examples. Next up are tertiary supply lines (from 'secondary' supply sources that can not reach a primary supply source but can reach another secondary/tertiary supply source.
===

Why is there a falco displayed in both screenshots ?

I haven't gotten to supply for individual units yet, so the counter being shown is simply the one I clicked on to bring up the Supply Status screen (I never change it).

I'll rewite the code to show the HQ for now - assuming the player has clicked on one of the HQs in the supply sources list on the left. Eventually, I'll let the player click on individual units, which will displayed at the bottom of the form (I've cut it off for these screen shots).

I guess I'll just leave the unit image blank if the player clicks on a suply source that is a city.[&:]

ORIGINAL: Shannon V. OKeets

ORIGINAL: Froonp

ORIGINAL: Shannon V. OKeets

I finally got the code for overseas supply lines working for secondary supply sources. Here are two examples. Next up are tertiary supply lines (from 'secondary' supply sources that can not reach a primary supply source but can reach another secondary/tertiary supply source.
===

Why is there a falco displayed in both screenshots ?

I haven't gotten to supply for individual units yet, so the counter being shown is simply the one I clicked on to bring up the Supply Status screen (I never change it).

I'll rewite the code to show the HQ for now - assuming the player has clicked on one of the HQs in the supply sources list on the left. Eventually, I'll let the player click on individual units, which will displayed at the bottom of the form (I've cut it off for these screen shots).

I guess I'll just leave the unit image blank if the player clicks on a suply source that is a city.[&:]

Or provide an image of a hex with a city icon? Perhaps the city name could be added to that display.

ORIGINAL: abj9562

ORIGINAL: Shannon V. OKeets

ORIGINAL: Froonp



Why is there a falco displayed in both screenshots ?

I haven't gotten to supply for individual units yet, so the counter being shown is simply the one I clicked on to bring up the Supply Status screen (I never change it).

I'll rewite the code to show the HQ for now - assuming the player has clicked on one of the HQs in the supply sources list on the left. Eventually, I'll let the player click on individual units, which will displayed at the bottom of the form (I've cut it off for these screen shots).

I guess I'll just leave the unit image blank if the player clicks on a suply source that is a city.[&:]

Or provide an image of a hex with a city icon? Perhaps the city name could be added to that display.

The insert map already does that.

ORIGINAL: Shannon V. OKeets

ORIGINAL: abj9562

ORIGINAL: Shannon V. OKeets



I haven't gotten to supply for individual units yet, so the counter being shown is simply the one I clicked on to bring up the Supply Status screen (I never change it).

I'll rewite the code to show the HQ for now - assuming the player has clicked on one of the HQs in the supply sources list on the left. Eventually, I'll let the player click on individual units, which will displayed at the bottom of the form (I've cut it off for these screen shots).

I guess I'll just leave the unit image blank if the player clicks on a suply source that is a city.[&:]

Or provide an image of a hex with a city icon? Perhaps the city name could be added to that display.

The insert map already does that.

Oh duh... face slap to self.

ORIGINAL: Froonp

ORIGINAL: Shannon V. OKeets

I finally got the code for overseas supply lines working for secondary supply sources. Here are two examples. Next up are tertiary supply lines (from 'secondary' supply sources that can not reach a primary supply source but can reach another secondary/tertiary supply source.
===

Why is there a falco displayed in both screenshots ?

Here are two screen shots of an improved version, showing the HQ unit if its path is being displayed. I fixed a bug in the search routine so it now finds a supply path for Umezu.

The colors are still for Italy since the Italian player is the current decision maker.


EDIT: I messed up cropping the top and bottom of the JPG file.[:@]