wesnoth
Allow comma-separated x and y in [item] at scenario level
Describe the desired feature
The goal would be to be able to use
[item]
image="scenery/village-human-burned2.png"
x=9,9
y=4,5
[/item]
Instead of
[item]
image="scenery/village-human-burned2.png"
x=9
y=4
[/item]
[item]
image="scenery/village-human-burned2.png"
x=9
y=5
[/item]
at scenario level. It is already possible inside an event.
It would be even more useful for for this code
[item]
image="scenery/village-human-burned2.png"
x=9-10
y=4-6
[/item]
If a name is given, it would be the same for all the created items
On a cursory check this tag seems to be handled here: https://github.com/wesnoth/wesnoth/blob/31db0409002bb094defd2065ef0518c166cf919f/data/lua/wml/items.lua#L120
Most likely a simple adjustment of this loop will do the trick: https://github.com/wesnoth/wesnoth/blob/31db0409002bb094defd2065ef0518c166cf919f/data/lua/wml/items.lua#L126-L128
Bingo: we need a Lua equivalent of this C++ function: https://github.com/wesnoth/wesnoth/blob/31db0409002bb094defd2065ef0518c166cf919f/src/map/map.cpp#L423
I also wonder whether https://wiki.wesnoth.org/LuaAPI/wesnoth/map#wesnoth.map.find already handles that or not.
most of our wml tags either accept a location filter or a single location, making this the single tag where we accept a comma seperated lists of xy woul be rather unintuitive imo
For what it's worth, @babaissarkar 's cursory examination is somewhat off-base. The code he's pointed out is the code that handles [item] in an event. The correct code is several lines up, the definition of wesnoth.persistent_tags.item.read.
The final conclusion (that we need a way to read location ranges without using a full location filter) seems valid though.
most of our wml tags either accept a location filter or a single location, making this the single tag where we accept a comma seperated lists of xy woul be rather unintuitive imo
This is not the "single" tag where things are different from "a location filter or a single location". There are others too, such as [village]. (Alright, that's actually the only other one I know of though.)
I believe there is a legitimate reason to not support a full location filter during preload, though I'm not 100% sure on that. Assuming there is indeed a legitimate reason, we may as well support as much of a subset of the location filter functionality as we can. Location filters already support comma-separated lists of xy, so that seems like a low-hanging fruit here.
The other possibility would be to realize that there isn't any reason not to support full location filter syntax here, and just implement that.
ok i didn't see the original point was about scenario level items (i just looked at the code before). But that makes me wonder more why this is needed in the first place, are there any reason not to use an event? Adding proceccing features for convieneice in the code that was just for de-serializing the mapitems seems wrong to me on first thought.
As I stated at the time on Discord, IMHO this issue could be closed as this feature is available at [event] level.
It could be closed, as the feature is indeed available in a prestart event, for example. But I do think it wouldn't hurt to add location list support for scenario-level items.
Admittedly, scenario-level tags exist more for serialization support than for ease of coding. But that doesn't mean we can't add any ease of coding features into them.