NotRoadTypes

[andythenorth]

All that said, good work andy !

Mostly Wolf01 & frosch

[SimYouLater]

Sorry I've been gone so long. I... had a nervous breakdown. Major stress. The issue, a real life matter, isn't fixed because it's so massive and interconnected that fixing it in the required timeframe that it can't be done. Unfortunately this will have some bad consequences, but I'll have to live with them.

Anyway...

I think this really goes out of the scope of NRT

+1

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).

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 !

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.

As for other types, here's a simpler solution...

• Include the possibility of using 32 railtypes code to increase roadtypes, tramtypes and extratypes (second bullet point) to 31 slots.
• Leave the option for a separate "extratype" based on tram - along with roadtype and tramtype - which has no tunnels and doesn't interact with roads, trams or any other terrain features except for height (and ignoring ocean save for increased price under sea tiles). Strongly recommend future patches NOT use this for subway.
  Primary use is as a replacement for WIRES, WIRED and PIPES (what I called "utilitytypes"), a better version of the elevated monorail system, or for that Chinese "strider bus" tram.
  Include one way for the latter situation only, with any such track needing only 4 more sprites, 3 for each straight tile as one for each direction and one both ways. Stations, intersections and curves will have only one sprite which are two-way (direction neutral). Going back the way the one-way extravehicle came requires a loop; not having the glitch means purposely using one tile each way (intersection glitches are unavoidable).
  Include translucent extratypes enabled by an "underground switch" for underground "utility extratypes". Extratypes are allowed to cross each other and will never interact with each other or anything else. One-way translucent extratypes should be disabled.
  Secondary use is decorative, mostly unsure what that could mean but could be useful; one possibility is a "faux subway/underpass" extratype that is not actually a subway, to be used as an underpass decoration or if the last bullet point ever becomes a separate patch - once again, recommend that this NOT be used as a "subway". Another is for road newobjects by proxy, though that's a bit of a hackjob.
• Extratype Stations: If an XML switch says the extratype is underground, stations do not appear on surface if anything is above. When not transparent, two mildly thick translucent lines at the outer edges (to denote SW\NE and NW/SE) denote that the translucent extratype has a station; otherwise, "tracks" act as tramtype does.
  Stations appear on empty tiles as one of only two sprites, custom graphics by type as stated, if nothing is above; one for NW/SE, one for SW\NE. The option to have only one spite for both directions should also be a possibility; stations above ground by direction are only necessary if the type is not underground.
  Decorative extratype stations should be possible but also disabled by default. Decorative extratype stations always override the roadtype and tramtype stations. In the "underpass/faux subway" example, the extratype station would be an ordinary-looking drive-through stop typical of roadtypes and subwaytypes but with a faux subway/underpass staircase.
  Underground extratype stations on slopes do not appear if a road, rail, any station or building is above it (save the aforementioned translucent lines to denote them). They appear as a blank concrete tile as used by buildings (including foundations), but which can be built on; if anything is built on it, the tile is displayed as grass beneath any transparent NewObject; slope-sensitive NewObjects overrule display of foundations as expected.
  Underground extratype stations on an adjacent tile or the same tile as any railtype station, bus or truck stop, roadtype/tramtype/extratype drive-through stop, or airport, are part of the same station. Underground extratype stations can't be built uphill/downhill or under sea tiles, and must be adjacent to docks. An underground extratype stop of a different extratype must be adjacent or perpendicular, and if the undertype railtype patch below is ever made, NRT underground extratype stations should be allowed to be built on the same tile unrestricted; in all cases of multiple extratypes crossing the transparent lines would form a square and transparent extratypes would both be clearly visible, while if undertype rails are made they should have a separate transparency setting.
  
  The above three bullet points should be accounted for in short-term coding decisions. While not the shortest possible explanation, by ignoring subways (which have signals) but not utilities (which don't), the suspended monorail (which sometimes doesn't IRL) and the strider bus (which has to be on road regardless), 30 points have been condensed to the above three. The final two is for what is outside the scope of this project (subways) and how I recommend handling it.
• Recommend to aspiring subway patch makers that they make a second railtype category, undertype. Undertype is railtype but translucent, with an option to make transparent seperately from extratypes; signals only visible (as the lights themselves, no signal stands) when undertype isn't transparent. Code to be separate from normal railtypes, not interact with surface and be transparent could and should be borrowed from extratype; no tunnels, doesn't interact with rails, trams or any other terrain features except for height (and ignoring ocean save for increased price under sea tiles).
• Undertype Stations: Stations do not appear on surface if anything is above, which when not transparent, are seen as two mildly thick translucent lines at the outer edges (to denote SW\NE and NW/SE) that denote that the translucent extratype has a station. NewStations do not apply. Stations with nothing above are marked by a blank concrete tile as used by buildings, but which can be built on; if anything is built on it, the tile is displayed as grass beneath any transparent NewObject. Slopes are handled the same as the underground extratype station recommendations. Undertype stations must be adjacent or perpendicular to other undertype stations.

[andythenorth]

@SimYouLater my (kindly intended) advice is to guard your mental health, and not worry too much about theoretical specs for retro transport games OpenTTD is a long way down any list of important things

[SimYouLater]

@SimYouLater my (kindly intended) advice is to guard your mental health, and not worry too much about theoretical specs for retro transport games OpenTTD is a long way down any list of important things

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.

As for the real life issues, that's due to something far more important than OpenTTD and is unsolvable, which is why I had a breakdown. The reason I posted is because I needed a break from trying to solve a list of issues - all of which are important and interconnected - and this is one of the few things that kept my mind off it that didn't rely on solving the issue first.

Word of advice: If your entire list of online accounts needs to be changed at once, you're in for a rough ride. The Yahoo hacks of 2013 and 2014 just became known a couple months back, and now I have to check and change ALL my passwords. It also means that, currently, I'm not able to access a couple of important email addresses. Since, like anyone, a lot of real life things OFFLINE also rely on email, that's a big issue.

[Wolf01]

just try to keep in mind what cloud be done with NRT

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).

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.

[luxtram]

Are different station/stop graphics in the scope of NRT? And if yes, can station graphics put over the vehicles?

[SimYouLater]

@SimYouLater my (kindly intended) advice is to guard your mental health, and not worry too much about theoretical specs for retro transport games OpenTTD is a long way down any list of important things

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.

just try to keep in mind what cloud be done with NRT

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).

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.

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.

As for the IRC discussion, it's basically what I was getting at with the "short-term goals" but from the mouths of devs that know the process better. If it will work exponentially better to renovate the code to enable more road/tramtypes while reducing stress on systems and whatever else you came up with, but everything else I've mentioned is out of scope, I'll gladly step aside and let you handle it from here.

Final Note: I'm not sure if it works with your new roadmap, but the only remaining ideas that are possibly within scope of NRT and not covered by your plans are the possibility of separate catenarytypes (might be easier to ignore them) and "NewStops" (custom bus/tram/truck stops). That's all I wanted to say, though if either or both those ideas are any good, then aside from myself I'm sure luxtram would be thrilled if custom stops were made possible. Good luck from here on out!

[luxtram]

I'm sure luxtram would be thrilled if custom stops were made possible.

Well, actually yes. Let me elaborate.

I realized (even before NRT was a thing) that it would be much less real estate consuming to run the subway system using tunnels and trams - it only takes 3 tiles: 2 tunnel entrances and 1 tram stop to make a subway station. It would take at least 2 additional tiles for rail as one needs signalling and actually more as trains load slower in short stations.

To make this happen one needs the possibility to create custom stops and in fact also custom tunnel entrances to hide the subway infrastructure. Yes, it could be done with newgrf overlays to some degree but it would take up additional tiles on the sides.

So yes, it would be indeed much appreciated if that all would be possible.

[andythenorth]

NewGRF roadstops are not in scope for NRT - there is nothing connecting the two except they are both road features

[SimYouLater]

NewGRF roadstops are not in scope for NRT - there is nothing connecting the two except they are both road features

Ah, well. Is making it easier for someone to integrate a custom stops patch with NRT in scope? Just a thought.

[andythenorth]

Ah, well. Is making it easier for someone to integrate a custom stops patch with NRT in scope? Just a thought.

Does the custom stops patch exist somewhere? I haven't seen it announced, nor a suggested newgrf spec for it.

[leifbk]

Ah, well. Is making it easier for someone to integrate a custom stops patch with NRT in scope? Just a thought.

Does the custom stops patch exist somewhere? I haven't seen it announced, nor a suggested newgrf spec for it.

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.

[KeldorKatarn]

How far is the feature btw? Are there still major problems? I'm starting a new series soon and I was thinking, if it was relatively far, I might integrate it into my code to use for that. It's basically just about the ability to build different road types. I wouldn't even care about speed limits or other stuff already working (houses not being built next to certain roads might be nice though, if that's working already and implemented in a newgrf)

So I guess I'm basically asking how far you guys are and what's left to do and whether putting this into a patch pack would be an option to already try it out.

[andythenorth]

How far is the feature btw? Are there still major problems?

Hard to answer that

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

[SimYouLater]

How far is the feature btw? Are there still major problems?

Hard to answer that

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

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]

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?

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 tbh

[kamnet]

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.

I think at this point patch pack developers should look at implementing it. They have a hardcore group of players who are usually very good at providing constructive feedback and finding bugs.

I think this weekend, if I get a chance, I'll put together a forum post which points regular players to the NRT builds as well as put together a list of what NewGRFs are currently available to play with.

[Wolf01]

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

[SimYouLater]

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

So you were working on that code overhaul you mentioned.

Question can be dropped then. Although I would like to know why andy had an impression that it was otherwise.

[andythenorth]

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 don't understand your point.

You keep putting words in my mouth in your posts. It's irritating.