NotRoadTypes

[kamnet]

Although I would like to know why andy had an impression that it was otherwise.

NRT is not currently being worked on. Wolf said nothing to the contrary.

I think it was this part that made it sound like it was being worked on (emphasis mine):

question was one of the main problems which kept us to continue the development on the current draft, and we are discussing about the next implementation.

[Wolf01]

Sorry, I used the wrong adverb in that sentence (brain was in italian mode).
I meant that some problems made the development stuck because they are unsolvable the way it's implemented and we need to think about a different approach for a new version of NRT (ok, not so different, but same, yet different).

At current time we are discussing on different ways to achieve it which may be implemented even before NRT as other features of OTTD will benefit from that, NRT won't be a single patch to apply to trunk, but a queue of changes which can live on their own, laying the base for NRT and other unrelated features.

It may take time to have the "full" NRT merged because we need to address any pitfall we might found, make the base and then adapt NRT to that.

[NekoMaster]

Is it really that difficult to add NRT to the current Nightlies or Stable? Last I played it everything worked pretty well for me, I had no crashes or issues.

[Alberth]

Unfortunately, "working" is a superset of "the correct solution". The former is just checking the outside (the appearance of the feature), while correct solution also takes the internal structure into account, for example with respect to scaling, future extensibility etc.
This makes "working" a pre-condition of "correct", but you cannot draw conclusions about the correct approach from "working".

In any patch, you always first aim for "working". Once you have that, you take step back, ponder about how it got solved, and decide whether the internal structure makes sense. It is quite normal in my experience that the answer to the latter question is "no" on the first attempts. This means two things: 1. You didn't nail the problem (ie it is different than you expected it to be), and 2. You learned a lot about the true nature of the problem.

The latter gives surprises that takes time to understand, before you can take another attempt.

[NekoMaster]

Well what is stopping Road types from being a thing, I remember when railtypes was being implimented and now we have it.

Is there some underlaying problem with implimenting RATT to the stable versions? Like incompatibility with the code or instability?

I've been trying to get people to use RATT/NRT but some players are too scared to try a version of openttd that isn't stable or nightly because they might think I'm linking them to a virus or something.

[andythenorth]

Is it really that difficult to add NRT to the current Nightlies or Stable?

No it would be really easy, just a couple of git commands and it's done. It's not going to happen though

I can't be arsed to write a long essay why, but NRT is dead in current form, and if we ship it now, savegames will need to be broken in future when something better is done. And OpenTTD is hamstrung by Never Breaking Savegames, and even if we did break savegames that would Upset Some Players, which nobody wants to live through, so eh.

Meanwhile, a defensive attitude to security is good, but if players are relying on 4 letters in the trailing part of a url for security, they might be better off learning a little more

Literally, right now, the only different between NRT build, and NRT merged into nightlies is that the url changes.

https://www.openttd.org/en/download-ratt <- current url
https://www.openttd.org/en/download-trunk <- url if we merge it into trunk

I appreciate where they're coming from, I didn't touch nightlies or allow newgrfs in OpenTTD until I'd been playing for about 2 years. I thought they were all dangerous hacks. So eh.

[Wolf01]

Well what is stopping Road types from being a thing, I remember when railtypes was being implimented and now we have it.

And that was our fail... we implemented NRT like railtypes, just to find out there are more pitfalls, for example you can't have different railtypes in the same tile (ok, there is a patch for diagonal ones, but you can't cross 2 incompatible railtypes) while NRT need to make roads and tramways to live together.

A lot of features like railtypes, tramways, timetables, seem to be put in the game because at that time they "just work", and now we need to change a lot of old things to make new things work.

[KeldorKatarn]

Well good luck putting stuff in a game by the time you get it "perfect".

When I read stuff like "road catenaries or tram catenaries" I roll my eyes. Who the heck needs catenaries for normal roads... we didn't have that now, why do we need it then?
For 90% of the player base our there this would be about being able to build different looking roads (especially ISR type ones), MAYBE have speed limits and have certain roads the towns can't build houses next to. done. That's all most people want.

Yet this is getting turned into some kind of super-feature with everything being combinable with everything and of course than runs into issues.

With this approach I'm not ever seeing this go anywhere. Especially if people have the attitude "if we don't do it perfect now, we have work later". Well that's how it works in every single software project out there. You put a feature in that the customers want, do your best to make it nice, then find out there's other stuff needed or the original solution wasn't perfect, so you have to add to it or massively refactor it. If you want to avoid that additional work you best never develop any software that's actually being used. Perfect software exists only in academic laboratory environments or on the personal repositories of devs that never release anything to the public.

99% of the features out there that patch packs integrate are not perfect, have hidden bugs that are discovered over time, or not ideal UI or are otherwise not 'perfect' yet. But tons of players use those versions over the official one because the amount of added gameplay opportunities are just insane, even if imperfect.

Why was there even a need for different tram types? I'd have started with road types and keep just one tram type. Do things incrementally. Yes maybe that makes it necessary to write conversion code later for savegames if people then also want different tram types but honestly, I've yet to see that request anywhere. People want different road types for highways, and industrial roads. I've yet to see a single PLAYER ask for multiple tram types or for catenaries on roads. And then I see even more crazy stuff like "underground" being implemented with road types, despite the fact that that wouldn't be a feature but a hack, just like "wire" track types are.

I appreciate the crap out of the development of this, since at least someone tried after the request had been out for YEARS without anything happening.

But if this perfectionism is continuing like it is in most open source projects then it will have the same fate.. never see the light of day.

Transport Tycoon would never have been relased if it has to be perfect. The signals were inherintely broken and caused deadlocks all over the place, the pathfinder was primitive and found the wrong paths with complicated networks. And most of that made it into the first versions of OpenTTD. Signals were crap, pathfinders horrible, to this day the pathfinding of ships is attrocious, still needing buoys and even then getting lost all the time for a tick or two, the game time isn't disconnected from real time, which means trains move slower and slower the longer the game lasts, there's no constant tick time, the use of the C++ OOP language features is next to not present.... but guess what. It's a great game that tons of people play.

Software can't be made perfect in a laboratory. It needs to hit the user on a massive scale and then improved. That doesn't mean it should be buggy as crap when released but it means it should make incremental steps, trying out whether one thing works before adding the entire kitchen sink.

[andythenorth]

Yet this is getting turned into some kind of super-feature with everything being combinable with everything and of course than runs into issues.

I love a long critical post that shows just how much you have absolutely no idea what you are talking about regarding NRT. Like every point you make about perfectionism being the death of software is accurate, and every point you make about NRT is just backwards wrong.

Really motivates working on the game. Thanks so much

Why was there even a need for different tram types? I'd have started with road types and keep just one tram type. Do things incrementally.

It's useful armchair advice? Where's your github fork? I started with different tram types. That was what I wanted to add to my game, so I got off my arse and patched it, even though my C++ knowledge is primitive. I don't give 2 f*** what PLAYERS have asked for, it's not a customer service operation here.

[Auge]

When I read stuff like "road catenaries or tram catenaries" I roll my eyes. Who the heck needs catenaries for normal roads... we didn't have that now, why do we need it then?

Err, trolleybusses? *btw* With the argument "we didn't have that now, why do we need it then?" one could state every change unnecessary. We hadn't NewGRFs at the beginning. Why did we need them? We hadn't multiplayer at the beginning or track types or what ever you want. Why the heck we need it now when the original game didn't need it?

Why was there even a need for different tram types?

Because several people asked for it. For example a tram type for steam trams without catenary. IMHO this is comprehensible, isn't it? Why one should get different road types but not different tram types when in generally both are roads? Are you the one, who want's to answer the questions of players why different roads are possible but trams not?

Tschö, Auge

[KeldorKatarn]

Where's your github fork?

On GitHub, being actively played by people, thanks.

I don't give 2 f*** what PLAYERS have asked for, it's not a customer service operation here.

Good attitude for a game dev. Done talking to you. Same thing, never getting anything done, perfectionist, reacting in the most aggressive ways to any kind of criticism and whenever someone not involved in the projects asks for something or criticizes the reaction is "DO IT YOURSELF OR SHUT UP".

And this is why I don't work on any open source projects. Same attitudes and s*** characters all around.

[KeldorKatarn]

Oh yeah... and pretty funny when a guy that by his own admission has "primitive c++ knowledge" tells a professional developer that has 3 released (market release games that is) under his belt, that he doesn't know what he's talking about... nice try bud.

[andythenorth]

Done talking to you.

Except for your extra second post eh? And the extra comments you had to add after you're done talking to me.

Same thing, never getting anything done, perfectionist

Except we shipped a viable NRT fork, with officially built binaries, support from the newgrf toolchain, and multiple grfs from third party authors. And we've found some problems with it.

reacting in the most aggressive ways to any kind of criticism and whenever someone not involved in the projects asks for something or criticizes the reaction is "DO IT YOURSELF OR SHUT UP".

Pot, kettle. You post a hostile lecture on HOW WE SHOULD HAVE DONE IT, presuming that we have done everything wrong, whilst posting ass-backwards, plain wrong assertions about what the actual problems are with this implementation. Then you don't like to continue the debate?

Oh yeah... and pretty funny when a guy that by his own admission has "primitive c++ knowledge" tells a professional developer that has 3 released (market release games that is) under his belt, that he doesn't know what he's talking about... nice try bud.

I said you have no idea what you're talking about with NRT. I did make an edit immediately after posting to make that more clear, as it read like I was dismissing your software knowledge, which wasn't my intent. I'm standing by what I said though: you have no idea what you're talking about specific to NRT.

If we're going to have a ridiculous p***ing match, I've earnt my living from software and games for 16 years. I wrote games with 10s of millions of plays. I've built quizzes, educational software, ad networks, websites, workflow systems, project management tools and user interface libraries. My day job now is building paid software used by hundreds of organisations with thousands of admin users and millions of end-users. Users who pay us, and whose feedback we listen to carefully, and whose needs we work every day to meet. I write my own code and have also been employing programmers for many years. I also have a couple million downloads of OpenTTD content, made entirely for my own entertainment and not for any other purpose. And those are just the successful bits: the rate of failed projects, failed ideas, and massive personal mistakes has been spectacularly high. Just saying. I've learnt plenty

But I never learnt to not stay up late arguing on the internet.

You could have just asked what happened to block NRT or so, or how it could move forward, rather than posting a wall of text about what we're doing wrong. You even still could, eh?

[Gwyd]

I'm just going to add my 2 pence to this discussion: I have little-no knowledge to the background of NRT and the like. But what I do know is that this is one of the most active patches I can see, the other active ones being JGR and Joker's packs. What does this mean to me? As much as NRT may not be massively significant to me it shows that progress can still be made, and will be made by those who are daring enough to try.

[Dave]

Right, I'm quite disappointed that we appear to have very quickly descended into a slanging match. That's so 2008.

I won't be removing posts but this is a very public word of advice that personal attacks on members of the forum will not be permitted. This even applies where one may try to do so under the veil of a professional opinion. In any case, I'd expect a professional in any field to be able to identify sensible decision making and, even where one disagrees, to speak constructively with their colleague.

This topic is a valuable resource for devs, players and other interested parties and I do not intend to lock it. However, if the war of words continues I may be left with no choice.

Thanks,
Dave

[kamnet]

With the very real possibility that future changes to NRT will break savegames, I can understand the reason for NOT moving it to trunk.

With that said, given the limitations that exist now, I think it's nice and useful enough that I'd like to see patch packs develop a fork for NRT and let players have a go at it. Even if it eventually thins out and dies, it might be fun while it lasts. And if an update breaks savegames, those patch pack players understand that.

[SimYouLater]

With the very real possibility that future changes to NRT will break savegames, I can understand the reason for NOT moving it to trunk.

With that said, given the limitations that exist now, I think it's nice and useful enough that I'd like to see patch packs develop a fork for NRT and let players have a go at it. Even if it eventually thins out and dies, it might be fun while it lasts. And if an update breaks savegames, those patch pack players understand that.

I'd like to say I get the perfectionism behind NRT. It could make 32 Railtypes look like 3 to have exponential increases.

I also get that you can't wait forever. No release is bad enough in something crowdfunded, and even in big business software development. In an open source project it's hard to remember that time still equals money in many ways.

My conclusion is that I think the total backwards compatibility is no longer possible without killing this project.

There were things I didn't let go of which were holding me back because somewhere in the back of my mind I knew they were attached to something which would be my doom if I did let it go. I figured it out eventually, and separated what needed to be kept from what needed to stop. I'm almost literally the same age as Transport Tycoon itself, that can be taken as you wish.

What can't is that it isn't just people. The place I live in is dying because most people want it to be a small town locked in time where they can retire from the constantly-changing world. Without new industry, it will die. The local government is in agreement with the majority and has driven out everything from restaurant chains to a water park.

OpenTTD is being held back by compatibility reaching that far back. People will need to accept that new versions will break compatibility and they have to keep old versions to keep playing older games. Otherwise, Transport Fever and Mashinky won't kill this game, we will.

[andythenorth]

I also get that you can't wait forever. No release is bad enough in something crowdfunded, and even in big business software development.

I'm unclear on how that's relevant here If it helps, there is a release of NRT, its available here: https://www.openttd.org/en/download-ratt

In an open source project it's hard to remember that time still equals money in many ways.

Can you expand? I can't follow this argument as it stands.

My conclusion is that I think the total backwards compatibility is no longer possible without killing this project.

It's way off-topic for this thread, and probably should start a new one, but...

...for the record, I think we should drop total backwards compatibility.

But I do not have commit rights, and afaict, no devs agree with me.

Also I might be wrong.

1. Dropping backwards compatibility will not result in faster development. Backwards compatibility is not the reason that development is relatively slow now compared to 2008 or so.

2. My advice: I would be careful what I was wishing for. Currently we have ~100% guarantee on savegame backwards compatibility. Removing that guarantee takes the lid off Pandora's box.

• Playing the same savegame for the last x months or years? Maybe we just broke that, no way back.
• Been carefully crafting a newgrf for a long time? Maybe we just broke that, and now you have to redesign and refactor.
• Painstakingly created a scenario? Maybe we just broke that, and you have to start again from scratch.
• Written a popular AI or GS? Maybe we just broke that and you have to redesign and refactor.
• Running a server with specific settings and admin scripts? Maybe we just broke that, now you have to redesign and refactor.
• Maintaining a large patchpack? Maybe we just broke core assumptions, and the changes are overwhelmingly large, killing the patchpack.

Much as I favour breaking the 100% savegame guarantee, the risk is that it kills the game faster than anything else by alienating people using one of the content APIs.

3. I want to drop backwards compatibility so we can clean up the user interface / gameplay experience, and simplify some code, at the cost of dropping some features. There would be some vocal players who would hate this. The relative drama around disabling train-flipping-in-depot shows how difficult it is socially to remove even small features. I have in mind removing big features.

4. Dropping backwards compatibility wouldn't get NRT into trunk. Unless someone is a clown, why would they willingly wear clown shoes in public? NRT is currently clown shoes. Why jam it into trunk, knowing full well that it's broken?

So eh.

[Leanden]

If i may pose the question then Andy. Why worry about making the changes in trunk?

The game is released under a GPL licence, and evidentally development is somewhat stagnant. Why not make a full on branch which becomes a Trunk of its own.

OpenTTDX.

The next evolution of OpenTTD. For the purists they can keep going with the main trunk, while those of us who want to see the game improve migrate to OpenTTDX

[andythenorth]

The game is released under a GPL licence, and evidentally development is somewhat stagnant. Why not make a full on branch which becomes a Trunk of its own.

Hasn't JGR effectively done this already?

One of the reasons I want to drop 100% savegame compatibility is that some things could then be stripped from trunk (how many pathfinders do we need? How many signal types?). Reduced complexity would make it a little bit easier to build and maintain patchpacks.