Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RailTypes: Introduction date not enforced #7321

Closed
jcoletto77 opened this issue Mar 3, 2019 · 13 comments
Closed

RailTypes: Introduction date not enforced #7321

jcoletto77 opened this issue Mar 3, 2019 · 13 comments

Comments

@jcoletto77
Copy link

Hi there,

In my railtype set, there is a high-speed line coded to be introduced in 1970, but in fact, it gets introduced much earlier than that.

I seem to understand that, currently,a specific railtype gets introduced when a vehicle of that specific railtype gets introduced.
In my set, however, there are no vehicles of that "high-speed" railtype. All my vehicles are coded as "normal-speed": some modern trains will be crippled outside of "high-speed" tracks, because the concept behind my “normal-speed” tracks includes “low maximum axle weight".

For this reason, I'd need introduction year to be enforced even if no vehicles of a certain railtype are present in the set.

Thanks in advance,
Snail

@PeterN
Copy link
Member

PeterN commented Mar 3, 2019

This is working as intended, the introduction date is an additional way to get introduction, it doesn't mean it only gets introduced on that date.

We could add an additional rail type flag that says introduction date should be the only method of introduction.

@jcoletto77
Copy link
Author

That would be useful. This flag could keep the current way of things as a default to preserve compatibility, and always enforce introduction date as an option.

@nielsmh
Copy link
Contributor

nielsmh commented Mar 3, 2019

Could such a flag perhaps be combined with the "hidden railtype" flag that was added recently?

hidden strict_date meaning
0 0 Introduced when either intro date has passed, or first train engine supporting it is introduced.
1 0 Never buildable.
0 1 Introduced exactly on the specified date, never before and never after.
1 1 Introduced on the specified date at earliest, but may be later if no engines support the railtype yet.

@PeterN
Copy link
Member

PeterN commented Mar 3, 2019

That complicates the hidden flag somewhat.

@PeterN
Copy link
Member

PeterN commented Mar 3, 2019

Hmm, should strict date introduction still require the required railtypes to have been introduced. I'm... not really sure how it will interact. Maybe 'impossible to introduce' are up to the NewGRFs to avoid.

@jcoletto77
Copy link
Author

Perhaps "Introduced exactly on the specified date" could override the required railtypes having been introduced? This would avoid loopholes, and as you said, it would be up to the NewGRF author to come up with a reasonable introduction scheme.

@PeterN
Copy link
Member

PeterN commented Mar 3, 2019

Looking at the code, I can't see how the railtype will have been introduced. Here are the existing conditions:

  1. As an engine becomes available, the introduces property of its railtype is applied. This by default includes only itself. If the railtype's introduces property includes other railtypes, those are also introduced.
  2. On each day, the introduction date property is checked, If the date has passed, and the railtype's required railtypes are already introduced, then the introduces property of this railtype is applied, as in 1.

No railtypes are introduced based on compatibility or powered flags.

So this begs the question, what is introducing it in this case...

@PeterN
Copy link
Member

PeterN commented Mar 3, 2019

Your introduction date is wrong, the value should be specified as days since year 0 (long date.)

The date set for NBBN is "91F" which is around May, year 6.

@PeterN
Copy link
Member

PeterN commented Mar 3, 2019

Looking at the code, I don't think a new flag to enforce this is necessary after all.

@jcoletto77
Copy link
Author

Thanks!
Now that I've replaced "91F" with "AFAB6" in my NFO code (which roughly corresponds to the number of days until 1/1/1970), the railtype doesn't show up in the list, even if I start in year 2200...

@PeterN
Copy link
Member

PeterN commented Mar 3, 2019

I've tested by manually overriding 91F to AFAB6 in the code (that's easier for me than modifying the NewGRF) and the rail type does appear in 1970, give or take a few days for leap years.

@jcoletto77
Copy link
Author

I just did some more checking, and confirm the current code works well.
It was a false alarm on my side. Sorry about that!

@PeterN
Copy link
Member

PeterN commented Mar 5, 2019

That's cool, I learned stuff about code I wrote 10 years ago now!

@PeterN PeterN closed this as completed Mar 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants