Merge Station Tool (Revisted)

[Casteele]

After searching for some way to join/merge nearby stations in to one single station, I found and read the "Merge Station Tool" patch that was accepted in to the main development. I do, however, have some comments I wanted to submit (but starting a new topic as that topic was "old"--mods, please move/adjust this post as needed!)

First, the idea that such merging is "cheating", I have some thoughts on that. Given the way I understand the game mechanics, it's not possible to cheat this way! Goods/PAX transport themselves from the source/producer to the nearest station by themselves--the players do not earn any money from this. Likewise, goods/PAX transport themselves from the destination station to the desired destination/consumer on their own--again, without paying any player for that. They simply use the "catchment area" to determine how far they'll transport themselves.

Thus, you could try to "cheat" by "extending" a station across the map, but all that would happen is the goods/PAX will jump on to your nearby station tile, see that they're already "connected" to their destination, and hop off to it--without paying anyone for it. The player doing so, however, is still paying the regular maintenance costs for those station tiles. Effectively, they're providing transportation at their own expense, rather then earning them revenues; They're only cheating themselves. So let them!

(You can see this in action by placing two connected factories on either side of a station, and watch as goods transfer across the station without ever earning you any income at all... And actually costing you regular maintenance for the station tile.)

Secondly, one of the issues I saw discussed was how far to allow connections, and some discussion about how to limit it, how much it costs, et cetera. Why not use the catchment area as the limit? If station B is within the catchment area of station A (which also implies A is within the area of B), then allow them to become merged. There's little need to even calculate a "cost" in this case, because the catchment area is self-limiting in itself. And it's "realistic" in both "real life" and within the game design; People will get off at a bus station on one side of a road, walk across the road to the subway station (or their target tourist attraction, et cetera) on the other side, and continue on their way, even though the two are not directly connected to each other; Nor does either station pay any costs for that kind of "connection".

If, however, it may be desired to allow stations farther out to become merged, then the distance limits and costs could become a factor to consider; From a coding standpoint, the easiest and fastest method is to calculate the "taxi cab distance" between the geometric center points. Simply iterate through every station A tile, finding the smallest and largest X coordinate (and do the same for the Y), this finds the "bounding box" for station A. Then subtract the lowest X from the highest X (And the same for the Y), to find the geometric center of the region. Do the same for station B. This leaves a pair of X,Y coords, one for Stn A and one for Stn B... which you do the same again--subtract the lowest X from the higher X, and same with the Y. This leaves a distance between the two centers along each axis. Add them together and you have the "taxi cab distance". (Yes, this means two single tile stations that are only one empty tile apart at a 45 degree angle would actually have a "taxi cab distance" of 2, not 1; But since the straight line distance at 45 degrees is greater than 1 in such a case (Pythagoras' theorem), it remains "fair".) And it avoids having to do a lot of more complex/CPU intensive calculations with floating point numbers.

Finally, the basic idea of a merge tool can, I believe, easily be extended in to a more general purpose "Station Management Tool" without a lot of extra coding, which can  not only merge stations, but also split them if desired. It can also allow one to indicate which station tile they wish to have the label float above--or even off to the side if it's in the way visually! Changing a station to a public one, and possibly many other future enhancements...

[Mariculous]

About the cheating issue, you are absolutely correct nobody will be paid for passengers jumping around and the player still has to pay the maintainance so your global single station example is indeed stupid.

However, in some (most?) paksets, inter city transportation is much more profitable than a local bus network. Local bus lines in pak128 do even often tend to be unprofitable on its own, so you have to pay the bus stops and additionally you have to pay the buses.

In that case just connecting these stations and thus forcing people to teleport around the city will reduce local "bus" networks loss.
You may argue it's still a loss so how is that cheating?

Well the profit comes in when multiple of those cheated stops are connected by e.g. rail service or highly loaded bus service.
That way it is very easy to create bus or rail networks where lines have an average load of above 50% even values around 80% are not that hard.
Such lines will quickly generate much more profit than the costs of these bus stops and that given, will be more profitable and easyer to maintain than networks with local bus tranport.

[Vladki]

Another "cheat" is that you can connect a factory/curiosity in difficult terrain to a station that is far away, in easier terrain. So you avoid terraforming, destroying farm fields or city houses, etc.
On the other hand this cheat is already possible even without that tool - build a chain of station buildings (cheap stops), and then destroy those in the middle. A possible solution to "carpeting the city with single bus stop" would be to limit maximum coverge area of a station to some size/area. E.g. with coverage radius 3 tiles, we have one stop covering 7x7=49 tiles. A train station could have 4 platforms - 12 tiles long, plus some buildings and bus stops so 6x12 plus coverage 12x18= 216 tiles. So the limit would have to be IMHO at leas 500 tiles to allow for big stations. And that would not prevent you from the cheats above, as they would do with less coverage area.

[Ters]

Another "cheat" is that you can connect a factory/curiosity in difficult terrain to a station that is far away, in easier terrain. So you avoid terraforming, destroying farm fields or city houses, etc.
On the other hand this cheat is already possible even without that tool - build a chain of station buildings (cheap stops), and then destroy those in the middle.

If the terrain is difficult, building those stops might require just as much expensive landscaping, so I guess this only makes sense if one needs a bigger station. How much of a cheat it actually is varies. Building a feeder line where the temporary stations buildings where might make more money in the long run, since profit is generated from distance between stations, not industries.

There are so many ways to cheat in single player, and so many things requiring moderation in multiplayer, that this feature might not make much difference.

[Leartin]

First, the idea that such merging is "cheating", I have some thoughts on that. Given the way I understand the game mechanics, it's not possible to cheat this way!

Cheating might be the wrong word. Rather, it encourages a style of play that is not necessarily intended, not balanced for, and possibly less fun.
Freahk already explained the monetary side of it - indeed, merged stations can be used to generate money. But the larger issue comes later.
You see, for beginners and depending on the pakset and setting, it might be hard to gain money at first, but there usually comes a point where you are just swimming in money. At that point, the goal usually shifts from "How can I gain money?" to "How can I avoid overcrowding/unhappy pax?". Pax distribution in a city is not flat. If you build your bus stops/lines without taking into account that the cathedral attracts tourists, you are almost guaranteed to get some overcrowding. More busses? Eventually the roads are full. Add tramways. Build subways. Solving those problems is a large part of the gameplay.
If you just merge all bus stops and have the whole city as one giant station, you eradicate all pax who would travel within the city, and combine the capacity of all stops, which is usually enough such that your one-city-stop stays green. You solved the complex transportation puzzle that the game is about without using transportation. It's a bit like solving a rubiks cube by carefully replacing all stickers.

There are so many ways to cheat in single player, and so many things requiring moderation in multiplayer, that this feature might not make much difference.

Still, having limitations in place at least clearly communicates the intention of the tool. Of course you can cheat in single player, but it's still important to communicate to the player that they are cheating, or at least exploiting mechanics. If they think what they are doing is perfectly normal and intended, how could they accept 'arbitrary' multiplayer moderation?

[Ters]

"How can I avoid overcrowding/unhappy pax?". Pax distribution in a city is not flat. If you build your bus stops/lines without taking into account that the cathedral attracts tourists, you are almost guaranteed to get some overcrowding. More busses? Eventually the roads are full. Add tramways. Build subways. Solving those problems is a large part of the gameplay.

I have enough problems keeping overcrowding trains stations in check. The bus lines feeding the trains stations just become an annoyance on top of that. I could increase the station coverage area setting and get rid of the bus micromanagement, but that might lead to lots of unwanted cross-connections in my freight network. So something giving better control over what a station covers could be nice for me.

[DrSuperGood]

First, the idea that such merging is "cheating", I have some thoughts on that. Given the way I understand the game mechanics, it's not possible to cheat this way! Goods/PAX transport themselves from the source/producer to the nearest station by themselves--the players do not earn any money from this. Likewise, goods/PAX transport themselves from the destination station to the desired destination/consumer on their own--again, without paying any player for that. They simply use the "catchment area" to determine how far they'll transport themselves.

It can be used to teleport goods very long distances for free, such as when normal transport would not be profitable or cannot be afforded. Not only does this give the player money in the form of not losing money, but it also saves them a lot of time as making such route profitable may require many hours or more of work.

However this was not the actual cheat part of it. The cheat part was that one could merge entire cities into a single stop, saving on the cost and difficulties of setting up local transport. This means one only had to care about long distance passengers and mail, which are always very profitable unlike the local transport. Competitors could not even fulfil local transport because your cheat stop would always be faster and thus used in preference of any actual local transport network.

Extended solved this by adding transit time. Such massive stops have insane transit time due to assuming slow walking speeds, hence an efficient local transport will easily compete with them. In standard this cannot happen since transfers are instant and so having 1 transfer (to the stop) is always faster than 2 (taking a bus between 2 stops).

Oh and for an actual cheat with this. In the most common payment method you get paid for how far the convoy moves goods between stops. Hence one could get 2 nearby stops, a source and destination, and artificially increase the distance the convoy travels by joining them with stops very far away, say at diagonal corners of the map. Since it costs nothing to ship the goods from their pickup point to the convoy you effectively generate free money. However this falls into the same category as the cargo bouncing exploit which can be used to achieve the same result, although with more effort. As an example, instead of building an expensive rail line to move coal to a powerplant one could magically teleport the coal to a huge ocean area of the map and instead move it via boat to make all the profit, setting up a bi-directional flow for bulk goods for the ships is trivial as one just needs another power plant and another coal mine to connect on opposite sides.

[Ters]

However this was not the actual cheat part of it. The cheat part was that one could merge entire cities into a single stop, saving on the cost and difficulties of setting up local transport. This means one only had to care about long distance passengers and mail, which are always very profitable unlike the local transport.

That is not how it is in my experience. Local transport is profitable almost by default, and there are almost no running infrastructure costs since the city streets are publicly owned. Only towards the end of the timeline does it change to almost certain unprofitability, since the buses seem balanced for the speed bonus at their top speed of 80-100 km/h, but city streets only allow for 50. However, at that point, I find that games are getting stale for several reasons. This might be heavily pak set dependent, though. I play pak64.

There are so many things with local transport that are a nuisance at best that it could almost fill a board. Most of them do actually affect all kinds of vehicles, but local transport gets hit the most simply because there are a lot more vehicles in that category. There is also literally less room for workarounds to some of them.

one could get 2 nearby stops, a source and destination, and artificially increase the distance the convoy travels by joining them with stops very far away, say at diagonal corners of the map. Since it costs nothing to ship the goods from their pickup point to the convoy you effectively generate free money.

Long shipping distances creates other problems when using the default JIT-mode, though. If I were to "cheat", I would do the opposite to reduce the stop-start effect in JIT1. In Simutrans, it doesn't really matter how much money one makes, as long as the cash flow is positive.

setting up a bi-directional flow for bulk goods for the ships is trivial

I have never found bi-directional goods to be trivial. It might be easier with JIT2, though. (I really should play some serious Simutrans again, so I can finish my current game and start one using JIT2.)

[Leartin]

I have never found bi-directional goods to be trivial. It might be easier with JIT2, though. (I really should play some serious Simutrans again, so I can finish my current game and start one using JIT2.)

Have two coal mines (A, B) and two coal power plants (A', B') with no cross connection. Set up a station at each factory, and two unrelated station (x,y) in the sea. Merge x with A and B', Merge y with B and A'. It's not what you would do in a normal game, so it's not strange you wouldn't encounter it.

[Ters]

Have two coal mines (A, B) and two coal power plants (A', B') with no cross connection. Set up a station at each factory, and two unrelated station (x,y) in the sea. Merge x with A and B', Merge y with B and A'. It's not what you would do in a normal game, so it's not strange you wouldn't encounter it.

It is how the schedules are set up that bothers me.

[Casteele]

Thanks everyone for their comments and explanations--it does help better understand the issues!

First and foremost, I am looking at things with the perspective of "I enjoy this game, and I want to help it grow, be better, and more fun for most--so they keep coming back for more!" Having been a coder on other games, MUDs in particular, I've too often seen development staling and becoming stale because of worries *at the coding level* of preventing player cheats/exploits of game code/mechanics. Personally, I despise cheats/exploits; They ruin the fun of games--even single player games--by taking the fun out of figuring out a solution to a problem, and he rewarding feeling of doing so.

However, I do see that as an administrative problem (especially in multi-player), and not a coding/development problem that can stall or prevent development of game features that add value to the game for many due to the actions of a few. At the other extreme, here's some game code that totally prevents any cheating at all: int main(int argc, char* argv[]) { return 0; /* no one can ever cheat this game because it never does anything! */ } I've seen MUD coders who've written code almost like that, or chose not to implement a much wanted game feature because they worry too much about people exploiting it. Until we have real thinking computers instead of just logical devices, I believe that administrative issues should be kept, and handled, at the administrative level, not the coding level.

On the other hand, there are some issues that can be solved, or at least add some administrative assistance, at the coding level. For example, the idea of using "whole city coverage" to prevent local congestion in order to make long distance transit more profitable; What if instead of calculating everything at once in the game loop (I'm used to calling such concepts a game "tick"), it makes it a two-step process? That is, when goods "hop" on to a station, they do not immediately hop off. But instead, they remain on it until the next game loop. This would mean that when other goods are trying to find a route, they'll see that this station is too crowded, and choose to avoid it. As I understand it, this may not be very much different than what I see/read about the "transit/walking time" concept is supposed to do.

Maybe this is even how it's already done--I'm not familiar with the game code. But that is how I would have done it. Each tick, iterate over all stations/industries/transports, doing a two-step process: First, figure out which goods/transports have to move to their next (or final) destination, and queue them to move there--don't actually move them until the end of the tick processing (the second step). This would including loading/unloading transports as a "destination"; Accounting for moving on/off a transport (convoy), station, or simply a loaded transport moving from one tile to another at speed.

The second step, then, would be to actually move the goods queued for movement. (Alternatively, the code loop can do this step first, processing the queue made during the previous tick. The net effect is the same. As long as there's a clear division point between the two steps.)

Thus, you could have the very realistic simulation of an empty station at which five transport convoys arrive during the same tick, and next tick, that station has gone from being empty to heavily overcrowded. This would make newly generated goods try to avoid that overcrowded station and find an alternate route. I've seen it in the food service industry often enough; A loaded tour bus stops at some food stop, and unloads. Others driving by looking for a place to eat would see the tour bus and decide to go eat elsewhere, because they know there will be long lines of people waiting to order and/or eat. It wouldn't matter if the restaurant had separate parking lots in many places (even with magical instant travel between the lots and the main store); The central store location is still clearly crowded and will be avoided. To me, this is not much different than a transport simulation--just using stations/platforms instead of a restaurant.

That is why it's also important to only queue the goods to move, but wait until the next step/tick to actually move them. If you move them all at once, then it would always "appear" that the station was never crowded because the goods would arrive and depart instantly, leaving the appearance of an empty station. And I think that is the game mechanic here where the problem arises in the first place.

I also think it would simplify the whole "walking time/distance" thing. Every station would be viewed as a whole, with overcrowding affecting the entire station, regardless of which single tile is being considered at the time. So if you use some "cheat" to connect a single station to every city on the map, then every city on the map will share one single, overcrowded station that goods will try to avoid. You do not need to try to calculate the time/distance between station tiles, because it won't matter.

It would also affect "long distance" routes, such as to tourist attractions or inter-city transport, since goods would try to avoid the overcrowded local station(s) regardless.

As it seems to be (in my version running here), I could actually cheat/exploit better without joining nearby stations. Let us say I have a coal power plant near a coal mine. I could put a station at each. But instead of running road/rail in a direct line between them, I could run it in a ring around the entire map, generating revenue for each tile as the convoys travel around the map. These revenues would likely exceed the maintenance costs, keeping it profitable. It would be foolish to try to detect and/or prevent this at the code level, because what if you had to do just this to transport goods around a geographic feature that was in the way? I could even include a "shortest direct" path for empty convoys to return to the first station while empty, by using way points to insure only loaded convoys use the "long" route around. In a multi-player server scenario, that would require a human administrator to look at the map design and determine if it was a legitimate loop, or one artificially created in order to "cheat".

In the end, my original thoughts and purposes for posting is the basic idea that this kind of a tool is a much needed tool to add value to the game. As it is, it takes much more extra work to plan and lay out stations and paths between them, due to game mechanics, than it should. It's also something that is done by the code, rather than something the players can control. This makes the game more frustrating, not more enjoyable. I see the same issue with the way some scream "CHEAT!" at every opportunity. It detracts from the game, without actually preventing cheating or creating an enjoyable game. This is especially true when I believe those "cheats" are more often an "edge case", not a "mainline" issue.

(My apologies if this post seems disorganized/long/jumpy/et cetera. It's partly intentional--Originally, I did not want to explain my every thought process, nor did I want to write a long, carefully organized academic paper that would cause people to just say "TL;DR!" Even as-is here, I've suppressed a lot of details; People can ask if they want those details.)

SavedURI :Show URLSavedURI :Hide URLhttps://forum.simutrans.com/index.php/board,33/action,post2.html

[prissi]

Honestly given the few number of active Simutrans servers at all time (<5)  compared to OpenTTD (280 right now), despite all the effort of hosting a Simutrans server at home with one click, I am not sure that worrying about cheating is really what should stop us from implementing stuff.

[Leartin]

At the other extreme, here's some game code that totally prevents any cheating at all: int main(int argc, char* argv[]) { return 0; /* no one can ever cheat this game because it never does anything! */ }

I hope you are aware that this is a slippery slope fallacy.

Also, what is the "administrative level"? As far as I know, the code in it's current form allows to specify a merge cost (which is multiplied by 2^distance) and a max distance. Whoever is the "administrator" of a game can choose those values however they please, so if you want to play without restrictions, set a cost of zero and a max distance of 1000. The predefined values are only what a pak-designer figured to be sensible values for their pakset to have a good expierience (well... they are probably not set in most paksets yet), same as all other settings.
A comparison: Imagine in online card games (Magic Arena, Heartstone) you could look at the other players hand. Sure, the rules say you are not allowed to, but nobody wrote code to prevent it because that would be restricting player freedom. Seems dumb, eh? While there might be a specific game mode/setting to allow it, eg. for a teaching environment, the status quo should be to enforce it by game mechanics, not rules.

This would mean that when other goods are trying to find a route, they'll see that this station is too crowded, and choose to avoid it.

That's only true if no_routing_via_overcrowded and/or avoid_overcrowded are active. (The former makes it so nothing spawns if it would need to travel over an overcrowded transfer, the later makes it so nothing will enter a vehicle if it leads to a transfer that's overcrowded) - both options are not too popular. If they are both off, the only negative effect is that pax won't spawn at that station, which is even helping the player get rid of the crowd easier.
I'm all for changes in that regard, but it's a bit far-fetched when talking about station merging.

Let us say I have a coal power plant near a coal mine. I could put a station at each. But instead of running road/rail in a direct line between them, I could run it in a ring around the entire map, generating revenue for each tile as the convoys travel around the map. These revenues would likely exceed the maintenance costs, keeping it profitable. It would be foolish to try to detect and/or prevent this at the code level, because what if you had to do just this to transport goods around a geographic feature that was in the way?

Well, you are wrong in how it works, and that's already sorta prevented.
There are three "pay_for_total_distance" settings. pftd=0, which you probably use, does not pay out per tile, but the distance between each stop along the line. You can still do it by creating stops along the road, that's what DrSuperGood referst to as "Cargo Bouncing Exploit". With pftd=1, you only get paid for the distance whenever the cargo changes vehicles. So you would need at least two lines for the Cargo Bouncing Exploit, but it's still possible. With pftd=2, you only get paid the distance between source and destination. If you move away from the destination, you may even get paid negative numbers. Therefore, the Cargo Bouncing Exploit is no longer possible. What if there is a geographic feature in the way? Why, you earn less of course. Though with unrestricted station merging, you can somewhat use the Cargo Bouncing Exploit with pftd=2, so...

I see the same issue with the way some scream "CHEAT!" at every opportunity. It detracts from the game, without actually preventing cheating or creating an enjoyable game. This is especially true when I believe those "cheats" are more often an "edge case", not a "mainline" issue.

There is a larger portion of the player base which turns off bankruptcy and plays as a model railway, and that's completely fine. There are many many settings and variables which can be tweaked for a harder or simpler game expierience, just as you like it, and making it easier is not bad. But that does not mean players should start in "creative mode", limits are a good thing. Limits that reflect how players generally think the game should be played are even better, as new players learn by playing what's expected. Mostly though, we come back to the slippery slope: If there were no limits, there would be no game.