Mostly Wolf01 & froschYNM wrote:All that said, good work andy !

Moderator: OpenTTD Developers
Mostly Wolf01 & froschYNM wrote:All that said, good work andy !
andythenorth wrote:+1Wolf01 wrote:I think this really goes out of the scope of NRT
I can't imagine NRT including a rewrite of vehicle movement or pathfinding code. Too much change in one patch, even if somebody were interested in working on it (afaik, nobody is).
Your points are indisputable. I do recommend pacing it but still doing a much simpler rewrite before integration into stable. If catenaries are unworkable as a rewrite, simply detect which catenary is from a newer xtype. If the roadtype became available in 1900 and the tramtype in 1950, and both use catenary, only the tramtype catenary is displayed. If the roadtype is upgraded to one with catenary from 2000, the road catenary is displayed over the tramtype catenary. Use the same strategy for conflicting drive-through stop graphics, enabling stop graphics by roadtype and tramtype.YNM wrote:On the point of one-way trams, and subways : I know that these are a thing. But firstly, I think they should be in a separate patch. I mean, let's be honest, if you can have one-way trams, why not intrinsic one way rails ? What I think we should do is drawing the limits between trams and trains; personally I think trams are those that doesn't need a (visible) signal equipment. There's no reason whatsoever in trying to have one way trams, esp. on the "scale" of OpenTTD. This also kind of renders subway-trams in OpenTTD to be more of a hack, which it really is, as in reality they're trains underground. But if anyone want to make a new implementation of it, please go ahead.
On the graphics : I know it's a jumbled mess so far, but I guess we have to pace in slowly. Correct catenaries, for example, isn't even what you get in rails. Personally I don't see a problem of having excess catenaries or catenaries not being drawn on a short scale (I prefer excess however when coming to road/tram vehicles).
All that said, good work andy !
No problem. Will do. The explanation there is both much shorter and simpler than the original thing, just try to keep in mind what cloud be done with NRT. I'd suggest doing the increase and types after it's solidified, after that even extratypes might be out of the scope.andythenorth wrote:@SimYouLater my (kindly intended) advice is to guard your mental health, and not worry too much about theoretical specs for retro transport gamesOpenTTD is a long way down any list of important things
Yes, we have in mind what could be done with NRT. NRT is about adding different graphics and optionally different features (speed limit, catenary for road, (dis)allowing building mixed types as combinations of both road and tramway, (dis)allow building railway crossings, (dis)allow usage of the *type from a vehicle of a different *type), maybe some edge case features like different tractive effort for vehicles based on type of traction (wheels vs tracks), disallowing building crossings or forbid cities to build along a road if there's only that road (like disabling houses along an highway or some industrial path).SimYouLater wrote:just try to keep in mind what cloud be done with NRT
SimYouLater wrote:The explanation there is both much shorter and simpler than the original thing, just try to keep in mind what cloud be done with NRT. I'd suggest doing the increase and types after it's solidified, after that even extratypes might be out of the scope.andythenorth wrote:@SimYouLater my (kindly intended) advice is to guard your mental health, and not worry too much about theoretical specs for retro transport gamesOpenTTD is a long way down any list of important things
Oh, not harsh at all. As you can see with the removal of the off-topic stuff, I came to a belated realization that even "utilitytypes" were out-of-scope.Wolf01 wrote:Yes, we have in mind what could be done with NRT. NRT is about adding different graphics and optionally different features (speed limit, catenary for road, (dis)allowing building mixed types as combinations of both road and tramway, (dis)allow building railway crossings, (dis)allow usage of the *type from a vehicle of a different *type), maybe some edge case features like different tractive effort for vehicles based on type of traction (wheels vs tracks), disallowing building crossings or forbid cities to build along a road if there's only that road (like disabling houses along an highway or some industrial path).SimYouLater wrote:just try to keep in mind what cloud be done with NRT
Sorry if I seem a bit harsh, but I don't think we'll ever see the "extra" features on NRT, so it's a bit useless to continue to discuss them in this place.
Features such as traffic lights, underground stuff, multi level transport ways (like the hanging monorail), different stations, roundabouts and ramps, etc... are just out of the scope of this patch and might be added in future with different patches, most of them, if not all, require changes to the state machine of vehicle movement, and it would be really cool to have it done with grfs too.
For other transport types, like pipes or electric wires or even belts (you called them utilitytypes) I would go for a separate patch not based on vehicles at all, feel free to open a topic for utilitytypes and discuss them there.
Here we could discuss about one thing which popped out on IRC: we were thinking about changing how NRT works (internally) in a way to spare some more bits in the map arrays and have exponential combinations of types, and a way which should ease the work of grf devlolopers (not-a-typo) which already made some proof of concept NRT grfs and raised various questions about how NRT works.
This doesn't mean that the scope of NRT will change, only changes how it does it, so no new features.
Well, actually yes. Let me elaborate.SimYouLater wrote:I'm sure luxtram would be thrilled if custom stops were made possible.
Ah, well. Is making it easier for someone to integrate a custom stops patch with NRT in scope? Just a thought.andythenorth wrote:NewGRF roadstops are not in scope for NRT - there is nothing connecting the two except they are both road features
Does the custom stops patch exist somewhere? I haven't seen it announced, nor a suggested newgrf spec for it.SimYouLater wrote:Ah, well. Is making it easier for someone to integrate a custom stops patch with NRT in scope? Just a thought.
I haven't seen any one either, but it would certainly be nice, for those of us who enjoy playing with trucks, if for instance a quarry truck stop could appear remotely realistic with a bulk loader contraption. Just keep the idea simmering on the back burner, guys.andythenorth wrote:Does the custom stops patch exist somewhere? I haven't seen it announced, nor a suggested newgrf spec for it.SimYouLater wrote:Ah, well. Is making it easier for someone to integrate a custom stops patch with NRT in scope? Just a thought.
Hard to answer thatKeldorKatarn wrote:How far is the feature btw? Are there still major problems?
Since it's obvious this isn't getting into Trunk without further improvement that you can't do, is it better to ask if it should be integrated with patch packs now?andythenorth wrote:Hard to answer thatKeldorKatarn wrote:How far is the feature btw? Are there still major problems?![]()
NRT is not currently being worked on. What's done is done, and seems to work. The github fork is maintained against OpenTTD trunk, so it's not falling behind and rotting. The OpenTTD compile farm builds binaries.
Links to binaries and github are in the first post of this thread, although you may know that already
I don't really understand the question. If patch packs want to integrate it, they will. The code is on github, it's currently maintained against trunk. I'm confused about how to answer the question tbhSimYouLater wrote:Since it's obvious this isn't getting into Trunk without further improvement that you can't do, is it better to ask if it should be integrated with patch packs now?
Well, no the devs just aren't going to slap it in. People who want to try it have been able to do so for the last several months. To be fair, you've not heard a lot about it, and I think that's because a lot of people really don't like having multiple OpenTTD installs, and they just may not know about it. But I think if there were any major issues that those would have been brought up on the forums already.SimYouLater wrote:Since it's obvious this isn't getting into Trunk without further improvement that you can't do, is it better to ask if it should be integrated with patch packs now?
So you were working on that code overhaul you mentioned.Wolf01 wrote:NRT is just a draft of what it should do once complete, and we published that to gather informations on what works and what should be changed.
Even if we get more attention by the standard users I don't think is the right thing to do, I don't want them to get used to something which might end up really different in future, specially the user interface as the GRF part is almost complete and it will stay that, and that was maybe the most important part, to see what GRF authors were able to do with the draft version of it.
BTW I think that it works, but there are some problems which will need to be solved, like having to define different road/tramtypes to change the pavement graphics without having anything else in return, also the "is the catenary for the road or the tramway?" 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.
The next draft will be a lot more funny to play for sure and it might have more chance to be merged in trunk
NRT is not currently being worked on. Wolf said nothing to the contrary. I don't understand your point.SimYouLater wrote:Although I would like to know why andy had an impression that it was otherwise.
Users browsing this forum: No registered users and 3 guests