Closed TTFTCUTS closed 11 months ago
So the logic to get the actual modifier icon path should be optimized. And it seems like there are some other 'inherit icons' situations.
Plugin now simply get the modifier icon path by template expression "gfx/interface/icons/modifiers/$.dds", where "$" is the modifier name.
It seems like there should be some addtional inference logic (and are there others?), and the icon file could also be a png file.
Some others:
All of these (note the warnings in the scroll bar) have icons in-game
Edit: Just noticed the priest unity additive modifier using an old Russian loc entry from one of our "orphaned" loc files in favour of the vanilla english loc. Unsure if that priority order is desirable or not. I've removed the entry from the file since it wasn't being used any more anyway.
Not sure what's the icon generation rule for template-based modifier (e.g. shipsize_<ship_size>_build_speed_mult
).
A possible enhancement:
Some modifiers such as
job_<x>_add
, where the corresponding job has anicon
field set, use the icon corresponding to the name set in the field instead of the job's name.Currently, the plugin will complain that the icon matching the modifier's name is missing, but this relation could potentially be inferred.
An example:
Here, the Iodizium Mining Drone has its icon set to the Iodizium Miner job, and in game the drone modifier uses the icon for
job_giga_iodizium_miner_add
. The plugin warns that the icon matching the modifier name is missing, which is true, but that's not the icon which the game ultimately uses. It could potentially infer the relation from the job and use the other icon like it does in game.As always, great work with the plugin, it helps our development work tremendously. Thank you for your efforts.