Map size discussion

[WPandP]

The game has its units of measurement, which it calls "miles", that work out to about 1.38 "miles" per map gridpoint. However, when you create a heightmap for use in generating terrain, it can be set to any scale, as this is just a matter of resizing an image. The game doesn't know diddly about the "scale" of your source image. So, it's possible to model an area as small as one mile squared, fill up a 1024x1024 map with it, and the game will still measure about 1400 "miles" of track across it. In such a case, the game's stated "miles" are coming closer to being real-world yards or meters. That's an extreme example, but it demonstrates the point - that the game's reported "miles" are arbitrary units of measure.

If one was a purist, it would likely be possible to work out the exact scale relationships, and then edit the language file perhaps to replace the word "miles" with "meters", and then distribute that language file as bundled with the scenario that is set to that scale. But of course this scale relationship would only be true for that scenario, meaning you'd have to swap out the language file after playing it.

Obviously, if you stick close to the 1.38 miles per pixel standard then you get miles that really are miles. But don't let that prevent you from zooming in on what you want to focus on! I have a distaste for scenarios that include a lot of map that never gets used, because the author didn't crop as well as they could have.

[nedfumpkin]

I checked the language file and miles is the default measurement and to change that would require quite a bit of work. To change it to kilometres could be done but Only Canadians and other Euopeans would be at home with it. The difficulty comes from some of the calculations that are made based on miles, and whether this would have any affect on those calculations. It may be more than just a text label.

But having said all of the above, if we take some real distances into account, then the difference between montreal and toronto is 300 miles, or 500 km (all distances rounded to the nearest fifty) Toronto to NYC 300m/500km.New York to Washington is 200m /300km

So with those distances, scale maps at 1.38 miles per pixel would be small maps really. The thing to also take into consideration is that the width of track, expecially double track which would be theoretically a few miles wide.

But at least knowing that the game considers one pixel to be 1.38 or 1.39 of some unit of measure can offer some ideas to think about for changing. For me it will make it a bit easier for map making knowing what x and y are for calculatin'.

[Gumboots]

Bumping this. Since I've been playing around with testing base maps for possible future scenarios, I've noticed a few things.

Although I don't use the PopTop Map Builder (MicroDEM and GIMP are much better) I did take a look at it yesterday. It does warn that the maximum size of any map is 591,361 pixels, or 769 x 769. Any map over that limit will be scaled down inside RRT3. This means there is absolutely no point in making 1025x1025 maps, because the game will never render them at that size.

Yes, the game will accept maps up to 1025 on any axis, but it wont render them at that size if the total pixel count is over 591,361. As the Map Builder states, the biggest the game will handle without scaling it down is 513 x 1025. Going to 577 x 1025 puts the total pixels barely over the limit (64 over, to be exact), which means the game will automatically scale such a map down.

I don't know what it will scale down to, because the Map Builder doesn't exactly say, but since maps are restricted to increments of 64n+1 there is no way it can be scaled down and keep the same proportions as the original (because the original proportions are 9:16, and those numbers have no common factors that will reduce the fraction to a simpler one, so a bit of arithmetic will show you that the map proportions will have to change when it is scaled down).

Obviously a 1025 x 1025 will be internally scaled to 769 x 769. So, if making a square map, that is the biggest size that should be made. I drew up a short table of maximum sizes.

Width -- Height --- W:H Ratio - % of limit

577 ------ 1025 ------ 9:16 ------ 100.01 - (just over, so map will be forced to scale down)
513 ------ 1025 ------ 1:2 ------- 88.92 - (under, so will render at actual size)
577 ------ 961 ------- 3:5 -------- 93.77
641 ------ 897 ------- 5:7 -------- 97.23
705 ------ 833 ------- 11:13 ----- 99.31
769 ------ 769 ------- 1:1 ------- 100.00 (right on the limit)

Something else I noticed: in various threads, people have reported problems with painting going blocky or spotty on parts. When I rebuilt a test map from 769 x961 (over the limit) down to 705 x 833 (within the limit) it instantly seemed to be easier to paint. Textures went on smoothly, with no sign of blockiness or spottiness, which wasn't the case with the original. The original, larger, one was ok for painting, just not as good. I could paint it, but getting a good result wasn't nearly so easy.

Also, maps outside the limit seem to lose chunks sometimes when trying to get an overview of the whole map. Bits towards one or more edges can get temporarily lost, and will only render when the camera angle and or distance is changed to something it likes. 1025 x 1025 maps seem particularly prone to this. 769 x 961 seems not to suffer from this problem, although as already mentioned that size is still outside the limit, and this does seem to have an effect on terrain painting.

Short version: since RRT3 wont render maps outside the limit at their intended size anyway, and since for quite a lot of them it will be forced to change their proportions before it can render them, there's no point making maps in sizes that RRT3 doesn't like.

-----------------------------------------------------

Ok, scale. Another thing I have noticed (this is for maps of south eastern Australia) is that the geography really starts to make sense at around 1 mile per pixel. Default game scale is supposedly just under 1.4 miles per pixel, but the original PopTop SE Australia map is closer to 1.5 or a bit more. At that scale, features get blurred to the point where actual town locations often don't make sense with regard to the surrounding topography.

Once the map scale gets to 1 mile per pixel, the countryside really starts to look like the real McCoy. You can get buildable grades, mountains that look pretty much in scale, and enough local detail that a local person can look the map over and think it makes sense. The whole thing feels right.

By the time you're out to 1.15 miles per pixel, it starts losing the plot a bit. Still not too bad, and depending on the location may be perfectly fine, but if the area in question requires details to look the part the result will be poorer at that scale.

This makes sense, because although the linear scaling is only 15% different, the amount of detail available will vary as the number of pixels per given area, or IOW as the square of the linear scale. So, 1.15 miles per pixel only has around 3/4 the detail of 1 mile per pixel. By the time you reach 1.4 miles per pixel, the amount of available detail is halved.

[Gumboots]

Hmm. On second thought, this stuff about forcing oversize maps to scale can't be right, because when I move the cursor around a map that is larger than the stated limit (ie 1024 x 1024) the X and Y coordinates shown for the cursor match the actual map size.

The only difference is that, for all maps, RRT3 seems to crop the last pixel from each edge. So, an actual 1025 x 1025 .gmp will have a cursor limit of 1023 in either direction, once loaded into the editor. This would indicate that when you load a 1025 x 1025 .gmp, what you see on screen is the area from 1 to 1024, with the areas from 0 to 1, and from 1024 to 1025, being cropped off and not visible.

If it matters for any map, this might give a way of getting better precision for mapping. Instead of laying out your actual mapped area from 0 to 1025 (for example) you would lay it out from 1 to 1024, with the 1px borders just being scrapped. I'll test this with some obvious colouring of the borders and see what happens.

I'll also do some more testing on the ease of terrain painting.

[Lama]

Could it be that the terrain map is skewed? Check what happens when you export it with gmp2bmp?

[Gumboots]

How do you mean "skewed"?

[Wolverine@MSU]

The only difference is that, for all maps, RRT3 seems to crop the last pixel from each edge. So, an actual 1025 x 1025 .gmp will have a cursor limit of 1023 in either direction, once loaded into the editor. This would indicate that when you load a 1025 x 1025 .gmp, what you see on screen is the area from 1 to 1024, with the areas from 0 to 1, and from 1024 to 1025, being cropped off and not visible.

There's a difference in the dimensions one uses for heightmaps versus the dimensions for the bitmap overlay: Heightmaps should follow the 64n + 1 rule but bitmap overlays need to be 1024 x 1024. The reason is that data from the heightmaps are used to set the elevations of the grid intersections; for a 1024 x 1024 map, there are 1025 verticies along each edge, but only 1024 actual cells. Think of a 2 cell x 2 cell map: there are three vertical gridlines, left - middle - right, and 3 horizontal gridlines, top - middle - and bottom. So the heightmap for this one would need to be 3 x 3 pixels whereas the actual number of cells is only 2 x 2.

[Gumboots]

That makes sense for the heightmap vs the image overlay, but I still don't get why the cursor only goes out to 1023 during a game. If using 1025 vertices and 1024 cells, I'd expect the cursor to go to 1024 if it was indicating each cell, or 1025 if indicating each vertex

Admittedly, it's not really an issue for most map making or gameplay. I was just curious about it.

[Wolverine@MSU]

The cells are numbered from 0 to 1023. If you want to renumber the lower left cell to (1, 1), then the upper right cell would be (1024, 1024).

[Gumboots]

Fair nuff. I'm just trying to get it all sorted in my head, so I have an easy system for placement of cities, etc. "One pixel", or cell, has quite a range on most maps. I like setting up a formula that will drop things right where I want them if I just plug in their latitude and longitude. Makes things easy if you do it that way.

[Wolverine@MSU]

Gumboots,

You might find the attached spreadsheet helpful. I use it all the time when I make a new map. Instructions are on the second tab (Notes).

[Gumboots]

I prefer to do it with my old HP programmable and Google Earth. I just pull lat and long straight from GE, throw the values into the formula I've set up, and the old HP spits put X and Y cooordinates for the map in question. I don't need to know miles per cell or anything else. Basically, [(city longitude - left edge of map longitude) / (map width in degrees)](map width in pixels) = X coordinate. Similar stuff to get Y.

What I'm interested in now is the exact correction between .tga heightmap and finished .gmp. I understand your point about vertices. Since the height information is taken from pixel colour, then transferred to .gmp vertex, you need the extra pixel to handle the extra vertex. Makes sense. However, it means that x=1 on your heightmap does not correlate to x=1 on your finished .gmp.

The correlation would actually be (x = 0.5) on the heightmap equates to (x=0) on the .gmp. (x=1024.5) on the heightmap equates to (x=1024) on the .gmp. Similarly for y axis. To get really accurate results from the positioning formula, this correction should be built in when making the initial heightmap. It should be fractionally larger (in degrees) than the finished .gmp (roughly one minute of longitude on the map I've been playing with).

Also, since the .gmp cells are (assuming a 1024 map) numbered 0 to 1023 instead of 1 to 1024, that's another correction that is needed. I had wondered what the cut off line was for rounding x and y coordinates. It's clear now that rather than the usual 0.499/0.501, it's actually more like 0.999/1.001. So, anything under 1 gets read as 0. 1 or slightly over, but less than 2, gets read as 1. Knowing that, it'll be pretty easy to deal with fractional coordinates when placing markers.

[sbaros]

As far as I have understood from these discussions, the field dimensions of RR Tycoon are fixed, i.e. each land cell corresponds to a fixed number of distance units, right?
If this is the case, our only option to modify the scale is to determine what these distance units are, which practically means to change the "mile" and "mile/hour" reference in the RT3 language file accordingly. Naturally, one has to keep separate Tycoon installations for different dimensioning systems, as I do.
For instance, I have dimensioned my South Balkan base map in a way that that the supposed "miles" are actually kilometers in the real world. So, I renamed all distance and speed references in RT3.lng to kilometers and uploaded the modified file here for use with mine and any other map intended to be dimensioned in km..
An advantage of this is that you have a surface 1.6²=2.56 times more detailed than the default mile-measuring option, not at all insignificant. Practically you can represent more accurately a varied industrial production within a specific region, particularly in dense industrial zones. Of course it takes more stations to cover it, since their catchment areas are actually based on land cells, but this doesn't affect realism negatively.
On the downside, you have a far lower size limit for the territory you want to include.
I have tried this very painstakingly researched and prepared Southern British Columbia scenario, where distances are enormously multiplied due to the desired detail level. It is so unfortunate that the real distances cannot be displayed.
Any observations on the above? Is there a way to force Tycoon III to display distances/speeds modified by a desired multiplier?

[Gumboots]

Not as far as I know. RT3 has the track "miles" hard-coded into the .exe. You can rename them to kilometres if you want to, but it has no effect on how the game plays.

It doesn't matter for map detail either. Map detail is only dependent on which scale you use, in terms of real life area for a given number of .gmp pixels. The game's distance measurements, which bear no relation to real miles or kilometres, have no effect on map detail.

[sbaros]

Yes, actually I compensate this by typing the "Go Go Go" thing when running kilometer-based maps.
Alternatively, one may modify accordingly each locomotive's speed/tractive effort tables for each intended "scale" (too much editing !) .

[Gumboots]

You could do that, but personally I find running realistic train speeds in absolute terms (ie: mph to match real life train speed) works well for me. As an example, the Latvia and NSW maps I made have (from memory) a scale of roughly 2 map pixels per real life mile. That's quite a large scale for RT3, but the economy works well even with 19th century trains that commonly operate in the 20-30 mph range.

TBH I hate fast trains on small maps, because you can never get a decent train ride.

[sbaros]

The game has its units of measurement, which it calls "miles", that work out to about 1.38 "miles" per map gridpoint. However, when you create a heightmap for use in generating terrain, it can be set to any scale, as this is just a matter of resizing an image. The game doesn't know diddly about the "scale" of your source image. So, it's possible to model an area as small as one mile squared, fill up a 1024x1024 map with it, and the game will still measure about 1400 "miles" of track across it. In such a case, the game's stated "miles" are coming closer to being real-world yards or meters.

In this case, you just have to rename "miles" and "m.p.h." inside the RT3 language file into "yards", "meters", "quarter miles", whatever corresponds to your chosen scaling,
One can also reverse this, i.e. represent large portions of the planet and rename the "miles" into "dozen miles", "tens of kilometers" et.c.
In both cases, modify locomotive speeds accordingly!
I am preparing a more extensive intervention on this matter to publish as soon as it is ready.

[Gumboots]

Why? As far as the game's economy goes, cargo moves at the same speed regardless of map size or real life map area. If you have a cargo source 200 map pixels from a demand, it will take the same time to get there if it's part of a 256x256 map of the whole world, or if it's part of a 1024x1024 map of Paris. It makes no difference.

You're getting mixed up by thinking that real world distances mean anything inside RT3. They don't. Not really. The game's "miles" are just an arbitrary unit, so the ledger can have things load "miles" and track "miles" listed. Neither of which are really any use during play anyway.

This earlier statement of yours is misguided:

An advantage of this is that you have a surface 1.6²=2.56 times more detailed than the default mile-measuring option, not at all insignificant. Practically you can represent more accurately a varied industrial production within a specific region, particularly in dense industrial zones.

It makes no difference if you call the game's internal units inches or parsecs. It's still the same map area in map pixels, representing the same real life area. It still has the same space for the same number of buildings, and the same economy flow. It makes no difference to how detailed the map is.

If you want a more detailed map, the only way to get it is to use a larger number of map pixels for a given real life geographic area.

---

The other thing that is unrealistic in RT3 is trip times. Take a fairly small map, like the default PopTop South East Australia map. I happen to know that a train from Sydney up to the Murwillumbah used to take about 18 hours back in the 1970's and early 80's. This was with a lot of stops on the way. In RT3 on the PopTop map, the same trip takes months of game time with far fewer stops. It's nowhere near realistic, but it doesn't matter. The game is balanced for it to work.

RT3 is a train game, not a train simulator. Past a certain point there is no gain in trying to make it too realistic. If you want absolute realism, you need a simulator.

[sbaros]

You are right after all.
Well, my original thought was that it does have the same number of buildings, but then you can think of each building representing more or less "real world" factories of its type. If you had your map scaled to dozens of miles, one steel mill for example would represent the whole steel industry of the Ruhrgebiet. And one would have to limit train speeds to 1/12th of the default ones. A "120 m.p.h." train would become a "10 dozen m.p.h." one.
However, I missed the crucial point of yours : cargo automatically moving by other modes is not affected by the scale a user wants to establish for a certain map (or at least we don't know how to regulate this). So, in the above "dozen miles" example, my trains would be totally uncompetitive in terms of delivery time.
However, I wouldn't be totally inflexible in terms of the scale. I'd say that there is a reasonably acceptable margin between ½ and 2 miles per intended RRT3 "mile".
It is a pity after all for so detailed work done, for example, with that splendid Southern British Columbia scenario. As I verified, its nominative distances are more than half-dozen times the real ones, which puts it way out of range...

[sbaros]

The other thing that is unrealistic in RT3 is trip times. Take a fairly small map, like the default PopTop South East Australia map. I happen to know that a train from Sydney up to the Murwillumbah used to take about 18 hours back in the 1970's and early 80's. This was with a lot of stops on the way. In RT3 on the PopTop map, the same trip takes months of game time with far fewer stops. It's nowhere near realistic, but it doesn't matter. The game is balanced for it to work.

It is not exactly unrealistic, it is a result of necessary "selective compression". Each RR Tycoon "train run" has to represent a sequence of similar round trips over the displayed period of time. Given the expected amount of time that an average user will want to spend on this, there is a necessity to simulate the passage of several years within a couple of real-time hours.
Selective compression is also heavily applied to physical railroad modelling for slightly different reasons, yet with comparable effects. The widespread "fast time clock" is a characteristic aspect of this.

RT3 is a train game, not a train simulator. Past a certain point there is no gain in trying to make it too realistic. If you want absolute realism, you need a simulator.

Actually, it is neither. Instead, it is a large-scale transport management simulation. A train driving simulator has a totally different purpose and cannot be a part of software aiming to emulate several decades of economic developments over a vast geographical area.