Simutrans Chat Room
Where cool people of Simutrans can meet up.

Basic couple constraint

Started by Ranran, March 12, 2019, 03:11:18 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


I get quite a bit confused now when you talk about "permanent" "semi permanent" "fixed". Are you talking about three different levels of connections between vehicles in additions to the standard separate outside the depot?

QuoteThat is, you can not know in the game the information on why it has only one connection partner.
This is really my main point and what I have been trying to explain through the entire discussion we had: Neither the player nor the game knows why a vehicle only have one connection partner. Only the author of the vehicle truly knows. Therefore the game should not try to guess the reason by telling the player that the connection is stronger or more fixed or permanent than other connections.

QuoteAfter all, I don't think there may be a need to implement fixed coupling at this time.
I think that it is better not to include the fixed connection in the basic connection constraint, since the fixed coupling is conflict with the existing constraints.
For example, is constraint[prev] = none and fixed_coupling[prev] = 1 simultaneously established?
Can fixed_coupling[prev]=1 and has_front_cab=1 occur simultaneously?
You are pointing at an issue, which is related to the issue Vladki pointed out, the example with the bus and trailer.

IMO the fixed_connection[prev/next]=1 should work completely independent from the rest of the constraints system. It should merely be a flag that the particular end cannot disconnect outside the depot. If a vehicle doesnt have it specified it is treated as if it can disconnect outside the depot, no matter what the other constraints are saying.
That way nor you, I, or anyone else needs to worry about the bus and trailer example for now since no one of us knows how the reassemble feature will eventually work. Perhaps James will code it so that the bus can leave the trailer in that circumstance, violating the trailers "constraint_prev" parameter, or perhaps James will code it so that the dat-file of the trailer needs to be altered in order for it to work. We dont know.
Yes, leaving it like that would lead to "overlapping" and slightly contradicting constraint systems, but the "fixed connection" system is most likely needed anyway in the new branch and the old constraint system also most likely needs some corrections in order to work properly.


If the convoy reassemble is implemented, it should definitely be made so that vehicles can be left in a station even if they do not form a valid convoy due to unsatisfied constraints and cabs. They just would be forbidden to move (most probably also because of no engine), or to move only in drive by sight mode.

Having some constraint[prev] (unless none is included) and has_front_drivers_cab=1 will effectively create a vehicle whose drivers cab is useless. Similar non-sens would be to put constrain[next]=any on brake van.

If the coupling is fixed or not must be completely independent from constraints. From the many examples mentioned here it is impossible to make sensible defaults. Perhaps only that if there are no constraints or constraint=none, then the coupling must _not_ be fixed. OTOH, if there is only exactly one constraint[next] and the other car has exactly one matching constraint[prev] it may be highly probable that the coupling is fixed. But you can never be sure. Autobuy feature in this case will apply but that also has nothing to do with permanence of connection between those vehicles. It is there just to spare you a few clicks.


I have been testing this to-day: my apologies for not having had time to look into this in more detail earlier. The graphical symbols are very useful and really do add splendid functionality: they also look very good. I have spotted a few errors in the untranslated texts, which I have fixed, and I have pushed the fixes together with this work integrated with the latest commits from the master branch to my basic-constraint-extension branch on Github.

I have also created an initial draft of English translation texts. Probably the best illustration of these is with a screenshot as follows:

I should be grateful for any feedback on this. I have additionally translated "LOCO_SYM" to "L" as suggested - anything longer (such as "Loco") did not fit.

I have now had a chance to test this with a specially compiled pakset using the new makeobj, which does appear to work correctly for the most part at least. However, one question, if I may: with articulated lorries, the trailers are shown as having a coupling of a type that cannot be uncoupled outside a depot, as here:

This is not correct, as articulated lorries' cabs can be and in reality were routinely detached from the trailers in ordinary use. I tried to modify the .dat files of the trailers to specify as follows:


but this has no effect. Is this an error or am I missing something?

Thank you very much for all your work on this in any event: it is much appreciated. This will make a splendid addition to the game.

Also, can I check whether any testing has been done as to whether this conflicts in any way with the vehicle-management branch?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.


I've been doing some other work recently, so I'm not working on coding for this. There are therefore a number of issues that need to be fixed.

Quotebut this has no effect. Is this an error or am I missing something?
If its constraint have only one target, it considered as fixed coupling, but I think that this should be corrected to hide.
And treat those with only one partner as having only one partner rather than fixed.

I think that the jagged side indication indicating that the current situation can not be at end is sufficient.
That is, defer the implementation of the black bar display and fixed_coupling settings.

In the future, I think it would be better to distinguish the strength of the connection between vehicles at the level (or some parameters).
e.g.) those that can not be separated forever, those with only one partner, Things that can not be separated outside the depot, those that can be separated in the depot, those that can not attach anything.
I think that it is better to think about parameters and display in consideration of them.

QuoteI have additionally translated "LOCO_SYM" to "L" as suggested - anything longer (such as "Loco") did not fit.
Yes, this was supposed to be something like L in English. I made it translatable so that the display can be optimized in other languages. I'm imitating the standard MON_SYM.


Splendid, that is helpful, thank you. Please let me know when you think that this is ready for integration, and I will test further.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.


Pak256-ex has already been prepared for this patch!


I advanced to the stage where this patch test can be performed.
I have changed the support for unsupported versions of vehicle paks. It will not look as broken as before.
makeobj has also been changed. The new version is 60.05.
You can download it from here.
It does not work correctly with makeobj 60.04.

The fixed_coupling parameter has been removed, so new makeobj will ignore it, but there is no problem.

Quote from: Ranran on July 02, 2019, 09:33:19 PMAnd this also affects the inversion algorithm. It will probably affect recombination as well.
If the locomotive was bidirectional, the side that can not connect anything when you shunt through the run-round loop will be back side.

Show in red the unconnected side.
It conflicts with the constraint setting. So it has to be reversed by using the turntable.
I have not addressed this issue yet.
This is true not only for locomotives, but also for EMUs with sharp noses.
Vehicles with a pointed nose do not have a coupler or are usually hidden in the nose except in case of emergency. So in many cases their head constraint[prev/next] is set to none.

I think that the operation about reorder needs to be checked particularly carefully.
I have been away from work for a while, so I might have missed something. (´・ω・`)

The branch is the same as before.

I added two new features:
(1) Upgradable symbol
(2) Mixed load prohibition
(3) Group constraint


Unfortunately, I got the opportunity to work on the features I proposed here.

Ranran kept moving forward to not miss this chance. Because I thought that it would be easier to do this together because it involves changes to makeobj. (´・ω・`)

A wagon like an open wagon simply can not carry different goods together, even in the same category. In other words, until the wagon is empty, it will be dedicated to the type of goods that were initially loaded on the wagon.
Another example: a tank vehicle with one tank.

It will also prevent the picture of the wagon from conflicting with the load.
It only improves the difference between reality and the weirdness of the look. (´・ω・`)

In the case of vehicles of mixed_load_prohivition, loads are divided and loaded in this way according to goods.

If you want to prohibit mixed loading of vehicles, describe mixed_load_prohibition = 1 in dat.

I added mixed_load_prohibition = 1 to 128.Britain-EX rail, truck, narrow gauge bulk and oil vehicles.
(modified BR-ex is here.)
Please note that this is a temporary work.
For example, I can not judge whether long goods - plank and steel can not be stacked together in the UK. It can not be done in Japan.

makeobj has been updated to a version of 60.06.
Please think that 60.05 did not exist. Using it will cause an error  ::'(

Now you can test this feature.
I also prepared saved game to test this. After loading it, start the convoy in the depot and watching it for a while with open the convoy detail window.

Enjoy it, thank you. (´・ω・`)らんらん♪

The test branch is here. This includes a patch for Formation picture.