Version 2.0 - Look to the Future

[planetmaker]

Was there not a concept of replicating everything in TTDP?

Has there ever been?

[Rubidium]

Was there not a concept of replicating everything in TTDP?

No; just "when we take an idea from TTDPatch, do it in a way that we consider better". For example a drive through road stop can have three different owners in OpenTTD: the owner of the road stop, the owner of the road and the owner of the tram track (I don't know how it is implemented in TTDPatch, but I suspect it doesn't store three owners).

Custom bridge heads has been attempted, but with the last attempt trains fell apart when turning around... so that was never even near trunk ready. Another problem with CBH is what to allow and what not to allow on the bridgehead. Should stations be allowed? What about signals? What about half tile slopes?

With building on tunnels: how do we know that the tunnel graphics are designed to get the rail on them? Putting rail on the default tunnel entrances just looks ugly. Also, what should be allowed to be constructed on top of the entrance? How to store the different owners? Different railtypes? Roads? Stations?

If you consider all these things you're quickly running into the current map array's limits w.r.t. available space. Also different pieces/owners of rail with different "accessibilities" means massive surgery in the pathfinders to make them understand that.

So, we're not saying it won't happen... it's just quite tricky, brings a lot of work and apparantly none of the developers has had a real urge to write it yet.

[Survivor]

No, there is(as of yet)no variable slope steepness.

I mean......is multi-slope practical in the future of OTTD?

[Beengalas]

Thought of an feature that would be nice, if possible, yesterday while building a very long railroad. Building signals at the same time as one build the railroad. Possibly an undermeny to the railroad with options regarding the signals. Would save a heck load of time.

[Dave]

Was there not a concept of replicating everything in TTDP?

No; just "when we take an idea from TTDPatch, do it in a way that we consider better". For example a drive through road stop can have three different owners in OpenTTD: the owner of the road stop, the owner of the road and the owner of the tram track (I don't know how it is implemented in TTDPatch, but I suspect it doesn't store three owners).

Custom bridge heads has been attempted, but with the last attempt trains fell apart when turning around... so that was never even near trunk ready. Another problem with CBH is what to allow and what not to allow on the bridgehead. Should stations be allowed? What about signals? What about half tile slopes?

With building on tunnels: how do we know that the tunnel graphics are designed to get the rail on them? Putting rail on the default tunnel entrances just looks ugly. Also, what should be allowed to be constructed on top of the entrance? How to store the different owners? Different railtypes? Roads? Stations?

If you consider all these things you're quickly running into the current map array's limits w.r.t. available space. Also different pieces/owners of rail with different "accessibilities" means massive surgery in the pathfinders to make them understand that.

So, we're not saying it won't happen... it's just quite tricky, brings a lot of work and apparantly none of the developers has had a real urge to write it yet.

For the record, Ben_K designed some excellent graphics for build on tunnels, but thank you for the clarification.

[Zuu]

Thought of an feature that would be nice, if possible, yesterday while building a very long railroad. Building signals at the same time as one build the railroad. Possibly an undermeny to the railroad with options regarding the signals. Would save a heck load of time.

Sounds like you are not aware of all the signal placement tools. There is one which place signals at a given signal distance all way up to the next junction by just draging a few cm to give a direction and there is another which can go past junctions but only on straight rail as with that tool you have to drag the entire stretch.

http://wiki.openttd.org/Signals#Signal_Construction

[Bob_Mackenzie]

Brilliant!

[Beengalas]

Thought of an feature that would be nice, if possible, yesterday while building a very long railroad. Building signals at the same time as one build the railroad. Possibly an undermeny to the railroad with options regarding the signals. Would save a heck load of time.

Sounds like you are not aware of all the signal placement tools. There is one which place signals at a given signal distance all way up to the next junction by just draging a few cm to give a direction and there is another which can go past junctions but only on straight rail as with that tool you have to drag the entire stretch.

http://wiki.openttd.org/Signals#Signal_Construction

Yes, I am aware of that. What I mean was more when I choose the click n drag for railroad, to have the option in this one to, for example, put an normal signal every second tile at the same time. Just so I don't have to go back and do it all again. Of course one will have to go back for the special signal.

To clarify: FIrst raidroad option, and when clicking on one of the 5 possible tools for building a rail, another box of option appears which where you decide if and what type of signal you want to be placed with the rail.

[City Builder]

Multi Monitor Support. I'd love to be able to stuff many of the windows on my second monitor, would really clean up my main view. Maybe also a GUI revamp.

[dihedral]

you probably have a multicore system, why not use both by starting a local server, and connecting to that - all windows you need for stats, etc. you can open in the network client #2

[ElliottB]

I think infrastructure sharing could/should be integrated into the main game in a way that it can be toggled on and off easily. In advanced settings there could be a simple 'enable infrastructure sharing' and the options for it below. I am also for signals on bridges and tunnels,

Warning, madness follows:
The programmer and open source nut in me is for the separation of the Graphics engine, User Interface, and game code; or at least separation of the User Interface from the rest of the code. I could foresee a NoAI type approach to the UI hook up. The UI's structure is dated and limiting in what you can do, and I don't mean the look. I love the look of it, but I find that a lot of the patches that make changes to it are closer to hacks than real revisions. Taking what it currently is an making it into a true UI framework would be worthwhile especially if my further idea is done: making OpenTTD extend-able.

In my mind, I'd love OpenTTD to become easily extended. Currently for a feature to make it into the hands of an average player, it generally has to prove itself worthy of being added to trunk. I'm more towards an approach similar to CIV4, Multi Theft Auto, NS2, and so on. Essentially, make modifying of the game mechanics, the ui, and so on accessible in the same way NoAI works.

1) Restructure + Separate UI
2) Devise Squirrel API for accessing UI
3) Restructure Game code
4) Devise Squirrel API for accessing Game Code
5) Sacrifice a goat to the programming gods (Maintainers of OpenTTD)
6) ???
7) Profit

[City Builder]

you probably have a multicore system, why not use both by starting a local server, and connecting to that - all windows you need for stats, etc. you can open in the network client #2

Interesting, I've just tried that and it works really well. Thanks for the suggestion.

[JohnRus]

1. Passengers / mail with destination.
2. Underground building and view, subways.
3. Rotation of the scene, in 4 directions.
4. Extra large cities, possibility to edit cities per building, to design the real scenarios.
4.b. Possibility to compile special sprites into single scenario file.
5. Realistic city's roads construction, no road "cubes" etc
6. Realistic size of the airport landing line, now too small.
7. More detailed vehicles animation.
8. Pedestrians.
9. Road traffic.

10. C++, if it still on C )).

Big thanks, respect and good luck to the dev team)

[Lord Aro]

5. Realistic city's roads construction, no road "cubes" etc.

set the city road building tendencies in advanced settings

7. More detailed vehicles animation.

involved almost completely rewriting the source code, i believe

8. Pedestrians.

Too small to be seen normally, and involves re-writing the map array to be able to be put in anyway

9. Road traffic.

Try StreettrafficAI or TowncarsAI

[Beengalas]

Another idea came up: extend the possibility with replace vehicles. Earlier today I was going to add two more loco motives to all my train. I would have prefered an option that is like "I want to change all these trains, defined by loco, wagon and length, into this type of train". So, in my case, all coal train with this setting, being change into this setting.

(extremly tired, hope it makes some sence)

[trainmaster611]

I'm a little late to this topic but I felt that I had something to contribute. I see two fundamental problems with OpenTTD as it stands:

1) User-Friendliness - Right now this game isn't terribly catchy for a newbie. As said before the game mechanics are hard to catch onto so there needs to be a better learning curve. The game is understandable to those of us that have been familiar with the game for some time but there's still a lot of user-interface problems that make the gameplay less than smooth. Tying in with this is all the technical jargon (grf, opengfx, 32bpp, patch, tar, etc). While many of us understand it and how they facilitate gameplay, its a pain in the ass for someone who just wants to play the game or just wants a few addons.

2) Pace - The biggest problem I've encountered in with any OTTD game I've ever played is the disproportionate pace of the game. At the start of the game, the gameplay is somewhere between a drudging steady pace and a painful crawling pace depending on the difficulty. The general formula is you build a line with a single train and wait for ages (usually 7 game-years) as you wait for enough money to build some sidings/double tracks and a second train. Then there is the wait time before you can build the second train which is slightly shorter and the pattern continues. However, once you get to several $100 thousand and up, you will be inundated with money so quickly you can't spend it soon enough on new trains, new lines, or upgrades (and of course these will accelerate your profit growth even more). The game is just too slow at the beginning and there is no challenge at the end. This is going to have to be addressed.

[maquinista]

2) Pace - The biggest problem I've encountered in with any OTTD game I've ever played is the disproportionate pace of the game. At the start of the game, the gameplay is somewhere between a drudging steady pace and a painful crawling pace depending on the difficulty. The general formula is you build a line with a single train and wait for ages (usually 7 game-years) as you wait for enough money to build some sidings/double tracks and a second train. Then there is the wait time before you can build the second train which is slightly shorter and the pattern continues. However, once you get to several $100 thousand and up, you will be inundated with money so quickly you can't spend it soon enough on new trains, new lines, or upgrades (and of course these will accelerate your profit growth even more). The game is just too slow at the beginning and there is no challenge at the end. This is going to have to be addressed.

Some GRFs have very high prices for the latest vehicles.

1. Passengers / mail with destination.
2. Underground building and view, subways.
3. Rotation of the scene, in 4 directions.
4. Extra large cities, possibility to edit cities per building, to design the real scenarios.
4.b. Possibility to compile special sprites into single scenario file.
5. Realistic city's roads construction, no road "cubes" etc
6. Realistic size of the airport landing line, now too small.
7. More detailed vehicles animation.
8. Pedestrians.
9. Road traffic.

10. C++, if it still on C )).

Big thanks, respect and good luck to the dev team)

I like some of these features, but I think that They correspond to other game, maybe a "OpenLocomotion". This game could be a fork of OpenTTD, when OpenTTD was almost finished.

Realistic airport sizes could be done in part, if new GRF airports code is added in the official release.

[ThunderAI]

I'm not sure a true scale airport would be possible. The entire games scale is out of wack with "areas" of scale. Take the Hub airports for example. a real sized Hub airport is larger than most cities in real life and finding a place to put that in game could be very hard if the airport has to be square?

Is Newgrf airports even being worked on anymore. My Auto-Update hasn't updated the source in what seems like years.

[Yexo]

I'm not sure a true scale airport would be possible. The entire games scale is out of wack with "areas" of scale. Take the Hub airports for example. a real sized Hub airport is larger than most cities in real life and finding a place to put that in game could be very hard if the airport has to be square?

Airports don't have to be square

Is Newgrf airports even being worked on anymore. My Auto-Update hasn't updated the source in what seems like years.

Yes, just because there are no new binaries doesn't mean there is no work going on.

[ThunderAI]

I'm not sure a true scale airport would be possible. The entire games scale is out of wack with "areas" of scale. Take the Hub airports for example. a real sized Hub airport is larger than most cities in real life and finding a place to put that in game could be very hard if the airport has to be square?

Airports don't have to be square

Is Newgrf airports even being worked on anymore. My Auto-Update hasn't updated the source in what seems like years.

Yes, just because there are no new binaries doesn't mean there is no work going on.

Airport don't have to be a closed shape in game? why are they all then?

Hum... I'll have to look into the development and see whats new