News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

bidirectional and can_lead_from_rear

Started by Vladki, September 22, 2016, 08:45:04 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Vladki

Why the red car cannot be turned on the turntable and put on the other end of train? All the other vehicles would then not need any shunting/turning as they have a green driving trailer. The red car seems to be the observation car from james' example.

My algorithm would be a bit different:
1. and 2. will be the same as yours
3. after reversal by my algorithm would be (__|-|__|-|__|-|__)-\__\-<__>, but then next reversal would make:  <__>-(__|-|__|-|__|-|__)-/__/ .. Although this is quite unusual setting, it might need some adjustments to keep the engines together. Hmm, maybe not. the \__\ will not have_front_guards_cab so it will probably end as <__>-/__/-(__|-|__|-|__|-|__)
4. will be the same as yours
5. will be: (__|-<__|-<__|-<__|-<__|-|__>
6. and 7. will reverse so that it will be order (_orange_)-|_green_|-<_purple_>
8. in my case it will look more like 7. - only one green car and 4 orange
9. will be the same as yours
10. will in my algorithm end up same as 5. However in your case - after reversal it will turn into push-pull train and will not rearrange any more.
11. will do the same as 9.
12. will be the same yours - but note also that after reversal it would have cabs on both ends and will become push-pull train.
Originally I thought that after 2 reversals the train should be back at its original order, but it is not the case, but eventually should find a stable pair of configurations.

Vladki

Sorry for double post.

Just wanted to sum up my algorithm.
In short it is about finding the longest part (optimally the whole) of train that has driver cabs on both ends. Then find in the rest the longest part with brake vans on both sides. Then swap those parts. If such parts are not found, rotate the engine or brake van as needed, together with any constraints they might have

Ranran

#72
Rendering issues:
Quote from: jamespetts on May 18, 2019, 11:56:45 AMOne possible solution is to have a reverse offset: a certain number of pixels in the x and y directions in which vehicles in a pakset (or a specific vehicle) are shifted in each of its 8 orientations if marked as reversed. I am not sure quite how difficult that this would be to code, and it would take a considerable time to calibrate, but it is likely to be less work than re-rendering the whole pakset. I have not looked into this in any detail to assess the viability.
Since pak.CS has the correct position, we will need to influence only a specific pakset to avoid any negative effects.

Quote from: Ranran on May 12, 2019, 01:12:36 PMbut it seems that the shift pixel of the freight car and the passenger car are different, so it is not enough to shift by the same pixel.
This is very unfortunate but, as I pointed out, this is different for each vehicle in the width of distortion. (´・ω・`)

QuoteFreight train:

Specifically, this open wagon seems to be a contradiction of 1px in both x and y.


However, this coach has a 7px distortion in the x direction and about 2.5px distortion in the y direction.


I think it would be easier to add an offset to dat than to modify the image, like
EmptyImage[SE]=./images/abcde.0.0,7,3




Reordering algorithm:
I replaced the image with a numbered one and added the example of American locomotive mentioned by Vladki.


#3:
It is a code issue. Imagine an algorithm for locomotive group renumbering.
I considered the code become very complex, so I considered the locomotive as a group and did the same reversal for all.
The code is a reuse of existing code.

It is renumbering by the simple code shown below:

for( ; a<--b; a++) //increment a and decrement b until they meet each other
{
reverse = vehicle[a]; //put what's in a into swap spacekarte_t::load(
vehicle[a] = vehicle[b]; //put what's in b into a
vehicle[b] = reverse; //put what's in the swap (a) into b
}


It should be noted that the formation of the locomotive group has unlimited possibilities.
It may be a 100 or more locomotives.
First, swap the 1st and 100th vehicles. Next, replace the 2nd and 99th vehicles. Repeat this and replace 50 and 51 to finish.

Question, what code do we need to write to renumber correctly in this?  :coffee:

This is an extraction of only the locomotive, and another vehicle is connected behind it.


#5
Whether the last vehicle is an unbidirectional vehicle is checked first. This is the same as the existing algorithm.
The tail of the fifth train is not a view vehicle. The passenger car is originally left at the station and waits for the locomotive shunt and runs in reverse. In the case of the formation of the view vehicle, it is common to rotate the whole formation with wye.
Unlike locomotives, passenger cars can not move on their own, so it is not impossible to pull out the last passenger car and rotate it on a turntable, but it will hardly happen in practice. If you do that it may be necessary to incur additional time penalties. Also, considering the possibility of fixed, the inversion algorithm will be complicated. If it is fixed, it may not fit on the turntable, so it will eventually become wye. Since this is a considerable edge case, it seems safe to use the standard method (wye) in this case. Because it is easy to be connected to the error when restoring it.

#7 and 8
Orange is considered to be pulled by the shunting locomotive and moved through the shunting loop. I think the vehicles that should be left at the station (not moving) are the longer ones.
Perhaps that should be closer to the operation of the brake van.
We also look at the search algorithm for the brake van from behind. In this case, when the last one is checked, it is regarded as a kind of brake van and the search is ended.

#10
Yes, that's right. But using wye suffers a big time penalty.
I think this is the player's responsibility. It looks like the player made the wrong decision but that it was corrected.
I think this problem is somewhat complicated, for example, what would happen if the previous two were locomotives without capacity and the four behind were coaches without power?
The reason for detecting No. 5 as an error is that there is no car (that is, a round end pointing to the left) that can be tailed in the remaining car when the locomotive is removed (for shunting).

#12
I think it is the same matter of 10.


QuoteIn short it is about finding the longest part (optimally the whole) of train that has driver cabs on both ends. Then find in the rest the longest part with brake vans on both sides. Then swap those parts. If such parts are not found, rotate the engine or brake van as needed, together with any constraints they might have
Yes, I think this makes sense.  :)


Supplement about my reordering algorithm:
Check the power and capacity to identify the locomotive. Therefore, locomotives should be renumbered as separate groups, with coaches and wagons without power.
EMU / DMU are different from them because they have power and capacity.


EDIT:
I think the turntable reversing time panalty should be proportional to the number of locomotive (count one power as one).
Also, I think that the remaining passenger cars and freight cars should be able to be loaded while the locomotive is shunting.

Vladki

#73
Loading already happens while train is reversed. So the time spent in station is the longer of the two (loading or reversal).

Quote from: Ranran on May 21, 2019, 02:46:56 PMI think the turntable reversing time panalty should be proportional to the number of locomotive (count one power as one).
I agree.

I think about adding a check in the beginning that if there is vehicle with power=0 && bidirectional=0 then just use wye.  However wye or loop requires quite some space and was not available at most stations.
It is good that you come up with such crazy train combinations, although a sane railway manager would never make such. But beginner players will surely make their first train to be something nobody of us would understand.

QuoteQuestion, what code do we need to write to renumber correctly in this?  :coffee:
Considering my algorithm, it will split between 8/9. the 9+10 will be considered as the brake van sequence - moved to the other end and rotated. 1 rotated too. Next time 9+10+1 will move together

Ves

I think those examples look great!

Although it is not required before the reassemble branch, I would like to add some thoughts and suggestions for princips in cases where "fixed_coupling" and also "front/rear" cabs are engaged:

Using the same ASCI art as Vladki:

<__>   - bidirectional engine
(__) - full brake van, cabless booster engine (EMD F9B)
|__| - ordinary car that cannot be neither front nor rear end
_|=|_ - fixed_coupling
_|-|_ - coupling that can be disconected anywhere
<__|=|__) - steam engine with tender
<__|=|__|=|__> - 3-part EMU/DMU/articulated engine including garrat engine
(__|-|__|-|__) - set of passenger cars (front-brake, middle, rear-brake)
|__|-|__|-(__) - two cargo waggons with full brake at the end


1) <__>=|__)
The fixed connection eliminates the rear cab. Both vehicles would need to turn around for reversal, just like a steam engine.

2) =<__>=
If a vehicle with this configuration is sent out alone, it can not connect to any vehicles outside the depot.

3) =<__>=<__>=
A convoy in this configuration also cannot split or connect other vehicles at either end.

4) <__>-(__)=
(Note the fixed coupling on the rear vehicle)
Altough perhaps unusual, a convoy in this configuration would allow the locomotive to disconnect from the car but not connect on the other end of the car. The car has effectively become only single directional and needs to turn around to be hauled in the other direction.

Ranran

Quote from: Vladki on May 21, 2019, 03:26:10 PMConsidering my algorithm, it will split between 8/9. the 9+10 will be considered as the brake van sequence - moved to the other end and rotated. 1 rotated too. Next time 9+10+1 will move together

Maybe, reverse the direction of black locomotive until the last locomotive is reached and swap the numbers if two or more purple locomotive are connected.
The number of black powered vehicles is counted and the reversing time is increased accordingly.


Quote from: Ves on May 21, 2019, 09:44:27 PM2) =<__>=
If a vehicle with this configuration is sent out alone, it can not connect to any vehicles outside the depot.

3) =<__>=<__>=
A convoy in this configuration also cannot split or connect other vehicles at either end.

4) <__>-(__)=
I thought it was necessary to distinguish whether cab side could be connected, but I think this display would be confusing.
Because the bar in front of the vehicle seems to represent a coupler. Actually, it is a notation often used in railway magazines and websites.
That is, it looks like the opposite meaning.
Those who saw the picture would think that the cab side without the coupler can not connect anything.

Vladki

With such a complicated possible configurations, I think if it would not be easier to have a smaller set of "typical" configurations and let everything unusual reverse using wye... with significant time penalty.

Ves

True, the symbols might look bad, however, I mostly used the ASCI-art to illustrate my point.
Thinking about it, what would it look like if you did that with your graphics?

jamespetts

There are a very large number of issues here; I will deal with them under headings for ease of reference.

Bidirectional flag for intermediate vehicles
It should in principle be possible for an intermediate vehicle to have bidirectional=0, should it not? Ranran gives the example of rail vehicles with seats all facing in one direction.

Are you sure that this is ignored at present? I have not looked into it for some time, but this is not my recollection of how it works, albeit that recollection is no longer certain.

Relevance of the existing can_lead_from_rear flag
I am not sure that I understand what you mean when you write that it is not clear what "side of the CFLR" has a cab; the can_lead_from_rear flag is intended to mean that, when the train is in the forward orientation, if the very last vehicle has this flag, the whole train can run in reverse without modifying the position or orientation of any vehicle. It follows from that that the rear end of that last vehicle must be assumed either to have a driver's cab or some other arrangement functionally equivalent to a driver's cab (e.g. in a driverless train, which is why the word "cab" should not be used in the .dat file syntax) to enable it to lead the whole train.

Thus, it is not immediately clear to me where the uncertainty lies - the "can_lead_from_rear" flag always indicates the presence of a driving cab (or equivalent) at the rear of the vehicle (i.e., the second of the three graphics in the message of the 18th of May).

If the vehicle also had the "allow_at_front" flag set to true, it would be as the third graphic. If it had only the "allow_at_front" flag set and not the "can_lead_from_rear" flag set, it would be as the first graphic.

It is important to avoid making existing data structures redundant if this can be avoided, as it avoids a lot of unnecessary work both in the code and the paksets.

Whether each vehicle or the whole train ought to have a flag to indicate its reversed status
The existing code already has a boolean flag for whether any individual vehicle is reversed: see line 317 of simvehicle.h.

Brake vehicles
I believe that I have already responded to Vladki's suggestions as set out in the 19th of May in an earlier message, proposing a specific alternative algorithm and noting that it should not be hardcoded that brake vans should always be at the rear, but should be a pakset level setting as at present. Likewise, whether any given observation car should be able to be placed behind the engine (etc.) should be a pakset level matter and not hardcoded. We want a system that works at a high level of abstraction wherever possible to give the greatest flexibility and minimise unnecessary coding work, unnecessary work for pakset authors and unnecessary work in understanding by players.

As to the front/rear constraints after reversal, it is very simple for an algorithm simply to take into account reversal in assessing the constraints, as already discussed, so that next constraints are treated as prev. constraints and prev. constraints are treated as if they were next constraints in any reversed vehicle.

Status of constraint=any
I see no immediate reason to change the way in which this works fundamentally. Generally, it should be possible for pakset authors to continue to get the existing behaviour or something close to it (or something that will always or almost always be better than it) by using the existing settings and can optionally choose to get the new behaviour by using new settings/parameters.

Reversing algorithms
We still need to finalise fully how we deal with brake vans before dealing with this. The algorithm itself will need to be reasonably predictable by users, and so should be simple in all but complex cases.

Rendering issues
It is extremely odd that it is even possible for the pixel shifting to be different for each vehicle. There must in principle be some deterministic algorithm that results in this difference and thus some means of automatically reverse-engineering this.

The amount of work that it would involve to re-render the entire Pak128.Britain pakset is so far beyond what is feasible that it is virtually inconceivable that this will ever be done in any conditions that are ever likely to occur. As to adding an offset in the .dat files - is this a known solution that allows Pak128.Britain vehicles to work in the same way as Pak128.CS vehicles?

Integration with vehicle management
Can I ask what consideration has been given to how well that the ideas being discussed here would, when implemented, fit in with the vehicle management branch when work on that is completed? This is of no small importance.
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

Quote from: jamespetts on May 29, 2019, 07:44:33 PMAs to the front/rear constraints after reversal, it is very simple for an algorithm simply to take into account reversal in assessing the constraints, as already discussed, so that next constraints are treated as prev. constraints and prev. constraints are treated as if they were next constraints in any reversed vehicle.

There is one important detail that you don't mention here. Currently 'prev' constraints assume coupling to the rear of another vehicle, and 'next' constraints assume coupling to the front of another vehicle. We would need to modify the .dat file definition to allow specifying a particular end of the adjacent vehicle in constraints. There is then the question of whether the existing format should be assumed to speficy coupling at a specific end (both vehicle in the same orientation) only, or whether it should allow the adjacent vehicle to be in either orientation.

Vladki

Regarding the misaligned reversed vehicles. Here are the templates of pak128.CS. Although they are old, designed for track with higher ballast, now they are used with offset 0,4. You can compare them with pak128.britain and see if you might find what is wrong. https://forum.simutrans.com/index.php/topic,3206.0.html

Ranran

This is a quick note about reversed vehicle position problem.
Simutrans is not originally designed to have a mix of reversed images. For example, S and N.
The image in the opposite direction is aligned with the opposite end. In other words, the reference position differs from the opposite vehicle, and the reference position shifts for all vehicles with different lengths.
Unless the problem is solved, in many cases when the vehicles in the opposite direction are mixed, the position appears to be shifted.

This is also true for pak.CS. It can be said about all pak.

But apart from that 128.Britain-EX has additional positional inconsistencies. That point is obvious if you look at the track and the position of the vehicle.