Thanks for the update! You might want to put your GitHub address as well: not everybody uses Windows
I've tested your patch again, and I think it's brilliant. It works correctly so far, refusing to decouple those wagons that would change length as a result of being detached from their engine.
Also, I seem to understand you're already checking for attachment rules, and preventing two "uncompatible" consists from coupling? If so, it's really neat.
I've found that your patch works wonderfully together with my own way to do "push-pull" (i.e. swapping the graphics across wagons). It gives a very realistic final result, if not for the wagons changing graphics right upon decoupling and coupling (when they revert back to their default status). To correct for that, we'd need to enhance OTTD itself.
Now, I have a question about something that happened in my game. I sent a train composed by a coupling of 2 MUs to a station, then decoupled it, and ordered its former "head" to go to a depot. Then, I ordered another train of the same type to go pick up the decoupled half of the first, still waiting at the station.
The situation is as it appears on this picture:
coupling question0.png [ 50.03 KiB | Viewed 810 times ]
* Train 2 is the decoupled half of the initial train; it's patiently waiting at the station;
* Train 3 is just outside of the station and has "Couple Any Train" as its order.
Now, as you can see, the signal in front of Train 3 is red, because Train 2 is waiting at the station. Because of this, Train 3 won't start. However, shouldn't it rather ignore the signal, advance at a low speed, and couple with Train 2? I can't understand why it's waiting instead...
I have to manually force the train to ignore the signal. When I do, Train 3 behaves exactly as it's supposed to: it advances, couples with Train 2, and then drives off.
Perhaps this thing of ignoring the signal should be automated. Would you need me to post a savegame or anything else to help you out with this?