Transport Tycoon Forums

Starbud wrote:Do you use one or many simultaneous in and outlets to the station?
The reason i ask is that i have noticed others try to send too many trains trough one piece of track where paralelism would do wonders to an otherwise very good design.

for me, the highest amount you can do for short distance to medium distance lines between stations is 2 trains per station/rail, ofther wise you get hold ups (and in rare cases lock up for poorly done signaling) for long distances you can have a lot of trains per track (4 or more) and having a 6 line station will handle a crap load of traffic if everything is done right. Its also good to put a pass by line by stations so trains dont need to get to other stations by going through the station (which can lead to congestion)

I use a combination of Terminal and In line (shown below)

...........D........................D
<<<<<x=[][][][][][][][]=x<<<<<
>>>>>x=[][][][][][][][]=x>>>>>
...........x===========x
...........D........................D

D = Depot
< or > = direction of rail (signal wise)
"=" = bi directional rail
x = junction/switch
[][][][][][][] = station

You can actually fill a 64 wide station (or wider if it was possible to build bigger stations).
The trick is to make grids that can let each train at each inlet take any avaliable path.

I have made a savegame and some screenshots of some new designs i made for the new signaling, making my designs alittle bit more compact.
I have been using 0.7.0-RC1

http://ottd.dyndns.org/1/nano/OpenTTD/S ... ified8.sav
http://ottd.dyndns.org/1/nano/OpenTTD/P ... 202327.png
http://ottd.dyndns.org/1/nano/OpenTTD/P ... 202327.png
http://ottd.dyndns.org/1/nano/OpenTTD/P ... 202327.png

I have updated the patch to revision 16069

Download it in the first post.

Note: there are no windows binaries this time, as I have not (yet) set up a crosscompiler. Windows binaries may be posted later once (if) I figure out how to make Windows binaries without having Windows ....

Hi there all,

I'm new here.. I wanted to try CarstsWorldScenario_v3.scn, so I'm trying to get extra-large-maps patch, version 8 (for r16069) to work. I'm using linux (ubuntu). I've followed wiki.openttd.org/Compiling_on_Linux, and everything themes just fine, until I select the map in game. Then the game just shots down. Any ideas what I did wrong? (or maybe left out)..

it will be more helpful if you can start the game from the console and provide the error message

Here is the error:

Error: Invalid map size

If you have used the patch from this thread, it should have limit of 8192 x 8192 tiles (or any other size that gives as much tiles, size in one dimension being between 64 and 1048576)

What size does that scenario have? Is it available somewhere? I think I could try it on my system and see if the I'll encounter the bug too.

Yes, I used your patch.. This is the scenario: CarstsWorldScenario: http://www.tt-forums.net/viewtopic.php?f=60&t=37089

can you post the latest binary with 0.7.0

I am using your patch with Carsts World Scenario as well + cargodist..I get same errors with crashes "Invalid Map Size"

Hmmm ... which version of OpenTTD were you using with the patch?

I tried large map patch with r16538 (BTW I had to update the patch for that version, get the updated patch in the first post) and I experienced no "invalid map size" problem when loading CarstsWorldScenario_v3.scn or CarstsWorldScenario_v3_1950.scn.

Updated the patch to r16598 and cleaned up the coding style. Get the patch and/or windows binaries in the first post.

Bilbo nice work.

I have the feeling that the developers are reluctant to increase the quantity of tiles in de game because of performance reasons.
If you would do some testing with openttdcoop games you can see that in certain situations the upper limit is being reached.
Now here is a request that may be a middle solution.
Would you be able to make a small patch that would give players the option of making a rectangular map using a max of tiles (4194304).
Examples

X Y

2097152 x 2
1048576 x 4
524288 x 8
262144 x 16
131072 x 32
65536 x 64
32768 x 128
16384 x 256
8192 x 512
4096 x 1024
2048 x 2048
1024 x 4096
512 x 8192
256 x 16384
128 x 32768
64 x 65536
32 x 131072
16 x 262144
8 x 524288
4 x 1048576
2 x 2097152

I myself would be very happy with 512 x 8192 (playing with very long trains and Gotthard tunnel etc.)

But for sure it would make navigating them easier.

Isnt that what the thread is all about?

The smaller proportion can't be < 64 because of several limitations (towns, newgrf).

65536 x 64
32768 x 128
16384 x 256
8192 x 512
4096 x 1024
2048 x 2048
1024 x 4096
512 x 8192
256 x 16384
128 x 32768
64 x 65536

The patch already works that way, except that it uses a greater tile limit. Bilbo stated somewhere in this thread how to lower that limit.

The version posted here have max. 64M squares, so you can have for example:
64 * 1048576
8192 * 8192
1048576 * 64
... and basically anything in between, as long as you have at most 64M squares, min. 64 in one direction and sizes are powers of two.

The version posted to flyspray (that could end up in trunk perhaps some time in future :) have lower limit (same max. number of squares and limit of one side being max. 8192), so you will end up with maximums of:
8192 * 512
4096 * 1024
2048 * 2048
1024 * 4096
512 * 8192

But changing for higher limits is simple, you need to change just two constants :)

I briefly tested version with even higher limits (16384 * 16384 map), but there are some issues: you need 64bit system, 64bit compiler (no chance to fit this into 2 GB limit for 32bit processes), lot of ram and its quite slow even on fast CPU's (core 2 duo), due to tile loop running on map of that size - if tile loop would end up being somewhat optimized (which is far from easy). Though it works at this size, 8192 * 8192 is probably the largest size still usable with current CPU's and codebase.

Ok but still I send you a patch showing you wat I would like.
It has a minor glitch with grafics.
No known bugs

Regards HackaLittleBit

Well, I looked at the patch and when someone wants to pick different size, he often have to pick smaller size in one dimension before being able to pick the large one in the other dimension

I think it is better to do it another way: Basically, just mark the "too large" values in red (instead of hiding them, like you do in your patch), so if someone pickjs the red value, he know he have to pick something smalle in the second dimension.

I have updated my patch this way. Get it in the first post (patch and/or windows binaries).

I have also improved train collision checking algorithm to be faster (now needs only two additions, one OR and one AND in most cases, instead of two 64bit multiplications and one 64bit addition) - probably even faster than the original one.