Purchase menus - filter by engine type

[Voyager One]

I know filters have been discussed before but here a very specific suggestion:

We have a filter "by cargo type". However, I think a useful thing would be a train filter by engine "propulsion" type: steam, diesel, electric, 3rd rail, metro, EMU, DMU, etc. Today's NewGRFs are crowded with a lot of engines a sometimes it's difficult to get around.

Now, I don't know anything about coding and programming stuff but I've thought about adding a simple "parameter" or some kind of sign number for every train - i.e. a "1" would mean a diesel, "2" for steam etc. Of course, every GRF would need updating with these numbers as well but I don't think it would be much of a problem for coders to do.

Once implemented, inside the Purchase menu, you could choose "only diesels", "only electrics" etc. Also, this could be implemented for other vehicles that have different propulsion types - maybe ships (sail, diesel...)

What do you think of this?

[michael blunck]

[...] What do you think of this?

Every locomotive has/may set prop19 (engine traction type) either to (steam/diesel/electric/monorail/maglev). In addition, it might have set a bit in prop27 (misc flags), if it´s a MU. Moreover, there might be a link into a rail type translation table to get information about anything more specific.

Other than that, restrict yourself to less engines.

regards
Michael

[Voyager One]

Ok, let me quote myself: "I don't know anything about coding and programming stuff..."

Please, explain me this as to a complete idiot.

Is it possible somehow and is it interesting to add at all?

[Kilgore Trout]

I think this is doable. I'm still learning how the GUI code works but it looks like it'll be similar to the cargo type filter. I'm not sure how tightly wedded all the filtering code is to cargo types, though.

edit: upon reflection, it looks like it would be a lot simpler to just add another sort type (sort by traction type). I don't know about only showing MUs or locomotives.

[Alberth]

I think this is doable. I'm still learning how the GUI code works but it looks like it'll be similar to the cargo type filter. I'm not sure how tightly wedded all the filtering code is to cargo types, though.

Not, both sorting and filtering is generic, you just have to provide a filter or sort function (which has of course knowledge about cargo type if that is what it filters/sorts on).

edit: upon reflection, it looks like it would be a lot simpler to just add another sort type (sort by traction type). I don't know about only showing MUs or locomotives.

By adding a filter.

Filters decide what entries to show (eg show all vehicles that carry passengers), sorting decides in what order it is displayed (eg high to low of capacity).

[Voyager One]

I'm involved in the 2cc set that has the most different types of engines between all the "major" sets. Of course, this idea is not about the 2cc set but it would comprise all.

IMO, most "major" sets have most of the following engine "types" (if I may call them this way):
- steamers
- diesels
- electrics
- DMUs
- EMUs
- metros
- railbuses
- monorails
- maglevs.
(I don't know if I've omitted something)

As far as I can see it as a complete moron for coding, I'm suggesting to add some kind of a "sign number" for each of these types in the OTTD "master" code. After that, it would be a simple thing to add these same "sign numbers" in every set (whose coders are interested of doing it) for every engine in the set. Afterward, that particular set would become "filterable" by engine type.

I can't say for absolutely sure if my way of seeing things is correct and applicable but that's basically it.

[Alberth]

You seem to be mixing railtypes and engine types.
'monolev' and 'maglevs' are kinds of tracks (rails), while 'steam' and 'diesel' are engine types that typically run at non-electric tracks.

Also, as michael blunck tried to explain to you, NewGRFs already have this type information (that's how you cannot run a electric engine at a monorail, for example), so there is no need to change the NewGRFs (if that would be possible at all, there are NewGRFs that cannot be modified any more for various reasons).

[Eddi]

there is already code that selects the company colouring for the different engine types. it should be fairly trivial to apply that into a filter.

[Voyager One]

You are both right (and I'm wrong) concerning "rail types" - true, I've made a mistake explaining. What I've meant to say concernes the "standard" normal track engines. Ignore the maglevs and monorails.

Until now it was impossible to filter only diesels, only electrics etc. THAT's what I wanted to suggest. But it wouldn't just stop on steam/diesel/electric - I'd also like DMUs separately, EMUs separately, a railbus separately etc.

The code for company coloring wouldn't be enough - i.e. a diesel locomotive has the same code as a diesel MU and a diesel railbus. Same for electrics. A new additional (more detailed) code would be needed.

I hope I explained clearly this time, sorry for before.

[Kilgore Trout]

I think this is doable. I'm still learning how the GUI code works but it looks like it'll be similar to the cargo type filter. I'm not sure how tightly wedded all the filtering code is to cargo types, though.

Not, both sorting and filtering is generic, you just have to provide a filter or sort function (which has of course knowledge about cargo type if that is what it filters/sorts on).

edit: upon reflection, it looks like it would be a lot simpler to just add another sort type (sort by traction type). I don't know about only showing MUs or locomotives.

By adding a filter.

Filters decide what entries to show (eg show all vehicles that carry passengers), sorting decides in what order it is displayed (eg high to low of capacity).

Ah, OK. All I saw was the cargo filter (e.g. _last_filter_criteria in build_vehicle_gui.cpp) so I thought that was the only one easily supported. I'll see if I can get a build environment set up in the next couple of days and attempt this, I think it's a good feature to have

[michael blunck]

[...] A new additional (more detailed) code would be needed.

IMO, it´s not.

Firstly, it´d require a modification of the spec, and, consecutively, modifications to a large number (if not all) train sets. Secondly, it´d instigate the usual discussion, simply because there will be a large number of vehicles which won´t fit in such a simple scheme.

My advice would be to use instead those already available information about train vehicles, as explained in my recent post.

regards
Michael

[Voyager One]

I really don't know what else to say. IMO, it would be a good idea. And besides that, a set could function without this code to properly and only those devs who are interested could apply this "filter code". The only consequence of "not having this code" would be that the particular set couldn't be filtered this way - all filter options would display all vehicles or none at all.

And even if it must be a separate code, it's a simple code that I'm proposing, and 99.99% of current vehicles would fit easily. I.e. "1" for steamers, "2" for diesels, "3" for electrics, "4" for DMUs, "5" for EMUs, "6" for railbuses, "7" for battery, "8" for metros, "9" for GTELs, "10" for hybrids and fuel cells and that's it. I don't see any other "propulsion" types except if someone decides to add a nuclear-powered locomotive.
In fact, I'd really like to see someone giving one example of an engine which wouldn't fit in one of these 10 categories. Besides, if in doubt, devs could choose a category and that would be it.

Set devs would need (if interested to adjust their sets) to add just one code to each engine and I don't see a problem there. They fill in stats manually anyway, so what's one more "stat" to add.

OTTD would get another filter which would recognize that additional code and display engines with that code only. IMO it could be useful because today's set are getting bigger and bigger and having a P-menu with 200 engines is tiresome for browsing.

[michael blunck]

[...] it's a simple code that I'm proposing [...] I.e. "1" for steamers, "2" for diesels, "3" for electrics, "4" for DMUs, "5" for EMUs, "6" for railbuses, "7" for battery, "8" for metros, "9" for GTELs, "10" for hybrids and fuel cells and that's it. I don't see any other "propulsion" types

You´re mixing categories. What´s the difference between a "diesel" and a "DMU" with regards to "propulsion type"?

This would in fact be the type of "transmission of power", i.e. diesel-mechanical, diesel-hydraulic, diesel-electric.

Indeed, your concept is flawed, simply because it mixes different categories.

regards
Michael

[Voyager One]

I'm not mixing categories, I just can't find a correct word to name this. That's why I've written "propulsion" within quotation marks. I'm not referring to the transmission power you're mentioning.

Maybe the best way to say it is "train type or composition or utilisation". I can't find the right term(s), don't take my words literally.

What's the difference between a diesel and a DMU? It's that "MU" stuff - multiple unit. The best way to explain myself is this: a diesel (locomotive) is a "(single) tractive device powered by a diesel engine". A DMU is a "(usually) passenger-hauling train consisting of multiple units powered by a diesel engine(s)". I don't know if you get my drift... And it's because of this difference that I'd like to have a filter, to be able to separate them this way too.

[michael blunck]

What's the difference between a diesel and a DMU? It's that "MU" stuff - multiple unit. The best way to explain myself is this: a diesel (locomotive) is a "(single) tractive device powered by a diesel engine". A DMU is a "(usually) passenger-hauling train consisting of multiple units powered by a diesel engine(s)".

First of all, I´d like to repeat that you are mixing categories in an unhelpful way.

Now, "diesel" is clearly a superset of "DMU". OTOH, it´s not clear what "diesel" should stand for as a category. Is it based on the fuel needed for combustion? The largest number of "diesel locomotives" would fall under "hybrid" in your scheme, according to this definition:

A hybrid locomotive allows the internal combustion engine to run at a constant speed, turning an electrical generator which in turn powers an electrical engine.

In this way, your scheme mixes categories based on motive power, resp. source of energy with categories based on usage resulting into unpleasant intersections of categories:

- there have been some Swiss steamers powered by electricity, are they "steamers" or "electrics"?
- there are "diesel" and electric" locomotives carrying small capacities of luggage or even passengers, are they "railbuses"?
- what kind of category is "railbus" at all? May it be a single part of a DMU? Must a railbus be a single vehicle? Is it a MU when being linked with a second one? How about propulsion in this case? There have been steam "railbuses", are they "steamers"? Which category takes precedence over which other category?
- how about "usage" in your scheme? (passenger, freight, switchers, ..)
- what is "Metro" standing for? Is it based on usage (passengers only), or is it based on a subset of "electricity", namely "3rd rail"?
- "battery" seems to be a category based on a special way to provide electrical energy, but it´s quite insignificant with regards to the actual vehicle: it could be a railbus or a switcher (main applications) or even something else,
- "DMU" and "EMU" are really only different with regards to source of energy, in turn.

I could write more, but it should be clear, that it would be better to make either

- a scheme based on motive power / source of energy, or
- a scheme based on usage

but not mixed up from both.

regards
Michael

[Voyager One]

OK, I get it. This discussion could go on and on and on... There are many "cons" and "pro" for both you and me and now it's clear to me that it would never be possible to achieve a balanced compromise that would satisfy everybody. I mean, I could answer all your questions but it's an opinion and "definition" of stuff of my own and there would be people disagreeing for sure.

As far as I'm concerned, we can end this discussion unless someone finds a better and more "universal" idea than mine.

And to all involved, please no offense for anything, it was just a discussion.

[michael blunck]

OK, I get it. This discussion could go on and on and on... [...]

That´s why I wrote:

Secondly, it´d instigate the usual discussion

Because we had it before, possibly a couple of times (well, not exactly addressed to "filtering").

And to all involved, please no offense for anything, it was just a discussion.

Nah. The idea as such is not bad, it´s just a clear concept which is missing.

And I´d like to remember that it´s already possible to write filters based on already available nfo features (hence no discussion needed), like track type, engine type, being MU, etc.

It´s even possible to define some bits in prop25, though this byte might be used already by some sets for internal use (e.g. DB Set).

regards
Michael