dabber's questions: vision to location

[dabber]

I'd like to have an enemy side fill up its keep with recruits before the start of the scenario. The idea is they are close to the player and have to be fought on turn 1. I can make the units, and I can brute force identify a castle relatively near the leader using a [filter_location] with leader location and radius filter. But the situation I want is a long and thin castle (blocking a peninsula), and my radius filter hits a second castle in addition to the one I want. I can brute force my way around that with multiple centers, but I feel there should be a better way. How would I get just the one contiguous castle?

[beetlenaut]

Why don't you just have the AI go first? It would fill its castle automatically that way. You can use [side] color to keep the player's color the same as it was when the player was side 1.

[dabber]

I'm messing with Legend of the Invincibles campaign, and I think changing side 1 would break some things.

Instead, I discovered [store_reachable_locations], which I thought would do the job. But it's output excludes some hexes, even though the leader can move there. Any suggestions on what might be wrong?
In the picture below, the flaming guys are the units created by the code below. There should be more of them 2 columns left of the big demon leader.

Code: Select all

#define RESTRICT_TO_KEEP_OBJECT_REMOVE LEADER_ID
    [remove_object]
        object_id=restrict_to_keep_{LEADER_ID}
    [/remove_object]
#enddef

#define RESTRICT_TO_KEEP_OBJECT LEADER_ID
    [object]
        [filter]
            id={LEADER_ID}
        [/filter]
        id=restrict_to_keep_{LEADER_ID}
        take_only_once=no
        [effect]
            apply_to=movement_costs
            replace="yes"[attachment=0]incomplete_store_reachable_locations.JPG[/attachment]
            [movement_costs]
                frozen={UNREACHABLE}
                shallow_water={UNREACHABLE}
                deep_water={UNREACHABLE}
                reef={UNREACHABLE}
                flat={UNREACHABLE}
                castle=1
                village={UNREACHABLE}
                forest={UNREACHABLE}
                cave={UNREACHABLE}
                hills={UNREACHABLE}
                mountains={UNREACHABLE}
                forest={UNREACHABLE}
                fungus={UNREACHABLE}
                swamp_water={UNREACHABLE}
                sand={UNREACHABLE}
                unwalkable={UNREACHABLE}
                impassable={UNREACHABLE}
            [/movement_costs]
        [/effect]
        [effect]
            ## giving him extra movement to reach long thin castle, value used for experimentation
            apply_to=movement
            set=7
        [/effect]
    [/object]
#enddef

#define PRE_POPULATE_KEEP_REACHABLE SIDE
    [event]
        name=side 1 turn 1
        ## find a leader (only supports one leader)
        [store_unit]
            [filter]
                canrecruit=true
                side={SIDE}
                [filter_location]
                    terrain=Kh*
                [/filter_location]
            [/filter]
            variable=populate_recruiter
        [/store_unit]
        [if]
            [variable]
                name=populate_recruiter.length
                greater_than=0
            [/variable]
            [then]
                ## lock leader into castle, then find where he can move
                {RESTRICT_TO_KEEP_OBJECT $populate_recruiter.id}
                [store_reachable_locations]
                    [filter]
                        id=$populate_recruiter.id
                    [/filter]
                    moves=max
                    variable=populate_castle
                [/store_reachable_locations]
                ## return leader to normal movement
            #    {RESTRICT_TO_KEEP_OBJECT_REMOVE $populate_recruiter.id}
                ## grab side in order to get recruit list
                [store_side]
                    side={SIDE}
                    variable=this_side
                [/store_side]
                ## put recruits into those locations, subtracting gold along the way
                [foreach]
                    array=populate_castle
                    [do]
                        {VARIABLE_OP recruit_string rand $this_side.recruit}
                        [unit]
                            type=$recruit_string
                            x,y=$this_item.x,$this_item.y
                            random_traits=yes
                            side={SIDE}
                        [/unit]
                        [store_unit_type]
                            type=$recruit_string
                            variable=recruited_type
                        [/store_unit_type]
                        {VARIABLE gold_spent $recruited_type.cost}
                        {VARIABLE_OP gold_spent multiply -1}
                        [gold]
                            side={SIDE}
                            amount=$gold_spent
                        [/gold]
                    [/do]
                [/foreach]
            [/then]
        [/if]
    #    {CLEAR_VARIABLE populate_recruiter,populate_castle,this_side,recruit_string,recruited_type,gold_spent}
    [/event]
#enddef

[beetlenaut]

There should be more of them 2 columns left of the big demon leader.

Hmm. Yeah, I see what you mean. I do think this method will work in the end.

It's usually really hard to find a logic error in 100 lines of someone else's code though, and as I expected, nothing sticks out as obvious. The next thing I would do is try it out. I would use {DEBUG_MSG} and [inspect] liberally to make sure that the stored locations were what I expected, the gold handling was happening the way I expected, and so on. However, I don't feel like creating a test campaign, scenario, map, sides, and macro calls--especially considering that you have all that already. If you want to post a running test version, I will probably be able to find the problem. (Assuming someone else doesn't get to it first.)

[dabber]

I figured posting the code wasn't likely to help, but I didn't have anything else to do. In theory, it is easy to add to any existing scenario, as long as there is a human side 1 and an AI side with a leader.
1) The output of [store_reachable_locations] is populate_castle, and that variable is wrong. It contains exactly the spots with new units and doesn't have the missing spots. (Technically, it contains the leader location, and the unit that is put there actually appears just south of him, but that is expected behavior I'll worry about fixing later).
2) The leader can move to the problem locations, based on hovering over him on my turn to show his possible movement.
3) If I don't add the movement restricting item, he summons a nice half+ circle around him, but only east. The same empty column appears to the west, and everything west of that is also empty.

Idea ... maybe, somehow, that side cannot see those hexes? That doesn't make much sense, but how would I force visibility for that side?

[beetlenaut]

If I don't add the movement restricting item, he summons a nice half+ circle around him, but only east...

So, if you remove the code you posted above, you have another form of the same problem. That means the bug is not in that code at all! It's somewhere in the code you haven't posted. It certainly sounds strange though.

Here is what you should do. Copy the necessary files into a separate test campaign that contains just this one scenario, and start removing chunks of the code in that test campaign. Eventually, one of two things will happen: One is that you discover where the offending code is. The second is that you will have created a cut-down test case so small that nothing more could be removed and still have it load and start, and it still has the problem.

If you still need help at that point, that's what you should post. A small test case is always the most polite thing to post for a group of volunteers to look at. You shouldn't expect us to have to write our own code in order to make it run. But, we do have to run it because that's how debugging works if the cause of the bug isn't immediately obvious.

I'm sure it's not a visibility problem.

[dwarftough]

If you experiment with LotI specifically, I think posting a scenario file with your changes could be helpful. It's hard to debug out of context. I wanted to try to reproduce your situation but I can't remember in which scenario the enemy has such a long keep

[gnombat]

If you experiment with LotI specifically, I think posting a scenario file with your changes could be helpful. It's hard to debug out of context. I wanted to try to reproduce your situation but I can't remember in which scenario the enemy has such a long keep

I think that is "Grim Port".

[dwarftough]

I think that is "Grim Port".

Big thanks for reminding.

Well, I tested dabber's code and found out that it works buggy when player's side has shroud. Which I don't understand tbh, is that Wesnoth bug? The documentation says if viewing_side isn't mentioned, store_reachable_locations should ignore it.

Reported here https://github.com/wesnoth/wesnoth/issues/7891

[gfgtdf]

As dwarftough mentioned, this is a bug in wesnoth we will fix it in wesnoth 1.18, but its unlikely that a possible fix will make it into 1.16. Maybe you can work around it by specifying viewing_side=2 (or whatever that units side is)

[beetlenaut]

Congratulations to dabber for doing something unique enough that a new bug got uncovered. That bug must have been waiting there two years at least. I guess it does relate to visibility, but I was assuming it wouldn't be an engine bug at this point.

[dabber]

Well that was sure interesting! dwarftough, thanks for trying it yourself. I was occupied over the weekend and didn't do any more testing.

I'm sure it's not a visibility problem.

I guess it does relate to visibility, but I was assuming it wouldn't be an engine bug at this point.

My full time job is writing software, and I've definitely said that sort of thing before!

[dabber]

I want to make all the units on one side unable to leave the castle where they start, except to let a few of them run out each turn, and then all of them be released after a few turns. To lock them in the castle, I thought I would give them an object that modifies movement costs, which I could then remove later. Giving them objects works, and they are stuck in the castle.
But removing the object requires each unit have an object with a unique id. I immediately figured I'd build an object id based on the unit id, but that fails - object id cannot contain spaces while unit id can have spaces! I found an interesting github discussion related to this, but no resolution.

1. Is there existing code to replace spaces with underscores in a string / unit id? It shouldn't be difficult to write, but it seems like a standard concept that should exist already.
2. Is there a better way to do this concept than via objects?

[gfgtdf]

while [object] id= needs to be unique, [modify_unit][object] id= doesn't need that, so i think you can just use [modify_unit][object]

[Ravana]

I would say it is just missing feature of object removal. When it had to be done manually you could filter by all fields, now with tag there is only one field available.