Borg bugs and feature requests

**Evilpotatoe** · October 25, 2023, 20:51

I didn't remember that @could now dig without having to swap to the pick, but... are you telling me @spending hundred of turns to dig through a *magma* vein with a shovel of digging is normal efficiency ?

I often dig through magma with crappy weapons.. is it that Vanilla's magma is tougher than Forg's one ? Or a question of non-optimized stats in my case (chose default human warrior for the borg, far from my usual brutes)

**agoodman** · October 25, 2023, 21:00

Originally posted by Evilpotatoe

I didn't remember that @could now dig without having to swap to the pick, but... are you telling me @spending hundred of turns to dig through a *magma* vein with a shovel of digging is normal efficiency ?

I often dig through magma with crappy weapons.. is it that Vanilla's magma is tougher than Forg's one ? Or a question of non-optimized stats in my case (chose default human warrior for the borg, far from my usual brutes)

Ya, that was caused by the RNG bug I just mentioned... If you failed once, you failed forever for repeats with the code the way it was. I just checked in a quick fix. Hopefully this will solve "repeated commands don't seem to work so well for the borg".

**Pete Mack** · October 26, 2023, 10:20

A mage cannot dig magma for some time

**backwardsEric** · December 8, 2023, 14:21

In recent post 4.2.5 builds, there's this compiler warning on macOS:

Code:

borg/borg-trait.c:1180:9: warning: variable 'extra_blows' set but not used [-Wunused-but-set-variable]
    int extra_blows                   = 0;

I suspect that borg-trait.c should be using extra_blows at line 1892 (though it will have to avoid double counting extra blows from the equipped weapon) missing a line around 1858 to set borg.trait[BI_BLOWS] with the new value of the extra blows from the equipment.

**agoodman** · December 9, 2023, 17:46

Originally posted by backwardsEric

In recent post 4.2.5 builds, there's this compiler warning on macOS:

Code:

borg/borg-trait.c:1180:9: warning: variable 'extra_blows' set but not used [-Wunused-but-set-variable]
    int extra_blows                   = 0;

I suspect that borg-trait.c should be using extra_blows at line 1892 (though it will have to avoid double counting extra blows from the equipped weapon) missing a line around 1858 to set borg.trait[BI_BLOWS] with the new value of the extra blows from the equipment.

I will have to check if having "extra blows" on a non-weapon does something. If you have a blade with extra blows, then armor that gives more extra blows, does it work or is that not allowed? I will muck up my artifacts.txt to try to give armor with extra blows to see what happens.

**backwardsEric** · December 9, 2023, 20:17

Originally posted by agoodman

If you have a blade with extra blows, then armor that gives more extra blows, does it work or is that not allowed? I will muck up my artifacts.txt to try to give armor with extra blows to see what happens.

From lines 1948-1949, 2283, and 2297 of player-calcs.c, off-weapon extra blows contribute to the total extra blows passed to calc_blows().

**agoodman** · December 10, 2023, 03:32

Originally posted by backwardsEric

From lines 1948-1949, 2283, and 2297 of player-calcs.c, off-weapon extra blows contribute to the total extra blows passed to calc_blows().

okay, I added trait for "BI_EXTRA_BLOWS" which should be all the blows granted by things that aren't the weapon. I think this will work. It doesn't do the p->obj_k->modifiers stuff but, if I am reading things right, that is always just 1 if you know that rune and if you don't the borg shouldn't have put it as an item attribute.

I should double check the extra shots and extra might calcs as well. I am pretty sure they are wrong but I am not really sure how. I updated that code while still figuring out the new structures.

**backwardsEric** · March 18, 2024, 04:11

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.

**agoodman** · March 19, 2024, 20:12

Originally posted by 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..

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.

Originally posted by backwardsEric

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.

Originally posted by backwardsEric

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** · March 20, 2024, 03:41

Originally posted by agoodman

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** · March 20, 2024, 21:11

Originally posted by backwardsEric

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.

**Grommen** · March 27, 2024, 02:46

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.

Attached Files

stoneToMud.zip (19.3 KB, 7 views)

**R3g3n3X** · April 1, 2024, 21:03

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.

Code:

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:

Code:

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

Originally posted by agoodman

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!

Attached Files

Legion.zip (12.4 KB, 7 views)

**agoodman** · April 4, 2024, 19:05

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.

**agoodman** · April 4, 2024, 19:24

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.

Borg bugs and feature requests

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment