Still unplayable

World in Flames is the computer version of Australian Design Group classic board game. World In Flames is a highly detailed game covering the both Europe and Pacific Theaters of Operations during World War II. If you want grand strategy this game is for you.

Moderator: Shannon V. OKeets

Post Reply
User avatar
Dabrion
Posts: 740
Joined: Tue Nov 05, 2013 10:26 am
Location: Northpole

Still unplayable

Post by Dabrion »

I gave up on this again..

I'd love to have some more documentation about the map files to be able to reconstruct the map, though. There seems to be no file that lays out borders and rivers and rail routing is a bit obscure. Any info on this?

For those enjoying, carry on..
"If we come to a minefield, our infantry attacks exactly as it were not there." ~ Georgy Zhukov
User avatar
michaelbaldur
Posts: 4805
Joined: Fri Apr 06, 2007 6:28 pm
Location: denmark

RE: Still unplayable

Post by michaelbaldur »

borders and rivers and rail routing

you can see those on the map

not sure what you mean
the wif rulebook is my bible

I work hard, not smart.

beta tester and Mwif expert

if you have questions or issues with the game, just contact me on Michaelbaldur1@gmail.com
Shannon V. OKeets
Posts: 22165
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: Still unplayable

Post by Shannon V. OKeets »

Borders between countries are determined by the country numbers assigned in the TER file. Control of hexes is then modified using the ALT files, which has different values depending on the year the scenario begins. There is also something somewhere that differentiates between the scenarios that start in in June of 1941 and those that start in December of 1941.

The river and rail data is in the HST file.

The RLS data is purely for rendering the graphics for rivers and lakes: the pieces that extend beyond the hexsides separated by rivers and lakes. That is, if the river covers just a couple of hexsides, then the tag end of the river might be drawn in another hex, just so the river doesn't abruptly end at the end of the hexside.

The graphics for the rivers and lakes use a tightly packed bit structure. That is undocumented because creating it is done by 'reading' a scanned in image of blue lines on a white background. That is a separate program (pre-processing).

In effect, changing the rivers and lakes is way out of scope for the MWIF project: reproduce WIF FE on the computer.
Steve

Perfection is an elusive goal.
User avatar
Dabrion
Posts: 740
Joined: Tue Nov 05, 2013 10:26 am
Location: Northpole

RE: Still unplayable

Post by Dabrion »

Ok, didn't make myself as clear as I could.

RAILS: I want to know more than is written down in the players manual about the routing of rail lines through the hexes. For hexes without features (cities, ports, resources, or label entries) I have a hard time coming up with a valid heuristic for the routing. Routing through the center of the hex leads to funny patterns, esp. on the coast lines. could you elaborate on where that information can be found or if it is hard coded.

RIVERS: I have had a look at the AggregateRiverLake.RVR and the content looks like an imperative language that describes splines and not a bit pattern. In any case could you describe how to read the file so I can improve my map reconstruction.

NAM file: Several hexes have more than one label entry (Königsberg in East Prussia for example). Some of them are unlinked but carry information inthe positions for ports and factories etc., even without factories in the hex. What does that mean?

FONTS: The font in use for the map, does it have a name?


Pls find a screenshot attached to have a look at the rail like issues.

Image
Attachments
europe.jpg
europe.jpg (4.53 MiB) Viewed 225 times
"If we come to a minefield, our infantry attacks exactly as it were not there." ~ Georgy Zhukov
User avatar
Dabrion
Posts: 740
Joined: Tue Nov 05, 2013 10:26 am
Location: Northpole

RE: Still unplayable

Post by Dabrion »

bump
"If we come to a minefield, our infantry attacks exactly as it were not there." ~ Georgy Zhukov
User avatar
AxelNL
Posts: 2389
Joined: Sat Sep 24, 2011 12:43 pm
Location: The Netherlands

RE: Still unplayable

Post by AxelNL »

ORIGINAL: Dabrion

bump

You mentioned in another thread that you pay others to find out for you what you want. What are you offering Steve? he might value the same thing I asked....
User avatar
Dabrion
Posts: 740
Joined: Tue Nov 05, 2013 10:26 am
Location: Northpole

RE: Still unplayable

Post by Dabrion »

wanna see the wares first!

p.s.: While we are waiting.. please educate me about the "Afsluitdijk". This looks like something that happens when my head hits the keyboard after a long night..
"If we come to a minefield, our infantry attacks exactly as it were not there." ~ Georgy Zhukov
Ubercat
Posts: 100
Joined: Wed Dec 19, 2007 3:35 am
Location: Near Allentown, PA

RE: Still unplayable

Post by Ubercat »

Trolling is exhausting work.
"I’m not convinced that faith can move mountains, but I’ve seen what it can do to skyscrapers." -William H. Gascoyne
Shannon V. OKeets
Posts: 22165
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: Still unplayable

Post by Shannon V. OKeets »

ORIGINAL: Dabrion

Ok, didn't make myself as clear as I could.

RAILS: I want to know more than is written down in the players manual about the routing of rail lines through the hexes. For hexes without features (cities, ports, resources, or label entries) I have a hard time coming up with a valid heuristic for the routing. Routing through the center of the hex leads to funny patterns, esp. on the coast lines. could you elaborate on where that information can be found or if it is hard coded.

RIVERS: I have had a look at the AggregateRiverLake.RVR and the content looks like an imperative language that describes splines and not a bit pattern. In any case could you describe how to read the file so I can improve my map reconstruction.

NAM file: Several hexes have more than one label entry (Königsberg in East Prussia for example). Some of them are unlinked but carry information inthe positions for ports and factories etc., even without factories in the hex. What does that mean?

FONTS: The font in use for the map, does it have a name?


Pls find a screenshot attached to have a look at the rail like issues.

Image
You've really messed up the data files.

- You have lost all the icons for resources and factories.
- You've removed all the indicators for which hexsides are rivers.
- You've lost all the hexside terrain for alpine hexsides.

It's hard to start to determine what data you have changed to achieve all this.

The Terrain data file holds information on which hexes have resources and factories, so it seems those files are damaged. It also holds information on 'labels', holding an index into the Labels data.

The Labels data with a 0 for size and 'none' for the name is used to enter routing directions for the rail lines. The Labels entry then contains a number between 1 and 25 for the routing point for the rail line. That is how the rail lines are routed along the coastal hexes that do not contain a city, resource, factory, or port. See page 196 of volume 2 of the Players Manual for what the numbers 1 through 25 indicate. If you have the original files, you can see numerous examples of how those 'none' entries are used to route the rail lines. For example, along the coastlines of Greece and Spain.

The River data is packed binary. Each hex is 152 pixels by 136 pixels. Each pixel can be one of 3 shades of blue (a darker blue outline for rivers and lakes). Each of the 152 rows is read separately. The 136 pixels are split into 17 groups of 8 pixels each. Letter codes are used to indicate a number of blank pixels: A = 1, B = 2, Q = empty row.

I am a little vague on the details at this point (I wrote this code 7 years ago). Below is the routine that reads the RVR file. Note that this holds the data for both the rivers and lakes.

===

procedure ReadMassiveRiverLakesFile;
var
PCol, PRow: Integer; // Indices into the pixels for a hex bitmap.
I: Integer;

function StripNextPixelRow: String;
var
PosC: Integer; // Position of next semicolon in string.
L: Integer; // Length remaining after first value trimmed.
begin
PosC := Pos(';', S);

Result := LeftStr(S, Pred(PosC)); // 1st value, excludes semicolon.
L := Length(S) - Succ(Length(Result)); // Length remaining.
S := RightStr(S, L); // Trim left value and semicolon.
end;
// ****************************************************************************
// ReadMassiveRiverLakesFile.
// ****************************************************************************
begin
Readln(FRL, S); // Read one line/hex of data.
S1 := StripNextPixelRow; // Remove row and column information.
(*
// ****************************************************************************
// Check if the stored river/lake bitmap is for the correct hex.
// ****************************************************************************
ReadRow := StrToInt(TrimString(S1)); // Extract the row #.
ReadColumn := StrToInt(S1); // Extract the column #.

if (Row <> ReadRow) or (Column <> ReadColumn) then
begin
L2 := 6;
Exit;
end;
*)
// ****************************************************************************
// Set location to the place in the CoastalBitMaps list of bitmap pointers.
// ****************************************************************************
Location := AddToPtr(RiverLakeBits, Pred(Place) * SizeOf(TRiverBits));

for PRow := 1 to 152 do // Read each row of the bits from the file.
begin
RowLocation := AddToPtr(RiverLakeSkipRow,
((Pred(Place) * 152) + Pred(PRow)) * SizeOf(Boolean));

S1 := StripNextPixelRow; // Take 1 pixel row worth of data from S.

PCol := 1;
while PCol < 18 do // 17 * 8 = 136 pixels.
begin
S2 := TrimString(S1); // Get next entry and trim remaining string.
Found := False; // Assume no letter code is found.

if Length(S2) = 1 then // All letter codes are single characters.
begin
for I := 17 downto 1 do // For each letter code.
begin
if S2 = LetterCode then
begin // Check for skipping the entire row.
if S2 = 'Q' then Boolean(RowLocation^) := True
else Boolean(RowLocation^) := False;

ZeroCount := I; // How many groups of 8 to skip.
Found := True;
Break;
end;
end;
end;

if Found then // Letter code found. Use ZeroCount to write out zeros.
begin
for I := PCol to PCol + Pred(ZeroCount) do RiverB[I, PRow] := 0;

Inc(PCol, ZeroCount);
end
else
begin // Number found, transfer data on line to RiverB.
Boolean(RowLocation^) := False;
RiverB[PCol, PRow] := StrToInt(S2);
Inc(PCol);
end;
end; // End of for each 8 bits in the row (PCol).
end; // End of all 152 rows.
// ****************************************************************************
// Transfer the single set of river bits into the aggregate data storage.
// ****************************************************************************
for PRow := 1 to 152 do
for PCol := 1 to 17 do
TRiverBits(Location^)[PCol, PRow] := RiverB[PCol, PRow];
end;
Steve

Perfection is an elusive goal.
User avatar
AxelNL
Posts: 2389
Joined: Sat Sep 24, 2011 12:43 pm
Location: The Netherlands

RE: Still unplayable

Post by AxelNL »

ORIGINAL: Dabrion

wanna see the wares first!

p.s.: While we are waiting.. please educate me about the "Afsluitdijk". This looks like something that happens when my head hits the keyboard after a long night..

What you experience after a long night gives me the explanation I was looking for. Boxers also experience a particular type of behaviour chance later in their career due to repeated shocks to their heads.

Afsluitdijk is actually the first ' bug' I reported as a beta tester, as it was misspelled 'afslutdijk' in the tutorials. That is more a description of a type of person than a work which turned the South Sea into a sweet water lake. You might have liked the misspelling more, so this could be reason for you to react negatively again?
bo
Posts: 4175
Joined: Thu Apr 30, 2009 9:52 pm

RE: Still unplayable

Post by bo »

Gee whiz I just looked at the same map on my game screen, but I don't seem to have that train bridge going from Southampton to Plymouth over water, I wish I did as it makes the train trip shorter [;)] I did not know that they had that kind of engineering technology in 1940 [:D] Oh well!

Bo
bo
Posts: 4175
Joined: Thu Apr 30, 2009 9:52 pm

RE: Still unplayable

Post by bo »

ORIGINAL: AxelNL

ORIGINAL: Dabrion

wanna see the wares first!

p.s.: While we are waiting.. please educate me about the "Afsluitdijk". This looks like something that happens when my head hits the keyboard after a long night..

What you experience after a long night gives me the explanation I was looking for. Boxers also experience a particular type of behaviour chance later in their career due to repeated shocks to their heads.

Afsluitdijk is actually the first ' bug' I reported as a beta tester, as it was misspelled 'afslutdijk' in the tutorials. That is more a description of a type of person than a work which turned the South Sea into a sweet water lake. You might have liked the misspelling more, so this could be reason for you to react negatively again?

Not just boxers AxelNL but a lot of our football players too.

Bo
User avatar
Dabrion
Posts: 740
Joined: Tue Nov 05, 2013 10:26 am
Location: Northpole

RE: Still unplayable

Post by Dabrion »

Hi Steve, thanks a lot!

The screenshot is preliminary at best. Icons for resources and factories are missing on purpose, since I didnt get around to define svg stubs them. I like the style of the original maps and will replace with those resources and factories once I find the time to create them.
River hexsides should be ok (although I didnt check that extensively), they might seem incomplete because I have only rendered them as blue hexsides in a layer that is under the border hexside layer. Alpine hexsides dont use the MWiF bmps obvioulsy.
All of this is in a CSS file and can be easily adjusted later on, so I didnt care for it at this stage.

I will try to get at the RVR file by the weekend and see what I can do. Concept seems clear now, thanks again!

Rails are still puzzling me. I understand the clock position and the NAM file. And I think I am using all the information available there already. There are 322 entrys with label size=0 and label=None. You will agree that this number does not seem sufficient to handle all coastal hexes with rails going through them. So there has to be more to it. Do you have a heuristic for deterimining the clock poition for undescribed hexes? I currently use city, ports and resources if present in the hex.

Cheers,
Phil
"If we come to a minefield, our infantry attacks exactly as it were not there." ~ Georgy Zhukov
Shannon V. OKeets
Posts: 22165
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: Still unplayable

Post by Shannon V. OKeets »

ORIGINAL: Dabrion

Hi Steve, thanks a lot!

The screenshot is preliminary at best. Icons for resources and factories are missing on purpose, since I didnt get around to define svg stubs them. I like the style of the original maps and will replace with those resources and factories once I find the time to create them.
River hexsides should be ok (although I didnt check that extensively), they might seem incomplete because I have only rendered them as blue hexsides in a layer that is under the border hexside layer. Alpine hexsides dont use the MWiF bmps obvioulsy.
All of this is in a CSS file and can be easily adjusted later on, so I didnt care for it at this stage.

I will try to get at the RVR file by the weekend and see what I can do. Concept seems clear now, thanks again!

Rails are still puzzling me. I understand the clock position and the NAM file. And I think I am using all the information available there already. There are 322 entrys with label size=0 and label=None. You will agree that this number does not seem sufficient to handle all coastal hexes with rails going through them. So there has to be more to it. Do you have a heuristic for deterimining the clock poition for undescribed hexes? I currently use city, ports and resources if present in the hex.

Cheers,
Phil
Ah, yes. The program checks for all sea hexsides and sets the centering position for a hex opposite that. So if hexside #3 borders an all-sea hex, then the program uses a position toward hexside #0 (same numbering as for forts). There might be more along those lines.

Here's the code:
===
// ****************************************************************************
// No icon in the hex requires more work.
// ****************************************************************************
if not Found then
begin // 1st: Avoid all sea hexsides.
AllSeaCount := 0;

for HCounter := 0 to 5 do // For each hexside.
begin
Map.AdjacentHex(GivenCol, GivenRow, HCounter, AHex); // Get Hex adjacent.
// ****************************************************************************
// If defined as a coastal hex or if there is an all sea hex adjacent.
// ****************************************************************************
if (Map.HexsideTerrain[GivenCol, GivenRow, HCounter, hsCoast]) or
(Map.Terrain[AHex.X, AHex.Y] <= teLake) then
begin
AllSea[HCounter] := True; // Hexside is an all sea hexside.
Inc(AllSeaCount);
Found := True;
end
else AllSea[HCounter] := False;
end;

if Found then
begin
case AllSeaCount of
1:
begin
for HCounter := 0 to 5 do
begin // 0, 1, 2, 3, 4, 5 --> 3, 5, 7, 9, 11, 1
if AllSea[HCounter] then
TargetPosition := (((HCounter * 2) + 3) mod 12) + 12;
end;

AdjustWeightTarget(Side, TargetPosition, DynamicWeight);
end;

2:
begin
SmallS := -1;
LargeS := 0; // For the compiler's reassurance

for HCounter := 0 to 5 do
begin
if AllSea[HCounter] then
begin
if SmallS < 0 then SmallS := HCounter
else LargeS := HCounter;
end;
end;

if (LargeS - SmallS) = 3 then TargetPosition := 0
else
begin // The formula is strange, but true
if (LargeS - SmallS) < 3 then TargetPosition := LargeS + SmallS + 3
else TargetPosition := LargeS + SmallS - 3;
end;

AdjustWeightTarget(Side, TargetPosition, DynamicWeight);
AdjustWeightTarget(Side, TargetPosition, DynamicWeight);
end;

3:
begin
SmallS := -1;
MediumS := -1;
LargeS := 0; // For the compiler's reassurance

for HCounter := 0 to 5 do
begin
if AllSea[HCounter] then // Look for the all sea sides
begin
if SmallS < 0 then SmallS := HCounter
else if MediumS < 0 then MediumS := HCounter
else LargeS := HCounter;
end;
end;
// ****************************************************************************
// All even or all odd means that none of them are adjacent
// ****************************************************************************
if ((SmallS mod 2) = (MediumS mod 2)) and
((SmallS mod 2) = (LargeS mod 2)) then TargetPosition := 0
else
begin // Check if all 3 are adjacent
if ((SmallS + MediumS + LargeS) mod 3) = 0 then
begin // All adjacent
case (SmallS + LargeS) of
2: TargetPosition := 5;
4: TargetPosition := 7;
6: TargetPosition := 9;
8: TargetPosition := 11;
5: if MediumS = 4 then TargetPosition := 1
else TargetPosition := 3;
end;
end
else // Neither all adjacent nor all separate
begin // Use the one that is not opposite one of the others
if (LargeS - MediumS) = 3 then
TargetPosition := ((SmallS * 2) + 3) mod 12
else if (LargeS - SmallS) = 3 then
TargetPosition := ((MediumS * 2) + 3) mod 12
else TargetPosition := ((LargeS * 2) + 3) mod 12;
end;
end;

AdjustWeightTarget(Side, TargetPosition, DynamicWeight);
AdjustWeightTarget(Side, TargetPosition, DynamicWeight);
end;

4:
begin
SmallS := -1;
LargeS := 0; // For the compiler's reassurance

for HCounter := 0 to 5 do
begin
if not AllSea[HCounter] then // Look for the non-allsea sides
begin
if SmallS < 0 then SmallS := HCounter
else LargeS := HCounter;
end;
end;

SmallS := (SmallS + 3) mod 6; // Take the opposite sides
LargeS := (LargeS + 3) mod 6;

if LargeS < SmallS then
begin // Switch small and large
HCounter := SmallS;
SmallS := LargeS;
LargeS := HCounter;
end;

if (LargeS - SmallS) = 3 then TargetPosition := 0
else
begin // The formula is strange, but true
if (LargeS - SmallS) < 3 then TargetPosition := LargeS + SmallS + 3
else TargetPosition := LargeS + SmallS - 3;
end;

AdjustWeightTarget(Side, TargetPosition, DynamicWeight);
AdjustWeightTarget(Side, TargetPosition, DynamicWeight);
end;

5:
begin
for HCounter := 0 to 5 do
begin // 0, 1, 2, 3, 4, 5 --> 3, 5, 7, 9, 11, 1
if not AllSea[HCounter] then
TargetPosition := ((HCounter * 2) + 9) mod 12;
end;

AdjustWeightTarget(Side, TargetPosition, DynamicWeight);
AdjustWeightTarget(Side, TargetPosition, DynamicWeight);
end;

6: // This should never occur, but it does.
begin
TargetPosition := 0;
end;
end;
end // End of all sea hexsides in hex.
else
begin // 2nd: Count how many rail hexsides there are for the hex.
RailHexsideCount := 0;
SmallS := -1;
MediumS := -1;
LargeS := 0; // For the compiler's reassurance.

for HCounter := 0 to 5 do // For each hexside.
begin
if (Map.HexsideTerrain[GivenCol, GivenRow, HCounter, hsRail]) or
(Map.HexsideTerrain[GivenCol, GivenRow, HCounter, hsRoad]) or
(Map.HexsideTerrain[GivenCol, GivenRow, HCounter, hsBurmaRoad]) then
begin
RailHexside[HCounter] := True; // Hexside is a rail hexside.
Inc(RailHexsideCount);
if SmallS < 0 then SmallS := HCounter // 1st hexside found.
else if MediumS < 0 then MediumS := HCounter // 2nd hexside found.
else LargeS := HCounter; // Last hexside found.
end
else RailHexside[HCounter] := False;
end;

case RailHexsideCount of
0: TargetPosition := 0; // If all else fails, center of the hex

1: // 0, 1, 2, 3, 4, 5 --> 21, 23, 13, 15, 17, 19
TargetPosition := 12 + (((SmallS * 2) + 9) mod 12);

2:
begin
if (MediumS - SmallS) = 3 then TargetPosition := 0
else if (SmallS > 1) or ((SmallS = 1) and (MediumS = 3)) then
TargetPosition := MediumS + SmallS + 9
else if MediumS < 3 then TargetPosition := MediumS + SmallS + 21
else TargetPosition := MediumS + SmallS + 15;
end;

3:
begin
// ****************************************************************************
// All even or all odd means that none of them are adjacent
// ****************************************************************************
if ((SmallS mod 2) = (MediumS mod 2)) and
((SmallS mod 2) = (LargeS mod 2)) then TargetPosition := 0
else
begin // Check if all 3 are adjacent
if ((SmallS + MediumS + LargeS) mod 3) = 0 then
begin // All are adjacent
case (SmallS + LargeS) of
2: TargetPosition := 23;
4: TargetPosition := 13;
6: TargetPosition := 15;
8: TargetPosition := 17;
5: if MediumS = 4 then TargetPosition := 19
else TargetPosition := 21;
end;
end
else TargetPosition := 0; // If all else fails, center of the hex
end;
end;

4:
begin
SmallS := -1;
LargeS := 0; // For the compiler's reassurance

for HCounter := 0 to 5 do
begin
if not RailHexside[HCounter] then // Look for non-rail hexsides
begin
if SmallS < 0 then SmallS := HCounter
else LargeS := HCounter;
end;
end;

if (SmallS + 2 = LargeS) or (SmallS + 4 = LargeS) then
begin // Special case of 3 out of 4 adjacent
if (LargeS - SmallS) < 3 then TargetPosition := LargeS + SmallS + 15
else TargetPosition := LargeS + SmallS + 9;
end
else TargetPosition := 0; // If all else fails, center of the hex
end;

5,6: TargetPosition := 0; // If all else fails, center of the hex
end;

AdjustWeightTarget(Side, TargetPosition, DynamicWeight);
end; // End of no all sea hexsides in hex
end; // End of no label


procedure AdjustWeightTarget(const ThruSide, ClockPosIn: Integer;
var AWeight: Integer);
var
ClockPos: Integer;
// ****************************************************************************
// This routine takes a clock position and weights where the rail line crosses
// the hexside.
// SideWeight ranges from 8 (double left) to 12 (double right).
// ****************************************************************************
begin
if ClockPosIn = 0 then ClockPos := ClockPosIn
else ClockPos := Succ((Pred(ClockPosIn) mod 12)); // Convert 13 - 24 to 1 - 12

case ThruSide of
0:
case ClockPos of
0, 3, 9: ; // Straight

10..12, 1, 2: Inc(AWeight); // Right

4..8: Dec(AWeight); // Left
end;

1:
case ClockPos of
0, 5, 11: ; // Straight

12, 1..4: Inc(AWeight); // Right

6..10: Dec(AWeight); // Left
end;

2:
case ClockPos of
0, 1, 7: ; // Straight

2..6: Inc(AWeight); // Right

8..12: Dec(AWeight); // Left
end;

3:
case ClockPos of
0, 3, 9: ; // Straight

4..8: Inc(AWeight); // Right

10..12, 1, 2: Dec(AWeight); // Left
end;

4:
case ClockPos of
0, 5, 11: ; // Straight

6..10: Inc(AWeight); // Right

12, 1..4: Dec(AWeight); // Left
end;

5:
case ClockPos of
0, 1, 7: ; // Straight

8..12: Inc(AWeight); // Right

2..6: Dec(AWeight); // Left
end;
end;
end;

Steve

Perfection is an elusive goal.
Shannon V. OKeets
Posts: 22165
Joined: Wed May 18, 2005 11:51 pm
Location: Honolulu, Hawaii
Contact:

RE: Still unplayable

Post by Shannon V. OKeets »

By the way, I consider the code for automating the drawing of the rail lines some of the most clever code I wrote. We still had to put in the Labels data (Patrice did most of that) to handle a few odd cases. I also have a page of notes on how I could improve (i.e., smooth out) the drawing of the rail lines some more. But I stopped where I did because there was so much more work to do.
Steve

Perfection is an elusive goal.
User avatar
Dabrion
Posts: 740
Joined: Tue Nov 05, 2013 10:26 am
Location: Northpole

RE: Still unplayable

Post by Dabrion »

Ok, I will need some time to digest the details. But I it seems this will help me solve the case.

I was already thinking about some approaches. Without putting much effort in, I could only think of identifying connected rail-paths inbetween hexes with label information available, choosing clock positions s.t. the distance of the rail line is minimized. That turned out to be computationally expensive, so I did not pursue it further.

Introducing a weight that biases away from allsea hexsides seems very reasonable!
"If we come to a minefield, our infantry attacks exactly as it were not there." ~ Georgy Zhukov
Post Reply

Return to “World in Flames”