Topic: Vehicle constraint improvements

[Ters]

An easy way to display to the player what general constraints a given car needs, could be to show something like two or three rows in the depot window:

Features:
Screw couplers
Electrics
Vacuum brake

Must be attached to a vehicle with:
Screw couplers
Electrics
Vacuum brake

Sure, but I don't think that is what Simutrans ought to use constraints for, except perhaps the brakes. Unless the player is given the option of changing the couplers on the vehicles for a small price, that is.

[Ves]

Sure, but I don't think that is what Simutrans ought to use constraints for, except perhaps the brakes.

I think that is the beauty of this mechanism, that it would be indeed possible to create such constraints! Although those where just some quick examples, it was a suggestion how to present it to the players.

Unless the player is given the option of changing the couplers on the vehicles for a small price, that is.

In Experimental, that would not be a problem (refering to the upgrade feature)

[Ters]

I think that is the beauty of this mechanism, that it would be indeed possible to create such constraints! Although those where just some quick examples, it was a suggestion how to present it to the players.

It is just that as a player, I don't want that kind of absolute constraints, because they don't really exist in real life. The only type of coupling constraint Simutrans needs in my opinion would be trailer hitch vs. fifth wheel for road vehicles. The adapter in that case is a vehicle of its own. The other kinds would be internal in Garratt locomotives and the like.

[Vladki]

I think I ought to explain why I started this topic. It started when I fiddled with pak128.CS and experimental. As there is no support for liveries in standard, but many liveries in real life, guys making the graphics produced quite huge amount of variations on the same vehicle. I know it is suboptimal, to retire vehicle just because livery had changed, but that's what we have now. As an example is the czechoslovak railbus class 810 and its trailer class 010. There are lots of modifications of these basic classes - not only liveries, but also upgrades - better comfort, new engines, control cars, more space for bikes, even conversion to multiple units. They have standard hook and chain coupling, so they can be attached to any engine, but they are of weaker construction, and may be put only at the end of train (if it contains full-size cars). Also they have centrally operated doors (pneumatic). Several classes of light-diesel engines (shunters), were additionally equipped with door control, to allow the trailers to be used without the powered railbus. (There were too many trailers made). Each trailer has independent heating, and batteries (charged from engine). So I wanted to make a constraint class, that would contain all 810/010 and their variations, plus properly equipped diesel engines, to be connected together, but not with normal cars. It could be achieved with current constraint system, but the amount of individual constraints would be huuuge.

Another example would be with steam heating - czechoslovak railways had two very similar diesel engines: class 775 and 776. Class 775 was used for heavy cargo trains (similar to russian "Taiga Drum"). Class 776 was a modification, equipped with steam heating for passenger trains. Because of that it was heavier, and had smaller fuel tank. Currently it is not possible to pass the information to the player and force them to use the heavier (and probably more expensive) class with passenger trains instead of its cargo-only twin.

In regard to ICE2 and similar - we had some similar discussion in pak128.sweden forum: http://forum.simutrans.com/index.php?topic=15851.0
In general you have two options: either you want to follow the reality very strictly, and then you have to define all 8 cars as separate objects (and further 8 for reversed unit). Or you give your players some freedom, and allow them to build something that really does not exist, but is technically possible (i.e. longer/shorter, without dining, over/under powered, etc.) In the latter case it may be beneficial to have a constraint group for ICE2 so that only ICE2 cars can get coupled together and pak developers are free to make a fictional ICE2 car (e.g. mail).

The strict approach is IMHO more suitable for shorter units, like trams, whose parts are not repeated.

After reading all the replies, I'm not sure if having constraints for everything is good approach. Some incompatibilities can be easily solved by adapters, or small engine upgrades, some not. Some incompatibilities and loss of functionality (e.g. heating, door control) are acceptable during shunting or moving vehicles between depots, but not acceptable during regular transport of passengers. And simutrans vehicles should be IMHO constrained for the regular traffic.

I think it is not worth implementing the default coupling or braking constraints, as they are usually standardized in whole countries or regions, and you do not have to care about them in regular traffic. Of course in border areas, you may have to deal with neighboring country's coupling (and other standards) and there were time periods when you had to deal with transition from one braking system to another, but that is IMHO too much of micromanagement and complication for players. OTOH simulating special couplings used for EMU/DMU like Scharfenberg, should be done. Also coupling groups may be useful for trucks and trailers.

TLDR: constraint groups /features may simplify some already existing constraint definitions, or allow some others which were not yet defined because they would require too long list. However some real world constraints should be omitted for simplicity and gameplay reasons.

[Leartin]

It is just that as a player, I don't want that kind of absolute constraints, because they don't really exist in real life. The only type of coupling constraint Simutrans needs in my opinion would be trailer hitch vs. fifth wheel for road vehicles. The adapter in that case is a vehicle of its own. The other kinds would be internal in Garratt locomotives and the like.

I agree to that in theory, but Simutrans is not real life. Coupling might not pose a restriction in real life, worst case, rope and a tight knot are always available.
But there are many real life factors not found in the game. I'm pretty sure there is some kind of law or regulation that would not allow to attach cars to a locomotive using a rope, even though it would be possible.

Now, some of these factors are rather general and could one day be represented in the game, since they are intuitive enough for players. Comfort, of course. Another thing would be a "brake power", a variable each vehicle could have. Using the weight of the convoy and it's summed up braking power would define a max allowed speed - even though it could technically go faster, it wouldn't be able to brake safely. Special brake wagons need to be added to get more brake power in the convoy so it's allowed to go faster. Essentially, these would be game mechanics that try to represent reality.

Apart from that, the game can create it's own "gameplay" reality. Rules that don't try to depict reality directly, but stem from programming issues or balancing, and may or may not be 'explained away' by aspects of reality.
For example, forcing a Railjet Locomotive to go in front of Railjet wagons. There is no reason to do that as far as reality is concerned. But for gameplay reasons, it should either be the best combinaton, or the only available one - because they *should* belong together. Balancing is hard though, especially since there are not too many variables by which vehicles can be destinct. Therefore the easier route, forcing them together and balance the whole train against other trains of limited variances (ICE, TGV)

[Ters]

I agree to that in theory, but Simutrans is not real life. Coupling might not pose a restriction in real life, worst case, rope and a tight knot are always available.
But there are many real life factors not found in the game. I'm pretty sure there is some kind of law or regulation that would not allow to attach cars to a locomotive using a rope, even though it would be possible.

The point is that if someone made an SJ Dm or NSB El 12 pak back in the 1950s, and put screws coupler constraints on it. An player in the 1970s would not be able to use that locomotive in Simutrans to pull knuckle coupled cars, even though the real locomotive was doing that in real-life. But this is more of a design rule than a technical issue, because the style of constraints I propose/support, could technically be used to create a screw vs. knuckle coupler constraint. There is however a significant compatibility issue with such a different constraint concept.

Now, some of these factors are rather general and could one day be represented in the game, since they are intuitive enough for players. Comfort, of course. Another thing would be a "brake power", a variable each vehicle could have. Using the weight of the convoy and it's summed up braking power would define a max allowed speed - even though it could technically go faster, it wouldn't be able to brake safely. Special brake wagons need to be added to get more brake power in the convoy so it's allowed to go faster. Essentially, these would be game mechanics that try to represent reality.

That is indeed an interesting idea, but I think that would be rather separate from general constraints. Experimental could perhaps use the same concept for service quality (which I believe it has, but I could have misread). If there isn't enough supply of heat or electricity, things would be cold or dark. Standard doesn't care for such things, so braking power would be a unique concept.

[Ves]

I think there is some major things that needs to be settled:
Are we talking about constraints as in all constraints must be respected or is just one matching constraint out of many enough?

Or is it assumed that there are like two "levels", one level where all is needed, and one level where only one single one is needed, much like the logic "and" and "or".

Is it assumed that a train "needs" the constraints in the constraint[prev] section and only "provides" the constraints in the constraint[next] section, but anything else could also be coupled rear?

In the latter case, the SJ Dm3 example would be easy to solve by using:
Constraint[next]
Screw coupling
Knuckle coupling

Then both types of coupling could be used since trains anyway cannot decouple cars in simutrans, it would not matter as you would not be able to fast switch the cars outside the depot.

[Ters]

In the latter case, the SJ Dm3 example would be easy to solve by using:
Constraint[next]
Screw coupling
Knuckle coupling

Sure, but if you have to put both on all locomotives in case of a coupler change, the constraint becomes pointless.

[Freahk]

Of course in border areas, you may have to deal with neighboring country's coupling (and other standards) and there were time periods when you had to deal with transition from one braking system to another, but that is IMHO too much of micromanagement and complication for players.

I do also think so for pak sets that try targeting everyone, including beginners. However, the beauty of the system would be that it's possible. So if one day someone wants to create a more complex pak set for advanced simu players, there's nothing stopping him to do so.
I don't know if such a pak modification would be played by many players but trying to solve things differently is always a nice things for experience exchange.

In regard to ICE2 and similar - we had some similar discussion in pak128.sweden forum: http://forum.simutrans.com/index.php?topic=15851.0
In general you have two options: either you want to follow the reality very strictly, and then you have to define all 8 cars as separate objects (and further 8 for reversed unit). Or you give your players some freedom, and allow them to build something that really does not exist, but is technically possible (i.e. longer/shorter, without dining, over/under powered, etc.) In the latter case it may be beneficial to have a constraint group for ICE2 so that only ICE2 cars can get coupled together and pak developers are free to make a fictional ICE2 car (e.g. mail).

I do currently have that exact problem with some closed source MU paks that fit the balancing well but don't have mail so these just aren't used, so I guess I will drop these out of my list of addons. This affects nearly all SNFOS and ENASSA MUs that were not made by Gauthier.
Also, newer MUs that don't have power heads anymore can most often also be configured by the client to fit different lengths. However, there are in fact requirements between the cars like powered cars that need to get the power from another car carrying a transformer and a pantograph.

The point is that if someone made an SJ Dm or NSB El 12 pak back in the 1950s, and put screws coupler constraints on it. An player in the 1970s would not be able to use that locomotive in Simutrans to pull knuckle coupled cars, even though the real locomotive was doing that in real-life. But this is more of a design rule than a technical issue, because the style of constraints I propose/support, could technically be used to create a screw vs. knuckle coupler constraint. There is however a significant compatibility issue with such a different constraint concept.

For st-ex it should not be a problem. The SJ Dm or NSB El 12 just has a screw coupler constraint in the 1950s and there will be an upgrade changing screw couplers to knuckle couplers availiable in the 1970s.
For sure to do so there must be a way of changing constraints by an upgrade.
For st-classic we would indeed need something like "or" connected constraints that can use constraint groups. The currently implemented constraint system is "or" combined, so we could maybe just combine it with constraint groups. That way we can't say that te train can just pull knuckle cars from the 1970s on but it would be a fine compromise I think.
We could just say constraint[next]=screw-coupling, constraint[next]=knuckle-coupling and could couple everything that can provide a screw-coupling or a knuckle-coupling.
Opposed to this, requiring something means, that everything of the requirement list has to be given otherwise the train can't move.


What about the option feature I mentioned?
That would be some kind of automatic vehicle upgrade if the requirements are given.
For example if a car has an engine option, that one can be activated by providing enough electricity to that car by forwarding the electricity from some electricity provider.
Also if there is a steam heating option in that car, that one will be activated if a car nearby can provide the heated steam.


Btw. groups of couplings can already be simulated in Simutrans by creating a coupling as a dummy car. That coupling is given the list of all cars that do have the same coupling and the cars will only contain the couplings it can use as the prev/next constraints. That way we do still have to maintain a long constraint list but we do only have to maintain it once for each coupling type instead of once for each car. Anyways, this is ugly and will decrease maximum train lengths pretty much. I guess this is the reason why pak authors don't define couplings that way.


Btw:

Your whole ICE2-concept is flawed, because you want to require players to do what you would like to see, pretty much arbitrarily.

You obviously didn't get what I want to do. Enforcing the dining car was just another compromise that worked best for all of the 4 mentioned aspects except the freedom for players to create whatever they want as long as it stays balanced.
I do just want to get as close as possible to trains that can
-be composed by the player as he wants, especially including over-length trains.
-be composed in a realistic setup without being worse than any unrealistic composition for its primary use case.
-not be composed in a way so that the train is completely unrealistic and also the best for a secific use case. That means it's np for me if someone creates a train that has only dining cars, but it is a problem for me if that is the most profitable configuration for a specific use-case.
-be build symmetrically, because otherwise some players will start crying again. However that point is the least important one for me nor I want to enforce symmetry for all.

For sure if there was a comfort level this would also be easier but by choosing constraints in a specific way, it's also possible to get close to these 4 points without a comfort system but currently the constraint system is a way too inflexible for really doing this.
That being said, I won't be writing about my balancing thoughts in this thread nor I will give any examples that are not explicitly about technical rrequirements.
Just notice that a more complex constraint system would make some things easier.

Anyways as I said, it was just an example that isn't that bad imho because a system that can describe these requirements well can also describe technical requirements well.

[Leartin]

That is indeed an interesting idea, but I think that would be rather separate from general constraints.

Yes, of course, that's intended. Constraints as proposed in this thread could be used to require a train to have a locomotive. Du'h - There already is a mechanic that requires a train to have a locomotive, the value "power". You could use constraints to limit how many wagons a train can be long. Du'h - There already is a mechanic that limits the number of wagons, the value "weight". These simulate reality, therefore they feel natural and can be grasped by a player quite easily (in comparison to something like "gear"... ugh)
Braking Power would just be another such value. At least, that's the idea. Not really that unique.

You obviously didn't get what I want to do. Enforcing the dining car was just another compromise that worked best for all of the 4 mentioned aspects except the freedom for players to create whatever they want as long as it stays balanced.
I do just want to get as close as possible to trains that can
-be composed by the player as he wants, especially including over-length trains.
-be composed in a realistic setup without being worse than any unrealistic composition for its primary use case.
-not be composed in a way so that the train is completely unrealistic and also the best for a secific use case. That means it's np for me if someone creates a train that has only dining cars, but it is a problem for me if that is the most profitable configuration for a specific use-case.
-be build symmetrically, because otherwise some players will start crying again. However that point is the least important one for me nor I want to enforce symmetry for all.

Or, maybe, you still did not get why doing this via constraints is a bad idea...
I agree to the goal, and I already gave you a solution: If the difference between dining car, first class and second class were purely in looks, no realistic setup could ever be inferior to an unrealistic setup. But as soon as you have different values for each, it's virtually impossible to balance. Say, one of the wagons is cheaper, one has lower running costs and one has more seats. Players will need one of these things the most. If they need lower running costs, they will go with only these wagons. If they need more capacity... and so on.
Constraints are hard stops though. Constraints tell you which vehicle you can add to a train. If constraints were to look at the whole train, they might instead tell you whether or not the composition can leave the depot. But being constraints, no matter what you do, it would always contradict the first thing on your list, to allow players to do whatever they want. And these restrictions, by trying to allow as much as possible, would be rather arbitrary.

You already said it several times: "If Standard had comfort..." - that's EXACTLY it. For dining car and first class, you NEED a game mechanic they can use. Comfort is the most obvious choice. Since you are talking about rather small amounts of different vehicles, it could be a much simplified mechanic, some kind of set bonus (eg. all first- and second class cars get some kind of bonus if there is also a dining car in the train) - but that has pretty much nothing to do with constraints, and might not even solve the problem completely, though it might solve other problems. (Soft limits could replace most hard limits except for absolute technical requirements)

[jamespetts]

Surely a simple but effective system such as Experiment's way constraints would allow a range of solutions, and all the various issues that are being discussed in detail here could be decided by pakset authors, each of whom may take a different view of the relative importance of some of the matters mentioned?

[Freahk]

Exactly!
It's up to the pak devs how they will use it.

I think that is the beauty of this mechanism, that it would be indeed possible to create such constraints!

However, the beauty of the system would be that it's possible.

Just notice that a more complex constraint system would make some things easier.

Which basically mean exactly what you said. Thanks for pointing that out.

I guess the discussions (at least for me) were more about what would be possible and how we could present it in an intuitive way to the player.

I'd still like to know how you think about the options (optional features of a car that can be activated if the requirements are given). I think it's a pretty nice system that would work well with st-ex upgrading feature and would offer much more possibilities for pak authors. On the other hand it could go a bit too far.

For st without ex it couldn't be used with upgrades since these don't exist there, but it could also bring some game-play advantages if you have to consider taking a more powerful cargo loco that can't offer automatic doors and heating or if you take a (way less powerful) passenger loco that can offer these.

[prissi]

The any constraits are in standard since 120.4.1, the rest will not come.