Grouping vehicle coupling constraints

[Ranran(retired)]

Hi, welcome to Ranran's pavilion. (´・ω・｀)やあ、ようこそらんらん亭へ

Today Ranran brought a new Jalapagos noodle patch again.
This is a new but fundamental feature, so I post to a new thread.
But this consists of a group of recently posted my patches. Because almost the same part is edited.
And this also involves changes in makeobj. So I think if they are done at the same time, it may save time and effort.

This is a realization of the delusion I previously wrote to some thread. It was completed when I made it for trial.
I did only a simple test but extensive validation using pakset may be necessary.



As I do not speak English, I am not confident I can explain this function well.  Also, advice on variable names is welcome.
Also, advice on the code is welcome. I just mimicked similar code. Pros may be able to do more efficiency. 
I have little knowledge of railways in British so it would be difficult to edit them properly for Britain-pak.
This is very flexible and depends on the pakset author's thinking. But it's simple and easy to understand, because this is following the existing system.

In short, (vehicle's) name is replaced by a constraint group name, and constraint [prev/next] can also specify a group name. That's it.
I believe this specification is very kindful of adding new vehicle or add-ons. 
Because when adding vehicles of the same specification, it is not necessary to change the constraints of existing vehicles.
The need to write a lot of vehicle names is gone. It was too ridiculous. Now people are freed from wasted work. 

This also has the disadvantage that only up to 255 vehicles can be added. Grouping makes it possible to connect with more vehicles.

The existing constraint list is too strict in the list, and loses its meaning when non-existent ones are mixed, which may have already been fixed in the basic constraint patch.
No such thing happens when using group constraints. This is a loose restriction.



Dat file reference:
group[front][n]=
group[rear][n]=
[n] is a number from 0.
Declare the name of the group to which this vehicle belongs.
Set the names of the saucer of constraint_group[prev/next] to the front and rear side of the vehicle.
Allows connection to vehicles that have this name in constraint_group[prev/next].
Multiple group names can be registered.
This is very important. It depends heavily on the pakset author's policy.
The name can be decided freely. Usable characters are the same as usual names (maybe).
The pakset author can be classified to associate with the connection settings, and be given names for easy understanding.
E.g. equipment name, formation position, class name, company name, coupler shape, etc.

constraint_group[prev][n]=
constraint_group[next][n]=
[n] is a number from 0.
Specify the name set in constraint_group. Then connection with vehicles belonging to the group is possible.
"none" or "any" can not be used. (It is considered a group name)
The point to be noted here is that you can specify multiple groups.
This makes it possible to reproduce the connection between upward compatibility and backward compatibility.
For example, group A can be coupling with group B but not with group C
Group B can be coupling with both group A and group C. Love is free. 
That is, grouping in consideration of it is required.

tips:
If you want to have a one-on-one connection, use the existing constraints. Autobuy / autoselect doesn't work with grouping constraints (maybe).
Please use constraint[prev/next][n]=none together with the head/tail end as before. If constraints does not have "none" but the constraint_group is set, it is considered as an intermediate side.
There is constraint[prev/any][0]=any as a looser constraint.
Even if it has multiple groups, if one matches, the connection is allowed.
The facing sides of the two vehicles must be able to connect to each other.


Show a picture of the constraint setting example:

This is just an example. There is no necessity to divide the cab and the inner. It is possible to divide according to the feature of each vehicle.

The version of makeobj is 60.07.
https://simutrans-germany.com/files/upload/Makeobj-Extended60-07rev3.zip

The repository is here.
https://github.com/Ranran-the-JuicyPork/simutrans-extended

Thank you for your patience and understanding to my poopy English.

I look forward to your feedback.

Thank you.   (´・ω・｀)らんらん♪

EDIT:
Modified the .dat reference because it changed the specification

EDIT2:
It has been changed to be able to register multiple group names.

[jamespetts]

Thank you very much for your work on this: this is most interesting. My apologies for not having had the chance to look into this so far. One point of clarification, if I may, as to the .dat file reference when multiple groups are selected: if a vehicle has multiple groups selected, may it couple to any other vehicle with at least one of those groups, or must it couple to a vehicle with all of those groups?

There is much to be said for modifying this feature so as to allow for a little of both. So, for example, if the default rule were permissive (i.e., a vehicle would be able to couple to another vehicle if any constraint group matched between the vehicles), and if one were to add the keyword "constraint_group_mandatory" to the .dat file, a vehicle with that specified would only couple to another vehicle that has all of the mandatory constraint groups, plus at least one of the non-mandatory constraint groups (if any) specified.

So for example, the following pairs of vehicles would be permitted to couple:

Vehicle A

constraint_group[next][0]=Kittens
constraint_group[next][1]=Puppies
constraint_group[next][2]=Bunnies

Vehicle B

constraint_group[prev][0]=Elephants
constraint_group[prev][1]=Bunnies
constraint_group[prev][2]=Crocodiles

***

Vehicle A

constraint_group_mandatory[next][0]=Elephants

Vehicle B

constraint_group[prev][0]=Elephants
constraint_group[prev][1]=Bunnies
constraint_group[prev][2]=Crocodiles

***

Vehicle A

constraint_group_mandatory[next][0]=Elephants
constraint_group[next][1]=Bunnies

Vehicle B

constraint_group[prev][0]=Elephants
constraint_group[prev][1]=Bunnies
constraint_group[prev][2]=Crocodiles

***

Vehicle A

constraint_group_mandatory[next][0]=Elephants
constraint_group[next][1]=Bunnies

Vehicle B

constraint_group_mandatory[prev][0]=Elephants
constraint_group[prev][1]=Bunnies
constraint_group[prev][2]=Crocodiles

***

Vehicle A

constraint_group_mandatory[next][0]=Crocodiles

Vehicle B

constraint_group_mandatory[prev][0]=Crocodiles

***

whereas the following pairs would not be able to couple:

Vehicle A

constraint_group[next][0]=Kittens
constraint_group[next][1]=Puppies
constraint_group[next][2]=Bunnies

Vehicle B

constraint_group[prev][0]=Elephants
constraint_group[prev][1]=Penguins
constraint_group[prev][2]=Crocodiles

***

Vehicle A

constraint_group_mandatory[next][0]=Kittens
constraint_group[next][1]=Puppies
constraint_group[next][2]=Bunnies

Vehicle B

constraint_group[prev][0]=Kittens

***

Vehicle A

constraint_group_mandatory[next][0]=Kittens
constraint_group[next][1]=Puppies
constraint_group[next][2]=Bunnies

Vehicle B

constraint_group_mandatory[prev][0]=Kittens

***

Vehicle A

constraint_group_mandatory[next][0]=Kittens
constraint_group[next][1]=Puppies
constraint_group[next][2]=Bunnies

Vehicle B

constraint_group[prev][0]=Puppies
constraint_group[prev][1]=Bunnies
constraint_group[prev][2]=Crocodiles

***

Does this make any sense?

[Ranran(retired)]

I'm afraid but I may not have understood your question correctly. (´・ω・｀)


This is only a duplicate of (vehicle) name replaced by group_name.
Only check whether prev or next vehicle can be connected. You will not be able to leave the depot unless they can be connected to each other.
(Vehicle's) name is vehicle-specific, but it is possible to have the same group name on multiple vehicles. Therefore it will make the constraints list very slim.





For instance,

a + f = NG
a + b + f = OK
a + e + f = OK
a + e + e + b + b + e + f = OK
a + c + d + f = OK


Even if you change the group name of a and f to XXX-middle, they have constrsaint="none", so you can allow formation like a - b- c - d - e- f.

Is constraint_group_mandatory different from setting only one group?
For example, it is possible to further divide the XXX-middle, like XXX-middle-A and XXX-middle-B.

This idea will be flexible but depending heavily on pakset author grouping work.
The constraints list can be made quite slim.
Also you will save yourself the time and effort of changing constraints when adding and removing vehicles; Adding a new vehicle "g" to the XXX-middle group or deleting vehicle "B" does not require changing existing vehicles constraints.


I think that pakset author can imitate real world constraints by well naming and grouping.

[ACarlotti]

The issue of constraints for reversed vehicles is closely interlinked with this, so they need to be considered at the same time. So I'd suggest something like:

Code Select Expand


Vehicle.dat:
name=...
Constraint[next][0]=...
Constraint[prev][0]=...
ConstraintGroup[next][0]=...
ConstraintGroup[prev][0]=...
Group[next][0]=...
Group[prev][0]=...


End x (='next' or 'prev') of vehicle A would be allowed to couple to end y of vehicle B if:
1. A accepted B - i.e.  for some i,j we have either A.Constraint[ x ][ i ]==B.name, or A.ConstraintGroup[ x ][ i ]==B.Group[ y ][ j ]
2. B accepted A (similarly)

So for a cars towing trailers we might have:

Code Select Expand


Car143.dat:
Constraint[prev][0]=none
Constraint[next][0]=none
ConstraintGroup[next][0]=car_trailer
Group[next][0]=car_with_tow_bar

Trailer23.dat:
Constraint[next][0]=none
ConstraintGroup[prev][0]=car_with_tow_bar
Group[prev][0]=car_trailer


And a 2/3-car MU that can work in multiple with other MU classes, with both halves identical (not actually true for this example):

Code Select Expand


br-165.dat:
name=BR-165-DMOS
Constraint[prev][0]=none
ConstraintGroup[prev][0]=networker-dmu
Constraint[next][0]=BR-165-DMOS
Constraint[next][1]=BR-165-MS
Group[prev][0]=networker-dmu
---
name=BR-165-MS
Constraint[prev]=BR-165-DMOS
Constraint[next]=BR-165-DMOS

There is one flaw in the second example, which is that the scheme described above doesn't allow us to specify which end of the other vehicle is referred to in Constraint[next]. In this case it actually works out correctly, but in general there could be issues. So some system should be added to specify a particular end of the other vehicle. One possibility (borrowing the choice of special characters from regular expressions, and listing both ends of the MS separately for illustrative purposes) might be:

Code Select Expand


name=BR-165-DMOS
Constraint[prev][0]=none
ConstraintGroup[prev][0]=networker-dmu
Constraint[next][0]=$BR-165-DMOS
Constraint[next][1]=$BR-165-MS
Constraint[next][1]=^BR-165-MS
Group[prev][0]=networker-dmu


I don't think this is the place to be trying to satisfy multiple constraints simulataneously (as you seem to be suggesting James with your discussion of 'mandatory' constraints). My suggestion here (which I think is equivalent to Ranran's except that it also accounts for vehicle reversal) is a fairly minimal set of changes that solve the following problems:
1. Many vehicles have long lists of constraints for common coupling types; these are often not updated properly when new vehicles are added, cannot be easily adapted to include addons, and in extreme cases might require excessive mempory usage.
2. The current constraint system does not account for the possibility of vehicles being reversed independently of the overall convoy.

Incidentally, I noticed while writing the Class 165 example (which isn't quite true to life because one of the driving cars on each unit has a toilet) that the current constraints are incomplete - according to Wikipedia, Classes 165, 166 and 168 can work in multiple with each other.

[Vladki]

Ranran: is it possible to specify that a vehicle is member of multiple groups? If not, than James' question is irrelevant at the moment. However it would be nice to allow multiple groups. That would allow for specifying coupling systems (buffers & screw, Scharfenberg, ...); braking systems (none, vacuum, air, ...); heating (none, steam, electric); door operation (none, air, electric); push-pull controls; etc, etc.... Then there would be necessity for more complex combinations like: air brake AND (steam OR electric heating)...

Reversed vehicles should swap the constraint Next/Prev as discussed in other threads, and that should of course apply to groups as well.

I'm not sure if it is necessary to distinguish the groups on front and back end of vehicle as ACarlotti proposes. I don't see a situation where it would be useful?

[ACarlotti]

I'm not sure if it is necessary to distinguish the groups on front and back end of vehicle as ACarlotti proposes. I don't see a situation where it would be useful?

The point is to be able to avoid convoys conisting of three identical vehicles in the configuration <<> (where the correct configuration is to have them pair up in some whole number of units, e.g. <><><>). If we can't specify which end of the other vehicle we're allowed to couple to, then I don't see how we can prevent such configurations arising in the future once convoy recombination allows for vehicles to be reversed independently within a convoy. And I think it would be foolish to design a constraint groups system that doesn't work for stuff that we know we intend to implement in the near future.

Ranran: is it possible to specify that a vehicle is member of multiple groups? If not, than James' question is irrelevant at the moment. However it would be nice to allow multiple groups. That would allow for specifying coupling systems (buffers & screw, Scharfenberg, ...); braking systems (none, vacuum, air, ...); heating (none, steam, electric); door operation (none, air, electric); push-pull controls; etc, etc.... Then there would be necessity for more complex combinations like: air brake AND (steam OR electric heating)..

I think fully supporting such a system goes well beyond simply allowing different constraint groups. Anything that can be done by combining multiple constraint groups can also be implemented solely by adding some additional groups. More complicated cases can't be solved simply by considering how adjacent vehicles interact - for example, you can't just couple a load of vacuum-braked wagons behind one wagon that can use either vacuum braking or air braking, if the locomotive itself only provides an air brake pipe.

So I strongly suggest we keep things simple to start by solving some of the existing known issues, and only consider approaching the more complicated issues of braking systems and door systems later if we find we need to. Coupling systems can already be accounted for by my suggestion, and everything else you mention would require a separate system for listing services that vehicles can convey along a train from a locomotive or other provider, and a (possible smaller) list of services that the vehicle needs to be provided with.

[Vladki]

ACarlotti: OK, thanks for explaining, you're right. However this should be extended even to non-group contraints then. If vehicles can be arbitrarily reversed (either manually in depot or due to recombination) then this could happen even without group contraints. Imagine that in your example <<> is emu-front, emu-rear (reversed), emu-front (reversed).
emu-front has constraint[next]=emu-rear. OK
emu-rear has constraint[prev]=emu-front. It has even contraint[next]=emu-front to allow two units to connect. So the contraints (even if we swap them due to reversal) will be satisfied. So there must be a way to distinguish whether the constraint is the internal permanent coupling of the unit, or the external coupling between units...

[ACarlotti]

ACarlotti: OK, thanks for explaining, you're right. However this should be extended even to non-group contraints then.

I agree - I already mentioned this earlier, although there may be a better way of notating it.

There is one flaw in the second example, which is that the scheme described above doesn't allow us to specify which end of the other vehicle is referred to in Constraint[next]. In this case it actually works out correctly, but in general there could be issues. So some system should be added to specify a particular end of the other vehicle. One possibility (borrowing the choice of special characters from regular expressions, and listing both ends of the MS separately for illustrative purposes) might be:

Code Select Expand


name=BR-165-DMOS
Constraint[prev][0]=none
ConstraintGroup[prev][0]=networker-dmu
Constraint[next][0]=$BR-165-DMOS
Constraint[next][1]=$BR-165-MS
Constraint[next][1]=^BR-165-MS
Group[prev][0]=networker-dmu


Also, I'm thinking it might be possible to overload the meaning of the Constraint field, by treating the name field as implying some constraint groups:

Code Select Expand


name=ClownCar
implies:
Group[prev][0]=ClownCar
Group[prev][1]=^ClownCar
Group[next][0]=ClownCar
Group[next][1]=$ClownCar


(Incidentally, I keep accidentally writing 'front' and 'rear' instead of 'prev' and 'next'. I'm not sure which would be better for 'Group'.)

[Vladki]

I think it is easy. Constraints say what the prev/next vehicle must be (capable of), while groups say what capabilities are on front/rear of this vehicle.

So prev/next for (group) constraints, front/rear for group membership

[Ranran(retired)]

Thank you for you guys thoughts. 

The issue of constraints for reversed vehicles is closely interlinked with this, so they need to be considered at the same time.

2. The current constraint system does not account for the possibility of vehicles being reversed independently of the overall convoy.

I agree with ACarlotti. I made it possible to set group names separately in front/rear.
Fixed the first post reference and added a makeobj link for testing.

In the Japanese example, in the EMU with many electrical connections  the electricity and control cables are fixed on the north side and the air system is on the south side, and in many cases it is not possible to connect vehicles in different directions except for the cab side.
On the other hand, locomotives (except for tenders and articulated cars) and coaches can be cross-connected in most cases.
Enabling cross-connects in MUs adds extra cost, so cross-connect functionality may be omitted even on the cab side if the train does not turn around along the way.




It has been changed as follows.

Example 1: When the direction of the vehicle is not distinguished



- In this example, ABC009 and ABC009(reversed) can be connected.
- It can use ABC001(reversed) instead of ABC009.
- There is no problem if ABC002 and ABC005 are reversed.



Example 2: When the direction of the vehicle is distinguish


In this example, ABC109 and ABC109(reversed) can not be connected.
ABC108 represents an example of a cross connect vehicle. In Japan, there is an example where a specific vehicle has the cross connect function and the same leading vehicle is used in the opposite direction. In other words, the vehicles behind are connected in the opposite direction with this vehicle as the boundary.

Formation example:
<_ ABC101 _| + |_ ABC108 _| + |_ ABC101(reversed) _>

<_ ABC101 _| + |_ ABC102 _| + |_ ABC108 _|  + |_ ABC102(reversed) _| + |_ ABC102(reversed) _| + |_ ABC109 _>

<_ ABC101 _| + |_ ABC102 _| +  + |_ ABC109 _> + <_ ABC101 _| + |_ ABC102 _| + |_ ABC109 _>


Currently, we do not check vehicle constraints outside the depot. It is put in the depot and the reversal information of the vehicle is kept, but when convoy returns to the garage, the reversal vehicle is restored.
The vehicle's reversed information retained also in the depot, but when convoy returns to the depot, the turnaround vehicle is restored.
That limitation will be removed in the future.

However, the individual inversion of the vehicle requires some problems to be solved (Reversed vehicle drawing position, etc.), changes to the GUI's modification functions and major changes, and I think its implementation should be done at the same time as the recombination, not this time.

Since the current extended does not yet have a constraint check outside the depot or an individual reversing function in the depot, so the reversing constraint check is not implemented this time but I don't think that's difficult.
If the vehicle itself is reversed, replace can_lead() with can_follow(), and change can_lead() or can_follow() to pass the target vehicle's bool is_reversed together. And if the vehicle is reversed, check the opposite side (group) constraint.





Think of this patch as a connection constraint that integrates cable, (air and steam) hose, and coupler.
I consider heating and air supply as an additional concept to be supplied upon connection establishment.

And I think this would be a topic to be discussed in another thread, but I think it would be better to distinguish between requesting vehicles and installed vehicles, and to see if there are vehicles installed in the convoy.
It may also be necessary to consider the capacity of the requester and the outputer, the effect if the condition is met, the effect if the condition is not met, and whether it is mandatory or not.

Ranran: is it possible to specify that a vehicle is member of multiple groups?

This is not possible at present.
Instead of having multiple group names, it is assumed that they have correspondence by having multiple constraints after distinguishing by name.
For example, vehicle A is group[front/rear] = air_brake, and vehicle B is group[front/rear] = air_brake_and_steam_pipe.
If the vehicle is sufficient for air_brake, set "air_brake" and "air_brake_and_steam_pipe" to constraint_group[prev/next]. The vehicle which needs both sets only "air_brake_and_steam_pipe".

Group[prev][0]=networker-dmu

Thus, group [front/rear] does not need to nest numbers like this.
I do not currently know if this is necessary, but it can be extended in the future.

So prev/next for (group) constraints, front/rear for group membership

I adopted this. 

[ACarlotti]

Group[prev][0]=networker-dmu

Thus, group [front/rear] does not need to nest numbers like this.
I do not currently know if this is necessary, but it can be extended in the future.

I think having multiple groups is necessary - suppose I had a diesel locomotive that was capable of hauling several different kinds of EMUs*. Rather than having to explicitly set each EMU unit to be able to connect to this locomotive, it would be better to just allow the locomotive to specify what types of EMU it provides couplings for. Indeed, if this locomotive were an addon, then specifying multiple constraint groups would be the only way of doing this. Indeed, if we want this to work also for coupling to vehicles that weren't specified with a constraint group, then we will need to reuse the name of another convoy as a 'group' or 'alias' for this convoy. This seems like a good argument for my earlier suggestion:

Also, I'm thinking it might be possible to overload the meaning of the Constraint field, by treating the name field as implying some constraint groups:

Code Select Expand


name=ClownCar
implies:
Group[prev][0]=ClownCar
Group[prev][1]=^ClownCar
Group[next][0]=ClownCar
Group[next][1]=$ClownCar


This suggestion would probably be best implemented by adding a coupling object to the game (where every existing vehicle automatically generates three objects related to its name, although we could delete the unused ones after reading the pakset). Each coupling object then has a list of vehicle ends that support it (either implicitly by the vehicles name, or explicitly in a 'group' or 'alias' setting), and each vehicle has a list of coupling objects representing ends it can be copied to (and there would be no need to separate out 'Constraint' and ConstraintGroup' options).


(*Examples of this sort of locomotive do exist - I know that Rail Operations Group in the UK have locomotives that can be coupled directly to a range of EMUs (including interacting with their electronics), to allow them to deliver or transfer EMU stock more easily. However, this specific use seems unlikely to arise in Simutrans, since we don't generally care about one-off stock movements.)

[Ranran(retired)]

Thank you for your explanation.

Indeed, if this locomotive were an addon, then specifying multiple constraint groups would be the only way of doing this.

I think this makes sense and seems to be a good reason to implement it.
So, I changed so that it could register multiple groups.

Also, I'm thinking it might be possible to overload the meaning of the Also, I'm thinking it might be possible to overload the meaning of the Constraint field, by treating the name field as implying some constraint groups:

name=ClownCar
implies:
Group[prev][0]=ClownCar
Group[prev][1]=^ClownCar
Group[next][0]=ClownCar
Group[next][1]=$ClownCar

This suggestion would probably be best implemented by adding a coupling object to the game (where every existing vehicle automatically generates three objects related to its name, although we could delete the unused ones after reading the pakset). Each coupling object then has a list of vehicle ends that support it (either implicitly by the vehicles name, or explicitly in a 'group' or 'alias' setting), and each vehicle has a list of coupling objects representing ends it can be copied to (and there would be no need to separate out 'Constraint' and ConstraintGroup' options).

Does this mean that we use group constraints to solve issues where existing vehicle to vehicle constraints don't consider reversing?
And does this mean that all vehicles automatically have the same group name as their name?
(I think this is a string comparison of constraint_group[prev/next] and vehicle name.)

Perhaps If the pakset/addon author does not set it purposely, vehicle (object) name will not be often used for the group name.
Also, pakset/addon author  must be careful of the duplication of group name and vehicle name.

Is there any reason to generate a copy of the vehicle name that has no orientation? (such as Group[prev][0]=ClownCar and Group[next][0]=ClownCar)



The connection between Locomotive and EMU has recently been talked about in another thread, but when doing such movements in the real world you can't (in many cases) load passengers. There is a reason that it can not provide electricity for service, can not get enough braking force, differences of brakes and control systems etc. But it is not difficult to just connect them and run at low speed than originally. This means that it will be in no load mode or the capacity will be 0 or get a penalty on top speed.
I think that there is a possibility that the game balance may be broken if we simply allow such coupling.
On the other hand, adding such a system to simutrans (or Extended) will take additional effort.

[ACarlotti]

Is there any reason to generate a copy of the vehicle name that has no orientation? (such as Group[prev][0]=ClownCar and Group[next][0]=ClownCar)

Yes - backwards compatibility. We want constraints in existing paksets to continue working as before; with my set of suggestions the only thing that might change is how they are represented in-game.

For reasons of compatibility, it would also be good to see if Standard would also accept some of these changes; I know there are several paksets that have both a Standard and Extended version, and it would be inconvenient if they had to use substantially different files.

The connection between Locomotive and EMU has recently been talked about in another thread, but when doing such movements in the real world you can't (in many cases) load passengers. There is a reason that it can not provide electricity for service, can not get enough braking force, differences of brakes and control systems etc. But it is not difficult to just connect them and run at low speed than originally. This means that it will be in no load mode or the capacity will be 0 or get a penalty on top speed.
I think that there is a possibility that the game balance may be broken if we simply allow such coupling.
On the other hand, adding such a system to simutrans (or Extended) will take additional effort.

The specific example I was referring to (i.e. some of the locomotives used by Rail Operations Group) is one where the electronics are fully connected to the locomotive and all brakes are working. This allows the consist to run at line speed, which significantly reduces the cost and time of transporting the EMU across the country. Rail Operations Group took over the contract to deliver Crossrail trains from Bombardier when all parties involved realised that Rail Operations Group could do it so much more efficiently.

This is still a set of one-off movements which wouldn't need to be modelled in Simutrans, but I believe Rail Operations Group may also have plans to use such locomotives to transport EMUs in service through non-electrified services (e.g. if the normal route is blocked or the OHLE is damaged and unusable). This sort of capability could plausibly have some use in Simutrans (but implementing it properly is outside the scope of this set of changes).

[jamespetts]

Thank you all for your thoughts on this and to Ranran in particular for the ongoing work. First of all, as to orientation, at present that is not much of an issue, but will become relevant in future when it becomes possible to recombine vehicles outside a depot; likewise the fact that the correctness of the convoy is only checked in depots - at present, this makes no difference, as there is a fixed reversing algorithm, and trains are de-reversed automatically on entering a depot, so this is never an issue. In future, there will be arbitrary recombination and trains will not be automatically de-reversed on entering a depot, so this will need careful consideration.

I am not sure whether the use of Regular Expressions syntax is the way to go, as this is not necessarily as clear as it might be to those not familiar with it. I should be grateful for people's thoughts on this question, especially those involved in working on paksets such as Pak.256, Pak128.Cs and so forth. Likewise on syntax, I am not sure what A. Carlotti intends by "Group" as distinct from "ConstraintGroup"; I should be grateful if he could elaborate.

Second of all, I very much agree with A. Carlotti that backwards compatibility is essential: we really must not do anything that breaks any existing individual constraint system. Individual constraints will continue to have a place both for backwards compatibility reasons and for special vehicle combinations (e.g. steam locomotives and tenders, Garratt engines, etc.).

Thirdly, the question of multiple constraint groups. It is correct that multiple groups are necessary for this system to work effectively; I am grateful to Ranran for implementing this. On the more complex question of adding logic to constraint groups, there are some additional complexities that I had not considered in my initial post. One of them is alluded to by A. Carlotti:

you can't just couple a load of vacuum-braked wagons behind one wagon that can use either vacuum braking or air braking, if the locomotive itself only provides an air brake pipe.

Dealing with this sort of issue requires a per convoy set of constraints that must be satisfied, the algorithm (and thus the data structure) for which is somewhat more complex than we have at present.

Also, the mandatory constraint system that I proposed would not have been able to deal with multiple alternatives, for example, carriages that are both vacuum and air braked and also both steam and electrically heated, needing only one braking and one heating system to be connected at any one time.

Careful thought will need to be given to what work that the vehicle connexion algorithm can sensibly be made to do as distinct from a future whole convoy algorithm. In other words, even if we are not implementing the whole convoy part of the algorithm now, we need to work out what that part of the algorithm will be so that we know that this part of the algorithm fits in well with it when we come to implement that before we implement this. I should be grateful for people's thoughts on this question.
Incidentally, I have also fixed the 165/166 issue in the pakset. We do not have a class 168 in the pakset as these are too similar to the 170 to have been worth including.

[Ranran(retired)]

Thank you for your thoughts and explanation.


For backward compatibility, I'm a little confused. (´・ω・｀)

If we want to make a non-directional connection, it is no matter to continue using the existing vehicle to vehicle connection.


When reversing the vehicle:

(Yellow is the part that needs to be corrected to the existing dat when considering reversing.)

Is this my wrong recognition?


Only when we want to have directionality, use group to perform a directional coupling constraint check.




It is reproduced by describing the name in group that it can not connect with the reversed vehicle. I think this is what ACarlotti intended.

What I asked was that the copy of the no orientation group name looks the same as the vehicle name, so it seems to be meaningless.



Common to brake and heating issue:

both constraints and constraint_groups only check the connections of facing vehicles.
It does not check whether cables and hoses are connected throughout the convoy. It is necessary to check other than the facing side of the next vehicle.
EMU has compressors and service power supplies distributed on multiple vehicles.
Checking only the coupling constraints of facing vehicles can not determine if they are included in the convoy.

And as I said before, it needs to be connected to the supplier, and may not need to be connected to the whole.
For example, the power supplied to the coach may be a diesel generator installed on a particular coach. The locomotive and passenger car do not necessarily have to be connected with the same cable.
However, coaches that do not have a generator can not operate air conditioning unless they can obtain the supply of electricity from the generator. The vehicle on which the generator is installed may be on the front or at the back. It is not always on the next vehicle.
Even if the vehicle does not require power for air conditioning or steam heating, it may have pipes and cables. (Thus, it may be solved with additional modifications as well as the difference between the couplers.)
In addition, there are several examples of behavior when the request is not fulfilled.
Problems with connection of brakes may not be a problem unless the braking force is insufficient. However, when the braking force is insufficient (in order to drive at a safe speed) convoy will receive a big penalty on the top speed.
This may be related to reproducing the needs of the brake van in the early era of railways.
In the case of formations like "Steam locomotive + coach + wagon", steam heating works correctly on the outward journey.
According to the current specifications, this convoy will be reversing order and the return will be changed to the formation of "Steam locomotive + wagon + coach".
Yes, the passengers need to travel without heating. But the train can drive. Perhaps the comfort level is greatly reduced.
In the real world the coach will be moved behind the locomotive for heating.
I think these are necessary to build a new and different system.


coupling_group works with existing constraints.
I think that grouping greatly contributes to simplification of the constraint setting that also takes into account the outside the depot. Dealing with brake and heating issues together can be quite complicated.

I think that should be considered as a completely separate function.

Ideas for the future:
If we can register multiple group names, we can use a group name like a cable/hose to indicate whether they are connected.

For consumption vehicle:
(1) Define the required equipment name of the vehicle.
(2) Define the groups required to connect with the vehicle on which the required equipment is installed. The equipment only works when properly connected with the installed vehicle.
(3) Define the amount the equipment consumes from the supply.
(4) Define the effect when the requirement is fulfilled.

name=coach_001 required_equipment[0]=steam_heating required_connecting_group[0]=steam_heating required_consumption[0]=10 fulfill_equipment_bonus_comfort[0]=20 required_equipment[1]=air_brake required_connecting_group[1]=air_brake required_consumption[1]=10 fulfill_equipment_bonus_brakeforce[1]=10

For supplier vehicle:
(1) Define the equipment name installed on the vehicle
(2) Define the amount the equipment supplies

name=steam_locomotive_001 installed_equipment[0]=steam_heating equipment_supply_amount[0]=500 installed_equipment[1]=air_brake equipment_supply_amount[1]=500

However, because it involves some complexity, I think that it is better to set it only when necessary.
It does not need to be used if the constraints are sufficient.

[ACarlotti]

What I asked was that the copy of the no orientation group name looks the same as the vehicle name, so it seems to be meaningless.

There are a couple of differences between what your images show, and the contents of my (latest) suggestion.

Firstly, I suggest doing away with "ConstraintGroup" and just using "Constraint" for all the settings. And secondly, I suggest handling all constraints in game as referring to some sort of constraint or coupling object. The 'no orientation group name' is intended as specifying a constraint object that directly replaces the reference directly to the vehicle, so that all constraints are handled internally using the same system.

[Ranran(retired)]

I understood your intention.
However, I am afraid this requires major changes in the current specification and it seems impossible with my skill. (´・ω・｀)
According to the current specification, the value set in Constraint[] is converted to another value only for none / any, and the others are directly written to pak file.
And when you start the game and load pakset, all object names that do not exist in pakset will be abandoned. That is, the newly registered group name in constraint[] will disappear.
(This is why the current constraints system is not tolerant. For example, if one misspelling is mixed in, then pakset does not have a misspelled vehicle object and all constraints that the vehicle has will be meaningless. It becomes possible to connect with all vehicles. For example, deleting one vehicle pak file from pakset will destroy all related vehicle's constraints.)

And the registered format is different. constraint has a pointer of vehicle. constraint_group is char.
Is it correct to register the group name as a vehicle object? Anyway I think I can not carry it out. ∩(´・ω・｀)∩
If big efficiency is achieved by fully integrating constraint[], this work may be better done by you.

[Mariculous]

I am pretty confused.
I found three different threads about this one feature?
https://forum.simutrans.com/index.php/topic,18837.70.html
https://forum.simutrans.com/index.php/topic,15766.70.html
and this one here.

Didn't read them all now as they are pretty long and I simply want to update the bug report and feature request list.
So may you tell me if these three are all about the same feature and which of these threads I should add to the list?

[Phystam]

I would like to try this feature for pak256-Ex pakset.
Where is the latest patch?
Maybe this feature is still progressing, and it would be helpful to develop this feature and the pakset both.

[Spenk009]

Phystam, if you look into RanRan's github repo you can find his published work. link. I'm afraid it looks like his last work was committed on July 30th, after the lengthier post about his intentions.

[Phystam]

Thank you for the information. I will try it later.

[Ranran(retired)]

So may you tell me if these three are all about the same feature and which of these threads I should add to the list?

The three are closely related to each other, but each has a slightly different theme.




thread 1: (this thread) [patch] Grouping vehicle coupling constraints
This patch tried to loosen the too strict constraint specification to make it ambiguous.
Change the dat file description format to make the constraint setting work of the pakset author easier.
We also need to consider the constraints when the vehicles are individually reversed due to recombination of the convoy in the future.
Unfortunately this patch has stalled. I hope we can get further discussion and cooperation. (´・ω・｀)

So this thread doesn't need to be added to the list.





<a href="https://forum.simutrans.com/index.php/topic,18837.70.html">thread 2: Basic couple constraint</a>
The purpose of this thread is to constrain the vehicle position in convoy according to the role of the vehicle and to express it with simple vehicle symbols.
For example, the one with a drivers cab can be at the front and is represented by a pointed head symbol.
This patch adds a new parameter to the dat description to achieve this.


[Add feature] Mixed load prohibition
In addition, a mixed load prohibition attribute has been added as an additional function to this patch.
For example, it can be prohibited to load coal and grain together in one bulk wagon.
If you want to allow mixed load as before, you don't need to change anything.


This patch can be tested.



thread 3: bidirectional and can_lead_from_rear
The main discussion in this thread was the convoy reorder algorithm when reversing.
The current reorder algorithm has a bug as I reported here. That patch will fix it.

The modification of the reorder algorithm is greatly affected by the Basic couple constraint and is included in the patch in (2).
As such, (2) and (3) are combined in the same patch.

if you look into RanRan's github repo you can find his published work. link. I'm afraid it looks like his last work was committed on July 30th, after the lengthier post about his intentions.

Yes, that's right.

Maybe this feature is still progressing

No, the progress of this patch has completely stopped because smart implementation methods are beyond my skills.
I think the basic concept of group constraint is also useful in standard.
I think my patch will work as I explained, but I think it's better to change the approach.
For details, please read the explanation of ACarlotti.

[Phystam]

もったいない！Mottainai!
However, this patch (of this topic) makes easier to construct our pakset. Even if you give up to make it, I am still looking forward to seeing it. If anyone can continue to  develop it, I thank them.

[Phystam]

I have an idea to solve the issue (is it truly an issue?)
First, add the vehicle name to group[] (both for front and rear). Then the constraint[] loses any roles, so we can delete it. And after that, change the name constraint_group[] into constraint[]. I didn't see the entire codes, but I believe that it works.

[Ranran(retired)]

I have an idea to solve the issue (is it truly an issue?)

I do not currently believe that there is something wrong with the system itself. After discussion, it was decided that a simpler and smarter method would be better.
But I can't afford to work on this in the near future (that part of the code will need to be largely rewritten.), and it's doubtful if I can implement it with my knowledge. But this is one of the features I really want.
As a result of simplification from the original plan, it will be a simpler form of the standard constraint and I think it will fit in the standard.
Therefore, it is a good idea to suggest to standard development as suggested by ACarlotti.
There are many standard add-ons in Japan and I believe this specification is quite useful for add-ons.