News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Constraint-Groups

Started by Leartin, May 18, 2017, 08:42:37 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Leartin

There is a thread for improved constraints, but it became very complicated fairly quickly. I'd like to pick a suggestion I made in it, since it should be a lot simpler than other stuff from that thread:

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

So, to be more clear:
Add a new parameter "Group" for vehicles, which can contain an array of strings - the groups.
Currently, the string used in Constraints means a vehicle with a name equal to that constraint string can be connected. Change this so any vehicle with a group equal to that string can be connected as well.


Something similar could be achieved with a different method:
Add a parameter "Is_hidden" to vehicles, which is boolean and off by default. If on, this vehicle will not be displayed anywhere in the game. It will not be listed in the depot, it will not be listed in a convoy info. Anywhere vehicle information could be displayed, add a check for the "is_hidden" parameter and skip the vehicle if that's on. This way, one could simply create a hidden vehicle instead of a group, and use that in constraints.
Alternatively to "Is_hidden=1", perhaps a subclass of vehicles could be used. An object=coupling which inherits everything from vehicles, but lacks cost, lenght, load, power,... but will be part of a convoy.

(obviously, this is already possible, except that it would be visible to players while it should really work in the background.)

Vladki

I support the groups constraints.

Sent from my ONEPLUS A3003 using Tapatalk


jamespetts

Simutrans-Extended uses a system of constraints for ways (way constraints) which might work also for vehicles: permissive constraints and prohibitive constraints. Each way type and each vehicle type can have up to 8 permissive, and up to 8 prohibitive constraints set. Each of them are numbered from 0 to 7 and can be translated into a specific name.

If a way has a prohibitive constraint, no vehicle other than a vehicle that has the same prohibitive constraint may pass over that way. This is used for restricted ways, e.g. very narrow tunnels such as those used by Tube trains.

If a vehicle has a permissive constraint, it can only travel on ways that have the same permissive constraint set. This is used for restricted vehicles, e.g. those that require a specific type of electrification. (Dual voltage vehicles are then made by having them defined as being electric without any permissive constraints set).

A similar system, with some adaptations, might be used for connecting vehicles. For example, if vehicle type A had prohibitive constraint 0 set, it would be able to couple only to other vehicles with prohibitive or permissive constraint 0 set. A vehicle with permissive constraint 0 set would be able to couple to any vehicle (a) without any prohibitive constraints; or (b) with prohibitive constraint 0 set. Other vehicles' permissive constraints would be ignored.

One might also want to specify alternative constraints: if vehicle type A had alternative constraints 1 and 0, vehicle type A could couple to any vehicle with a prohibitive, permissive or alternative constraint of 1, 0 or both 1 and 0, but not any vehicle that had neither.

For example, one type of railway carriage may have only vacuum brakes. Other types of railway carriage might have only air brakes. Others still may have both air and vacuum brakes. Coding the carriage with both as having an alternative constraint of both vaccum and air brakes (say constraint nos. 0 and 1) would allow it to couple to any vehicle with vacuum and/or air brakes. Through-piped goods wagons, without automatic brakes of their own, but with pipes to enable them to be connected to locomotives with vacuum or air brakes and to other wagons that have those sorts of brakes could be coded as permissive 0 and 1. Likewise, locomotives that can either be coupled to unfitted freight wagons (with no vacuum or air brake constraints) or fitted freight wagons or passenger carriages (with vacuum or air brake constraints) could have permissive constraints of types 0 and 1.
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.

Ters

I still think brakes are a poor example for constraints. Constraints are fixed, brake systems are not. Let alone other connections, like cables for electricity and remote control. I just saw a picture of a flat wagon that was upgraded with the necessary cables, and perhaps other things, required for operating together with coaches just for a few weeks in a television show this summer.

Leartin

#4
James, that's the complex kind of approach that's discussed in the other thread. Not that I wouldn't like it, but it's a total overhaul of how constraints work. In order to use it effectively, pretty much all vehicles of a pakset need to be adjusted, and due to it's complexity, I'm not sure it would be implemented in Standard even if a patch existed. The suggestion here is of much smaller scope and technically does not add new functionality, since the same could be achieved by manually typing all members of a group instead of the group. It's more about convenience.

Since the suggestions do not clash and try to achieve slightly different things, I stongly recommend to keep them seperated. Discussion about complex constraints can be found here: http://forum.simutrans.com/index.php?topic=15867


That being said, I don't think we need a cross-pakset-general-discussion about what constraints should or shouldn't be used for. It was tiresome enough in the small circle of p192c-devs, and there is no definitive answer. Having everything go with everything, to restricting wagons to only combine with their own set: It's not "better" or "more realistic", it's just a design choice, all it needs is consistency in itself.

DrSuperGood

I think the correct feature name is "aliases". For assembly constraint purposes either absolute names can be used, or alias names. The relationship is such that many different components (vehicles, name it what you want) have to have unique names but can have a common alias. This could also be expanded such that a single component type can have multiple aliases.

This terminology is used by the game StarCraft II where for requirement purposes one might need multiple different unit types to be considered as the same unit type. One gives these different unit types the same "alias" value and then use that alias in the requirements to refer to any unit using that alias.

In the given example "Adler" could be an alias given to the 3 coach types. The locomotive constraint (or whatever the field is called) would then be set to the alias "Adler". Pakset authors might want to emphisie that an alias is being used by naming them like "ALIAS_Adler" so that maintainers know immediately when an alias or actual type is being referenced.

Adding this feature to linear searches should be easy as on top of testing the component type name it also checks all aliases for a match. Backwards compatibility should be maintained by assuming empty alias lists. Mechanically alias lists could be stored as a list of strings which can be read in sequentially. The depot UI should be expanded to show alias names, useful for know how stuff will link together. Potential memory and performance optimization would be to parse unique aliases into alias identifier numbers at load time and use those internally instead of having to perform string comparisons however for a first implementation I would not recommend this (micro optimization).

Leartin

*PUSH* due to a similar idea that came up in the German Forum:
https://www.simutrans-forum.de/mybb/showthread.php?tid=8884

A parameter "traction_engine" which causes only vehicles of the same traction_engine to be able to connect. Using a restricted amount of numerical values, similar to clusters for buildings.
Thoughts? (I still think Alias are more useful)

ACarlotti

I suggested something similar, but slightly different in functionality, back in March:

Quote from: ACarlotti on March 23, 2018, 06:46:28 PMI've also noticed that there are a lot of places where large numbers of vehicles have identical coupling constraints. (E.g. groups of multiple units that can all couple with each other, or barges of a particular kind). I think it would be helpful to have a way of specifying coupling groups, so that the .dat files for a group of vehicles needn't all specify the same long list of valid couplings (which contributed to some of the broken references above, and probably has some other bugs at present as well). I think this would be best implemented as a modification to makeobj, which could be made to expand such groups into full lists.

So it seems that lots of people want this; we just haven't agreed on a precise implementation yet.

prissi

I would rather like groups, not aliases. They could be abstract, i.e. no centered around a certain vehicle. For instance one could have "Laenderbahnen" in Germany, meaning pre 1871 railways. Or a "freight" group, which requires a freight engine. (In the depot, a selection of a freight engine would show only freight cars. However, prior to the first selection all groups are show. This is different from constraits, which may hide certain vehicles).

However, this needs to be properly documented (and in case of names also translated).

Ters

Quote from: prissi on August 27, 2018, 01:23:06 PM
I would rather like groups, not aliases. They could be abstract, i.e. no centered around a certain vehicle. For instance one could have "Laenderbahnen" in Germany, meaning pre 1871 railways. Or a "freight" group, which requires a freight engine. (In the depot, a selection of a freight engine would show only freight cars. However, prior to the first selection all groups are show. This is different from constraits, which may hide certain vehicles).

However, this needs to be properly documented (and in case of names also translated).

There seems to be somewhat different things here. As far as I know, nothing technically prevents one from hooking a modern Norwegian Sggs (non-German and freight) behind a Prussian P 8 (Länderbahn and passenger). However, you can't hook a semi-trailer behind a Setra S10. (You might put an adapter in-between, but that counts as a new vehicle with new constraints.)

I think that constraint groups that allow you to say that this trailer is a semi-trailer which must be connected behind a semi-trailer truck (or dolly), without listing every such vehicle explicitly, is very useful for add-on makers and users. Currently, if players are to mix-and-match semi-trailers and truck from base pak set and add-ons, neither base pak set nor add-ons can use constraints at all, as they do not know of the other vehicles.

Not putting freight cars behind a passenger locomotive, or modern cars behind an old locomotive, is a stylistic decision, which I think should be up to players. Not putting semi-trucks behind vehicles without a fifth wheel is a technical constraint, decided by the pak author. There is a gray zone in between, such as train couplings or breaking systems, which are technical, but can be overcome with a rather minor (and mostly invisible by Simutrans standards) refit. This can be and has been done by railway companies in real-life.

Leartin

Quote from: prissi on August 27, 2018, 01:23:06 PM
I would rather like groups, not aliases. They could be abstract, i.e. no centered around a certain vehicle.
I'm not sure it's meant to be connected, but why is it aliases can't be abstract/ not centered around a certain vehicle? If the pak author would choose "laenderbahnen" as alias for his länderbahnen, you'd save the trouble to translate the thing (since it's not visible to a player anyway, and if the pak author chose a non-english term, chances are the whole pak is full of non-english object names as well)

I get that it's slightly more bothersome to get a string rather than an integer with makeobj/out of it, though it's something that needs to be done for constraints anyway. I really don't understand what the benefit of using something other than constraints for a concept so similar to constraints is supposed to be.

prissi

I think the group has to be shown. Otherwise it will be hard to understand why suddenly lots of vehicles disaapear ...

Leartin

Quote from: prissi on August 29, 2018, 06:15:22 AM
I think the group has to be shown. Otherwise it will be hard to understand why suddenly lots of vehicles disaapear ...
I'm not so sure about that. Showing the group might help understand why certain vehicles go together, if it is not appearent. But your own examples actually show what's more likely to happen:
"Freight" is a restriction obvious enough such that players will get it due to the selection of vehicles. The same would be true for semi-trailer trucks and semi-trailers, or horses and horse carts.
"Laenderbahn" would not be obvious due to vehicle selection, unless the player is educated in german railway history. Showing the name wouldn't help - even worse if a translator goes with something like "Regional Railroad".
An advantage could perhaps be if the group could be pre-selected as a filter, so the player can compare vehicles within the same group. Perhaps even create custom depot tabs for especially large groups. But I think that would go in a very different direction that has more to do with vehicle management than with constraints.


Why not both?
> Create a new Group Object. That Object only has a name, a description (string) , and a priority (integer). Since it is an Object, it can be translated, even though groups would be unique to a pakset.
> Vehicles may reference any number of Group Objects by name, indicating they belong to the group.
> In the Depot, each vehicle lists all groups it belongs to, from highest to lowest priority; alphabetically if same priority (This is so you could add "German", "Länderbahn" and "Bavarian" to the same vehicle, and have them appear in this order, rather than "Bavarian, German, Länderbahn").
> Groups can be searched for and filtered
> Groups with a translated description can be clicked to open a new window given said description (same functionality as factory descriptions)
---
> Implement Alias. Each vehicle may reference an Alias. (Or perhaps several?)
> Change Constraints so that, in addition to the name, they also look for Alias and Groups of a Vehicle.
> This means the pak author can use visible groups as constraints, but can also set custom constraints easily with hidden alias.
Vice versa, visible Groups can be used for Constraints, but can also be used to indicate which vehicles would go well together without forcing anything.

Since I don't know exactly how the backend works, it might be that Alias and Groups could even be the same reference in the vehicle, but only visible if a group object of the same name exists.

I know, I know, even more work to implement. But I think it's important to cater different pakset philosophies. In p192c, a differentiation of freight locomotives or länderbahnen wouldn't happen. It would all be more about smaller-scaled sets, like Adler, Rheingold, Henschel-Wegmann, Railjet,... - and that's all already done via constraints. Similarly, trucks specify one or two possible trailers. There wouldn't even be a change for the player, just that addons to these restricted sets would be possible.

Ters

I don't think constraints and "groups" really belong together the way the term "group" has drifted since the topic was started and named. None of the groups suggested so far really are constraints as for which vehicle can be connected together, only, at best, which vehicles normally belong together. I don't think Simutrans, or rather the pak sets, should be too strict on which vehicles belong together based on epoch, nationality or minor coupling details. Players should be allowed to mix-and-match to a certain degree, just like real-life railroad companies do, as shown by the following mix-and-match trains.


NRK Sommertoget 2017 (Norwegian Broadcasting Corporation Summer train 2017):


A rolling television studio (and "hotel") consisting of modern passenger cars and par of container cars (temporarily?) retrofitted with cables for door control signals. (Mostly pulled by modern electric locomotive, but sometimes a slightly older diesel locomotive.)


Oslo-Hamburg train 1979:
(Images can be found at https://jernbane.net/bo/subpage.php?s=4&u=11623. You "must" register at jernbane.net to see the full images. I'll focus on the right-most image on the fifth row.)
Norwegian locomotive (used for freight as well, I think) followed by Swedish locomotive, followed by some German passenger cars followed by what I think are either Norwegian, Swedish or Danish passenger cars. (The dual heading is probably because one had to switch drivers at the border, and this was the smoothest solution, not due to weight.)


I've also seen pictures at jernbane.net of DMUs, and maybe also EMUs, with freight cars behind them. Simutrans doesn't simulate this kind of oversized baggage and/or mail/freight hybrid, though. If one wants to do it just for show, the combinations are so limited that it can be done with the existing constraint system.


Another thing to do for show would be heritage trains. Like this DMU being pulled by an (almost cropped out) diesel locomotive. (Although for regulatory reasons not applicable in Simutrans.)

Leartin

Quote from: Ters on August 29, 2018, 10:35:49 AMI don't think Simutrans, or rather the pak sets, should be too strict on which vehicles belong together based on epoch, nationality or minor coupling details. Players should be allowed to mix-and-match to a certain degree, just like real-life railroad companies do, as shown by the following mix-and-match trains.
My favorite example is an ICE pulled by a Diesel locomotive due to broken overhead wires - many things are possible, and for a model railway environment, you need barely any restrictions.

However, Simutrans is a game, too. You can have restrictions in place not because they simulate reality, but because they make for a better, more diverse game.
Just as example: What if a TGV has a more expensive control cars, while an ICE has slightly more expensive wagons? If you could mix them, the cheapest constellation would always be an ICE control car and TGV wagons. If you can't mix them, there would be a choice dependent on how long a train you need. While slightly worse for a model railway player (only slightly, since chances are anyone who plays for looks did not intend to mix the two brands), it would be a huge improvement for the game player, who now sees use in more different objects. In a similar vein, while dividing freight and pax locomotives does not make any sense for realism, it would help in balancing them to make for a more fun game, since one would only need to balance for either goods or pax, never both.

To give the model railway user all the freedom they could get, it might be better to just have some game option to turn constraints (or groups, if they become a different thing) off completely. I assume constraints are only checked while composing a train in the depot and never again after that, so for a model railway player to turn it off, be creative with a specific train, and turn it on again after they sent the train off should work. (Or they just turn it off forever and have fun with a horse pushing (not even pulling) a semi-trailer. If it's a 'cheat' (an option not accessible to a player who does not switch to public hand), it really does not matter.)

Ters

I wrote "not too restrictive" not "not restrictive at all". My examples were all about mixing vehicles with standard screw couplings, not whatever weirdo couplings may be internally in a DMU or EMU.

Constraints should be for something which it makes no sense to turn off. Semi-trailers without proper trucks, locomotives without tenders, DMUs/EMUs without front or/and rear control cars (unless that really is realistic), those kinds of things. Groups like freight and Länderbahn is something different, like the existing tabs.

Leartin

Quote from: Ters on August 29, 2018, 05:46:17 PM
I wrote "not too restrictive" not "not restrictive at all". My examples were all about mixing vehicles with standard screw couplings, not whatever weirdo couplings may be internally in a DMU or EMU.
My point wasn't about the coupling used, but about the gameplay value of constraints even if they are not based on realism. It's the same for other trains perceived or branded as a Set, even if they don't have a special coupling.

In fact, branding is an important factor we could consider: A Siemens ES64U2 is a boring number, but brand it with Austrian design, and it becomes an exciting Taurus. Go a step further and give it the railjet-design, and now it's even better. Due to marketing decisions, you'll only see railjets with railjet-branded Taurus on regular traffic, and no Taurus with a railjet branding would carry freight. It's certainly possible, I'm sure it's even done if the regularly scheduled locomotive breaks down on short notice or something, but that never happens in Simutrans.
As a private company, you are free to buy a ES64U2 and use it however you want. But you wouldn't be allowed to use brandings of other companies unless you aquire a license, so you'd have to follow the brands rules.

QuoteGroups like freight and Länderbahn is something different, like the existing tabs.
I agree, hence my suggestion to not force an overlap.

Ters

Quote from: Leartin on August 30, 2018, 04:49:48 AM
In fact, branding is an important factor we could consider: A Siemens ES64U2 is a boring number, but brand it with Austrian design, and it becomes an exciting Taurus. Go a step further and give it the railjet-design, and now it's even better. Due to marketing decisions, you'll only see railjets with railjet-branded Taurus on regular traffic, and no Taurus with a railjet branding would carry freight. It's certainly possible, I'm sure it's even done if the regularly scheduled locomotive breaks down on short notice or something, but that never happens in Simutrans.
As a private company, you are free to buy a ES64U2 and use it however you want. But you wouldn't be allowed to use brandings of other companies unless you aquire a license, so you'd have to follow the brands rules.

I don't see anything in the gameplay of Simutrans that requires enforcing of this. There are some practical aspects to consider as well. What if the only EuroSprinter add-on for the pak set you play has been drawn in Railjet livery? Should you then not be able to use it as a generic EuroSprinter? However, nothing prevents a pak author form using the current constraint system to enforce that Railjet EuroSprinters only connect to Railjet passenger cars. I only propose/support to extend the constraint system with something more generic than listing each vehicle explicitly. This does not change that fact. I just don't see this as the primary purpose of constraints, although there is a considerable grey zone between what certainly counts as a constraint and what doesn't. The SJ X2 for example looks very much like an EMU, but it is technically not very different from the Railjet concept. The integration of locomotive and the passenger cars is just taken a bit further than just a paint job, but it is possible to disconnect the locomotive and drive it around independently. The closely related Norwegian type 71 and 73 are however true EMUs, with motors throughout the set rather than a dedicated locomotive unit.

However, the Railjet can potentially have some of the same issues that semi-trailers have. What if they start using other locomotives besides the EuroSprinter? With the current constraint system, one would have to rewrite at least the first passenger car (depending on how flexible the car arrangement is) to open up for this. With more generic constraints, a completely different artist could make just the new locomotive and it would work.

Another thing that I thought of mentioning earlier, but never did is that while you may never see a TGV pull a freight car, you might see a freight car pulling a TGV. A broken down TGV. This is however irrelevant to Simutrans, as trains don't break down. (It could be nice for model railroad purposes, but probably only if you could join the trains up out on the track.)

Ultimately, some decisions are up to the pak author. I just don't see a reason to solve all possible issues just to solve one.

Leartin

Quote from: Ters on August 30, 2018, 08:28:54 AM
What if the only EuroSprinter add-on for the pak set you play has been drawn in Railjet livery? Should you then not be able to use it as a generic EuroSprinter?
From my perspective: No, because it was created for the addon, balanced to work with that, and using it elsewhere would be an unsupported misuse. I'm all for allowing an easy "cheat" for it (including offering sources so the player can change the vehicle, or someone publishes a different version) but that would be on the player, not the creator. Me, I'd probably add a generic EuroSprinter, or a normal Taurus without special constraints first.
It begs the question though: Why use a railjet loco as a generic Eurosprinter? I'd prefer a green locomotive for the line that in reality uses a green locomotive over a red locomotive with the same name. That's probably because I'm not too much into trains, but still.

Quote from: Ters on August 30, 2018, 08:28:54 AMI only propose/support to extend the constraint system with something more generic than listing each vehicle explicitly. This does not change that fact. I just don't see this as the primary purpose of constraints, although there is a considerable grey zone between what certainly counts as a constraint and what doesn't. [...] However, the Railjet can potentially have some of the same issues that semi-trailers have. What if they start using other locomotives besides the EuroSprinter?
I'm absolutely with you. Technically, there already are different types of EuroSprinter that pull Railjets, and they do have slightly different livery. That is exactly the point of the proposed Alias system: As long as there is only one Railjet locomotive in the pakset, you would constrain by name. If you want to add others, you only need to use the alias of the original.

My point is NOT that you would be wrong. My point is that other opinions are just as reasonable,and it does not matter what anyone thinks Constraints should do, since noone can ever be right nor wrong. If you say technical constraints, a strong rope circumvents almost all of them (semi-trailers would be really loud scratching over the floor, but it's physically possible). If you say anything along "reasonable", someone will read all train logs available and disable any connection they can't find evidence has ever been done historically. And the important message is: Neither view on the topic is wrong, and all of them (except mister rope) could do with a better way to do constraints to use them to their liking. Give us that (preferably as Alias, not as groups shown in the depot) and everybody wins. (And by you, I don't mean you specifically, but anyone who can and wants me to like them :) )

Ters

Quote from: Leartin on August 30, 2018, 09:59:49 AMFrom my perspective: No, because it was created for the addon, balanced to work with that, and using it elsewhere would be an unsupported misuse. I'm all for allowing an easy "cheat" for it (including offering sources so the player can change the vehicle, or someone publishes a different version) but that would be on the player, not the creator. Me, I'd probably add a generic EuroSprinter, or a normal Taurus without special constraints first.
It begs the question though: Why use a railjet loco as a generic Eurosprinter? I'd prefer a green locomotive for the line that in reality uses a green locomotive over a red locomotive with the same name. That's probably because I'm not too much into trains, but still.
Balancing in Simutrans, to the extent that it actually is, seems to resolve around the speed bonus. Using a high-speed locomotive for freight would not be cheating, because you would be losing money on it. Except for some freight types which are set up for higher speed than the typical freight locomotives, such as cooled goods (and mail, the the extent that it even is considered freight, in pak64).

Furthermore, locomotives in Simutrans should strictly speaking be in player livery, not Railjet. A Railjet like setup in Simutrans, where you play as your company, not a model railroad, would therefore have a locomotive that looks just like any other locomotive of that type. Which means that it would have to satisfy this "Railjet"-like constraint coming from the "Railjet" cars, but itself have no (or at least less restrictive) constraints itself on what cars it can pull.

Quote from: Leartin on August 30, 2018, 09:59:49 AMMy point is NOT that you would be wrong. My point is that other opinions are just as reasonable,and it does not matter what anyone thinks Constraints should do, since noone can ever be right nor wrong.
Well, that is exactly why I want to not put too much into constraints. The game should give some leeway to the pak author on how to do things, but also, and perhaps more importantly, the game and the pak author should not put too much restrictions on how the player wishes to play. Let the player experiment with vehicle combinations to see what works and what doesn't economically and efficiently as part as regular play. That is not cheating, that is the way of the business.

prissi

This topic was concieved for discussion on how one could avoid using an express engine (which has to be very powerful) to carry freight. Because if no speed bonus is used, then such an engine will be always superiour to a freight engine, because runnig cost is essentially determined by power. If one wants to avoid this (e.g. to make the passenger transport less rewarding than freight) such groups could be useful. Another example are the very early engines which were not very powerful, so their cars were very light. This means that modern engines can pull a very large number of those, also hard to balance correctly.

Ters

Old cars are light, but also slow and with low capacity. And Simutrans already has a timeline feature that can ensure that you can not use them with later engines.

And with pak64, I find that the freight locomotives are the ones with the highest power and running cost, at least in the mid-1900s. The only true passenger locomotive in 1950 capable of pulling a significant number of passenger cars at 100 km/h or more is the BR01. The other two locomotives capable of that at that time is the F7 and the NS1000, both of which seem to be freight locomotives. Although the F7 was adapted for passenger service, and the NS1000 was perhaps originally intended to be a passenger locomotive. Which only shows that the classification of locomotives as freight or passenger is difficult in itself. Many would have to be duplicated with differing running costs only to fit passenger or freight use, if it is impossible to balance locomotives for both usages. (Technically, there would be a difference in the specifications of the real-world locomotives. Freight variants have smaller wheels and hence lower top speed, but better tractive effort(?) than passenger variants. The top speed of the freight cars should be enough to deal with the speed, and Simutrans Standard does not have accurate enough physics for the rest to make any sense.)

Leartin

Quote from: prissi on August 30, 2018, 12:21:26 PM
This topic was concieved for discussion on how one could avoid using an express engine to carry freight.

Where did you get that from?
This thread was conceived for use in restricted sets of vehicles.
The one this was inspired by was one about more complicated groups for things like steam heating, centrally operated doors, cabling for control cars.
The german one was mostly about seperating horse carriage from truck&trailer from semi-trailer.

Everyone wants to do slightly different things with it, but we agree that we want it. Your idea of seperating freight from pax is just as valid, but could be done with the same system everything else could be done with.



Ters

Well, there are two possible solutions as I see it.

One is to simply give vehicles the ability to state "I am an X", and then other vehicles can use X in their constraints just like the can use the explicit name of a vehicle.

The more complex one, and harder to make backwards compatible, would be for vehicles to provide a set of somethings, which other vehicles would require one or more of. A semi-trailer would require something providing a fifth wheel. Certain passenger cars would require the previous vehicle to provide screw coupling and door control cabling.

Each can implement the other, although the latter is overkill for the first, and it would take a lot of Xes to replicate the latter with the first.

Leartin

Quote from: Ters on August 30, 2018, 01:20:17 PM
Each can implement the other, although the latter is overkill for the first, and it would take a lot of Xes to replicate the latter with the first.
The difference is whether multiple entries are cumulative, correct?
("I am X" and "I want X next" would be the same as "I need X" and "I provide X", but "I am X and Y" would be valid for "I want X next", while "I need X and Y" is not satisfied with "I provide X".)

If that's the case, wouldn't it be just as hard to convey "I require either X or Y" with the second system, while easy with the first?

Ters

I got a bit unsure if and vs. or, and combinations thereof, started rearing its head, so I skipped it. Most of the "I want X or Y" I've seen today is because of the lack of the feature being discussed. Perhaps "or nothing" makes it still relevant. It can maybe be special cased. I haven't done much thinking on the second alternative, as the first one seems enough for all I care for.