The International Simutrans Forum

 

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

0 Members and 1 Guest are viewing this topic.

Offline Ranran jp

  • *
  • Posts: 301
  • 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.

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

Offline Ves

  • Devotee
  • *
  • Posts: 1587
  • 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: 18239
  • 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: 9383
  • 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: 301
  • 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: 18239
  • 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: 9383
  • 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: 9383
  • Languages: De,EN,JP
Re: constraint[prev]=any
« Reply #7 on: Yesterday at 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: 301
  • Languages: ja
Re: constraint[prev]=any
« Reply #8 on: Yesterday at 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.  :)

Offline Ves

  • Devotee
  • *
  • Posts: 1587
  • Languages: EN, SV, DK
Re: constraint[prev]=any
« Reply #9 on: Yesterday at 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.