What changes would you like to see in OpenTTD?

[ic111]

As the other thread viewtopic.php?f=29&t=76852 deals with the topic of project organisation, I want to raise a different question here:

What changes / features, compared to todays OpenTTD, would you like to see? Into which direction should gameplay move (if any)? I mean both more or less existing patches, and things that might / should be added in your opinion (as long as implementing them is at least somewhat realistic)?

My personal opinion / taste:

• I like to play with timetables
• If day length means that you have a concept of time within a day, then creating different amounts of passengers etc., depending on the time of day, should be possible in principle. If I link this with the timetables issue, sophisticated transport schemes like "in the morning and evening, passengers need to be transported, freight trains need to run at other times of day" would sound possible.
• A dream - certainly hard or impossible to implement in an efficent way - would be cargo distribution that takes the timetable into account
• I like sparse networks (sparse in terms of number of vehicles) more than dense networks. I.e., I regard setting up a one-track-line where trains meet at defined stations much more interesting than adding a maximum number of trains to a two or four track line.
• To make the latter possible in a senseful way, compared to todays OpenTTD, I would need
  • (much) less passenger / cargo production (I know, controlled by NewGRF, but this doesn´t help if the NewGRF produces too much, and offers no suitable parameter to control it) - what I would like is a simple overall factor I can define in the settings; what I have is a simple source code hack that changes production by some factor; but since calculations are based on Integers, the sensefully possible factors are clearly bounded, and if I want more, more sophisticated code changes would be needed.
  • less population growth - I wrote a simple patch that solves this problem for me completely by introducing two corresponding settings, but AFAIK this approach of solving this is disliked for fundamental reasons - for some reasons I never fully understood, scaling factors in the settings seem to be disliked.
  • station that behave more relaxed with respect to station rating, if for a longer time no vehicle arrived - at least I managed to make stations behave like harbours with respect to this, again using a source code hack.
• I like the idea of infrastructure cost, but I dislike the current concept of infrastructure costs that grow non-linear based on the network size - again, I solved this topic by implementing a simple source code hack.

The question wether I (in terms of real world time) ever manage to implement more non-trivial patches than I already implemented is an open question, but this is about the roadmap I would have in mind based on my personal playing style.

[_dp_]

I mostly play on competitive mp servers, also configure and maintan some of them (CityMania). So I'd like to see

• Some fine-tuning and game mechanics improvements from competitive POV. E.g. some sensible way of distributing industry cargo among stations.
• Better building tools and more hotkeys for existing ones. More ingame information and stats. Gladly that's mostly solvable with compatible client.
• More control over the game for a server (and I guess that means GameScript though I don't rly care much about it since I do patching). Starting from basic things like being able to properly reject players action. Also various command/api improvements like ability to scroll players viewport or send him a popup message (not whole company).
• Ability to do various game configuration without writing or cloning newgrfs. E.g. highly configurable map generator where I can define things like "Every town needs to have exactly one 2x3 powerplant within a square from 18 to 22 tiles from town center and there should not be any other powerplants on map". Or change price of a vehicle in a newgrf (rigth now it requires cloning entire newgrf if price is set in callback).

[Wolf01]

I would like more control on eyecandy. I play mainly to make dioramas, but usually I end up with unrealistic things.
I made some extended tools for map editor which greatly improve the drawing (yes drawing) of terrain features such as valleys and peaks and even mountain ranges.
These tools are still at prototype stage but with some more effort and knowledge they might become reality and I would be glad if they will be in the game in future.
I would like an extensible state machine via newgrfs to allow creating different road, rail, docks/locks and airports features, with the ability to define the movement of the vehicle in a particular tile and the path to follow between multiple tiles.
I believe in NRT, if we'll do it right it might bring some freshness and variety to the game.

[Gwyd]

I'd just like to point out: if there are different amounts of cargo production throughout the day, to notice this you'd need to move all the passengers there in the first place.

[lcd_47]

This question comes up once in a while on various gaming forums. As far as I can tell, the outcome is pretty much always the same:

• Since OpenTTD is such an old game, everybody has a list of suggestions;
• Nobody ever cares about somebody else's list, but everybody feels strongly about their own;
• A subset of the features people want have patches, but the developers (see the other thread) have long ago declared said features useless or undesirable in some other way (which, by the way, is why they can claim with a straight face that no low-hanging fruits are still left for development);
• The thread eventually dies out, nothing ever gets done about any of the suggestions, and people move on.

But since you ask, here are my pet features I'd like to see in OpenTTD:

• Most of the UI tweaks in the CityMania patch mentioned above (and in the BTpro patch). I don't particularly care about city building or the competitive side of the game, but I really appreciate the zoning tool, the tool for watching other companies, being able to filter the list of industries by output and sort it by production, the tooltips for stations and industries, etc. etc. It does add a lot to the game play, I wouldn't conceive playing without the CityMania patch these days.
• A number of other minor UI tweaks, such as showing train length and current group in the details window, an option to turn tunnels transparent, etc.
• Better groups: being able to create groups by various vehicle stats and / or criteria, collapsible groups, financial stats per group, being able to set speed limits per group, etc.
• A purchase window that separates locomotives from wagons. Playing with sets like 2CC or NUTS with the official client is a pain from this point of view.
• A feature to upgrade all bridges to the highest speed available on the entire map.
• A feature to convert all lines connected to the current tile to another type of rails.
• Lists of depots and waypoints, to complement the list of stations.
• A number of unicorns: templates for replacing trains, less painful timetables, truly automatic auto-separation, a working day length feature.

Except for the unicorns and for converting lines connected to the current tile, I don't see any major problem with achieving any of the above (I actually already have patches for most of them). But I'm also equally sure all of them are also somebody else's useless garbage.

[andythenorth]

The thread eventually dies out, nothing ever gets done about any of the suggestions, and people move on.

That's why I didn't add my ponies to this list

But no harm in playing armchair wishlists I guess

[ic111]

What motivated me to this thread was that several people started talking about the possibility of forking, and now I was curious wether visions that make a fork necessary because of desired, but in trunk impossible (larger) features, exist out there...

I mean, e.g., I don't understand where the problem in adding some scaling factors to the settings is, but on the other hand, fixing this by writing a small patch on my own is that easy, that I don't regard that as sufficient reason for a fork.

[JGR]

A list of things that I'd personally like will probably end up suspiciously like a subset of the list of things already in my own patchpack .
I won't repeat that here.

Instead I'll make a slightly controversial proposal:

• Moving to C++11 and binning support for older platforms
• Refactoring to use C++11 features which tend to improve code quality (e.g. std::unique_ptr instead of manual new/delete malloc/free everywhere, using C++11 containers, better type safety).
• Adding some of the diagnostics/crashlog extensions in my patchpack which would be useful for development/debugging in general (some use C++11 features).

[leifbk]

I think that this topic really belongs in the "OTTD Suggestions" forum. Anyone looking for suggestions for improvements to the game should spend a good time browsing that forum. That being said, there are exactly two items that I'd dearly love to have in the vanilla game:

• A way to slow the game down, probably with a variable daylength.
• A timetable implementation that just says "spread this group of vehicles out evenly", without the current hassle of micromanagement each time a new bigger and faster vehicle comes along.

Oh, and by the way, fix the "variable width" of the depots when the number of vehicles of one type exceeds 100. But that's really a bug, and should be addressed as such.

[andythenorth]

Probably the wrong place, but variable daylength is one of the most requested features. I have never understood why the length of a day matters to gameplay. Can anyone explain it to me?

[kamnet]

Probably the wrong place, but variable daylength is one of the most requested features. I have never understood why the length of a day matters to gameplay. Can anyone explain it to me?

The dates and years are truly cosmetic, for the most part. It might make some difference if you're playing on an arctic map, where the snow line varies depending on the month. For me, though, I just don't like the fact that a year of game play passes and my train has hardly gone anywhere. I like the idea of having a scale of time in the game, it feels meaningful to me. But when it passes too quickly, then it feels meaningless. I like the daylength patches because I can slow that down, and it feels like something more significant is happening in the game. Or, I can speed it up. Whatever makes me feel happy.

And I think that's what it comes down to. It makes people happy.

[mrjack2]

Probably the wrong place, but variable daylength is one of the most requested features. I have never understood why the length of a day matters to gameplay. Can anyone explain it to me?

It massively eases capacity constraints allowing saner PAX transport especially, and it gives time to play "the whole map' rather than just bits of it.

[lcd_47]

Probably the wrong place, but variable daylength is one of the most requested features. I have never understood why the length of a day matters to gameplay. Can anyone explain it to me?

Because production, costs, inflation etc. are defined in terms of game's time. If you just slow down game time and leave everything else unchanged you get trains taking N times longer to load, N times longer to get anywhere etc. So you also need to scale a bunch of variables, which are spread all over the place. Then there are things that are time-based and need to be left alone (f.i. breakdowns), and they too are all over the place. So you can't just scale everything blindly. And finally there are interactions between the things that should scale and the ones that shouldn't, and you need to make sure these make sense as well. It gets hairy pretty fast.

[lcd_47]

A timetable implementation that just says "spread this group of vehicles out evenly", without the current hassle of micromanagement each time a new bigger and faster vehicle comes along.

I've been pondering about this on and off for a few years now, and I'm pretty sure using timetables for spreading out vehicles is the wrong approach. Timetables do have their uses, but they solve a different problem. This is probably not the place to discuss algorithms though.

[andythenorth]

...So you can't just scale everything blindly. And finally there are interactions between the things that should scale and the ones that shouldn't, and you need to make sure these make sense as well. It gets hairy pretty fast.

Aren't those all the reasons it shouldn't be implemented? I am curious about why people want it, it would add zero to my games, but it's so requested that I must be missing something

[lcd_47]

Aren't those all the reasons it shouldn't be implemented? I am curious about why people want it, it would add zero to my games, but it's so requested that I must be missing something

As far as I can tell it has to do with the timespan of the useful vehicles in the common NewGRFs. The "interesting" time period seems to be about 1850-2100. If you start earlier it becomes increasingly hard to stay alive. At the other end, you can go on past 2100 as far as you wish (provided you don't completely fill up the map), but nothing much "happens" after the last generation of vehicles have been introduced. I suppose that's why people want the earlier stages to last longer. Translate that to a multiplayer game where players are on different continents, and a day length patch allows everybody to enjoy, say, the game's 1920s without having to stay up at ungodly hours.

Another reason to want it is, of course, to shut up the crowd asking for it.

That said however, yes, the above are reasons why the existing day length patches are unlikely to be really fixed any time soon. It's a feature that would have been "easy" if the original design made provisions for it. But adding it now is probably a lot more effort that it's worth.

[andythenorth]

As far as I can tell it has to do with the timespan of the useful vehicles in the common NewGRFs.

Could just fix it in newgrf, with an option to multiply intro dates by [some factor] from [some base date]. Either per newgrf (parameter), or globally.

Or we could have a tech ladder, and introduce vehicles by tech level, not date (I am serious)

[lcd_47]

Could just fix it in newgrf, with an option to multiply intro dates by [some factor] from [some base date]. Either per newgrf (parameter), or globally.

Or we could have a tech ladder, and introduce vehicles by tech level, not date (I am serious)

And then, either way, you'll have the "realism" crowd up in arms. Personally I don't understand what "realism" even means in the context of OpenTTD and why it's so desirable, but to some people it seems to be a thing (and a huge one at that). I suppose I'm just lacking imagination...

[andythenorth]

And then, either way, you'll have the "realism" crowd up in arms.

Ach well. Given that the game DOESN'T EVEN USE PROPER PERSPECTIVE, I think we have bigger realistic fish to fry. I mean, the real world is not dimetric. So eh.

Some time ago (ok, 25 years), I pointed out a minor unrealism in a model train engine to the guy who had built it. He pointed out, politely but effectively that nor did it have a real diesel engine, a real toilet for the driver, or a real little person driving it. Point made.

Toys are toys. Games are games. Realism is long established as not a goal for OpenTTD.

[ino]

I am all for realism myself. I wouldn't oppose the tech tree (as long as there are cheats to disable them), but I would hate to scale the year. Even in most NewGRF, the train from 1920-2017 would correlate pretty okay with what we know of real world, and allow player to understand pretty quickly the power/speed of currently available vehicle. Scaling the year pretty much destroy that, and also messed up new vehicle expectation.

In regard to realism, I am currently playing the Japan-Tokaido scenario, and I am, as far as possible, trying to re-create the entire Japan Rail network in that region. It usually has to do with construction style though, with various self-imposed limits. I also try to also match the vehicle usage with real history, but it proves too hard because of timetabling change involve from faster train. With exact timetabling and routefinding restriction, OpenTTD can actually simulate real world train timetable quite okay. I know Simultrans can also do this, with various video available on YouTube.

[Note: on that map, 148 ticks per minutes seems to make it very close to real world. I usually play with daylength of 9-11 otherwise a freight train would take 5-7 years travelling from Tokyo to Osaka at 100km/h]