Location-Based Recruit Lists?

[weewah]

Is there a way to make location-based recruit lists?

I'm aware that, if I wanted to make a leader able to recruit different units at different keeps, I could simply use move events to change the recruit list whenever the leader moves onto a keep.

But what if I wanted to make a leader able to recruit different units on different castle tiles, while remaining on the same keep? Is there any way to do that?

[Celtic_Minstrel]

I'm pretty sure there isn't a way to do that, unless someone can come up with something weird and clever (but I doubt it).

[gfgtdf]

Well you could try to use mouseover events to change the recruitlist in a way that would only allow those units that'd be legal for the position (note that it's more complicated because when the location is occupied it will be placed somewhere else) you also have to be careful with sync or other clients might reject that action.

[Tad_Carlucci]

What he means is you would need to not only detect the tile with a mouseover event but you would need to detect if it is occupied and, if so, know the search pattern for nearby tiles, looking for an un-occupied tile, to determine the position where the new unit will appear.

[octalot]

It wouldn't be a good UX, but maybe show a message, refund the gold, and kill the unit?

Code: Select all

    [event]
        name=recruit
        first_time_only=no
        [filter]
            race=merman
            [filter_location]
                terrain=!,Chw,Khw,Cm*,Km*,W*
            [/filter_location]
        [/filter]
        [message]
            speaker=narrator
            message=_ "Merfolk can only be recruited on water-castle tiles"
        [/message]
        [gold]
            side=$unit.side
            amount=$unit.cost
        [/gold]
        [kill]
            id=$unit.id
        [/kill]
    [/event]

[Tad_Carlucci]

If you have to go to so much work you have to ask: is it really necessary? And: can I get a similar effect with a totally different approach?

While it's possible you've identified a new use case, and could possibly even justify changing the engine to support it, I sort of suspect a small adjustment in your design goals would make the issue simply go away.