News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

Dat file reference for: Vehicles and Ways

Started by Ves, January 18, 2016, 01:23:56 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

[C] Ranran

A good perspective.  ;)
I have prepared a pak configured as such. Insert the attached pak into pak.sweden and check the road depot.
I confirm this at today late night but check the results with your own eyes.
And it would be helpful to have an opinion on how it should be.
Because the algorithm may still have room for refinement.

Vladki

Have a look at road, ship and air depots. Some vehicles are <__), and some /__/
I have compared hovercrafts: sr-n6-winchester.dat and sr-n4-mountbatten-mk1.dat - there is no difference regarding constraints (non on both sides), and no use of bidirectional, CLFR, or has_cab... Yet they have different vehicle bar shape..   Frankly, I think that all cars, boats, and airplanes should be /__/.  As the cannot run backwards.   <__) shall be only for rail engines like american EMD F9A

[C] Ranran

Those without a cab before in the above list were 1D, 2D and 3D.
Next, those without a cab at the rear were Unidirectional 1F, 2F, 3F, 1H, 2H, and 3H in addition to the 1D, 2D, and 3D described above.

Sirius

Imho, the following would by logical:
"cab at front" cases
Logically, I would make the following propositions when driving forwards:
"no constraints specified" => "cab at front"
constraint[prev]=none => "can be at front" ~> true
has_front_cab=1 => "cab at front" ~> true
"cab at front" => "can be at the front" ~> true
"can be at the front" => "cab at front" ~> true
"cab at front" <=> "can be at the front" ~> true
"no cab at front" <=> "cannot be at the front" ~> true
"no cab at front" <=> "prev constraints defined" and "prev none constraint absent" ~> true

The above is only true when assuming that any vehicle is allowed to move forwards, which is currently always true.
That means a vehicle that can be at the front but doesn't have a cab there does not make sense as such a vehicle could not move forwards.
Further note I am aware that after reversal there might be a car at the "front", which is now the back, that does not have a front cab. From the old data we cannot distinguish front end cars from cabs.
Am I missing something here?

From the given information, the only thing we can say for sure about "can be at the front" is it depends. 3* cases, 3D in specific.
constraint[next]=none => "cab at front" ~> depends

"cab at rear cases"
The rear cab thing is slightly more complicated as we need to consider unidirectionality, there can be vehicles without a cab at the end and some combinations of parameters are contradictions.
It's easyer to say when we will not have a cab at rear.
Again logically, I would make the following propositions:
constraint[next]=none => "can be at rear" ~> true
"no constraints specified" => "can be at rear" ~> true
"can be at rear" and can_lead_from_rear=1 => "cab at rear" ~> true
"can be at rear" and can_lead_from_rear undefined and "powered" => "cab at rear" ~> true
"can be at rear" and can_lead_from_rear undefined and "unpowered" => "no cab at rear" ~> true
"can not be at rear" or can_lead_from_rear=0 => "no cab at rear" ~> true

Further:
can_lead_from_rear=1 and "can not be at rear"  ~> ↯
can_lead_from_rear=1 and unidirectional ~> ↯

In short
Thus, in short: 1* and 2* cases all have a front cab.
Purely from the 3* we don't know anything about the front cab.
Not covered in the table are cases with "prev" constraints defined but without a "constraint[prev]=none" defined. These don't have a front cab.

So 1D and 2D should have a front cab.

For 1* and 3* cases, the A, C, E cases have a cab at rear, B, D, F, H cases don't have a cab.
G is contradictions.
Purely from 2* cases we know B, D, F, H cases don't have a cab but the others depend.
Not covered in the table are with "next" constraints defined but without a "constraint[next]=none" either don't have a cab or are contradictions.
Also cases "with can_lead_from_rear" undefined are not covered. These behave like can_lead_from_rear=1 when powered and can_lead_from_rear=0 when unpowered.

So 1F, 3F, 1H and 3H should not have a rear cab.

Ves

Without considering how it could or should be, I attempt to distinguish the cases which is currently implemented. When that truth table is in place, we can much easier discuss what cases should generate cabs or not.

Quote from: Freahk on February 14, 2020, 07:14:24 PMG is contradictions.
I know, it is on the list just for consistency at the moment.

Quote from: Ranran on February 14, 2020, 01:49:49 PM
Those without a cab before in the above list were 1D, 2D and 3D.
Next, those without a cab at the rear were Unidirectional 1F, 2F, 3F, 1H, 2H, and 3H in addition to the 1D, 2D, and 3D described above.

So Ranran, are you saying this is how it works now:

1A) no constraints specified   bidirectional = 1   powered         can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
1B) no constraints specified   bidirectional = 1   powered         can_lead_from_rear=0 = HAS FRONT CAB   |   HAS REAR CAB
1C) no constraints specified   bidirectional = 1   unpowered      can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
1D) no constraints specified   bidirectional = 1   unpowered      can_lead_from_rear=0 =                                 |
1E) no constraints specified   bidirectional = 0   powered         can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
1F) no constraints specified   bidirectional = 0   powered         can_lead_from_rear=0 = HAS FRONT CAB   |
1G) no constraints specified   bidirectional = 0   unpowered      can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
1H) no constraints specified   bidirectional = 0   unpowered      can_lead_from_rear=0 = HAS FRONT CAB   |


2A) constraint[prev]=none      bidirectional = 1   powered         can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
2B) constraint[prev]=none      bidirectional = 1   powered         can_lead_from_rear=0 = HAS FRONT CAB   |   HAS REAR CAB
2C) constraint[prev]=none      bidirectional = 1   unpowered      can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
2D) constraint[prev]=none      bidirectional = 1   unpowered      can_lead_from_rear=0 =                                 |
2E) constraint[prev]=none      bidirectional = 0   powered         can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
2F) constraint[prev]=none      bidirectional = 0   powered         can_lead_from_rear=0 = HAS FRONT CAB   |
2G) constraint[prev]=none      bidirectional = 0   unpowered      can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
2H) constraint[prev]=none      bidirectional = 0   unpowered      can_lead_from_rear=0 = HAS FRONT CAB   |


3A) constraint[next]=none      bidirectional = 1   powered         can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
3B) constraint[next]=none      bidirectional = 1   powered         can_lead_from_rear=0 = HAS FRONT CAB   |   HAS REAR CAB
3C) constraint[next]=none      bidirectional = 1   unpowered      can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
3D) constraint[next]=none      bidirectional = 1   unpowered      can_lead_from_rear=0 =                                 |
3E) constraint[next]=none      bidirectional = 0   powered         can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
3F) constraint[next]=none      bidirectional = 0   powered         can_lead_from_rear=0 = HAS FRONT CAB   |
3G) constraint[next]=none      bidirectional = 0   unpowered      can_lead_from_rear=1 = HAS FRONT CAB   |   HAS REAR CAB
3H) constraint[next]=none      bidirectional = 0   unpowered      can_lead_from_rear=0 = HAS FRONT CAB   |

When the truth table is correct, I will attempt ro write it down to a more generalized and slim truth table!

Vladki

Please is it possible to add defaults to ALL values in the first post?

I'm trying to understand the new reversal options and how the defaults behave. bidirectional, clfr, has_*_cab, and the connection to various constraints...
@Ranran would you be so kind and explain at least what is the meaning of the flags used in basic_constraint_prev/next ?


enum veh_basic_constraint_t {
cannot_be_at_end = 0,
can_be_head  = 1,
can_be_tail  = 2,
unconnectable = 4,
intermediate_unique = 8,
unknown_constraint = 128,
only_at_front =(can_be_head|unconnectable),
only_at_end = (can_be_tail|unconnectable) // this type always be bidirectional=0
};

I think that can_be_head is that it has drivers cab at the respective end, and that can_be_tail means that it can be the last vehicle in that direction (it is a brake van)
But what are the others? Especially the last combined flags: only_at_front only_at_tail. Can you show some real examples of what is what?

Also I had the feeling that the obsolete CLFR is translated to has_rear_cab, but apparently it is much more complicated. It explicitly enforces bidirectional=1 and effectively works as if the vehicle has both front and rear cabs. Which is not true for most of the vehicles that have CLFR=1. They usually have only the rear cab. I thought that if CLFR is deprecated, you would try to get rid of it ASAP and convert it to the new options, but you are still using it all over the code.

I think there is also some confusion caused by terminology. It seems that sometimes you use "END" for either end of train (front or rear), but sometimes only for the rear end.

[C] Ranran

A new vehicle parameter was added earlier but is not listed yet.
https://forum.simutrans.com/index.php/topic,21492.msg199857.html#msg199857
Can james edit the first post and add it? I am not an English speaker.

p_accommodation[X] =
m_accommodation[X] =