Transport Tycoon Forums

kamnet wrote:Create your own fork

Not what my suggestion was about at all, and I certainly do not have the skills to manage an entire fork of a project the size of openttd.
Furthermore, doing so would create a rift between the purists wanting to keep compatibility, and those happy to move away from it.

Redirect Left wrote:That isn't how any serious development works, you can't just decide you want to do something, and every one (the other devs) goes "yes, do it!". I'm involved in a few developing things, and i'd be seriously concerned for the integrity of openttd if that is how the dev cycle works.

Yup, spot on, agree with you completely

That's why I wrote this...

andythenorth wrote:All you have to do is earn commit rights, and make the changes

Redirect Left wrote:doing so would create a rift between the purists wanting to keep compatibility, and those happy to move away from it.

The rift is there, anything you do isnt going to create that rift, but i suspect it would alleviate some of the issues.

Talk is cheap, code much less so.
An implementation of a feature, even if imperfect or incomplete, is far more valuable than discussion/suggestions.

If you want a feature or lack thereof and can implement it, you should just do so.
Having something executable, even if not/never in trunk, gives something concrete and potentially actionable to have future discussions about.

Redirect Left wrote:

kamnet wrote:Create your own fork

Not what my suggestion was about at all, and I certainly do not have the skills to manage an entire fork of a project the size of openttd. Furthermore, doing so would create a rift between the purists wanting to keep compatibility, and those happy to move away from it.

Well, if not for you, then for somebody else. And to be fair, we already do have one fork of OpenTTD that is steadily plodding along. But even with that fork, great care is still being taken for backwards compatibility.

Leanden wrote:The rift is there, anything you do isnt going to create that rift, but i suspect it would alleviate some of the issues.

Yep, agreed. And I think at this point most OpenTTD players no longer care about backwards compatibility with TTD. Nobody is playing 20 year-old save games. If they want to do so, they can open up any old version of OpenTTD and continue to play it. And there's no reason why we can't have both BC and non-BC versions. If there are future developments which can be ported from one to another, huzzah.

I'm confused here: would that mean the non BC version would need to be compatible with BC? I'm no expert here, but that sounds very hard...

kamnet wrote:I think at this point most OpenTTD players no longer care about backwards compatibility with TTD. Nobody is playing 20 year-old save games. If they want to do so, they can open up any old version of OpenTTD and continue to play it. And there's no reason why we can't have both BC and non-BC versions. If there are future developments which can be ported from one to another, huzzah.

If savegame compatibility should be broken at some point, I think that version 2.0 would be the logical place to do it.

leifbk wrote:

kamnet wrote:I think at this point most OpenTTD players no longer care about backwards compatibility with TTD. Nobody is playing 20 year-old save games. If they want to do so, they can open up any old version of OpenTTD and continue to play it. And there's no reason why we can't have both BC and non-BC versions. If there are future developments which can be ported from one to another, huzzah.

If savegame compatibility should be broken at some point, I think that version 2.0 would be the logical place to do it.

Well, if you wanted to just jump from 1.7.x to 2.0.0, sure. But where OpenTTD updates yearly, I personally don't want to wait two and a half years to do that. But, then again we did jump from 0.7.x to 1.0.0, so...

I really don't think it matters what version number a feature gets implemented under. Really the only purpose of having a version number is so that you can have an accounting of what's changed.

kamnet wrote:

leifbk wrote:

kamnet wrote:I think at this point most OpenTTD players no longer care about backwards compatibility with TTD. Nobody is playing 20 year-old save games. If they want to do so, they can open up any old version of OpenTTD and continue to play it. And there's no reason why we can't have both BC and non-BC versions. If there are future developments which can be ported from one to another, huzzah.

If savegame compatibility should be broken at some point, I think that version 2.0 would be the logical place to do it.

Well, if you wanted to just jump from 1.7.x to 2.0.0, sure. But where OpenTTD updates yearly, I personally don't want to wait two and a half years to do that. But, then again we did jump from 0.7.x to 1.0.0, so...

I really don't think it matters what version number a feature gets implemented under. Really the only purpose of having a version number is so that you can have an accounting of what's changed.

Yes, version numbers matter, like when Python broke compatibility big time between version 2 and version 3. It may be expected that compatibility breaks between major version numbers.

I didn't say anything about a time frame, but I believe that everybody should start thinking ahead about what we'd like to get incorporated into OpenTTD 2.0, and start planning for it.

Hello

kamnet wrote:

leifbk wrote:If savegame compatibility should be broken at some point, I think that version 2.0 would be the logical place to do it.

Well, if you wanted to just jump from 1.7.x to 2.0.0, sure. But where OpenTTD updates yearly, I personally don't want to wait two and a half years to do that. But, then again we did jump from 0.7.x to 1.0.0, so...

It's not mandatory to let version 1.9 be followed by 2.0. A not backward compatible version 2.x can be accompanied by a backward compatible version 1.10, 1.11 and so on.

Tschö, Auge

Auge wrote:Hello

kamnet wrote:

leifbk wrote:If savegame compatibility should be broken at some point, I think that version 2.0 would be the logical place to do it.

Well, if you wanted to just jump from 1.7.x to 2.0.0, sure. But where OpenTTD updates yearly, I personally don't want to wait two and a half years to do that. But, then again we did jump from 0.7.x to 1.0.0, so...

It's not mandatory to let version 1.9 be followed by 2.0. A not backward compatible version 2.x can be accompanied by a backward compatible version 1.10, 1.11 and so on.

Tschö, Auge

Of course. But OpenTTD's versioning scheme has been to make a major release around April 1 of every year, and that version release number corresponds with the year. 1.0.0 was 2010, 1.1.0 was 2011... 1.7.0 was 2017. I'll grant you, it's all novelty, but I don't see where the devs are going to break with that pattern.

kamnet wrote:But OpenTTD's versioning scheme has been to make a major release around April 1 of every year, and that version release number corresponds with the year. 1.0.0 was 2010, 1.1.0 was 2011... 1.7.0 was 2017. I'll grant you, it's all novelty, but I don't see where the devs are going to break with that pattern.

Only one of those, 1.0.0, was a major release. The others are point releases.

I'd say, make a v2 branch now, and rewrite the (insert four-letter word here) out of it, and don't care about breaking compatibility. Pull in all the good stuff that users have been asking for. I'll be happy as a translator and beta-tester.

kamnet wrote:Of course. But OpenTTD's versioning scheme has been to make a major release around April 1 of every year, and that version release number corresponds with the year. 1.0.0 was 2010, 1.1.0 was 2011... 1.7.0 was 2017. I'll grant you, it's all novelty, but I don't see where the devs are going to break with that pattern.

While it's a convenient mapping, I don't believe it was designed that way, it just happened by coincidence.

As for 2020, don't know what will happen, but will be interesting to find out

Hello

kamnet wrote:

Auge wrote:

kamnet wrote:Well, if you wanted to just jump from 1.7.x to 2.0.0, sure. But where OpenTTD updates yearly, I personally don't want to wait two and a half years to do that.

It's not mandatory to let version 1.9 be followed by 2.0. A not backward compatible version 2.x can be accompanied by a backward compatible version 1.10, 1.11 and so on.

Of course. But OpenTTD's versioning scheme has been to make a major release around April 1 of every year, and that version release number corresponds with the year. 1.0.0 was 2010, 1.1.0 was 2011... 1.7.0 was 2017.

I think, this (version number vs calendar year) was a coincidence. Once there was a more or less complete OpenGFX-set. That hovered the version number to 1.0 (independence from original game grafics).

But that was not my point. The version number of OpenTTD (and any other software) could climb from 1.9.x to 2.0, but that's not mandatory (as said). It also could raise to 1.10 (and so on). So there is the possibility of a 1.x branch (with x > 9) with backward compatibility and beside it a 2.x branch without this compatibility. Will this happen? Who knows?

Tschö, Auge

kamnet wrote:Nobody is playing 20 year-old save games.

That's not true. I still fire up my original version of TTD from time to time for nostalgic reasons. Virtual machines are a thing of beauty. Being able to retrieve those games from years ago and trying again (and again) to build it better can be fun, too. Especially when you have to deal with all those limitations that OpenTTD has made obsolete. Admittedly, I haven't done it in awhile, but the games are kept on my not-cold file server because they're definitely not cold data. However...

kamnet wrote: If they want to do so, they can open up any old version of OpenTTD and continue to play it.

Exactly. And I think OpenTTD has reached the point where backward compatibility can now be honorably retired. We can have the best of both worlds with what we have now. Old-school is preserved well enough that historical "data" can be accessed and...played. That gamer who's had the Civilization game running for literally years and years I think exemplifies the idea behind this ability to preserve and play forever, and I think that's a good thing.

Redirect made a comment about how difficult it is to get things into trunk - that patches are often used instead. I've always assumed that OpenTTD became tightly regulated to ensure the most basic aspects of the game are strictly preserved. There are certain aspects of the game that are cornerstones: the quasi-isometric/3D-from-2D layout, the "curved track is for Locomotion" limitation, etc. If you change it too much, it's not what I call a pure reincarnation of TT. It becomes something else. And that's where we're at right now. "Stifling further developments and improvement" to me is just another way of saying that v1.9 should be the last version whose intent is to strictly conform to TT's spirit. I feel like we're reaching the limit of what can be done without working beyond that.

In no way is this me being critical of anyone's work or anyone's ideas of what OpenTTD is, should be, or might become. It is simply an observation from someone who - if development stopped forever tomorrow morning - would still be left with something he will enjoy the rest of his life and be grateful for those who made it possible. I think that's the finest compliment you could ever give to any group of people who donate so much and receive so little in return.

-Marc

AntoninKyrene wrote:It is simply an observation from someone who - if development stopped forever tomorrow morning - would still be left with something he will enjoy the rest of his life and be grateful for those who made it possible. I think that's the finest compliment you could ever give to any group of people who donate so much and receive so little in return.

Nice comment, well expressed

I have never played TTD,but if I could bring my 1995 Original-TT games into a DOSbox session that would work with my FreeBSD,I'd like that.
But I'd also like to see OpenTTD flower beyond what could be done before.
It's not that hard to run different applications.

andythenorth wrote:

AntoninKyrene wrote:It is simply an observation from someone who - if development stopped forever tomorrow morning - would still be left with something he will enjoy the rest of his life and be grateful for those who made it possible. I think that's the finest compliment you could ever give to any group of people who donate so much and receive so little in return.

Nice comment, well expressed

+1

I think many people think that way. Maybe that’s lost in the clamour for NEW NEW NEW all the time.

Not easy to improve on perfection. One of the many reasons this game is still being played.

How many other games that started out with the DOS operating system that are still being played today basically still using the same design and play style.

How many games and software that makers suppose to made improved versions and made the program worse.

Yahoo is one I can remember .. was a great chat program using cam and able to type messages to friends .. they improved it and now can not use cam. So was that really a improvement?


Cheers all

leifbk wrote:

kamnet wrote:But OpenTTD's versioning scheme has been to make a major release around April 1 of every year, and that version release number corresponds with the year. 1.0.0 was 2010, 1.1.0 was 2011... 1.7.0 was 2017. I'll grant you, it's all novelty, but I don't see where the devs are going to break with that pattern.

Only one of those, 1.0.0, was a major release. The others are point releases.

I'd say, make a v2 branch now, and rewrite the (insert four-letter word here) out of it, and don't care about breaking compatibility. Pull in all the good stuff that users have been asking for. I'll be happy as a translator and beta-tester.

I would call 1.2.0 and 1.4.0 major releases. 1.2.0 was the first time that major patches have been implemented (in TerraGenesis as there were more options to generate a map) and 1.4.0 was the CargoDist release. There were also other releases like the more map heights, and auto rail.