Version 2.0 - Look to the Future

[Eddi]

from TTDP (might as well bring everyone to work on one game)

that would be cool, if there was still anyone working on TTDP...

[TSH]

from TTDP (might as well bring everyone to work on one game)

that would be cool, if there was still anyone working on TTDP...

Well I know a lot of people still play it just for features like CBH, maybe those players would work on OTTD if they weren't playing TTDP? I think the important thing would be having the features that attract people to that game in OTTD.

[Supercheese]

Well I know a lot of people still play it just for features like CBH, maybe those players would work on OTTD if they weren't playing TTDP? I think the important thing would be having the features that attract people to that game in OTTD.

http://www.tt-forums.net/viewtopic.php? ... 20#p994089

So far, these are the main new features provided by the patch:

• Parallel tracks of different railtypes on the same tile
• Custom road bridgeheads
• Custom rail bridgeheads, including signals

[TSH]

Well I know a lot of people still play it just for features like CBH, maybe those players would work on OTTD if they weren't playing TTDP? I think the important thing would be having the features that attract people to that game in OTTD.

http://www.tt-forums.net/viewtopic.php? ... 20#p994089

So far, these are the main new features provided by the patch:

• Parallel tracks of different railtypes on the same tile
• Custom road bridgeheads
• Custom rail bridgeheads, including signals

I know they are available from patches, along with auto spacing and cargodist but getting them in trunk would be an improvement I imagine, if say the version 2.0 aim was complete the C++ transition and code all major features - like the new map array and newroads/aiports etc.

[Alberth]

the version 2.0 aim was complete the C++ transition

Huh? What makes you think the C++ compiler used to compile the program accepts anything else than C++?

Perhaps you are confusing "being object-oriented" with "being C++"? These are completely unrelated, you can program in an object-oriented way in any language.

[TSH]

the version 2.0 aim was complete the C++ transition

Huh? What makes you think the C++ compiler used to compile the program accepts anything else than C++?

Perhaps you are confusing "being object-oriented" with "being C++"? These are completely unrelated, you can program in an object-oriented way in any language.

I was under the impression that most parts were in C++ while some were still in C? I'll admit code languages are not my strongest point so I could be mistaken.

[Alberth]

the version 2.0 aim was complete the C++ transition

Huh? What makes you think the C++ compiler used to compile the program accepts anything else than C++?

Perhaps you are confusing "being object-oriented" with "being C++"? These are completely unrelated, you can program in an object-oriented way in any language.

I was under the impression that most parts were in C++ while some were still in C? I'll admit code languages are not my strongest point so I could be mistaken.

What worries me mostly here is that you make claims about the state of things without proper understanding what you exactly mean to say by your own statements.

[TSH]

Huh? What makes you think the C++ compiler used to compile the program accepts anything else than C++?

Perhaps you are confusing "being object-oriented" with "being C++"? These are completely unrelated, you can program in an object-oriented way in any language.

I was under the impression that most parts were in C++ while some were still in C? I'll admit code languages are not my strongest point so I could be mistaken.

What worries me mostly here is that you make claims about the state of things without proper understanding what you exactly mean to say by your own statements.

Perhaps I do mean 'object-oriented', I'm only a front end designer so my knowledge of the back end is limited to what I pick up from working with developers. Am I correct in thinking that all the stuff in C is behaving as intended when compiled in C++ and need not be modified (or be a target for 2.0)?

[Alberth]

Perhaps I do mean 'object-oriented', I'm only a front end designer so my knowledge of the back end is limited to what I pick up from working with developers. Am I correct in thinking that all the stuff in C is behaving as intended when compiled in C++ and need not be modified (or be a target for 2.0)?

C made a separation between programs and data, leaving it to the developer to organize that relation. For larger programs to work, a developer did of course organize that in some systematic way. That is what we now refer to as "being object-oriented". Newer languages come with language primitives such as classes and inheritance to give the developer more support to handle the relation.

These primitives are nicer for programming in general, but they come at a cost. The implementation has to follow the rules of the language, which in practice means you have to perform additional checks in which situation you are, or you have to store additional meta-data next to your 'real' data. In about 90-95% of the cases this is no problem.
In the remaining cases (and the map in OpenTTD is one of those exceptions), the additional checks and storage becomes significant enough to have an impact on performance or size. In these cases we prefer to use our own way of handling the relation between program and data, rather than letting the language primitives handle them.

So yes, there are parts in OpenTTD which have their own way of organizing data and program. It's still object-oriented, it's just a different form with better performance and storage requirements than what the language can provide "out-of-the-box".
Until a even better solution is found, this is how we want to keep it; we see no point in degrading performance and increasing storage requirements just for adhering to how C++ thinks object-orientation works.

[2457]

actualy i personaly do not like object oriented programming.
bloated, and way too slow...

oop is just a tool, and any tool can be mis-used.
i think oop is a tool that can be way too easyli mis-used.


but, i think those who actualy do the coding of ottd can choose the tools they use.
whatever it be.

[PikkaBird]

Gentlemen, the Oracle has spoken.

[kyosuke1989]

I think that major features until Version 2.0 could be (not in order trunk-merged):

- Infrastructure sharing (needs some thinking yet)
- Re-re-reworked C&P (clipboard), at last. It should help to make shift from current micromanagement of infrastructure developing in games played to macromanagement of building infrastructure lines (you know, it's very frustating to build the same type of railyards and line over and over again manually), and that way encourage players to build larger transportation networks with less work. And then the micromanagement level should be shifting to finding the "nodes" for transportable passengers and goods, when using for example, FIRS as industry set. The shared orders did save unseen amounts of micromanagement on developing vehicles, and this C&P should do same for infrastructure.
- Custom bridgeheads. The current placement restricts developing of "good flowing" network in small spaces and inside cities.
- Signals on tunnels and bridges. The current tunnels and bridges are really restricting and limit the gameplay very much, and require several paraller bridges and tunnels where there is long bridges and moderate amounts of trains.
- Chunnel
- More height levels. Those currently maximum levels aren't really challenging in terms of gameplay, resulting of gigantic levelling of terrain in later game. It wouldn't be so easy and cheap anymore after that.
- Larger maps. Would be able to enjoy heightmaps with better resolution than nowadays. And challange to even sparser maps in terms of towns and industries!

Of course, those patches need at least reviewing work in order to reach trunk, and usually futher developing, and that takes time. Good things come when the time is.

[Rubidium]

1) adding that many features in a single release is bound to give it a really slipping release date;
2) you forgot the undo knob;
3) 2.0 is planned for 2020, so I hope you can wait that long.

[kyosuke1989]

1) adding that many features in a single release is bound to give it a really slipping release date;
2) you forgot the undo knob;
3) 2.0 is planned for 2020, so I hope you can wait that long.

Whoops, i meant until 2.0.

[fabca2]

3) 2.0 is planned for 2020, so I hope you can wait that long.

Yeah? 2020 to have all these feature?!...
I say OK.

It's not that far,
7 years... at the scale of TTD/Ottd history it's not an issue.

I'm ok to wait 7 more year to get all that (plus cargo dist).

[V453000 :)]

: DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD

- Custom bridgeheads. The current placement restricts developing of "good flowing" network in small spaces and inside cities.
- Signals on tunnels and bridges. The current tunnels and bridges are really restricting and limit the gameplay very much, and require several paraller bridges and tunnels where there is long bridges and moderate amounts of trains.

Yeah, this totally restricts the gameplay, in fact it makes TTO/TTD/OpenTTD such a bad game that nobody is playing it and nobody ever did.

Anyway, on a more serious end, custom bridge heads would be cute, but argument that it prevents you from building good flowing network is just ridiculous. Obviously it would be easier to stuff more things in a tight place, but well flowing whatever is obviously not anyhow disturbed by a lack of 1 tile at each bridge end. See for example http://wiki.openttdcoop.org/File:Psg207_V.png and tell me how bridges are a restriction there. There are about 83% passengers transported by the way so I wouldnt call that too restricted.
Still, it is just a feature which would make more options available for building which is never a bad thing.

Signals on tunnels and bridges are a bigger problem from my point of view.

Consider the following: B/T without signals cause
- caring how long the bridge is
- caring how much space there is for it
- caring how many bridges there are (moving the problem to the wide dimension too)
- granted you have high enough land, you could almost always dig a tunnel under it with 100% line throughput. Stupidly easy as it gets rid of any space management you have to make.

Consider the following: B/T with signals cause
- you to build a bridge/tunnel

As you can clearly see, the feature would eventually not add anything to the game. You can build bridges and tunnels already. The problem is, it would make bridges and tunnels behave the same way as normal piece of straight rails.
Therefore it removes the variety in a sense that it makes two differing things behave the same way.

In my opinion TTO/TTD/OpenTTD are games which are based on unbelievable amount of possibilities and logical connections between basically everything, and gives the player a milllion and one questions on how to solve the throughput problem/train jam he is having. Removing those questions is like slowly killing the game.

[2457]

lack of PBS signals would limit the game in a verry similar way, YET, they are implented.
A good network could be built without the PBS signals, the lack of PBS did not make the game unplayable,
but having PBS is better.

Having signals on bridges and in tunnels would make it even better, and less restrictive.
While the lack of it does not ruin the game.

I would like the signals on bridges and in tunnels.
I would like diagonal tunnels and bridges.

[kormer]

This debate begs an important question, if a patch already exists, is proven to be stable in both single and multiplayer, and is popular with the community, what more is needed to justify including it in trunk?

[V453000 :)]

Adding PBS to the game adds a new element of signals without removing anything.

You can argue that it makes noobs play only with PBS and thus not discover the real problems/solutions their network has, which would be more obvious with block signals - but that is just how people use the feature, while the feature itself is great by all means.

Signals on bridges is a completely different feature because it does not add anything, as I described above.

[Pyoro]

Huh, I don't get why you're against this. What would stop you from just not building signals on bridges and let everyone else play like they want?
Might even be an option to be turned off (like build on slopes. I've never seen anyone having that one disabled, but hey, it's possible...)