UI: Allow any mod sound to be selected as a multiplayer turn notification sound #11623
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
... Actually, "New architecture to find any non-texture-atlas media" would be more fitting. but that title up there can go into the changelog.
No issue, this is for a slightly miscast "Modding request": Allow any mod sound to be selected as a multiplayer turn notification sound. - borrowed the title even though my first one was a tad shorter.
This is the extreme version - started with "how would I imagine an easy to use yet still flexible tool to answer the question 'which media file if any should I use for a given key'..." and then coded top-down from the framework draft. I did not yet check whether the other intended clients do anything in a significantly different way. I suspect the priority between newgame-selected mods, perm audiovisual ones, and builtin is not always exactly the same - but it should be.
The ugliest part of that request is how to attach human-readable labels to sounds, the old solution to that was ugly, and it's not much better here. As mentioned in my replies to the above, moving UncivSound back to enum-based - nope, without large refactorings that ultimately fails on unexpected impediments. Refactoring all UncivSound usages to cleanly distinguish between the interface and the enum - possible, but not right now. Then once that enum exists, it could carry display labels... Again, not yet. But in here there's still a tricky little imp that still enumerates the existing UncivSound.X instances almost as if the container were an enum. Almost moot since most instances need a mapped label anyway, but - had fun coding it.
No screenshots since I don't know of any suitable mod
@5cover - your idea and you mentioned PR'ing the same - so your review would welcome, s'il vous plaît.