Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More track for the same cost #7814

Closed
Floedekage opened this issue Nov 1, 2019 · 9 comments
Closed

More track for the same cost #7814

Floedekage opened this issue Nov 1, 2019 · 9 comments

Comments

@Floedekage
Copy link

When laying tracks between to points it cost the same for a "hard" 90 degree turn and diagonal track.
I've built one line consisting of 31 straight tracks, then a 90 degree turn and then 31 more track pieces, compared to one diagonal line between the same two points.
The cost are £9891 for the straight line and £9867 for the diagonal
The length tool tip indicates that the diagonal length is 32 (31,5) and the straight is 63 (62,5).
Trains will of course choose the shorter, diagonal, track but the speed comparison between the two are about 3:2 in favor of the diagonal
Should one piece of diagonal track not cost half of a piece of straight track?
And should the speed possibly reflect the symbolic length of the tiles? E.g. in the above the diagonal line would have a speed advantage of 2:1?

Version of OpenTTD

1.9.3

Expected result

Single diagonal tracks should costs about half of a straight piece of track, as to reflect their symbolic compared length.

Actual result

One piece of diagonal track equal to 0,5 symbolic tiles cost the same as one straight piece equal to one tile.

Steps to reproduce

Build a railroad between to stations that are at an angle, make one using as much straight track as possible and one with as much diagonal track as possible.

@ldpl
Copy link
Contributor

ldpl commented Nov 1, 2019

Price calculations use manhattan distance so it makes sense that tracks of the same manhattan length cost the same. And speed discrepancy is a well known thing that's being discussed for years without any tangible result. Though if anything it should be made slower on diagonals, not faster as you're suggesting.

@Floedekage
Copy link
Author

The Manhattan distance certainly explains why it is the way it is.
I still think this should be changed however.
I do not understand however why you think speed on diagonal pieces should be slower? This might be a difference in how we choose to play the game, perhaps?
Maybe this should be left as a setting for the players to chose? Much like the "Forbid trains from making 90* turns"?

To expand on my point in the first post; the "hard 90* turn" has a maintenance cost of £288, whereas the diagonal has a maintenance cost of £480. Should the cost here not also be lower for the diagonal, or at least the same?
Again, this might be a difference of how we we all play the game, but I prefer creating realistic train lines that follow the landscape, and first now I might have realized why the difference in weather my company survived seemed so random. It might have come down to if I had too many lines with long diagonal sections.

@ldpl
Copy link
Contributor

ldpl commented Nov 2, 2019

@Floedekage I don't think speed should be changed at all. But there is a solid reason to slow it down as currently diagonal tracks cover double distance with only 75% speed so they're effectively 33% more profitable than straight ones.

Also, realism usually isn't a good reason for a proposal as openttd itself is not very realistic and was never supposed to be. Sure, you can play in a some specific way and call it realistic but to make it actually realistic you would need to rewrite the game from scratch. Like, what's the point of meddling with train speeds for more "realistic" income when the whole economy model in the game has nothing to do with real life? Just cheat yourself some money and make whatever "realistic" thing you want.

@Floedekage
Copy link
Author

@ldpl I don't get how you arrived at those numbers. A diagonal line between two points is about 70% the distance of a 90* angle, related to the speed difference between the two types of lines that actually makes the 3:2 speed ratio very apt as the longer 90* line is then ~33% slower and that's at least close.

But my comment on the cost of construction and maintenance related to length still stands.
Following the numbers from my first post that would make diagonal lines 30% more expensive i regards to mathematical length and double as costly related to the in game measurement.
The maintenance of the diagonal line is then from the start about 3 times as expensive as the 90* line, that makes it 5 times as expensive compared to mathematical length and 6 time as expensive compared to the in game measurement.

I don't quite get your point about how this game isn't supposed to be realistic. It is after all a simulator and plenty of the additions that have been made since OpenTTD recreated TTD incorporate realism, e.g Infrastructure maintenance, Cargo Dist., Realistic Train- and Vehicle Acceleration Model, Slope Steepness for Trains and Vehicles and probably more.

Nobody is expecting any simulator game to be a 100% recreation of reality, and I am not saying that you or anybody should have to play with the same settings as I do, but it might surprise a new player to learn that the most cost effective way of building a train network is to build a longer line between to points than the most direct line.

Your last point is very dispiriting. Why would you suggest I should cheat to get some money to get the challenge of building a realistic infrastructure network? All I am asking is that it would be nice to at least have the option to make the cost and maintenance of a stretch of line be relative to the length of that line.

@ldpl
Copy link
Contributor

ldpl commented Nov 3, 2019

@Floedekage I know transport tycoon is called a simulator sometimes and mb by 1995 standards it was but as a current state openttd is a total junk of a simulator so it's more reasonable to just call it a sandbox game. For instance, in a regular game money doesn't rly matter, if you so insist on not "cheating" you can take 10 minutes to make a line that will bring you more money than you can ever spend. Yeah, and unless you're playing with basecost newgrf construction and maintenance costs are negligible compared to profits (on an optimal distance) that's why I say diagonals are 33% more profitable (or faster, depending on how you look at it). There are competitive servers that are very meticulously set up in a way that they can have actual goals that matter but it's a completely different gameplay, very unlike of what's usually considered to be "realistic".

@Floedekage
Copy link
Author

I would love to get a second opinion on this.

I see where you are coming from @ldpl , but it still seems like something that should be changeable.

@andythenorth
Copy link
Contributor

I wouldn't worry about it, the OpenTTD scale is highly variable. Trains are shorter for some angles than others. The original sprites change height between angles. It's all probably fine.

Although these costs may seem wrong once noticed, they make little difference to the gameplay.

It's also not noticed by many people. I've read hundreds of OpenTTD issues in recent years, and the only one I found that's close to this is a fix for diagonal speed of trains: #1793

So I'm proposing closing this one as "won't fix". Thanks for contributing :)

@floodious
Copy link

floodious commented Jan 11, 2020

@Floedekage
I would love to get a second opinion on this.

Ideally the distance would be sqrt(1/2) as expected... but you must look at this in terms of the actual implementation. I'm not going to jump to conclusions here but if forced to guess I might think the code itself uses integer computations which can not accommodate approximately correct speeds, distances or anything else for that matter. I suspect this is the intended meaning behind statements like "... but that would be a whole different game."

The game has many significant problems of scale. There have been significant efforts invested toward improving the code for hill-climbing and such with approximations. When you consider these issues however you should realize the only way you could implement valid computations would be if you had every number. That includes angles (climbing, descending and tilting), distances including heights, material properties and friction, engine properties, fuel, cargo weight and so on. Realistically many of the core elements simply do not exist such as a definite scale for length/height. So the whole thing breaks down right there.

So back to my point about real practical implementation of the code ... depending upon how the code currently works you might be able to make small improvements to the approximate results. It doesn't make sense to focus on ideals directly... rather you need to aim for "playability > cost > accuracy" or similar. Then you need to look at your aim to improve realism and come up with a way to modify the current code to achieve that improvement without negative impacts upon other features: processing cost or overhead, game playability, compatibility.

So ultimately unless you're aiming to re-write the game from scratch (a whole different game), it really makes such goals quite troublesome or even impossible to reach practically.

Price is almost definitely of the least concern... again merely a question of how it might be fixed and whether a fix is even possible. Making a 45 degree angle equal 70.71% distance + time would be a more worthy aim... but not necessarily any less impossible.

@andythenorth
Copy link
Contributor

Thanks for this. There's been no activity on this for some time, and as it stands, it doesn't look likely that it will go any further. I'm closing it as we try to keep the issue count low for OpenTTD, it helps us focus on things that are important and fun. Feel free to discuss in irc or request re-opening if you disagree. Thanks for contributing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants