Similarly lack of heating might reduce comfort ... But this is going too far.
That would be something currently simutrans-ex specific.
Anyways I like the idea. We would have to differ technical and comfort requirements. A technical requirement means that a train can't dirive if the requirement is not provided.
A comfort requirement means that a train can be used without it but it won't have the additional comfort coupled to the feature.
We could even present these to the player in an intuitive way: We do just list the technical the required, forwared and provided features of each car and also display the default and max comfort of a car so a player can quickly decide if that car is worth looking for the comfort requirements in detail.
These would be also listed like in a way like
electricity is needed for a dining car to work and obviously can only be provided if there is some locomotive generating electricity or some loco or car that transforms electricity from the catenary. Such a car would just provide electricity.
3 would be a technical feature for the powered cars that don't have an own catenary
Note: there is again no difference in providing of forwarding a feature that is needed for technical or comfort reasons. There is only a difference in the requirement. If a technical requirement can't be provided, the train just can't move on its own. If a comfort requirement isn't provided, it will just provide less comfort.
in the dat files it could look for example like this:
Well I'm not happy with this syntax. I think it would be better readable if we could define these as pairs like this
just drop the value index, if we can only say what instead of how many of these can be provided/are needed.
Because it's me, I do have to think about what this feature would be in general. I know implementing the general idea would go a bit far but I want to share these thoughts maybe some of these can be used somewhere.
Currently we did just look at the specific case where we have defined 2 special cases: technical and comfort requirements. What are these requirements in gemeral?
There are many technical values for vehicles in simutrans for example max velocity, power, some power multiplier, weight, cost and runningcost.
So what exactly is a vehicle feature? A feature is something that will be activated if it's requirements are provided. When it's activated, it will change the values of a car in a specific way.
So we have to define something like provides, forwards and options for each vehicle, where an option needs a requirement to be activated.
I know in st-ex vehicles can be upgraded. This currently changes some values of the vehicle if i understand it right.
This could instead just add a provides, forwards or option.
An example, where +n means "add the number n to the base value", -n means "subtract the number n from the base value" =n means "set this value to n", *n means "multiply the value with n" and /n means "divide the value by n"
our powered control car which doesn't have an own car has the following requirements, which I will describe in a more readable JSON-like way instead of in a dat file way. Note that this can be translated to dat syntax without any problems.
#some heating power will be consumed, the remaining amount will be passed to the next car.
#our cab car can't control any loco if jthere is no loco listening to it.
#our control car does have some engines so it will use these if some loco (or whoever) provided the needed electricity for these.
an upgrade for this car could install automatic doors. These do increase the maintainance costs a bit but will also lower these if the feature is used because there won't be a conductor needed for that car:
#this option doesn't have a requirement so it will be always active, reflecting the increases mantanance costs when automatic doors are installed
#this is the feature itself reflecting that there won't be a conductor needed if we have automatic doors.
#this means it needs an automatic door controller for this feature to work but won't "consume" that feature
#there won't be a conductor so the running_costs will be lower
Other upgrades could be 1st class "added features". Don't know if "added feature" is the right translation for "Komfortmerkmal" meaning something like a feature that will be offered by 1st class cars that isn't offered in 2nd class cars
#increased space for each seat
#meaning there will be 30% less seats in that car
Or an own pantograph so it doesn't require to get the power needed for the engines from a loco.
Our cars in between this control car and the loco would need to:
These for sure could be done by upgrading cars
A loco for this could be something like that by default (without upgrades)
And there could be a passenger train upgrade for this loco like this:
And also a cargo upgrade like that:
#decrease vmax, increase gear
I guess we would also have to provide a name for options so we can present these better to the player.
translated to dat syntax the heating option would be something like
and so on.
One could also reflect bogie upgrades, installation of Train protection systems to increase the maximum velocity or whatever.
This would be really flexible and understandable. I don't think it could be presended in an intuitive way to players but there are also many other features im simutrans that aren't intuitive.
It won't affect balancing as long as it's not used, so it doesn't affect the balancing of existing sets.
The downsides of that much flexibility are that it would be pretty complicated balancing scenarios where many vehicles can offer many different options. On the other hand, pak maintainers aren't forced to create extremely complex scenarios.
implementing this also shouldn't be that much more work compared to the requires/forwards/provides solution that only uses technical and comfort requirements since it's basically the same you can just also adjust other values.
However in general it seems that having require on control car, forward on middle cars and provide on engine might be the way to go.
provide/require should not imply that it also forwads something. The should be independent settings.
That would make upgrading in some cases easier. Also that way we don't have to provide something to the left/right. We do just provide some amount of some feature and say to which direction this can be used by forwarding it to that direction.
You could argue that generationg power (provides) in a car is useless for the other cars if there is no cabling (forwards) to transport this power to the next car.