News:

SimuTranslator
Make Simutrans speak your language.

Merge Station Tool

Started by HyperSim, January 02, 2019, 02:13:55 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

HyperSim

Happy new year, everyone!!

I made a new general_tool for standard, Merge Station Tool (general_tool[41]).

How to use?
It's very easy. Just click two stations you want to merge.
This video shows you how this feature works.
https://youtu.be/J3etXaNbKE4

When to use?
- Unite split platform that was made by mistake
- Merge station and bus stops
- Extend station (ex. add harbor at shore nearby) without using any dummy station.

Q & A
Q. Is there any limit?
A. You can only merge stations belonging your company.
Q. Is it possible to merge very far stops?
A. Yes.  You can merge a stop at one side of the map and one at the other side if you want to.
Q. May it destroy the game?
A. I don't think so.  You can make station 100km away without this feature.

.diff file based on the newest source code (updated Dec. 25th 2018) is attached.
Here's the branch of my github.
https://github.com/HyperSimu/simutrans/tree/MergeStaTool
Any questions and idea are welcome.
Thenk you.

Leartin

There is this "tactic" where you cover a whole city as if it was one station. Many consider it an unfair tactic, or even a cheat, and there were talks about how to prevent it (station size limit, station density, etc.). Your patch, on the other hand, would be an enabler for that tactic, since it would not only be easier, but cheaper as well. The quite logical solution someone came up with: For each tile apart in manhatten distance, merging stations should cost one "station tile" worth of money. This way, while it becomes "easier", it at least doesn't become cheaper.
I'd change that by not using the cheapest station tile, but a value set in the configs. This way, a player who just wants to have a model railway could set it to 0 and not have to pay anything, as you intended, while server-players may use higher values to prevent abuse.
[Note: If costs are added, I'd suggest the ability to drag from one station to another, so you can see the cost associated with it before releasing the mouse button. Just like how you can build roads with two clicks, or by dragging from one place to another]

In the video, you show that the first station gets incorporated into the second. Please make it so the stations name tag switches to where you clicked with the mouse the second time. This should also work if you use the tool on the same station twice. There is currently no way of changing the position of station tags, so it would be really nice to have here, since a dedicated "change station name tag position tool" is a bit silly.

On a technical note: Is this the same as if you'd delete one station and completely rebuild it, or are all wares in that station, destined to that station, etc. still there after you combine them?


I suppose these are a lot of requests considering you only went out for a simple tool (well... general tool :P), but please consider them. :)

HyperSim

Thank you for your suggestion.

QuoteI'd change that by not using the cheapest station tile, but a value set in the configs. This way, a player who just wants to have a model railway could set it to 0 and not have to pay anything, as you intended, while server-players may use higher values to prevent abuse.
I agree.  I will add the option.

QuoteOn a technical note: Is this the same as if you'd delete one station and completely rebuild it, or are all wares in that station, destined to that station, etc. still there after you combine them?
The latter.  This tool works like "make station public tool", so all wares and passangers are still going to the station after unification.

Ters

Quote from: Leartin on January 02, 2019, 04:31:12 PMIn the video, you show that the first station gets incorporated into the second. Please make it so the stations name tag switches to where you clicked with the mouse the second time. This should also work if you use the tool on the same station twice. There is currently no way of changing the position of station tags, so it would be really nice to have here, since a dedicated "change station name tag position tool" is a bit silly.
I like this idea. Just moving the name around should not cost anything, though.

Leartin

Quote from: Ters on January 03, 2019, 06:39:40 AM
I like this idea. Just moving the name around should not cost anything, though.
Combining two stations should cost the same regardless where in the station one clicked; And if it's the distance between two stations that matters, not the distance between clicks, clicking the same station twice would give a distance of zero, therefore a cost of zero.
I'm not sure if it would be programmed that way, but that's the reasoning I'd expect as a player  (=agreement on no cost for moving the name around)

HyperSim

I updated this patch!

Update feature
- Add "cost_multiply_merge_halt" parameter in simuconf.tab.  The cost is calculated by (cost*distance) (default value is 1,000 ¢/tile)
- Use center of station to measure station distance.  (It is weighed by station building level)
- If the stop you're going to merge is located in the station coverage of the station, it doesn't cost.

I realized that moving station name tag would be affect many part of the game, so I think we should discuss more at other post.

.diff file based on the newest source code (updated Dec. 25th 2018) is attached.
Here's the branch of my github.
https://github.com/HyperSimu/simutrans/tree/MergeStaTool
Any questions and idea are welcome.
Thenk you.

HyperSim

Sorry, there's mistake in .diff file.

ceeac

Two comments:

  • The patch contains intermediate files (.gch and .d files). They are not needed.
  • Currently the diff does not apply when using svn patch. You can make a svn compatible patch using git diff --no-prefix.

HyperSim

Thank you ceeac-san.  I fixed some bug and modified .diff file.

prissi

Apart from the issue of Leartin (which essentially boild down to Simutrans being a TRANSPORT simulator and thus transport across ocean via stops defies the purpose), I do not like the current implementation. I would rather change the existing merge and make public into a merge tool, which also allows merging with a public station, and a make pubic tool independent from the first. That is probably even more logic than the current one.

And as stated before, in networkgames, the availability of such a tool would totally screw the balance, because a player using this tool would almost certainly get less transfers until destination than a player not using it. This would force to other players to use it as well. It needs to be really expensive to prevent misuse with drastically increasing costs (i.e. 2^n = 1 tile space 100, two 400, 3 tiles 800, 10 tiles 102400 and so on) Linear will certainly no do. Since no maintenance is involved, I do not see the need to scale this cost with the month length.

Ters

Quote from: Leartin on January 03, 2019, 07:19:55 PMCombining two stations should cost the same regardless where in the station one clicked; And if it's the distance between two stations that matters, not the distance between clicks, clicking the same station twice would give a distance of zero, therefore a cost of zero.
I'm just not sure how easy that is to implement.

Quote from: HyperSim on January 04, 2019, 09:29:56 AMUse center of station to measure station distance
That is not what I would expect. If I have two station bordering each other, I would expect to pay nothing, since the cost was supposed to equal to the number of stations tiles one would otherwise have to build and destroy if the station was built as one to begin with.

Quote from: prissi on January 04, 2019, 01:27:40 PMin networkgames, the availability of such a tool would totally screw the balance
As has been mentioned, the tool does not enable something that is not already possible. It only makes it easier, and possibly cheaper. The biggest difference is probably joining stations across water. One could perhaps calculate the price according to distance along land and over bridges.

Leartin

Quote from: HyperSim on January 04, 2019, 09:29:56 AM
- Use center of station to measure station distance.  (It is weighed by station building level)
[...]
I realized that moving station name tag would be affect many part of the game, so I think we should discuss more at other post.
Well, in case moving the station name tag does not become part of this tool, wouldn't it be easiest to just measure distance between the tiles you click on?
Maybe not entirely what one would expect, but that would be reasonable behaviour. The player gets the task to find the shortest distance between the stations they want to merge.

Quote from: prissi on January 04, 2019, 01:27:40 PM
And as stated before, in networkgames, the availability of such a tool would totally screw the balance, because a player using this tool would almost certainly get less transfers until destination than a player not using it. This would force to other players to use it as well. It needs to be really expensive to prevent misuse with drastically increasing costs (i.e. 2^n = 1 tile space 100, two 400, 3 tiles 800, 10 tiles 102400 and so on) Linear will certainly no do.
Players can already do the very same thing by building stations and destroying them again. Which is why the idea is so straight forward: Measure the distance and pay for each tile where you would have buildt a station if you had used the other method.

If an attempt is made to prevent that type of play, it should encompass the old method just as much as the new one. A few examples, without concern for whether it could be done:
- restrict the max size of stations to a certain value (but what about legit large stations?)
- restrict the max size of stations to a certain value, but allow certain extension buildings to change that value.
- when you build the first tile of a station, it becomes it's center, and creates a buildable area surrounding it, in which further parts of the station can be buildt. For larger station, special extension buildings with their own buildable area may be required.
- restrict the max size of stations based on station density (=you draw a rectangle around the station. If [(number of tiles with station) - (number of tiles without station) < x], the station is too spread out and can not be expanded outside the rectangle.)
- restrict the max size of stations based on station density, but with more complex shapes for larger stations. (up to 20 tiles, it's just a rectangle; 21-40 it's two rectangles, etc.) [finding two or more touching, not overlapping, rectangles, which encompass all station tiles while also encompassing the least amount of tiles. That sounds so simple, it's either easy or an unsolvable problem...]
- restrict the max size of stations based on station density, but allow special extension buildings to influence the results (change the x-value) - More expensive stations might allow for less density, buy being unlikely to be buildt by players who cheat distances in the first place.
- keep tab of stations which have disconnected parts. Have monthly costs for these distances as extra maintenance. (perhaps even non-linear, but in return a lot less for only one or two tiles)

Or even something more radical:
- disconnect station coverage from station size. Each station only has coverage around it's center (indicated by the name tag). Special buildings may expand the coverage, but only around the same center. Spreading would be completely pointless, for extra coverage you need to either build smaller bus lines (you could build train lines, but if the train is 5 tiles long there is no space between stations) or pay for free parking and taxi services to enhance reach, which might be easier, but more costly.
(This probably would require to detangle code so old it's written in hieroglyphs though, I'm fully aware it's not viable)

isidoro

All those new rules about restrictions on how to build stations will only confuse new players and maybe old ones too and defies in my opinion the goal of simplicity of mainline Simutrans.
If it were possible or easy to program, I would go to the root of the question.  It costs nothing for a ware to travel form one station tile to another.  It should cost, at least, time.  It's the same concept as station coverage.  The game supposes that ware within station range travels on their own means to the specific platform.  It just costs nothing and is infinitely fast.  It should cost, at the very least, time.
Ware should belong to tiles instead to to stations.  Whenever a vehicle/line requires a ware and it is in the station or its coverage, it should travel to where the stop tile is, spending some time in moving from one tile to the next.  If the transit is between map height levels, time should be greater, of course.  And, if between tiles with no land connection, it should simply be forbidden.
But I gess that that is quite difficult to program.  Not to tell the difficulty of the user interface to indicate where each peace of ware is...



HyperSim

Quote from: prissi on January 04, 2019, 01:27:40 PMAnd as stated before, in networkgames, the availability of such a tool would totally screw the balance, because a player using this tool would almost certainly get less transfers until destination than a player not using it. This would force to other players to use it as well. It needs to be really expensive to prevent misuse with drastically increasing costs (i.e. 2^n = 1 tile space 100, two 400, 3 tiles 800, 10 tiles 102400 and so on) Linear will certainly no do. Since no maintenance is involved, I do not see the need to scale this cost with the month length.
Cost is a big problem and I'm not sure what is the best way.
I have the idea calclating the cost using exponetial function but I can't decide the formula (ex. what is the best value for base), so I used linear function for the present.  I want to discuss about it.

Quote from: Ters on January 04, 2019, 07:31:28 PMThat is not what I would expect. If I have two station bordering each other, I would expect to pay nothing, since the cost was supposed to equal to the number of stations tiles one would otherwise have to build and destroy if the station was built as one to begin with.
If the station is placed inside the station coverage area, the cost become zero.  (see the image attached)

Quote from: Ters on January 04, 2019, 07:31:28 PM[...]
I'm just not sure how easy that is to implement.
I think it's not so difficult.  Just change the order of station tiles list.
However, I'm afraid that this feature may affect every scene related station and should not discuss here.

Quote from: Leartin on January 04, 2019, 11:12:56 PM[...]
Well, in case moving the station name tag does not become part of this tool, wouldn't it be easiest to just measure distance between the tiles you click on?
Maybe not entirely what one would expect, but that would be reasonable behaviour. The player gets the task to find the shortest distance between the stations they want to merge.
I doubt it.  In my opinion, changing the cost by where you clicked on is more non-reasonable behaviour.

Those rules suggested by Leartin-san is too complecated to adopt so as the idea isidoro-san.

Vladki

Quote from: isidoro on January 04, 2019, 11:43:40 PM
All those new rules about restrictions on how to build stations will only confuse new players and maybe old ones too and defies in my opinion the goal of simplicity of mainline Simutrans.
If it were possible or easy to program, I would go to the root of the question.  It costs nothing for a ware to travel form one station tile to another.  It should cost, at least, time.  It's the same concept as station coverage.  The game supposes that ware within station range travels on their own means to the specific platform.  It just costs nothing and is infinitely fast.  It should cost, at the very least, time.
Ware should belong to tiles instead to to stations.  Whenever a vehicle/line requires a ware and it is in the station or its coverage, it should travel to where the stop tile is, spending some time in moving from one tile to the next.  If the transit is between map height levels, time should be greater, of course.  And, if between tiles with no land connection, it should simply be forbidden.
But I gess that that is quite difficult to program.  Not to tell the difficulty of the user interface to indicate where each peace of ware is...

This is done in simutrans extended. Passengers and goods take time to move from their home to the first station, from the last station to the final destination, can transfer between nearby stations on the way, and it also takes time to transfer within one station (big station takes longer). All these times are accounted for, and affect the routing decision. The coverage for passengers/mail is much bigger (10-20 tiles) than for goods (2-3 tiles). I'm not sure if passengers would swim or not... :-)

What I would consider useful for simutrans standard would be:
- if part of station is detached, it would form a new station. Maybe with some delay (at the end of month) to allow for temporary split while rebuilding the station. Cargo and passengers waiting should be left on that part where their next hop convoy is expected to arrive.
- stations of the same player that touch each other merge automatically (or manually for no cost - with the possibility of moving the label). Detached parts shall not be mergeable.
This would stop players from carpeting the whole town by detached bus stops acting as single station, but allow for fixing mistakes, or joining two stations that grew too big.

And as a nice bonus would be to allow stations of different players that touch each other to form a transfer point - passengers and goods should be able to transfer just like on public station, for simplicity it can be instant.

HyperSim

Quote from: Vladki on January 05, 2019, 02:45:01 PMWhat I would consider useful for simutrans standard would be:
- if part of station is detached, it would form a new station. Maybe with some delay (at the end of month) to allow for temporary split while rebuilding the station. Cargo and passengers waiting should be left on that part where their next hop convoy is expected to arrive.
- stations of the same player that touch each other merge automatically (or manually for no cost - with the possibility of moving the label). Detached parts shall not be mergeable.
This would stop players from carpeting the whole town by detached bus stops acting as single station, but allow for fixing mistakes, or joining two stations that grew too big.

I don't think it is nice idea.
Players often make separated station for some reasons.
- Station that have no platform track to pass the express train overtake a local train.  (Overtake Station in the figure1)
- Make Bus Terminal apart to avoid not to interrupt other traffic.  (Bus Terminal Station in the figure1)
- Build a warehouse away from track terminal to add farm in the connection.  (Track Terminal in the figure2)
- ...or just decoration.
Merging other player's stop may confuse players because players can't recognize what station is connected or not, so make public system is a reasonable choice.

Vladki

Ok, the overtake station and bus terminal are good examples. But the example with farm I would consider as cheating. Normally the truck will have to go to the central building to load. Grain will not fly over the fields on its own.

I don't want to merge other players stations. Just allowing transfers between players.

Ters

Quote from: Vladki on January 10, 2019, 03:04:05 PMNormally the truck will have to go to the central building to load.
Normally, the farmer would provide a way for you through the field as well. In my opinion, it is silly that you have to demolish parts of a "factory", and thereby remove some of its capacity, just to be able to access it. So in this case, it would not be cheating, but working around stupidity.
Quote from: Vladki on January 10, 2019, 03:04:05 PMGrain will not fly over the fields on its own.
Sure it does. How else does it get from the outer fields to the central building?

Vladki

But you have to demolish the fields to make the setup from screenshot above anyway. Just you can let the fields grow again.

Ters

Quote from: Vladki on January 10, 2019, 10:52:10 PM
But you have to demolish the fields to make the setup from screenshot above anyway.
Just one with the proposed merge tool.

Quote from: Vladki on January 10, 2019, 10:52:10 PM
Just you can let the fields grow again.
The fields won't grow again unless one "cheats" by building a disconnected station. Some other fields may grow, if there is room for them. In either case, that takes time. And money has been spent that might be needed for something else early in a game. Removing a field costs 5000 in pak64. So the removal of two fields costs the same as, or even more, than certain locomotives! It might actually be cheaper in the short run to tunnel below them, depending on the terrain.

Leartin

Quote from: Ters on January 10, 2019, 05:10:24 PM
Sure it does. How else does it get from the outer fields to the central building?

It is moved by the farmer, who moves about his fields to till the earth, plant seeds and reap the harvest all the time. Since the game is no farming simulator, we don't see that, but we can assume the farm works like a farm works, and the harvest is stored in the farms silo.

The problem starts with player stations, as they would not exist in reality. There is no movement of goods from the farms silo to a silo right next to it from a transportation company, rather, the farm (or any factory) would provide the means to be able to load a truck.
Which could be interesting. Imagine each factory would spawn with a road station and generate the lowest-level gravel/dirt road to connect to the closest street. It would help starting a company, as you might get away with buying just a few cheap trucks to make a profit. Larger factories might even come with their own railway or narrowgauge stations (but without rails). To give players the ability to expand on their own if they want a larger station, allow goods transfer between stations right next to each other (by choice).
If the station object, the position/rotation, and perhaps extra waytiles could be defined in each factory, the "natural" station could be incorporated in the graphical representation.

I'm aware this idea is not directly related to merging stations and has far more gameplay impact, but I do think it would be a positive impact and change our perspective of stations in general.

Quote from: isidoro on January 04, 2019, 11:43:40 PMIt costs nothing for a ware to travel form one station tile to another.  It should cost, at least, time.  It's the same concept as station coverage.  The game supposes that ware within station range travels on their own means to the specific platform.  It just costs nothing and is infinitely fast.  It should cost, at the very least, time.
You pay station maintenance. I was under the impression this station maintenance would include operating costs for forklifts, cranes, pumps and conveyer belts that move goods around within the station. You don't follow the internal logistics of a station, which does not mean they don't exist, they just aren't in the focus of the game. You don't pay per good, you pay a lump sum.

Doesn't mean there shouldn't be a limit, or a cost, on wares travelling over gaps rather than within stations, but I don't think it's free (unless there are free stations, that is)

Vladki

I like the idea of factories having a loading bay of their own. Just like the factories on water (oil rig and fish swarm)

Ters

Quote from: Vladki on January 11, 2019, 03:09:59 PM
I like the idea of factories having a loading bay of their own. Just like the factories on water (oil rig and fish swarm)
Me too.

HyperSim

Quote from: Vladki on January 11, 2019, 03:09:59 PM
I like the idea of factories having a loading bay of their own. Just like the factories on water (oil rig and fish swarm)
I like the idea but it is too different to discuss here I think.

Let's back to the main problem.
You have a lot of opinions I know but first of all we sould decide on our policy.
Which way to calculate the merge cost  is better, linear or exponetial?
I give you two examples.
1.  total cost = COST * distance  (linear)
2.  total cost = COST * 2 ^ distance  (exponetial)
(COST: Basic cost to merge station defined in simuconf.tab)
After deciding the policy, let's move on detail.

gauthier

Many ideas were thrown in this thread. In my opinion, most of them make the game either confusing, out of its aim of being simple and focused on transportation or too CPU-intensive for what it's supposed to do. If I could select only one idea to solve most, not to say all, problems, it would be:
Quoterestrict the max size of stations to a certain value (but what about legit large stations?)
In real life, such very large stations are usually airports with several terminals so that the airport had to set up a shuttle service or even a light guided transport (rail, monorail, even maglev) between the terminals. This idea totally makes sense for me.

Regarding the merging cost, it should not be more expansive than merging the station by the well-known build-and-remove method. Then I would go for linear cost.

Leartin

Quote from: gauthier on January 13, 2019, 09:33:46 AMIn real life, such very large stations are usually airports with several terminals so that the airport had to set up a shuttle service or even a light guided transport (rail, monorail, even maglev) between the terminals. This idea totally makes sense for me.
...and besides, if bordering stations could transfer pax from one to the other at the cost of a transfer (=as if they were connected by a vehicle), one could still build gigantic stations consisting of several stations; and if someone would carpet a city with such bordering stations, there would at least be the transfers, negating the peer pressure prissi mentioned.

But I'm not sure it works with all paksets, because of differing train lengths. If your pakset usually has trains of length 4-5, it would be easy to restrict station size to a 6*6 square. If trains of length 11 are reasonable in any given pakset, you could not have a smaller station size limit. An 11*11 square would still allow a station covering 15*15 tiles consisting of 9 bus stops, which is bad enough to say the problem wouldn't be completely solved. Note that the limit for train length (in terms of wagons) was lifted only recently, so it might be that one would have to think of 21 tiles length or longer. At this point, station size restrictions would be a joke.

That's where the idea of density comes in, to allow for large stations that are actually all station, while disabling large stations consisting of too little parts.
The rules may look complicated, but I don't think they are hard to grasp in gameplay.
Let's say you need a density of 87,5% with 5 Tiles leeway. The formula: [Tiles in Rectangle]≤[Station Tiles]+([Tiles in Rectangle]/8)+5. If true,you have enough density.
Finding the rectangle is rather trivial (smallest and largest x and y coordinate; would be needed for the simple max station size anyway). Not sure if worth saving as a station characteristic or just recalculating each time.
87,5% seems strange, but allows for bitshift operation. So you only have bitshift, additions and then compare two ints, and it's only done once for each attempt to expand a station. Shouldn't destroy any pc.

What does it do in practice? Say you build a station which tiles only connect on a corner. After 3 such tiles, your calculation is 9≤3+1+5 and true. Build a fourth tile, and the calculation becomes 16≤4+2+5 and false. It will be buildt, but now the station gets a tag that it's under density, and it can't be expanded outside it's rectangle.
Why not just disallow it being buildt? Because you run into trouble with large stations. Say you build a ten tile long train station. - thats fine. Now you want to add a parallal platform. The very first tile would come up with 20≤11+2+5 which is false. If this was disallowed, it would become very complicated to deal with the building process of these stations. This would always be a problem once a station is large enough, so by generally allowing to expand the rectangle by one no matter what, there is always the option to fill it up to reach density and build further.

While complicated if you try to fully understand it, a common player does not need to, just the principle of "don't spread out stations" would be enough. Especially if the settings are more generous (eg. require 75% density and 10 tiles leeway - density requirement can be 50; 75; 87,5; 93,75 or 100 percent, depending on how far the bits are shifted, and the leeway can be any number. ) Note that four stations in a square, spaced for maximum coverage with 2 tile radius, would be 4 tiles in a 36-tiles square. Those could be prevented by low requirement of 50% density and 10 tiles leeway, I find it hard to believe that would affect any "real" stations which are not in a very strange shape to begin with. Things like the speedbonus, how pax spawn etc. are more complicated than that.


Quote from: HyperSim on January 13, 2019, 06:14:03 AMI like the idea but it is too different to discuss here I think. Let's back to the main problem. [...]
Sorry, but I don't think this can be tackled in parts.
You see, the reason why exponential costs are on the table would be to discourage using the tool to build cheaty stations. If those can't exist, or are discouraged by other means, it would not matter for your tool anymore. Eg. if there was a hard station size limit, your tool would not require any distance-based pricing.
Likewise, some expressed their opinion that non-connected stations should not exist at all, and if that became a reality, your tool would only be able to connect bordering stations anyway.

I would not mind having it, for now, with linear pricing, to reflect what could be done by building and deleting stations. But if anything comes from the surrounding discussion, this answer may change, or the question might be void.

HyperSim

I updated the patch.

Update feature
- Add "allow_merge_distant_halt" parameter in simuconf.tab.  Default value is false.  If this is disabled, you can't merge station located outside of the station coverage.
- You can change allow_merge_distant_halt in setting dialog.
- Change the formula of merge cost.  The cost is 2 ^ distance * COST(defined in simuconf.tab).

.diff file based on the source code (on Dec. 25th 2018) is attached.
Here's the branch of my github.
https://github.com/HyperSimu/simutrans/tree/MergeStaTool
Any questions and idea are welcome.
Thenk you.

prissi

Commited (of a heavily edited and cleaned up version) of this patch in r8715

Leartin

Does it work like Hypersim stated in his last post, or were there functional changes in implementation?

DrSuperGood

Quote# the cost to merge stations: the actual cost is (cost*2^distance)
I am not too sure how logical this is seeing how one can make infinitely large stops with linear cost by dragging stop buildings across the map. So people are aware even if cost is just 1, a 63 tile distance is impossibly expensive using a full 63 bits worth of money (impossible to obtain in most pak sets). Also it might be exploitable since one could break a 63 tile merge into multiple 4 tile merges for a fraction of the cost.

I certainly think some better and more consistent cost model or limit to prevent excessively large "cover everything" stops is needed. A good start would be a maximum spread which can be defined on a per pakset basis. A decent default for this would be 64x64 tiles, since in standard pak64 and pak128 that would be enough for 4 to 5 separate 12 long platforms.

prissi

The distance is the smallest distance between two tiles belonging to the stops. So long neighbouring platforms are only one tile apart. (And for techincal reasons it is limited to 31 tiles, then the cost stays the same.) But I agree that a maximum distance would make much more sense than either all or nothing.

And there are some functional changes. Especially the center tile (with the name) will move when extending stations. Also joining will work as before, i.e. only direcly adjacent stations can join if this is disabled. However, a maximum distance seems better.

Vladki

#31
Is there any documentation how this tool should be set in menconf.tab and simuconf.tab. So far I get either "too far" or "insufficient funds". Yes the player is in depth but it is a freeplay game

EDIT: I tried again in a fresh game (200.000 c), and that is still insufficient funds to merge a stations that have one tile gap in between. Not even stations that are directly adjacent. What I'm doing wrong?

HyperSim

Quote from: Vladki on April 24, 2019, 01:40:20 PM
Is there any documentation how this tool should be set in menconf.tab and simuconf.tab. So far I get either "too far" or "insufficient funds". Yes the player is in depth but it is a freeplay game

EDIT: I tried again in a fresh game (200.000 c), and that is still insufficient funds to merge a stations that have one tile gap in between. Not even stations that are directly adjacent. What I'm doing wrong?

I also see that would happen.
I think that line 6415 in simtool.cc would be wrong
if(  player != welt->get_public_player()  ||  !player->can_afford(workcost)  ) {
it should be
if(  player != welt->get_public_player()  &&  !player->can_afford(workcost)  ) {

By the way, I also found one odd thing.
In settings window, we can change "allow_merge_distant_halt" parameter.
This should be a checkbox (like "separate_halt_capacities" parameter) but it is a number text box. (see the picture attached)
I checked source code but I cannot find out what was wrong.

Leartin

Wouldn't the number for "allow_merge_distant_halt" indicate the max allowed distant between halts? An additional hard limit to the soft cost limit. At least, as presented I'd assume that as a player.

Vladki

Wouldn't it be more sensible to have the check for public player included in can_afford check? I thought that public player can do anything even if in debt. That way you wouldn't have to care about public player check in dozens of similar places of code?


prissi

HyperSim was correct. However, the allow_merge_distant_halt is indeed the maximum distance you can merge.

Fixed in r8762

HyperSim

Quote from: prissi on May 18, 2019, 02:21:48 PM
HyperSim was correct. However, the allow_merge_distant_halt is indeed the maximum distance you can merge.

Fixed in r8762

Thanks.

Quote from: HyperSim on May 18, 2019, 04:29:42 AMBy the way, I also found one odd thing.
In settings window, we can change "allow_merge_distant_halt" parameter.
This should be a checkbox (like "separate_halt_capacities" parameter) but it is a number text box. (see the picture attached)
I checked source code but I cannot find out what was wrong.
I did not notice that the parameter "allow_merge_distant_halt" was changed to an int value, so forget that.

HyperSim

#37
I checked r8762 and the merging is working.
However, when I do merging, the funds increase.  I checked the code and line 6372 and 6404 in simtool.cc were wrong.

workcost = -welt->scale_with_month_length( (1<<distance) * welt->get_settings().cst_multiply_merge_halt );
should be
workcost = welt->scale_with_month_length( (1<<distance) * welt->get_settings().cst_multiply_merge_halt );

That was originaly my mistake, sorry.


And I found that line 219 in gui/settings_stats.cc was also wrong.

INIT_NUM( "allow_merge_distant_halt", sets->get_allow_merge_distant_halt(), 0, 0x7FFFFFFFul, gui_numberinput_t::POWER2, false );
should be something like
INIT_NUM( "allow_merge_distant_halt", sets->get_allow_merge_distant_halt(), 0, max( welt->get_size().x , welt->get_size().y ), gui_numberinput_t::AUTOLINEAR, false );

ACarlotti

Quote from: HyperSim on May 19, 2019, 02:30:02 PMAnd I found that line 219 in gui/settings_stats.cc was also wrong.

INIT_NUM( "allow_merge_distant_halt", sets->get_allow_merge_distant_halt(), 0, 0x7FFFFFFFul, gui_numberinput_t::POWER2, false );
should be something like
INIT_NUM( "allow_merge_distant_halt", sets->get_allow_merge_distant_halt(), 0, max( welt->get_size().x , welt->get_size().y ), gui_numberinput_t::AUTOLINEAR, false );

That change looks wrong to me - I don't see why you would want to constrain the value of a setting by the current dimensions of the current map. What happens if that map is subsequently enlarged? Also, what happens if a new (larger) map is created/loaded?

prissi

The cost fix is submitted in r9763, but for the maximum distance, I go with ACarlotti

HyperSim

I've found another bug related this patch.
It has already reported in this topic.
https://forum.simutrans.com/index.php/topic,19018.msg180203.html#msg180203

This problem is caused by overflowing of "cent" (koord) in "recalc_basis_pos()" in simhalt.cc.
I attached .diff file to solve the problem.


Quote from: ACarlotti on May 19, 2019, 04:11:47 PM
That change looks wrong to me - I don't see why you would want to constrain the value of a setting by the current dimensions of the current map. What happens if that map is subsequently enlarged? Also, what happens if a new (larger) map is created/loaded?

That is true, I agree.  Then, this is better?
INIT_NUM( "allow_merge_distant_halt", sets->get_allow_merge_distant_halt(), 0, 10000, gui_numberinput_t::AUTOLINEAR, false );
Anyway, "gui_numberinput_t::POWER2" is definitely wrong and it should be fixed.