[NewGRF] More options for setting vehicle refit masks - #13090
Conversation
7dc929c to
87ed9e6
Compare
…lass intersection.
a07edfe to
5232af7
Compare
|
Test NewGRF: test_13090.zip It has to be used in sub-tropic climate as the only NewGRF. It will add three new rail vehicles:
|
|
If somebody only wants to review/approve either the property or the callback, I'll happily split this into two PRs if necessary. Added to the PR description, too: "The new callback is run only once after NewGRF load and not cached, so a potential desync hazard if e.g. the date is included in the CB." |
|
The And perhaps this needs to be activated by a callback_mask bit (which of course varies by vehicle type). Iron Horse by itself has 10,000 engines, so enumerating 640,000 callbacks just for that "may" take some time. It may be fine... |
5232af7 to
eed518a
Compare
|
Now with a callback flag. Updated test NewGRF: test_13090_v2.zip |
|
Best commit since the day PBS graced us with its presence. |
Motivation / Problem
The existing properties to define vehicle refittability based on cargo classes are limiting.
There are properties for OR, AND NOT, and XOR, but no AND or any other boolean logic.
Description
This PR adds a new property to filter the allowed refits based on an AND of cargo classes, i.e. only cargos that have all cargo classes from the prop are added as an allowed refit.
In detail, the existing prop 28/1D/18/18 select a candidate list of refittable cargos that have at least one of the cargo classes from the prop set. The new prop then filters this list by only allowing cargos that have all of the cargo classes from the new prop set.
To future-proof the refit calculations, there's an additional new callback introduced that is run once for each vehicle type and defined cargo after NewGRF load that allows overriding the prop-based refit mask. The callback is passed the cargo classes and the local cargo ID and will either allow, disallow, or not change the refittability of each cargo.
These two features are fully independent, so there would be no problem dropping one of them.
Limitations
The new callback is run only once after NewGRF load and not cached, so a potential desync hazard if e.g. the date is included in the CB.
Checklist for review
Some things are not automated, and forgotten often. This list is a reminder for the reviewers.