News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

Assorted broken vehicle references

Started by ACarlotti, March 23, 2018, 06:46:28 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ACarlotti

I've been trying to fix a load of broken references (in relation to the upgrade listing bug mentioned elsewhere). The following are issues I have discovered but not fixed:


  • BR-158Front-Trolley(Regional) - this is no longer defined (and is probably the wrong name anyway). The trolley variant of br-158 was removed last summer around the time that passenger classes were added.
  • BR-1568Front(-Trolley)(Regional) - also not defined, but this looks like a typo for the above.
  • SR-augmentation-trailer(front) /(rear) - this has been split into multiple different augmentation trailers, so I suspect each reference to this needs replacing with a line for each new type.
  • (Composite/Wooden/Steel)HullUnpoweredNarrowboatMail - the mail variant is completely missing. It also seems odd that the stats are the same for the different material types (not yet balanced, perhaps?).
  • (Steel/Wooden)HullDumbBargeMail - again the mail variant is missing.
  • vickers-vanguard-952-(cool/piece) - I fixed the bad references, but noticed that these are defined with the option to upgrade to themselves. More generally, the upgrade paths for these seem a bit strange (can convert a passenger (but not freight) 952 to a freight 953).
  • BR-Class23 - included in coupling rules but doesn't currently exist.
  • petrol smoke - ok, this last one isn't a vehicle, but it is another missing cross reference

I'll upload the fixes I've made soon.

I'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.

jamespetts

Thank you for spotting these: this is most helpful. Errors in compat.tab are often not noticed, so thank you for spotting these and for the forthcoming fixes.

I had been wondering about introducing a coupling grouping system for a while. I was thinking something a little different to what you propose, keeping the existing system intact, but adding a new type of more abstract coupling constraint system similar to the way constraint system so that one can specify to what vehicles may couple by type (e.g., "screw link coupling, vacuum brakes" or "buckeye coupling, air brakes, electric train heating", etc.).
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.

Vladki

There were some discussions about coupling constraints in the past. So you might want to review them. There's lot to think about. Coupling itself, brakes, heating, door control, push-pull operation...

There were several methods proposed. Either constraint groups: e. g. Pendolino car group, that would allow you to compose the Pendolino from any combo of 1st, 2nd, dining, mail, front and tail cars.

Another idea was some sort of require/provide/pass through options, (e. g. for heating or remote control.)


jamespetts

My apologies: I must have missed that. Now incorporated.
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.

ACarlotti

I'd like to clarify while we're here that I have no immediate plans to fix the remaining issues mentioned in the first post, as I am in these cases uncertain of the intended correct behaviour. Someone with more familiarity with the pakset ought to take a look at some point.