Engine Pool suggestions (making it more useable)

[michael blunck]

[...]

Seems the discussion goes the usual way now.


Well, let me summarise for you:

- the feature is flawed, because it affects user interaction (mixed up GUI, wrong composition of rolling material, ...)
- the feature is buggy, see OzTransLtd´s comprehensive posts.

And no, "we .grf coders" haven´t been involved in any way (in contrast to "were aware", or "had noticed", ...), else we would have pointed out many of these flaws during the process.

Meanwhile, there have been some good proposals by OzTransLtd and by richk67 (in the CanSet thread), but OTOH, I must say that I don´t find parts of Richard´s and most of Peter´s contributions of any help ATM.

It would be nice if these gentlemen would return to a more technical level of discussion.

regards
Michael

[richk67]

... The feature is flawed... buggy...

What part of my statement says otherwise:

The current facility is a raw beginning; some of the ideas here can give it more polish. Ultimately it comes down to the coder who does the work of coding the changes to decide what and how it works. All others are just, as they say in theatre plays, "Voices Off".

You cant have been expecting a finished solution the first time it hits trunk? Trunk is a development area after all.

OzTransLtd´s comprehensive posts are often phrased as a dictation of what MUST be there, many of which are designed to restrict game users. Not conducive to cooperative development. It would be nice if grf developers realised that players want flexibility, not restrictions.

As for what I will write about, I will express what I want, when I want, thank you. Or is it just that when you dont like what is said, your only retort is to say "shut up"?

[Draakon]

Remember guys, the game is made as a free will game aka where player can choose what to use, when to use etc not to limit them. This feature just opens our game more. Meaning that we must only make a sorting ability for the feature and use set x prices on set x trains only but not set y. The player is the chooser here, not others. What's so bad anyway when using set x, set y, set z and more sets together? It is suited for scenarios that are based more then 1 part of the world. Having the sets make incompatible together because of this feature is bad idea. It is the player that makes the choices, not the authors. It is the player if he want's to use CanSet for example with NARS, UKRS and JapSet. Removing the ability to use set x with set y and z for one feature that is very good in many ways is just stupid and not needed.

[michael blunck]

Remember guys, the game is made as a free will game aka where player can choose what to use, when to use etc not to limit them. This feature just opens our game more. [...] The player is the chooser here, not others. What's so bad anyway when using set x, set y, set z and more sets together? [...] Having the sets make incompatible together because of this feature is bad idea. It is the player that makes the choices, not the authors. [...] Removing the ability to use set x with set y and z [...] is just stupid and not needed.

It´s not useful to post your mislead opinion everywhere without having read (and possibly understood) the reservations and proposals of the .grf authors first.

regards
Michael

[Eddi]

i have to side with richk here. it is trunk development, there are bound to be a) bugs and b) missing/incomplete features.

consider the enginepool patch as the basic infrastructure, upon which the requested features need to be implemented.

then there is the question about which features should be implemented. it's a difficult task, because it should consider both compatibility with old grfs and a plan for the middle future.

the impression i get is that a lot of grf coders around here are guided by archaic (TTDP) systems, and cry outloud when a new development rips their god given limitations from underneath their feet. the engine pool patch is only the first instance of the flexibility that may come.

someone mentioned livery overrides. i think that is a real nightmare feature to build a set around, because it relies on a very important limitation: the TTD notation of there being a fixed "front engine". sure, it will probably be there for another couple of years, but it's bound to disappear at some point, because people find it too limiting. a good example for this limit are the hacks around the turning of trains that have been made recently. and it will certainly not end there.

i'm "dreaming" of real shunting here, where you have individual vehicle chains that may or may not contain an engine at all, that then can be chained together dynamically. "Easy" uses of that feature would look like this:

• Detaching an engine temporarily to let it drive to the other end of the train [possibly turning it around on a turntable]
• Attaching a helper engine to climb steep slopes
• Switching between steam/diesel and electric traction at the border of the electrified system

A little more elaborate would be dynamically gathering freight trains at central stations. "Realistically" [some people hate this word], it is also very common that a set of wagons gets picked up by an engine from a different company, especially at country borders.

Sure, it's all a dream for now, as [to my knowledge] nobody has even started coding on this, but imho it'll only be a matter of time. thus i think now is the appropriate time for grf coders and developers both to discuss how they want to maintain such a flexible system in the future, without relying on the fact that an architecturally forced limitation will stay there forever (and then acting surprised and overwhelmed when it is gone)

there are, however, gameplay or realism driven limitations that should be up to a grf coder to be enforced. for example, it should never be able to attach a cargo vehicle chain to an ICE vehicle chain, but i do not see a reason to not allow a regular steam engine to pull any kind of freight or passenger wagon, no matter from which vehicle set that wagon may come.

[michael blunck]

the impression i get is that a lot of grf coders around here are guided by archaic (TTDP) systems, and cry outloud when a new development rips their god given limitations from underneath their feet.

This is totally wrong but seems to be a common insinuation inside the "OTTD world".

.grf set authors had made numerous statements why they don´t like this feature in its current form and what they find important for themselves. Talking about "archaic (TTDP) systems" is just plain old rubbish heard numerous times before but would lead nowhere.

regards
Michael

[Eddi]

and of course you picked the least significant phrase to comment on

[michael blunck]

and of course you picked the least significant phrase to comment on

Well, if it was of such insignificance to you, why did you write it in the first place? OTOH, for me it was significant enough, that´s why I quoted and commented on it.

regards
Michael

[Eddi]

no, it is of course not insignificant, but maybe it was slightly overgeneralised or exaggerated.

but you cannot deny that the case at hand (CanSet) is an instance of this problem. There is this brand new feature [which was btw. in development and announced for over a year now], and the first reaction to it is "oh, this breaks some fundamental assumptions of my set, i will deny the existence and any possible benefits of this feature", while it was simply intended to give more options and variety [which i thought grfs were all about]

[michael blunck]

you cannot deny that the case at hand (CanSet) is an instance of this problem. There is this brand new feature [which was btw. in development and announced for over a year now], and the first reaction to it is "oh, this breaks some fundamental assumptions of my set, i will deny the existence and any possible benefits of this feature", while it was simply intended to give more options and variety [which i thought grfs were all about]

Well, yes. Firstly, it were the Canadian Set guys and their decision which you´re talking about, not me and my sets. Secondly, yes, I´m sharing the same concerns as they do and, BTW, I´m 100% sure that each of the "large" set authors will have their reservations, at least with regards to the current state of that feature.

With regards to "more options and variety", I´m not sure what you´re talking about.

Mind you that TTDPatch had that option (using different train sets concurrently) for years but it was found contradictory to the needs of grf authors and the majority of users, and thus GRM (graphics ressource management) was introduced into TTDPatch. Now, OTTD is in a comparable situation, but still lacking a similar management mechanism for concurrent .grfs.

With regards to "variety", I don´t share your view. The "multipool" feature (when allowing concurrent sets to be used in an "unlimited" fashion) will indeed hamper variety, not improve it. Variety (in TTD) is introduced by additional features ("realistic acceleration", "waggonspeedlimits", "livery override", diverse "restricting" callbacks, ...) and the controlled limiting function of them, thus generating "niches" for every vehicle in a set. Without it, you´ll loose the built-in coherence of a set and "flatten" your games, something I wouldn´t describe as "more options and variety". The sheer number of different vehicles available isn´t decisive for a good game.

regards
Michael

[richk67]

The sheer number of different vehicles available isn´t decisive for a good game.

For you - that is your *personal* opinion, not shared by this poster at least (and obviously several others on this forum).

The demands for limitations on the feature come across as dictats from the elite.

[Eddi]

indeed, limitations are what drives a game forward. for example i never use the "engines do not expire" option. but not all limitations may reliably be coded into a grf, some limitations are the ones the player imposes. in context of the engine pool, that may for example be to limit the usage of a set by region. e.g. a central europe scenario where you use dutch, german, austrian, czech and polish vehicle sets, but only in their appropriate region. or an alpine scenario where you use german, swiss, austrian and italian vehicle sets. similarly, you might want to use different tram sets in different cities.

at that point, you should trust on the fact that the player will enforce the rule to keep the gameplay [variety] alive.

i often view (Open)TTD as a replacement for a model railway, and model railways are usually about "themes", not about building a competitive gameplay. this is imho an important matter to consider when building a set, to allow a player to disable some limitations for more "sandbox" style of game.

a negative example for this is the ECS implementation by George, it enforces efficiency rules [especially on closing industries] which do not match the difficulty level that some people want to play [get big a variety of cargo rolling, without looking at efficient transport ratings]

[michael blunck]

The demands for limitations on the feature come across as dictats from the elite.

Your latest contributions only come across as sinuations but not as helpful comments in any way. It should be obvious that .grf authors want to have their sets presented in the most correct way, even in OTTD. I don´t really understand why you have a problem with that.

regards
Michael

[broodje]

For you - that is your *personal* opinion, not shared by this poster at least (and obviously several others on this forum).

Yep exactly, his opinion, the problem is, he is also the developer of the set, so he can do as he pleases, As he should be able to do, it is his set after all. If you want to play games with tons of the same engines, with only different visuals you can use other sets can't you? I find it rather silly that the majority should decide (or maybe even force) how a grf creator should make his set.

[michael blunck]

"engines do not expire" option. but not all limitations may reliably be coded into a grf, some limitations are the ones the player imposes. in context of the engine pool, that may for example be to limit the usage of a set by region. e.g. a central europe scenario where you use dutch, german, austrian, czech and polish vehicle sets, but only in their appropriate region. or an alpine scenario where you use german, swiss, austrian and italian vehicle sets. similarly, you might want to use different tram sets in different cities.

Indeed ...

Nevertheless, there´s also the legitimate wish to use trains from different sets in a more serious way, even - or indeed most interesting - for the "realistic" players. In many European countries we have a high degree of cross-border traffic, with e.g. TGVs running into Switzerland and Germany, ICEs running into France and Belgian, Polish and Czech trains running into Germany, etc., pp.

So, what we need would be a flexible interface to allow cross-set usability. What we don´t need is an amorph mass of incompatible train set vehicles in our games. [...]
http://www.tt-forums.net/viewtopic.php?p=695136#p695136

i often view (Open)TTD as a replacement for a model railway, and model railways are usually about "themes", not about building a competitive gameplay. this is imho an important matter to consider when building a set, [...]

Indeed, that´s just what I do.

a negative example for this is the ECS implementation by George, it enforces efficiency rules [especially on closing industries] which do not match the difficulty level that some people want to play [...]

Yes, George´s implementation is rather over the top, IMO. My own implementation will be less ambitious/nit-picking.

I find it rather silly that the majority should decide (or maybe even force) how a grf creator should make his set.

In the good old days, everything had been discussed with the audience on the TTD news group and on the TTDPatch mailing list. Nearly nothing was introduced without prior discussion. O/c that were the days of the "elite" ...

regards
Michael

[Draakon]

Still the problem with the Engine Pool for OpenTTD doesn't mean that "Hey! Its the end of the world! They have done it! Quick! Disallow our set with other sets to be loaded" should be done.

BTW, where is this new action or callback documented that disallows a certain set to be used with others sets? AKA like CanSet uses.

[Eddi]

I find it rather silly [to] force how a grf creator should make his set.

that is exactly the problem of the discussion, there are at least 3 partys involved here [game devs, grf designers, players], and each side thinks the other side forces things upon them. there needs to be a sensible discussion to find a good compromise that each side has the impression that they have enough freedom to develop/design/play the way they like it the most.

In the good old days, everything had been discussed with the audience on the TTD news group and on the TTDPatch mailing list.

you will probably find that the community has grown significantly since then, which creates several communication problems

[richk67]

The demands for limitations on the feature come across as dictats from the elite.

Your latest contributions only come across as sinuations but not as helpful comments in any way. It should be obvious that .grf authors want to have their sets presented in the most correct way, even in OTTD. I don´t really understand why you have a problem with that.

To quote Bananarama: "Its not what you say, its the way that you say it."

One man's "correct" way to use a set is another man's intolerable restriction. I dont really understand why you have a problem understanding that.

Many sets have had this fetish for getting rid of monorail, and maglev. 2 reasons usually "I need Vehicle IDs", "I dont like the unrealism of them". The first of these is eliminated entirely by the Engine Pool. That only leaves the second, which is a personal flavour/fetish of the author. Should a vehicle grf author prevent a player from adding those vehicles if they want them? I say, "No Way".

Most of this is a matter of philosophy; there is a TTDP philosophy, an OTTD philosophy, a grf author twist, a developer twist, and a player twist. Not incompatible, but it sure comes across from this that one particular group wants to exert its superiority, and if it doesnt get its way it will take its toys away and play on its own.

[Rubidium]

After seeing this whole discussion I am (personally) wondering why having multiple vehicle sets is such an enormous problem whereas having multiple station sets is not. With multiple station sets one can also build station sets that do not match or even make the station look different than what it was supposed to be.

So shouldn't the same method you are proposing for the Engine 'pool' also be applied to stations, houses, cargoes and industries? This way a set author can force that his/her vehicle set may only be used with only a specific station and industry set.

[michael blunck]

One man's "correct" way to use a set is another man's intolerable restriction. I dont really understand why you have a problem understanding that.

Well, obviously I´m talking about my own sets and the way they should work under TTDPatch and OTTD. "Correct" in this context meaning they should work as designed. And this, o/c, is not a solitary decision of my own (in an elitist way), but it´s a result from a cooperation with the interested audience (aka fans of the DBXL), as can be seen from the discussions in that particular thread here on tt-forums and on the german tt-forums.

regards
Michael