Transport Tycoon Forums

Our current problem is how sets could work better together and maybe even sharing rolling stock.
The big sets are currently very incompatible and each set has to provide always all rolling stock.

Current Problems we face today.

- different base cost and multipliers
- different sense of econommy
- depot offset differences
- rail offsets differences
- how to deny cross set coupling of non engine/wagon combinations

We can see this with the Engine Pool system introduced by OTTD.


Solutions:

- classes for vehicles (EU/DACH/US/AUST) You can't put together trains with different classes. (richk67)
- maybe changeing the cost multiplier to be larger? (eis_os)
- classes for different coupling systems? TGV/ICE/DEFAULT? (eis_os)
- shared economy grf (eis_os)
- use GRM to allow certain vehicles be used by foreign sets. (Michael)

Non Solutions:
- Disabling other sets. (This is not allowed usage of grf features in the sense of Developers)
- Simple allowing all sets to be put together. The base cost problem simply shows it won't work



I try to collect all possible solutions/ideas here in the first post.

[excerpt from OTTD "multipool" thread]

[...]

- 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

I guess coupling class could consist of two "LABEL" arrays internal and foreign, if foreign is set to 0. It can't be used outside. As bonus a grf author could use less veh id based testing if a wagon can be attached to an engine.

-edit-
A different concept would be to allow some kind of static id for an engine, wagons can say, hey I am allowed to be used with an specific coupling class or with the Engine called TGVENGDUPLEX. So to get a formal language how to describe relations between Engines and Wagons. Currently we don't have that concept, only implicit by local callback code...

well ... in my eyes is the first thing that needs to be solved is the price-issue.

Not sure what would be the hardest, but i think this is the easiest...

Let "us" grf devs agree upon some set ranges for:
Purch price
Running cost

and perhaps even include this in the wiki tutorial or something

the 2nd thing that somewhat annoys me is what wagons to use on what set.

it _could_ be smart to either include some tabs on the purchage GUI in openTTD, and let each set get it's own group. This might need some new action 4 name or something ... typical 4 letter words. DFLT, DBXL, UKRS, NARS, NORW, SWE_, 2-CC.
Or:
"we" grf devs could name the engines/wagons in theese sets ... dbXL-Ice3, dbXL-BR182 or similar.

For this, only OTTD would need to show some grf specific text (much like newstations in TTDPatch) for each GRF as category.

About running costs, already asked for stats in the CanSet thread

About the base/multiplier cost, i had a few thoughs on the subject.
I have to say it's not clear as what can be done about that.

The idea is that right now, due to the CanSet event, everyone is talking about the vehicles costs that need to be isolate, in order to prevent damages. That problem is not directly related to engine pool, must I specify. It has always been there.

So, yes, one can imagine that vehicle base/multiplier costs should be isolated. But then, what's next? What other costs will be "required" to follow the same path? There are 49 base costs in the system. Which ones will be required to be isolated? And if ever all of them are, how can the game is going to be using the proper ones on sections that are not directly controlled by the grf who introduced them?

Ex.: CanSet (just an example) decides to change terraforming costs. As well as all engine related ones. How can the system will know which, from the standard or the one that Canset defined, will be used? Simple. It cannot.

So it comes to the point where one would think that isolated costs should be specific to certain features, and not just vehicles. But such a system will need to be defined. Otherwise, it wold be fruitless. And unfair for those who are delivering other thatn vehicle sets. Like stations, industries, houses, bridges etc...

belugas wrote: unfair for those who are delivering other thatn vehicle sets. Like stations, industries, houses, bridges etc...

There are more global vars rather than only for vehicles: tile refresh offsets, misc .grf features, locale-dependent settings.

regards
Michael

Well my post was more TTDPatch/NewGRF centric, we have / had the problem with TTDPatch. If I remember right, LongVehicles did change basecosts too. This is no an engine pool problem, I request a common freight rolling stock since ages. (Michael and me talked about the vehicle cost model before OTTD exists, actually I had a game transferring from TTD to DBSet vehicles with all kind of tiny problems)

As I said in the CanSet thread that Vehicle Graphics shouldn't change the economy.
My idea is a common shared economy model, eu.grf as example. All Eu centric GRFs will agree on it.

michael blunck wrote:

belugas wrote:unfair for those who are delivering other thatn vehicle sets. Like stations, industries, houses, bridges etc...

There are more global vars rather than only for vehicles: tile refresh offsets, misc .grf features, locale-dependent settings.

I am well aware of that, michael. But right now, i'm talking about costs.

eis_os wrote: As I said in the CanSet thread that Vehicle Graphics shouldn't change the economy.
My idea is a common shared economy model, eu.grf as example. All Eu centric GRFs will agree on it.

When modifying certain base costs (e.g., for engines/wagons to get purchase prices right) it is often unavoidable to change even more base costs (e.g., building cost for track, signals, ...). O/c, no train .grf should change base costs for other vehicles ...

I doubt that a "common shared economy model" would be suitable. It is a common myth to believe that all European railway systems should have similar costs, in contrast to the US, e.g.

regards
Michael

eis_os wrote:Well my post was more TTDPatch/NewGRF centric, we have / had the problem with TTDPatch. If I remember right, LongVehicles did change basecosts too. This is no an engine pool problem, I request a common freight rolling stock since ages. (Michael and me talked about the vehicle cost model before OTTD exists, actually I had a game transferring from TTD to DBSet vehicles with all kind of tiny problems)

As I said in the CanSet thread that Vehicle Graphics shouldn't change the economy.
My idea is a common shared economy model, eu.grf as example. All Eu centric GRFs will agree on it.

Oskar, I agree that it is not an engine pool problem. I'm merely saying that it has grown out of proportion. It's just that it is a matter that should be addressed.
Now, i'm sorry if I came in here and gave my opinion to something, but may i remind that it's michael who diverted the discussion to be followd in here? I do not mind getting out of here and continue elsewhere, but i guess this elsewhere should be somewhere where everyone who has something meaningful to say. Unless i've misinterpreated the beginning of your post... of course...

Base costs or multipliers? (As noted, it may be necessary to change newgrf to make the multipliers larger)

Belugas, no, but I don't want to say it's a engine pool problem, or a OTTD problem. It's simply the model currently doesn't work in TTDPatch either.
Again, I want to correct that - I don't think that it is an engine pool problem or an OTTD problem but a general TTD problem-

Still the solution should be general to work without engine pool if possible.

-edit-
I still think that changing the base cost is simply wrong, again the best thing would be a solution without changing them. Still we don't have a solution. The only what grf authors tell us (sorry to be a bit harsh) it won't work. I guess there is no real pressure.

belugas wrote:may i remind that it's michael who diverted the discussion to be followd in here?

If this isn´t the appropriate place, we could move elsewhere. But lets try not to discuss the same problems in more than two threads.

I think it should be obvious that I - as a train .grf developer which is (and will be) used both in TTDPatch and OTTD - have an interest in this discussion.

regards
Michael

I never said I don't want this discussion and I never said I don't want OTTD Devs here, actually I want the real opposite, simply forget OTTDs current engine pool as point of critique and find a solution that doesn't depend on engine pool doing a lot of magic or actually doing special gui work. I still think newgrf should not depend on GUI implementations problems.

I do completely agree with both of your last posts, Oskar and Michael

The current problem is more than just "GUI implementations problems". The real problem is that the address space for veh-IDs has grown, with the consequence that one may load .grfs concurrently - a situation we had already before in TTDPatch. Back then, the answer of .grf developers had been the extension of their sets to fill the available address space. Guess why?

Now, this wouldn´t be a solution here because of the large number of available IDs. And that´s why we need some mechanism to allow for cooperation of concurrent sets. (If we really want this at all.)

GUI problems are minor problems in this context.

regards
Michael

Some note to Michael, TTDPatch could as well deny any changes to global properties if there are different ways to get to resolve most common problem. (or simply ignore them). It still was a bad idea to allow GRF Authors to hack into the TTD internals directly.

Tile refresh offsets is actually a bad example (wiki tells us):

Since these values are global to the entire game, you shouldn't just overwrite them with an action D. Instead, you should first check if they're big enough for you by using action 7, and skip your action D if they are. This way, the variables will be set to the maximal value needed, not just the value needed for the last grf in the list.

So you can remove this from your list. Maybe O)TTD(Patch should simply enforce this behavior.

DBSet likes to change "Y-Offset for train sprites (8E)" if I remember right, I consider this a "feature" to be removed when there has been more consistent/better way found.

-edit-

Back then, the answer of .grf developers had been the extension of their sets to fill the available address space. Guess why?

This was never actually an answer to the problem. Make it impossible for the User to reach the problem by defining all other Sets void.
A reasons I deny always the usage of grf deactivating of other sets. Thats not the real purpose, it's again cheating. After all the users and well the Devs have the problem because of this trickery by grf authors.

The GUI problem addressed "DJ Nekkid" post. The Y-Offset for train sprites and the depot 32px settings are GUI workarounds. At least they are defined this way in newgrf.

may i bring to your attention that global variables have been a bad idea since the beginning of time

as your software project grows and the flexibility increases, they will always get in your way.

OTTD devs have already realised this and are reducing the amount of global variables step by step.

a solution for the base cost issue could look like following:

1. deprecate setting of vehicle base costs in the current NFO version
2. remove that ability in the next version
3. instead increase the range of vehicle costs
4. upon loading a grf which sets vehicle base cost, do not change the global base cost, but instead calculate that change into the vehicle costs when loading a vehicle from the grf, so when loading old grfs, the prices will still match the ones the grf designer intended

that, of course, will not work with terraforming costs or something, but i currently do not see a way for two grfs which change terraforming costs to reasonably interact with each other anyway.

eis_os wrote: ... costs, base costs ...

How do I (the CanSet) use base costs ?

Note : all amounts in British £, the game currency.

The following base costs are modified, if required :

. Track Type Cost Factors for normal, electric and narrow gauge (maglev).
. Engine and wagon purchase costs.
. Running costs for steam, diesel and electric.

First we find the highest cost among all the vehicles :

CPR / GE ES44AC 'Evolution' has a purchase price of £160,000. Then we find the next higher multiple of the max base cost that covers that amount; i.e. £200,000, which is ½ of standard max base cost of £400,000.

CNR / BBD HR616 has diesel running costs of £22,500. The next higher multiple of the max base cost that covers this engine is £41,600 or 8 fold of standard max base cost which is £5,200.

Then we set the cost multiplier for all costs and work out the multiples for each individual vehicle. We want to achieve as much granularity as possible, so the max base costs will be set as close as possible to the highest cost/price specified, which could be lower than the maximum standard base cost.

Currently, the max base costs in CanSet are set as follows :

... potential solution ...

Specify costs as real amounts with every vehicle; how to implement that and store them in a save game, or apply them whenever a game is loaded (including adjustments for inflation) is for the experts to sort out.

Another option to explore would be to have maximum base costs defined per GRF set; sets that don't do it use standard base costs.

eis_os wrote: ... graphed cost over the lifetime of a game ...

Currently, we do not change the costs during a game; except for the inflationary adjustments made by the game itself. But that could change, after a review of costs, using CB36. So any graph would show a straight horizontal line from 1920 to 2050 and beyond. Should you want a list of used costs across the entire range of vehicles, I could put together a spreadsheet.

belugas wrote:About the base/multiplier cost, ... What other costs will be "required" to follow the same path? There are 49 base costs in the system. ...

You would have to deal with all costs equally; e.g. NACity does change max base costs too, but to a limited extent, because it does interfere with other sets, e.g. ttrs3 and even industries when it comes to demolition costs.

eis_os wrote: ... Vehicle Graphics shouldn't change the economy. ...

But, that makes vehicle sets stand out; without it all vehicle sets are playable equally. The US set decided to lower purchase costs but increase running costs; the CanSet followed that model too. The DBset wants more realistic purchase prices. Changing the economy gives variety among the sets and should be possible.

... Base costs or multipliers? (As noted, it may be necessary to change newgrf to make the multipliers larger) ...

Of course we could increase the maximum base cost to say, 10,000,000 for engines and every body uses that one. But engines would then cost a multiple of 39,062. I don't think that is what we want.

... DBSet likes to change "Y-Offset for train sprites (8E)" if I remember right, ...

Not just the DBSet, every set uses that; because we need to fix the problem with the 2 pixels vertical difference between depot view and track view.

This could be done without, if the game makes that adjustment automatically and someone goes and adjusts all Y-offsets in trg1r.grf for all TTD 'original' vehicles.

And global variable 9E bit3 goes into the same league.

Bloody Nora. I was staying out of this but this is getting ridiculous.

Let's highlight a few key issues, shall we?

Firstly, GRF Authors are Designers. There are no standards in GRF design, and we don't just "translate" the vehicles of <x country> to GRF. Every set designer has ideas about how they would like their set to play, and every set designer has their own ideas about how to overcome the challenges and shortcomings of TTD. This is a Good Thing, because this results in innovation. If we'd laid down strict standards early on, then every train set ever made would be the original DB set with different sprites and a little fiddling around the edges.

Because of this, you are never going to get two sets that weren't designed to work together to work together in any way that makes sense, gameplay-wise. Loading two sets with different design philosophies is going to have 'interesting' results, and there's not a lot grf authors can do about it.

Therefore, I think the focus of this discussion should be maximising the ability of GRF authors to make their sets interoperable, if they want to, and however they want to.

Specifically, to address Oskar's points:
- different base cost and multipliers I agree with the approximate consensus, that it would be good if vehicle building and running costs were isolated.
- different sense of econommy is not a problem that can or should be 'fixed'.
- depot offset differences will not be an issue for sets that are designed to work together, and is only a minor graphical glitch otherwise, so not worth worrying about.
- rail offsets differences ditto
- how to deny cross set coupling of non engine/wagon combinations This is the major problem at the moment. As far as I'm concerned, all that is needed is a new action 2 variable; the grfid of the set the vehicle was defined by. Anything beyond that is the concern of the individual grf author.

Speaking for myself, my approach to this new feature is that by default I will make my grfs disable themselves if specific, known-conflicting grfs* are found - this will protect naive players from just piling everything in and ending up with a mishmash. But I will always provide a parameter to get around it, so that players who are capable of RAUTFM and know what they're doing, or just don't care, can get around it. I think having a little faith in players is better than trying to bulletproof our grfs so that the player always gets the intended playing experience, whether they want to or not.

*considering that significant grf sets are released at the rate of about one a year, I don't see this being a problem to maintain.