Bug: `alternative_sprites` in conditional blocks away from the parent behave inconsistently
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
Research direction
Start by reproducing the behavior with the attached redef-alternate.zip example and inspect how alternative_sprites and conditional blocks are processed. Compare the result with the linked NFO specification; done means conditional alternative sprites follow their condition and nonsensical separated definitions are handled consistently with NewGRF semantics.
Written by the indexing model from the issue text.
Description
As alternative_sprite blocks can be placed away from their 'parent' sprites, the NML syntax implies you can do things like define alternative_sprites in a conditional block which are used only when that condition is met. For example:
replace grid_temperate_spr3981(3981, "temperate_groundtiles_gridline_8bpp.png") { template_groundtiles(0, 0, 1) }
if (climate==CLIMATE_ARCTIC) {
alternative_sprites (grid_temperate_spr3981, ZOOM_LEVEL_NORMAL, BIT_DEPTH_32BPP, "arctic_groundtiles_gridline_bt32bpp.png") { template_groundtiles(0, 0, 1) }
}
This doesn't work as you'd expect from the code. The alternative sprites are always used irrespective of climate.
The syntax also allows some quite nonsensical definitions:
if (climate==CLIMATE_TEMPERATE) {
replace grid_temperate_spr3981(3981, "temperate_groundtiles_gridline_8bpp.png") { template_groundtiles(0, 0, 1) }
}
if (climate==CLIMATE_ARCTIC) {
alternative_sprites (grid_temperate_spr3981, ZOOM_LEVEL_NORMAL, BIT_DEPTH_32BPP, "arctic_groundtiles_gridline_bt32bpp.png") { template_groundtiles(0, 0, 1) }
}
Such behaviour is not possible for NewGRFs (cf. NFO specs) as alternative sprites are just one part of the definition of a single real sprite.
Some example NML and images:
redef-alternate.zip
- 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