The International Simutrans Forum

 

Author Topic: Basic couple constraint  (Read 4086 times)

0 Members and 1 Guest are viewing this topic.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Basic couple constraint
« Reply #35 on: April 15, 2019, 08:54:24 PM »
The reversal re-ordering is a different issue: the reversing code tests for very specific cases of things that should and should not be re-ordered, and the type of vehicles that you mention are not among those specific cases. If you can add the locomotives in question to a pakset so that I can test, I might be able to add these to the specific case of how to treat reversing if I get the time.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2716
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Basic couple constraint
« Reply #36 on: April 15, 2019, 10:22:41 PM »
I think it would be better to have the code more generic and not dealing with specific exceptions. There are other configurations that behave similarly. E.g. a DMU/EMU with regular waggons attached at the end. It is a working configuration, but the DMU/EMU loses the very quick reversal, as it has to shunt to the other end, but it should move as-is.  I will prepare a sample - I have the class 131 in pak128.cs, but I ca't get the whole pakset working (see my report a few days ago)

Offline Ranran jp

  • *
  • Posts: 483
  • Languages: ja
Re: Basic couple constraint
« Reply #37 on: April 15, 2019, 10:37:36 PM »
Perhaps the solution to that problem is beyond this patch.

I think the Vladki's example is the same issue as the Japanese articulated electric locomotive I mentioned in my previous post.
At least the current extended does not consider the case where the bidirectional = 1 locomotive is single headed.

For example, this type of locomotive never works properly (if you treat this vehicle as two cars).
https://en.wikipedia.org/wiki/SBB-CFF-FFS_Ae_8/14
Japanese locomotive examples:
https://en.wikipedia.org/wiki/JNR_Class_EH10
https://en.wikipedia.org/wiki/JR_Freight_Class_EH500

I'm convinced that the fixed_coupling is useful to reorder the convoy when train reversing also in the current version.
This is because reordering when reversing is actually a re-combination of outside the depot.
A powered vehicle that is fixed_coupling is considered to be a group, and I think that it is the correct operation to shift together when reversing.

I think that adding new parameters to the dat is not a good idea if it is achieved by a review of the algorithm.




Currently, bidirectionl articulated locomotives are shifted as A by reversing.
It will be able to review the algorithm to make this B.

I guess that the same process can handle Garratt and brake tender.
« Last Edit: April 16, 2019, 04:44:19 PM by Ranran »

Offline Ranran jp

  • *
  • Posts: 483
  • Languages: ja
Re: Basic couple constraint
« Reply #38 on: April 16, 2019, 04:23:15 PM »
One thing that might be helpful once this has been finalised is to put up a post somewhere explaining what each of the symbols mean, with pictures of what each of them look like, in a list format.

This is a clutter job (Including the latest in-game demo), but we can display the legend when nothing is selected.
I'm not an English speaker, so I can't make of an appropriate English text, but I think it's preferable to be as short as possible.

Considering the minimum display width of 64px pakset, it may be better to describe only the shape of the bar.
And add the difference between powerd and unpowerd and fixed coupling thing.


What do you guys think about this?


Quote
The explanation should also be in the in-game help files, although unfortunately I do not believe that it is possible to have pictures in these.
I hope that help text can extend the description in html format for added color description and symbol description.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2716
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Basic couple constraint
« Reply #39 on: April 17, 2019, 11:24:52 PM »
Here is an example of articulated bidirectional loco. The weirdness is a bit more than what ranran described.
Lets have a train 12ABCD, where 1 and 2 are engine parts, A-D are wagons.
After reversal it should be: ABCD12
However with bidirectional=0 I get: BCDA21, engines facing properly, but log turnaround
And with bidirectional=1 I get: BCDA21, engines facing wrong, but short turnaround
Note that also the first carriage got pulled to the other side with the engines in both cases.

Testing engine attached (diesel)

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2716
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Basic couple constraint
« Reply #40 on: April 24, 2019, 06:19:44 PM »
I think the discussion about reversal should continue here: https://forum.simutrans.com/index.php/topic,15766.msg154687.html#msg154687
I'm preparing a sample save game with some less usual train combinations.

Offline Ranran jp

  • *
  • Posts: 483
  • Languages: ja
Re: Basic couple constraint
« Reply #41 on: April 27, 2019, 11:59:06 AM »
I am working slowly. (´・ω・`)
I tried adding information of formation to convoy detail window.



I will explain in order from the top.
As I do not know the correct English expression, I will add Japanese sideways. (´・ω・`)

In Japanese, "編成図" is the best word.
(´・ω・`)この編成図は常に左側が先頭です。This formation picture is always head on the left.

- Car no. (号車番号)
The locomotive and others are numbered separately. The letters before the locomotive number can be changed by the translation file.
In case of return trip, car numbers will be in reverse order except locomotive.
The car numbers of vehicles that can be upgraded will turn purple.


- Formation picture (編成図)
This is the same as the depot dialog, but it is used to represent vehicle conditions. i.e. outdated vehicle or not. It does not display the error of coupling.


- Boarding rate indicator (混雑度表示)
Those that do not carry cargo, such as locomotives and caboose, are displayed in gray.
Yellow is empty. 100% boarding rate is orange. The boarding rate over 100% is dark purple. Other than those is lime green.
If there are multiple classes, they will be integrated.


(´・ω・`)らんらん♪
« Last Edit: April 28, 2019, 02:57:54 AM by Ranran »

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Re: Basic couple constraint
« Reply #42 on: April 28, 2019, 10:14:23 AM »
I think this is brilliant!

I do, however, not get the numbering system, in the picture it appears to count backwards or am I missing something?

Skickat från min ONEPLUS A6003 via Tapatalk


Offline Ranran jp

  • *
  • Posts: 483
  • Languages: ja
Re: Basic couple constraint
« Reply #43 on: April 28, 2019, 11:06:11 AM »
Thank you for your favorite  :)

not get the numbering system, in the picture it appears to count backwards or am I missing something?


Numbering is reversed on the return trip.   ;)
The same vehicle will keep the same number in EMU or DMU.
« Last Edit: April 28, 2019, 11:29:35 AM by Ranran »

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Basic couple constraint
« Reply #44 on: April 28, 2019, 05:12:31 PM »
Thank you, Ranran, for your work on this and Vladki for your feedback.

I think it would be better to have the code more generic and not dealing with specific exceptions. There are other configurations that behave similarly. E.g. a DMU/EMU with regular waggons attached at the end. It is a working configuration, but the DMU/EMU loses the very quick reversal, as it has to shunt to the other end, but it should move as-is.  I will prepare a sample - I have the class 131 in pak128.cs, but I ca't get the whole pakset working (see my report a few days ago)

As stated on the thread relating to that topic, modifying this code to do anything other than accommodate new specific cases would not be a simple bug fix but a major new feature which would require to take its place behind all the higher priority features if I were to code this myself. This would mean that it would be likely to be many years before this became the highest priority development task. If anyone else would like to do this, that would be another matter, although detailed discussion would be needed (in the appropriate thread) about how best to design this.

Before I attempt to work on new specific cases, I will need to know whether anyone else is interested in coding the more sophisticated solution to this issue so that no work be wasted. If I do need to attempt to address this as a bug fix, I will also need a compiled pakset in which I this issue can be reproduced reliably (and a fresh thread so that I can keep track of the issue and not lose it in amongst the discussion of Ranran's work on the GUI).


This is a clutter job (Including the latest in-game demo), but we can display the legend when nothing is selected.
I'm not an English speaker, so I can't make of an appropriate English text, but I think it's preferable to be as short as possible.

Considering the minimum display width of 64px pakset, it may be better to describe only the shape of the bar.
And add the difference between powerd and unpowerd and fixed coupling thing.


What do you guys think about this?

This is helpful, I think: I am happy to rewrite the English translations once the code for this is finalised. Presumably, you would be happy to provide the Japanese translations?

I should be grateful for anyone else's view on the clarity of this display.

Quote
I hope that help text can extend the description in html format for added color description and symbol description.

I am not sure whether this is possible and have not looked into this, but if this were possible, it would be a helpful thing.

I am working slowly. (´・ω・`)
I tried adding information of formation to convoy detail window.



I will explain in order from the top.
As I do not know the correct English expression, I will add Japanese sideways. (´・ω・`)

In Japanese, "編成図" is the best word.
(´・ω・`)この編成図は常に左側が先頭です。This formation picture is always head on the left.

- Car no. (号車番号)
The locomotive and others are numbered separately. The letters before the locomotive number can be changed by the translation file.
In case of return trip, car numbers will be in reverse order except locomotive.
The car numbers of vehicles that can be upgraded will turn purple.


- Formation picture (編成図)
This is the same as the depot dialog, but it is used to represent vehicle conditions. i.e. outdated vehicle or not. It does not display the error of coupling.


- Boarding rate indicator (混雑度表示)
Those that do not carry cargo, such as locomotives and caboose, are displayed in gray.
Yellow is empty. 100% boarding rate is orange. The boarding rate over 100% is dark purple. Other than those is lime green.
If there are multiple classes, they will be integrated.


(´・ω・`)らんらん♪

This is very useful and interesting, thank you.

May I ask whether you consider this ready for testing at this stage, or did you want to do any more work to it first?

Offline Ranran jp

  • *
  • Posts: 483
  • Languages: ja
Re: Basic couple constraint
« Reply #45 on: May 06, 2019, 01:34:35 PM »
Well, I resumed the work and reviewed the whole patch. I have uploaded my work to my github repository. You can test this. Any feedback on this will be welcome.  :)

The change was larger than expected. (´・ω・`)
There are many code that were moved and rewritten. I would appreciate it if you guys could give me some advice.  :-*

For the patch to work properly, the vehicle must be packed by the new makeobj(60.04). (makeobj 60.04 can download from here)
The pak created by the old makeobj will set the parameters automatically, but that's not perfect.  ::(

1. Symbol legends:
It became this shape.

Review the original text before adding the translated text. I will add a Japanese translation after that. Note that the width may not be sufficient for a 64 px size. :warning:

2. dat reference:
The new parameters are..
Code: [Select]
constraint[prev][0]=any
fixed_coupling[prev]=0/1
fixed_coupling[next]=0/1
has_front_cab=-1/0/1
has_rear_cab=-1/0/1
The meaning of the parameters is left as is. Should I put outside_the_depot? It is a fairly long string. Parameter name may be strange, so in that case, it would be helpful if you could point it out.
-1 means automatic setting. It is often determined by the contents of the constraint. If there is a conflict, it is ignored.


3. Reorder algorithm:
I reviewed the meaning of the symbols and modified the reorder algorithm. This is a recombination puzzle using symbols.
It breaks convoy into three groups, locomotives, coaches, and cabooses, and reorders each. It does not reorder if locomotives requires a turntable.
I would appreciate it if you could check if it is working correctly.  The convoy detail window will help you check it. Debug build displays yellow asterisk to the right of the reversed vehicle number.


There are three categories of Reversing messages:
Reversing / Shunting / Changing direction
We might be able to break them down a little bit.  :lightbulb:
The same is true for reversing time. That is, the difference between a single locomotive and two locomotives that require a turntable.


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


EDIT:
If you pak with the new makeobj, you don't need to edit the old .dat much.
This is because it depends heavily on the description of constraints. The description of constraints takes precedence and attempts to eliminate the conflict.

can_lead_from_rear=1 indicates the possibility of having a driver's seat, and the side that can be the front/rear is automatically recognized as the driver's cab.
Correct dat if it is incorrect.

If there is only one constraint other than none, it is automatically recognized as permanent_fix and fix_coupling(out side the depot), so you do not need to describe about cab and fixed_ parameters. The cab description is then ignored.

If a vehicle with bidirectional = 0 can be at the front, it is automatically recognized as having a cab in front; if it can be at the rear, it is recognized as having no cab. Anything else is ignored.

I think symbols make it easier to find constraint errors. ;)

The branch of Britain-Ex is here.


Secondary effect:
Coaches and brake vans without cabs can be the rear, but never the front. Therefore, these do not appear in the options unless you choose a locomotive first.


makeobj update to 60.04
« Last Edit: May 18, 2019, 01:21:02 PM by Ranran »

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Re: Basic couple constraint
« Reply #46 on: May 11, 2019, 12:20:45 AM »
I think it is brilliant to show the symbol legends when no convoy is selected in the depot!
If you dont mind, I just have some notes with some suggestions  :)

1) "Select vehicles from the list and assemble conboy" (typo) :)

2) When looking at the symbols, one gets the impression that it is the "entire" symbol that determines what the vehicle represents, when in reality vehicles might have one end of the symbol in one end and another in the other end. If you separate the bars in the middle, perhaps with a jaggered end towards each other to symbolize a broken bar, it will be very clear that it is the ends of the bars, and not the bars them self, that are describing the features.
However, the powered/unpowered bars looks OK, since that is the middle of the bar you are describing.

3) My old "issue": Fixed couplings equals permanently attached vehicles outside the depot and IMO doesnt need distinguishing. The two help text entries unfortunately does not clear out the confusion why some vehicles should be treated as "permanently" attached to each other and others "fixed" to each others. Writing it out in text in this place would most likely take up alot of space and feel clumpsy compared to the rest of the legend section. The effects are the same anyway (non-detachable vehicles) and that is the only thing that counts, sorry.
However, I would like that you symbolize a fixed coupling with the two halfs and the black bar (as you currently are showing the "permanently" symbol). That helps the player understand that that connection cannot be broken outside the depot.


2. Dat reference:
I dont think we would need a -1 for the "has_front/rear_cab". The point of the entry in the datfile is that the author can determine that it has particular cabs or not. For any vehicle without the entry the default I believe should be 0 (no cabs) if I have not misunderstood anything?
I also think there is no need to add "outside_the_depot". It should be fairly obvious for the pakset author.

Offline Ranran jp

  • *
  • Posts: 483
  • Languages: ja
Re: Basic couple constraint
« Reply #47 on: May 11, 2019, 01:49:38 PM »
Thank you for your advice. That's very helpful.

I changed the legend based on your advice.


Does this change make sense?

About Permanent Coupling:
It is conscious of the form of looking at two separate things as one. The existence of jagged edges become a lie, so we need to hide it. So I cover it with a black vertical bar.

This will be used mainly in the following cases
- a pair of unit
- one vehicle is divided into two because the cargo category is different

This is especially useful if players want to understand the formation of EMU. Many trains today are unitized.
For example, when remove it from the assembling convoy in the depot, it is obvious that deselecting one will simultaneously release the permanently coupled vehicles.

I dont think we would need a -1 for the "has_front/rear_cab".
The -1 setting exists for compatibility. When using a new makeobj, it is necessary to describe the presence or absence of a cab on all vehicles if the absence of a cab is determined forcibly.
By setting the default to auto, only the minimum necessary description is required. I have already finished changing the minimum .dat of the britain pak. It will not require many .dat changes.

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Re: Basic couple constraint
« Reply #48 on: May 12, 2019, 06:48:44 PM »
Thank you for your advice. That's very helpful.

I changed the legend based on your advice.


Does this change make sense?
Yes, that does look much better! I dont know how you are doing the bars, wether it is all png graphics or if the shapes are coded directly in the code. I was thinking that you maybe could emphazise it even more if you have like a "broken" connection between the ends, so it looks like you have taken the bar and broken it into two bars. That is a common way of telling that it is a "continuity, but we focus on this end", if you understand?

But I see that you took away the fixed coupling bar and just made it the small black bar, and that I think is not so good. It would be better IMO if you do like the other entries, that would be the half's of the bar with the small black dot next to it.

Quote
About Permanent Coupling:
It is conscious of the form of looking at two separate things as one. The existence of jagged edges become a lie, so we need to hide it. So I cover it with a black vertical bar.

This will be used mainly in the following cases
- a pair of unit
- one vehicle is divided into two because the cargo category is different

This is especially useful if players want to understand the formation of EMU. Many trains today are unitized.
For example, when remove it from the assembling convoy in the depot, it is obvious that deselecting one will simultaneously release the permanently coupled vehicles.
I have a feeling we can discuss this on and on and on why I think its a bad idea and you think it is a good idea.
I see all cases of two vehicles that would be fixed to each other as "a pair of units", no matter if I could have chosen five different vehicles to "fix" to the initial vehicle or only one. It doesnt make any differense.

As to the jaggered ends for fixed couplings, why should you hide it? I anticipated that the shapes of the bars would be the same, no matter wether the coupling was fixed or not. Especially the shape for cab's end should be usefull to have also for fixed couplings.

Quote
The -1 setting exists for compatibility. When using a new makeobj, it is necessary to describe the presence or absence of a cab on all vehicles if the absence of a cab is determined forcibly.
By setting the default to auto, only the minimum necessary description is required. I have already finished changing the minimum .dat of the britain pak. It will not require many .dat changes.
I believe the default should be 0 to make it as failproof as possible, both for the pakset author to debug the pakset and for the code maintainer.
But I would be carefull to start the editing proces of pak britain until the different mechanism's are completely implemented. You never know how and if James will eventually incorporate changes in the end.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Basic couple constraint
« Reply #49 on: May 16, 2019, 10:21:10 PM »
Ranran - my apologies most sincere for not having had a chance to look into this and the related topic relating to can_lead_from_rear (etc.) recently: these topics need to be considered together and require a lot of time and effort to do them justice; I have been quite busy with other things recently and have not had that time to spare. Such time that I have had for Simutrans I have had to spend on fixing bugs. Hopefully, I will be able to look into this in more detail soon and move towards integration.

I very much appreciate the work that has gone into this.

Offline Phystam jp

  • *
  • Posts: 248
  • Pak256.Ex developer
  • Languages: JP, EN, EO
Re: Basic couple constraint
« Reply #50 on: May 17, 2019, 12:35:11 PM »
I tested it using pak256-Ex. It seems worked well, However, I do not know which I should check. Ranran, Can you help anything related to this? Check list is most helpful for me.


Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Basic couple constraint
« Reply #51 on: May 18, 2019, 10:23:53 AM »
Thank you very much for your work on this: it is much appreciated.

First of all, when I tried to merge the code from your basic-constraint-extension branch into the code from the master branch (on a new branch on my repository created from the master branch), I ran into merge conflicts, especially with simversion.h: it appears that this code increments the saved game version. May I ask what additional data are actually written with the saved game? The version will need to be brought up to date with that on the master branch (i.e., one ahead of it, with the lines of code for loading/saving the individual data modified accordingly) so that I can test it.

I do like these sophisticated set of symbols, and showing the help text when nothing is selected is definitely a good idea. I agree with Ves's suggestions and like your way of showing the fragments of the symbols.

As to the .dat file syntax, may I suggest that fixed_coupling_prev and fixed_coupling_next become fixed_coupling[prev] and fixed_coupling[next] in order to make this consistent with the constraints? Also, I think that using numbers other than 1/0 for logical (as opposed to numerical) input is potentially confusing. These data can be coded in makeobj as these numbers (-1, 0, 1), but it might be sensible to have them be able to be specified in the .dat files as a string; I believe that there is a function that will extract strings from .dat files, which can then be used with strcmp() to extract the data for writing to the file. Alternatively, the syntax might simply be that "-1" can in theory be specified, but that the way that people are encouraged to write .dat files is just to omit has_front_cab or has_rear_cab if they want the default/automatic behaviour. In relation to what the default should be, I agree with your original idea (if I understand its implementation correctly) that sets -1 as the default, as this will be, if I have understood correctly, the most compatible with existing paksets without the has_front_cab or has_rear_cab data specified. I think that it is best not to use the "outside_the_depot" part of the string, as this is, as you note, rather long.

As to the reordering algorithm, I will need to be able to test this (see above on merge conflicts) to be able to comment on this in detail - but thank you very much for looking into making this algorithm more sophisticated: it is much appreciated. One query with this is how you intend can_lead_from_rear to interact with has_rear_cab; is the idea that has_front_cab and has_rear_cab will supersede can_lead_from_rear, which will be retained for legacy compatibility, or is the idea that they will continue to retain distinct and useful functions?

Finally, it is good to see this being tested with Pak.256-Ex!

Offline Ranran jp

  • *
  • Posts: 483
  • Languages: ja
Re: Basic couple constraint
« Reply #52 on: May 18, 2019, 12:33:19 PM »
I have to write a lot of replies, but I only post the urgent contents first.
Quote
I ran into merge conflicts

This seems to be a conflict with the ACarlotti's fix from 6 days ago. (At that time, SAVE_MINOR became 11.) I have not changed SAVE_MINOR.
On the other hand, I increased EX_VERSION_MINOR to clarify it because the dat format for vehicles has changed.
i.e. version 14.6

Quote
One query with this is how you intend can_lead_from_rear to interact with has_rear_cab; is the idea that has_front_cab and has_rear_cab will supersede can_lead_from_rear, which will be retained for legacy compatibility, or is the idea that they will continue to retain distinct and useful functions?
The flags fix_coupling, has_cab, and constraint[]=any are stored in a new area called basic_coupling_constraint. This replaces the old bool can_be_at_rear area.
Can_lead_from_rear is no longer used, but it remains because it does not need to be erased immediately. So it can still be used.
The CLFR is also used for compatibility with older paks. A vehicle with CLFR=1 is considered to have a cab if it can be the front or rear.


Ranran, Can you help anything related to this? Check list is most helpful for me.
Thank you for the testing. What does a checklist mean?

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Basic couple constraint
« Reply #53 on: May 18, 2019, 01:16:19 PM »
Thank you for your replies. First of all, you do not need to change EX_SAVE_MINOR if you are only updating the .dat file format: this has its own versioning system independent of the saved game versioning system. This datum should only be updated if the saved game format changes.

As to the can lead from rear parameter, that is perhaps best discussed in more detail on the other thread, and I have set out some suggestions there.

You may also want to have a look at this thread regarding some of the new schedule/vehicle management features on which I had worked in early 2018 and which I am in the early stages of reviving to continue the work to check that none of what is proposed here conflicts with that work and to see whether there can be any useful integration between the two feature sets (and, if so, to discuss how best to go about this integration).

Thank you again for your work on this.

Offline Ranran jp

  • *
  • Posts: 483
  • Languages: ja
Re: Basic couple constraint
« Reply #54 on: May 18, 2019, 01:41:03 PM »
As the name of "basic" suggests, this patch builds an ambiguous constraint such as constraint=any.
The symbol representing the ambiguity is the end shape. The method of reversing reorder is also determined by its shape. The basic constraint parameter is the data for the shape of this symbol.
For example, a rounded edge can be at the rear, and a pointed nose can be at the front. Jagged edges can't be at front and rear.
Fixed coupling will be useful in a recombination system. This is based on the idea of Ves in that thread.

The only piece of information that I think is missing is whether the head can couple something more. That is, the difference between only be at front and can be at front.
For example, if information can be read from the formation picture as to whether one set of EMU can be combined with another set of EMU, I think it would be useful in recombination.

Offline Ranran jp

  • *
  • Posts: 483
  • Languages: ja
Re: Basic couple constraint
« Reply #55 on: May 18, 2019, 05:02:17 PM »
Quote
I dont know how you are doing the bars, wether it is all png graphics or if the shapes are coded directly in the code.
This is a type of color bar because it needs to support a variety of colors. Left and right are displayed separately.


permanent_coupling vs fixed coupling, I think there is a clear difference between these two.
The term permanent _ coupling may not be appropriate.
It is "fixed anywhere" and "fixed out side the depot".
In other words, "cannot detach out side the depot" and "cannot detach anywhere".
One (permanent) is completely superior and includes inferior.


Quote
I have a feeling we can discuss this on and on and on why I think its a bad idea and you think it is a good idea.
I'll give you an example of how that might be useful.


I am currently running EMUs which is 4 cars set. But it is always crowded, so I would like to add vehicles to its formation.
So let's check the formation of this EMU.


Example Train A:
If there is a "fixed anywhere" distinction, it is displayed like this

The EMU suggests the possibility of connecting other vehicles between the first and second and third and fourth cars.
Since intermediate cars do not have cabs, they are often cheaper and have more capacity than cars with cabs. It's economical.
It may be possible to attach a new EMU set to another EMU set, but it is not possible to read from this figure. (This is also something I want to improve.)
However, formation with four cabs is very uneconomical if it does not carry out decoupling and annexation.
So what I need most now is a new middle car.
Train A has that potential. Then, let's consider adding an intermediate car from the replace dialog.; )



However, if there is no distinction between them, such information cannot be read.
So you should always open the replace dialogn to check.



Example Train B:
This is another four-car train example.

If there is a "fixed anywhere" distinction, it is displayed like this


This clearly shows that the four cars are fixed units. That's why it's impossible to add intermediate cars. So increasing the number of both means adding extra cabs.
Since Ranran is the president of rationalism and never does such an uneconomical thing, I can immediately decide to transfer that **** train to another line or scrap it.
If the same EMU set is added, it is likely to be 4 + 4, or 8 cars.
I might want to form a six-car formation because of the station tiles.
You can read it from the formation picture.
Yeah, I didn't bother to open the replace dialog. (´・ω・`)b


The train geek may also discern the vehicle type from the position of the permanent coupling and motor. Don't underestimate their abilities.  :::)



This is something I've written before, but it can indicate that the convoy is forced to bring another vehicle when player purchase one in a depot.
This is the current simutrans unfriendly design, which can cost extra money or exceed the expected station tile length.
Sometimes the pakset author writes all costs and output power on the first vehicle, but it is incorrect.
When you build a convoy from rear it looks free. Such as tender locomotive, Garratt, or a concatenated tram.

I think it would be nice if I could add up the unit price power length and so on.  :lightbulb:
The locomotive had to write the power to the first car, but with my patch it's no longer necessary.
Garratt can describe power to the central vehicle. This will allow the formation picture to recognize that it is a garratt.



For the above reasons, I believe that these distinctions are useful.


I tried to find a good example from pak.Britain, but I couldn't find a good one because the EMU in the UK looks very inflexible in formation.
It mean that it is difficult to flexibly make a long formation without a useless cab like the one I explained. Or, since it doesn't have a motor other than the head, the MT ratio decreases as the middle car is connected.
Many Japanese EMU, especially the Japanese National Railways, have a high formation flexibility, so it is easy to add intermediate car in between.
I suppose that may be the reason why you don't understand the necessity of it.
I think you might consider the basic formation of EMU is same until it scrapped.
EMU in the britain pak, in my view, often forms a mass of two, three, or four cars, many of which have no intermediate power units, and therefore end up with more cabs.
But many cabs are useless if convoy can't detach.



For example, this Japanese EMU can form such a flexible formation. (This train is the same one that Pystam showed in the example.)

This is by no means an edge case, it is the most manufactured class in Japan with 3447 cars.
Of course, there are ones with fixed 2 cars and ones with fixed 3 cars. That's why this difference is so significant.


Quote
I see all cases of two vehicles that would be fixed to each other as "a pair of units", no matter if I could have chosen five different vehicles to "fix" to the initial vehicle or only one. It doesnt make any differense.
I see the difference here. Maybe the meaning of "unit" is different between you and me(Japanese).
I am trying to represent "units" with permanent coupling. In Japan, a "unit" means multiple vehicles that are systemically fixed.
Especially today, we need a lot of machines, so we put them on multiple vehicles. For example, pantographs, Auxiliary Power Units, air compressors, master control systems, converters.
The dispersed vehicles are regarded as one unit. This does not include the cab. The driver's cab controls multiple units. It is assumed that the cab always comes at the beginning and end and can control all power units.
The formation picture shows the existence of the cab, so it plays a sufficient role. I am trying to represent "unit" with permanent coupling.
Perhaps the "unit" Ves is considering is from the front cab to the rear cab. That's the difference.

In Japan, EMU has been the mainstream for a long time. Passenger trains pulled by locomotives died out early.
EMU also has the flexibility to add coaches to locomotive-driven train. There is an idea of "intermediate unit".

By adding a power unit and a trailer car in the middle in a balanced manner, car numbers and power output are kept in balance.

For example, there is a Japanese-made EMU called class 385 in Scotland.
This class has three cars formation and four cars formation.
This class has power car of 1000 kw (it has 4 motors) and a power car of 500 kw (it has 2 motors), and the balance of 1 car is 500 kw in both formation.
One motor car of the three-car formation has no motor on one bogie.
Equalizing the power balance is important for on-time operation.

(BTW, the spec of Britain-ex class 385 seems to be different from the real.)
http://www.hitachi.com/rev/archive/2017/r2017_02/pdf/18-24_R1-02.pdf
Code: [Select]
There are two types of Class 385, a four-car train
set and a three-car train set. The four-car train set
has two motor cars (M) and two trailer cars (T) in
what is called a 2M2T configuration. For a three-car
train set, in contrast, sufficient traction capacity is
provided by 1.5 M cars. Accordingly, the Class 385
adopts a system in which the traction unit (converter)
is split into two drive systems, with each car having
two motor bogies that are controlled separately (see
Fig. 4). This means that three-car train sets can have
a 1.5M1.5T configuration in which one of the bogies
on one of the two M cars is a trailer bogie, thereby
eliminating two traction motors and one traction unit
drive system. This configuration reduces the weight of
a three-car train set by approximately 1.5 t.

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Re: Basic couple constraint
« Reply #56 on: May 18, 2019, 07:22:12 PM »
I still call it "permanent coupling" and "fixed coupling" since the words are shorter and easier to remember  :)

Example A and B:
Indeed, in the case you describe you can easily determine that the vehicles cannot be altered in the depot or by the replacer in any way with the "permanent coupling". But you should remember that you are on the other hand not guaranteed that you can alter the other "fixed connections" for the other vehicles either. That makes it NOT a distinction wether it is a truly "permanent coupling" (no other vehicles can connect due to the other vehicles constraints/availability) or just a "fixed" coupling (other vehicles in the depot can connect). That would still require a visit to the replacer window to find out.

Regarding the japanese way of building trains, I get that there is some flexibility in some EMU's and lesser in others, and some units (a 'unit' being a single vehicle on its own structural frame) having to be together for the train to work. But if, say, such a unit had a variation for whatever reason, hence triggering the "fixed" symbol instead, you could not rely on the symbol anymore to detect those units (since the "permanent coupling" symbol only appears when there is exactly one (available?) vehicle in the constraint specification). Then some of those units would have the "permanent coupling" marker and others have just the "fixed coupling" marker for no other reason than the unit exists in two variants. Wouldnt you find that inconsistent?
Maybe it is not planned to have multiple variants of the same units in the japanese pakset, but that will most likely not be true for every other pakset.

The flexibility of EMU's is a feature also in Sweden where different companies have bought versions of the same EMU with different amounts of units. The units being physically fixed to each other until either scrapped or sent to the workshop to get reused in new configurations (although I dont think that has ever happened, save for X2000). I dont plan it to be a feature that some units have a more "fixed connection" than others, even though I will constrain certain units to each other because of their real world counterpart always have those two units next to each other. But due to some variations that have existed (seat configurations, catering capabilities, power variants etc) I need to make the initial unit able to connect to all of them and vice versa.

What you could consider in the japanese pakset is to have all those EMU's as not fixed couplings, but I guess they are fixed couplings in real life, and so should be fixed couplings in Simutrans as well.
What it really feels like you want is a third way to group vehicles together visually, some granularity to the fixed couplings to determine that "those connections are more fixed than those". I can understand that, although I dont think it would be needed in the swedish pakset.
But I higly disagree that the determination of "permanent coupling" is done the way it is, since that will affect all vehicles in all other paksets as well.


Getting rid of the autobuy feature is indeed possible, and it would not change any game mechanics in any way. You still have to buy all needed vehicles in order to make it leave the depot.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2716
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Basic couple constraint
« Reply #57 on: May 18, 2019, 10:33:07 PM »
I still do not get why the difference between fixed and permanent coupling should be important in the game. Thinking of EMUs, all of them can be rearranged with enough effort. Even if it is not done in practice, in theory it should be possible. What may be interesting is to charge some extra fee for decoupling and rearranging such train in depot.

The only vehicles I can imagine, that can never be decoupled are maybe garrats or articulated buses and trams. And that's maybe only because there is no choice of alternative parts. But in practice you still can swap the parts. E. G. Make one articulated bus from two which were damaged in accidents (one damaged in front, one in rear, take the good parts and connect them.)

So imho it is not worth creating a coupling that can never be decoupled. Otoh it might be worth to charge for decoupling fixed/permanent coupling in depot.

Offline ACarlotti

  • *
  • Posts: 483
Re: Basic couple constraint
« Reply #58 on: May 19, 2019, 12:45:08 AM »
But if, say, such a unit had a variation for whatever reason, hence triggering the "fixed" symbol instead, you could not rely on the symbol anymore to detect those units (since the "permanent coupling" symbol only appears when there is exactly one (available?) vehicle in the constraint specification). Then some of those units would have the "permanent coupling" marker and others have just the "fixed coupling" marker for no other reason than the unit exists in two variants. Wouldnt you find that inconsistent?
I think you are misunderstanding the proposal (unless I have misunderstood it instead).

I think EMUs are a bad example of what Ranran calls a 'permanent coupling', since in theory it would normally be possible (at some expense) to separate a unit into its constituent carriages and combine it with different carriages (probably requiring a lot of work in a depot and some software configuration, but that's not infeasible). This isn't usually a routine operation, because there's very rarely any need to do so. However, I can think of two situations where this would occur. Firstly, multiple units are sometimes lengthened (by inserting carriages) or shortened (by removing carriages) to upgrade the service in one location, or to reuse them on a less demanding service (e.g. the old Great Western Railway HSTs, which are being shortened and reused in Scotland). Secondly, sometimes an accident results in a portion of a multiple unit being temporarily or permanently unavailable. If this happens to more than one multiple unit, then the undamaged portions of different multiple units might be recombined to form a new working multiple unit.


I have two suggestions that might help. Firstly, I would change the name to 'permanent connection'. This avoids the word 'coupling', which to me implies that it is possible to uncouple (though not necessarily everywhere).
And secondly, I think a much better example of a 'permanent connection' can be found in ships. In pak128.Britain, it is common for ships to have space for multiple holds - these holds can then potentially provide for a number of different goods types. Since the hold is literally built into the structure of the ship (presumably upon construction), then it would be infeasible to switch holds between different ships (in a much more fundamental way than applies to trains or any other convoy that can bend between vehicles). This need not prevent changing what a ships can carry, but such changes would need to be made by converting (upgrading) one type of hold to another. Furthermore, this would have a meaningful effect on gameplay, unlike an example of a rigid vehicle represented as two vehicles in Simutrans with a unique configuration, where the potential to swap vehicle halves would have no benefits (compared to not swapping halves).

So imho it is not worth creating a coupling that can never be decoupled. Otoh it might be worth to charge for decoupling fixed/permanent coupling in depot.
As written above - we've forgotten about ships.

Offline Ranran jp

  • *
  • Posts: 483
  • Languages: ja
Re: Basic couple constraint
« Reply #59 on: May 19, 2019, 07:05:54 AM »
I use the expression "permanent connection" as proposed by ACarlotti.


Quote
Then some of those units would have the "permanent connection" marker and others have just the "fixed coupling" marker for no other reason than the unit exists in two variants. Wouldnt you find that inconsistent?
I do not think that is inconsistent, because there could be an example of one "fixed" and the other "not fixed".

It is treated as fixed because one side is not fixed but the other side does not allow disconnection.
If permanent connection is inconsistent, then normal fixed will also be inconsistent.
It will feel a bigger inconsistency because it doesn't seem connected.


The above example is often found in DMUs.
The single-head diesel car which has engine and cab, is detached at the station and can be returned to the depot on its own or wait for another train to arrive. Therefore, it is not included in fixed outside the depot.




The convoy assembling behavior in the GUI has the following distinct differences between "permanent connection" and the others:

Normal Coupling (Include fixed):


Permanent connection:



However, there is currently no indication of the difference in this behavior, so the player cannot know in advance.
I find this very inconvenient.

At least the "permanent connection" sign serves as an expression of "automatic coupling" or "automatic back to storage" in the depot.
Changing yellow bar to another color does not solve this problem.
This is not supported for back to storage. All convoy's already assembled are usually show green bar.

I also think it can give a notice to display the information when implementing the function to display the total of the vehicles combined together when selecting a vehicle in the depot.
That is, the total length and price are displayed when the player hovers over the vehicle having that symbol. So you can check before you purchase.



I don't think it's necessary to distinguish between real units.
There is also a large discrepancy in representing the passenger and mail compartments in the same vehicle as two vehicles. (As ACarlotti points out)
It is sufficient for the meaning of the symbol to have only one coupling partner.

In that way, I think there are some situations where this distinction is useful. And since it doesn't look much different than a fixed couple, it won't be too confusing.
Rather, I think the difference in GUI behavior will continue to cause a confusion if we don't make this distinction.
Since "permanent connection" also has the characteristic of "fixed couple" there is not much difference in the meanings of the two symbols.


In addition, vehicles that are permanent connections often share maintenance information (Upgrades and timing of retirement), and it is worthwhile to be able to read it from picture.
For example, vehicles of different types may be mixed, but the unit vehicles of permanent connection are almost the same class.
On the other hand, the fixed relationship may simply be EMU or DMU, or a vehicle manufactured at a completely different time.

Quote
But in practice you still can swap the parts.
This is currently impossible. It's hard to create an opportunity for permanent connection vehicles to have separate parts because selling one vehicle automatically sells the other automatically. (However, if both sides are not permanent connections, they may not all be sold.)
The same is true for upgrades. If all the upgraded vehicles are upgraded with the same combination, upgrading one will upgrade all the others automatically.
However, complicated upgrade settings can leave a part alone. (For example, one of the permanent vehicles can be upgraded to a different vehicle that does not have a connection relationship.)


Quote
That would still require a visit to the replacer window to find out.
However, it is possible to omit the confirmation process in comparison with the case where no distinction is made.
For example, if there is a distinction in "Train A", the question is whether it is possible to remove the 1st or 4th car and connect another car to there.
If there is no distinction, I don't know what to check first, so I may remove the second car. (Because the first cab is absolutely necessary.). Then the third car will be removed together automatically. Then you will have more work removing the 4th car. After all, it takes the same labor as reassembling from the beginning. It is caused by unfriendly GUI.


Quote
But due to some variations that have existed (seat configurations, catering capabilities, power variants etc) I need to make the initial unit able to connect to all of them and vice versa.
I don't think so. "Power units" usually do not separate.
There is a description in Japanese here, but unfortunately there is no similar description in the English version.
For example, a plurality of dedicated cables are provided between a motor car equipped with a pantograph and a motor car not equipped with the pantograph, but it is not required between the power unit and another car. And a device on one side controls eight motors. And there's no need to use a normal coupler between them, and they are fixed by bar and bolts together.

For example, in this image, look the between vehicles. You can see that the shape of the coupler and the number of cables vary between vehicles.
http://kakeyama.kokuden.com/commuter/e233r6k.htm
There are many cables between "power units", and rod couplers are used.

This is a topic related to the reverse of individual vehicles, but of course, "power unit" cannot be reversed and coupling each other because of the arrangement of equipment. Basically, other than the intermediate units of the modern EMU, they are not designed to be connected in different orientations due to equipment or cable location. Therefore, as Vladki said, reverse also needs to reverse the connection. However, there are also cases where the connection is made in both directions at an extra cost. especially the side having a cab.
It is called "両渡り構造"(two-way structure?) in Japanese, but I don't know what it is called in English. You can see that sometimes jumper cables are only on one side.



One more example, this articulated locomotive is a permanent connection. They never swap with other same class ones. On the front is the car's serial number 4, but of course on the other side shows also serial number 4.
But that of pak.CS may not be, idk.

EDIT:
In many cases the term permanent was also incorrect. This is also expressed as semi-permanent in Japanese.
They can't be separated in the depot, but they can be separated in the factory (place where an overhaul might be performed).
What I want to express is semi-permanent coupling.
« Last Edit: May 19, 2019, 08:06:45 AM by Ranran »

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18745
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Basic couple constraint
« Reply #60 on: May 19, 2019, 12:11:46 PM »
We have a number of issues here.

Permanent connexions and fixed couplings

Ranran distinguishes two different cases, and Ves suggests that only one conceptualisation will suffice; but there is actually a subtle distinction within one of Ranran's cases. If we are overhauling this system to have a more comprehensive representation of reality, then we might want to distinguish:

(1) vehicles that may be coupled/uncoupled in service;
(2) vehicles that may be coupled/uncoupled only in the depot to form other trains; and
(3) vehicles that cannot really be coupled/uncoupled at all.

The distinction between (1) and (2) will only be relevant when the new schedule features are implemented, but it will be important when they are. The distinction between (2) and (3) is the distinction between a Garratt (which is in three separate parts which turns corners as three separate parts) but cannot under any circumstances actually run without those three exact specific parts in that exact sequence, and a multiple unit with a fixed inter-carriage coupling (such as the London Underground S stock in modern times, or some of the early Metropolitan Railway multiple units with bar couplers that could only be uncoupled in the workshop) which can be re-assembled, but only as a significant workshop job rather than readily in service. Indeed, some of these early Metropolitan Railway multiple units with the bar couplers were later rebuilt to have conventional couplings (or a near identical type built with conventional couplings; I forget which) to allow them to be recombined more easily.

A. Carlotti mentions a fourth possible distinction, which is irreversible connexions, such as holds in a ship. I am not sure whether these would be necessary, since a ship can in principle be refitted to have different holds, although this might have a cost in reality. Some further thoughts on whether these in reality should fall into class (2) above or whether they need their own fourth class may be needed. I also note that Ranran distinguishes between a depot and a factory (which might be termed a "workshop" in the context of 19th century and 20th century railways in the UK). Currently, we do not have that distinction in Simutrans-Extended, and there are no plans to introduce it. The question is then whether the depots that we do have should be considered as depots or workshops for these purposes, given that we have no option of having separate workshops.

A related thing to note in relation to vehicles that do not normally uncouple and become re-combined even within the same type (such as the example of which Ranran gave a picture) is that, in some places at least, combining parts is common on overhauls. This video, for example:


describes 'bus overhauls in Aldenham works in the 1950s. It was common for 'buses coming in for overhaul to leave with a different body/chassis combination than that with which they arrived. Again, given that overhaul is a feature that we are planing to introduce, some consideration may need to be given to just how permanent that these couplings should really be.

Nomenclature of "unit"

There may well be a real difference in the use of "unit" in English and Japanese - the word "Unit" in English in the railway context applies normally as a shortening of the phrase "multiple unit", which refers to passenger (or, less commonly, mail) carrying vehicles with built-in power and driving cabs that can be combined together to form trains. The word does not generally refer to an entirely fixed set of vehicles. Perhaps we might use "multiple unit" and "fixed unit" to distinguish these cases in future?

Automatic purchasing

I note that Ranran is not keen on the automatic purchasing function. I should be interested in people's views on this. This is, as he notes correctly, from Standard, and is presumably intended to make it easier to assemble fixed formation trains as it avoids unnecessary mouse clicks. If this feature were to be abolished, a player would have to click each of (for example) four cars individually to make up a train that can only ever be formed of those specific four cars.

Ranran writes that this could solve the issue where the first car in a train is often given the cost and power, whereas in reality all the different cars had their own cost and power (which may be zero in the latter case). I do not think that removing automatic purchasing alone could do this, since the reason to do this is so that the player knows the cost and power of the set before buying any of the members of that set. As things stand now, unless the player selects "show all", which gives a very cluttered view of all possible vehicles available in the current era, the player cannot see the cost and power of the next unit in the sequence without buying the first unit. Disabling automatic purchasing would not alter this; the player would still have to purchase the first unit.

However, in circumstances where, if a player sells a vehicle in the same game month as that in which it was purchased without ever having used it, a full refund is given, is it necessary to disable the automatic purchasing feature? If a player finds an automatically combined set of vehicles unsuitable, they can readily be sold.

Might it be worthwhile alerting the player somehow to the possibility of automatic purchasing and selling instead of abolishing this feature?

Testing the code

I have now had a chance to test this briefly - thank you for the fix to the versioning. One thing that I notice on loading the Pak128.Britain-Ex demo game is that, on entering the depot, the 4-SUB unit does not appear to conform to the description of the symbols, in that the intermediate vehicles have the symbol showing that they can be at the rear of the train, yet they cannot. However, is this the expected behaviour when the pakset has not been compiled with the dedicated version of makeobj? If so, I wonder whether some different defaults might be useful, as I cannot immediately see how a vehicle that does not have either no "next" constraints or a "none" constraint should ever show the symbol for allowing it to be at the rear of a train.

The symbols do look good, though: very tidy, clear and polished.

I have noticed some overlapping text in the details window, where "LOCO_" (something, which I cannot read because of the overlapping) overlaps with the numbers for the individual vehicles. This can be seen in convoy no. 101 in the Pak128.Britain-Ex demo game.

Offline Ranran jp

  • *
  • Posts: 483
  • Languages: ja
Re: Basic couple constraint
« Reply #61 on: May 19, 2019, 01:08:21 PM »
One thing that I notice on loading the Pak128.Britain-Ex demo game is that, on entering the depot, the 4-SUB unit does not appear to conform to the description of the symbols, in that the intermediate vehicles have the symbol showing that they can be at the rear of the train, yet they cannot. However, is this the expected behaviour when the pakset has not been compiled with the dedicated version of makeobj?
Yes, that's right. The new makeobj writes the vehicle bar shape flags(basic_coupling_constraint) with reference to the constraints and cab and fix parameters.

Quote
If so, I wonder whether some different defaults might be useful, as I cannot immediately see how a vehicle that does not have either no "next" constraints or a "none" constraint should ever show the symbol for allowing it to be at the rear of a train.
I will consider the handling of the vehicle made with the old makeobj.


Quote
I have noticed some overlapping text in the details window, where "LOCO_" (something, which I cannot read because of the overlapping) overlaps with the numbers for the individual vehicles. This can be seen in convoy no. 101 in the Pak128.Britain-Ex demo game.
That is because the symbol is translatable.
For English, for example, add the following line to the tab file and translate the symbol.
Code: [Select]
LOCO_SYM
L

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2716
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Basic couple constraint
« Reply #62 on: May 19, 2019, 01:30:09 PM »
I use the expression "permanent connection" as proposed by ACarlotti.
Due to the length of this thread it is better to repeat what you mean directly without reference to some previous posts. I'm already lost at what is meant by whom as fixed and what by permanent. Maybe it would be better to have option like can_disconnect=anywhere/depot/never, or cost_to_disconnect=0/<some price>/-1 (infinity/never). It might be best to use terms like normal/semi-permanent/permanent for these?

It is treated as fixed because one side is not fixed but the other side does not allow disconnection.
Now you confused me even more. I thought that fixed/permanent coupling is something that is the same on both sides. What you describe seems that it can be decoupled easily, but will leave one part unable to move without the other. That is imho not what fixed/permanent coupling should mean.

At least the "permanent connection" sign serves as an expression of "automatic coupling" or "automatic back to storage" in the depot.
Changing yellow bar to another color does not solve this problem. This is not supported for back to storage. All convoy's already assembled are usually show green bar.
"automatic coupling" - do you mean the effect that if there is only one possible constraint[next] it will be automatically purchased when the front part is purchased? I do not find that as a problem. But If you feel so, then it might be worth having a possibility to switch it off and let player buy all parts individually, even if there is no other choice. What I think is a problem, is that sometimes the constraints are not interpreted correctly, and some vehicle combinations can be built only in "append" mode and not in "insert" mode. But that should be investigated as individual bug reports with exact reproduction case.

Quote
I also think it can give a notice to display the information when implementing the function to display the total of the vehicles combined together when selecting a vehicle in the depot.
That is, the total length and price are displayed when the player hovers over the vehicle having that symbol. So you can check before you purchase.
That would be nice so one can easily estimate the total costs - especially in regard of articulated engines/buses/trams. But sometimes there may be a choice of different tenders for one steam engine (and vice versa) and then it will not work. In any case, you can sell the purchased train for full refund if you do not dispatch it from depot. So this is not so big problem anyway.

I have two suggestions that might help. Firstly, I would change the name to 'permanent connection'. This avoids the word 'coupling', which to me implies that it is possible to uncouple (though not necessarily everywhere).
And secondly, I think a much better example of a 'permanent connection' can be found in ships. In pak128.Britain, it is common for ships to have space for multiple holds - these holds can then potentially provide for a number of different goods types. Since the hold is literally built into the structure of the ship (presumably upon construction), then it would be infeasible to switch holds between different ships (in a much more fundamental way than applies to trains or any other convoy that can bend between vehicles). This need not prevent changing what a ships can carry, but such changes would need to be made by converting (upgrading) one type of hold to another. Furthermore, this would have a meaningful effect on gameplay, unlike an example of a rigid vehicle represented as two vehicles in Simutrans with a unique configuration, where the potential to swap vehicle halves would have no benefits (compared to not swapping halves).

Ah ok, finally I understand. So far I really thought about articulated vehicles, which fundamentally can be decoupled (although in some cases at high cost). Cargo holds (or even a mail hold in passenger car) are a good example of truly inseparable parts. Although I consider cargo holds as a flexible thing. I think that especially old cargo ships were quite universal, and able to carry almost anything, provided it was packed reasonably. So most of them would have wide open cargo space, which could be loaded with piece goods - boxes, sacks, bundles and barrels. So even other simutrans categories "bulk, fluid, long, special" would be able to coexist in the same hold if packed properly. But simutrans does not simulate "packing". Also some rail and road cars are flexible and can easily be used for bulk (coal, stone) or long (wood, steel) goods without any modification. So in this case I think that replacing the holds should be (almost) for free. But in my view rail cars with half passenger and half mail are a good example of truly permanently coupled vehicles (and those exist in pak.CS)

One more example, this articulated locomotive is a permanent connection. They never swap with other same class ones. On the front is the car's serial number 4, but of course on the other side shows also serial number 4.
But that of pak.CS may not be, idk.

For example Czechoslovak articulated class 131 https://cs.wikipedia.org/wiki/Lokomotiva_131 is coupled using the standard hook & screw, plus some special control cables. Thus the parts can be disconnected easily and can move alone, (even have different numbers), but in practice they are never separated. The same is valid for and EMU classes 460/560 https://cs.wikipedia.org/wiki/Elektrick%C3%A1_jednotka_460, which were originally built as 5-car units, but some 20-years later some middle trailers from 460's were transferred to 560's to form 4- and 6-car units respectively. Again the coupling is classic with some extra control cables, and extra compressed air hose for closing doors. (460 and 560 are almost the same, except for voltage: 460 is 3kV DC, 560 is 25kV AC). So these are a border case - can be decoupled anywhere, but in practice they are not.

On the other hand other EMUs (451/452/471) are permanently coupled (but theoretically can be rearranged in factory or service depot). Similar example is swdish DM3 - 3-part articulated loco, which was originally built as twins, and the middle parts ordered and added later. So these are typical examples of those that cannot be decoupled outside depot, but can be decoupled in depot (at some cost).

In many cases the term permanent was also incorrect. This is also expressed as semi-permanent in Japanese.
I like that - permanent and semi-permanent makes it much clearer than using synonyms permanent vs. fixed

Offline Ranran jp

  • *
  • Posts: 483
  • Languages: ja
Re: Basic couple constraint
« Reply #63 on: May 19, 2019, 02:25:38 PM »
It is treated as fixed because one side is not fixed but the other side does not allow disconnection.
Now you confused me even more. I thought that fixed/permanent coupling is something that is the same on both sides. What you describe seems that it can be decoupled easily, but will leave one part unable to move without the other. That is imho not what fixed/permanent coupling should mean.

The semi-permanent is only a function that was originally in the standard that I visualized with the semi-permanent symbol.
(And it happened to be similar to fixed coupling)

When it is in a relationship of A→←B→C,

BC is automatically purchased when you buy A.
B is not purchased automatically when C is purchased in Insert mode.
removing C from ABC's convoy then automatically remove A and B.
Selling A or B will sell all ABC, but selling C will not automatically sell A and B.

This is a standard feature.


Fixed coupling is a parameter specific to reversing order and recombination.
If one of the vehicles is fixed and the other is separable out of the depot it may cause an error.
Because basically fixed is the intermediate end, one intermediate end is left behind and the situation that it can not operate occurs.
So I think they should be considered fixed and inseparable.

EDIT:
I think it depends on how the recombination works.
For example, if a vehicle (such as coach) is added at an intermediate position of the train from storage at a station, I think that it is better to fix only when both sides are fix.
It is probably not a major problem as it is a easy fixable issue.

About "unit":
It often refers to a unit for operating a motor or power unit. Therefore it is connected semi-permanently. I recognized it as EMU/DMU because there are multiple units. (´・ω・`)
« Last Edit: May 19, 2019, 02:58:08 PM by Ranran »

Offline ACarlotti

  • *
  • Posts: 483
Re: Basic couple constraint
« Reply #64 on: May 19, 2019, 03:56:45 PM »
But in my view rail cars with half passenger and half mail are a good example of truly permanently coupled vehicles (and those exist in pak.CS)

While they may be a good real-world example, I dont they're a good example for requiring permanent connections in Simutrans, because I don't think there would be any exploits that might arise from not having them permanently connected.

One issue with implementing permanent connections would be that currently convoys can be separated into individual vehicles in the depot. This would break permanent connections, so we would either have to find some way of storing the permanent connection details after breaking apart the convoy, or prohibit breaking up those vehicles in the depot. The latter then raises the issue of what would happen if we try doing this to convoys that contain multiple such groups of permanently connected vehicles. So it might be reasonable to restict the use of permanent connections to things like ships where in real life we have one vehicle, but in Simutrans we currently need to use multiple vehicles to efficiently provide for a wide variety of cargo carrying configurations.

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Re: Basic couple constraint
« Reply #65 on: May 19, 2019, 05:04:34 PM »
ACarlotti,
The difference between "fixed connection" and "permanent connection" is not that the "permanent connection" symbolizes the concepts of vehicles that are more difficult to separate than others, or a vehicle that have cargo slots like boats in pak britain.
It is basicly only making the distinction between vehicles that autobuy in the depot and those that do not, making the assumption that those vehicles that autobuy have a "stronger" connection than those that doesnt autobuy (but otherwise are having a "fixed connection").

Ranran, I did tell you that the autobuy feature can indeed be disabled, I showed where in the code in this thread.

Quote
I don't think it's necessary to distinguish between real units.
It is neccessary to distinguish between real units! Unless you want the pakset author to have multiple copys of the same first unit because the second unit exists in several variations. That is an unfair assumption to make and very difficult for the author to draw the line where it should be permanent and only fixed.
Therefore every unit has to be its own entity by default.

Quote
There is also a large discrepancy in representing the passenger and mail compartments in the same vehicle as two vehicles. (As ACarlotti points out)
It is sufficient for the meaning of the symbol to have only one coupling partner.
Yes, and the differentiation between "permanent connection" and "fixed connection" does not solve the problem. The mail/passenger/7+different cargo slots in pakbritain will not trigger the "permanent connection" because you can choose any slot to be next to the previous one. You dont choose a ship with a specific configuration, as that would mean 100+ of each ship model displayed in the depot.

Quote
In that way, I think there are some situations where this distinction is useful. And since it doesn't look much different than a fixed couple, it won't be too confusing.
Rather, I think the difference in GUI behavior will continue to cause a confusion if we don't make this distinction.
Since "permanent connection" also has the characteristic of "fixed couple" there is not much difference in the meanings of the two symbols.
Wrong, implying there is a difference, makes the player also think there is a difference, most likely a difference bigger than just the autobuy.

Quote
I don't think so. "Power units" usually do not separate.
There is a description in Japanese here, but unfortunately there is no similar description in the English version.
For example, a plurality of dedicated cables are provided between a motor car equipped with a pantograph and a motor car not equipped with the pantograph, but it is not required between the power unit and another car. And a device on one side controls eight motors. And there's no need to use a normal coupler between them, and they are fixed by bar and bolts together.
NO units in a DMU or EMU usually separate, that is the point of the name "Diesel Multiple Unit" or "Electric Multiple Unit" no matter it being the power unit, the cab units or any other unit. They are a bunch of units fixed together in a DMU or EMU. But given enough effort, all units in a DMU or EMU can separate, just like ACarlotti suggests.

Example of what I meant:
EMU_A
EMU_X
EMU_C_Power
EMU_D_Power
EMU_X
EMU_B


The A-unit and B-unit have cabs on the outside and have to be at the ends. The X-units are motorless units and there can be as many of them as posiible. The C- and D-units are the power units. They have to be next to each other, but can otherwise be anywhere in the train. They are also constrained to be next to each other, so the "permanent connection" is displayed between them and you get a visually pleasing GUI with the "permanent connection" and the "fixed connections"

But, then some of the power units have built in a small pentry to them, raizing the catering level:
EMU_C_Power
EMU_D_Power
EMU_D_Power_(pentry)

That would mess up with the display, giving the C unit a "fixed connection" marker and the D unit "Permanent connection". Adding to that, the power units might exist in even more configurations:
EMU_C_Power
EMU_C_Power_1'st_class
EMU_D_Power
EMU_D_Power_1'st_class
EMU_D_Power_(pentry)

Completely eliminating the "permanent connection" markers due to the player being able to criss cross them.

Quote
In addition, vehicles that are permanent connections often share maintenance information (Upgrades and timing of retirement), and it is worthwhile to be able to read it from picture.
For example, vehicles of different types may be mixed, but the unit vehicles of permanent connection are almost the same class.
On the other hand, the fixed relationship may simply be EMU or DMU, or a vehicle manufactured at a completely different time.
Also wrong. You cannot make that kind of assumptions on behalf of other paksets.


If you have a steam garrat engine consisting of three parts you would have three vehicles showing up in the depot:
Garrat_part_A
Garrat_part_B
Garrat_part_C

Due to their constraints setup A can only be next to B, which in turn can only be next to C.
That would trigger the "Permanent connection" symbol and that feature would work as expected, showing a little stronger connection between these vehicles.

BUT, the Garrat_part_C exists also in another vairation (higher coal load so a higher range) and alot of the garrat engines where equipped with that instead of the original, so then the depot would look like this:
Garrat_part_A
Garrat_part_B
Garrat_part_C_original
Garrat_part_C_enhanced

Now, due to their constraints setup A can still only be next to B and vice versa, hence triggering the "permanent connection" for both vehicles but B must be able to connect to the both C's, so that end will have the "fixed connection" instead. The C variants can only connect to B so that end will still have the "permanent connection".
The result would look a bit weird, especially with the B-C connection where one end is fixed and the other is permanent instead of both just being fixed.

But the manufactorer of the garrat engine has come up with a new middle part as well, so now we have all these parts to toy around with:
Garrat_part_A
Garrat_part_B_original
Garrat_part_B_enhanced
Garrat_part_C_original
Garrat_part_C_enhanced

Now the A part has to be able to connect with both B's, hence only "fixed connection", B front end would still (and as the only connection in the garrat) have the "permanent connection". Both of the B's should be able to connect with both C's and vice versa, so that connection will now only show up as "fixed" for both ends.
This result would also look pretty weird, mostly due to the A-B connection where one is permanent and the other is fixed. But more importantly, it is starting to dissolve the concept of "permanent connection" and if you had fixed connections after the garrat (for whatever reason) then you would not be able to tell the last part of the garrat.

So, if I understand you right Ranran, you would want the entire Garrat to be threated as its own entity, a "single unit", selecting the first vehicle of it would show the property of all the following parts. That would require this amount of vehicles in the depot:

Garrat_part_A_(B_orig_C_orig)
Garrat_part_A_(B_orig_C_enhanced)
Garrat_part_A_(B_enhanced_C_orig)
Garrat_part_A_(B_enhanced_C_enhanced)
Garrat_part_B_original_(C_orig)
Garrat_part_B_original_(C_enhanced)
Garrat_part_B_enhanced_(C_orig)
Garrat_part_B_enhanced_(C_enhanced)
Garrat_part_C_original
Garrat_part_C_enhanced


That is pretty substantial, just to make a small GUI feature work. Can you see that?


Even if the concept of "permanent connection" was to be implemented in the sense that some units are harder to detach in the depot than others, I have serious doubts about it:

The typical example is the Garrat. It is pretty obvious that the engine doesnt work without all three parts. So therefore it would be a good candidate for the "permanent connection" flag.
But then we have the normal tender steam locomotive. It might be less obvious, but for 99% of them, the steam engine needs the tender in order for it to work, otherwise it has no fuel. Therefore it should also have the "permanent connection" flag set.
Then in the world of EMU's you have EMU's that are structurally dependent on the next car on top of "Jacobs boogie's" such as the Swedish X60 or the new Swedish MTR (Note the boogie is between the cars):


Or the Danish S-trains (One car hanging on the next):

No one of the vehicles will work if the neighbors are not there, so therefore such vehicles would also be candidates for the "permanent connection" flag.

Moving on, what about the cars of a regular EMU which have a motor in them, but no power supply? After all, they are the similar cases as the steam engine: An engine with no fuel. Therefore they would also be candidates for the "permanent connection" flag as much as the tender steam engines are.

So when all those vehicles are candidates for the "permanent connection" flag we are only left with self contained powerunits and power-/motorless EMU or DMU cars that is not forming a structural support for its neighbour.

Vehicles which can haul more than one cargo type such as boats and boat holds are also good candidates for the "permanent connection" flag, but their mere existense is a work around to the fact that a vehicle can only haul one cargo type. As Vladki points out, boats of old times (and also modern times due to container transport) are higly flexible, and can carry princippally anything without big structural changes to the boat (save for specific tank boats). Wouldnt that then contradict the concept of "permanent coupling" since the player should be able to easy swap out the cargo holds?

So what would the "fixed connection" versus the "permanent connection" then actually aim to display and inform the player?

As ACarlotti points out, there is not really any way to exploit the system in the first place when omitting the concept of "Permanent connection", it only sets arbitrary GUI displays.
True, if you where to implement costs of rebuilding, say a garrat engine, but that would probably be a much much more substantial change to the code and require new GUI elements to work out, and IMO is not really needed for Simutrans.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2716
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Basic couple constraint
« Reply #66 on: May 19, 2019, 08:22:33 PM »
Hmm, I think I finally understand, but please correct me if I am wrong...

What I was thinking all time about was about coupling that was PHYSICALLY fixed or permanent in some way - i.e. a coupling that cannot be uncoupled easily/anywhere, but only in depot/workshop or never at all. This has currently no effect on the game, but will be important in the planned feature of convoy recombination outside depot.

What Ranran apparently meant was the autobuy/autosell feature that automatically buys the next vehicle if there is exactly one constraint[next] defined. In that case the use of fixed/permanent coupling was very unfortunate and caused much confusion. Because the autobuy/autosell feature may be triggered for vehicles which can be PHYSICALLY decoupled very easilly. Think of a bus with optional trailer. The bus can be running alone, but the trailer can be used only with one specific bus. Thus buying the trailer (in insert mode), will automatically buy the bus too. Removing the bus from the convoy will remove the trailer too. (But not the other way round.) It is also perfectly OK to have the bus go with trailer from A to B, leave the trailer in B and continue to C alone, and pick up the trailer in B on way back to A. This is in no way fixed/permanent coupling, yet the autobuy/autosell feature will trigger at some situations.

So if Ranran (or anyone else) has an issue with autobuy/autosell, it might be:
a) a bug in simutrans (perhaps shared with standard) that the autobuy/autosell is triggered when it should not (or not invoked when it should be)
b) a bug in pakset, where constraints are not defined properly and thus triggering autobuy where it should not (or the other way round)
c) just a feeling that the autobuy feature is not useful - then an option to disable it might help
d) some other GUI issue? e.g. inability to see the power/cost/capacity of the whole sequence that will autobuy at once?
cases a and b should be reported as bugs with specific vehicle combination that does not behave as expected.
I have no idea how to deal with d - as Ves pointed out there may be several options to mix/match, e.g. a steam engine that can be used with several different tenders and vice versa a tender that can be used with different engines. IMHO the only way is to buy them as separate convoys, compare the full specs, and sell (for full refund) those that you do not like.

But please do not use the words fixed/permanent coupling for vehicles that are just constrained in way that triggers automatic purchase of the next unit. It just causes confusion.

Offline ACarlotti

  • *
  • Posts: 483
Re: Basic couple constraint
« Reply #67 on: May 19, 2019, 09:40:04 PM »
But please do not use the words fixed/permanent coupling for vehicles that are just constrained in way that triggers automatic purchase of the next unit. It just causes confusion.

Agreed. Also, I want to clarify the distinction I was trying to make earlier. I'll assume (as is the status quo) that depots/workshops/manufacturers are the same thing in Simutrans. Then we have:
"Permanent connection" - a connection between two simvehicles that cannot sensibly be broken apart once built, even in a depot or workshops. I think this applies mainly to things like ship holds, where any flexibility in changing cargo type would most sensibly (in my opinion) be implemented as 'upgrading' one hold type to another. This would also apply to any vehicles that are coded as multiple simvehicles purely due to constrains on the length of simvehicles or their ability to carry multiple cargo types.
"Fixed coupling" - a connection that cannot be uncoupled outside of the depot in routine operation (i.e. the convoy recombination feature), but can feasibly be broken apart inside the depot.
"Unique coupling/connection" - there is only one possible choice of preceeding/following simvehicle

In cases where there is only one possible successor and (respectively) predecessor simvehicle (which would currently trigger autobuy), then I think the two are approximately equivalent in terms of their effect on gameplay - I can see no reasonable exploit arising from being able to swap around halves of a vehicle that are identical apart from their state of maintenance (as long as maintenance intervals and costs in the upcoming feature are matching/proportionate in the pak set).

However, I think the value of having a 'permanent connection' distinct from a 'fixed coupling' setting would come from allowing flexible design of large vehicles such as ships by building them from multiple simvehicles in a large number of configurations, without allowing subsequent unrealistic changes to the configuration of such ships. There may be a better way to solve this latter problem than the use of a 'permanent connection', and the current model is not without flaws. For example, the maximum number of holds that a ship can contain is effectively hardcoded as 7 (this applies to the Brig and to the East Indiaman in pak128.Britain, for example). The only way (at present) to restrict the number of holds to a smaller number is to set up the next/prev constraints to limit the number of holds (e.g. the Humber Keel always has exactly one mail hold 'following' it). For larger, more flexible, ship designs, we currently require paksets to define holds separately for each possible hold location in a ship, which may be physically realistic but is probably an unnecessary level of detail.

So in conclusion, I think (for now) 'fixed coupling' is a sensible thing to add as soon as it is ready (although it would have no gameplay effect until vehicle recombination is introduced), whereas 'permanent connection' would have some implementation issues and might not be flexible enough in the only situations where it would make a meaningful difference to gameplay. I think we need to discuss more (probably in a new thread) about whether 'permanent connection' is the right solution to ships, or whether a system for allowing flexible allocation of good types to hold space in a single simvehicle is a better way to go. As for 'unique coupling/connection' - I don't think that should be included in the symbols being developed here, as it depends less on the properties of the vehicles and more on what other vehicles exist in the pakset. (Yes, I'm aware that vehicles specify a list of things that they can couple to, but I think that is an artefact of the current design that should be removed, rather than something that should be embedded into the gui for other vehicle properties.)

Offline Ves

  • Devotee
  • *
  • Posts: 1677
  • Languages: EN, SV, DK
Re: Basic couple constraint
« Reply #68 on: May 20, 2019, 11:16:05 AM »
Vladki, your example with the bus and trailer I don't think any of us had considered at all!

I can see two ways for solutions:
1) vehicles without constraint[prev/next]=none (and no fixed couplings) can also be left with the particular end 'bare'.
However, it might backfire with vehicles that have not properly set "fixed_connection"

2) redo all constraints in pak.britain to have constraint[prev/next]=none for all vehicles affected.


Regarding the autobuy, I don't mind it existing, although I would also not mind if it dissapeared.

Skickat från min ONEPLUS A6003 via Tapatalk


Offline Ranran jp

  • *
  • Posts: 483
  • Languages: ja
Re: Basic couple constraint
« Reply #69 on: May 20, 2019, 01:18:58 PM »
Quote
Ranran, I did tell you that the autobuy feature can indeed be disabled, I showed where in the code in this thread.
Yes, I also answered at that time. James also opposed the removal of automatic buy at that time.
I also strongly oppose the proposal. Because I think automatic coupling is a useful feature. I just say that there is room for improvement.
As it was added Simutrans went two steps ahead. On the other hand, it has also some inconvenience. So we took a step back. We went one step ahead in total.
To remove the automatic buy is just one step backwards and back to the beginning.
It will make players feel more inconvenient to erase what they used to be.
For example, player feels it more troublesome to click the connecting tram divided into five parts five times for purchasing it.

Standard has a length display bar that responds to mouse-over in the depot dialog. They made a step forward.
I suppose that we can modify this to display the total number of additional vehicles, the length, and the total cost, and total power.
Then we will cancel one step of backward and go more two steps forward. I hope that.(´・ω・`)


Quote
It is neccessary to distinguish between real units! Unless you want the pakset author to have multiple copys of the same first unit because the second unit exists in several variations. That is an unfair assumption to make and very difficult for the author to draw the line where it should be permanent and only fixed.
Therefore every unit has to be its own entity by default.
What I want to say is that there is no point in distinguishing between the it has only one coupling partner (since pakset does not have multiple options) and the real unit.
This is because the arrangement and connection of the devices are not actually simulated, the pakset author just writes the coupling partner.
That is, you can not know in the game the information on why it has only one connection partner. You can only guess that it will mimic reality to some extent.
So I tried to give a display for automatic buy to a vehicle with only one partner. It is simply for convenience and does not consider deceptive units. I don't think there is a need to lose convenience for things that have not been implemented.
I think that has_only_one_coupling does not cause confusion about the name.

Quote
NO units in a DMU or EMU usually separate
I said POWER UNIT. It(MM'ユニット) is a mainstream Japanese style that is different from what you are talking about. It can not be separated.
However, since it is only one of the fixed forms, the difference is meaningless. Just set one constraint.
It showed the possibility that my thought fixed was different from your thought fixed.


Quote
Wrong, implying there is a difference, makes the player also think there is a difference, most likely a difference bigger than just the autobuy.
I think it is not worthwhile to express the differences that are not implemented in the game.
I am now rethinking the meaning of fixed coupling. I suppose that what I thought of as semi-permanent coupling might be the fixed coupling of Ves.



Quote
But given enough effort, all units in a DMU or EMU can separate
I thought this would be called semi-permanent coupling. However, if this is a fixed coupling, the function seems to be unnecessary at present. (At least until recombination is implemented)


After 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?



Quote
a) a bug in simutrans (perhaps shared with standard) that the autobuy/autosell is triggered when it should not (or not invoked when it should be)
I think the problem with auto sell that due to the ambiguity of the display. And that's what I want to improve.

Quote
When it is in a relationship of A→←B→C,

BC is automatically purchased when you buy A.
B is not purchased automatically when C is purchased in Insert mode.
removing C from ABC's convoy then automatically remove A and B.
Selling A or B will sell all ABC, but selling C will not automatically sell A and B.
When selling the above ABC, the number sold varies depending on which one is selected. However, it is obvious that there is no perfect permanent connection between B and C if there is a distinction between the permanent connection(has_only_one_coupling).

Information visualization is also useful for finding pakset authors' misconfigurations.



I wonder if it would be impossible to take an alternative approach to ship loading. For example, there are various types of containers, but the ratio of load type of cargo is variable. However, the number of containers (volume/space) that can be loaded does not change. (In some cases, the weight may be limited)
« Last Edit: May 20, 2019, 01:37:15 PM by Ranran »