Engine Pool suggestions (making it more useable)

[Draakon]

Every electrical train can run on every electrical track, no matter what track set has been loaded.

as I said, maglevs and monorails are electrical too.

But they are different in design. They don't have wheels(maybe monorail has, but maglevs don't)

[Eddi]

... someone mentioned livery overrides. i think that is a real nightmare feature to build a set around ...

It is complex, but quite manageable. In the CanSet, that is the backbone; the behaviour of wagons depends on the engine, i.e. the engine company (CNR, CPR ...) or engine type (e.g. push-pull). Wagon overrides is not just the livery; the wagon length (of some of them) differs by company, plus a lot more tiny little things (everybody seems to like so much). They are all determined via an engine wagon override action-3 to start with. If the engine is not a Canadian one, the wagons won't function as intended, they are lost totally. And if a player wants to attach a wagon from another set, the Canadian engine doesn't know how to handle the situation.

You are welcome to make improvements ... I like your ideas, but let's stay focused with what we have at the moment.

well, i cannot promise to stay focu... ooooh, what a nice butterfly

anyway, the way i view it, relying on a fixed front engine is going to fail in the near or far future. In the near future, because with the mixing of sets you cannot be sure that the engine in question is from your set [e.g. a dedicated graphics artist might do a one-engine set with custom colourful livery in the next random jubilee edition], but generally want this engine to be useable with your set. In the far future, like i suggested, with the total abolishment of a "front engine", there are "engines" [what ever vehicle has >0 power], and there are "wagons" [vehicles with 0 power]. a "train" would then be any consist of (nested) vehicle chains that contains at least one engine and the vehicle in "front" must be refitted with a driver's cab, whether it is an engine or not.

and there we have a keyword: refitting. this one is much more likely to be reliable. [in the next thought i will assume that it is possible to refit wagon chains without a front engine present. IMHO that is an overdue feature anyway]

so here we go, refitting wagons. let's take your example of different companies with different wagon lengths. you could allow the player to refit the wagon chain to any company livery he likes. and then for each livery you define a "coupling specification". so you have wagons that can be refitted to "coupling A" and "coupling B", and an engine that is only compatible with "coupling A", so the player will not be allowed to attach wagons with "coupling B" to this engine, he will have to refit them to "coupling A" first.

this way, much like real railways, you can assure inter-set compatibility by defining standard couplings, like "American standard coupling", "European standard coupling" or "Russian standard coupling", that way, you can start a freight train in Berlin, move it with a German engine via Munich to Kufstein, from there let an Austrian engine pick up the train to haul it via Innsbruck to the Brenner, and from there let an Italian engine haul it down to Bozen, Verona and wherever else you would want to go in Italy. The set creators only will have to make sure they make their engines conforming to the "European standard coupling". Also, you can restrict usage for passenger trains if you specify also an "Electric heating coupling", so express passenger wagons can only be hauled by engines which provide electric heating. Or you could define a "Nonstandard ICE 3 coupling", to allow ICE 3 trains only travel as one [or two] unit, without the ability of intermixing.

likewise, you could then allow trains for push-pull service only if

1. the engine and all wagons provide "push-pull coupling"
2. the last wagon has been refitted with a driver's cab

that being said, an engine doesn't necessarily need a driver's cab. e.g the ET-87, where the engine is in the middle, and there are two wagons with driver's cabs.

special cases might be required when vehicles offer more than one coupling mechanism (and the "best" common coupling mechanism decides the validity of the train consist, like a helper engine doesn't need the ability for heating when it is pushing a train which already has a proper engine) and for shunting operations (which will certainly cause other kinds of headaches, too, i just wanted to throw this in the room)

anyway, with the sheer infinite amount of vehicle IDs and improved filtering mechanisms on the build vehicle list, there is probably not the necessity anymore to encode all possible ways of a passenger wagon into the same vehicle ID [with refit options]. i understand that this will get you in trouble with TTDPatch compatibility, though.

[michael blunck]

In the far future, like i suggested, with the total abolishment of a "front engine", there are "engines" [what ever vehicle has >0 power], and there are "wagons" [vehicles with 0 power]. a "train" would then be any consist of (nested) vehicle chains that contains at least one engine and the vehicle in "front" must be refitted with a driver's cab, whether it is an engine or not.

This is already the case in TTDPatch, at least from a user´s view.

this way, much like real railways, you can assure inter-set compatibility by defining standard couplings, [...]

I´m unsure what you mean with "couplings" in this context, but I think something like this should be already possible as well.

likewise, you could then allow trains for push-pull service only if
- the engine and all wagons provide "push-pull coupling"
- the last wagon has been refitted with a driver's cab

Already possible. I´m doing it this way in DBXL 0.9.

that being said, an engine doesn't necessarily need a driver's cab. e.g the ET-87, where the engine is in the middle, and there are two wagons with driver's cabs.

It doesn´t matter where in the consist the "real" engine would be located, as long as the kinetics of the consist would be computed correctly. E.g., in the actual implementation of the ET-87, the (single) "engine" is o/c at the front, only the graphics suggest that it´d be in the middle. And with the "poweredwaggons" feature of TTDPatch you could even put power and weight into that middle vehicle. So, that´s all perfectly possible even today.

anyway, with the sheer infinite amount of vehicle IDs and improved filtering mechanisms on the build vehicle list, there is probably not the necessity anymore to encode all possible ways of a passenger wagon into the same vehicle ID [with refit options]. i understand that this will get you in trouble with TTDPatch compatibility, though.

Using "livery refit" isn´t a makeshift. Sparing veh-IDs is only a by-product. The main reason is to have different graphical representations for vehicles linked to a certain engine, depending on a bunch of other variables (be them engine-related or not). To give up that mechanism only because of the availability of an "indefinite amount" of veh-IDs is a no-go for .grf developers. IMO, this makes no sense at all, because the basic functionality of "livery refit" would get lost. And o/c, this has nothing to do with "TTDPatch compatibility", as usual.

regards
Michael

[OzTrans]

... The main point is that certain sets could be able to be used in one game without mixing the sets.. I believe OzTransLtd wanted that, that Canadian Set would be unmixed with others, but that doesn't deny us to use other sets at the same time ... If only the economical changes would be per GRF basis too ...

Yes, we would want the ability to restrict any vehicle in the CanSet to be mixed with other sets and the global settings of base costs to be on a per GRF basis. That is the goal, now we wait until we get it. What other sets do is no concern to me.

... Gare Central / Toronto Union ...

I get your point, this has always been a problem; but at the time CanStn v0.3 was created we didn't have access to landscape information. Now, that landscape information is available, these issues will be a thing of the past. CanStn v0.4 will address incomplete buildings; if a building or feature, that spans multiple tiles, cannot be displayed correctly, due to partial removal, it will change into e.g. parkland, car parks or anything that displays correctly. It will then be up to the player to fix the problem. I don't think restricting stations to be built from one single set only would be necessary or even desireable. How would you build a passenger station, that also has freight platforms for goods and these come from a different set.

... Just wondering how I can code: allow only NewGRFs with GRF ID x, y and z to build industries when I am enabled. ...

Having classes in addition to the GRF ID would be a good idea; e.g. ECS industries, spread across many GRFs, would belong to the same class.

... patch flag 78

This flag is linked to the OpenTTD patch switch 'Enable multiple NewGRF engine sets. That flag can be read by a set and used to disable the set, if that set requires the pool to be disabled. It will not solve any problem. A set should not have to use it; there should be other means of achieving compatibility.

Yes, the CanSet disables itself, if the flag is on; it's the first line of defence.

... your suggestions ...

They are all great and we would love to have them. They would break current GRF sets and those sets would require a rewrite. Are we prepared to rewrite them ? Maybe, but we would object to have your features implemented with little warning. If a new feature breaks existing GRF sets then there is trouble in the air.

.. using individual vehicles (by ID) instead of refitting ...

I don't think players would be happy, when building a passenger train to have to choose among 30 different passenger coaches with some being rejected because they do not fit the engine. They'd prefer to build the train using one type of passenger coach and then refit the train.

[Eddi]

This is already the case in TTDPatch, at least from a user´s view.

i think you totally misunderstood me, i was talking from an implementation point of view, not from a user's point of view.

I´m unsure what you mean with "couplings" in this context, but I think something like this should be already possible as well.

by "coupling" i mean any kind of standardised interface between components [vehicles], so in order to check compatibility between two components, you do not compare special IDs, but you check if they share the same interface. over the whole world this is how interoperation between components of different manufacturers work. you connect PCs from one manufacturer with monitors from a different manufacturer, or headphones with CD players, or wagons with engines... all work the same way by complying to a previously defined interface, which you may call "coupling" or "translation table" or whatever, i'm speaking very abstract here.

if you then have a generic engine, like e.g. a BR 101, you can allow interoperation between vehicle sets by specifying a common standardised interface, or if you have a very special engine, like an ICE3 you can specify a non-standard interface to only allow specially prepared vehicles [long distance coaches refitted to ICE3 livery] to attach to it.

It doesn´t matter where in the consist the "real" engine would be located, as long as the kinetics of the consist would be computed correctly.

i know that an "NFO-crack" like you knows his way around this issue. but for anyone else, would view that as a huge hack, and hacks WILL get you in trouble with interoperability. so when it will be possible to put the engine where it belongs [in the middle], why not use it like that, too? so an ET-87 consist would then not only graphically, but also in the implementation consist of:

• an ET-87 steering wagon [cab front]
• an ET-87 engine [no cab]
• an ET-87 steering wagon [cab back]

and a different grf can provide a different implementation for each individual part as long as he knows the programmatic interface, without worrying about any implementation-hacks

for vehicles linked to a certain engine

that's the key point i am talking about, you should not rely on the fact that you

1. know the properties of each vehicle in the chain on programming time
2. the vehicle chain stays constant over time

imho it is already bad enough that Rheingold wagons change colours while you move them around in a depot, but having this happen at a station each time the engine moves to the other end of the consist is simply a ridiculous thought

They are all great and we would love to have them. They would break current GRF sets and those sets would require a rewrite. Are we prepared to rewrite them ? Maybe, but we would object to have your features implemented with little warning. If a new feature breaks existing GRF sets then there is trouble in the air.

exactly, that's why i warn you now so i can say "i warned you two years ago" when this feature gets actually implemented.

I don't think players would be happy, when building a passenger train to have to choose among 30 different passenger coaches with some being rejected because they do not fit the engine. They'd prefer to build the train using one type of passenger coach and then refit the train.

i think that can be addressed

e.g. the current system of building trains automatically attaches new wagons to an existing engine if it is the only engine in a depot. at that time, it could also automatically refit the wagon to the matching livery, but instead of current livery override, which will disappear when the engine gets moved away, it will be persistent, so if you want to switch the engine for an incompatible one, you will have to manually refit the wagons.

so, new wagons would be in a "virgin" state until they get attached to an engine, that engine then forces an automatic livery override, and any further livery override will need manual intervention, because livery override is now persistent

[PikkaBird]

It would be useful for set interoperability (or non-interoperability, as the case may be) to have the grfid of the grf a vehicle comes from available as an action 2 variable. Anything beyond that (oranges? coupling schemes? push/pull? livery refitting?) is getting unnecessarily specific - this discussion should be about giving tools to grf authors, not what the grf authors do with them.

[Eddi]

that is causing the same concerns that peter1138 voiced before, you have to update your GRF for every single other GRF that you want to have compatibility with, that is a total maintenance nightmare, so nobody will do it.

just assume this scenario: some graphics artist has an idea for a new vehicle that would fit into an existing set, now for the vehicle to be useful he has two choices:

1. get the coder of the set to include it [which typically gets the answers: "there is no space anymore" or "i already have vehicle XYZ that is too similar"]
2. build an own complete vehicle set around this engine [which is likely to fail for many reasons i won't get into now]

he cannot just code his vehicle into a grf and then "plug it in" with the vehicle set he designed it for. because there is no defined interface that "just works", because the sets seal themselves off from any vehicles unknown to them.

[michael blunck]

In the far future [...] with the total abolishment of a "front engine", there are "engines" [what ever vehicle has >0 power], and there are "wagons" [vehicles with 0 power]. a "train" would then be any consist of (nested) vehicle chains that contains at least one engine and the vehicle in "front" must be refitted with a driver's cab, whether it is an engine or not.

This is already the case in TTDPatch, at least from a user´s view.

i think you totally misunderstood me, i was talking from an implementation point of view, not from a user's point of view.

I understand quite well. So let me try agai: This is already the case in TTDPatch, not only from a user´s POV but by implementation. However, today, the "main" engine of a consist is always the first veh in a consist (same as in plain TTD and OTTD), but o/c that may change in the future. However, conceptually, there will be always one engine in a consist acting as the "main" engine (e.g., to which the schedule is linked, etc).

by "coupling" i mean any kind of standardised interface between components [...]

Well, this is going OT quite a bit too far, IMO.

[livery override]

As I already wrote, "wagon override / livery changes" is an elegant concept, relieving the player from the burden of managing dozens of different coaches/wagons for different engines or services. Given the fact, that many similar mechanisms have been explicitly introduced to ease player´s life (e.g., automatic renewal comes to mind), I don´t see that automatic livery refit would be given up for a load of superfluous work on the player´s side, only because that "multipool" feature would allow for an "indefinite number" of veh-IDs. I don´t see any relationship with the functionality of the actual feature of livery refit / wagon override, sorry.


Now, here´s a proposal for set interrelationship under the "multipool" feature.

- multiple sets may be loaded unconditionally. This would be useful for players wanting multi-regional or "world" scenarios. For this to work, the "global vars" problem has to be solved.

- vehicles (engines and wagons/coaches) from different sets may not be included into foreign consists except if a set does allow this in an explicit way (opt-in). For this to work, introduction of a new mechanism in .nfo, resp. the already existing GRM, is needed. This mechanism should allow to list veh-IDs which may be used together with "foreign" material by foreign sets. Only in this way it could be guaranteed that foreign sets do not spoil the complex interrelationship between engines and coaches of the own set. Obviously, this couldn´t be achieved the other way round, i.e., when listing IDs of the foreign sets which may be used by the own set.

E.g., the DBXL would allow usability of freight wagons, coaches and engines which aren´t interrelated in such a way that inclusion into a foreign consist or addition of foreign material to them would hamper their functionality. OTOH, combined vehicles, i.e., articulated engines and train sets may be used only on a "stand-alone base" by the foreign set but not included into foreign consists.

If that would not be possible for technical reasons, the fallback positions would be to only allow material from the opt-in list, regardless of their use as stand-alone or included into foreign consists.

regards
Michael

[richk67]

that is causing the same concerns that peter1138 voiced before, you have to update your GRF for every single other GRF that you want to have compatibility with, that is a total maintenance nightmare, so nobody will do it.

Hence my suggestion of grf classes in the same way as newstations have a class. Then, "friendly" grfs only need to belong to the same class - which would give you the security of longevity with no need to update the vehicle .grf every time one of its "friends" changes.

To give the .grf authors ultimate control, you then need 2 bits in Misc flags:
1) disallow cross-class usage
2) disallow cross-grf usage

Then, if as seems the case, a grf author wants to refuse all usage outside their set, then they can. Or they could limit it to the friendly sets within the class. Or they can allow it to be cross-used with any set in any other class.

It would also solve the user interface issue; you would have a selector - exactly as in newstations - where you choose what class to view, and would then only see the vehicles from that class.

[Eddi]

there will be always one engine in a consist acting as the "main" engine (e.g., to which the schedule is linked, etc).

i think that is a major point where we differ.

e.g. engine-switching scenario.

Imagine you are in the 1980's you have an express train "Karlex" going from Berlin via Leipzig via Plauen to Karlsbad (Karlovy Vary [ČSSR])
you have 3 places where you need to switch engines, because

1. Leipzig is a head station
2. in Reichenbach the electrification ends
3. the train crosses the Czech border

You have one chain of wagons that has exactly the above order list, and several engines that only have partial routes:

1. electric engine A:
   • go to Berlin and pick up a free 'Karlex' vehicle chain
   • go to Leipzig and leave all wagons behind
   • [... here wait for the wagon chain to free the platform, then pick up another free wagon chain to go elsewhere ...]
2. electric engine B:
   • go to Leipzig and pick up a free 'Karlex' vehicle chain
   • go to Reichenbach and leave all wagons behind
   • leave the platform and go to the engine yard to wait for another train to arrive
   • ...
3. diesel engine C:
   • go to Reichenbach and pick up a free 'Karlex' vehicle chain
   • go to Czech border and leave all wagons behind
   • ...
4. czech engine D - similar to the others

that way, you could build up an engine rotation independent from wagons, and a long distance train network independent from specific engines.

so which of these engines do you want to view as THE main engine?

[michael blunck]

e.g. engine-switching scenario.

In which variant of TTD/TTDPatch/OTTD does it exist?

regards
Michael

[Eddi]

in the future variant of OTTD, as i explained before.

[michael blunck]

in the future variant of OTTD [...]

Ah yes. So it´s not of any use to further discuss it in this thread.

regards
Michael

[Eddi]

on the contrary, this thread is entirely about the way how to address current and future features of OTTD and their implications on the NewGRF system.

therefore, now is the time to get a wide view of possible future developments to decide a system of flexibility so that the NewGRF system does not have to constantly adjust to any new fundamental feature.

[nautre125]

on the contrary, this thread is entirely about the way how to address current and future features of OTTD and their implications on the NewGRF system.

This thread is about the Engine Pool and the problems and concerns it raised.

[AndersI]

My immediate thought was a form of 'stepwise refinement':

1. There is already a 'classid' built into every GRF: its grfid. This can be used to filter vehicles in the buy window. An option switch can decide if this also affects connectability. This works with all GRF:s, old and new. Additionally, a GRF that reads the option switch can decide to deactivate itself if the value of the switch is not to its liking.

2. The next step would be a classid set by the GRF, for the whole GRF. In this way 'friendly' grfs can be shown together and connected together. This assumes the GRF is modified to include a SetClassId.

3. The last step would be to have the possibility to set classid on the vehicle level (any vehicle that doesn't have a ClassId of its own inherits the Classid of the whole GRF, if that is not set the grfid is used). Technically, this step is unnecessary, as the same function could be achieved by splitting up a GRF in many parts and applying point 2. OTOH, fewer GRF:s is better. This could also be used to simplify for the GRF authors even when no other pooling is used, as with this facility it would be easier to setup connection restrictions inside one GRF, without coding complicated conditionals. TTDP compatibility would be lost, though, if the ClassId concept is not developed there.

Some questions that just occurred to me:

What about GRF:s that modify the behavior of another GRF? Such useful tools as a GRF to change the release year of all the standard vehicles? Or adding ECS refit support to the standard vehicles (or any other set). Which set do they work on when enginepool is active? If there is a way to get this to work, how do you stop a GRF from changing the ClassId of an already loaded vehicle? Only allow setting the ClassId if it is blank?

I think it's lucky I'm not an OTTD developer...

[frosch]

@AndersI:
Property 11 in http://wiki.ttdpatch.net/tiki-index.php ... lVariables

@Others:
My suggestion towards the GRFID-VehicleID-party:
Unknown vehicles could be represented with the invalid ID 0xFFFF (already suggested above). If a newgrf wants to interoperate with an other newgrf, it could use a similar property as the above property 11 to map a range of vehicle IDs of other sets into the own ID space. E.g. specify a GRFID, a number of IDs and one or two start offsets, to map IDs <offset1>..<offset1+number-1> from <grfid> to IDs <offset2>..<offset2+number-1> of the active newgrf. The active newgrf then knows those vehicles and can modify their properties and identify them in callbacks.


However, personally I prefer the vehicle-class/coupling-class as it is more future-proof and does not need every newgrf to know every other newgrf. But it should not be compared with station classes. Cargo classes (with props like acceptable and non-acceptable classes) are a better example, as I would expect vehicles to allow multiple classes and reject other classes. Imagine classes like: Passenger, freight and (not compatible with other GRFIDs).
Passengers could identify themself to the passenger class, and OTOH decide independently if they are compatible to freight vehicles.
However multiple units would always be specific to a single newgrf.

[michael blunck]

Property 11 in http://wiki.ttdpatch.net/tiki-index.php ... lVariables

A really dangerous feature. Even more disappointing than what "multipool" already offers today.

If a newgrf wants to interoperate with an other newgrf, it could use a similar property as the above property 11 to map a range of vehicle IDs of other sets into the own ID space.

As already written, I think it should be the other way round, i.e. the .grf to be "used" would have to release certain (or all) of its IDs to the "user .grf" (opt-in). Other than that, it wouldn´t work because of possible internal interrelations inside the "used" .grf. Only the author of a .grf would be able (and hence should) decide which of its constituents may be used correctly from outside, but never the author of the "user .grf" (well, let´s introduce "master" resp "slave" .grf for now).

However, personally I prefer the vehicle-class/coupling-class as it is more future-proof and does not need every newgrf to know every other newgrf.

Read my proposal here or in the thread below.


BTW, because this thread contains too much OT meanwhile and is more or less concerned with improvement of this particular OTTD feature, I´ll post further comments in the more general thread set up by eis_os:
http://www.tt-forums.net/viewtopic.php?f=26&t=37870

regards
Michael

[OzTrans]

... train classes, cross-usage flags ....

I believe this would be a workable solution; we could have a class table and slots in that table made available in var act-2 chains. However, we would still need a method to identify individual vehicles, that are defined in different sets, but have the same class, as vehicle IDs still can be duplicates.

One step further could be sub-classes (labels), that identify vehicles as passenger, freight, universal, or push-pull etc.

... 3] splitting GRF sets ...

No thank you, I don't want to maintain separate GRFs for steam engines, diesel engines, push-pull capable vehicles etc. as the case may be. ECS Industries are an example and I don't think many players like that approach very much.

... overriding other GRF sets / Action0-General property 11 ...

Been there done that. You can only override one single GRF. Overriding properties across more than one set is not possible. You cannot override cargo transportability, the infamous cargo class, of say road, sea and air sets to make them work for you with ECS Industries.

I cannot see any useful purpose for that property 11.

[PikkaBird]

I cannot see any useful purpose for that property 11.

I believe the intended purpose is so you can make "addon" grfs that modify your own older grfs, rather than appearing alongside them. It's not intended that you use it to modify anyone else's grf.