Borg bugs and feature requests

[agoodman]

In the attached save file, the borg playing a blackguard has equipped a ring of searching with the cowardice curse and has managed to be surrounded by the townsfolk. The ring has been fully identified so, at least in my mind, there's absolutely no reason to keep it.

I may not have coded for the cowardice curse. That is a new curse so it is possible I don't have code to avoid it. I will take a look.

[agoodman]

With the latest post-4.2.5 code (last commit is https://github.com/angband/angband/c...150f6c1d929bc2 ), there's cases where the borg repeatedly tries to dig out a granite wall despite the game saying "You chip away futilely at the granite wall." (which means there's no chance for success; for rubble the similar message is "You dig in the rubble with little effect."). I haven't checked if that's because the borg miscalculates the chance of successfully digging or if it proceeds to dig even knowing there's no chance.

The borg doesn't currently check for the "bad digging" messages. It relies on having calculated the chance of digging right and thinking it can dig. I don't think my recent digging change caused this but... maybe. Either there is a case where he thinks he can dig but he can't or he is desperate to get somewhere and is digging even though he has low chance of success. If you can get a save file of him doing this, I can look into it further, otherwise, I can look at the code but it will be hard to fix.

[backwardsEric]

In the attached save file, the borg playing a blackguard has equipped a ring of searching with the cowardice curse and has managed to be surrounded by the townsfolk. The ring has been fully identified so, at least in my mind, there's absolutely no reason to keep it.

[backwardsEric]

With the latest post-4.2.5 code (last commit is https://github.com/angband/angband/c...150f6c1d929bc2 ), there's cases where the borg repeatedly tries to dig out a granite wall despite the game saying "You chip away futilely at the granite wall." (which means there's no chance for success; for rubble the similar message is "You dig in the rubble with little effect."). I haven't checked if that's because the borg miscalculates the chance of successfully digging or if it proceeds to dig even knowing there's no chance.

[agoodman]

ok, I think the immediate fix for this is "don't flow toward veins if you are hungry" which stops the problem of the borg flowing up to the vein then deciding not to dig because he is hungry. (Unfortunately for Alair he then runs into the next room and gets eaten by mice. Stupid borg) I will test this some more but this is probably the first step. I think some checks need to be combined for a single "can't dig" check.
I think I need to change this code around to not flow to veins when hungry but DO dig if it gets you to where you want to go, even if hungry. That will enter the fix queue. In fact I think the filter for flowing toward a vein is probably "if down to x foods" so the borg doesn't dig around till he is out of food and hungry then stop digging. IIRC, that is what the original change to not dig when hungry was supposed to accomplish.

[agoodman]

Since there is a down staircase there, another option (if playing with connected stairs, without forced descent, and without persistent levels as is the case here), it could take the down stair and immediately come back up to get a completely new dungeon.

Yes, I just don't want him to go down and explore... I might need him to do > < but he might do that automatically since he will get down there and think "Hungry! I gotta get upstairs... hey, I am on stairs!". I will have to check it out. It is going to take some debugging. I will be checking into it this week.

BTW, merged your pull requests. I am just making a new sandbox to test the code quickly on my machine before I create a pull request to the base code.

[backwardsEric]

I can try a couple of things here...
1) it should explore a new area if it checked and can't dig
2) it shouldn't make a goal of something it needs to dig if it can't dig
3) at some point it if it is hungry enough, it should dig.

Since there is a down staircase there, another option (if playing with connected stairs, without forced descent, and without persistent levels as is the case here), it could take the down stair and immediately come back up to get a completely new dungeon.

[agoodman]

Attached is a save file where, using the default borg.txt, the borg character gets caught bouncing back and forth between a down stair and pile of rubble next to a vein. Eventually that loop tightens to back and forth diagonal moves next to the pile of rubble before the character dies from starvation.

okay, back from traveling and taking a look at this.

a quick debug says it seems to be flowing toward the "dark" trying to find a up stairs. Forbidden from going down because it is low on food. It can't dig because that uses too much food/energy so it runs back to the stairs it knows. Rinse, lather, repeat.
I can try a couple of things here...
1) it should explore a new area if it checked and can't dig
2) it shouldn't make a goal of something it needs to dig if it can't dig
3) at some point it if it is hungry enough, it should dig.

btw, you have "base delay factor" set to 40 (= d) so he is gonna be slow.

[backwardsEric]

Attached is a save file where, using the default borg.txt, the borg character gets caught bouncing back and forth between a down stair and pile of rubble next to a vein. Eventually that loop tightens to back and forth diagonal moves next to the pile of rubble before the character dies from starvation.

[backwardsEric]

Borg: necromancers and light sources

With the default borg.txt, started up a necromancer with the borg, and the first messages are "Need to refuel but cant!" and then the borg went to the general store to buy torches. Since light at the player's square affects a necromancer's spell casting failure rate and necromancers can see without a light source, necromancers don't start with a light source and are picky about what light sources (or any gear with a bonus to the light radius > 1) they use. I haven't looked at how to adjust borg.txt to account for that.

[backwardsEric]

That's right. That ego items use activations rather than one or more effects is a fairly recent change (post 4.2.4), see https://github.com/angband/angband/issues/5451 for some background on that.

[agoodman]

Just making sure I understand the way the base code works...

artifacts have activations. random artifacts can have any activation.

ego items might have activations but, from reading ego_item.txt, none actually do.

Other objects just have effects. So shining dragon armor doesn't activate to the DRAGON_SHINING activation, it just has an effect which may or may not match up to an activation (for example, there is no DRAGON_WHITE activation)

[agoodman]

If there's no clear relationship between the power in activation.txt and the value the borg assigns to an activation, then one approach would be to add a field to activation.txt, say 'borg-value', add the parsing necessary for it in obj-init.c (how parse_act_power() is used there can be an example), and add storage for that field to struct activation in object.h (and if a non-zero default value is desired for that field do that in obj-init.c's parse_act_name()). Then the value of that field can be used rather than if/else block at borg4.c:~4900. Those changes are more intrusive to the rest of the code but fit well with the principle of moving what someone is likely going to want to modify from the source files to the data files.

That is a possibility but I always dismiss any change that involves changing base code to make the borg work. I have always taken it as a design limit that changing base code for the borg was, in principle, forbidden. The result of this is that there are several arrays and functions I copied into the borg code that could just have the "static" removed from them in the base code. The exception to this is screen saver code and things that have to be in the UI like watching for the ^z.

I agree with the principle of moving things people want to change to a data file but I was going with a borg specific dynamic power formula in the borg.txt file. If you check the second post in this thread, I mention some of my thoughts on this. It is lots of work but my dream is to have an external human readable easy to understand file that people can modify and change vast amounts of the borg behavior.
If I got power and depth to be dynamic, as I outlined, the next step would be home power... then we would have users able to tweak what the borg wielded, what he carried, how deep he went and what he stored at home. The next after that would be how he explores... and I have no clue even how to start that.
We can discuss this further on another thread. In general I find "dynamic borg" to be fascinating. A borg that someone with zero C skills can modify would be fun.

[backwardsEric]

Well, this will take some work. I can't really just use the "power" field because borg "power" not really the same as an objects power.

If there's no clear relationship between the power in activation.txt and the value the borg assigns to an activation, then one approach would be to add a field to activation.txt, say 'borg-value', add the parsing necessary for it in obj-init.c (how parse_act_power() is used there can be an example), and add storage for that field to struct activation in object.h (and if a non-zero default value is desired for that field do that in obj-init.c's parse_act_name()). Then the value of that field can be used rather than if/else block at borg4.c:~4900. Those changes are more intrusive to the rest of the code but fit well with the principle of moving what someone is likely going to want to modify from the source files to the data files.

[agoodman]

Any activation from lib/gamedata/activation.txt is possible on a randart. As an example, see kineahora's bug report here, http://angband.oook.cz/forum/showpos...6&postcount=28 , about a randart that had the FOOD_WAYBREAD activation (not present on any artifact in the standard set). For the value determination in borg4.c:~4900, one might have special cases but then fall back to using the power field for the activation as the basis for the additional value of that activation. For tactical decisions about when to use an activation, that, in general, would require looking at the effects the activation invokes.

Well, this will take some work. I can't really just use the "power" field because borg "power" not really the same as an objects power. For example the borg gets 60000 "power" for wielding an unidentified sword at low levels to encourage him to use it to find out what it does. Or 2500 "power" per point of AC up to 15 then 2000 up to 75 then 1500 after that... Just weird numbers made up way back when to influence the borgs decision making. Right now activations generally get a base 500 plus some for damage they do or if they do something that makes the game easier like mapping. The whole power thing could use a rebalance as has been pointed out by the borg doing stupid things like picking the wrong sling or ring. Ah well, on the to-do list. Activations first, power later...