Page 10 of 11

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 11 Jun 2018 21:29
by Karn
Also there is fundamental problem with programming feature for NewGRF as a patch (except when you are dev and have commit rights to make it to trunk). Grf support outside trunk is outside of official compatibility so it's not useful for NewGRF authors, neither for me. It's because those modified NewGRFs are not guaranteed to work in trunk now or in future, so why to risk/bother as a NewGRF author?

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 00:33
by Drury
I keep forgetting that trains explode if you let them decouple in a dead end. Please developer fix my stupidity.

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 00:54
by Leanden
I imagine that the whole livery override thing is a non-issue if the individual wagons/coaches have their liveroes set by a subcargotype?

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 06:01
by andythenorth
Leanden wrote:I imagine that the whole livery override thing is a non-issue if the individual wagons/coaches have their liveroes set by a subcargotype?
Yes and no :)
* someone writing a newgrf now has other solutions and doesn't need to use livery override
* the spec contains livery overrides, there's no deprecation warning, and they're used (how widely I don't know) in released grfs, so they have to be handled

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 07:02
by michael blunck
Leanden wrote: I imagine that the whole livery override thing is a non-issue if the individual wagons/coaches have their liveroes set by a subcargotype?
It could only be an issue in case livery override would be dependent on the engine.

regards
Michael

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 08:14
by Karn
andythenorth wrote:
Leanden wrote:I imagine that the whole livery override thing is a non-issue if the individual wagons/coaches have their liveroes set by a subcargotype?
Yes and no :)
* someone writing a newgrf now has other solutions and doesn't need to use livery override
* the spec contains livery overrides, there's no deprecation warning, and they're used (how widely I don't know) in released grfs, so they have to be handled

You claim something needs to be fixed, but yet we don't have real example of what exactly is the problem. You use fancy words that something can go wrong and you use fancy ideas of how it should be. Altho you ignore how it really is. Only one, who provided relevant reproducible example to this NewGRF topic is JGR and that issue was resolved. Are we talking about some minor issue that is a corner case and maybe need small fix? Or are we talking about something, that needs new concept? Who knows, dramatic talk will not change anything.

We seem to have a bug? How can I reproduce it?

There will always be problems like - what if NewGRF authors set max speed to 1kph or other bizzare cases. But real question is, do they actually do it? And should we forbid them such cases? Same goes with liveries, we don't have to be restrictive to them, they have common sense. Specs can't fix every logical error.

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 08:44
by michael blunck
Karn wrote:
andythenorth wrote: [...]
You claim something needs to be fixed, but yet we don't have real example of what exactly is the problem. You use fancy words that something can go wrong and you use fancy ideas of how it should be. Altho you ignore how it really is. Only one, who provided relevant reproducible example to this NewGRF topic is JGR and that issue was resolved. Are we talking about some minor issue that is a corner case and maybe need small fix? Or are we talking about something, that needs new concept? Who knows, dramatic talk will not change anything. [...]
Yeah, the usual "reservations" of trunk developers and their entourage are a known fact.

I´m developer of a large sophisticated train set, and I will test your patch during this week. I will post serious comments, and probably even report bugs, if any.

regards
Michael

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 08:44
by Wahazar
My V4 CEE newgrf change livery of wagons according to livery chosen by engine.
but it is not a huge issue, if engine livery is not altered (used as default), no glitches happen.
PKP set does it opposite - livery of locomotive by default vary depend of freight/passenger/express cars type - it will change after decoupling/coupling.

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 10:06
by Karn
McZapkie wrote:My V4 CEE newgrf change livery of wagons according to livery chosen by engine.
but it is not a huge issue, if engine livery is not altered (used as default), no glitches happen.
PKP set does it opposite - livery of locomotive by default vary depend of freight/passenger/express cars type - it will change after decoupling/coupling.
I played a bit with your newgrf and it has interesting property - wagons livery keep even when you disconnect locomotive, so if you use for a route one type of livery (not just default) it doesn't switch during coupling.

Edit: Some of wagons keep it and some don't. Could you please explain how those that keep liveries do it compared to those depending only on engine?

Also is this about caching the variable gcache.first_engine? If we would switch it to normal variable and update it only in depot, would it fix this whole problem?

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 10:55
by Eddi
Karn wrote:It's because those modified NewGRFs are not guaranteed to work in trunk now or in future, so why to risk/bother as a NewGRF author?
i'm afraid this is an issue you won't solve in this thread. there is always some transitional period during development of such a massive change. especially since we've not even arrived at a consensus yet, which might require a working prototype to try out the different variants..

In Theory (tm), the NewGRF system offers ways to check the version of the game, so you can skip features that are not supported yet.

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 11:03
by Eddi
Karn wrote:Also is this about caching the variable gcache.first_engine? If we would switch it to normal variable and update it only in depot, would it fix this whole problem?
A test you could run: decouple the engine, check if things changed. then save the game and reload, see if it changed now.

anything that changed in the second case is a serious bug and a desync hazard

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 11:41
by Karn
Eddi wrote:
Karn wrote:Also is this about caching the variable gcache.first_engine? If we would switch it to normal variable and update it only in depot, would it fix this whole problem?
A test you could run: decouple the engine, check if things changed. then save the game and reload, see if it changed now.

anything that changed in the second case is a serious bug and a desync hazard
I tried that before. It looks desync free.

My question is about, if and where are results of callbacks stored for liveries. My guess is vehicle cache, but I don't know whole mechanism of how vehicle is drawn. If it is cache, then it should be sufficient to change it to vehicle property and then keep that property after save/load and livery wouldn't change everytime the cache deletes.

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 12:05
by Wahazar
Karn wrote: Edit: Some of wagons keep it and some don't. Could you please explain how those that keep liveries do it compared to those depending only on engine?
International/express/sleeping coaches are refitted by self, local coaches and freight wagons use parent livery.
Another issue can occur with mixed freight cars - first wagon have always different livery (service car), not sure what happen if it would decoupled from rest of train - did next car change its livery to service car?

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 12:43
by andythenorth
Karn wrote:You claim something needs to be fixed, but yet we don't have real example of what exactly is the problem. You use fancy words that something can go wrong and you use fancy ideas of how it should be
I call BS on that. Leanden asked a direct question, I answered it directly. I miss what the problem is there.

In fact f*** this thread, and f*** tt-forums tbh. I'm having a break.

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 13:11
by michael blunck
andythenorth wrote:
Karn wrote: You claim something needs to be fixed, but yet we don't have real example of what exactly is the problem. You use fancy words that something can go wrong and you use fancy ideas of how it should be
I call BS on that. Leanden asked a direct question, I answered it directly. I miss what the problem is there.

In fact f*** this thread, and f*** tt-forums tbh. I'm having a break.
What had your answer to do with his question?

My answer to his post was much more to the point, where yours was completely beyond, just to mention again your personal problems with "livery override"?

There are no problems with "livery override" in this context.

regards
Michael

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 14:06
by Karn
michael blunck wrote:
andythenorth wrote:
Karn wrote: You claim something needs to be fixed, but yet we don't have real example of what exactly is the problem. You use fancy words that something can go wrong and you use fancy ideas of how it should be
I call BS on that. Leanden asked a direct question, I answered it directly. I miss what the problem is there.

In fact f*** this thread, and f*** tt-forums tbh. I'm having a break.
What had your answer to do with his question?

My answer to his post was much more to the point, where yours was completely beyond, just to mention again your personal problems with "livery override"?

There are no problems with "livery override" in this context.

regards
Michael
That's basically my point, this thread was pushing on NewGRF (livery) problem like it's gonna destroy the world. To move somewhere with discussion I asked for evidence the same way, how this topic was pushed (to be even noticed). This patch has another 10 serious problems and soon I won't have time to work on it. I need some real feedback and suggestions while I have time. Thank you Michael in advance for those tests, hopefully it'll move us somewhere.

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 18:49
by michael blunck
Some testing ...

Reversing
Karn wrote: Then there is the reversing idea. My plan is to rework reversing, basically as mentioned ^^.
Then it will allow more combinations for shunting.
Yeah, after decoupling and later re-coupling at the back of train (engine running around), the consist is "flipped" (switches around). Maybe "reworking reversing" would be also beneficial for the old "push-pull" problem?


Querying the engine

Some applications need querying the engine, either by "wagon override" or by using CB36. E.g., consists of rail cars expanded by (non-motorized) coaches. Usually, these come in fitting liveries, which get broken on decoupling. Supplying coaches with fitting liveries would be excessive, and would confuse the player. There needs to be some method to either retain the overridden livery, or to prevent such trains from decoupling (set by the newgrf).

Apart from "livery/wagon override" and/or CB36 there´s another problem.

Although there´s maintenance cost for wagons, there´s no real "maintenance" for wagons in depots, i.e. vars 4B and 92 are not set for wagons, making livery changes by visiting a depot after a certain time (use case: DBXL, SBB Set, ...) impossible. And thus, only available when being attached to an engine:

Code: Select all

def(1) lastservicedate(
   engine(
	      ref(10) if(<date(31-12-1949)) // cream livery
	      ref(11) else // red livery
   )
)

def(2) ageinyears(
	ref(10) if(0 .. 10) // still cream, try later
	ref(1) else	// 10 years older, check maintenance date
)

def(3) yearbuilt(
	ref(2) if(< 1950) // old livery, check for change
	ref(11) else	// already red
)
Without exposing vars 4B/92 also for wagons, this cannot be worked around.


MUs, callback handling
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.
Amazing! This works as intended. I´ve already tested it with 2 coupled 3-part articulated MUs (CBs 10, 16, 1D, 2D, 36, plus (internal) livery override). It´s even amazing that it´s possible to give the decoupled part another order (manually), and when meeting again, both MUs will couple again. O/c, after recoupling, the orders for the originally decoupled MU is lost. Would be nice to have "portion working" feature as well ("flügeln"), but I have no idea how this could additionally be achieved ...
test4.png
test4.png (1.39 MiB) Viewed 1418 times
... to be continued.

regards
Michael

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 20:26
by Eddi
michael blunck wrote:Reversing
that probably needs some overhaul on how vehicles are stored/processed. in particular, vehicle chains need to be doubly linked lists [maybe they already are, haven't checked], so processing vehicle movement can run through them in one way, while NewGRF property/callabck evaluation an run the other way. afair Frosch has done some preliminary work on this once
Maybe "reworking reversing" would be also beneficial for the old "push-pull" problem?
that would be "just" an addon where the NewGRF would return a callback result about "may run backwards"

however, going down this path opens up a few other cans of worms. like, if you attach an engine to a train that already has an engine on the other side (e.g. a banking engine), which side should now be considered "forward".
Querying the engine

Some applications need querying the engine, either by "wagon override" or by using CB36. E.g., consists of rail cars expanded by (non-motorized) coaches. Usually, these come in fitting liveries, which get broken on decoupling. Supplying coaches with fitting liveries would be excessive, and would confuse the player. There needs to be some method to either retain the overridden livery, or to prevent such trains from decoupling (set by the newgrf).
that's why i originally suggested that livery oerride should prevent shunting.

however, the most extreme corner case i can think of right now that might be worth testing: In the DBSetXL, version 0.82 (the "current" version), the ET87 has only 1hp, and only gets ists "real" hp from attaching powered wagons, which afair also change length. while this is easily the worst way i have seen people abuse wagon override, it is a real-world-existing way, so it should be addressed somehow
Although there´s maintenance cost for wagons, there´s no real "maintenance" for wagons in depots
yes, "last maintained" date only gets set on the front engine. this is also a minor problem when you take apart an older train inside the depot which consists of multiple engines. the previously non-front engine will get a "wrong" livery, and only update its livery on being "serviced" while exiting the depot.
michael blunck wrote:
Eddi wrote: [...] one thing that is probably going to cause trouble for shunting is "powered wagons"
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.

regards
Michael
i do realize that you're living in a parallel universe where there is a DBSet 0.9, however, the rest of us must still live with your horrible hacks from over a decade ago...

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 21:09
by michael blunck
[slightly OT]
Eddi wrote:
mb wrote: Reversing
that probably needs some overhaul on how vehicles are stored/processed. [...]
Yeah. Karn already wrote that he "decided to remove experiment with reversing because I think it deserve separate patch"
Eddi wrote:
mb wrote: Querying the engine
Some applications need querying the engine, either by "wagon override" or by using CB36.
that's why i originally suggested that livery o[v]erride should prevent shunting.
Problem is not "livery override", but querying the engine. You already wrote
Eddi wrote: [additional flag/callback] that is a possiblility, but that effectively disables the shunting feature for all existing NewGRFs, which is a rather harsh limitation. so we should try to explore less harsh solutions, before considering this.
A relatively easy solution (much simpler than that "shadow parent" idea) would be to add a flag to allow (or disallow?) decoupling the engine(s) of a train:
Miscellaneous flags (27)
...
7 80 Engine may (may not?) be decoupled from consist (OpenTTD >r?????)
Since we´re unsure about behaviour of all old (abandoned) sets with regards to "decoupling", we could roll a dice. But at least the grf developer would know better than the user about technical limitations of his set.
Eddi wrote: [...] powered wagons [...]
This is the real deprecated newgrf feature. Superfluous since implementation and widespread use of "articulated vehicles".
Eddi wrote: [maintenance for wagons] yes, "last maintained" date only gets set on the front engine. this is also a minor problem when you take apart an older train inside the depot which consists of multiple engines. the previously non-front engine will get a "wrong" livery, and only update its livery on being "serviced" while exiting the depot.
I know. It´s on my wish list since ages.
Eddi wrote: [we] must still live with your horrible hacks from over a decade ago...
"Horrible hacks" only in retrospective. It was state-of-the-art in 2005.

regards
Michael

Re: Dynamic train composition? (Decoupling/Shunting/etc..)

Posted: 12 Jun 2018 22:04
by Karn
Eddi wrote:
michael blunck wrote:Reversing
that probably needs some overhaul on how vehicles are stored/processed. in particular, vehicle chains need to be doubly linked lists [maybe they already are, haven't checked], so processing vehicle movement can run through them in one way, while NewGRF property/callabck evaluation an run the other way. afair Frosch has done some preliminary work on this once
Do you know if it is somewhere online? I ran to few problems and opened questions that made me remove it, maybe he had solutions for them. Those were:
1) Should info about train stay in first vehicle, or should there be something like consist for whole train, that contains order and other important things that are stored in first vehicle?
a) if no, then how to copy orders without making crazy duplicate code and NewGRF problems
b) if yes, how to access variables in reasonable way and how many changes are needed
2) How to deal with articulated vehicles both on map and in train gui
3) How to reprogram the reverse function, it has calls from various places and most of code assume, the train can't flip. It's especially problem for 1)a)

Btw Train is double linked chain, it has Next() and Previous() to move between vehicles.