Matrix Games Forums

Forums  Register  Login  Photo Gallery  Member List  Search  Calendars  FAQ 

My Profile  Inbox  Address Book  My Subscription  My Forums  Log Out

Still unplayable

 
View related threads: (in this forum | in all forums)

Logged in as: Guest
Users viewing this topic: none
  Printable Version
All Forums >> [New Releases from Matrix Games] >> World in Flames >> Still unplayable Page: [1]
Login
Message << Older Topic   Newer Topic >>
Still unplayable - 10/6/2014 10:31:42 AM   
Dabrion


Posts: 733
Joined: 11/5/2013
From: Northpole
Status: offline
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..

_____________________________

“WiF is like sex: sure, it may give some practical results, but that's not why we do it.”
- Richard P. Feynman, 'WiF, Sex, and the Dual Slit Experiment'.
Post #: 1
RE: Still unplayable - 10/6/2014 12:01:55 PM   
michaelbaldur


Posts: 4774
Joined: 4/6/2007
From: denmark
Status: offline
quote:

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

(in reply to Dabrion)
Post #: 2
RE: Still unplayable - 10/6/2014 7:29:36 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
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.

(in reply to Dabrion)
Post #: 3
RE: Still unplayable - 10/28/2014 3:18:32 PM   
Dabrion


Posts: 733
Joined: 11/5/2013
From: Northpole
Status: offline
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.




Attachment (1)

< Message edited by Dabrion -- 10/28/2014 4:20:17 PM >


_____________________________

“WiF is like sex: sure, it may give some practical results, but that's not why we do it.”
- Richard P. Feynman, 'WiF, Sex, and the Dual Slit Experiment'.

(in reply to Shannon V. OKeets)
Post #: 4
RE: Still unplayable - 11/3/2014 6:11:31 AM   
Dabrion


Posts: 733
Joined: 11/5/2013
From: Northpole
Status: offline
bump

_____________________________

“WiF is like sex: sure, it may give some practical results, but that's not why we do it.”
- Richard P. Feynman, 'WiF, Sex, and the Dual Slit Experiment'.

(in reply to Dabrion)
Post #: 5
RE: Still unplayable - 11/3/2014 4:57:18 PM   
AxelNL


Posts: 2386
Joined: 9/24/2011
From: The Netherlands
Status: offline

quote:

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....

(in reply to Dabrion)
Post #: 6
RE: Still unplayable - 11/3/2014 9:05:32 PM   
Dabrion


Posts: 733
Joined: 11/5/2013
From: Northpole
Status: offline
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..

< Message edited by Dabrion -- 11/4/2014 1:34:31 AM >


_____________________________

“WiF is like sex: sure, it may give some practical results, but that's not why we do it.”
- Richard P. Feynman, 'WiF, Sex, and the Dual Slit Experiment'.

(in reply to AxelNL)
Post #: 7
RE: Still unplayable - 11/4/2014 12:44:41 AM   
Ubercat

 

Posts: 100
Joined: 12/19/2007
From: Near Allentown, PA
Status: offline
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

(in reply to Dabrion)
Post #: 8
RE: Still unplayable - 11/4/2014 3:56:05 AM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

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.




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[I] 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.

(in reply to Dabrion)
Post #: 9
RE: Still unplayable - 11/4/2014 5:55:54 AM   
AxelNL


Posts: 2386
Joined: 9/24/2011
From: The Netherlands
Status: offline

quote:

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?

(in reply to Dabrion)
Post #: 10
RE: Still unplayable - 11/4/2014 4:27:58 PM   
bo

 

Posts: 4176
Joined: 5/1/2009
Status: offline
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 Oh well!

Bo

(in reply to Dabrion)
Post #: 11
RE: Still unplayable - 11/4/2014 4:29:10 PM   
bo

 

Posts: 4176
Joined: 5/1/2009
Status: offline

quote:

ORIGINAL: AxelNL


quote:

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

(in reply to AxelNL)
Post #: 12
RE: Still unplayable - 11/4/2014 10:51:54 PM   
Dabrion


Posts: 733
Joined: 11/5/2013
From: Northpole
Status: offline
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

_____________________________

“WiF is like sex: sure, it may give some practical results, but that's not why we do it.”
- Richard P. Feynman, 'WiF, Sex, and the Dual Slit Experiment'.

(in reply to Shannon V. OKeets)
Post #: 13
RE: Still unplayable - 11/5/2014 5:52:40 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

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.

(in reply to Dabrion)
Post #: 14
RE: Still unplayable - 11/5/2014 5:58:45 PM   
Shannon V. OKeets

 

Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
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.

< Message edited by Shannon V. OKeets -- 11/5/2014 7:00:18 PM >


_____________________________

Steve

Perfection is an elusive goal.

(in reply to Shannon V. OKeets)
Post #: 15
RE: Still unplayable - 11/5/2014 11:31:01 PM   
Dabrion


Posts: 733
Joined: 11/5/2013
From: Northpole
Status: offline
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!

_____________________________

“WiF is like sex: sure, it may give some practical results, but that's not why we do it.”
- Richard P. Feynman, 'WiF, Sex, and the Dual Slit Experiment'.

(in reply to Shannon V. OKeets)
Post #: 16
Page:   [1]
All Forums >> [New Releases from Matrix Games] >> World in Flames >> Still unplayable Page: [1]
Jump to:





New Messages No New Messages
Hot Topic w/ New Messages Hot Topic w/o New Messages
Locked w/ New Messages Locked w/o New Messages
 Post New Thread
 Reply to Message
 Post New Poll
 Submit Vote
 Delete My Own Post
 Delete My Own Thread
 Rate Posts


Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

1.453