NotRoadTypes

[Wolf01]

"640k ought to be enough for anybody"

30 *types are enough if wisely chosen.
If the problem is to have *types for every speed limit or for every pavement type, then I'm sorry but there is something which doesn't work.
NRT was intended more to allow different real types, like road+catenary for trolleybus, highways, heavy haul roads for slow vehicles, country roads, wetroads, bidirectional pipes etc.
And yes, they have they own speed limits, features (no houses, no level crossings) and appearance, if there is the need for different speed limits on the same road, it is not with multiple roadtypes that solve the problem, but with proper road signs.

I repeat: the only part I would change is to have a pool (with hookers) of both *types which can fill up to 30 positions, instead of 15/15, but it's up to the entire team and devs that it should be decided, as it needs some changes to the current code.

[andythenorth]

I frankly have no idea why the OTTD developers still refuse to implement 32 railtypes in trunk

Don't confuse 'refuse' with 'nobody is interested'. Peter has a patch for it, it's just there's nobody interested in committing it to trunk.

Speaking as someone who *doesn't* have trunk commit rights (and won't get them), I think 32 is stupid.

The user experience for 32 railtypes (or roadtypes or tramtypes) would be awful.
1. The *type dropdown menu would only just physically fit onto my screen
2. Choosing types would be appalling. How do I make choices between 32 different types? It needs a spreadsheet and a flow chart. It's not a game, it's a tedious economic exercise.
3. Understanding vehicle compatibility between types would be awful.
4. It's p*** poor design by the newgrf author imho. Have some discipline, make choices. It's terrible for the same reason FIRS Extreme is terrible and HEQS is terrible: no proper choices made, just blah blah blah add MOAR .
5. 32 is *not* enough. If newgrf authors can't reduce to 16, they're not going to be capable of reducing to 32.
6. If a newgrf needs all 32, there's no way to combine newgrfs. Kind of anti-social design. Railtype and NRT grfs should contain about 4 or 8 useful types, and let players combine with other grfs to get the game they want.

If the limit is raised, it should be raised to something sensible, like 16k or 65k. That would be much better. But it needs a rewrite of the map array. Not likely.
32 is ridiculous, it's neither small enough to be an interesting constraint, nor is it enough to solve the problem (the problem is poor newgrf design btw).

And this is why I don't get trunk commit rights.

[Erato]

1. <doesn't fit on screen>
2. <how do I make choices>
3. <compatibility between types>
4. <authors should consider their choices>
5. <if we increase it to 32, that becomes the new "not enough">
6. <can't combine newgrfs if you need all 32> <Newgrfs should limit themselves to 4~8 useful types>

1. smh

1StEcuH.png

(1.27 MiB) Not downloaded yet

2. not necessarily a problem
3. not necessarily a problem

In JapanSet Tracks I've never had similar problems with having difficulty understanding what is and what isn't compatible with each other, even though it takes up most railtypes. I don't think adding additional railway gauges, or things like maglev tracks or monorail tracks or whatever really, is going to make this problem worse.
(of course I designed Maglev Track Set like a bloody idiot making the perfect counter example)

4. not necessarily a problem

I still stand by my opinion that having fake subways and elevated fake metro systems using NRT would be super cool. If I were to want to make a tramtrack set to faithfully represent Tokyo, I'd already need 14 railtypes for that. 17 if I include Nagoya, but that would cover just about everything. Of course, using "clever design" I can add a parameter for boring people getting rid of all the elevated and underground variants, so it's limited to only 7 tramtypes.

But that would be boring. Sure it might be what most people prefer, but I like having different aesthetic choices, and blocking the possibility from the get go because you don't like it,

5. true
6a. not necessarily a problem

I find it ridiculous that I can't have JapanSet Tracks with the (2!) Japanese tracks in MTS and Vactrains without disabling urban tracks in JapanSet Tracks. I have this problem with the limit at 16!

6b. not necessarily a problem

The most barebones version of JapanSet Tracks you can reasonably expect to get has 7 railtypes. I don't want a barebones version. Of course, JapanSet Tracks offers a way to reduce the total amount of tracks to the 7 railtypes I mentioned before.
Sure you might not agree with having different tracktypes for urban lines and different speed limits, but it provides interesting gameplay aspects to consider, which I, and many others prefer.
99% of projects I can think of do not need 32 *types or even 16. I can fit most projects in my head within the before mentioned 8 *types. And for most projects I don't have a reason to consider elevated, underground or urban *types. But having different speed limits, at least in my opinion, makes gameplay more interesting. Even if we extend the JapanSet tracks to it's limit and add some speed variants, then we still don't cross 32 so that's a nice limit, I guess. Any reasonable combination of newgrfs won't go beyond 32 *types

I agree with Wolf01 here, 30 *types is enough if wisely chosen. But I stand by my opinion: 16 is just a tad too few.

[Wolf01]

1. Not all players play with 4k resolution

Also I was put down on pool of 30, we made 15/15 because we had 4 bits free for each road/tramtype on a tile (with 0 or 15 being "invalid" for reasons)

[Snail]

Speaking as someone who *doesn't* have trunk commit rights (and won't get them), I think 32 is stupid.

The user experience for 32 railtypes (or roadtypes or tramtypes) would be awful.
1. The *type dropdown menu would only just physically fit onto my screen
2. Choosing types would be appalling. How do I make choices between 32 different types? It needs a spreadsheet and a flow chart. It's not a game, it's a tedious economic exercise.
3. Understanding vehicle compatibility between types would be awful.
4. It's p*** poor design by the newgrf author imho. Have some discipline, make choices. It's terrible for the same reason FIRS Extreme is terrible and HEQS is terrible: no proper choices made, just blah blah blah add MOAR .
5. 32 is *not* enough. If newgrf authors can't reduce to 16, they're not going to be capable of reducing to 32.
6. If a newgrf needs all 32, there's no way to combine newgrfs. Kind of anti-social design. Railtype and NRT grfs should contain about 4 or 8 useful types, and let players combine with other grfs to get the game they want.

If the limit is raised, it should be raised to something sensible, like 16k or 65k. That would be much better. But it needs a rewrite of the map array. Not likely.
32 is ridiculous, it's neither small enough to be an interesting constraint, nor is it enough to solve the problem (the problem is poor newgrf design btw).

And this is why I don't get trunk commit rights.

I see your point as a suggestion to newGRF developers to keep things disciplined and not get carried away by rivet counting. But this is not a problem with poorly designed newGRFs: the issue is in OTTD itself, because it bakes the rail (or road) type together with its electrification system. Unless we disentangle these two things, any set supporting multiple rail types and different electrification systems will have to deal with some kind of combinatory explosion.

You may be surprised to hear me say this , but I totally agree with you when you say a railtype grf should contain between 4 to 8 useful types of *rail*. The set I'm developing does exactly like that: it has 5 standard gauge types, and 3 narrow gauge types, each differentiated by maximum axle load and maximum speed. That's already more than enough for me.
However, I also have three different electrification systems: DC, AC, and third rail. To make things more complex, DC and third rail can coexist on the same rails: and I'll also have to define slots for "bicurrent" engines (able to run on DC and AC), as well as "amphibious" engines (with pantographs and 3rd rail shoes).

If we could build rails first, and then add the proper electrification system(s), it would be much easier and tidier. But that's not possible in OTTD as it is now. Therefore, we have no choice but repeat the same rail type for each electrification systems it supports.
As I mentioned, I'm keeping things "simple" in my set, so I'd end up using "only" 21 combinations. I could bring this down to 16, but I feel it'd be a limitation that detracts from the playing experience. So I'll recommend players to use a patchpack such as JGR's, and add a parameter to my set that ditches 5 combinations, for people who still want to stick with trunk OTTD.


As for your other objections, as I said, I don't need to get any close to 32. Even 24 or maybe 20 would be enough for me. Just 16 feels a bit tight.
Choosing between types can be intuitive enough, as long as the newGRF author labels things reasonably. And even compatibility among types will be manageable, as long as the newGRF has a robust design. Raising the limit by itself won't create any new issues: solid design is the issue. I just disagree with your statement that "any trackset with more than 16 types is badly designed to begin with". You can do bad designs even with 2 or 3 types

So yeah, I agree with the others here: given the way OTTD works now, 16 types is too few, and asking for 32 is more than legitimate. Sorry, Andy

[kamnet]

I frankly have no idea why the OTTD developers still refuse to implement 32 railtypes in trunk. If this continues, I'll have to add a parameter to my set that ditches a few railtypes to keep below 16

I would suggest this anyhow. For example, there are two track types that I would like to use out of Japan Set Tracks because they're visually appealing to me, but I can only use them if I enable the whole set, which hogs up almost the entire allotted space, which means I'm not using other rail types.

[wallyweb]

if there is the need for different speed limits on the same road, it is not with multiple roadtypes that solve the problem, but with proper road signs.

Unfortunately the drivers of OTTD/TTD vehicles are imaginary and probably illiterate.
Or do you have something else in mind?
As in ... Is it possible to have an open road speed property whereby the player can place something (sign?) on a road tile so that that tile and subsequent tiles, up to another something (sign?) is encountered? The default (without a sign(?) ) would be "unrestricted".
A secondary default might be that the signed restriction arbitrarily expires after a predetermined number of tiles thus eliminating the possibility of one sign accidentally affecting the entire network. A grid might be useful here so as to accommodate turnouts. Hmm ... This needs some thought. Would the limit apply before or after the sign? Or both? The side of the road upon which the sign is placed might be useful to regulate this. I'm thinking of something akin to the signals currently used for the game's railroads.

[kamnet]

There's two things that are for certain:
1) There are always going to be some sort of limit in this game until the map array is re-designed.
2) That limit is never going to be enough for some players.

I don't find it unreasonable to ask for the numbers to be bumped up, and I don't find it unreasonable to ask NewGRF developers to be smarter in how they design their NewGRFs to work within any given limitation. We're going to have players who want NRT to be based on speed limits, some who want it to be for eyecandy, some who just want lots of different transport options, and some who want everything they can get.

[acs121]

Map array redesign is just the step forward in OpenTTD, though it's very hard to implement.
About those road signs...you can still use drive-thru stops and tell to go via non-stop and set a speed limit, but then you have unserviced stops !
A thing about NRT is that in the future it may be able to support things e.g busways, something impossible in trunk right now.

[andythenorth]

If we could build rails first, and then add the proper electrification system(s), it would be much easier and tidier.

NRT started out with a patch I made to add/remove electrification from roads and tramways, separate from the type

The upside of that route is that it's simpler and would avoid having types like this:

• 'rail, 30km/h'
• 'rail 30km/h, electrified 1500v DC'
• 'rail, 30km/h, electrified 25KV AC'
• etc

The downsides are:

• it bakes in 'electrification' as a concept, which limits the potential for authors to do creative / silly hax with catenary sprites etc
• it would need work to handle the which electrification types can be applied to which railtypes, in a way that works across grfs
• it would need work to handle vehicle compatibility with electrification type AND railtype, including callbacks and cached results
• it's just not how railtypes was done, for whatever historical reasons

Basically, what we have is the most flexible solution to limited bits on the map, whilst being very flexible for authors' ideas. But it has many downsides and isn't 'best' for any use case other than a few railtypes (or roadtypes).

Looking back, a solution could have been to reduce the scope of the spec, e.g. removing railtype speed limits etc. That horse has left the stable though

I'm on the fence about whether separate electrification would have been better. It's a clean way to support a very common use case, and could have had a nice UI. But it means two sets of labels interacting with vehicles. That kind of thing tends to be complicated and have unwanted side effects.

[acs121]

Honestly i think people shouldn't bother about voltages. That's a really damn bad idea.

[Kruemelchen]

Well, if Ground Types get to be realised, you wouldn't need that much Road Types anyway.

However, I think GRF authors need to keep balancing realism and playability as well. IHMO every type should be very distinctive from all the others in use-case

About those road signs...you can still use drive-thru stops and tell to go via non-stop and set a speed limit, but then you have unserviced stops !
A thing about NRT is that in the future it may be able to support things e.g busways, something impossible in trunk right now.

I guess then waypoints / signals should be ported to Road/Tram Types
After all IRL train signals can have speed limit signs on them.
And maybe traffic lights could just be some sort of signal ...

Honestly, then speed limits could be safely removed

[Snail]

I'm on the fence about whether separate electrification would have been better. It's a clean way to support a very common use case, and could have had a nice UI. But it means two sets of labels interacting with vehicles. That kind of thing tends to be complicated and have unwanted side effects.

It would have been complicated, but there could have been a standard set of labels newgrf authors could follow to ensure compatibility. A bit like what we've got now with railtype labels.
The beauty of such a system is that each *vehicle* could specify with kind or rail/roadtype, AND electrification system, to be compatible with. We could have vehicles supporting multiple electrification systems, without necessarily creating a specific railtype.

Like this, even a limit of, say, 8 railtypes and 4 electrification systems "would be enough for everyone" (TM).

Honestly i think people shouldn't bother about voltages. That's a really damn bad idea.

I can see your point. Separation between AC and DC could look like "too" much realism to some. On the other hand, there are still electrification systems that are so different that they ought to be separate (normal catenary, threephase, third rail...)

[kamnet]

Truthfully, I wish that right now we not worry about voltages, and instead let NewGRF developers identify those vehicles within their sets. But, eh.

[acs121]

Well, if Ground Types get to be realised, you wouldn't need that much Road Types anyway.

However, I think GRF authors need to keep balancing realism and playability as well. IHMO every type should be very distinctive from all the others in use-case

About those road signs...you can still use drive-thru stops and tell to go via non-stop and set a speed limit, but then you have unserviced stops !
A thing about NRT is that in the future it may be able to support things e.g busways, something impossible in trunk right now.

I guess then waypoints / signals should be ported to Road/Tram Types
After all IRL train signals can have speed limit signs on them.
And maybe traffic lights could just be some sort of signal ...

Honestly, then speed limits could be safely removed

Waypoints for roads were something refused by devs few years ago.
However, Wolf01 told me there was possibility for bus / truck-reserved ways in NRT, and that it is far from being impossible. So, let's wait as we can !

[Kruemelchen]

Well I'm patient in waiting

[McZapkie]

Are there any nml project involved into NRT, to lurk into its code?
I want to make horse carriages capable to run on off-road but not on highway.

[Eddi]

I want to make horse carriages capable to run on off-road but not on highway.

that's backwards, the road decides what vehicles go on it, not the vehicle decides what roads it runs on

so you need a "dirt road" roadtype, then make normal roads compatible with it, but highways are icompatible with this roadtype. this "light" (or "early") dirt road type should be different from the "heavy duty" dirt road type intended for HEQS vehicles

[andythenorth]

Are there any nml project involved into NRT.

https://github.com/andythenorth/nml-and ... d_tramtype

[acs121]

You should know, to code NRT NewGRFs, as far as i know, you can only use NML.