News:

Want to praise Simutrans?
Your feedback is important for us ;D.

Vehicle constraint improvements

Started by Vladki, November 14, 2016, 11:58:38 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Vladki

Originally I wanted to put this in experimental subforum, but I think this could make it into standard, without breaking anything.

1. simutrans experimental already has "constraint[next][0]=any" that says the vehicle cannot be the last in train, and some other vehicle has to follow. Usually used on older non-braked wagons, to force a brake van at the end of the train. It would be nice to have this in standard as well.

2. opposite to 1. would be "constraint[prev][0]=any". That would mean that this car cannot be at the front of train. This could then be set on all cabless cars, forcing the train to start with engine or a control car.

3. allow for constraint features/groups. Their use would be to simulate some features like steam heating, centrally operated doors, cabling for control cars.
Rationale is - some passenger cars can be operated only with some engine clasess, that are equipped for proper heating, closing and opening doors. One could do it using prev/next constraints, but the list would be long, it would repeat at many cars, and would have to be change if new car of that class is added to the pakset. Maintaining such a list at all relevant cars would be error prone.

For the case of steam_heating, or door control, it could look like this:
Engine with steam generator (or just steam engine), would have: constraintgroup[0]=steam_heating
Passenger car that requires steam for heating would have: constraint[prev][0]=steam_heating and constraintgroup[0]=steam_heating.
Being in the constraintgroup means it passes the feature further to next car.

Simulating cabling for control cars would be more difficult, and more specific to experimental. I have some ideas, but I have to sort them out for myself first.

Ters

I'm not sure how useful this would be. Especially 3 would likely require introduction of new vehicles, possibly massive alterations and rebalancing to introduce and force such rules, and give a prolonged period of "chaos", considering the huge amount of existing vehicles (including add-ons) that don't consider such rules at all. Players will be confused why some luxury passenger car add-on can be pulled by an El Cheapo locomotive, while even relatively cheap passenger cars can't, without an extra "useless" wagon. Players who care for such realism likely apply this constraint by themselves.

Suggestion 1 also has some introduction problems similar to 3. If introduced into existing pak sets, and it will be rather useless if it isn't, players will suddenly need to add an extra car to their trains. Even if that car costs nothing and weighs nothing, so that it doesn't affect the profitability of the trains, it will still add extra length, which might cause jams that wasn't possible before. The only exception would be break cars that are normal freight cars, just with a tiny shed at the end. These can just replace the last similar non-break car, but would also be only make a tiny cosmetic difference.

Suggestion 2 seems to lack the kind of drawbacks 1 and 3 have, but most locomotives I've seen force themselves at the beginning of a train by not allowing anything else before them (except sometimes a similar locomotive), causing rule 2 to seem rather pointless. However, I'm not entirely happy with locomotives only being possible at the front, which might be just because number 2 is not currently possible. I don't think introducing number 2 will not lead to "chaos", but removing the constraint on locomotives that they have to be first, can. I think the "chaos" will mostly be the ability to run a lot of trains without any kind of cab first, at full speed, since most cars will lack the not-first constraint, so mostly cosmetic chaos.

These are the possible problems I can think of. So while introducing this functionality doesn't in itself break anything, making use of them will. And what is the point of introducing things, but not using them? It is no a definitive "no", but something to think more about.

jamespetts

I can certainly see the advantage of constraint groups - the current constraint system can be very cumbersome. Adding this would make maintaining Pak128.Britain-Ex a great deal easier, although it would take quite a lot of work to set up in the pakset initially. It could also allow for simulation of different braking systems (some more powerful than others - brake force is already a variable in Experimental) such as vacuum brake, air brake, chain brake and purely manual brakes.

One issue that will have to be considered, however, is how to represent these abstractions to the player: it will need more of an explanation, I think, than just showing to what vehicles that the vehicle in question can or cannot connect individually without explaining why.

The idea of an "any" constraint for "prev=" is also an interesting one, and does make sense in principle. This should be much easier to implement and would not change behaviour unless and until implemented in the pakset. This would also need no particular way of being explained to the player, as the reasoning for not allowing an ordinary railway carriage first (for example) would be obvious.

It may be that these features are more suitable for Experimental after all if the issue as to compatibility with long-established paksets or saved games is the main objection to adding these to Standard, since Experimental is at a point in its development where things can be added to existing dedicated paksetse without too much disruption (as all Experimental paksets are either under constant development in close co-operation with the code development and are likely to implement these ideas rapidly, or are long defunct).
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.

Mariculous

Edit: holy **** that post got pretty long and no one will read it to the end. The first 7 sections are about my idea of improving the current structure of the .dat files, the sections 8 to 10 are my idea of how we could change the constraints system to a much more powerful and more pakset-dev friendly way and the sections after it are just tons of examples.

--------- splittung the dat ---------
I posted another idea to solve this problem in a complete different way a few weeks ago in the German Simutrans Forum.
I'll try to explain the problems I encountered with the current constraint system and my ideas to solve these issues. However, I must admit it would require much more changes to the Simtrans code than Vladkis Idea but would also provide a more flexible way to define these constraints.

Some months ago I started reworking on some pak128 and SNFOS vehicles to see more different vehicles on my Simutrans Server. At first I started re balancing high speed trains because imho the pak128 balancing is fine for lower speeds but totally strange for high speed trains. At Second I started changing power (and cost) values of many trains so that the realistic train lengths can be used ingame, because prefer realistic train lengths and train compositions over these short train compositions of pak128.
Doing so, I noticed quickly that for some trains I really need to define 16 different cars for one! train (the Eurostar E320). However, graphically there are just 7 different cars if I could mirror cars, it would be even just 4 different cars.
So I started thinking about alternatives:
1. just create these 7 cars and allow the player to combine these as he wants to.
2. Just don't create that much cars, maybe just 3 or 4 but that would lead to much less details.
3. We need a new constrain system that does not just look one car behind and ahead. It has to know its context in the whole train.

That 3rd idea is what I thought a bit about:
We could split the dat of the vehicle into 2 or even 3 parts.
1st The graphical definition of the vehicle.
2nd the technical definition of the vehicle, referring to a graphical definition.
3rd the constraint definition of a vehicle, that defines where a car (defined by the technical definition)

I guess the current .dat files are compiled for performance and copyright reasons. We could still compile the graphical definition, but shouldn't compile the others, so the player could always re balance existing closed source  addons and also (much more important imho) create new cars for closed source addons.

For backwards compatibility constraints and technical data of the vehicles should still be taken from the dat file and these new files can override the values.
That being said, i didn't yet tell you my ideas about the most important point of my Idea: how do we define which cars can be combined in which way?

Attributes that are currently used and belong to the the graphical definition are
emptyimage, loadimage and copyright. For sure there also has to be a name for the image definition.

technical attributes are obj, name, waytype, engine_type, freight, payload, speed, power, gear, weight, cost, runningcost, fixed_cost, intro_year and intro_month

--------- an other way to define the constraints ---------
Imho defining the constraints of a car is just the exact same as defining the syntax of e.g. a programming language, so we could also use techniques that are already used over years to define a syntax that will be accepted. However, we will have to do it a way different because most  of the times these techniques can just say "it's k" or "nope" but we do also need something like "nope, but could could add these so it will be k" and "k, but you can still add these"

My first idea was defining the constraints by some kind of regular expressions. However, this approach has some huge disadvantages and no real advantages compared to my second Idea.

My second idea is a BNF like syntax of describing the constraints for example ABNF. Wtf is BNF? Basically BNF consists of nonterminals and symbols, where a symbol in this case is the name of a vehicle and a nonterminal is something like a placeholder for a chain of symbols.
I'll use an ICE2 with a fictional mail car as an example and will also grab the break/cabless car example.

The definition of the ICE2 constrains would be something like
"ICE2_CARS:=ICE2_CARS ICE2_CARS|ICE2_car|ICE2_post|_EPSILON_", meaning ICE2_CARS accepts everything that is a combination of only mail and passenger cars
"ICE2_MID:=ICE2_CARS ICE2_diningCar ICE2_CARS", meaning ICE2_MID accepts avrything that is like ICE2_CARS but also mus have exactly 1 dining car somewhere
"ICE2:=ICE2_powerHead ICE2_MID ICE2_cabHead", meaning an ICE2 (forward) is something that has a power head in the front, a cab car at the end and cars as defined in  ICE2_MID in between.
"ICE2_REVERSE:=ICE2_powerTail ICE2_MID ICE2_cabTail", meaning the same as ICE2 but with the cab car in the front.
"ICE2_COMP:=ICE2|ICE2_REVERSE|ICE2 ICE2|ICE2 ICE2_REVERSE|ICE2_REVERSE ICE2_REVERSE", meaning that you can combine 2 ICE2 as you want to create a ICE2 composition, just never couple a power head directly to another power head.

Where _EPSILON_ means nothing is also accepted.
One also has to define which rule the "root rule" is. That means which rule the only rule is that will be accepted. All the other rules can be inserted to it be separating these with an or.


Let's come to Vladkis examples:
For the cab cars and brakeless cars you can just define a rule like
BRAKED_CAR= list of all cars that do have a brake
TRAIN_CAR:= list of all cars that can be coupled to a normal train
TRAIN_CARS:= TRAIN_CAR TRAIN_CARS
TRAIN_END:= LOCO | BRAKED_CAR
TRAIN:=CAB_CAR_LEADING TRAIN_CARS LOCO | LOCO TRAIN_CARS TRAIN_END
ROOT_RULE:=TRAIN


The idea of feature groups would also work that way. For example:
HEATED_LOCO:=all locos that can heat a train
HEATED_TRAIN:= HEATED_LOCO HEATED_CARS

The only problem would be "groups" that require multiple features e.g. heating and automatic doors. One would have to create a rule for each desired combination of these features.

HEATED_AUTODOOR_TRAIN:= HEATED_AUTODOOR_LOCO HEATED_AUTODOOR_CARS
HEATED_AUTODOOR_CARS:= list of  all cars that have automatic doors and need a heating
HEATED_CARS:= HEATED_AUTODOOR_CARS and also all cars that do only have the heating feature
same for automatic door cars and the locos.

However, if I didn't misunderstand you the constraintgrup feature would have the same problem.

constraint[prev][0]=steam_heating
constraint[prev][1]=automatic doors

would accept everything that has at least one of these features.

Vladki

Yes the constraint groups would be better if combined with 'and', while non-groups with or. Combining groups in advance (brake, door, brakedoor) would require putting an engine capable of more features into all possible combination groups.

However I do not like the idea of using BNF to define constraints. It is powerful but tricky to understand.

gauthier

QuoteMy first idea was defining the constraints by some kind of regular expressions.
As far as I know, the current constraint system is already equivalent to regular expressions.

BNF are really elegant. I learned them in a course about languages and compilators so I like them, but it would of course be difficult for most players to use ... if it's presented in such computer-science-ish terms. On the other hand, most of the time, such expressions stand for a quite intuitive reality. Seeing what convoys work and what convoys don't, players can easily understand what they have to do.
Finally, I applause to this idea, it's powerful, intuitive and awesomely elegant !

prissi

The current system (xref_reader_t) with automagically resolving such references on load time is completely unsuitable for any of these requests. It would mean a complete rewrite of the system and quite some change to the handling of pak files.

I invite anybody looking at this not very easy to follow code. But until somebody start programming this him/herself, it is unlikely to be realised by me at last.

Mariculous

Well in the German Forum Prissi said, the current system would be completely incompatible to regular expressions or the BNF way, so I guess it really would be much work needed to implement it that way.

About the difficulties of the BNF, I can just say that it's for sure not totally easy to understand but however, in pak128 I do just see pretty easy constraints that would be translated to BNF something like
DUCK_CARS:=DUCK_CARS DuckCar | DUCK_CARS DuckMail
SOME_DUCK:=DuckHead DUCK_CARS DuckTail
so it's also simple and at least imho even easier than telling each of these 4 what's next and what's before it.

@Vladki that would work I guess. However, it will be a bit confusing for the pak creator, because he doesn't immediately see which of these prev/next constraints are actually cars and so they are "or" connected and which ones are features, so they are "or" connected.

To clearly point this out to the person who's working at the .dat files, it could be better do define these features and requirements as another variable for example in the dat:

name=steam_loco
technical data...
constraints...
provides=steam_heating
provides=automatic_doors

name=luxus_train_car
technical data...
constraints...
requires=steam_heating
requires=automatic_doors
requires=dining_car

name=luxus_train_car
technical data...
constraints...
requires=steam_heating
requires=automatic_doors
provides=dining_car

However, I started thinking about coupled trains like the ICE2. The game doesn't know that these should be 2 different trains, that do need one dining car, one power car and one power head each, so we would also need something like a provides=_clear_ keyword to tell the game engine, that we don't care about what the left side of this car provides, if we need a feature on the right side of it and vice versa.

But I must admit, that system would be easier to implement than the BNF solution.

@Prissi or the other devs: would it be possible to remove the requirements for these indices for the prev and next constraints?

jamespetts

Quote from: prissi on November 21, 2016, 09:22:11 PM
The current system (xref_reader_t) with automagically resolving such references on load time is completely unsuitable for any of these requests. It would mean a complete rewrite of the system and quite some change to the handling of pak files.

I invite anybody looking at this not very easy to follow code. But until somebody start programming this him/herself, it is unlikely to be realised by me at last.

There is possibly an easier way of doing this that would not require rewriting the rather complex xref system, although may not be as powerful as has been suggested; that would be to use a system based closely on Experimental's way constraint system on top of the existing xref system without altering what is already there.

One might then have something like this in the .dat files:


# Individual vehicle constraints - current system
constraint[next][0]=br-class-101-driving-motor-rear
constraint[next][1]=br-class-101-centre-trailer

# Constraint classes - new system
constraint_class[prev][0]=5
constraint_class[prev][1]=7


And in the translation text:


constraint_class_5
Screw coupling
constraint_class_7
Vacuum brakes


Indeed, one could re-use a lot of the way constraint code for this.
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.

Mariculous

Why exactly do we need these numeric indices in the constraints? I mean it's always just 0, 1, ..., n-1, n
Isn't it possible to imply these at compile time of the .dat files? Makeobj doesn't even warn you when you use the same index twice. It's pretty annoying to compile everything, start the game and notice that you can't compose the train as you want it to be because you just missed to increase one of these <insert evil word here> indices.
I added a tiny dat file preprocessor to my little java build-tool that can do the work for me but this feature is more a rage moment feature than a stable and solid solution, it's slow and I don't even use it by myself anymore because I'm not sure if it could destroy my .dat files if the tool terminates in an unusual way. It would be nicer if makeobj could do this for us.

jamespetts

We are perhaps now getting into more general makeobj suggestions? If this were implemented, great care would have to be taken to preserve compatibility with existing .dat files.
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.

Mariculous

@jamepetts You are totally right it doesn't belong to this thread so I just created a new one for this request. You can find it here: http://forum.simutrans.com/index.php?topic=15875

Vladki

@freahk: I originally wanted to propose something like provides/requires but it was too late in the evening and my head was about to explode, when thinking more about the details. It seems to be simple as long as only features provided by engine and required by all other cars are considered. (like breaking, heating, doors)
I gets quite bad with control cars, but they are really relevant only for experimental.

For multiple units like ICE2, TGV or Pendolino is using current constraint system IMHO sufficient.

Mariculous

QuoteFor multiple units like ICE2, TGV or Pendolino is using current constraint system IMHO sufficient.
It is as long as you just want to to say "This is my multiple unit, it starts with a power head and ends with a cab car, in between these are some cars"
If you want to say something like
"My multiple unit starts with a power head or a cab car and ends with a power car, if there was a cab car at the front, otherwise it ends with a cab car. In between of these there are some mail and passenger cars, compose these as you want as long as there's also a dining car in the composition."

In fact these scenarios are what I was thinking about when talking about MUs. You can define this scenario using the current constraint system but you will need at least 14(!) different cars to define this!
It's even worse if you want to go for even more realism and want to add "Oh i nearly forgot, for sure (exactly!) 2 of these MUs can be coupled to create a larger MU."

This scenario is obviously also possible using the current constraint system, in fact each scenario you can think of that works  results in a train with a finite length is possible using the current constraint system.
However, for some scenarios, well it's really the worst case, we will need to define (m^n) - 1 cars, where m is the number of different cars, wen ignoring the constraint differences, and n is the maximum train length. As I said, It's totally the worst case, but knowing this we should really look for some other ways to define scenarios like the ICE scenario without repeating us many times.

Back to the ICE2 example, it's still far away from the worst case, but we already need at least 28 cars to define this.
If you look at these 28 cars without the constraints, you will notice that these are just 7 different cars.

So why shouldn't we just say "An ICE2 half-train is a train start starts and ends with some kind of start/end car and has any number of mail-, passenger- and dining cars in any combination in between." That's the part of the definition that will be handled by the constraints. We continue to say "and it also needs exactly one power car, one dining car and one cab car in a composition." That's handled by the requires/provides system. The Power Head gets the requirements "cabCar" and "Dining Car" and provides "PowerCar". The CabCar gets the requirements "PowerHead" and provides "CabCar" and the diningCar just provides "DiningCar"
The user interface would tell the user in red or green colored font the requirements of the currently built train.
When we want to continue "and we can couple 2 of these ICE2 to a long train", it will be a bit tricky to define this by using the current constraint system combined with requirements but it is possible and we also need to define much less cars than we would have to without requirements.
We would just alter our definition of what an ICE2 is to "An ICE 2 is a train that starts with an ICE2 half train, that we defined above and can be combined with another half train"
In constraints this would mean we tell the last car of the first half train that there can follow a PowerHead2 or a CabCar2. Notice, that these differ in requirements and prev constraints to the powerHead/CabCar defined for the half train.
Now we continue again "and for sure that half same has the same requirements as the first half train"
That's why we also have to define a DiningCar2, that provides diningCar2, the trailing CabCar2, wich requires PowerCar2 and provides CabCar2 and PowerHead2 which provides PowerHead2 and requires CabCar2. Our Leading Power-/CabCar2 for sure provides PowerCar2/CabCar2 and requires the other one and DiningCar2.

That seems a bit ugly and imho it IS ugly, however it would work and we would only need to define 12 instead of 28 cars.

Why the hell should we enforce these things for MUs? (not only MUs to be exact) Well enforcing an ICE2 to have a power Car, a cabCar and a Dining car has 2 reasons: the 1st reason is obvious: If I create some graphics, I want to see these in-game. The other one is balancing. Most players will always try to build the most profitable train. That's fine but in fact in Simutrans (not ST-ex) there is no gain for dining cars so these aren't used. Because they aren't used anyways you will increase the cost of the other cars to keep the balancing. When you did that really no one will use your dining cars ever again.
Allowing the player to also compose triple, quad or whatever tractions can, depending on which values are uses for balancing, also break the balancing.
Balancing most times works by defining a train load that is needed for the train to be profitable. Someone could (and I do) raise this load for trains that have a superior capacity. So if we wouldn't force the train to single or double traction we would consequently have to increase its km cost per seat.


That being said, I think the provides/requires system is a nice compromise to the in fact much more flexible but also much harder to implement BNF way.
Since sometimes even with this system we will have to repeat cars and for some other reasons like editing the constraints or rebalancing closed source objects, it would be nice if we could use this feature and also split the dat-file into the 3 mentioned parts (graphical, technical and compositional part)

Ves

Although I agree that an improvement to the flexibility of the vehicle constraints is very welcome, I think that it easy gets quite overcomplicated. Creating DMU's myself, I know some of the struggles and the need to define the 'same' vehicle over again in order to constrain the length of the train or allow/force certain features.

I like the approach that James suggested:
# Individual vehicle constraints - current system
constraint[next][0]=br-class-101-driving-motor-rear
constraint[next][1]=br-class-101-centre-trailer

# Constraint classes - new system
constraint_class[prev][0]=5
constraint_class[prev][1]=7

which would fix the issue that an ICE train only can have ICE cars. All cars except the cab car should as well have defined "constraint[next][0]=any" in order to force another car (with the required constraint class) behind it.

Possibility adding this to it (as also was suggested earlier):


# a vehicle requiring a restaurant car to exist somewhere in the train
constraint_class[any][0]=6

# a vehicle which IS a restaurant car
is_constraint_class=6

Translation:

constraint_class_6
Restaruant

Which would mean that if any of the cars in a train has that limitating constraint, it wont be able to leave the depot unless you also have coupled a vehicle with the "is_constraint=6" in its datfile.

This would solve the issue to force a restaurant car *somewhere* in the players consist. It would also allow one to have for example "heater cars" (a car that heated the heating in the other cars. It came not always from the locomotive). For Experimental, one could even make a desired constraint type, ie in regards to heating. No heater car, lower comfort due to colder cars. A car in the consist that does not have vaccum brake equipment? All vacuum brake cars looses their braking capabilities.

However, I have no idea how to force a length to a train other than something like

max_length=
min_length=

A vehicle will not show up in the depot when building a train and their maximum length value of cars is reached. Only the higest value "min_length" and the lowest value "max_length" of any car in a consist would be considered when trying to send the train out of depot. However, it might be overkill and maybe a bit clumpsy?

But with these extra definitions in a vehicle dat-files, I cannot think of a scenario where you would need to define the same car over and over again.

Ters

I don't know of any situation where a specific train length is mandatory that isn't enforced by the power to weight ratio, length of platforms and passing loops, or the need for vehicles to come in one specific sequence.

And since these requests already go into very specific details of train operations (some of which I suspect 90%+ never think about): I usually move vehicles between depots by driving them around, so I like to have the ability to hook any marginally compatible vehicle together, even it the special adapters might realistically force a slower speed than normal. A decades old Rc2 locomotive can pull a modern FLIRT EMU (see pictures on 14th and 15th row). Some parts are more difficult to pull by themselves, though.

Mariculous

@Ves If I understand you right, we are talking about the same thing.
constraint_class[prev], constraint_class[next], is_constraint_class only differs slightly from requires/provides
The "requires" attribute I suggested doesn't care about the direction (prev/next) where a feature is needed. Most times this is the desired behavior I think, because you don't want to say "my MU (or any train) always has a cab car in the back" or "the heating of my car always has to come from the front".
is_constraint_class is exactly the same as provides. Note that one car should be able to also provide multiple features so you don't have to create features (you called these constraint classes) so you don't have to create features like "diningAndHeating" For electric trains those cars do exist and there do also exist  cars that only provide one of these.
So I will continue talking about features, provides and requires, meaning the exactly same as the words you used, but these words are imho more intuitive to understand.

If you think the prev/next is needed for some reasons, we should think about creating something like provides[ left], provides[ right], provides[ any]. I took left/right because it's also more intuitive in this case imho. Because prev/next is used in constraints to say that something (in that case an exact car) is needed directly before/after that car. If we use another word, we do tell the reader that it behaves differently.

QuoteBut with these extra definitions in a vehicle dat-files, I cannot think of a scenario where you would need to define the same car over and over again.
I can, just take the ICE example from my previous post. I still had to define the diningCar, powerHead and CabCar twice and max_length wouldn't change anything to it.
The length is, and IMHO nearly always should be, limited by the power of a train.
If someone wants to build an over-length train to operate it on lower speed tracks, it's just fine. Surely it would be better to provide the player a real alternative but many pak sets don't have that much graphical content so players have to use these compromises especially for intercity mail in pak128.

Maybe some feature clearing mechanism would be also nice, however I didn't think much about it yet. Anyways, the idea of feature clearing is to reduce car repetitions even further. That way we could say something like
PowerHead<-
provide[ right]=PowerHead
require[ right]=DiningCar, CabCar
clear[ prev]=DiningCar, CabCar

To tell the game that we only want single traction or double traction without repeating ourselves we would need something like max_amount so we can tell the powerCar and CabCar that their max_amount is 2.
That would be useful however it could be a bit of an overkill and also we would have to attach this max_amount to the feature instead of attaching it to the car because there are MUs that can be coupled with other, different MUs. A real life Example would be the TGVs. Nearly any type of TGV can be coupled with nearly any other type of TGV.
As I said, this could be kind of an overkill but it would be also useful in some, indeed pretty specific, situations.

Anyways if we had these features, we would just need 7 cars to define an ICE2 full train. The ICE2 for sure is just an example.
Btw. If we had this attribute, we could also define all of our MUs in a way so that these can be pulled by a normal loco. In fact, as Ters also mentioned, this is also in reality possible but at least in Germany only used in emergency cases or for delivery drives.

Ves

Quote from: Ters on November 23, 2016, 07:01:16 AM
I don't know of any situation where a specific train length is mandatory that isn't enforced by the power to weight ratio, length of platforms and passing loops, or the need for vehicles to come in one specific sequence.

And since these requests already go into very specific details of train operations (some of which I suspect 90%+ never think about): I usually move vehicles between depots by driving them around, so I like to have the ability to hook any marginally compatible vehicle together, even it the special adapters might realistically force a slower speed than normal. A decades old Rc2 locomotive can pull a modern FLIRT EMU (see pictures on 14th and 15th row). Some parts are more difficult to pull by themselves, though.
When each car of the dmu has its own traction the power to weight rate gets a boost.
Cool picture with the Rc pulling the flirt! I saw some pictures from Sweden where a Rc pulled a dmu (Regina, I think), but that was with special equipment and a special situation.

Freakh, yes it's basically similar as your suggestion just released, however, I still don't understand how you need two of those cars?

Ters

Quote from: Ves on November 23, 2016, 12:24:13 PM
When each car of the dmu has its own traction the power to weight rate gets a boost.

Yes, but then you can build insanely long trains, as long as your infrastructure is up to it. Maybe there are some limitations in how many motors the control unit can control, but it is not unreasonable that this can be changed if the operator wants to. Vehicles can be modified to some degree, while still being considered the same class. Other practical limitations probably kick in in Simutrans as in real life.

Quote from: Ves on November 23, 2016, 12:24:13 PM
Cool picture with the Rc pulling the flirt! I saw some pictures from Sweden where a Rc pulled a dmu (Regina, I think), but that was with special equipment and a special situation.

Well, this wasn't a normal situation, and special equipment was needed. But it was an example of what I was writing about: moving equipment around. Every FLIRT delivered to Norway has arrived in that way. There is also at least one case of a DMU with passengers being pulled by a diesel locomotive on purpose. It had driven by itself from Denmark through Sweden, but lacked the proper ATC equipment to run alone in its former home country. (The locomotive is also a museum piece, but one which has the ATC equipment, since it hadn't emigrated.) No special equipment required in this case, since the DMU has standard screw couplers. Norwegian MUs sometimes (often?) pulled a normal freight car back in the 20th century. The very early ones where even often partially made up of converted passenger cars.

Vladki

I would prefer to not make things over complicated and to give players some freedom. We discussed emus in expetimental forum recently. Imho for ice2 should be fine to have duplicated only for power and cab cars (heading front and back) and let the player freely combine coaches inside (1st/2nd class, dining, mail). Comfort and catering is taken care of in experimental. And player may want to make long unit with power on both ends, or put cabs on both and have something that cannot move at all... :p


Mariculous

QuoteFreakh, yes it's basically similar as your suggestion just released, however, I still don't understand how you need two of those cars?
I would need to define these twice because otherwise there could be 3 power heads and only one cabCar and one diningCar in an ICE2 composition, since the second powerHead requires diningCar which is already provided by the diningCar in the first half-train.
That would lead to a train length of 24 cars that only need one diningCar and one cabCar. Since I do calculate the balancing of a train with one dining car and one cabCar for each power head it's obvious it will break the balancing.
Another point is that I want to say that two half trains can be composed to a full train, so I need to tell the powerHead or cab car at the front of the train that there can't be anything in front of it. Also, we have to tell the powerHead/cabCar at the end of the first half train that there can follow the front of another half train or nothing.

Sure we could say two half trains can only be coupled at their cabCars, wich is a compromise that at least doesn't affect the balancing.
That way we wouldn't have to define the cab car and power head twice for each direction but we would still have to define the dining car twice.
In fact, when defining a MU I would take this compromise if I had to choose between that compromise or defining 2 more power heads and cabCars. But as always, it's nicer if you don't have to take a compromise.


@Vladki
Note: I'm not talking about Simutrans-ex where things like comfort and catering give you nice tools to balance 1st class- and dining cars.
Im Simutrans (without ex) there is simply no way to make dining cars attractive to the player without making normal cars unattractive for specific use cases.
There are only 3 numbers that
For example if you decrease the seat costs per kilometer of a dining Car, players still won't use these on high capacity lines because the dining cars do have a much to low capacity but they will use trains with only dining cars on lines that don't require a high capacity.

I had another idea how we could make that system a bit more powerful without making things too complicated:
Instead of just saying that some car provides (is a constraint class) or requires (needs a constraint class) something we could say how many of these it can provide and how many it needs.

Back to the heating example, in germany there were diesel locomotives that had enough power to pull a passenger train with a secific amount of cars. However, their heating didn't have enough power to heat that many cars so these were used in double traction for thse trains.
Talking .dat-ish it would mean something like:
provides=7 heating
And for each car it would be something like
requires=1 heating

We could also define something like the example of ters by just telling the control car provides=8 motorController and telling the powered cars soemthing like requires=2 motorController

Back to the ICE2 I could just tell each power head:
requires=1 cabCar, 1 diningCar
these would just provide 1 diningCar / cabCar each.
the only problem left would be limiting that train to 2 half trains.
One could do some hacky dummy car that has to be coupled in front of every train that can be used in double traction that would provide 2 trainController.
Power Heads would require one trainController each.

Such a system would be pretty powerful, we could just tell the user how many cars that need a specific feature can still be added, or the other way round, how many of these features he has to provide until his train can leave the depot, so it would be easy to understand and it wouldn't be too much coding effort I guess.
I guess currently it's about checking if a feature is provided and for that feature we would have to increase a counter for each provide and decrease it for each require by the given values and check if this counter is greater or equal to 0.

Quoteor put cabs on both and have something that cannot move at all... :p
sure it can if it's coupled with another half train that contains at least one power head, however this combination wouldn't be a problem for me since it would affect the balancing only in a way so that the train won't be profitable.
Maybe I'll even allow 2 power heads in a train but to do so I need some tools to enforce another expensive car into the composition to keep the train balanced.

Currently I don't have these, so the first ICE2 I saw on my Server was a 12 units (24 cars) long train with 3 power heads, one cabCar and 2 diningCars, being ugly, having a cost/(seat*kilometer) value that was 3 percent below the balanced value and a seat/length number that was 5% above the balanced value. These players sometimes drive me mad.
I rebalanced that train a bit so there's only a difference of 0,8% for the cost/seatkilometer value and 1% for the seat/length value. However, if I would put even more seats to the cab car, I do already see ICE 2 compositions with 5 cab cars, 5 dining cars, 3 power heads and 11 noramal cars on not too higly frequented lines in my mind.

That's the reason why I'm trying to find a more flexible solution than the current constraint system that should still be easy to use fur the player.

Vladki

To enforce dining car etc. in simutrans standard, you can make the constraints like this: front power/cab has to be followed by 1st class coach, then dining, and then any mumber of 2nd class coaches and a rear cab/power. To add more reality rear cab can connect only to another front cab, rear power must be last.
Add a mail coach anywhere you like. This is all easily achievable with current constraints.

Mariculous

@Vladki yor first statement is totally right but I don't see the point of it. That's a different scenario. That way we could also create a train that has a power Head on the front and back of the train but we don't want that for balancing and, even if not that important, realistic reasons.

Note: I don't differ between 1st class and 2nd class if these don't differ optically because it doesn't give us any gameplay advantage in simutrans (non ex). However, I do like the idea of calling these cars "1st class" / "2nd class" in cases where we need to have cars to the left side of the dining car and for constraint reasons, the same car on the right side of the dining car, so we don't have to say "the passenger car that is onthe left/right side of the dininc car".
I'll just pick up this terminology but you should notice that these are, except for the constraints, the exact same cars.

Also,
QuoteTo add more reality rear cab can connect only to another front cab, rear power must be last.
simply is not true. We can take this compromise for simplicity reasons but it's not realistic.

In the current system, we do only know what the previous was and can only say what the next can be. So to limit the train to at most 2 half trains, force a dining car and allowing both half train to drive cab or power head in front, each car would have to "remember":
-if they are in the first half-train,
-if there is a power head in the front and
-if there is a diningCar in the current half-train.
The only way of "remembering" something in the current system is by duplicating a car. One of these states that there WAS already that thing in the train and the other one states that there wasn't.
So there are 2^2=4 combinations each car has to remember. Do we really need all of these for each car? For the current scenario the answer is simply yes. (ask me if you don't know why but I think it's obvious because we didn't exclude any combination.)
Since we do have 7 different cars (cab leading, cabTrailing, head leading, head trailing, 1st class mail/passenger, 2nd class mail/passenger, dining car) without the constraint, there are possibly 4*7=28 cars to define.

Let's have a look at which ones are maybe not needed:
We soon notice that a trailing 1st class head/cab nor a leading 2nd class head/cab do make any sense, so we can remove these 4 cars.
We can also drop the power heads in the middle of a long-train since this is unrealistic anyways.
We do still need 22 cars to define this exact scenario. If you don't trust me, that we really need that much, just draw a DFA and minimize it or whatever and you will see this.

Because these are still pretty many cars, we wouldn't do this and instead take the compromise that there can't be anything coupled to the power cars because it doesn't change the balancing in any way.
When doing so, "a car is in the first half train" will be equivalent to "there is already a power head in this part of the train".
Because we know this, we do only have to "remember" one of these.
So now we have to posibly define 2*7 cars.
Again we can drop the cab/head that don't make any sense.

Now we do just need to define 12 cars. Same arguments as above, fewer is not possible for this exact scenario.

Dropping even more requirements would affect the balancing of the train. Creating over-length trains is not a problem since it can be balanced in a way so that these do need the same or a little bit higher utilization to be profitable.

When taking that compromise, we do still need to define some cars multiple times. Because it's harder to maintain and our depot will be messed up, it's a compromise.

All I say is that we should look for an improvement of the current constraint system so we can take fewer compromises.
Balancing is already hard enough so it would be pretty nice if we would not think think that much about if a specific constraint will break the balancing in any case or not.
Furthermore, having unnecessary cars does also lead to repetitions when adjusting the balancing.


That being said, I'd like to see more ideas about how this can be done.

Vladki

If balancing is your main target, do the balancing so that a train composed only of 2nd class coaches is reasonably profitable. Even if non existent in real world (too long, no dining, power on both ends) but still plausibe in simulation. Leave the dining or other special cars optional for those who like to model reality, and balance it so that it is still profitable, but not a cash cow.

In one of my games I tried to keep the train units as much as in real world until I ran in capacity issues and replaced all dining cars with normal coaches as I could not make longer trains (12 tiles).

Mariculous

Yeah that's another compromise...
On a 4k*4k multiplayer map (yes, connecting takes a while) with already over 2 milion inhabitants there wouldn't be any dining cars because high capacity is needed.
In fact, I didn't enforce dining cars on the previous map, so nobody used these.

I wasn't pretty happy about this situation because especially haru and Gauthier spent some time for so many pretty dining cars that just weren't used by anyone.

Anyways, this thread isn't about balancing. It's just about constraint improvements and I gave some examples of what is  currently possible and gave some examples of what I would like to define without spamming cars to the depot.

There were also wishes by other users that could be simplified by improving the constraint system (e.g. heating or automatic doors feature)

I do still think we should try to reduce the amount of compromises needed when using constraints.

Ters

Quote from: Freahk on November 25, 2016, 01:03:30 AM
I wasn't pretty happy about this situation because especially haru and Gauthier spent some time for so many pretty dining cars that just weren't used by anyone.

How do you know? There are broadly two types of Simutrans players: the model railroad players and the tycoons. Dining cars are for, and probably by, the former group. Apart for the screenshot boards, it is hard to know what that group is up to. The tycoon group is more likely to engage in multiplayer games, which gives others a fuller view into what they are up to.

Quote from: Freahk on November 25, 2016, 01:03:30 AM
Anyways, this thread isn't about balancing. It's just about constraint improvements [...]

Changing the constraints system does involve balancing in one way or the other. Even if it is just because the current balancing makes vehicles with the new constraints useless, as they will be inferior to existing non-constrained vehicles. Then things start morphing into a compatibility concern.

For me, point number 2, and by extension point number 1 for symmetry, are the most interesting ones, but only if properly applied to already existing vehicles. As I play pak64, it would be almost impossible to see the difference between various sub-types (1st class, 2nd class, dining) within a class of passenger cars. I only miss the ability to multi-head trains, since all locomotives must be the first one, which I believe is to avoid any other kind of vehicles first.

Leartin

Freahk, your problems are not within the constraints system, but with the economic system of Simutrans.

The constraints system right now is simple, to have some basic control. One could argue it's just what kind of coupling is used, very simplified.

Vladkis request is essentially about technical restrictions -  you cannot have a train with no brakes, you can not have automatic doors with electric control carried by a steam locomotive that does not even supply electricity, etc. Since they are technical restrictions, they (usually) make sense to players, if they are told what it is about.

But what exactly restricts an ICE from being only second class cars? Why does a dining car need to exist? It is not a technical nessecity, the trains would function either way. Railway companies do it because they gain profit from doing it. If there was no first class and dining car, people might use a different means of transportation, or simply trains by another railway company. In reality, people always have a choice not to take a train - something not depicted too well in Simutrans. And of course there might be some extra money from selling foods.

Simutrans-Players usually do the same any railway company would do: Since dining cars don't do anything, they are simply ignored.


IMHO forcing the player to use inferior cars in his train composition in this manner is not the way to go. It's fine with the current constraints, because placing the dining car in this case is much like placing the 'useless' tender, if you even have to do it manually. It's a different story if there is a functionally complete train, with front car, heck car, some car to take electricity inbetween - and the game tells you it is not complete. It probably could not tell you exactly what's wrong, and even if it says "requires dining car", you can't add it - you remove the end car and... still can't add it, because dining cars don't go at the end for some reason. I wouldn't know.

And there is a pretty obvious solution for now: Make all cars functionally identical. Since Simutrans does not know the difference between first class, second class and dining cars, just don't make a difference either. Sure, a player who wouldn't care about this kind of realism wouldn't use them, or would even create a train with dining cars only, but those are the players who would first uninstall your trains if you force them to use specific conveys for no good reason. However, players who do care about realism and graphics can use them with no downside.

Using that route, you could ask for two additional game function -
different graphics for the same car, kind of like liveries, that the player has to choose manually
different graphics for the same car based on the position in the train. Thus, the player just picks the kind of train he wants and how many carts, but the first car will look like first class, the second like dining car, and if the train is long enough, two of the middle cars could even change their graphics to end cars. Beauty even for those who don't want it.

The more obvious route, of course, is adding comfort in some kind of way, to actually have classes and dining cars count for something. In that case, nothing would stop the player to scrap first class and dining cars, but with the right balancing, it just wouldn't be the most profitable way.


If you want the player to have freedoms, let them have the freedom to make bad choices.
If you want the player to be restricted to compositions you like, don't let them arrange trains in the first place, just force the full train composition.

Ters

There is the fundamental question: What are constraints for in Simutrans?

I think they are primarily there for articulation. By this I mean that what is in practice a single vehicle, has been divided up into several "pieces" so that the can articulate more realistically around corners. A typical example would be a Garratt locomotive. These have very strict constraints. For any given vehicle (part), there is only one possible next until you have all pieces in place. Some MUs and trams are similar.

Tender locomotives are similar, but now things get more fuzzy. A tender locomotive must have a tender, and as far as I know, it is always next to the locomotive. And tenders do not appear by themselves elsewhere in the train. However, a particular class of locomotive does not necessarily require a particular class of tender. Simutrans is not really capable of modelling this last part when third party add-ons are thrown into the mix. (Tenderless tender locomotives and locomotiveless tenders can probably be encountered in transport, but I think they often use special couplings, so they will then likely be at the end of the train, or on flatcars. This might be too much of a special case.)

This is what I consider to be the absolute rules. The game must enforce this.

As far as I'm aware, there is only one other rule, or rather set of rules, that is absolute within the real world (well, it wasn't in the very early years of railroads): brakes. If the locomotive doesn't support continuous brakes, or even the right type of continuous brakes, then the train must have other means of braking. Such a locomotive can only pull trains which have other means of providing braking power.

Different couplers cause problems connecting vehicles, but it can be overcome. And it is certainly within the freedoms of a railroad company to modify a vehicle to carry a different coupler, or even multiple. Likewise, it is not impossible for a railroad company to put a flatcar in the middle of a TGV train if they really want to, with some relatively minor modifications, although unless it carries something with a profile matching the rest of the train, the top speed will probably be affected by the inferior aerodynamics.

prissi

On pak64 engine which can be multiheaded with itself:
1Diesellokomotive
2Diesellokomotive
3Diesellokomotive
SD40
1Ellok
BB1280
Be5-7
Eb3-5
Ed2x2

Those can go to any place in a consist:
Br118DR
BRV36
Br234
JNR_C11
NS1600
1Ben140
3Ben185

Mariculous

QuoteHow do you know? There are broadly two types of Simutrans players: the model railroad players and the tycoons.
How do I know? Well I can't speak for the whole world but at least for my first multiplayer map which used the original pak128 without any changes or add-ons there wasn't a single dining car on the whole map.
Basically this is right. Imho most players are somewhere in between of being tycoons or model railroad players. At least at my tiny multiplayer.
In addition there is also the Fetz123 group of players that wants everything to be symmetric. Somethimes this could drive me mad :D
Because of exactly that reason I started thinking about what I had to to to get trains that can be built symmetrically and do generate its best profits in a realistic setup without restricting train setups too much so trains can be composed differently for different needs.
I know this is nearly impossible but I'm trying to get as close as possible to this point.
I tried out some different approaches and, as expected, none of these worked as I wanted for different reasons.
I must admit enforcing an inferiour car maybe is not the way to go but that way worked best for now but I'm still tying out new ideas, also playing with fixed_costs and so on.
For the next multiplayer map I'll try out to remove the dining car requirement and instead will slightly reduce its costs per Passenger-distance compared to normal cars. Since I already know that way there would be ugly, unrealistic and inballanced ding car only trains on lines where high capacity isn't needed, I will have to limit the amount of dining cars in a train.

For the next multiplayer map I'll try out to remove the dining car requirement and instead will slightly reduce its costs per Passenger-distance compared to normal cars. Since I already know that way the would be ugly, unrealistic and inballanced ding car only trains on lines where high capacity isn't needed, I will have to limit the amount of dining cars in a train.
At this point I do again hit the limits of the limits of the current constraint system so I will again drop the symmetry and some visual variety like rotated trains (cab car front).
Anyways these would be much easier if the constraint system would be a bit more powerful.
Surely some system of comfort would be even nicer but I don't think this would come for simutrans non ex since this would change the balancing really much!
For the current system without something like comfort the only way to get some variety is creating some cars in a way so that they are well for low capacity routes (low capacity per length but also inexpensive)
and creating other cars that work well for higher capacity lines (high capacity per length but also expensive). This does give some variety of trains being used for different lines but it won't give any variety for different cars in a single train because there is no reason for adding lower capacity cars to hig capacity trains or vice versa.

@Leartin I don't really see the differences between technical or service features.
Sure I know the real world difference of these but a system that can describe technical requirements well can also describe service requirements well and vice versa. But I will use examples that do have technical requirements in the future if you want.

QuoteChanging the constraints system does involve balancing in one way or the other.
Indeed it can affect the balancing but it doesn't necessarily have to. As long as the new system isn't used at all by a pak set it won't change anything anyways so implementing this feature won't break any pak balancings. If some pak devs don't want that feature or don't have time to change the existing vehicles to use that feature they can just ignore it and everything for this pak would be the same as it was before.
For pak128 where constraints are pretty simple it could for example help increasing the visual variety by allowing to build MUs cab car first without affecting the balancing.


QuoteLikewise, it is not impossible for a railroad company to put a flatcar in the middle of a TGV train if they really want to, with some relatively minor modifications, although unless it carries something with a profile matching the rest of the train, the top speed will probably be affected by the inferior aerodynamics.
So we should drop constraints (describing the coupling) completely and instead just describe needed and provided features so a train can technically drive? Well nice idea but there would be really many balancing changes and obviously constraint changes needed for a pak to use it that way. However, currently this is simply not possible without maintaining a giant list of thousands of constraints. We could just drop all constraints without caring about technical requirements but that wouldn't make any sense.


I thought about the 3rd point of the request especially about this:
QuoteSimulating cabling for control cars would be more difficult, and more specific to experimental. I have some ideas, but I have to sort them out for myself first.
This is something that can be done using the constraint system so you can only couple cars in between a cab car and a loco that do have such a cabling so I didn't really understand the problem of that cab car cabling first.

However since we said now "nearly everything can be coupled with everything if company really wants this" I do see the problem now: We could couple for example a cargo car in between these passenger cars so there wouldn't be such a cabling.

We could in addition to requiring and providing features by these "constraintgroups" also forward features.
If our car forwards a feature this means our car will provide this feature to cars directly next to it if the car on the other side of our car provides it. Otherwise it won't provide it.

So for a train with a control car in the front we would have to check if there is a loco somewhere that listens to this control car. We could do it that way:

controlCar:
requires=controlCarListener

passengerCar:
forwards=controlCarListener

universalLoco:
provides=controlCarListener
provides=airBrake

cargoCar:
forwards=airBrake
requires=airBrake


That way we couldn't use the cargo car in a passenger train with leading control car because the control car can't comminicate to the loco.

As i already mentioned, if it's not much more work it would be nice if we could define how many of these features can be provided/are required.
That would make things easier.
I won't provide another example so this post doesn't explode again and no one can say that it is already possible by providing a completely different scenario.

Vladki

Well it seems that we are getting close to the same ideas. I also thought about features like provides/requires/forwards. The problem with control cars (and some other features) is that you can connect them even if the cars in between do not forward the control, you just lose the capability to reverse quickly (in simutrans-ex). There are also wireless control cars, but you cannot control just any engine with them. (But it does not matter what cars you put in between.) Similarly lack of heating might reduce comfort ... But this is going too far.

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.

Leartin

Quote@Leartin I don't really see the differences between technical or service features.

The difference is that players can rather easily see why a train would require technical features, but not why it needs service features. For example, it's really simple for players to figure out why a train wouldn't move if there is no locomotive, or why a tender needs to be there. Not true for sercive features which are optional.

Your whole ICE2-concept is flawed, because you want to require players to do what you would like to see, pretty much arbitrarily.
Worst case: A player builds an ICE2 with too many cars (including a dining car) and tries to solve the problem by adding another power car and control car. According to your rules, that's perfectly fine, as long as they put a dining car in there as well. Now please explain that player why he is not required to balance all cars between the two half-trains, but is required to use a dining car... And no, more rules are not the solution, because every rule you add makes it stranger for the player if his convoy, that's technically perfectly capable of getting out of the station, does not move.

In reality, ICE2 have only one available composition, consisting of 8 cars. If you want to restrict the player for realism reasons, this should be the only possible combination.
For more diverse gameplay, you can simply change how many of each car have to be in the convoy. You can reduce down to 5 unique cars and still require first class, dining car and second class. Thus, trains stay somewhat realistic.
I'm sure nothing stops a real ICE2 from having 3 dining cars and 4 first class cars if somebody was hellbent on creating such a train. If the same crazy person puts power cars on both ends, well... make sure they don't run in opposite directions? Other than that, and beside being pointless/ugly, it's probably not too problematic. Same goes for a train with two control cars, though it would be a sitting duck. Could be carried by another ICE though.

What you want is somewhere between these. Because you want to decide for the player which compositions are acceptable and which are not, based on grounds of what you like. Even if it becomes possible, it's a terrible thing to do to players, and will end in a lot of unnessecary frustration for them.

Now, things like automatic doors and heating are pretty much the same - a convenience that can't be properly depicted by the game. IF a comfort level would exist, like in EX, one could use these constraint requirement ideas not for having the train work or not, but for actually getting the bonus on comfort these conveniences would provide. (broken air conditioning never stopped an ICE from running, after all...)


Improved constraint features that are really useful, in my mind, would be to make vehicles belong to one or more groups, and the option to restrict to that group rather than a specific vehicle. Eg. the Adler locomotive, rather than specifying its three possible wagons, would just constrain next to the "Adler"-group, which it would belong to itself. Then, each wagon would do the same, but with previous as well. Now, if someone created an additional wagon for the Adler, even if it's fantastic and never existed in reality, they only need to name the group. Nobody needs to go back to all existing vehicles and change the constraints for the new one to work.

Ters

Quote from: Leartin on November 26, 2016, 02:36:05 PM
Improved constraint features that are really useful, in my mind, would be to make vehicles belong to one or more groups, and the option to restrict to that group rather than a specific vehicle. Eg. the Adler locomotive, rather than specifying its three possible wagons, would just constrain next to the "Adler"-group, which it would belong to itself. Then, each wagon would do the same, but with previous as well. Now, if someone created an additional wagon for the Adler, even if it's fantastic and never existed in reality, they only need to name the group. Nobody needs to go back to all existing vehicles and change the constraints for the new one to work.

I'm thinking along the similar lines. What I am thinking is that the constraints should be based on the interface between the vehicles rather than the actual vehicles. This is particularly useful for semi-trailer add-ons.

Then there is the other issue of how the balance of power should be between pak author and player. I'm leaning towards giving most to the player, since real life vehicle constraints are not constant. As an example, I like to present the SJ Dm. Originally delivered in the 1950s, it consisted of two locomotives connected back-to-back using a special coupling and with screw couplers at the front. NSB ordered similar locomotives which it called El 12. At this time, the locomotives could in theory pull every other standard gauge car in both countries, although I doubt they could provide steam heating to passengers cars requiring that.

At some point, however, the ore trains they were built to pull switched from screw coupler to knuckle couplers, so the locomotives got their screw couplers replaced with knuckle couplers as well (buffers were retained). From that point onwards, the locomotives could suddenly pull cars it could not pull before. Whether it no longer could pull screw coupled cars is unknown to me. They retained their buffers, and combining a knuckle coupler with screw coupler is not unheard of. If this development is to be enforced by the pak author, I see no other option than to have two sets of SJ Dm-vehicles: one with screw couplers and one with knuckle couplers, with the former being retired at the same time the latter is introduced.

However, the same weight issues that caused the switch of couplers also required more pulling power (not sure which happened first). SJ ordered new cabless units that were inserted between the two pre-existing units. This is doable with the current constraint system in Simutrans. With an interface/coupling type constraint, one might open up for multiple cabless units in between if a vehicle only supports a single interface at either end. If the pak author is to enforce just Dm+Dm or Dm+Dm3+Dm, then vehicles need to support multiple interfaces. The rear end of the front Dm need to support A and B, while the Dm3 supports B at the front and C at the read and the read Dm support A and C at the front. I'm not sure how Leartin's suggestion would cope with this.

NSB took a different approach. This simply split up, modified and rearranged their El 12s into triple-units. This means that an El 12 could suddenly find itself coupled with its front towards the rear of another El 12. This wasn't possible earlier. This means that there have been three different constraints for the front of an El 12, two of which are contemporary.  In addition, SJ Dm and NSB El 12 might be considered the same locomotive class. Although I don't know exactly what the differences are, I wouldn't rule out the possibility that one could connect Dm and El 12 back-to-back. I've read that their guts were both similar enough to several other Swedish locomotives that they could in theory be controlled by each other.

These locomotives are pretty much historical now, so one might figure out some way of defining constraints for all of this in Simutrans, but the same thing can also happen to existing locomotives. If the pak author doesn't keep updating the pak, then the player will suddenly find the vehicle unable to do something which now happens in real life.

Mariculous

QuoteSimilarly 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

needed features:
brake

additional comfort:
heating: 5
electricity: 20

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:

require[technical]=controlCarListener

require[comfort][0][name]=heating
require[comfort][0][value]=5

Well I'm not happy with this syntax. I think it would be better readable if we could define these as pairs like this
require[comfort]=(heating, 5)
or rhat
require[comfort][]=[heating,5]

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.

option={
  require: heating,
  #some heating power will be consumed, the remaining amount will be passed to the next car.
  amount:2,
  values: {
    comfort: +5
  }
}

option={
  require: controlCarListener,
  amount: 1,
  values: {
    #our cab car can't control any  loco if jthere is no loco listening to it.
    speed: =0
  }
}

option={
  require: electricity,
  amount: 450,
  values: {
    #our control car does have some engines so it will use these if some loco (or whoever) provided the needed electricity for these.
    power: =450
  }
}


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
option={
  values: {
    running_cost: +2
  }
}

#this is the feature itself reflecting that there won't be a conductor needed if we have automatic doors.
option={
  require: automaticDoors,
  #this means it needs an automatic door controller for this feature to work but won't "consume" that feature
  amount: 0,
  values: {
    #there won't be a conductor so the running_costs will be lower
    runninc_cost: -10
  }
}


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
For example

#increased space for each seat
option={
  values: {
    comfort: +10
    #meaning there will be 30% less seats in that car
    payload: *0,7
    runninc_cost: -10
  }
}


Or an own pantograph so it doesn't require to get the power needed for the engines from a loco.

provides={
  name: electricity,
  amount:450
}




Our cars in between this control car and the loco would need to:
forward=electricity
forward=automaticDoors
forward=heating
forward=controlCarListener
These for sure could be done by upgrading cars

A loco for this could be something like that by default (without upgrades)

provides={
  name: electricity,
  amount:1200
}
provides={
  name: controlCarListener
  amount:1
}

And there could be a passenger train upgrade for this loco like this:

provides={
  name: automaticDoors
  amount:1
}
provides={
  name: heating
  amount:10
}


And also a cargo upgrade like that:

#decrease vmax, increase gear
option={
  values: {
    speed: -20
    gear: +50
  }
}


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

option[0][require]=heating
option[0][amount]=2
option[0][values][comfort]=5

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.

QuoteHowever 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.

Ves

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