News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

Basic couple constraint

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

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ranran

Hi. Ranran has brought a new patch from Jalápagos again. (´・ω・`)
Yeah, you probably understood the content of the patch from the title.
I have wondered that why constraint[]=any has been limited to next.
The same thing should be applicable for this constraint in the opposite side.
And this will contribute to eliminate unnecessary options from the depot. (For example, the first coach or van.)


This is a demo that gave the freight car constraint[prev][0] = any.
These can not be at the front any longer.  :P




I accidentally got the opportunity to fight makeobj code, so I granted him the ability I had been wanting. (´・ω・`)新アビリティ『前方連結権』よー

I have coded to manage multiple flags with 1 bite. That is, instead of the original constraint[next]=any(bool can_be_at_rear), manage multiple flags. Thus three new parameters were added, but the size does not change.
And I put together fixed_coupling_ requested by Ves here.
All of these are flags related to coupling vehicle, prev or next.
So I named this variable coupling_constraint but I do not know whether this is suitable English or not.  :-[



In code, flags are managed as follows:

enum veh_constraint_t {
CAN_BE_AT_FRONT = 1,
CAN_BE_AT_REAR = 2,
ONLY_BE_AT_FRONT = 4,
ONLY_BE_AT_REAR = 8,
fixed_coupling_prev = 16,
fixed_coupling_next = 32,
permanent_coupling_prev = 64,
permanent_coupling_next = 128
};



(1) CAN_BE_AT_FRONT/ CAN_BE_AT_REAR
These are described in .dat file as follows:

constraint[prev][0]=any
constraint[next][0]=any

prev option is a new addition in this patch.
CAN_BE_AT_ extends the function more than ever. Makeobj determines whether it can be at both end and give it a flag.
This try to prevent that it can be at front or rear when pakset don't have a vehicle written in constraint list.


(2) ONLY_BE_AT_FRONT / ONLY_BE_AT_REAR
Since ONLY_BE_AT_FRONT and ONLY_BE_AT_REAR are determined automatically and flag is set, it is not necessary to set parameters.
This parameter is used, for example, to indicate that the next vehicle will not connect any more vehicles. And of course, outside the depot, it will not connect other vehicles to that part anew.


(3) fixed_coupling_prev / fixed_coupling_next
These are described in .dat file as follows:

fixed_coupling_prev=1
fixed_coupling_next=1


These are parameters that Ves's planning.
There is no meaning as a function at present, but I planning to use this as an extension of GUI.
Determine what kind of vehicle type.


TODO:
I think it is necessary to reconsideration the algorithm to move the brake van when reversing. It is related to the bug which I reported in another thread.
Because the constraints were extended in both sides. Currently it only checks one side.




:idea: Plan:
Although not implemented yet, I plan to improve the following feature:

Indicator bar
- Explicitly indicate that nothing can be connected in front of or behind the vehicle
- Explicitly indicate  that it can be at the front or end
- Explicitly indicate that you can not disconnect outside the depot


For example, red is the side that can not be connected, black is the side that can be the end.
This should make things clear when looking over the whole convoy. However, a good design has not come yet. (´・ω・`)




Repository:
britain-ex vehicle testing ( add constraint[prev][0]=any to railway freight cars and old coaches )
https://github.com/Ranran-the-JuicyPork/simutrans-pak128.britain/tree/extend-coupling-constraint

simutrans extended, and makeobj 60.02
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/basic-constraint-extension

The makeobj for testing this is version 60.02. This includes 60.01 changes.



It will be helpful if you can share your thoughts. Thank you.

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



EDIT1:
I changed the thread title as "basic couple constraint" to make the implementation purpose clearer and to distinguish it from service system constraint and brake system constraints etc.
I don't speak English so I'm not sure if this name makes sense though. (´・ω・`)

EDIT2: ADD: permanent_coupling

Ves

Quote from: Ranran on March 12, 2019, 03:11:18 PM
Hi. Ranran has brought a new patch from Jalápagos again. (´・ω・`)
Yeah, you probably understood the content of the patch from the title.
I have wondered that why constraint[]=any has been limited to next.
The same thing should be applicable for this constraint in the opposite side.
And this will contribute to eliminate unnecessary options from the depot. (For example, the first coach or van.)


This is a demo that gave the freight car constraint[prev][0] = any.
These can not be at the front any longer.  :P



Thank you, I am very happy to see this!

Quote
I accidentally got the opportunity to fight makeobj code, so I granted him the ability I had been wanting. (´・ω・`)新アビリティ『前方連結権』よー

I have coded to manage multiple flags with 1 bite. That is, instead of the original constraint[next]=any(bool can_be_at_rear), manage multiple flags. Thus three new parameters were added, but the size does not change.
And I put together fixed_coupling_ requested by Ves here.
All of these are flags related to coupling vehicle, prev or next.
So I named this variable coupling_constraint but I do not know whether this is suitable English or not.  :-[

In code, flags are managed as follows:

enum veh_constraint_t {
CAN_BE_AT_FRONT = 1,
CAN_BE_AT_REAR = 2,
ONLY_BE_AT_FRONT = 4,
ONLY_BE_AT_REAR = 8,
fixed_coupling_prev = 16,
fixed_coupling_next = 32
};


(1) CAN_BE_AT_FRONT/ CAN_BE_AT_REAR
These are described in .dat file as follows:

constraint[prev][0]=any
constraint[next][0]=any

prev option is a new addition in this patch.
CAN_BE_AT_ extends the function more than ever. Makeobj determines whether it can be at both end and give it a flag.
This try to prevent that it can be at front or rear when pakset don't have a vehicle written in constraint list.

(2) ONLY_BE_AT_FRONT / ONLY_BE_AT_REAR
Since ONLY_BE_AT_FRONT and ONLY_BE_AT_REAR are determined automatically and flag is set, it is not necessary to set parameters.
This parameter is used, for example, to indicate that the next vehicle will not connect any more vehicles. And of course, outside the depot, it will not connect other vehicles to that part anew.

(3) fixed_coupling_prev / fixed_coupling_next
These are described in .dat file as follows:

fixed_coupling_prev=1
fixed_coupling_next=1


These are parameters that Ves's planning.
There is no meaning as a function at present, but I planning to use this as an extension of GUI.
Determine what kind of vehicle type.


I would just like to make clear that I am not planning anything in this regard, it was a mere wish to James that something like this would be implemented and in this way. I think that we should wait for James confirmation to see wether it actually is going to be implemented like this, or if he has another way he wants to do it.

Quote
:idea: Plan:
Although not implemented yet, I plan to improve the following feature:

Indicator bar
- Explicitly indicate that nothing can be connected in front of or behind the vehicle
- Explicitly indicate  that it can be at the front or end
- Explicitly indicate that you can not disconnect outside the depot


For example, red is the side that can not be connected, black is the side that can be the end.
This should make things clear when looking over the whole convoy. However, a good design has not come yet. (´・ω・`)
I do like the idea of an improved design, however I think it is not clear in the picture you show. I think the current design (where the bar is only split in two) is pretty good, as that clearly specify how you may combine the convoy in the depot.
So instead of adding stuf to the ends of that bar, I think you could have another bar directly below it that displays wether it may or may not detach it self outside the depot. It could be white and black (white=can detach, black=can not detach) so each vehicle in the view would have two bars. So if you see a vehicle with a black bar, you know it will always stay connected to the vehicles you put next to it in the depot. Vehicles with a white bar, would likewise be able to completely detach itself outside the depot (of corse following possible other constraints it might have). Front ends of DMU's would have left half white and right half black. If the vehicle can not have anything in front of it (constraint_prev[0]=none) it would display black left half, and likewise for the aft end.

I plan anyway to clarify in the vehicle manager what vehicles precisely a particular vehicle can connect to, and so all constraints would be specified.

jamespetts

This is very interesting, thank you for this work. Some comments below.
Constraint[prev]=any
This is a very good idea, and your demonstration shows how useful that it is. Thank you for this. I will review the code generally in due course.
Coupling constraints
Having user-defined coupling constraints is a good idea, and one that many have wanted for a long time. "Coupling constraints" (plural) or "Coupling constraint" (singular) are indeed good English and are probably the clearest description for what I understand this feature to be.

However, if we are adding coupling constraints, I wonder whether we might add a little more sophistication so that we can simulate a number of real life things that constrain rail vehicles coupling in a way that is efficient for pakset authors to code and easy for players to understand.

For example, a railway carriage might have a screw link coupling and vacuum brakes. A locomotive might have a screw link coupling and air brakes. This locomotive would not be able to couple to the carriage. However, another locomotive with screw link coupling and both air and vaccum brakes would be able to couple to the carriage. It would also be able to couple to the carriage with a screw link coupling and air brakes, but that carriage would not be able to couple to a locomotive that was not equipped with air brakes. Another carriage may have a buckeye coupling and air brakes. A locomotive may have a buckeye coupling and both air and vacuum brakes; it should be able to couple to the carriage with air brakes and a buckeye coupling, but not to either of the carriages with a screw link coupling. The carriage with the air brakes and a buckeye coupling should be able to connect to another carriage with air brakes and a buckeye coupling, but not to a carriage with vacuum brakes and a buckeye coupling, even though the locomotive has vacuum brakes. A carriage with Clerk & Webb chain brakes should be able to couple to other carriages with Clerk & Webb chain brakes and also to a locomotive or carriages with no brakes, or a locomotive with vacuum or air brakes, but not carriages with vacuum or air brakes. A carriage with vacuum brakes, a screw link coupling and steam heating should not be able to connect to a locomotive with vacuum brakes, a screw link coupling and electric heating - and so forth.
I wonder whether a system similar to way constraints (but perhaps with a larger integer to store the data) might work here. It is something of this order that  have been meaning to implement for a while.

If that is not something that you can achieve within a reasonable time, then what you have coded so far is no doubt an advance on the present situation - but I will be wanting to add the more abstract type of constraints one day myself, so we may have to think about how to make this system compatible with (and not confusing to players or pakset authors regarding) the system that you have coded here.
Brake van algorithm
I have not yet had a chance to look into the reported issues with this. However, if you are re-coding this to take account of the more sophisticated constraints, that would be very helpful.
Indicator bar
These are very interesting ideas - it is certainly a good thing to have a graphical implementation of these matters. Quite how best to represent them to players is not entirely straightforward.
Currently, the system is fairly easy for a player to infer: green is good, and if everything is green, the train will be able to run. If we are to have additional graphical representations, these need to be as clear as this and not make the existing indications any less clear. Small bars at the end I am not sure make things as clear as they might be: the bars are very short, so it is difficult to see them clearly, and it is not clear how these relate to the functions of the larger part of the bars.

Ves's idea of multiple bars is one possibility; but I wonder whether that might also be confusing, since, with multiple bars, it is no longer possible for players to infer just by looking at the GUI what the bars mean, at least approximately. I wonder whether some sort of symbol might perhaps be better? Although I am not entirely sure where it would go.
This might be a place where it is worth experimenting with a few different designs (mocked up initially, perhaps, to avoid coding things that end up not being used) and getting feedback from several players as to which is the clearest.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

prissi

I think you can have this easier. Here is a patch for standard, that enables "any" as well.

Ranran

Quote from: prissi on March 17, 2019, 01:36:53 PMI think you can have this easier. Here is a patch for standard, that enables "any" as well.
I think that is a feature that many Japanese players have been waiting for also in the standard.
It is a versatile option.  ;)

jamespetts

Quote from: prissi on March 17, 2019, 01:36:53 PM
I think you can have this easier. Here is a patch for standard, that enables "any" as well.

Interesting. If this is to go into Standard, it would be better for the code in Extended not to diverge from that. The other features that I describe above would still be worthwhile, but it would be better for them to be implemented in a way compatible with what is to be the new Standard feature.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

prissi

My code just adds a dummy vehicle "any" to the xref, which is then tested for leading or not. (Like NONE is equal to 0 pointer.) I still have to test it, but then it will go into standard (and it require not even a change of makeobj version, so it would work immediately).

prissi

As expected the code there did not work as intended. Here is a working version, just add in makeobj constrait[prev][0]=any just like any other name. You could also have the same with next. Works with any workobj version.

Ranran

@James and Ves, Thank you for your detailed thoughts.

James, you seem to misunderstand what I tried to implement. And I apologize that my explanation was not enough.
What I aimed at this patch is a very simple and loose constraint. It is simple and clear for players to understand.
And this is just an extension of constraint[prev/next] = any/none.
So I do not think that it will create complexity when editing vehicle dat file.
This patch is to improve the GUI significantly, without much modification to the system.

The purpose is to clarify the composition of convoy and make it easy for players to understand it.
And this will ease composition and reconnection.
I believe that it will make full use of that ability, especially in recombination systems.




This is an example of a picture that is often used to represent the train configuration. Is this common for train geeks outside Japan? I don't know.
Think of a pantograph as a vehicle with a motor. (This is for your imagination and has nothing to do with this implementation.)


Anyway, from this image you should be able to get some information about the train configuration.

For example, the train B has a 4 + 4 configuration, and it will be possible to split off on the way to different destinations. But train C will not be able to do that.
Train D will be able to dump the behind three cars on the way. The isolate three dumped cars will be able to attach another locomotive in front and go to another destination but it may cause an error when returning.
Train E is an image of a freight train. Train E will be able to add and drop vehicles (such as wagons) in the middle position.





I implemented one function so please watch the demo. (´・ω・`)刮目して?



Pay attention to the shape of the color bar.  ;)

You can see that this EMU is a 2 + 4 configuration.



This is only a slight extension of the existing system, so I don't think it will inhibit the addition of the strict constraint feature you mentioned.
If you understand this and think that the word Coupling constraints doesn't fit, suggest another word. I'm not an English speaker, so I think I can not select the best word.


fixed_coupling_:
I think this parameter is useful. This clarifies the distinction between A, B, C vs D, E.

QuoteSo instead of adding stuf to the ends of that bar, I think you could have another bar directly below it that displays wether it may or may not detach it self outside the depot.

How about this one? This will clarify the DMU and EMU.
Such a line will not be displayed in the freight train. It can be disassembled outside the depot.


Quote from: jamespetts on March 17, 2019, 10:01:08 PMIf this is to go into Standard, it would be better for the code in Extended not to diverge from that.
Prissi implemented it differently than the existing Extended system. In current Extended makeobj writes bool can_be_at_rear to the vehicle pak, but prissi's do not.
This makes sense for a standard that prefers a simple implementation but it is not extensible. That's because it specializes in determining whether coupling is possible.
So it won't work for the feature which I'm trying to add.

Since extended's bool can_be_at_rear is highly available, I extended it uint8 and renamed and reused it.
That is, makeobj has a flag in the form of a vehicle. By writing necessary data to pak file beforehand, unnecessary processing is omitted.
Again, this is just an extension of the existing system. I just reused the unused area.
Therefore I don't think it's a good idea to go backward and remove bool can_be_at_rear and align it with the standard's code.


On the one hand, I know that many Japanese player are craving it for the standard. It is a great pleasure to have it implemented in the standard.
Many thanks to Prissi.  :)

Ves

Ranran, I must say that I find your idea with the shape of the bar really clever, but I do not think that it is enough, sadly. I did not notice the shape at all until I read that I had to look for it. And even then, I have to stare exactly on the bar in order to determine its shape, and cannot look at multiple vehicles at once to determine that information. I even have problem looking at one end of the bar, and determine the shape of the other end, forcing me to look two different places for each vehicle I want to evaluate. The shapes would have to be much bigger, but that would then ruin the elegantnes of your approach.

I still believe that displaying a second bar is the best way to do it. I came to think that you could make a button that toggles the second bar on and off. The button would be called "show fixed couplings", and when pressed. a new set of bars appear in white and black dependent on wether the couplings at that end are fixed or not.

Let me explain why I think that is a better way:
When you build a convoy in the depot, you are presented with ALOT of information. You have the top section where the lines are selected, you have the currently assembled convoy, along with its green/yellow/red color bars, you have the text field below the convoy where some details about the convoy is presented, and then some buttons that determines what to do with the convoy. Then you have a tab system and then the actual vehicle selection field (which might be very huge indeed), along with its green/yellow/red bars and then a vehicle details textfield at the bottom. All of which are presented at once.
In order to build a convoy, the player wants to have the best suitable vehicles for the particular convoy he has to build, and will therefore spend most of the time starring in the lowest textfield for details about the vehicles. Meanwhile, the player can quickly hover the mouse over the next available vehicle, since he can, by just a brief look on the vehicle image, determine wether that vehicle can be used. There are simply no other information in the vehicle selection field than wether the vehicle can be used as the next (and last) vehicle, and the picture of the vehicle. Both informations are very easily read and no need for starring (true, some vehicles can indeed be dificult to distinguish from other vehicles, and the bars also shows colors for upgrade and obsolete, but that is another story).

Your approach with detailing the existing bar would force the player to also stare in the vehicle field in order to determine wether it has permanent coupling or not. Granted, the information might be rather obvious, mostly given that you already know what you are building, hence there might be no need to amplify it. However, a good use for this feature could be to easily identify "heads" and "tails" for DMU's, something that I am afriaid I practically find impossible in your moving picture, since I would have to stare and remember each end of every bar, and then it would be just as "easy" to just look at the actual graphics of the vehicle.

Instead I believe it should be associated with new set of colors not used elsewhere, and displayed as a new bar with the same (or perhaps only slightly less) amplitude as the existing "availability" bar. Combined with the possibility to turn the feature on and off, the player can turn it off when building "normal" trains or other types of vehicles.

The good thing with this approach is that it is very flexible and expandedable: Instead of having a toggle button, have a combobox that the player can choose between different "display modes", for instance wether a vehicle can be first in a convoy or last in a convoy, or wether it has any constraints at any end. If James some time in the future decides to implement new constraint types (brakes, couplings, heatings etc), those could also be displayed that way.

Ranran

Visibility issues:

Yes, I knew about the issue of visibility.
Please check the image which enlarged the hight of the bar by 1 px.




I thought that the span between bars might be too narrow as one of the causes that make it hard to see its shape.
So, I scraped both sides of the bar by 1 px.




Another option is to make the corners sharper.






Quoteit is no longer possible for players to infer just by looking at the GUI what the bars mean,
I thought that the design which imaged the "coupler" from this point is more easy for the player to understand. The coupler is at the end.
In fact, such designs are often used. But it may be difficult to express in such small pixel.
https://blog-001.west.edge.storage-yahoo.jp/res/blog-c9-c0/toki_lucario/folder/1261455/89/39942789/img_3_m?1434868200
https://blog-001.west.edge.storage-yahoo.jp/res/blog-30-72/amenity221/folder/1283488/26/50131826/img_19?1257233030
http://rail.hobidas.com/blog/natori09/archives/metoro100005.jpg

On the other hand, in the design used to express train specifications in reality, the under box may indicate under floor equipment, and the color of the wheel may indicate it has power or not.

In the case of a model, it is often represented by a bar rather than a wheel. Because the model does not have a motor on the bogie.
And I think that the existence of power is one useful information. In EMU (in Japan?), the ratio of powered and unpowered car is very important when assembling modern trains. It is called MT ratio.
And I believe the 2nd under bar thinks that many people associate "power" if there is no explanation about it. But that may be Japanese sensibility.

These designs vary depending on the purpose, but whether they have a power or can be disconnected outside the depot are both useful information in (future) extended.

One reason I think the second bar is not a good idea is that the current bar is part of the "panel" and has this structure.




QuoteIf James some time in the future decides to implement new constraint types (brakes, couplings, heatings etc), those could also be displayed that way.
IMO, I don't think it should be intertwined with that (brakes, heatings etc) idea.
Because it does not seem to consider only the front and back connection.
It is a system constraint rather than a coupling constraint. (Brake system, heating system, etc.)
It need to check the whole convoy's vehicle. In other words, they can not be the same because they are different principles.
For example, to operate the steam heater, the steam generator needs to be somewhere in the train and connected to it.
The connection should not be interrupted on the way. But it does not matter if it is in front or behind, but one side is enough.
The current coupling system can not make such a decision. Whether the coupling is possible will be judged independently for front and back. And it is very troublesome to express this in the above diagram. This should not be summarized in the same figure.

This picture is drawn as an image of steam heating, but shows that they may be different systems.

That system is similar to the supply and demand and connection of electricity (on the map).
The supplier may be in vehicles that are far apart. There may be vehicles on the way that do not require it, but there is no problem if the cable or pipe is connected.
The brake is the same principle. It would not make sense to have a machine to control and make compressed air. It is not always at the front.
And sometimes it's very complicated because it uses multiple systems and is backward compatible. Perhaps James knows more about them.
I do not think that I can express it in a small figure.

In addition, heating is not a driving system but a service system. It is comfort that is closely related. That's why it shouldn't be together.

On the toggle of the bar
I think the system is worthwhile when complex systems such as steam heating and brake air supply are introduced.

I am not opposed to incorporating these systems, but questioning them as treating the same thing. ???

Should I decide not to include the topic of "detach outside of the depot" in order to move forward step by step?

Thank you for your attention.

Vladki

#11
I like the first image, corners are clear, spacing is fine. But I do not get the system you described a few posts earlier (abcde). It must be simplified. E. G. No corner = fixed coupling (emu/dmu), slanted corner = normal coupling (chain & screw)
I. E. There should be no chance to connect slanted with straight corner like in d and e config.

Also topic diverged away from its title (constraint prev=any)

To heating and other systems (brakes, doors...) this was already discussed many times with different suggestions (e. g. Some provides, requires, pass through options). What is important is that many vehicles were refitted during their lifetime from one system to another (steam heating to electric), there are adapters for different couplings (sharfenberg to chain and screw), and many are not strictly required, just affect comfort (heating in summer) or turnaround time (push pull equipment only on one end of train) that brings infinite complexity.

For starters I think generic groups would be fine. Like pendolino680 group where all vehicles of pendolino class 680 will be members and you could combine them any way you like. And a new car (imagine a restaurant or mail) would need just to be members of that group and no change of old members would be needed. This would greatly help with late 18th century vehicles where the list of constraints is enormous and often inconsistent.

Ranran

Quote from: Vladki on March 23, 2019, 07:53:48 AMBut I do not get the system you described a few posts earlier (abcde).
The shape simply indicates whether that side can be at the front or rear.


B:


C:


D':

I could not make D's example well. (´・ω・`)
D is an example of a combination of a locomotive and coaches. Coaches are often rearranged as needed, and they are highly variable.
I have not edited these dat. Also I do not know in detail about these vehicles.
There is a possibility that these settings do not match the new system.
In the example of Japan's high growth period, there were many double-ended coaches.




E:


QuoteI. E. There should be no chance to connect slanted with straight corner like in d and e config.
I don't think so. Check the example of (E).
The wagon can not be at the end and needs a brake van.

QuoteAlso topic diverged away from its title (constraint prev=any)
Yes, I know. What I am aiming for in this thread is simple and not as complicated as those.

QuoteFor starters I think generic groups would be fine.
I like this idea. :D

Vladki

Oh so... I thought the slanted or straight end had to show if the coupling is fixed or not. But what you say is whether the train can end there. I don't see any reason to show it. When buying the train the green/yellow colors already do that.

Ranran

Quoteif the coupling is fixed or not.
What kind of case do you say "fixed"?
Is the vehicle having only one binding partner? (For example, when one car is selected, the second car is selected automatically.)
Or unique partners specified that does not contain "none", and not constraint=any?
like

constraint[next][0]=coach01
constraint[next][1]=coach02

Or another new feature - the vehicle can't separate outside the depot?


QuoteI don't see any reason to show it. When buying the train the green/yellow colors already do that.

(1) Please imagine rearrenging a convoy that has already been assembled.

You can see at a glance that removing car # 2, # 3 and car # 4 is fine.


(2) Is car # 5 the right choice? If pakset correctly simulates the economy, this choice may indicate inefficiency.


(3) However, it would be useful to be able to figure out how separable when the recombination system is implemented.
That is, it may not be a waste that coach # 5 is there.

(4) You may be able to identify the vehicle from the shape of the bar.
Most of the coaches look the same to me, so I have no idea what type they are for example when selling. (´・ω・`)

Vladki

- Or another new feature - the vehicle can't separate outside the depot?

Yes, i though that this is what you wanted to show.

Ranran

Ah, okey.
Quote from: Ranran on March 21, 2019, 09:11:55 AM

How about this one? This will clarify the DMU and EMU.
Such a line will not be displayed in the freight train. It can be disassembled outside the depot.
One of the drafts to express it is this image I previously posted.


widen space ver.:
The left is 2px height and the right is 1px height


It will need to adjust the width of the bar if you want to display this in the lower panel.


Ves's proposal is to make another bar.

Ves

I too was under the impression that we where talking about wether vehicles where permanently attached to each other or not, that is what I have been talking about all the time.
Although the bar is more easy to read now while it is bigger (thank you), it is still a bit hard skim through the vehicle field to see.. But with the other meaning wether it can be first (and/or last) in the convoy, I must say that I find the shape of the bar to be quite confusing:

The tilted end of the bar looks like the front of a high speed EMU, like a TGV-train running in france. When seeing such an end of the bar, it suggests that there is a drivers cab there, hinting that that end might be put at the front of the train. That is certainly NOT true for a bunch of the vehicles appearing in your screenshoot (for instance the brake van). I do not think it is necessary to tell the player this way that a particular vehicle can be at the end of a convoy, that is rather obvious by other means (partly when assembling the convoy).
Instead, what I could agree to use the tilted ends for are on actual drivers cabs (defined with "can_lead_from_rear=1"). Those can be very difficult to spot by looking at the graphics (since the cab usually faces away from the player), and it would feel much more intuitive, since the player would know "it has a tilting end, that part can lead the convoy". Locomotives with cabs in both ends would have tilted both ends, The bars of DMU's would always start with a tilt and end with a tilt, and it would be pretty easy to identify the number of DMU's within the convoy.


Quote

It will need to adjust the width of the bar if you want to display this in the lower panel.
I must say that I find that a really clever idea, Ranran!

Quote
Ves's proposal is to make another bar.
I still think adding another bar is a good idea. Combined with a combobox, it can show all kinds of information. You wrote earlier that stuf like constraint types, electric/steam heating etc is something else, but I beg to differ. Select "heating" in the combobox, new bars with different colors will show up under each vehicle. Yes, the color will be the same at both ends, but you will immediately be able to identify which vehicles uses steam as heating as they will be, say yellow, all electrically heated will show up as, say orange. Same if you select "coupling", then all screwcouplings will show up with, say green, all "TGV-permanent-couplings-between-cars" shows up as yellow. I know that those are features that are not incorporated, and might never be either, but I believe there are other informations that exists that could benefit from this, for instance cargo types, or highest passenger class, or catering level. Which ends are permanently coupled could be showed this way too. Or wether a particular end of a vehicle can be at the end of a convoy ;)
It would basicly be a tool to group vehicles by color in the vehicle field by different parameters.

QuoteMost of the coaches look the same to me, so I have no idea what type they are for example when selling.
This I too find very true, hence why I have such strong feelings about how this is done so we get the most intuitive system for all players!  :)

Vladki

Yes I also think that the slanted bar should be used for drivers cab, ie can lead from rear

prissi

Why not using the half yellow half green bar of standard which means it requires another trailing/leading vehicle?

jamespetts

This is quite a complex discussion.

First of all, I understand that this is a separate thing from the more abstract coupling constraints discussed above - the title was somewhat misleading. As long as this can be implemented in a way that does not make it any harder or less efficient to implement more general coupling constraints, this is a worthwhile advance.
Secondly, whilst it is unfortunate that we cannot converge with Standard, I understand the reason given for this, and it is better to have this feature in a way that works well with the Extended codebase.
The controversial issue seems to be the GUI. There is much to be said for using the slanted end motif as a way of explaining to users what vehicles can be where, and, at least with the latest version, I can see this clearly, but there is a possible problem in that, to me, the slanted end would indicate that the vehicle can be driven from that end, rather than that it can simply be at the back. Whether a vehicle can be at the front of a convoy is a relevant and meaningful thing in Simutrans-Extended, and there is a can_drive_from_rear parameter, so if we are using the slanted ends, they should be for this purpose.

To symbolise a vehicle's inability to be placed at the rear of a convoy, I suggest a different motif: a jagged edge on the right hand side, and the bar being slightly shorter on the right hand side. This should convey clearly to a user that this vehicle is not a complete end and needs a different vehicle at the end to make up a complete train. However, is this information not in any event conveyed by the yellow half bar? I suppose that using the slightly shorter bar with a jagged edge would make it clearer to users what the yellow means.

As to the fixed formation indications, I think that these lower bars are a bit small to see clearly or look neat. What I suggest is to have this inter-linking graphic half the height of and in the same colour as the bar to either side of it. As to the algorithm for this, do I understand correctly that this is shown when either vehicle is the only type of vehicle to which the other may be coupled? If not, you will need to explain the significance of this more clearly, as I am not sure that this makes clear what this means. (If we are having a new system when the convoy re-assembly feature is introduced where vehicles cannot separate outside the depot, as may well be worthwhile, this display is probably more useful for this purpose).
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

ACarlotti

It's worth noting that we don't yet have a good system for handling constraints regarding vehicles that are reversed (e.g. an EMU vehicle with a driving cab can be at either end of a train, but only if the cab is facing outwards). This is probably something that needs discussing separately, but I think deciding on an appropriate GUI needs to take into account that vehicles can be reversed relative to other vehicles in the convoy (including in future as part of convoy recombination).

Ranran

#22
Thank you for your feedbacks.

This is a demo of last week version. (for fixed coupling)




I added a decision of permanent coupling. This means having only one fixed partner.
This also is automatically determined by makeobj, so there is no need to set new parameters in dat file.
Naturally, it can not be detached outside the depot, so it will automatically be included in fixed coupling.

In the demo image, fixed coupling is represented by 1px height line, permanent coupling is represented by 2px height line.




Symbolic design:

The mockup I'm currently thinking of is something like this:

B:


C:


D':


E1:


E2:



What kind of meaning do you imagine at first glance? Perhaps that's important.



(I'm sorry to summarize my reply here)

Please note the following points:
- This is not only used for TRAINS and this is just an "abstraction".
- It's not just for assembling in the depot. When running, selling, rearranging, that is, all when looking at the information of convoy. I think this display can also be used for convoy information (and convoy detail).
- Imagine convoy being reversed and reordered. Then are there any contradictions?
- pak (dat) does not have data of whether or not there is a driver's cab, so there is no way to distinguish it. You need to be aware that any locomotive has can_lead_from_rear=0. Check the example of E2.

EDIT1:
Quote
What I suggest is to have this inter-linking graphic half the height of and in the same colour as the bar to either side of it.
In the case of such a figure, I think it is difficult to distinguish between freight wagons and intermediate EMU/DMU car which can not be detached outside the depot.
And especially yellow is very difficult to recognize the shape.

EDIT2:
And as in example B, even though one vehicle has only one hand, its partner may have many hands.
Permanent coupling is not always mutual love.  :P


name=vehicle_A
constraint[next][0]=vehicle_B
----
name=vehicle_B
constraint[prev][0]=vehicle_A
constraint[prev][1]=vehicle_C
constraint[prev][2]=vehicle_D

But tied A does not release B ::'(

Ves

QuoteIn the demo image, fixed coupling is represented by 1px height line, permanent coupling is represented by 2px height line.
What is the difference between fixed coupling and permanent coupling, that should be the same thing?

QuoteSymbolic design:
The mockup I'm currently thinking of is something like this:
What kind of meaning do you imagine at first glance? Perhaps that's important.
B - I have a hard time telling the difference between the pointy ends and the ends with the grey middle bar, especially when you have two sizes of grey middle bars.
C - Looks neat and appears to be a convoy that is permanently attached, and can drive in both directions.
D - Looks also pretty good. It is quite clear that the locomotive and tender is one "unit", and it can drive only one direction (although I actually dont know what the slanted bar after the tender means, it just looks like a spoiler). The rack of cars looks pretty good too, since it starts with the flat end and ends with a flat end. Learning what the symbolic means, it looks like you can detach the last car without problems, as well as you can detach the locomotive and put it in the other end of the train (after turning it around).
E1 - Same as with D, looks pretty good.
E2 - Same as with E1 but it is confusing why the ends are not tilted on either ends like in the other examples.

I liked better when it is a tilted end instead of a pointy end. It looks more like the front of a vehicle, and you get the possibility to tilt it the other way if there ever arrizes a need for that.
The permanent attached symbol, however, I think fits fine in the middle, so as to avoid confusion with the tilted end. Although James whished for it to be in the color of the bar, I found it pretty good in the color you showed in your last screenshoots.
Two sizes of permanent couplings does not look good, and I dont understand why you would need it. I have a suspicion that it is for when two vehicles are "hardcoded" together by the datfiles, but that is not a good idea in my opinion, since you dont know how the pakset author thought when (s)he created the pakset. I think it is fine that you threat those just as "normal" fixed couplings if that is not already specified.
But it is a problem I think with the locomotive in E2. The sole purpose of the increased symbolic around the status bar is to increase visibility, but having the locomotives display with flat ends is working very much against that. I didnt realize that there actually is no way of telling wether a locomotive is double headed, singleheaded, or has any cabs at all. Yes, perhaps some of the constraint logics could be used, but it would most probably be a bit flawed.

Quote from: ACarlotti on March 28, 2019, 08:06:12 AM
It's worth noting that we don't yet have a good system for handling constraints regarding vehicles that are reversed (e.g. an EMU vehicle with a driving cab can be at either end of a train, but only if the cab is facing outwards). This is probably something that needs discussing separately, but I think deciding on an appropriate GUI needs to take into account that vehicles can be reversed relative to other vehicles in the convoy (including in future as part of convoy recombination).

That makes me wonder wether we could have even more parameters to the datfiles (yay! ;D ).
Just mentioning "drivers_cab_front" and "drivers_cab_rear"...

edit:
Quote- Imagine convoy being reversed and reordered. Then are there any contradictions?
Might be, however that is actually more of a pakset problem than you patch. It just ilumminates the problem:
In example D, you have cars with one flat end and one jaggered end. The jaggered ends impose that those particular ends needs to be inwards towards the other cars with jaggered ends, when it appears to be an otherwise symmetrical car. But as stated, that is most likely due to how the constraints are designed in pakbritain.

Ranran

Thank you for feedback. I resumed work on this patch.

Review:
The new design shows the existing concept of extended - the behavior of reversing, in the shape of the car end. That is, bidirectional and can_lead_from_rear. The difference between locomotives that use turn tables, locomotives that do not, and EMU / DMU.
Currently, that information is hidden in the game. However, it can be difficult for anyone unfamiliar with the train (I also do not know any British trains at all), as the player can only predict until it actually reversing. For example, a push-pull steam locomotive in demo.


QuoteWhat is the difference between fixed coupling and permanent coupling, that should be the same thing?
QuoteTwo sizes of permanent couplings does not look good, and I dont understand why you would need it.
Oh sorry, my expression was incorrect, fixed coupling is fixed coupling outside the depot:-[
permanent coupling has a stronger connection than fixed coupling outside the depot. The next vehicle will be forcibly connected in the depot.
This is a useful feature, on the other hand, IMO, not announcing it in advance is one of simutrans's unfriendly designs.


QuoteB - I have a hard time telling the difference between the pointy ends and the ends with the grey middle bar, especially when you have two sizes of grey middle bars.
It is not gray but black with transparency. I tried multiple transparencies and the image happened to be pale.
It fortunately made it clear that there was a drawing bug. It also shows that using the same color as the bar also produces shape ambiguity.
I avoided pure black because I think it is too noticeable. I tried to distinguish by thickness to avoid it. But the result was not good, I see. (´・ω・`)


I made some drafts of fixed coupling design.



1) Change translucent black to pure black.
2) Set the position down and make the permanent coupling height 2px.
3) Change from pure black to dark gray in (2)
4) Change fixed outside depot to dark gray in (2)



5) Change permanent coupling to pure black, fixed outside depot to dark gray



6) T-shaped permanently connected side to indicate that something is forcibly connected. fixed out side the depot is shown by a simple line.





Luckily, I succeeded in solving the transparency bug in the vehicle panel. :D It has expanded the design possibilities of the bar.

Take a look at the new demo!  ;)


Note: Deterioration of the color by .gif conversion is seen in some places (´・ω・`)

Unpowered vehicles made the center translucent.


Steam locomotive(example of bidirectional=0):

Think of the tender locomotive as a combined arrow.
It means that tender's back side always backwards, because it is reversed while sticking to the locomotive when reversing.





QuoteBut it is a problem I think with the locomotive in E2. The sole purpose of the increased symbolic around the status bar is to increase visibility, but having the locomotives display with flat ends is working very much against that.
I rounded the side that could be the end of the bidirectional attribute. This is just judged by bidirectional, the locomotive and brake van are the same shape.
On the other hand, the distinction between the powered vehicle and the unpowered vehicle can be made, so the difference between the locomotive and brake van is easier to understand.


QuoteI didnt realize that there actually is no way of telling wether a locomotive is double headed, singleheaded, or has any cabs at all.
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
Unfortunately there are many locomotives of this type in Japan. (´・ω・`)
It will need to make the reorder code in reverse compatible with this.
They all have power, but they may not have power. James mentions Garratt in the code.
In the Japanese example there is a tender locomotive that behaves like bidirectional=1, some diesel locomotives which has single cab require a turntable.
The locomotive must also consider that it can be pushed. There are brake tenders in the UK.
https://hiveminer.com/Tags/brake%2Ctender



QuoteThat makes me wonder wether we could have even more parameters to the datfiles (yay! ;D ).
Just mentioning "drivers_cab_front" and "drivers_cab_rear"...
I think that extra parameters should not be added if possible.
IMHO, I think it's not worth doing it, because I think that the current "can be at front" is functioning enough. I do not understand what the benefits of doing it compared to current constraints system.
If anyone change the code so that convoy can not drive unless the head is cab and add that parameter to each vehicle's dat, I do not think that we will be able to get the one that is worth the effort. (And maybe it's hard to handle some special cases correctly)
I am not editing dat files so much in the demo of this patch.
I only added constraint[prev] = any to the trailer which has constraint[prev]=any, and added fixed_coupling to a few EMUs for testing.
(fixed_coupling is not necessary until the recombination system is implemented)

However, on the other hand, it is also true that the present reorder code is incomplete, so it may be necessary to consider what kind of irregularity occurs in reorder the convoy under the recombination and what parameters are required.




About MT ratio:

I think it is useful to see the MT ratio at a glance.
For example, it can be seen at a glance that the convoy (4 cars) in the front has MT ratio of 2: 2, while the convoy in the back (4 cars) has MT ratio of 1: 3.
And in many cases the powered vehicles are expensive and the trailers are cheap.




I want to distinguish between what can be end and what can only be end, but I have not come up with a good idea about it. (´・ω・`)
This will reveal the following:
- Possibility to connect another convoy
- The possibility that the next available vehicle can connect another vehicle when you try to select

jamespetts

This is very interesting: thank you very much for this. I do like:

(1) the use of different shapes to represent different coupling capabilities;
(2) the use of bridging graphics to represent (semi-) permanent couplings; and
(3) the use of translucency to represent unpowered units.

These things are most helpful and represent a definite enhancement. It is definitely useful to see the motor: trailer ratio when assembling multiple units.

One thing that I am not so fond of is the use of 1px height lines: these are hard to see, I think, and also look untidy. Can we modify these to thicker lines (and modify the thicker ones to even thicker lines)? I think that the graphics would be easier to understand and a lot neater.

As to the separate topic of the reversibility of certain types of coupled locomotives common in Japan, what would be very helpful is to implement these in a pakset somewhere (perhaps Pak.256?) so that I have some worked examples to use for testing. It should not be difficult in principle to add the necessary algorithms to deal with these common types of vehicles, but creating the test vehicles (and then removing them again afterwards) would take almost as long as doing the actual algorithm work, and, since these will be needed for a Japanese pakset in any event, it seems to me sensible to await at least one example of these before modifying the code.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Ves

QuoteOh sorry, my expression was incorrect, fixed coupling is fixed coupling outside the depot.  :-[
permanent coupling has a stronger connection than fixed coupling outside the depot. The next vehicle will be forcibly connected in the depot.
This is a useful feature, on the other hand, IMO, not announcing it in advance is one of simutrans's unfriendly designs.
Ah, I see and also partly agree! But I am not fond of the solution to the issue, due to it being confusing:
Say you have two steam engines and three tenders, one steam engine can only couple to one of the tenders (ie the "stronger" connection), and the other steam engine can connect to the two other tenders, while all three tenders can connect to anything. If I understand your algorithm correctly, one steam engine will get a thick line and the other engine will get a thin line (if fixed_coupling_next is specified) while the tenders would all get thin lines (fixed_coupling_prev is specified).
In my opinion, it is too much information, partly because it is only kind of usefull when actually creating the convoy in the depot, and secondly since those marks will live with the display of the vehicles all along its life on the map, cluttering the otherwise clean design you have made.
In the depot it might create confusion, since neither of the engines will anyway be able to detach from their tenders outside the depot. It might led players to believe that thick lines only goes with thick lines and vice versa (which is not true, as shown in your screenshoot) or that one steam engine has one kind of connection while the other has another kind of connection and so forth.
Add to that that it might be pretty random which vehicles has only one fixed partner and which vehicles has more fixed partners and you will most probably end up with alot of players that never get around to learn what the thicknes of the lines actually means.

Besides, information about wether a vehicle can make fixed connections to multiple vehicles or only one inside the depot will anyway not tell you what specific vehicle that might be, or wether that vehicle is then hard constrained to ANOTHER vehicle and so on.

I agree that it can be quite disturbing in the depot when pressing one vehicle, then a complete set of vehicles automatically are bought due to their constraints. I think, however, that the better solution would be to disable that feature, so the player will have to press every vehicle (s)he whishes to buy. In the case of the hardcoded one to one constraints, the player is presented with that sole vehicle and buying that will reveal the following vehicle available for purchase.



I like the idea with transparency in the bars, that works great with powered/unpowered vehicles!
It appears though, that it can be a bit difficult to spot the difference in the vehicle selection field, perhaps increase the transparency for easier identification?

QuoteI want to distinguish between what can be end and what can only be end, but I have not come up with a good idea about it.
There are only so much one can do with a bar. Perhaps some new symbols could be used in conjunction, for instance a "two tail lights" -symbol for vehicles that can only be at rear?


Ranran

#27
QuoteCan we modify these to thicker lines (and modify the thicker ones to even thicker lines)? I think that the graphics would be easier to understand and a lot neater.
Is this something like these?

- Base bar height: 6px, coupler height: 2px

Even px height do not have a sharp nose.

- Base bar height: 7px, coupler height: 3px


Which is the better? or another?




I must apologize that I did not clarify that 1) - 4) of the reference image of my last post was a failure example. (´・ω・`)
The demo animation gif of my last post is made by discarding those drafts.

Quoteone steam engine will get a thick line and the other engine will get a thin line
Quotewhat the thicknes of the lines actually means.
There is no difference in line thickness because I changed the display of permanent coupling to the T end.
Permanent coupling is automatically incorporated into fixed coupling, but the meaning of black horizontal bars is practically the same. And now it looks the same.


Quoteit is too much information
I do not think so. This is a very small amount of information only to check "the black lines are connected or not" to determine whether it is possible to recombine outside the depot.
There is the fact that the vehicles where the lines are connected are considered as one group, which makes the player's to grasp convoy configuration simpler.

(This is still an old image)
For example, this convoy has 10 vehicles but can be simplified into 3 groups. Depending on the schedule, these three groups may be separated along the way. But it will never be finer than that. It is recognizable only by looking at the connection of the lines and I do not think that it is too much information.

QuoteBesides, information about wether a vehicle can make fixed connections to multiple vehicles or only one inside the depot will anyway not tell you what specific vehicle that might be, or wether that vehicle is then hard constrained to ANOTHER vehicle and so on.
Again, the black horizontal line is regarded as one group at outside the depot and has no further meaning.
The one with a black vertical line is often called a unit in many cases. This is what regards the unit as one chunk. It will not make much sense except when assembling in the depot. It is of the type that is automatically considered as fixed_coupling without having to write fixed_coupling to dat file.

Note that only permanent coupling in the depot makes sense until the recombination is implemented.

Quotethat the better solution would be to disable that feature, so the player will have to press every vehicle (s)he whishes to buy. In the case of the hardcoded one to one constraints, the player is presented with that sole vehicle and buying that will reveal the following vehicle available for purchase.
I think this is a very complicated issue. The current specifications have both positive and negative aspects.
However, it is obvious that renovating this requires a lot of work.


QuoteIt appears though, that it can be a bit difficult to spot the difference in the vehicle selection field, perhaps increase the transparency for easier identification?
Ahh, yes. Transparency is still an issue to consider. I will increase the transparency.

Phystam

Thank you, Ranran, for your great work!
I really love the constraint display, and it will be very helpful for constructing convoys.
I think that the transparency for motor cars is not so good idea, because the GUI theme will change the color.
Using other non-transparency color (such as the color multiplied by gray) should be better.

Currently there is no EMU in pak256-Ex, but it is planned to introduce some EMUs, in the next update. I would like to test this feature using pak256-Ex.

Ves

First, let me clarify that I really do think you are doing a great job, Ranran. The examples you provide does look really good and I believe is a great addition, thank you!!
My main goal with my arguments is to think like a new player that is presented with a GUI, and have the learning curve (which is already pretty steep even for Simutrans Standard) as shallow as possible. The perfect GUI would in principle not need help texts.

I believe we confuse each other, though:
QuoteI do not think so. This is a very small amount of information only to check "the black lines are connected or not" to determine whether it is possible to recombine outside the depot.
There is the fact that the vehicles where the lines are connected are considered as one group, which makes the player's to grasp convoy configuration simpler.

(This is still an old image)
For example, this convoy has 10 vehicles but can be simplified into 3 groups. Depending on the schedule, these three groups may be separated along the way. But it will never be finer than that. It is recognizable only by looking at the connection of the lines and I do not think that it is too much information.
This is a great design and completely intuitive, and this is not what I have been talking about or arguing against (save for the now vertical black bars, see below).

QuoteAgain, the black horizontal line is regarded as one group at outside the depot and has no further meaning.
The one with a black vertical line is often called a unit in many cases. This is what regards the unit as one chunk. It will not make much sense except when assembling in the depot. It is of the type that is automatically considered as fixed_coupling without having to write fixed_coupling to dat file.

Note that only permanent coupling in the depot makes sense until the recombination is implemented.
Although you changed it to a vertical bar immedietedly following the colored bar which does indeed make it less prominent, it is this (and ONLY this) part of the information that I find is the case of "too much information". You agree yourself that it is unnecessary information when the convoy has left the depot, since those vehicles will anyway not be detachable.

Emphasizing with the GUI that there is a difference makes the player also believe that there is a difference.

About the autobuy:
QuoteI think this is a very complicated issue. The current specifications have both positive and negative aspects.
However, it is obvious that renovating this requires a lot of work.
It took me some time to find it as it was very well hidden, but in simtool.cc at line 8847 it reads:
if(info->get_trailer_count()!=1  ||  (tool=='i'  &&  info==start_info) || tool == 'u'   ||  new_vehicle_info.is_contained(info->get_trailer(0)))
Commenting that line out will force the while loop into the "break" immediatedly. One could probably clean out some more things around the loop, as autoadding vehicles is what it appears to do.



QuoteWhich is the better? or another?
I like the thicker version (7px bar height), and I think it looks really good! This makes it easier to spot the transparency (or how you decide to do the color alteration as Phystam mentiones) within the bars and the connections between vehicles, and also I find it pretty easy to read multiple vehicles at once.

The last vehicle in that convoy (although an illegal convoy), I think the black bar should extend to the second last vehicle as well. Now its unclear wether the connection is fixed and one could wonder wether the convoy can actually split there. When the convoy is well outside the depot (well, that would be if it wasnt illegal) the connection is anyway fixed and the player should avoid to get confused with that. But the illegal connection between vehicle 2 and 3 I think is excellent presented as you do and I would not change that.

If you want to emphazise for the player what specific vehicle is enforcing the fixed coupling, I would suggest to use the symbol you currently have made for the "permanent coupling" (which I argue against above) and use that as the fixed coupling symbol instead of just the black line.

jamespetts

The increased thickness is a great improvement, I think - this looks considerably better. Phystam may have a good point about transparency - I am not sure how well that this will work with other backgrounds and it would be worthwhile testing it. It would be interested to see this tested with Pak.256 as suggested.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Ranran

Thank you for your thoughts on this.

I will need to solve any issues that may arise before changing the code.


It is about 64px size pakset.
There used to be 64px size for experimental pakset, but there is no one that has been updated.
At 7px height it looks like this in 64px size pakset...


Is there a problem with this appearance?
Or do I have to deal with this individually? (´・ω・`)



Also, if enlarge the height and change it to a color that Phystam said, the shape of the head will be slightly different to simplify the drawing code.

The head of the upper 6th car is a bidirectional example. (The actual that car is EMU.)

And this is not yet an in-game image, but what do you think of the center color of the non-powered vehicle in this width?


Quote from: Ves on April 14, 2019, 05:55:28 PMIt took me some time to find it as it was very well hidden, but in simtool.cc at line 8847 it reads:

if(info->get_trailer_count()!=1  ||  (tool=='i'  &&  info==start_info) || tool == 'u'   ||  new_vehicle_info.is_contained(info->get_trailer(0)))

Commenting that line out will force the while loop into the "break" immediatedly. One could probably clean out some more things around the loop, as autoadding vehicles is what it appears to do.
What I wanted to say is that I do not think that only canceling this is the correct answer. That certainly has the advantage of saving you the hassle.
Also, pakset may have stated the full cost or the like on the first vehicle on the premise of using this function. For example, connected tram in 128.Britain-Ex. (However, this is not correct when assembling from the rear vehicle.)
If my ideal is to be stated, the vehicle connected when the mouse is over is displayed in translucent on the upper assembled conboy (standard has a bar that shows the length of the convoy.), and the information such as the added vehicle length and cost is additionally described. But I think it will take a lot of work to make it.

jamespetts

The 64 pixel version, although not as neat as the 128 pixel version, still looks quite acceptable, I think: it seems functionally clear, at least. Also, it is unlikely that there will be any significant usages of a 64 pixel sized Extended pakset as the trend is towards larger tile sizes, although this possibility cannot be ruled out entirely.

The non-powered colour in your example graphic seems good to me.

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. 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.

As to the code referred to by Ves, I believe that this is from Standard and automates purchases of linked vehicles. It is probably sensible to retain it unless it presents insuperable difficulties.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Ves

Quote from: Ranran on April 14, 2019, 10:55:27 PM
Also, if enlarge the height and change it to a color that Phystam said, the shape of the head will be slightly different to simplify the drawing code.

The head of the upper 6th car is a bidirectional example. (The actual that car is EMU.)
And this is not yet an in-game image, but what do you think of the center color of the non-powered vehicle in this width?
I think it does look good!

Quote
What I wanted to say is that I do not think that only canceling this is the correct answer. That certainly has the advantage of saving you the hassle.
Also, pakset may have stated the full cost or the like on the first vehicle on the premise of using this function. For example, connected tram in 128.Britain-Ex. (However, this is not correct when assembling from the rear vehicle.)
If my ideal is to be stated, the vehicle connected when the mouse is over is displayed in translucent on the upper assembled conboy (standard has a bar that shows the length of the convoy.), and the information such as the added vehicle length and cost is additionally described. But I think it will take a lot of work to make it.
Quote from: JamesPettsAs to the code referred to by Ves, I believe that this is from Standard and automates purchases of linked vehicles. It is probably sensible to retain it unless it presents insuperable difficulties.
I am not strongly for or against the autobuy feature as such. That was just the argument to differentiate the GUI between single constrained and multi constrained vehicles.

Vladki

Hello, I must admit that I'm getting lost here. What is all this supposed to fix/enhance?
I believe it started with differentiating coupling that can (not) be uncoupled outside depot, which is so far only a planned feature.
I admit that showing different color bar for powered and unpowered vehicles might be useful, as well as showing can-lead-from-rear.
But I lost at the multitude of shapes and colors...

In regard of can-lead-from-rear, this might be a good time to reopen an older issue. Currently it is impossible to code twin/triple articulated engines, like swedish Dm3 https://en.wikipedia.org/wiki/SJ_Dm3, czechoslovak class 131 https://cs.wikipedia.org/wiki/Lokomotiva_131. These are permanently coupled together. Similar case are american EMD F9 A/B units https://en.wikipedia.org/wiki/EMD_F9 which can be rearranged in different formations. The problem demonstrates when reversing - at the moment the only way to reverse properly is to set these units as not bidirectional, but then it takes longer time to reverse (like steam engines with trailing tank). If these units are set as bidirectional, then the order is swapped, and after reversal they are facing cab-to-cab. Instead the whole unit should be moved to the other end as-as, and time taken should be same as for single bidirectional engine.

A solution I proposed some time ago would be to change the meaning of bidirectional and can-lead-from-rear (CLFR):
bidirectional=1 means that the vehicle (engine or car) can run at full speed in both directions - no need to turn it around
bidirectional=0 means that the vehicle has to be turned around. In practice there was a speed limit for running in reverse, so the reversal was done if possible. We are not simulating deliberate running in reverse with speed penalty
CLFR=1 vehicle has a cab at the rear (or a central cab that is useable for driving in both directions)
CLFR=0 vehicle does not have a rear cab (it may, or may not have a cab in front, that is not important).
For reversal - if all vehicles are bidirectional, the train would be searched from the end for a vehicle with CLFR=1, and split there. The part from the front to the rearmost CLFR=1 will be moved without rearranging to the other end of train. Only if the last vehicle is CLFR=1, the shortest turnaround time will apply. If there is no vehicle with CLFR=1, the first vehicle will be turned around (regardless of if it is bidirectional or not), and attached at the other end.
If there are any other non-bidirectional vehicles, the would have to be turned around and attached at appropriate place. This also solves the problem for trains that have regular engines at both ends. This change would allow them to reverse as fast as if the train were a single unit.

Examples:
most rail cars (trailers): bidirectional=1, clfr=0   (no change)
steam engines with separate tank: bidirectional=0, clfr=0 (no change, same values for engine and tank)
steam tank engines, most single unit diesel and electric engines with 2 cabs or central cab: bidirectional=1 clfr=1  (change in clfr)
twin engines like class 131 above: front unit bidirectional=1, clfr=0; rear unit bidirectional=1, clfr=1

jamespetts

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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Vladki

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)

Ranran

#37
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.
Quote from: Ranran on April 13, 2019, 01:53:24 PMAt 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.

Ranran

Quote from: jamespetts on April 14, 2019, 11:06:50 PMOne 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?


QuoteThe 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.

Vladki

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)

Vladki

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.

Ranran

#41
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.


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

Ves

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


Ranran

#43
Thank you for your favorite  :)

Quote from: Ves on April 28, 2019, 10:14:23 AMnot 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.

jamespetts

Thank you, Ranran, for your work on this and Vladki for your feedback.

Quote from: Vladki 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)

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).

Quote from: Ranran on April 16, 2019, 04:23:15 PM

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.

QuoteI 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.

Quote from: Ranran 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.


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

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?
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Ranran

#45
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..

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

Ves

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.

Ranran

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.

Quote from: Ves on May 11, 2019, 12:20:45 AMI 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.

Ves

Quote from: Ranran 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?
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.

jamespetts

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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Phystam

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.


jamespetts

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!
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Ranran

I have to write a lot of replies, but I only post the urgent contents first.
QuoteI 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

QuoteOne 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.


Quote from: Phystam on May 17, 2019, 12:35:11 PMRanran, Can you help anything related to this? Check list is most helpful for me.
Thank you for the testing. What does a checklist mean?

jamespetts

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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Ranran

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.

Ranran

QuoteI 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.


QuoteI 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.


QuoteI 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
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.

Ves

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.

Vladki

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.

ACarlotti

Quote from: Ves on May 18, 2019, 07:22:12 PMBut 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).

Quote from: Vladki on May 18, 2019, 10:33:07 PMSo 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.

Ranran

#59
I use the expression "permanent connection" as proposed by ACarlotti.


QuoteThen 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.

QuoteBut 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.)


QuoteThat 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.


QuoteBut 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.

jamespetts

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.
Download Simutrans-Extended.

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

Follow Simutrans-Extended on Facebook.

Ranran

Quote from: jamespetts on May 19, 2019, 12:11:46 PMOne 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.

QuoteIf 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.


QuoteI 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.
LOCO_SYM
L

Vladki

Quote from: Ranran on May 19, 2019, 07:05:54 AMI 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?

Quote from: Ranran on May 19, 2019, 07:05:54 AM
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.

Quote from: Ranran on May 19, 2019, 07:05:54 AMAt 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.

Quote from: ACarlotti on May 19, 2019, 12:45:08 AM
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)

Quote from: Ranran on May 19, 2019, 07:05:54 AMOne 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).

Quote from: Ranran on May 19, 2019, 07:05:54 AMIn 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

Ranran

#63
Quote from: Vladki on May 19, 2019, 01:30:09 PM
Quote from: Ranran on May 19, 2019, 07:05:54 AMIt 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. (´・ω・`)

ACarlotti

Quote from: Vladki on May 19, 2019, 01:30:09 PMBut 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.

Ves

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.

QuoteI 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.

QuoteThere 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.

QuoteIn 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.

QuoteI 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.

QuoteIn 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.

Vladki

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.

ACarlotti

Quote from: Vladki on May 19, 2019, 08:22:33 PMBut 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.)

Ves

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


Ranran

#69
QuoteRanran, 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.(´・ω・`)


QuoteIt 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.

QuoteNO 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.


QuoteWrong, 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.



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



Quotea) 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.

QuoteWhen 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)

Ves

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

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

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

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

Vladki

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

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

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

jamespetts

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

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



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

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



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

fixed_coupling_prev=0

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

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

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

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

Follow Simutrans-Extended on Facebook.

Ranran

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

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

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

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

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

jamespetts

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

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

Follow Simutrans-Extended on Facebook.

Phystam

Pak256-ex has already been prepared for this patch!

Ranran

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

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

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

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

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

The branch is the same as before.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/

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

Ranran

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

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



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


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


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


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

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


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



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

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


EDIT:
The test branch is here. This includes a patch for Formation picture.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/mixed-load-prohibition