Dynamic train composition? (Decoupling/Shunting/etc..)
Moderator: OpenTTD Developers
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
i ve been silent since that patch came out but watched with interest, and i haven t tested it yet, so yes my comment won t be constructive at all, sorry for that :
- my mouth is watering since patch came out !
thanks for all the effort ! Now i return to silence
- my mouth is watering since patch came out !
thanks for all the effort ! Now i return to silence
- andythenorth
- Tycoon
- Posts: 5658
- Joined: 31 Mar 2007 14:23
- Location: Lost in Music
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
Place to start looking is probably cb36 https://newgrf-specs.tt-wiki.net/wiki/C ... s_.2836.29Karn wrote:Maybe all we need is the current depot check and as a bonus check, if length of vehicle(s) changed. (Or capacity too, if any NewGRF does it without changing length)
There are a few other callbacks too that change properties and/or need cache re-rolled (10, 11, 12 etc)
I'm wrong person to trust on this, but afaik changing certain properties can cause:
- game crashes
- network desyncs
- invalid cache
- behaviour that's hard to explain and confuses player
TL;DR it's an interesting patch, if limiting some newgrf behaviour is needed, might be worth doing
Probably easier discussed in irc https://wiki.openttd.org/IRC_channel
FIRS Industry Replacement Set (released) | HEQS Heavy Equipment Set (trucks, industrial trams and more) (finished)
Unsinkable Sam (ships) (preview released) | CHIPS Has Improved Players' Stations (finished)
Iron Horse ((trains) (released) | Termite (tracks for Iron Horse) (released) | Busy Bee (game script) (released)
Road Hog (road vehicles and trams) (released)
Unsinkable Sam (ships) (preview released) | CHIPS Has Improved Players' Stations (finished)
Iron Horse ((trains) (released) | Termite (tracks for Iron Horse) (released) | Busy Bee (game script) (released)
Road Hog (road vehicles and trams) (released)
-
- Tycoon
- Posts: 5948
- Joined: 27 Apr 2005 07:09
- Contact:
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
Changing length by CB (36) should be rather rare, in contrast to capacity change. I´ve done a quick look in DBXL, and there are 55 occurencies of capacity changes (by CB 36):
- using same passenger cars over different generations (remodeling)
- having/refitting passenger cars for differing comfort levels (cargo aging)
- freight cars with fixed volume but different loading weights for cargoes based on stowing factors
None of them depending on the engine, but rather on date/age, on refit cycle (var F2), or on cargo type.
regards
Michael
- using same passenger cars over different generations (remodeling)
- having/refitting passenger cars for differing comfort levels (cargo aging)
- freight cars with fixed volume but different loading weights for cargoes based on stowing factors
None of them depending on the engine, but rather on date/age, on refit cycle (var F2), or on cargo type.
regards
Michael
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
Seems OpenTTD already counts with those problems. We got ConsistChanged() method and ValidateTrains(). They both deal with cache and check everything needed. They handle decoupling in depot, which is same thing except the vehicle length change, which doesn't need to be forbidden in depot. But we even have flags for that for ConsistChanged().
I think only issue is vehicle length that needs to be checked. Capacity shouldn't matter, as it is allowed to change both in depot and during autorefit.
So using depot's ValidateTrains() and checking CB 36 and 11 for length change should be enough, otherwise only graphical glitch is possible with weird NewGRF.
I think only issue is vehicle length that needs to be checked. Capacity shouldn't matter, as it is allowed to change both in depot and during autorefit.
So using depot's ValidateTrains() and checking CB 36 and 11 for length change should be enough, otherwise only graphical glitch is possible with weird NewGRF.
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
I also use CB36 a lot. I change wagon length according to the leading engine in order to have multiple version of the same vehicle type without cluttering the purchase list; I also do it for the user's convenience.michael blunck wrote:Changing length by CB (36) should be rather rare, in contrast to capacity change. I´ve done a quick look in DBXL, and there are 55 occurencies of capacity changes (by CB 36):
- using same passenger cars over different generations (remodeling)
- having/refitting passenger cars for differing comfort levels (cargo aging)
- freight cars with fixed volume but different loading weights for cargoes based on stowing factors
None of them depending on the engine, but rather on date/age, on refit cycle (var F2), or on cargo type.
One case is for railcar trailers; I've got different types, each matching to a specific railcar model. Of course, each trailer type has its own length. I think it's more convenient for the player to have one generic slot for "Railcar Trailer" in the purchase list, which can automatically adapt to the railcar it's attached to, rather than having to choose among 5 or 6 different types of trailers, each of which can be attached only to certain engines?
Another case is for mail wagons, all of which share the same ID and automatically match the style of the passenger coaches in the consist: I do this by checking the engine. Again, would you rather have multiple IDs for mail wagons, so that every time you'd have to choose the matching type to add to the consist?
The French Narrow Gauge Train Set is now released! Get it here
- andythenorth
- Tycoon
- Posts: 5658
- Joined: 31 Mar 2007 14:23
- Location: Lost in Music
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
It's not really a critique of your newgrf design choice Snail . The better question is, how would you support this behaviour with shunting, given that vehicle length absolutely *cannot* change outside a depot?Snail wrote:Again, would you rather have multiple IDs for mail wagons, so that every time you'd have to choose the matching type to add to the consist?
FIRS Industry Replacement Set (released) | HEQS Heavy Equipment Set (trucks, industrial trams and more) (finished)
Unsinkable Sam (ships) (preview released) | CHIPS Has Improved Players' Stations (finished)
Iron Horse ((trains) (released) | Termite (tracks for Iron Horse) (released) | Busy Bee (game script) (released)
Road Hog (road vehicles and trams) (released)
Unsinkable Sam (ships) (preview released) | CHIPS Has Improved Players' Stations (finished)
Iron Horse ((trains) (released) | Termite (tracks for Iron Horse) (released) | Busy Bee (game script) (released)
Road Hog (road vehicles and trams) (released)
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
an alternative to the manual "detach" nodes to be set by the players would be that upon shunting, the vehicle gets a "shadow" link to the original vehicle that it left the depot with. with that, it could be ensured that the callbacks always refer to the same vehicle, but it may cause issues if the vehicles are sold separately
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
No offense taken, we just have totally opposite ideas. You don't mind having a long purchase list, while I find it fine to use CB36 to change a vehicle's properties.andythenorth wrote: It's not really a critique of your newgrf design choice Snail
The fact we think each other's approach is silly is irrelevant we just need to find a solution for both.
I think this would be a very good solution indeed.Eddi wrote:an alternative to the manual "detach" nodes to be set by the players would be that upon shunting, the vehicle gets a "shadow" link to the original vehicle that it left the depot with. with that, it could be ensured that the callbacks always refer to the same vehicle
I would actually propose something similar, but maybe with a wider scope: it would be great if we had a function that not only returns the engine a wagon is currently attached to (as we have now), but also the engine it left the depot with, i.e. some sort of "original" engine. Such information could be cached and updated each single time the wagon leaves a depot.
Then, upon shunting, we would check the ID of the new shunting engine, and only allow shunting if the latter is compatible with the "original" engine.
This would solve most compatibility problems I can think about...
The French Narrow Gauge Train Set is now released! Get it here
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
that needs some addition to the NewGRF system where a vehicle can have multiple "PARENT" references. i think frosch had a proposal about that a few years back.Snail wrote:it would be great if we had a function that not only returns the engine a wagon is currently attached to (as we have now), but also the engine it left the depot with, i.e. some sort of "original" engine. Such information could be cached and updated each single time the wagon leaves a depot.
anyway, during a discussion on IRC, a proposition came up:
during a shunting operation, the following 3 checks are made:
- CB36 and all related callbacks are run, and if "dangerous" changes (like length) occur, the shunting operation is forbidden
- the wagon-attach-callback is run as if it were in a depot, and if it fails, the shunting operation is forbidden
- if the engine uses wagon overrride, the shunting operation is forbidden
this should catch all the worst cases, without outright forbidding shunting on all existing NewGRFs. then, some advanced tools might be needed for NewGRF authors to affect the way shunting works (like disallowing shunting in the middle of an EMU), which can be used to improve future NewGRFs
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
Yep, that would be quite helpful...Eddi wrote:that needs some addition to the NewGRF system where a vehicle can have multiple "PARENT" references. i think frosch had a proposal about that a few years back.
There's more to it than wagon override... Recoloring and graphics can also be changed according to the leading engine. I think we should check for them as well.Eddi wrote:if the engine uses wagon overrride, the shunting operation is forbidden
The French Narrow Gauge Train Set is now released! Get it here
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
yes, but it's not really game-breaking, so we could live with old GRFs being slightly wonky in this case. New GRFs should get the proper tools to specifically deny shunting if they want to rely on such thingsSnail wrote:Recoloring and graphics can also be changed according to the leading engine. I think we should check for them as well.
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
There were some unexpected crashing bugs in 0.3. They should be gone now. I'm not aware of any game crashes atm.
I made something about NewGRF decoupling, it shouldn't corrupt game now.
Here is 0.4
Edit: binaries are in development thread
I made something about NewGRF decoupling, it shouldn't corrupt game now.
Here is 0.4
Edit: binaries are in development thread
Last edited by Karn on 14 Jun 2018 14:00, edited 1 time in total.
-
- Tycoon
- Posts: 5948
- Joined: 27 Apr 2005 07:09
- Contact:
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
Why should it? To avoid "unpleasant" livery changes? Or to safely reset property modifications?Eddi wrote: if the engine uses wagon over[r]ride, the shunting operation is forbidden
Apart from simply changing the looks of wagons when being attached to certain engines, IMO the more important feature of "wagon override" is ignoring or resetting speed limits for trains (i.e. its locomotive) imposed by attached wagons.
E.g.,
Code: Select all
makevehicle(_E19,
link(ref(6), MENU)
default(ref(8))
override(_PDISTLONG, ref(F_AUM)) // passenger long-dist LONG
override(_PDIST, ref(F_)) // remove speed limit of 140 km/h
override(_MDIST, ref(FP_)) // remove speed limit of 120 km/h
override(_SPW, ref(SPW_)) // remove speed limit of 140 km/h
)
IMO, performing a shunting operation on such a train shouldn´t do any harm, rather than reset the original speed limiting effect for decoupled wagons when being attached to a different engine.
regards
Michael
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
the issue i have with "wagon override" is that it has too many side effects.
anyway, one thing that is probably going to cause trouble for shunting is "powered wagons"
anyway, one thing that is probably going to cause trouble for shunting is "powered wagons"
-
- Tycoon
- Posts: 5948
- Joined: 27 Apr 2005 07:09
- Contact:
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
IIRC, I´ve never used that feature (MUs can be better modeled by articulated vehicles). Would be interesting to see which train sets are using it.Eddi wrote: [...] one thing that is probably going to cause trouble for shunting is "powered wagons"
regards
Michael
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
Maybe this patch should provide settings, if livery override is accepted for shunting or not?
Formerly known as: McZapkie
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, wired, ECS industry extension, V4 CEE train set, HotHut.
Another favorite games: freeciv longturn, OHOL/2HOL.
Projects: Reproducible Map Generation patch, NewGRFs: Manpower industries, PolTrams, Polroad, 600mm narrow gauge, wired, ECS industry extension, V4 CEE train set, HotHut.
Another favorite games: freeciv longturn, OHOL/2HOL.
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
I don't see point in wasting programming time on limiting anything. As long, as the game doesn't corrupt, there are no more limits needed. We have restrictive limits that apply in the depot. Same limits apply outside the depot, so I don't see point in making new special rules that adds nothing to gameplay or overall fun. Why is red box that tells user that he can't do something requested so much?
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
So perhaps instead, when a train attempts to couple to a different one, if any callbacks result in a risky/impossible change (e.g. wagon length) then just reject the coupling and cancel the order?
It will probably give strange-looking results that a bunch of cars suddenly change design but at least it shouldn't entirely prevent players from using any existing NewGRF.
It will probably give strange-looking results that a bunch of cars suddenly change design but at least it shouldn't entirely prevent players from using any existing NewGRF.
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
That's already implemented. I'm not sure if without bugs. Some testing would be nice to see, if weird results are possible.
Re: Dynamic train composition? (Decoupling/Shunting/etc..)
Honestly Karn, yet you're almost doing a revolution in OpenTTD with your patch. When people want, they have.
Who is online
Users browsing this forum: Amazon [Bot] and 11 guests