Decoupled part of train is becoming new train. There is open question, if the train limit should apply for trains or for locomotives. With this patch it makes more sense to limit locomotives, since they are what makes profit possible.
MUs (dualheads) won't be allowed to decouple, there is not much to do with generic wagons, it would be just weird. Only possibility to decouple will be to decouple 2 already coupled MUs.
Then there is the reversing idea. My plan is to rework reversing, basically as mentioned ^^. Then it will allow more combinations for shunting.
I'm also working on: Adding number parameter for how many units to decouple. And basic conditions for finding train for couple - IS_EMPTY, IS_FULL, and something with cargotypes. This will create framework for such thing as non-electric->electric shunting station
Karn wrote:MUs (dualheads) won't be allowed to decouple, there is not much to do with generic wagons, it would be just weird. Only possibility to decouple will be to decouple 2 already coupled MUs.
MU doesn't necessarily imply dual-head.
See attached for what I mean.
In general the NewGRF spec permits wagons and locomotives to be arbitrarily different when coupled compared to when not, and it isn't obvious to determine whether this is a "safe" thing to allow in the context of decoupling.
Probably you will need to snoop on what the NewGRF is doing and just not allow de/coupling if it is doing this sort of thing (e.g. using variables 40-42, 60-62, etc.)
JGR wrote:
In general the NewGRF spec permits wagons and locomotives to be arbitrarily different when coupled compared to when not, and it isn't obvious to determine whether this is a "safe" thing to allow in the context of decoupling. [...]
"Longer" wagons/coaches are usually articulated, i.e. composed of 2 or 3 vehicles, e.g. by use of var 4D.
This is a very interesting project, but I'm not sure how it would work with trainsets that change wagon properties according to the engine they're attached to.
For instance, in the set I'm working on, a passengers wagon's characteristics (livery, appearance, properties, even length...) are determined by the leading engine type. If a wagon has a "short" length when attached to engine A, and a "longer" length when attached to engine B, how would it behave in a game where I swap engine A with engine B in the consist? So far, we're not allowed to change a wagon's length outside of a depot, so I'm really puzzled as to how it would work with this patch.
Snail wrote:This is a very interesting project, but I'm not sure how it would work with trainsets that change wagon properties according to the engine they're attached to.
It won't, not ever
But I think it's good that forks can explore new ground.
The future of OpenTTD is stable core, and lots of feature forks. Some forks won't be compatible with newgrf spec. That's ok.
Meanwhile we've discussed 'shunting' here since year zero. Congrats to Karn for actually writing some code to implement it
Snail wrote:
This is a very interesting project, but I'm not sure how it would work with trainsets that change wagon properties according to the engine they're attached to.
It won't, not ever
Depends. Some wagon properties, based on the engine, will fall back to default values. Others, like modifying vehicle length, would not work outside their scope (defined only when done in depots), and will probably produce desyncs in MP games.
BTW, apart from changing vehicle length by means of a CB for part vehicles inside a MU (which might not be split anyway by this patch), I don´t see any use case (= "bad feature") for changing vehicle lengths for wagons hauled by a normal engine (locomotive)?
I don't know how your patch works, but i would propose to handle the "wagon properties depend on engine" by having the player specifically define "detachable wagon groups" in the depot. only those may take part in shunting operations, and vehicles in that group will not have access to vehicle properties outside that group. as far as the NewGRF is concerned, that is the whole train. shunting may only happen betewen such groups, and they cannot be searated by shunting
Eddi wrote:I don't know how your patch works, but i would propose to handle the "wagon properties depend on engine" by having the player specifically define "detachable wagon groups" in the depot. only those may take part in shunting operations, and vehicles in that group will not have access to vehicle properties outside that group. as far as the NewGRF is concerned, that is the whole train. shunting may only happen betewen such groups, and they cannot be searated by shunting
"Let's make player's judgement prevent technical problems". What could go possibly wrong?
Karn wrote:"Let's make player's judgement prevent technical problems". What could go possibly wrong?
i don't think that's what i said
There is technical problem with variable wagon length depending on NewGRF engine. The problem is, when you change the engine outside the depot, it can corrupt certain things like absolute positions on map or some properties on level of changing NewGRF in game. You proposed to make player define what's technicaly safe to do outside the depot, even when the game will end up in unexpected state. So player would have to guarantee with his choices that the game won't crash/corrupt.
no, i proposed that the user gets the option to specify what he intends to do, so the game can avoid the unsafe operations, without completely removing them from the game.
Some newgrfs have restrictions, using "start-stop" or "can_attach" switches, to handle MU things etc.
Is it possible to check result of these switches when coupling/decoupling order is being set?
Probably only second one is possible (decoupling order sanity check)...
What about livery overrides? The stuff associated with that is only ever meant to take place in a depot. All kinds of crazy stuff could happen: in particular a change in capacity may occur.
Congrats to Karn for actually writing some code to implement it 