Increase the amount of veh. IDs? (Use mult. vehicle sets)

[Digitalfox]

Yeah, I thought it funny that TTDP can spend so much breath on arguing over how many buses to allow in a road vehicles set... well, duh! Just allow as many sets as you want.

Well if you are saying that TTDP should raise the limits or use this approach of slot's, you know what some person will say " oh it's not because it almost impossible without rewriting almost everything in TTDP, it's because we don't care we are happy with what we have and users don't care for more slot's or more vehicles per slot" This is not what i think of TTDP community in general, but about someone who always gives the impression that things aren't done in TTDP just because there's no need or interest, when the difficulty is the answer for not doing it... Be honest please...
At least in OpenTTD i always feel that when something is over the possibilities for now to be coded it's said in a honest way..

[dev|ant]

Does it retain the vehicle type limits within the 256 block? ie. trains ~110, a/c ~80, ships ~10, road ~50 ish

Yes, though these days with EngineID being 16 bits and NewGRFs not strictly requiring the current allocations, changing that should be achievable. The only thing you'd have to worry about are the massive backwards-compatibility headaches it would produce.

Would be fantastic to be able to create a UKRS version with all those "missing" classes - 50s, 52s, 45s, 56s, etc, and still retain the maglev and monorail systems.

Could you do this by creating say a GRF for each type of engine, eg. steamers, diesels, etc? Then you could load one in each slot and end up with the same result.

[George]

Could you do this by creating say a GRF for each type of engine, eg. steamers, diesels, etc? Then you could load one in each slot and end up with the same result.

1) Would it be possible to have a flag in buy vehicle window to group vehicles by slots? Would it be possible to allow users to select slot to display? So we could open slots like "Steamers", "Deasel", "Electric", "Wagon"? Same for "Bus", "Tourist bus", "Truck", "Trailer".
2) Would it be possible to have these slots inside one grf? So one GRF could say "This part is a slot for buses and this part is a slot for tourist buses"?
3) Could slots collaborate? So I could make a slot "trucks" and "trailers", but when I assemble a road train, the trailer could check, that it is attached to a lorry, not the bus or the trailer?

[nilsi]

Well honestly I am against communication between slots or else we sometime need a feature to mirror slots because we want to use some sets that change other slots. I think one slot should be enough for every interdependancy needed in a set. And the different parts should be stand alone (e.g. steamers vs. diesel as proposed).

[George]

Well honestly I am against communication between slots or else we sometime need a feature to mirror slots because we want to use some sets that change other slots. I think one slot should be enough for every interdependancy needed in a set. And the different parts should be stand alone (e.g. steamers vs. diesel as proposed).

I see a big problem here. How would wagons know, that they are attached to freight locos or passengers locos? How to prevent connecting freight wagons to passenger locos? Hope you understand the problem.

[nilsi]

I understand the problem, but I do not see a reason why wagons should know it in the first place.
Most German Locos have been used for both services during their lifetime. And it would still not prevent somebody from loading the same set twice to workaround such a restricton.

I know about Trains like ICE or TGV, but this should fit in the same slot.

[dev|ant]

1) Would it be possible to have a flag in buy vehicle window to group vehicles by slots? Would it be possible to allow users to select slot to display? So we could open slots like "Steamers", "Deasel", "Electric", "Wagon"? Same for "Bus", "Tourist bus", "Truck", "Trailer".

That's what I'm working on at the moment. Initially the slots will only be identified by number, but I don't see why we couldn't set up other filters in time.

2) Would it be possible to have these slots inside one grf? So one GRF could say "This part is a slot for buses and this part is a slot for tourist buses"?

Interesting idea, though I feel it should probably be implemented as part of the core GRF functionality, rather than in this patch?

3) Could slots collaborate? So I could make a slot "trucks" and "trailers", but when I assemble a road train, the trailer could check, that it is attached to a lorry, not the bus or the trailer?

Can you change trailers on a truck at the moment, other than through a refit? I didn't think you could, but I'm happy to be corrected. I'm not changing the core functionality of vehicles at such a low level, just allowing more of them.

How would wagons know, that they are attached to freight locos or passengers locos? How to prevent connecting freight wagons to passenger locos? Hope you understand the problem.

The same way they are now - through callback 1D.

[George]

2) Would it be possible to have these slots inside one grf? So one GRF could say "This part is a slot for buses and this part is a slot for tourist buses"?

Interesting idea, though I feel it should probably be implemented as part of the core GRF functionality, rather than in this patch?

Some code should get this information from GRF anyway.

3) Could slots collaborate? So I could make a slot "trucks" and "trailers", but when I assemble a road train, the trailer could check, that it is attached to a lorry, not the bus or the trailer?

Can you change trailers on a truck at the moment, other than through a refit? I didn't think you could, but I'm happy to be corrected. I'm not changing the core functionality of vehicles at such a low level, just allowing more of them.

This should be changed. It should be done the same way as for trains.

How would wagons know, that they are attached to freight locos or passengers locos? How to prevent connecting freight wagons to passenger locos? Hope you understand the problem.

The same way they are now - through callback 1D.

The problem is that in steamer GRF ID XX would be a passenger loco, while in the other it may be a freight loco, the EMU in the third. What to do?
I mean we can't use ID any more. We need to have some flag to check?

[dev|ant]

The problem is that in steamer GRF ID XX would be a passenger loco, while in the other it may be a freight loco, the EMU in the third. What to do?
I mean we can't use ID any more. We need to have some flag to check?

In this case the most useful way to use the 1D callback is with the engine checking the cargo type of the wagon. So an EMU will only allow passenger carriages to be added.

Where this does break though, is when a passenger carriage from another slot is added to such an EMU that has wagon override. I haven't come up with an easy fix for this yet, but I'm sure it's possible.

[michael blunck]

Most German Locos have been used for both services during their lifetime.

That´s not correct. Although you´re right that most german locomotives have indeed been used both for passengers and freight "during their lifetime", new engines were definitely developed either for express passenger service, passenger service or freight service. Only in later years, when newly developed locomotives entered the scene, engines formerly used in express passenger services were "downgraded" to passenger service and those in passenger service entered freight service (where applicable).

This is an overall feature in German railways, both in DRG and in DB times, and the DBXL has and will reflect this behaviour to a large extent.

> The problem is that in steamer GRF ID XX would be a passenger loco, while in the other it may be a freight loco, the EMU
> in the third. What to do?
> I mean we can't use ID any more. We need to have some flag to check?

In this case the most useful way to use the 1D callback is with the engine checking the cargo type of the wagon.

There are more ways to ensure usage of the correct coaches and wagons in existing sets. E.g., in DBXL I´m checking for cargo, veh-ID, prop25, ..., and quite a number of other things (can´t look into it ATM).

The only way to achieve something like this (loading multiple vehicle .grfs with the same veh-IDs) properly would be to make it completely transparent for the .grfs. Other than that, more problems would be generated with people having trouble with the sets.

And BTW, TTDPatch has a sophisticated "Graphics Ressource Management" system (GRM), which allows .grfs not only to check the availability of ressources but also allows them to check the exclusive availability. This is a phantastic feature to disclose known incompatibilities beforehand, but it seems to be wasted in your current approach for OTTD.

regards
Michael

[dev|ant]

There are more ways to ensure usage of the correct coaches and wagons in existing sets. E.g., in DBXL I´m checking for cargo, veh-ID, prop25, ..., and quite a number of other things (can´t look into it ATM).

That's a great way to do it.

The only way to achieve something like this (loading multiple vehicle .grfs with the same veh-IDs) properly would be to make it completely transparent for the .grfs. Other than that, more problems would be generated with people having trouble with the sets.

And completely transparent it shall be.

And BTW, TTDPatch has a sophisticated "Graphics Ressource Management" system (GRM), which allows .grfs not only to check the availability of ressources but also allows them to check the exclusive availability. This is a phantastic feature to disclose known incompatibilities beforehand, but it seems to be wasted in your current approach for OTTD.

Agreed it is a good way of identifying conflicts, but it can't always resolve them (especially without the talents of a very gifted nfo coder). GRM isn't wasted in my approach, it can still be used to make sure everything a GRF wants to use is available, it will just apply within it's particular slot.

[nilsi]

@mb That is exactly what I was talking about

[michael blunck]

@mb That is exactly what I was talking about

Is that so?

Your post:

I understand the problem, but I do not see a reason why wagons should know it in the first place.
Most German Locos have been used for both services during their lifetime. And it would still not prevent somebody from loading the same set twice to workaround such a restricton.

I know about Trains like ICE or TGV, but this should fit in the same slot.

is nevertheless misleading because it´s not the same if it´s unimportant whether a locomotive may add each and every coach/wagon all the time (as you suggested) or if specific coaches/wagons are only allowed in specific timeframes.

Which is the case both in RL and in DBXL and should be a strong reason to implement it with regards to those requirements.

regards
Michael

[nilsi]

I should have been more specific.
It sounded like restricting attachable wagons for the whole lifetime.
I also remembered a recent discussion about DB 143 hauling freight trains.


Unrelated I do not like wagons changing their liveries without explicit refitting,
so they would not have to know their loco.

The proposed waggon acceptance by carried cargo seems reasonable to me (and without complicated inter-slot handling).

PS: Yes I am more the model railroading then the efficiency player.

[mph]

Would it be possible to allow multiple sets, but not to allow them to interact.

So you could have dbsetxl and canset for example, and have trains of each set running on the same network. But- you couldn't attatch a wagon from db set to a canadian train. To make sure the sets function exactly as the author intended.

in the veh list you would have something like this, each expanding to show that set.

dbsetxl>
canset>
usset>


I dont know how you have implemented your patch, and what you can achive so, but good luck.

[Zephyris]

Ideally I would imagine a set of switches for slot to slot interactions;
modification of base prices
sharing of wagons
etc...

[michael blunck]

Unrelated I do not like wagons changing their liveries without explicit refitting,
so they would not have to know their loco.

Well, the DB Set never did this (livery change w/o explicit refitting/renewal), simply to achieve that special "DB feeling". But that doesn´t mean that there´s no link between engine and coaches. Although, in fact it´s the other way round: a locomotive knows their coaches. I.e., a V200 is first using Aüms/Wrüms between 1950 and 1960, then switches to TEE service (incl "hump" dining-cars) until leaving premium service in 1974, now using long-distance coaches in cream/oceanblue until 1986, when InterRegio and InterCity services are being started. In addition, from 1979 you may refit premium services to ordinary long-distance trains, and even more later you may use local coaches.

The proposed waggon acceptance by carried cargo seems reasonable to me (and without complicated inter-slot handling).

Usually, differentiation between long-distance and local coaches cannot be done by checking cargo.

regards
Michael