Europe map?

[Frederyck]

ORIGINAL: iamspamus

WARNING: Totally useless fact -

I think that the space N of Kiruna and E of Narvik is where the Ice Hotel is built every year. www.icehotel.com. At least, somewhere around there. Don't know if that qualifies for a name on the map though!

It is somewhere around there in Jukkasjärvi - but it is a fairly recent thing. I think the ice hotel was made for the first time at the end of the 1980s or beginning of the 1990s.

[Froonp]

ORIGINAL: Shannon V. OKeets

ORIGINAL: Froonp
I think that this is a GREAT idea.
Also what can be done is to simply put the link to the relevant page in Wikipedia.

But, a lot of the labels I add are not "linked" to the hexes in the same way that city / ports names are linked. I mean that, a city name will appear on the map, but also in the status bar when the mouse is over the HEX where the city is (which is not necessarily the hex where the label is).

So, will your 'cookies' system be able to "detect" that a given hex is linked to a label ? for example, for the "Vemork" label (the heavy water works in Norway), how will your 'cookies' system know that the hex where I right clicked has the "Vermork" label ?

These are technical details, but you asked.

The program can matche the label to each city/port icon on the map because the each hex has a unique map label # in the TER.CSV file (most of these numbers are vacuous - there are not 70,200 named locations!). That same # has to appear in the NAM.CSV file which holds the labels for displaying the label on the map. What I am proposnig is that a NAM.TXT file be created that uses the same ID# for each text entry. A similar scheme is used to match units from the unit CSV files (AIR, LND, NAV) with their bitmap images (JPG) and their text descriptions (AIR.TXT).

Earlier I had indicated using the first letter of the name (which would also work), but let's go with having the player click on the hex that the name is associated with, rather the whichever hex the name is positioned in - since we sometimes reposition names/labels for cosmetic reasons.

Yes, but Vermork for example, is not associated with any hex (in the TERR file). It is only appearing on the map thanks to the NAM file. So, in the case of those kind of cosmetic names, would your 'cookies' system work ?

[Shannon V. OKeets]

ORIGINAL: Froonp
Yes, but Vermork for example, is not associated with any hex (in the TERR file). It is only appearing on the map thanks to the NAM file. So, in the case of those kind of cosmetic names, would your 'cookies' system work ?

I haven't looked at that code in a while (over a year ago) but I was under the impression that the TER.CSV should contain the index into the NAM.CSV file to make the linkage. I am pretty sure it is essential for displaying the name of the hex as part of the map header screen (there's a little panel that displays the name of the hex under the cursor).

To answer your question directly, the index into the NAM file should be included in the TER file for the corresponding hex number (coordinates Column, Row) in order for the text description for the hex to appear. If someone is going to the effort to create a write up for a hex, then adding the NAM index for the hex in the TER file should be a minor additional task.

[Shannon V. OKeets]

Along the lines of text write ups for hexes, there could be short ones for even the major cities:

1 - Paris, captured by the Germans on ..., and liberated on ...
2 - London, first bombed by Germany on ..., attacked by V1s on ..., last bombed on ...
3 - Leningrad, cut off from the rest of Russia on ..., temporarily reconnected during the winter of, seige lifted on ...

and so on.

[Froonp]

ORIGINAL: Shannon V. OKeets

ORIGINAL: Froonp
Yes, but Vermork for example, is not associated with any hex (in the TERR file). It is only appearing on the map thanks to the NAM file. So, in the case of those kind of cosmetic names, would your 'cookies' system work ?

I haven't looked at that code in a while (over a year ago) but I was under the impression that the TER.CSV should contain the index into the NAM.CSV file to make the linkage. I am pretty sure it is essential for displaying the name of the hex as part of the map header screen (there's a little panel that displays the name of the hex under the cursor).

You're right, but see below.

To answer your question directly, the index into the NAM file should be included in the TER file for the corresponding hex number (coordinates Column, Row) in order for the text description for the hex to appear. If someone is going to the effort to create a write up for a hex, then adding the NAM index for the hex in the TER file should be a minor additional task.

Yes, but the problem is that nearly each time that I had added a label for a blank end of rail, I also have put a "none" entry linked to the hex (TER file) so that the railway ends at the place I want it to end (either to give it the right shape, or to make it end at the correct place in relation with a river or a lake or a coastline). As there is no city nor port usually in those hexes, I'm obliged to put "none" entries there. So it is that "none" entry that is referenced in the TER file, and I can't reference another.
Except if you change the TER fils structure so that multiple entries from the NAM files can be refered to herein.

For example, for Namsos, I have created an entry for the Namsos label itself (NAM file, #3455, hex 30,39) so that it appear on the map, and I have also created an entry for a "none" label (NAM file, #2968, hex 30,39) linked to hex 30,39 (TER file) so that the railway goes into position 9 of the hex (near the coast, where Namsos is supposed to be). So, I can't link Namsos entry (#3455) to the same hex.

[Froonp]

Except if you change the TER fils structure so that multiple entries from the NAM files can be refered to herein.

You could achieve that by adding an extra field before the last field of the TER file. This field would be : Number of labels (from NAM file) associated with this hex. Could range from 0 to 3.
Then, the next fields would be either at -1 or showing the ID of the label.
The 4 last fields for Namsos hex (30,39) in the TER file would be (...),2,2968,3455,-1

Kind of the way you've structured it into the COA file for the number of adjacent Sea Area.

I'm not even sure that the extra field would be needed.

This would also have the advantage of being able to make the railway pass through a "none" entry without going to the minor port or city in the hex, which would solve nicely the issues with Holyhead, but also with Brest, and Messina that are a pain for me to see.

[mlees]

Sorry if I missed it. I was thinking about the "Strait" crossing arrow and sea boundaries.

Is it possible to make the crossing arrow have a higher priority than the sea zone boundary, so that the arrow graphic rests on top of the sea zone boundary line?

[Froonp]

Humm, in fact I wonder if I did not have this wrong from the start.

I think I could also have linked the 30,39 hex (TER file) with the Namsos entry (NAM file), and simply indicated in the Namsos entry (NAM file) the position of the railway using the city position field, instead of using the city position field of a "none" entry (NAM file).

If I'm right here, it seems that I will have :
- a lot of "none" entries to be removed and replaced by their mate-label entry.
- a lot of labels (islands and other places) to link to the TER file.
- a lot of blanks in the NAM file (useless "none" entries) to fill in with the bottom entries of the NAM file.

Am I right Steve ?
Am I also right that it is desired that labels appearing on the map (not river or mountain names, only places names such as small cities, island, etc...) are linked to the TER file ?

Hopefuly, I have the list of all "none" entries, and I can filter down the NAM file to all size 8 black color texts (miscellaneous labels) to help me [:D].

I was afraid that doing so Namsos would appear in the list of cities & ports that you can have by hitting CTRL+F. It seems that it does not (I tried with another entry). How do the program knows the list of what should appear in that list ? Does it have to be defined as a city / port hex in the TER file ?

[Shannon V. OKeets]

ORIGINAL: Froonp
Humm, in fact I wonder if I did not have this wrong from the start.

I think I could also have linked the 30,39 hex (TER file) with the Namsos entry (NAM file), and simply indicated in the Namsos entry (NAM file) the position of the railway using the city position field, instead of using the city position field of a "none" entry (NAM file).

If I'm right here, it seems that I will have :
- a lot of "none" entries to be removed and replaced by their mate-label entry.
- a lot of labels (islands and other places) to link to the TER file.
- a lot of blanks in the NAM file (useless "none" entries) to fill in with the bottom entries of the NAM file.

Am I right Steve ?
Am I also right that it is desired that labels appearing on the map (not river or mountain names, only places names such as small cities, island, etc...) are linked to the TER file ?

Hopefuly, I have the list of all "none" entries, and I can filter down the NAM file to all size 8 black color texts (miscellaneous labels) to help me [:D].

I was afraid that doing so Namsos would appear in the list of cities & ports that you can have by hitting CTRL+F. It seems that it does not (I tried with another entry). How do the program knows the list of what should appear in that list ? Does it have to be defined as a city / port hex in the TER file ?

Let's handle this through email. I wouldn't want any of the forum readers mentally injured trying to understand these details.

[Shannon V. OKeets]

ORIGINAL: mlees
Sorry if I missed it. I was thinking about the "Strait" crossing arrow and sea boundaries.

Is it possible to make the crossing arrow have a higher priority than the sea zone boundary, so that the arrow graphic rests on top of the sea zone boundary line?

Yes, but I want both the straits icon and the sea area boundary clearly visible. Whichever one is on the bottom would be partially covered. Instead I'l lsimply relocate the stratis icon off to one side.

[ajds]

I notice the westernmost oil resource in the Caucasus is named Armavir - after a little checking, that seems reasonable, but I am simply curious why Maikop is not used for the title?  Maikop seems to have more historical connection to oil production, and I am more familiar with Maikop from other WWII resources.

[Froonp]

ORIGINAL: ajds

I notice the westernmost oil resource in the Caucasus is named Armavir - after a little checking, that seems reasonable, but I am simply curious why Maikop is not used for the title?  Maikop seems to have more historical connection to oil production, and I am more familiar with Maikop from other WWII resources.

Well, it was be cause of the placement of the OIL resource on the map, and because of this map of the oil exploitation in the Caucasus in 1940. Maikop is better known, so I'll research it better to see if it needs to be changed.

[Froonp]

A 1944 map o f the area.
Seems that Armavir is better placed to be the name on that resource. Opinions ?

[trees]

this thread is a great example of how hard these guys are working on all this for us

[composer99]

Yeah, I sometimes wonder what Patrice does for a living aside from haunting these forums. [&o]

[Froonp]

ORIGINAL: composer99

Yeah, I sometimes wonder what Patrice does for a living aside from haunting these forums. [&o]

I'm a system engineer in computers & network in southern France, currently in mission in a large territorial collectivity where I have some spare time and access to broad band Internet. Hence, I can access the forums and give answers quite often.

[Shannon V. OKeets]

Here are the revised straits icons. In the upper left you can see that the sea area boundary and straits icons now have zero overlap.

[Incy]

The strait should be on both sides of the sea border, but this is not very clear from the graphic. Newbies might be tempted to think the strait near Fredrikshavn is only on the Baltic side...
(not very important here, but quite important some other places, Gibraltar is just one...)

[Shannon V. OKeets]

ORIGINAL: Incy

The strait should be on both sides of the sea border, but this is not very clear from the graphic. Newbies might be tempted to think the strait near Fredrikshavn is only on the Baltic side...
(not very important here, but quite important some other places, Gibraltar is just one...)

I think this can be handled ni the tutorials and Rules as Coded (RAC) documentation. By simply stating that the straits arrow indicates two hexes are connected and that to prevent the use of the straits, all sea areas adjacent to the two hexes need to be 'controlled'. If the documentation is clearly written, it shouldn't be that hard for new players to understand.

[Froonp]

ORIGINAL: Shannon V. OKeets
Here are the revised straits icons. In the upper left you can see that the sea area boundary and straits icons now have zero overlap.

Well, there is no more overlap, but now that the graphic is offset on one side, it gives the false impression that the strait from Frederikshavn to the southwest hex only crosses the Baltic Sea Area, while it also cross the North Sea. This gives the false impression to the player observing the map that he can cut the supply between both hexes through the strait by cutting the supply throught the Baltic Sea alone, while he will have to also cut it in the North Sea.

Missleading, isn't it ?

I've tried a mock up with a wider centered double arrow for the strait hexside double arrow, but this is not very pretty.

What about putting the present double arrow one time on each side of the sea area boundary ?

What about also, having this double arrow a bit shorter ? Say, 30% shorter, with maybe a head 50% larger ?

Here is an attempt at showing an alternative idea.