Recently I was thinking a lot about multi-modal vehicles. I have a proposal, how it could be handled in .dat files. Please take this as "design part" with some brainstorming, open for discussion, which could later lead to implementation (coding). From start we should really think no only about bi-modal (as in diesel or electric), but multi-modal (diesel, DC-electric, AC-electric), or even multi-system (electric but able to run on different voltages). Multi-system electric engines and EMUs have different characteristics when running on different voltages. The system as I see it, would allow to have multi-system engines with exact specification, which electrification systems it can use (unlike now when multi-system engines can run on any voltage). Also it could allow electric engines to be pulled by diesel engines on non electrified lines.
So the proposal is like this:
1. new option "multi-mode = 1" that will enable all these new fuctions. 0 would mean legacy behavior.
2. vehicle characteristics (power, tractive_effort, ...) for running in independent mode (diesel, hydrogen, battery, ...) would be defined as usual. Purely electric vehicles would have power=0 here.
3. there would be an extra set of characteristics for each way_constraint_permissive that this vehicle can use. The index would be the constraint number (e.g. in pak128.Britain-ex: 0 = DC third-rail, 2 = AC overhead)
Example:
obj=vehicle
name=BR-800MiddlePower
engine_type=diesel
multi_mode=1
# diesel mode
speed=200
power=700
tractive_effort=122
gear=50
runningcost=210
# electric mode (AC)
speed[2]=225
power[2]=904
tractive_effort[2]=77
gear[2]=80
runningcost[2]=226
# hypothetic third-rail DC mode (lower power and speed limit)
speed[0]=160
power[0]=850
tractive_effort[0]=77
gear[0]=80
runningcost[0]=226
(Hmm, I thought the electric mode would have lower running cost... But thats what I found in br-800.dat and br-801.dat...)
The list of options that can vary with the mode of operation is up to discussion. Most importantly range should be added to the above list. (Battery powered vehicles have quite limited range.)
If any option in this set would be omitted, it will default to the same value as is specified for independent (diesel) mode. Also values for all unspecified indexes will default to independent mode. (e.g. for the above vehicle, power[1] for DC overhead catenary, would have the same values as independent mode.). As you see the way_constraint_permissive[2]=2 and way_constraint_permissive[0]=0 is omitted. This will allow the vehicle to run anywhere.
The implementation of vehicle movements would have to do the following:
- check the multi-modal flag
- if multi-modal, check what permissive constraints are on the current tile where the vehicle is.
- if no constraints are present, continue as usual, use the normal values
- if there are multiple constraints, choose the constraint with the highest power
- use the indexed values of the chosen constraint
Issues I'm aware of now:
- purely electric vehicles would have power=0 by default, and only some power[n]=non-zero. They wouldn't be able to depart from non-electrified depot, but what if they encounter a stretch of unelectrified track on their journey? Would they refuse to leave the last electrified station, saying "no route"? Or would they enter the section, coast for a while, and eventually get stuck? Would they move at least 1 km/h to get out of there?
- using both diesel and electric engine on a train, would give power of both on electrified track. On non-electrified track, the electric engine would be just dead weight. (Not an issue though).
- electric engine with optional battery car. Engine would have power=0 and power[2]=880; battery car would have power=100 and power[2]=0. If the current way has the constraint no. 2, power[2]=0 should take precedence and switch the battery car off. (So it would not "boost" the engine while running on AC catenary). But it would boost anyway if the track has both AC catenary and 3-rd rail, because power[0] would default to power=100...
- implementation issue - as described above, the memory consumption of the vehicles would explode as it would have 9 sets of power related options (1 for independent mode and 8 for all possible permissive constraints). This could be reduced to store only those that are defined, but the algorithm for choosing the values would be more complicated.
- exceeding the range - well that could happen even now - what if there are multiple engines with different ranges in the same train, and the next destination is within the range of some engines, but out of range for others? With multimodal it becomes more funny. There might be an unelectrified stretch of track, but too long for the given vehicle's batteries. But both stops would be electrified, so the departure check for range would assume infinite range...
That's all for now. Any opinions, suggestions, etc?