Canadian Trains Set [v1.0 now available] ...

[michael blunck]

[OT]

[...] the new feature in OTTD that allows more than one train set to be active,

One of those not so useful features BTW, because it does encourage people to do something like this:

OpenTTD_5387_640_.png (18.7 KiB) Viewed 3420 times

Which is clearly a step into the wrong direction because that´s exactly what we had in TTDPatch, but 5 (?) years ago.

regards
Michael

[Ameecher]

ooo, nice

I wasn't arguing for the feature at all, I was just trying to help R-TEAM out in his explanation.

[andythenorth]

[OT]

Which is clearly a step into the wrong direction because that´s exactly what we had in TTDPatch, but 5 (?) years ago.

...well that screenshot just confirms that good taste is an unevenly distributed commodity!

Personally I'm looking forward to having multiple grf sets active in OpenTTD (can't yet - nightly builds won't start on my machine, don't fancy compiling). When it comes to combining new GRFs there's a bit too much 'which set can carry which cargoes'. Multiple newGRFs will deal with that, or perhaps I should stop abusing Can Set parameters to use it with PBI, and then my problem would go away

For example, the Canadian Set is a natural fit for the US Set (although there'll will be a lot of overlap). There are also many rail systems which have a mix of US/European/home grown vehicles, and mixing grf sets is good for that. Although I guess more vehicles is mostly just more eye candy

Getting off topic here - sorry.

[broodje]

For example, the Canadian Set is a natural fit for the US Set (although there'll will be a lot of overlap). There are also many rail systems which have a mix of US/European/home grown vehicles, and mixing grf sets is good for that. Although I guess more vehicles is mostly just more eye candy

Exactly, that is how I would use it, but there is more: Now it is possible to have multiple german sets for example: one for the S-bahn, one set for the main DB, one set for freight? you get my drift . Some heavy discussed trains could be added, which do not serve any real immediate gameplay (the BR23?) , but does serve the eye (although in my case eycandy is also gameplay).
And to get back on topic: the same could be done for the canadian set: separate the narrow gauge, and you free a lot of slots to play with.

[michael blunck]

Now it is possible to have multiple german sets for example: one for the S-bahn, one set for the main DB, one set for freight? you get my drift . Some heavy discussed trains could be added [...]

Well, I didn´t say that having more veh-IDs would be the bad thing, but to encourage people to add every rail set available to their list and mix everything which doesn´t fit together.

...well that screenshot just confirms that good taste is an unevenly distributed commodity!

IMO, that new feature doesn´t help developing "good taste".

regards
Michael

[Niek]

Someone's playing style or their taste shouldn't have anything to do with game development. I agree that using high speed trains for cargo is unrealistic and ugly, but it's possible in the original and everyone should be free to choose playing like that.

[michael blunck]

[...]I agree that using high speed trains for cargo is unrealistic and ugly, but it's possible in the original

Maybe in original TTD but not in TTDPatch when using a well-defined rail vehicles´ set.

and everyone should be free to choose playing like that.

Doh. The moot argument again ...

regards
Michael

[Snail]

I agree that using high speed trains for cargo is unrealistic and ugly, but it's possible in the original and everyone should be free to choose playing like that.

True... and and another true thing is, every set developer with some common sense should be free to prevent TGVs from pulling container trains.

[XeryusTC]

IMO it's very pointless to discuss about something as subjective as this. Some people like to play very realistic and others like to play with fast trains and stuff and nothing's going to change that. It is always said that discussing about difference in tastes is very pointless, and thus this is too

[OzTrans]

... what R-TEAM is trying to say here is that, because of the new feature in OTTD that allows more than one train set to be active ...

I gathered that much, but sometimes I like to play dumb ...

... multiple NewGRF engine sets or Dynamic Engine Pool ...

Just to clarify the situation. The CanSet cannot swim; I'm not going to teach it how to, I just keep it away from the pool's edge. We don't want any accidental drownings.

The manual has always said, that the CanSet is not compatible with any other trains sets. This is still the case ant it holds even more true with the introduction of the engine pool in OpenTTD. But, from tomorrow this will be enforced. No other trains sets, including TTD 'original' vehicles, will be allowed to be active while the CanSet is. It will try to deactivate all other trains sets, if it cannot it will deactivate itself.

Further to that, the set will be limited to known and existing game/patch revisions that have been proven to work correctly. We cannot afford to have a set like the CanSet to have its quality compromised.

So for TTDPatch players, that means 2.6 alpha 0 r1888 to r1895 inclusive; a very narrow window, but due to constant introduction of bugs [untested fixes and features] this is unavoidable.

OpenTTD players will have v0.6.0 and v0.6.1 (and its siblings) available. v0.7.x (the nightlies) is restricted to r12283 to r14000 currently, but if more problems are encountered it may be taken of the shelf all together.

Now, I'm not against that new feature, but as I cannot be held responsible for its very bad and crappy implementation, the CanSet requires that 'Enable multiple NewGRF engine sets' be turned off. I'm sorry for those of you who want to play with multiple road, air and sea sets; if you do, the CanSet is a No-Go.

I don't want to go into details what is bad and awful and how it should have been done (we, 'real' coders, are never consulted anyway), but below is a selection of problems that cause grieve to the CanSet. After I encountered those, I lost interest in taking 'photos' not to mention the asserts.

The feature was tested using the CanSet, USSet, Norwegian Set and TTO 'original' vehicles :

. Maglev and narrow gauge, do not mix well.
. US Set stuffs up rail crossings
. The Purchase list does not show what set the vehicles are from; that;s really bad for newer players.
. Where are the Norwegian engines ?
. Where is the CanSet Doodlebug ?
. US Gondola refittable to food !! I could accept sure-footed cows though.
. Huge problems with wagon livery overrides, generic callbacks, callback 1D (in particular), vehicle variables 42, 60, C6, F2 to name a few.
. CanSet's push-pull and speed features compromised.

... and the list goes on. But, I will not enter into any discussions or lodge bug reports.

Well, that's enough for today, have a nice day ... but keep your discussions civilised; CanSet v0.3e will be out tomorrow ...

[DanMacK]

Well, that about says it folks. I would love for this set to be available for the Dynamic Engine Pool, but unfortunately it's not. Apparently better documentation on this feature is required, as well as better compatibility, or it won't be implemented. I'm sorry, but it's not gonna happen.

Sorry guys, but no BN SD40-2's with the Canset at this time.

[belugas]

Maglev and narrow gauge, do not mix well.
. US Set stuffs up rail crossings
. The Purchase list does not show what set the vehicles are from; that;s really bad for newer players.
. Where are the Norwegian engines ?
. Where is the CanSet Doodlebug ?
. US Gondola refittable to food !! I could accept sure-footed cows though.
. Huge problems with wagon livery overrides, generic callbacks, callback 1D (in particular), vehicle variables 42, 60, C6, F2 to name a few.
. CanSet's push-pull and speed features compromised.

... and the list goes on. But, I will not enter into any discussions or lodge bug reports.

So, how can it be fixed if we do not know in details what to look for?
You have experienced in the past how placing a bug report can achieve its goal. I wonder what made you change your mind.
By the way, simply using bit 78 in ttdpach's flags for var 85 is not enough?

[athanasios]

Me goes and removes CanSet from my grf list...

[andythenorth]

Now, I'm not against that new feature, but as I cannot be held responsible for its very bad and crappy implementation, the CanSet requires that 'Enable multiple NewGRF engine sets' be turned off. I'm sorry for those of you who want to play with multiple road, air and sea sets; if you do, the CanSet is a No-Go.

That's a shame. In the short term, from the results you've demonstrated, I can see why: it's GRF soup, and it starts to look like a hassle - to play, as well as for you guys who code and maintain.

Looking ahead though, even if trains are a hassle, I reckon it's very likely there will be multiple RV sets that I would want to use (and maybe one day some more new ships...). If that means no Can Set, that's sad. Can the key issues not be resolved?

. US Gondola refittable to food !! I could accept sure-footed cows though.

Nah, that's ok - it's for really big spaghetti.

cheers,

Andy

[michael blunck]

I'm not against that new feature, but as I cannot be held responsible for its very bad and crappy implementation, the CanSet requires that 'Enable multiple NewGRF engine sets' be turned off. [...]

Me goes and removes CanSet from my grf list...

Well, it should be obvious that all developers of large sets, be it DanMack/OzTransLtd, Pikka, Wile, George, ..., and me have put an enormous work into our sets. Not only from a graphics´ artist point of view, but also from the layout and balancing of our sets, just to allow to play them "in the right way" - and only in this way we brought about the progress of "realism" into this old game.

IMO, this (the possibility to build and play in a more "realistic" way) is the most important development in TTD until now, and the majority of people seems to agree.

OTOH, there are a couple of people who don´t care about this: they´re always using the most powerful engines available, they don´t care if sets don´t mix well from a graphical POV (e.g., real liveries vs. cc liveries) or from technical stats. They like to tranport cattle with TGVs or ICEs.

From my opinion, sets should be used in the way the set developers designed them in the first place. Set developers had to make a choice which vehicles to be included into a set and how to use them, and the gamers will have to adapt to the "rules" of the sets (and in fact, newer sets make increasingly use of more rules, so the trend seems to be clearly towards "realism"). And that´s OK, because in general, by the specific way a set is developed, the set´s developer has gained much more insight as the occasional player, and thus sets the rules.

E.g., I didn´t design the DB set to be used together with SD-40s or the ICE having a top speed of 500 km/h (or, most horribly, to be used alongside TTD´s "original" rolling stock!). Every set is designed and balanced as a self-contained entity. In the best case, introducing "foreign" vehicles will break up the coherence of such a self-contained set, and in the much worser case, all kinds of bugs and flaws seem to be introduced, at least at the time being.

That said, to have more veh-IDs available is a good thing. Only the unlimited way it´s handled in OTTD ATM, doesn´t make much sense to me.

regards
Michael

[eis_os]

No other trains sets, including TTD 'original' vehicles, will be allowed to be active while the CanSet is. It will try to deactivate all other trains sets, if it cannot it will deactivate itself.

I can understand your problems, considering that I have all sets loaded at once to test the extended sprite limit patch, and to see if some changes on TTDPach breaks loading sets at all, this will result in more pain as Developer. I guess I will stick to the very old version that can be loaded together. (NOTE: Thats not for gameplay testing)

Actually I am totally against disabling other authors sets, you should disable only Sets you have written or there is an agreement. If authors start to deactivate other sets in a way they can't be reactivated and this will result in bad player experience TTDPatch developers will have to find a workaround...

Further to that, the set will be limited to known and existing game/patch revisions that have been proven to work correctly. We cannot afford to have a set like the CanSet to have its quality compromised.

I can understand this fully, but not by the cost that CanSet makes it impossible to load other sets. There are people who prefer to play with different sets. A reason TTDPatch got a grf status window in start screen options. Tell the people via error message this set can't be used with other sets and disable itself.

So for TTDPatch players, that means 2.6 alpha 0 r1888 to r1895 inclusive; a very narrow window, but due to constant introduction of bugs [untested fixes and features] this is unavoidable.

Imho, it's a shame you name bugs first, DaleStan does a great job. Actually most activity on TTDPatch is to fix bugs, make features work better, fix internal code to be less a hackish beast.
There aren't new features introduced in TTDPatch since ages /specially the train code wasn't touched). Actually TTDPatch developers and I think OTTD Devs simply have the problem that grf functions can't be tested by an automatic unit test system and simple there is not enough time to work on features and do a gameplay test with all sets.

[michael blunck]

the CanSet [...] will try to deactivate all other trains sets, if it cannot it will deactivate itself.

Actually I am totally against disabling other authors sets, you should disable only Sets you have written or there is an agreement.

I totally agree. Sorry, I didn´t mention this.

regards
Michael

[Ammler]

(maybe this part of discussion should be splitted out of that thread...) [from here]

OzTransLtd, the main and only wish I saw, afaik, is: if it would be possible to deactivate the narrow gauge part of your set. You can't mix trainsets from the realistic view, because of different balancing with basecosts etc.... yet.

But there is also a eye candy view. I would like to be able to play a scenario with canada train set and japan set (shinkansen) or DBSet Transrapid. Or you could play a Multiplayer game wich companies uses different sets. (Certainly not for cargo transport with a transrapid engine.)

You do also support disabling the industry part...

If someone needs to set parameters to disable something, he should know, that he changes your set and shouldn't be suprised about bad things, which could happen.

But maybe it is also possible for you and the other big set developers like MB and Pikka etc. to balance there sets together, so you could also do competition games with multiple sets and it doesn't matter which set you take.

The competition begins with choosing the right set (every set could have it's own advantages)

Greets
Ammler

[krtaylor]

Trying to somehow "balance" multiple disparate sets from all over the world, in an endless variety of combinations, would be an impossibly huge and wasteful effort. And, it would only apply to that small subset of players who a) use OTTD and b) don't care at all about playing realistically. What is that, 10%? 5%? Why should the set-coders double their effort to cater to this minority? It doesn't make any sense.

I do agree that trying to force other sets to disable is the wrong approach, if for no other reason than people who are trying to use them will wrongly conclude that the other sets are the trouble, and harass their coders for a fix that can't come from them because the cause is elsewhere. If as designers of a set, you don't want your set to be used in that way, then the proper thing to do is code your set to disable itself if there are other sets loaded.

It does seem, in principle, that it would be nice to allow multiple RV and plane sets, if for no other reason than RVs and planes do honestly mix a whole lot more than trains do. How many purely European trains are found on American railroads? Not very many - but European planes and RVs are commonplace. But the correct solution to that problem would be for the OTTD crew to split the switch in two - one for trains, and one for everything else. This makes sense because trains are far different than the other transport types in the game, in all sorts of ways, so it's fair for them to be handled specially.

[richk67]

Ah - good to see that "Trains Are God" attitude still prevails.

To me, it is simple; there should be a standard gauge CanSet, and a NG CanSet. TTDP users could then load both and have the full CanSet they know and love. OTTD users could pick and choose as their improved software allows. Probably MUCH easier to code/sort out than trying to add an optional switch.

As for the twoddle on user percentages... if OTTD "non-realism" users is down at 10%, then CanSet users must be approaching 0.001%. Its all tosh. Non-realism users (ie. original TTD users who do not use .grfs) massively outweigh any realism subset. (Check out the online servers - what proportion use vehicle .grfs? Its low.)

Personally, I far prefer having some future technology to play with - some of us have an optimistic view of the future, and I get far too much realism IRL to want to have it in my train/plane/boat set.

When adding a set of vehicles, I would have thought vehicle designers would jump at the chance of not having to choose between including loco A and not B; being able to have both is surely the way forward. Imagine a BR set, with 100 locos per era. To me, heaven. A heaven that is not possible on TTDP; sets that guarantee they cannot work in the multiple vehicle set environment of OTTD, to me guarantee I wont use them.