Upgrading from a version prior to 0.7.3 changes specific use cases using vehicle random_bits
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start by reproducing the two switch examples with nmlc and tracing how switch ranges and random_bits are handled. Identify the existing compiler diagnostic and test locations while checking the behavior change introduced by #288. Done means affected cases produce a useful warning when no valid range or default exists, with coverage for the reported examples.
Written by the indexing model from the issue text.
Description
Hello,
I recently upgraded from 0.7.1 to 0.7.5, and when I re-compiled a GRF (Mop's Expanded Road Vehicles) I noticed that some vehicles in-game had broken sprites.
I narrowed it down to this change, #288, after reading through the changelogs and testing different versions/commits.
This is due to how the original code is in deciding between different spritesets, f.ex:
switch (FEAT_ROADVEHS, SELF, switch_w_l_f_flat_e, random_bits ) {
0..63: spriteset_w_l_f_flat_e;
64..127: spriteset_w_l_f_flat_f;
128..191: spriteset_w_l_f_flat_g;
192..255: spriteset_w_l_f_flat_h;
}
As there is no default value or specific range defined there is no valid choice when the random value is between 256-65535.
I don't know if any other GRFs have the same issue, or if this is a very specific issue to how this GRF was written.
However, I do think it would be nice to have this show up as a warning in the nmlc output, if possible, so that its easier to catch if this is a problem in their code.
It also changes the probability between choices in cases like this, where it will now heavily favour the default value when compiled with a newer version of NML:
switch (FEAT_ROADVEHS, SELF, switch_o_box_b, random_bits ) {
0..69: spritegroup_o_box_a;
70..139: spritegroup_o_box_b;
140..209: spritegroup_o_box_c;
210..255: spritegroup_o_box_d;
default: spritegroup_o_box_b;
}
However, that is less of an issue, as it at least does have a default value to fall back to, even though it might lead to an unknown/unwanted change in behaviour for other GRFs, if they have implemented logic like this, and they are unaware of the random bits change.
- Dominant language
- Python
- Stars
- 61
- Forks
- 47
- Avg merge
- 8d 14h
- Merged PRs (30d)
- 3
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from OpenTTD/nml
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 50/100
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
Similar issues
-
15-minutes 5-minutes algorithm any-language beginner-friendly c cpp csharp easy go good first issue hacktoberfest help wanted java javascript kotlin python rust swift typescript
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Huerte/algo-solutions-python#254 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 1-3 hours Newbie friendliness 86/100
MichaelYcJo/SpecSeal#1543 ·
-
size/s
Difficulty 1/5 Under an hour Newbie friendliness 90/100
sipyourdrink-ltd/bernstein#7179 ·
Maintainers usually reply within 1 day
-
good first issue help wanted python up-for-grabs
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
andrewsiah/agentswarm-data-tasks#309 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day