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

[michael blunck]

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.

Good point.

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.

E.g., by extending GRM, we could introduce something like "friend" and "foe" .grf-IDs, i.e. sets which may resp may not be used together. In fact, this is an old idea. E.g., I´ve discussed something similar with Hyronymus for the NS and the DB set years ago.

In this way, more realistic scenarios could be created with, e.g., German and Dutch/Belgian or Swiss and French vehicles. And in the same way, you could easily avoid the US and the DB set being used together. O/c, set designers would need to adapt their sets if to be used together, but that shouldn´t be a problem with a solution far better than the current is.

regards
Michael

[Vikthor]

It's seems to me that lot of people here lives with assumption that trains do not mix. While this might be true for Northern America and probably other continents it's completely false for Europe. To name a few cases: ČD 680 Pendolino in Austria, ÖBB class 1116 Taurus in Brno or Ljubljana. Just look on Railfan Europe http://www.railfaneurope.net/pix_frameset.html. Or see video with DB ICE-3 in Paris http://www.youtube.com/watch?v=hwDjHjUKaK8. Or look at Eurostar...
And with European Union pushing for liberalization of railway transportation we can expect this mixing to continue.
I as a player really welcome dynamic engine pool because when used sensibly it allows for more realism, not less. That said, there is probably room to improve it, but that won't be achieved by ignoring it or even trying to convince everybody how bad it is.

PS: It might be good idea to split this discussion.
EDIT: Hmm it took me far too long to compose this message, Michael was faster.

[eis_os]

Hmm, my plan was to introduce a new post for it but ohh well.

The current state of Sets are quite incompatibly because all use a different Realistic Models (including different sense of economy). You simple can't put together different GRFs, they will set different base costs /multiplier as example. It's like putting Mars and Earth and Toyland together and wonder why it won't work

The DBSet as example uses other offsets to the rail pieces. (So you can't connect different rolling stock after all).

Actually my wish would be some common ground. (The base cost system of TTD actually was meant to set the difficult level).

GRF Authors tell us they create Vehicle Sets, ok, but why do they change the economy too? *

Say we have a eu-economy.grf - It's responsible for the difficulty settings a game have, so it's responsible to set the economy bases and how hard the game actually is. It's not responsible of a vehicle (specially a rail only ) set to screw the cost system of TTD. And all eu sets will require this grf. (It has to be common sense, please no ECS like bunch of grfs, then starting complaining it doesn't work otherwise and it's the Dev fault.
Request a feature then and wait for a O)TTD(Patch Dev to allow creating a base for all sets)

Currently all Rail Sets influences somehow the economy and other settings that may or may screw other aspects of the game, this actually won't work if you try to share rolling stock.

(Actually I still don't know why we don't have a common freight set for the eu region, even if I have to tell it what other Set I use)

Next part, there is no common sense about sizes and offsets. You can't attach Michaels wagons as example to a different sets engine. (yes this was a repetition) And sorry Michael, but DBSet is still my favorite so it works as base for me describing stuff

----
* I know why the grf authors do it, but please think about it, it is still wrong, the difficult setting is not a grf setting but a players setting... I know specially Michael has an different opinion about it... still my standpoint is: TTD(Patch is not an simulator, it's the players decision how hard a game should be...

[michael blunck]

E.g., by extending GRM, we could introduce something like "friend" and "foe" .grf-IDs, i.e. sets which may resp may not be used together.

Well, a very simple approach is already possible by defining those "foe" .grf-IDs and take silent leave if encountering anyone of them. A better solution would be to have one .grf as the "master" .grf and define others as "slave" .grfs allowing to define exactly which veh-IDs from those may be used.

[...] with European Union pushing for liberalization of railway transportation we can expect this mixing to continue.

One problem might be that that´s not generally true for the past.

regards
Michael

[richk67]

E.g., by extending GRM, we could introduce something like "friend" and "foe" .grf-IDs, i.e. sets which may resp may not be used together.

Well, a very simple approach is already possible by defining those "foe" .grf-IDs and take silent leave if encountering anyone of them. A better solution would be to have one .grf as the "master" .grf and define others as "slave" .grfs allowing to define exactly which veh-IDs from those may be used.

This reminds me greatly of the Class concept used for newstation (and NewGRF_ports) .grfs. The vehicle .grf could have a class such as "USCA" for the USA/Canada sets, and "EURO" for mainland europe, "EUUK" for europe and UK sets. Then rolling stock could only be bought and used between vehicles in the same class.

Perhaps also include a flag in the Misc settings of the vehicle to indicate whether cross-Class usage is allowed.

This gives the option for those who want it, and limits the rolling stock to the appropriate vehicle sets.

[michael blunck]

GRF Authors tell us they create Vehicle Sets, ok, but why do they change the economy too? * [...]
* I know why the grf authors do it, but please think about it, it is still wrong, the difficult setting is not a grf setting but a players setting... I know specially Michael has an different opinion about it... still my standpoint is: TTD(Patch is not an simulator, it's the players decision how hard a game should be...

Well, I´m doing it simply because with original TTD base costs I cannot get "realistic" purchase prices for engines and wagons. Especially the base cost for wagons/coaches is ridiculously low. But o/c, the player is able to change the net prices by setting the difficulty level as usual.

The vehicle .grf could have a class [...] Then rolling stock could only be bought and used between vehicles in the same class.

Perhaps also include a flag in the Misc settings of the vehicle to indicate whether cross-Class usage is allowed.

These are good suggestions.

regards
Michael

[OzTrans]

An Update of the Canadian Trains Set v0.3e [30 May 2008] has been posted; get it here.

What's new ?

. some gondola sprites were incorrectly aligned; fixed.
. CPR 'Cartier' ore train: ore hopper 'modern' now refittable to 'Cartier' livery if attached to a CPR MLW M636 engine.
. new ore hopper 'modern' liveries, CPR 'Hawker Siddley', ONR 'Progressive' and 'Chevron'; added.
. set internal cargo types had incorrect bit mask settings; fixed.
. set internal logic redesigned to allow for many more company liveries; stage I implemented *).
. a lot of housekeeping.
. set deactivates and issues message, if activated in wrong environment; i.e. WIN/DOS.

NOTE:

TTDPatch players : CanSet v0.3e now compatible with TTDPatch version 2.6 alpha 0 r1888 to r1895 [inclusive] only.

The MLW RS18 and GMD FP7 ONR Northlander will be updated at a later date.

... no BN SD40-2's with the Canset at this time ...

What does that mean ? There is nothing stopping you to have another livery for the SD40-2.

*) BTW, you can start thinking about extra wagon liveries (especially freight), a large number of slots (sprite IDs) have been freed now.

Comments re rest of discussion to follow in due course ...

[andythenorth]

Re: Running costs. I think that they and the purchase costs need to be adjusted somewhat, and andy's suggestions make A LOT of sense.

Do the set developers have an opinion on whether the set should be played with Inflation on? It's causing me some revenue problems with trains.

I have been playing an OTTD (6 RC1) game since about 1903. I'm currently in 2042. I normally get bored and start a new game by about 2000, but with the CanSet and Generic Road Vehicles it's definitely more fun - there's plenty to do.

The problem I have is that nearly all trains have been losing money since about 2020. Running costs on a GEVO are something like $9.5m per year, and it's impossible to turn a profit with freight. The routes are sensible lengths; the trains are about 20 tiles long, they fill quickly, they travel at or near top speed, and they don't encounter delays. Passengers are better, but trains that were banking $18m per year are now bringing in more like $10m (although no complaints there).

I'll emphasise a couple of points:

• I'm not playing to make stupid money, that's too easy: I have planes bringing in $50m per year, I could build a hundred more if money was the goal. I want an interesting variety of transport routes, but not ones making a loss.
• It seems as though running costs increase disproportionately to revenue. This is more likely to be an OTTD issue than Canset, but I thought I'd raise it here first to get the set developers' opinion.
• If turning off inflation is the recommended solution that's no problem.

I have an inkling that the problem would be reduced, but not solved by possible future tweaks to running costs. IIRC, the running costs on diesels are (subjectively) about that twice that of steam. I have a bunch of trains losing about $6m / year with a $9m running cost, but if the running cost was half ($4.5m) I'd still be losing. These *are* definitely classic money-making TT routes.

So in summary, I'm about to start a new long game with CanSet and am wondering whether to turn inflation off. Thoughts?

[OzTrans]

... inflation or no inflation ...

Whether you play with or without has no bearing on your profitability or lack of. I play without, because inflation clouds my mind.

Playing the CanSet (in TTDPatch) has given me (on average) running costs of about 35 % in early years and 25 % in the 1940s compared to train revenue. That is quite good. The train list is from January 1948. Almost all trains are steam driven. There are big winners (long distance fast passenger services) and big losers (short distance freight feeders with lengthy loading times). Some are double headed, they need to cross the Rocky Mountains, others are allowed to use the base tunnel. The future will tell what diesels are like.

Now, revenue is not controlled by vehicle sets, it is determined by industries, distance travelled and time taken. May be there is something in Open that is different to the Patch.

In the next update I want to address the purchase and running costs. Can I ask you, to play a game in OpenTTD with inflation off, difficulty settings of running costs and cost of construction set to high. That will make comparisons to my game possible.

Save the game on every January 1 (or thereabouts); keep all these saves but send me saves after each decade (every 10 years) together with a copy of openttd.cfg.

This way, we should get some ideas where we can improve the set.

[peter1138]

Whether you play with [inflation] or without has no bearing on your profitability or lack of.

Actually it does, as the inflation rate on cargo payment rates is 1% less than inflation on all other costs. I don't know if this is an OpenTTD or original TTD feature though, but from the lack of understanding in the comments, I suspect the same applies in TTD too.

[andythenorth]

...the inflation rate on cargo payment rates is 1% less than inflation on all other costs. I don't know if this is an OpenTTD or original TTD feature though, but from the lack of understanding in the comments, I suspect the same applies in TTD too.

That that explanation does fit what I've experienced. After 140 game years that 1% could make quite a difference to the gap between running costs and income.

In the next update I want to address the purchase and running costs. Can I ask you, to play a game in OpenTTD with inflation off, difficulty settings of running costs and cost of construction set to high. That will make comparisons to my game possible.

Yep, will do. Can you recommend a freight weight multiplier and any other patch settings you want to control for.

[OzTrans]

... the inflation rate on cargo payment rates is 1% less than inflation on all other costs ...

That makes a big difference and most probably is the problem of reduced profitability. What can we do about it ?

... test game ...

I personally use a freight multiplier of 5; which works well for me.

Other settings :

Normally, I choose the hard difficulty level. Then turn the AI and disasters off and set breakdowns to none, I still have all trains auto-serviced every 5 months.

Now, I just noticed that the vehicle running costs are set to medium in both hard and medium games (same in OpenTTD); so that means I have been playing with running costs at medium level and not high as intended. Therefore, could you set your cost of construction to high and running costs to medium.

Otherwise, go with whatever settings you like. In the end I'd like to know can a player maintain profitable services over time, but not too profitable.

[Draakon]

Why did you make it disable this and all other train set when this and other has been loaded with the text: Not Compatible? Its outrageous. Yes you may think that its wrong, bad etc, and i don't have anything against that you think so. But that doesn't mean you must make it disable it or others when loaded with others. Its an users free will to choose what he wants to use(i mean what train set to use and what not). You should remove the boundary of what i am talking about.

[andythenorth]

Why did you make it disable this and all other train set when this and other has been loaded with the text: Not Compatible? Its outrageous. Yes you may think that its wrong, bad etc, and i don't have anything against that you think so. But that doesn't mean you must make it disable it or others when loaded with others. Its an users free will to choose what he wants to use(i mean what train set to use and what not). You should remove the boundary of what i am talking about.

Jumping in here (and I have nothing to do with the hard work of creating the Canadian Trainset), there are two possible evils:

• Evil 1: Oz disables the grf with other trainsets, and lots of players are pissed off that they can't use the grf in this way. Over time, more and more players expect to be able to use multiple trainsets, and eventually the CanSet is only used by a small minority of hardcore fans.
• Evil 2: Oz doesn't disable the grf, and lots of players constantly file a stream of bug reports, which drives the set developers nuts, and causes users all kinds of gameplay problems (it's not nice when you have to abandon a good game because of grf incompatibility that only becomes obvious after 20 years of game time - for example, a conflict between IDs that means you have nothing to haul a certain cargo at a sensible speed and cost).

The best outcome would be the following non-evils:

• Grf developers and OTTD developers figure this out and get a good architecture in place. This would involve something simple like classes. There are only a small number of active grf developers, it wouldn't be too hard to figure out a couple of 'families' of compatible grfs. Nothing should be too tightly coupled i.e grfs shouldn't become dependent on each other and have to be maintained against each other. I know nothing about grf coding, but I know a bit about the social dynamics of creating code, and tying different grf sets together too closely will be a nightmare of decay and fragmentation.
• Users who don't contribute code / grfs just keep quiet for a bit (no whining) and live with the limitations.

If Oz wants to restrict CanSet vehicles from mingling with other GRF sets, that remains his right, no-one else's.

I personally would like to have other rail vehicle options available. In my view the ideal solution would be managed in gameplay: other grfs could be used with CanSet, but if a player tries to mix vehicles in those sets with CanSet vehicles, then they would get a message "This vehicle type can not be used with this locomotive" etc.

Another idea would be that the CanSet gets a lot bigger, including a lot of other North American trains.

But the proper place to discuss that further is here: http://www.tt-forums.net/viewtopic.php?f=32&t=37812

cheers,

Andy

[LordAzamath]

• Evil 1: Oz disables the grf with other trainsets, and lots of players are pissed off that they can't use the grf in this way. Over time, more and more players expect to be able to use multiple trainsets, and eventually the CanSet is only used by a small minority of hardcore fans.
• Evil 2: Oz doesn't disable the grf, and lots of players constantly file a stream of bug reports, which drives the set developers nuts, and causes users all kinds of gameplay problems (it's not nice when you have to abandon a good game because of grf incompatibility that only becomes obvious after 20 years of game time - for example, a conflict between IDs that means you have nothing to haul a certain cargo at a sensible speed and cost).

You call it evil? Atleast canadian set isn't disabled for all openttd anymore.. Which would be kinda evil..

[Ammler]

Heya, just updated to version e and have a small bug to report:



As you can see, I have no other set loaded but can't use your set anyway.

I guess, you just check if the patch "engine pool" is activated, I would then suggest, you do not disable it, else you do just print a warning, but let the GRF loaded. (So you can still use multiple Trams.)

Edit: You should at least mention that in your release post, So users who play with OTTD trunk knows, not to update to "e". (And if they do, they do not have to complain about, like me

Edit2: Sorry, wasn't aware, that is only a political decision, nothing technical. (But that is sad.)

Your set is one of the most powerful eyecandy sets availabe at the moment.

Edit3: /me is looking forward for "f".

Greets
Ammler

[Draakon]

I know its authors of decision to do so, but i can't see a reason here why block it because of loading multiple sets? If it because of the costs issue then CanSet isn't the only problematic set with this problem. Every other set has it too.

[michael blunck]

I know its authors of decision to do so, but i can't see a reason here why block it because of loading multiple sets? If it because of the costs issue then CanSet isn't the only problematic set with this problem. Every other set has it too.

If you (still) don´t understand then read again the arguments given here and in that other thread Andy pointed to.

regards
Michael

[Draakon]

*sigh* You guys seem to fail to understand why Engine Pool was made.


Also, this set is ruined now.

[Toni Babelony]

Also, this set is ruined now.

Shabang! Smack in the face! All your hard work has been in vain! Artists, coders en developers, you may go home now.

--

I still think it's an awesome set and it doesn't need any other set to contribute to it's awesomeness. It's just that awesome! Did I already say it's awesome, though it's a pity for those who want to combine it with other sets. So be it.