@James and Ves, Thank you for your detailed thoughts.
James, you seem to misunderstand what I tried to implement. And I apologize that my explanation was not enough.
What I aimed at this patch is a very simple and loose constraint. It is simple and clear for players to understand.
And this is just an extension of
constraint[prev/next] = any/none.
So I do not think that it will create complexity when editing vehicle dat file.
This patch is to improve the GUI significantly, without much modification to the system.
The purpose is to clarify the composition of convoy and make it easy for players to understand it.
And this will ease composition and reconnection.
I believe that it will make full use of that ability, especially in recombination systems.
This is an example of a picture that is often used to represent the train configuration. Is this common for train geeks outside Japan? I don't know.
Think of a pantograph as a vehicle with a motor. (This is for your imagination and has nothing to do with this implementation.)
Anyway, from this image you should be able to get some information about the train configuration.
For example, the
train B has a 4 + 4 configuration, and it will be possible to split off on the way to different destinations. But
train C will not be able to do that.
Train D will be able to dump the behind three cars on the way. The isolate three dumped cars will be able to attach another locomotive in front and go to another destination but it may cause an error when returning.
Train E is an image of a freight train.
Train E will be able to add and drop vehicles (such as wagons) in the middle position.
I implemented one function so please watch the demo. (´・ω・｀)刮目して？
Pay attention to the shape of the color bar. 
You can see that this EMU is a 2 + 4 configuration.
This is only a slight extension of the existing system, so I don't think it will inhibit the addition of the strict constraint feature you mentioned.
If you understand this and think that the word Coupling constraints doesn't fit, suggest another word. I'm not an English speaker, so I think I can not select the best word.
fixed_coupling_:I think this parameter is useful. This clarifies the distinction between
A, B, C vs
D, E.
So instead of adding stuf to the ends of that bar, I think you could have another bar directly below it that displays wether it may or may not detach it self outside the depot.
How about this one? This will clarify the
DMU and
EMU.
Such a
line will not be displayed in the freight train. It can be disassembled outside the depot.
If this is to go into Standard, it would be better for the code in Extended not to diverge from that.
Prissi implemented it differently than the existing Extended system. In current Extended makeobj writes
bool can_be_at_rear to the vehicle pak, but prissi's do not.
This makes sense for a standard that prefers a simple implementation but it is not extensible. That's because it specializes in determining whether coupling is possible.
So it won't work for the feature which I'm trying to add.
Since extended's
bool can_be_at_rear is highly available, I extended it
uint8 and renamed and reused it.
That is, makeobj has a flag in the form of a vehicle. By writing necessary data to pak file beforehand, unnecessary processing is omitted.
Again, this is just an extension of the existing system. I just reused the unused area.
Therefore I don't think it's a good idea to go backward and remove
bool can_be_at_rear and align it with the standard's code.
On the one hand, I know that many Japanese player are craving it for the standard. It is a great pleasure to have it implemented in the standard.
Many thanks to Prissi.
Recent Posts
It's interesting. Thank you for the notice. 