News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

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