I have been philosophising over a similar functionality myself, but I never came to a full agreement with myself about the extend of this kind of functionality, because I could endlessly come up with extra possibilities. But here are my thoughts:
In the first place, I would like this kind of functionality, however, if we reason about it, we would see that there is a bunch of other parts of a train that can deviate between a carriage or wagon that is coupled at both sides and an end-car. Take for example the traditional 'chain' or 'screw' couplers used here in Europe, but also for example gaiters between two carriages.
Then I realised that in earlier times, when reflective surfaces were harder to come by, the signals on the end of the train (the markers as you call it) had to be changed around sunset from marker signs to lamps, so it would also be nice to have the possibility to switch the freightanim during the activity, for a predefined different marker. Which then opened the way in my mind for carriages that crossed borders (for example, in the 1930s the Dutch railway law required a train to have three markers (signs at day, lamps at night) on the train. One of those markers was a red disk or a red lantern placed underneath the buffer or the coupler hook, the other two should either be placed on the widest part of the train, or above the roof. These two lamps should have a red light to the rear, and a green (later yellow) light to the front. The Belgian law only required a single sign or lantern on the rear of the train), so it would also be nice to be able to define multiple signal sets for different countries etc etc.
Well, you see, I started to come up with more and more functionality that would be nice to have and ended up discarding the plan for being too large and infeasible.
However, I did have a start of a plan to implement this kind of functionality. You see, in the ORTSFreightAnim we can define Subtypes. What if we could define these subtypes somewhere?
If we could define that the subtype so that the type would only be used on the last vehicle, or the first vehicle or all vehicles, we would start getting somewhere. In the case of couplers and gaiters we would need to define that the subtype would be necessary on all vehicles, but then define what shape is used in what case, for example: shape A for all vehicles that are coupled on both sides, B for vehicles on the rear of the train, C for vehicles on the front of the train, and D for vehicles that are uncoupled.
From there on we could be thinking of incrementing the logic of these cases, for example for gaiters the logic from the coupler would be duplicated, but then the condition should not only be 'coupled on side x', but 'coupled on side x to a vehicle that has the same subtype defined' etc.
Finally you could think of a dialog box somewhere in the sim where you could choose to add, replace or remove certain freight anims from the vehicle, which would also add the possibility to, for example, to choose between a set of marker types, but also to change the destination signs on your train.
So, my plan of attack would be the following:
- Create the possibility to define freightanim subtypes and simple characteristics, like if they are required, and if they should be shown at day or night
- Increment the definable logic to the extend that you can define if a type of freightanim is required on all, front or rear vehicles
- Add the possibility to define lights for ORTSFreightAnims
- Increment the definable logic to the extend that you could define for a subtype what shape should be shown for what condition with simple conditions, like front, back, uncoupled or center vehicles
- Extend the conditions to more dependencies, for example the presence of a freight anim of the same subtype at the coupled vehicle.
- Add the possibility to choose between freight anims of the same subtype in a in game dialog. This would require to define in the subtype if the subtype is mutual exclusive (that is: could there be more freight anims of the same type on the same vehicle or not), and read the statement if and when a subtype is required, so that on a carriage in the center of a train we would not need to choose an end marker, but can choose between multiple destination signs etc.
However, I think this would have to wait until a new engine/wagon file format is in place. I am willing to help design the file format on this point, however, I would really need to find some time to add C# to my skills (which contains quite some programming languages in different abstraction levels, but not C#) to help implement it.
Additionally, because I realise this is a lot of work, I would define the blue points as 'can haves' in the MoSCoW method, while the other points could be 'should haves', but I respect if both are scaled down a step to won't haves and can haves respectively.
Just my 2 cents on a functionality that would be a step in the right direction, but might have a lot of implications.
Log In
Register Now!
Help
