Non-random introduction date (non-GRF breaking?)

[George]

Wrt. changing the format of properties: IMO that is a no-go. Every tool relies on the size of properties, so they would all have to learn to distinguish properties according to the GRF version. OTOH adding new properties is no problem.

Currently there is a big problem, that vehicles properties 00, 03 (together with Long format introduction date) have random values added. What would be the best way to have values, which are not affected by random change? New introduction date and vehicle life properties, or removing random factor in version 8?

[Yexo]

Adding a bit to train prop 27 (other vehicle types have similar props) that says "don't randomize the introduction date". That is, if it's decided that such a feature is actually required.

[George]

Adding a bit to train prop 27 (other vehicle types have similar props) that says "don't randomize the introduction date". That is, if it's decided that such a feature is actually required.

Yes, it is very important for EMUs/DMUs. Because they are assembled from parts, which should become available and disappear from the buy menu at the same time. This would allow correct assembling of the consist.

[Hyronymus]

And it makes more realism possible for those set developers that like to stick to real dates.

[Eddi]

what should IMHO be more useful is a "make this vehicle automatically avalable when vehicle X is available" property/callback. then the introduction of the EMU-head would still be able to randomize, but the middle wagon would always be available at the same time. likewise a passenger wagon and its accompanying mail wagon.

[DaleStan]

<meaningless jabber about introduction dates>

Which DOES NOT REQUIRE A NEW GRF VERSION.

Please, people. Is this concept really that hard to grasp? Unless the change you are proposing will break existing GRFs, it is off-topic here.

[frosch]

One could also keep rerandomising the introduction dates as usual, but with these restrictions:

• The order of introduction does not change; so introduction date "x+1" will always be after "x".
• Vehicles with the same introduction date "x" get the same random amount.

And yes, Dalestan, some mod should split this

[George]

<meaningless jabber about introduction dates>

Which DOES NOT REQUIRE A NEW GRF VERSION.
Please, people. Is this concept really that hard to grasp? Unless the change you are proposing will break existing GRFs, it is off-topic here.

if the behaviour for props 00 and 03 is changed to no random value added, than it is a change for GRF version, imho. In case a new prop is added no new GRF version is needed.

[PikkaBird]

if the behaviour for props 00 and 03 is changed to no random value added, than it is a change for GRF version, imho.

And why on earth would the behaviour for those properties be changed?

Yes, it is very important for EMUs/DMUs. Because they are assembled from parts, which should become available and disappear from the buy menu at the same time.

I can't think of a scenario where this is much preferable to the current methods available, which are a) building the EMU/DMU using generic passenger cars which change their appearance to match, or b) building the EMU/DMU as a string of one vehicle, or c) building the EMU/DMU as a prebuilt articulated consist. If the feature is added, Yexo's flag is probably the way to go.

[Eddi]

"make this vehicle automatically avalable when vehicle X is available" property/callback.

to precisise this, this could work similar to railtype prop 18/19