News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

met-bogie constraints & upgrades

Started by Vladki, July 11, 2017, 12:33:48 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Vladki

I have found some inconsistencies in met-bogie constraints and upgrades. However I'm not exactly sure how they were supposed to be operated.

met-bogie-brake-front seems to be OK. Whatever in front of it, and middle, rear or none cars behind.
met-bogie-third (middle) seems to be OK too. Constraint_prev is front and middle cars, constrain_next is rear and middle cars.
met-bogie-brake-rear, has constraint_prev OK. But as contraint next I would not expect middle and rear cars. What makes sense to me is either anything, nothing, or a front brake car (to join two sets together).

met-bogie-push-pull seems to be OK - allowing only limited set of engines, and 1 (rear), 2 (front+rear), 3 (front+centre+rear) cars in a set.

met-motor-third-back is missing the bidirectional flag
met-motor-third-front is also missing the bidirectional flag and incorrectly marked as can_lead_from rear.
met-motor-third-middle can be upgraded to itself...

Here is a patch


diff --git a/london-underground/met-bogie.dat b/london-underground/met-bogie.dat
index da6943b..e7f9021 100644
--- a/london-underground/met-bogie.dat
+++ b/london-underground/met-bogie.dat
@@ -167,17 +167,12 @@ min_loading_time=10
max_loading_time=30
comfort=70

-Constraint[Next][0]=met-jubilee-third
-Constraint[Next][1]=met-jubilee-brake-rear
-Constraint[Next][2]=met-ashbury-1863-brake-rear-fitted
-Constraint[Next][3]=met-ashbury-1863-third-fitted
-Constraint[Next][4]=met-bogie-third
-Constraint[Next][5]=met-bogie-brake-rear
-Constraint[Next][6]=met-dreadnought-third
-Constraint[Next][7]=met-dreadnought-brake-rear
-Constraint[Next][8]=district-4-wheel-third-fitted
-Constraint[Next][9]=district-4-wheel-brake-rear-fitted
-Constraint[Next][10]=none
+Constraint[Next][0]=none
+Constraint[Next][1]=met-jubilee-brake-front
+Constraint[Next][2]=met-ashbury-1863-brake-front-fitted
+Constraint[Next][3]=met-bogie-brake-front
+Constraint[Next][4]=met-dreadnought-brake-front
+Constraint[Next][5]=district-4-wheel-brake-front-fitted

Constraint[Prev][0]=met-jubilee-third
Constraint[Prev][1]=met-jubilee-brake-front
diff --git a/london-underground/met-motor-third-back.dat b/london-underground/met-motor-third-back.dat
index 6f4eac7..e0d4fca 100644
--- a/london-underground/met-motor-third-back.dat
+++ b/london-underground/met-motor-third-back.dat
@@ -23,7 +23,7 @@ runningcost=148
length=7

can_lead_from_rear=1
-bidirectional=0
+bidirectional=1
upgrade[0]=met-bogie-push-pull-rear
way_constraint_permissive[3]=3
available_only_as_upgrade=1
diff --git a/london-underground/met-motor-third-front.dat b/london-underground/met-motor-third-front.dat
index 98e81b1..f72e313 100644
--- a/london-underground/met-motor-third-front.dat
+++ b/london-underground/met-motor-third-front.dat
@@ -24,8 +24,8 @@ runningcost=148
sound=lul-1938-stock-ff3170.wav
length=7

-can_lead_from_rear=1
-bidirectional=0
+can_lead_from_rear=0
+bidirectional=1
upgrade[0]=met-bogie-push-pull-front
way_constraint_permissive[3]=3
available_only_as_upgrade=1
diff --git a/london-underground/met-motor-third-middle.dat b/london-underground/met-motor-third-middle.dat
index 17b121f..aa11e20 100644
--- a/london-underground/met-motor-third-middle.dat
+++ b/london-underground/met-motor-third-middle.dat
@@ -24,7 +24,6 @@ can_lead_from_rear=0
bidirectional=1
upgrade[0]=met-bogie-push-pull-rear
upgrade[1]=met-bogie-push-pull-centre
-upgrade[2]=Metropolitan-Motor-Third-Middle
way_constraint_permissive[3]=3
available_only_as_upgrade=1



Further I have a question about upgrades. The interface is rather tricky, but I finally managed to go through upgrade. However I could upgrade only vehicles that were a part of convoy. If I disassembled a convoy, I could not upgrade the individual vehicles. And due to changing constraints, such vehicle may remain un-upgradable forever.
It is also quite hard to find out if I can upgrade anything, even if the convoy is in the depot. It would be nice if the convoy has some new color that says "upgradable", and the vehicles in depot as well. Then clicking on existing the vehicle could offer an upgrade instead of adding/removing from convoy.



jamespetts

Thank you for the report - I have now fixed the anomalies, although the bidirectional and can_lead_from_rear flags are consistent with other multiple units, which work correctly, so I do not think that these are incorrect.

As to the interface for upgrading, that will have to be given some consideration when the maintenance features are implemented in due course. Amending the user interface in Simutrans in any non-trivial way, however, is extremely difficult because of the arcane nature of much of the code, so any solution would have to be very straightforward.

May I suggest a separate topic about the interface? It is very confusing to have a general discussion about the interface in the same thread as a bug report about a pakset.
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.

Vladki

In that case I probably did not understand how is the bidirectional and clfr supposed to work.

I thought that vehicles not bidirectional must be rotated... Or is it just that the vehicle has cab on both sides? How about normal rail cars (without driver)? Do they need bidirectional = 1?

Sent from my ONEPLUS A3003 using Tapatalk


jamespetts

If I recall correctly, when a train reverses in formation (i.e., the rear vehicle has can_lead_from_rear=1 set), the bidirectional flags of the end vehicles (and possibly the others) are not checked, as the code assumes that anything that can lead from the rear means that the train will simply reverse without any change to the formation. I am not entirely sure of this, however, as it has been a long time since I have worked on this code; I used the existing vehicles in the pakset as a template of how they ought to be configured (look at the BR Class 117 DMU, for example).
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.

Vladki

I could not find much detail about the class 117, so I will ask. It may be similar to a Czechoslovak EMU 560 class http://www.vagonka.cz/20001.asp?ids=22516
It has powered cars at both ends. Each powered car has only one cab, and a gangway on the other. If running alone it must be turned around, but normally they run in a set, so there's no shunting and turning neecessary. How should it be coded?
Front: bidirectional=0, clfr=1 ?really?
Middle: bidirectional=1, clfr=0
Rear: bidirectional=0, clfr=1

On the other hand DMU 843 http://www.vagonka.cz/20001.asp?ids=2254, has cabs on both ends. It can be used alone, or in combination with class 043 trailers and optionally also class 943 driving trailer (with only one cab). I'm not sure if it can be remotely controlled to form a longer set with motors on both ends, but let's assume that yes. It can be controlled form driving trailer, so it should be cotrollable from another motor car.
Motor: bidirectional=1, clfr=1
Middle: bidirectional=1, clfr=0
Rear: bidirectional=0, clfr=1

jamespetts

The Class 117 is as you describe: each end carriage in a set is a motor carriage with a cab at one end and a gangway at the other. The (optional) centre carriage has a gangway at either end and is unpowered. They were inevitably run in sets with a cab at either end. Often, the sets would be coupled to other sets of the same or a different type of multiple unit. You can see how these work in game and how they are coded by looking at the .dat files and also the compiled pakset.
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.

Vladki

Yes I took the options from class 177 dat. What I do not understand is why the front motor has clfr=1? If it would be at the end of the train (ignoring constraints) it could not lead from rear, as its cab would be in the wrong direction.

But it could be a way to tell that the front car can be remotely controlled, to avoid making push-pull sets with incompatible engines.

jamespetts

Quote from: Vladki on July 12, 2017, 06:51:14 AM
Yes I took the options from class 177 dat. What I do not understand is why the front motor has clfr=1? If it would be at the end of the train (ignoring constraints) it could not lead from rear, as its cab would be in the wrong direction.

But it could be a way to tell that the front car can be remotely controlled, to avoid making push-pull sets with incompatible engines.

The can_lead_from_rear on the front vehicle may well be redundant. However, can you explain more about the remote control to which you refer? I am not sure that I fully follow.
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.

Vladki

The idea is that not all engines can be used in a push-pull configuration. Current constraints can solve that for dmu/emu, which are used only with their specific trailers. But there are also general purpose engines and driving trailers. Then the constraints might allow you to build a train that can run forward just fine, but should not run reversed. So I thought that clfr on front vehicle might be used to indicate if it can be controlled from driving trailer, or not.

In such case, only trains with clfr=1 on both ends would reverse quickly. Front engine with clfr=0 would have to run around to the end of train, even if there would be a driving trailer attached.

Sent from my ONEPLUS A3003 using Tapatalk


jamespetts

That is an interesting idea - but how could this clearly be communicated to players, do you think? Currently, in Pak128.Britain-Ex, I simply do not allow locomotives that are not push-pull fitted to couple to any auto-trailers.
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.

Vladki

Perhaps an informative line in depot, saying if the selected vehicle is bidirectional, and if it can be used in push-pull set.

I have a real example. Czech railways have not used push-pull sets until late 90's. Now they have upgraded some older passenger cars to driving trailers, employing starndard WTB (wire train bus). So far they have upgraded some engines of 4 different classes (electric 163, 242, 362, and diesel 750.7), to be compatible, and the latest class 380 is compatible too. The middle cars had to be upgraded too, but that was only minor thing - adding the wires, sockets and plugs to get the control signals through. At the moment two classes of passenger cars are being upgraded.

So the question is how to code such thing? Should I split all the involved engines, and trailers to two objects. One would be the original engine/car, second would be upgrade to push-pull operation. The push-pull cars would then be constrained so they could be joined only to the push-pull enabled engines?

(This takes us back to the old discussion of more general constraints...)

jamespetts

In the code as it currently stands, you would need to code specific vehicle based constraints for a push-pull set, being different vehicles from the non-push-pull set. The push-pull set could be very inexpensive upgrades (the middle carriages in particular) of the original, non-push-pull set.
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.