Borg bugs and feature requests

[agoodman]

Using version 4.2.5-193-gfc1e6bcff

With turning afraid back on in 4.2.5-188-g24fce3201, borg can now get stuck in a hallway between 2 mobs. Attaching save or will email agoodman if that fails.

Looks like this is an old bug. From what I can tell reading the 3.4.0 code, it would have happened there too. The borg gets all the way to the "twitchy" stage where it just picks a random direction and goes in it. The problem is that trying to attack when afraid doesn't take a turn so there is never any progress.

I just checked in a "fix".... it isn't great but the borg will chip at a wall in hopes to not be so scared in the future. Works for your save file. If the borg is completely surrounded by monsters and afraid he will rest a turn. BTW, it should only get this far if it doesn't have a spell to case or a scroll, like phase door, to read. I notice your borg had a deep descent scroll on him but the borg doesn't currently know how to use those.

[Grommen]

Using version 4.2.5-193-gfc1e6bcff

With turning afraid back on in 4.2.5-188-g24fce3201, borg can now get stuck in a hallway between 2 mobs. Attaching save or will email agoodman if that fails.

[agoodman]

ya, the only places it uses swap items is borg-item-wear.c/borg_backup_swap(). The comment to it says it all

* Place our "swap" if needed. We check both the armour and the weapon
* then wear the one that give the best result (lowest danger).
* This function is adopted from "borg_wear_stuff()" and borg_wear_rings
*
* Basically, we evaluate the world in which the swap is added
* to the current set of equipment, and we use weapon,
* that gives the largest drop in danger---based mostly on resists.
*
* The borg is forbidden to swap out certain resistances.

It doesn't even check "hey, how about if I swap to get a better attack"... unless it thinks it can kill the baddie, thus reducing the danger.

I think this would be a good enhancement so I will keep it in mind. I will have to think about where a "could attack better via swap" hook could be put in. It would need to be careful not to lose a resist by swapping or the borg would just instantly swap back before attacking getting into a swap loop.

[agoodman]

Well, my current borg when fighting Itangast tries to pick him off from a distance with iron shots from a bow- no problem- but fails to take a turn (though it's not -that- serious a risk for a great gain; 990+ hp, borg) to change to his dragonslaying artifact weapon when Itangast has moved adjacent- just keeps poinking with +0 iron shots. not great, that. (Angband 4.2.5 compiled under MacPorts running on my MacOS 14.5 computer. With, since it may matter, randarts selected.)

I will take a look at the weapon swap code. I didn't write this section so it might take me a bit to understand it. My memory of it is that the borg is good at swapping to be safer ("mon might breath fire, switch to a resist fire swap item") but not as good at "I can attack better with this swap".

[agoodman]

In the latest release (maybe previous ones too. just getting back into this), https://github.com/angband/angband/r...157-g3c9cb4468, my level 40 Druid likes to cast Turn Stone to Mud a lot. Seems to mostly get stuck in this loop when near those small monster areas that are mostly surrounded my indestructible walls.

It looks like backwardsEric has a fix to this. Just pushed it forward. I missed this entirely.
Thanks!

[eschiss1]

Well, my current borg when fighting Itangast tries to pick him off from a distance with iron shots from a bow- no problem- but fails to take a turn (though it's not -that- serious a risk for a great gain; 990+ hp, borg) to change to his dragonslaying artifact weapon when Itangast has moved adjacent- just keeps poinking with +0 iron shots. not great, that. (Angband 4.2.5 compiled under MacPorts running on my MacOS 14.5 computer. With, since it may matter, randarts selected.)

[agoodman]

as mentioned in https://angband.live/forums/forum/an...f-they-find-it dynamic calcs has been added back to the code with a new format. If people who compile the code themselves want to grab it and let me know
1) how to better document it
2) how to modify the format to be more readable
3) any other changes they might want
it would be appreciated
thanks!

[agoodman]

found it...
* Remove Curse swap armour
*/
bool borg_decurse_armour(void)
{
/* Nothing to decurse */
if (borg_cfg[BORG_USES_SWAPS] && !decurse_armour_swap)
return (false);
should be

if (!borg_cfg[BORG_USES_SWAPS] || !decurse_weapon_swap)

if (not using swaps) or (no swap to decurse) done.
I never stumbled on this one because I never turn off swaps. Good find.

[agoodman]

I think the swapping to digger thing was already fixed. At this point it doesn't tell you but when you have a digger in inventory and dig it just uses the digger (this is main game stuff, not borg stuff) so there is no need to manually swap in a digger.
I thought I had the remove curse issue solved but I loaded up Legion, un-squelched remove curse and used wizard mode to drop one and...
"
You have no curses to rremove
# Reading Scrolls of Remove Curse
& Key * *BAD KEY * *
"
well.. that ain't good. A debugging I do go.

[R3g3n3X]

The attached save has two behavior quirks that I think I've narrowed down. I have the borg.txt file configured 'FALSE' for borg_uses_swaps. This seems to result in a remove curse loop that I have to manually intervene on to cast a remove curse (perhaps related to new curses not being coded in to the remove curse logic yet?) or, at times, I have tell the borg to ignore the remove curse scroll because there is nothing to decurse in equipment or inventory yet it loops on casting the scroll. Not sure you can get that to duplicate since I already ignored all remove curse scrolls but wanted to mention it. This does not seem to happen when borg_uses_swaps is set to TRUE in borg.txt.

Trying Item Shovel (1d2) (+6, +4) (best power 4046162)
Against Item Quarterstaff 'Eriril' (1d9) (+13,+15) <+4,\
+1> (borg_power 5136509)
Reading Scroll of Remove Curse.
#
& Key <OxE000>
Key <OxE000>
&
& Key <r> (0x72)
& Key <q> (0x71)
& Key * *BAD KEY * *
& Key <Ox9C>
# Parsing msg <You have no curses to remove. >
# Parse Msg bite <You have no curses to remove. >
Trying Item Shovel (1d2) (+6, +4) (best power 4046162)
Against Item Quarterstaff 'Eriril' (1d9) (+13,+15) <+4,\
+1> (borg_power 5136509)
# Reading Scroll of Remove Curse.
& Key <OxE000>
& Key <OxE000>
<r> (0x72)
& Key <q> (0x71)
& Key * *BAD KEY * *
& Key <Ox9C>
# Parsing msg <You have no curses to remove. >
# Parse Msg bite <You have no curses to remove. >

EDIT: I turned on swaps and the behavior persisted. It's probably an issue you're already aware of.

The second quirk is, and again borg_uses_swaps is turned off, that he does not swap a shovel into equipment to dig. I think the hunger/digging balance is already on the borg development radar, but this is adjacent. Verbose borg text loop sample:

Trying Item Shovel (1d2) (+6, +4) (best power 3553492)
Against Item Quarterstaff 'Eriril' (1d9) (+13,+15) <+4,\
+1> (borg_power 4611441)
# Digging through wall/etc
& Key <T> (0x54)
& Key <9> (0x39)
# Parsing msg <You tunnel into the quartz vein.>
# Parse Msg bite <You tunnel into the quartz vein.>
Trying Item Shovel (1d2) (+6, +4) (best power 3553492)
Against Item Quarterstaff 'Eriril' (1d9) (+13,+15) <+4,\
+1> (borg_power 4611441)
# Resting to recover HP/SP.
& Key <R> (0x52)
& Key <&> (0x26)
<Ox9C>

I also have borg_self_scum set to FALSE in borg.txt. I don't think that would alter these behaviors but in the interest of full quirk disclosure there you are

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.

This would be amazing! I'm just picking up the borg again after fiddling with it back in the early 00s and I'm wishing I could use the borg.txt file to do more, or at least use inscriptions to manually control what the borg keeps at home, in inventory, and equips, as you describe. I've grabbed the source code (I'm not a coder, but I'm close enough to follow logic) and I've been trying to figure out how the 'here be dragons' part of the borg.txt file interacts with the source to try and get more granular control over my little AI characters. Thanks for all the work you guys do!

[Grommen]

In the latest release (maybe previous ones too. just getting back into this), https://github.com/angband/angband/r...157-g3c9cb4468, my level 40 Druid likes to cast Turn Stone to Mud a lot. Seems to mostly get stuck in this loop when near those small monster areas that are mostly surrounded my indestructible walls.

[agoodman]

For the spell, item activation, and staff, there's still the chance of failure when casting/using the item. To me, the earlier announcement is okay as is - or it could say "Trying to banish ..." rather than "Banishing ...".

The return from trying to activate/use is "true" even if the use failed since the borg doesn't know it failed till it gets a response from the keystroke from the game. So the processing is "press keys, give control back to game" In this way it is really removing the kills from the list prematurely. This isn't a huge deal because it will look at the screen again next time and create the kill list again. It is wrong in that it will eliminate kills it ran from but are now off screen from its list of kills it knows about making it less likely to try to genocide them in the future. In other places the borg deals with this sort of thing by watching for a set of messages from the game. It is a little harder for genocide because there isn't a "all the 'Z's have disappeared" message so it would need to track what it just did across turns. There are places that is done but the code is tricky and adding it here... well, I guess it can go on the enhancements list.

[backwardsEric]

I think if you can't use one of the (scroll/spell/item/staff) it should have kicked out up top. If all the or's are false, something went wrong and we already announced we are genociding something.

For the spell, item activation, and staff, there's still the chance of failure when casting/using the item. To me, the earlier announcement is okay as is - or it could say "Trying to banish ..." rather than "Banishing ...".

[agoodman]

There seems to be an inconsistency in the borg's logic for using banishment. Shouldn't the assignment at borg-fight-defend.c:2037 ("tmp_genocide_target = b_i;") be guarded by "if (b_i)"? Otherwise, a case with a rejected immediate threat and an accepted general threat will result in banishment not being cast..

Hmmm, trying to follow this code and figure out what is going on. I think you are right. I think further, this code should have its variables renamed so that it is more obvious what is going on here.

Also, the returned value when simulating (borg-fight-defend.c:2044-2049) differs from what's returned when the spell is actually cast (borg-fight-defend.c:2091) though the latter is not used by the caller. The comments by the simulated case return values are misleading: the one at borg-fight-defend.c:2047 should be something like "/* Simulation for general threat */".

Ya, I think this routine could use a good going over. I think it evolved from just genocide for immediate threats to also handling "is a threat on the level" and "is generally a threat so getting rid of it to be safe" and I am not sure it was done completely right.
BTW, I don't want to give the impression that I have anything but the highest respect for previous borg maintainers. Mistakes happen, many by me.

Edit: Noticed later that the removal of the banished monsters from the kill list (borg-fight-defend.c:2112-2131) is done even if the scroll/spell/item/staff is not used.

I think if you can't use one of the (scroll/spell/item/staff) it should have kicked out up top. If all the or's are false, something went wrong and we already announced we are genociding something.

[backwardsEric]

There seems to be an inconsistency in the borg's logic for using banishment. Shouldn't the assignment at borg-fight-defend.c:2037 ("tmp_genocide_target = b_i;") be guarded by "if (b_i)"? Otherwise, a case with a rejected immediate threat and an accepted general threat will result in banishment not being cast.

Also, the returned value when simulating (borg-fight-defend.c:2044-2049) differs from what's returned when the spell is actually cast (borg-fight-defend.c:2091) though the latter is not used by the caller. The comments by the simulated case return values are misleading: the one at borg-fight-defend.c:2047 should be something like "/* Simulation for general threat */".

Edit: Noticed later that the removal of the banished monsters from the kill list (borg-fight-defend.c:2112-2131) is done even if the scroll/spell/item/staff is not used.