The International Simutrans Forum

 

Author Topic: constraint[prev]=any  (Read 568 times)

0 Members and 1 Guest are viewing this topic.

Offline Ranran jp

  • *
  • Posts: 308
  • Languages: ja
constraint[prev]=any
« 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



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:
Code: [Select]
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:
Code: [Select]
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:
Code: [Select]
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/extend-coupling-constraint2

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.

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

Online Ves

  • Devotee
  • *
  • Posts: 1588
  • Languages: EN, SV, DK
Re: constraint[prev]=any
« Reply #1 on: March 13, 2019, 11:07:16 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:
Code: [Select]
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:
Code: [Select]
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:
Code: [Select]
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.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18249
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: constraint[prev]=any
« Reply #2 on: March 17, 2019, 11:55:59 AM »
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.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9391
  • Languages: De,EN,JP
Re: constraint[prev]=any
« Reply #3 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.

Offline Ranran jp

  • *
  • Posts: 308
  • Languages: ja
Re: constraint[prev]=any
« Reply #4 on: March 17, 2019, 02:03:30 PM »
I 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.  ;)

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18249
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: constraint[prev]=any
« Reply #5 on: March 17, 2019, 10:01:08 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.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9391
  • Languages: De,EN,JP
Re: constraint[prev]=any
« Reply #6 on: March 18, 2019, 02:08:57 PM »
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).

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9391
  • Languages: De,EN,JP
Re: constraint[prev]=any
« Reply #7 on: March 21, 2019, 01:34:46 AM »
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.

Offline Ranran jp

  • *
  • Posts: 308
  • Languages: ja
Re: constraint[prev]=any
« Reply #8 on: March 21, 2019, 09:11:55 AM »
@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.

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

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.


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

Online Ves

  • Devotee
  • *
  • Posts: 1588
  • Languages: EN, SV, DK
Re: constraint[prev]=any
« Reply #9 on: March 21, 2019, 06:15:54 PM »
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.

Offline Ranran jp

  • *
  • Posts: 308
  • Languages: ja
Re: constraint[prev]=any
« Reply #10 on: March 23, 2019, 06:41:35 AM »
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.





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



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

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2508
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: constraint[prev]=any
« Reply #11 on: March 23, 2019, 07:53:48 AM »
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.
« Last Edit: March 23, 2019, 08:08:15 AM by Vladki »

Offline Ranran jp

  • *
  • Posts: 308
  • Languages: ja
Re: constraint[prev]=any
« Reply #12 on: March 23, 2019, 12:56:37 PM »
But 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:


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

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

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

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2508
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: constraint[prev]=any
« Reply #13 on: March 23, 2019, 03:24:56 PM »
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.

Offline Ranran jp

  • *
  • Posts: 308
  • Languages: ja
Re: constraint[prev]=any
« Reply #14 on: March 23, 2019, 04:02:38 PM »
Quote
if 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
Code: [Select]
constraint[next][0]=coach01
constraint[next][1]=coach02
Or another new feature - the vehicle can't separate outside the depot?


Quote
I 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. (´・ω・`)

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2508
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: constraint[prev]=any
« Reply #15 on: March 23, 2019, 04:35:12 PM »
- Or another new feature - the vehicle can't separate outside the depot?

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

Offline Ranran jp

  • *
  • Posts: 308
  • Languages: ja
Re: constraint[prev]=any
« Reply #16 on: March 23, 2019, 05:13:53 PM »
Ah, okey.

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.

Online Ves

  • Devotee
  • *
  • Posts: 1588
  • Languages: EN, SV, DK
Re: constraint[prev]=any
« Reply #17 on: March 23, 2019, 05:50:31 PM »
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.

Quote
Most 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!  :)

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2508
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: constraint[prev]=any
« Reply #18 on: March 23, 2019, 05:55:23 PM »
Yes I also think that the slanted bar should be used for drivers cab, ie can lead from rear

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9391
  • Languages: De,EN,JP
Re: constraint[prev]=any
« Reply #19 on: Today at 01:47:34 PM »
Why not using the half yellow half green bar of standard which means it requires another trailing/leading vehicle?