Author Topic: Constraint-Groups  (Read 1326 times)

0 Members and 1 Guest are viewing this topic.

Offline Leartin

« on: May 18, 2017, 08:42:37 PM »
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:

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.

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

Offline Vladki

Re: Constraint-Groups
« Reply #1 on: May 18, 2017, 09:18:55 PM »
I support the groups constraints.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 16880
  • Total likes: 548
  • Helpful: 182
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Constraint-Groups
« Reply #2 on: June 21, 2017, 12:18:42 AM »
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.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5026
  • Total likes: 244
  • Helpful: 113
  • Languages: EN, NO
Re: Constraint-Groups
« Reply #3 on: June 21, 2017, 05:30:02 AM »
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.

Offline Leartin

Re: Constraint-Groups
« Reply #4 on: June 21, 2017, 06:30:14 AM »
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:

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.
« Last Edit: June 21, 2017, 06:43:45 AM by Leartin »

Online DrSuperGood

Re: Constraint-Groups
« Reply #5 on: June 21, 2017, 11:54:25 PM »
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).