Topic: Circular/non-squared Station Coverage

[moritz]

Dear Devs,

I would love to see circular station coverage and I have thought of an idea how it could possibly be done:

A way to implement this would be to check the x- and y-offset of a tile to the station and have it connected to the station only if x²+y² ≤ c², where c is the coverage radius.

Here are examples of the results for c=1, c=2 and c=3:

Code: [Select]

..... ....... .........
..x.. ...x... ....x.....
.xSx. ..xxx.. ..xxxxx..
..x.. .xxSxx. ..xxxxx..
..... ..xxx.. .xxxSxxx.
      ...x... ..xxxxx..
      ....... ..xxxxx..
              ....x....
              .........
The calculation of the circular station coverage could be done when loading the map and the result of that then be used in-game, so that the same thing doesn't have to be calculated over and over again. This would of course have to be a toggle.

Without really knowing any C++ or the structure of the Simutrans code, this might be a way to implement it:

Code: [Select]

read "circular_station_coverage" from simuconf.tab
if circular_station_coverage=0 -> do the normal thing
otherwise                      -> check if there is a tile with a stop within "c" units of the tile in any direction #limit the search for stops to surrounding square, because it can't possibly be further away
                                  assign variable dx = x_coordinate_of_current_tile - x_coordinate_of_stop_tile
                                  assign variable dy = y_coordinate_of_current_tile - y_coordinate_of_stop_tile
                                  if dx^2 + dy^2 > c^2 -> set tile_is_covered = 0
                                  otherwise            -> set tile_is_covered = 1
What do you think? Is this possible and worth the effort? It is a fairly small change which would only have a strong effect for larger station coverages and new savegames. It looks nice though and adds realism.

[DrSuperGood]

Distance in Standard Simutrans is Manhattan Distance so circular radius is out of place. Also it would make covering a city very difficult because circles do not fit together very well.

[moritz]

Well, not every Simutrans City looks like Manhattan and circles fit together well enough - just not in the standard rectangular grid you might be using for your bus stops. In addition to that, I am not quite sure what you mean with "Manhattan distance". Pricing in Simutrans is also based on "geometrical distance" I believe. Remember that it is only meant to be an option for those players who like it.

[Ters]

In addition to that, I am not quite sure what you mean with "Manhattan distance".

Manhattan distance is used in Simutrans. There are several possible reasons. Finding square roots are expensive. Tile based movements means that "normal" distance isn't correct either (although Simutrans doesn't do full tile based movement).

[moritz]

Yeah, I thought about the complicated squareroots, but isn't that "solved" by comparing the squares instead of the square roots? I'm sure multiplying a number with itself is easier than finding a root.

[Ters]

Yeah, I thought about the complicated squareroots, but isn't that "solved" by comparing the squares instead of the square roots? I'm sure multiplying a number with itself is easier than finding a root.

For what you propose, yes, but not for pricing and possibly other things. DrSuperGood's argument seems to be that circles are a foreign element in Simutrans, where everything else is square.

For the default catchment area size, a circle does not look very circular, either. The short diagonals can make them very difficult to use. Especially industries with fields around can be difficult to reach. In a way, squares make most sense for small areas, less than 4 probably, while circles make more sense for bigger catchment areas.

[moritz]

Does that mean that with "Manhattan distance" a diagonally adjacent square is at least two units away? Should the "Manhattan coverage" not look something like this:

Code: [Select]

..... ....... .........
..x.. ...x... ....x....
.xSx. ..xxx.. ...xxx...
..x.. .xxSxx. ..xxxxx..
..... ..xxx.. .xxxSxxx.
      ...x... ..xxxxx..
      ....... ...xxx...
              ....x....
              .........

[Dwachs]

You are right, station coverage is computed with maximum metric. However, distances are measured with Manhattan distance.

[Isaac.Eiland-Hall]

I am not surprised with the lack of support on this proposal. I agree. I think square is good - one reason being that the tiles are square, and since most paksets use a coverage of 2, it's just too small to make circular. It's already a pain to cover every time in a city.

That being said, I think the best way to sell the idea would be to propose that the average should grow from 2-square to 3-circular. That would help make up for the hardship imposed by the shape change. For instance, a pak using 3 would grow to 4.

But *that* being said... I'm personally happy with squares.

[Leartin]

I don't think you'd play any different with these kinds of station coverages, you'd just be more annoyed about gaps and overlaps.

They might make more sense if there were really big circles somehow, but why would you have those? Maybe if there was a second station coverage for long-distance-travel, allowing anyone inside the area to go there by local traffic and using that station as a starting point for destinations further away. Basically, this would simulate that someone travelling from Linz to Lafayette would not bother to check local busses, but rather plan the journey from Linz central station or Linz airport - as a city inhabitant, you just assume there is a way to get to the airport or central station.

More in detail, for anyone who bothers:
Say there are three levels of travel, let us call them local, international, and intercontinental, even though those words only work on world scale.
There could be "international" station expansions, and "intercontinental" station expansions which, upon building, give this station an "international" and "intercontinental" coverage according to the stations size. Size could be either the capacity or a new value given by special station extensions.
International stations are only connected if you can go from one to the other without changing vehicle anywhere but in an international station. Once you get two international stations on the map, international travel starts by picking two international stations (probability calculated by the amount of potential pax in it's international coverage radius), and if a route is found, you look for a normal station within the international coverage radius, again based on the number of pax connected to that station, and find a route from there to the international station.
Intercontinental works the same, but one tier higher, searching for international stations first.

The problem of calculating long routes on big maps is that there are so very many possibilities. This is also one of the reasons why there is a limited amount of vehicle changes before the algorithm aborts (unwanted cross-connections is another one)
By using two seperated grids like this, you get far less possibilities. It might be that the number of line changes could be reduced to a small number like 3, and still have connections from anywhere to anywhere on the map. This should in turn result in better performance.
Obviously, backwards compatability is given simply by not putting any international stations in the pakset.

[Dwachs]

You definitely have to check local buses when travelling from Linz airport, in particular when you are arriving in the evening

[Leartin]

I only have to check when they go, not if they go. Simutrans never checks when to go, so for Simuthanians, it's enough to know that from any bus station in linz, somehow, at some time, you can arrive at the airport
And even if there was no bus (which would be the players responsibility for not creating one), when I go to Lafayette, a taxi to the airport wouldn't cost much in relation to the plane ticket, so I'd rather use a taxi (start at the airport) than not going, especially since I was silly and bought the ticket already without checking

[Václav]

I have nothing against moritz's request, but I don't think that it is for small coverage areas. Because then there would be too much stations - and it is not good for overloading of city roads.

[DrSuperGood]

I personally would not mind an overall increase in station pickup range from 2 to something like 4. In experimental they use massive pickup radius which makes covering cities for high percentage pickup much easier.

In pak64 I have come to the conclusion that it is impossible to use busses once a city reaches a certain size as you end up with a block of solid name tags for all the stops. raising it to 4 or so would greatly reduce the number of stops and so also reduce the clutter.

It is not like pickup range is even limited in size. Nothing would stop me covering an entire city with a single bus stop in standard which is also a considerable problem in my opinion.

Maybe the best solution would be to add different pickup radius for different stop structures? A bus stop could have a pickup of 3-4 where as a train station could have a pickup of 8-10 (as people will walk further to a train than for a bus). Airports could have a pickup of 20 as people will walk even further for them.

[Isaac.Eiland-Hall]

The standard radius used to be 3 years ago, then was changed to 2 in most paks. You can set it somewhere in the config if you poke around a bit - I'm afraid I don't recall offhand. Will only work for new games, though.

[An_dz]

The standard radius used to be 3 years ago

Humm, strange, never heard of a radius of "3 years ago". Is that in light years?

[Ters]

Humm, strange, never heard of a radius of "3 years ago". Is that in light years?

It probably refers to the catchment area's size in the fourth dimension. Although it appears to be more like a half-circle, since it extends only into the past and not into the future.

[An_dz]

It probably refers to the catchment area's size in the fourth dimension. Although it appears to be more like a half-circle, since it extends only into the past and not into the future.

Hahaha, perfect Ters. A helpful point for this comment.

[IgorEliezer]

Humm, strange, never heard of a radius of "3 years ago". Is that in light years?

{The standard radius used to be 3 [tiles]}{years ago}, and... wait a minute. Is your comment serious? :x

[Leartin]

Wait, so Simutrans station coverage extends in the fourth dimension, but not in the third? Why is it that a tunnel straight trough a mountain with a station in the middle lets simuthanians happily appear on the mountain top platform? xD

[Ters]

Wait, so Simutrans station coverage extends in the fourth dimension, but not in the third? Why is it that a tunnel straight trough a mountain with a station in the middle lets simuthanians happily appear on the mountain top platform? xD

Man engines.

[Isaac.Eiland-Hall]

In case anyone was seriously confused by my phrasing: "Years ago, the radius used to be 3 [tiles] [instead of the now 2 tiles]".

But this thread is hilarious.

[An_dz]

Haha no, I was not serious. But the first time I read it I did like I said and got confused, I thought it was funny and posted.