Borg bugs and feature requests

[backwardsEric]

Downloaded 4.2.6-117-gf1f841fe7 and have been running the borg as usual. For the first time ever in my experience, while running the borg, Angband eventually becomes almost unresponsive (responding to keystrokes with at most klick-sounds, and to command-q quit, the only command it seems to respond to in any other way, with an actual freeze from which I have to force-quit the application.)

That's not related to the Borg, but is a bug in https://github.com/angband/angband/c...687a357e1e91ff . I'd recommend using 4.2.6-107-g64d78d7f6 as that does not have the bug and there's no Borg-specific changes in 4.2.6-117-gf1f841fe7 .

[eschiss1]

Downloaded 4.2.6-117-gf1f841fe7 and have been running the borg as usual. For the first time ever in my experience, while running the borg, Angband eventually becomes almost unresponsive (responding to keystrokes with at most klick-sounds, and to command-q quit, the only command it seems to respond to in any other way, with an actual freeze from which I have to force-quit the application.) Did this a couple of days ago, and is in the middle of it again now...

[Nick]

you ever notice how when you want to get a borg deep it dies off over and over but when you want to test the death code the borg makes it to level 37...

I feel like this is a special case of a more general phenomenon

[agoodman]

you ever notice how when you want to get a borg deep it dies off over and over but when you want to test the death code the borg makes it to level 37...
I am going to have to add some "do something extra stupid after a period of time" code to get this tested.

[agoodman]

I do wonder with the last "there is a wall in the way" if somehow it cheated death but the borg didn't refresh and is confused. Perhaps the order in which I am now consuming messages is flushing the message when it shouldn't be. More debugging is definitely needed.

[backwardsEric]

I'll run it with a watchpoint on borg_cheat_death - if that's being clobbered that could explain the failure to reincarnate and why there might be an association with higher level borgs.

[agoodman]

Okay, in my quick test it is doing the reincarnation in that case. It isn't keyed off of "You die", though it does look for that and makes sure to end the borg when it gets that, if you aren't cheating death. It is keyed off of "Die?" which you should always get after death if you have cheat_live set. Not sure what is going on.

[agoodman]

The choices are complicated around cheating death and explained in borg.txt...
1) cheat death and keep playing
2) reincarnate and start again as a new character (determined by borg_respawn_race and borg_respawn_class)

so it sounds like you want option two but are getting option one... it looks like the default is borg_cheat_death = FALSE if you copied the borg.txt provided or let the game generate borg.txt. I think that should do 2. I will debug a bit to verify. I have been messing around a bit in that code so I might have broken it. I will need to turn on USE_STATS since I never do that.

[backwardsEric]

I set up the Borg to automatically restart when it dies: the player option to cheat death is on and the Borg option to cheat death is off. Start the Borg running with Ctrl-z z with the default borg.txt. Occasionally when the borg dies, the standard cheating death procedure happens (return to town fully healed) rather than the borg reincarnating. This is with the recent development versions, compiled on macOS 26.3.1 using 'make -f Makefile.osx OPT="-O0 -g -DUSE_STATS -fsanitize=address -fsanitize=undefined"'.

I have not tracked down why this happens in some cases rather than others. It's possible that this is from a bug outside the borg - the "You die" message is lost or damage to the player is not routed through the take_hit() routine. Anecdotally, the high level borgs are the ones that tend to bypass the reincarnation. These are the last messages from the most recent example:

# Aiming Wands of Teleport Other (4 charges).
Target Selected.
You have 3 charges remaining.
The hasty ent misses you.
The hasty ent punches you.
# MISS_BY:The hasty ent (+)
# HIT_BY:The hasty ent (+)
# There was a monster 'greater demonic quylthulg' at (15,169)
# Loc9,173 Dep:77 Lev:50 HP:-15/972 SP:111/401 Danger:p=271
# Protected by PFE
# No Teleport. scary squares: 100 <2x>
# Performing defense type 11 with value 160
# Targeting hasty ent who has 386 Hit Points (8,173).
# Logging Spell pathway (9,173): My grid.
# Logging Spell pathway (8,173): hasty ent, danger 6
# Aming Wands of Teleport Other (3 charges).
You invoke wizard mode and cheat death.
There is wall in the way!

The borg is dead by the "# Loc9,...." line but there is no sign of the "You die" message.

[agoodman]

From what I can see the webpage is updated when a new release is created. I don't think I messed with the commands before the release was cut so they should be "as accurate as before I messed around" for the released version, not the compiled cutting edge version. So... kinda accurate because I hadn't been keeping the docs up to date.

[eschiss1]

Will do and thanks. Thumbs-up

[agoodman]

By the way, the list of borg commands in borg.rst.txt and on an official website I think too, gives an out of date list of internal borg commands (e.g. ^z 2 rather than the now ^z P for the depth the borg believes it's ready for.)

I rewrote a bunch of the commands. I just checked in https://github.com/angband/angband/pull/6526 to update the docs.
btw, play around with the commands and see if they work the way you like.

[eschiss1]

By the way, the list of borg commands in borg.rst.txt and on an official website I think too, gives an out of date list of internal borg commands (e.g. ^z 2 rather than the now ^z P for the depth the borg believes it's ready for.)

[eschiss1]

Thanks. It's happened a few times in, however, a weird game.

[agoodman]

An awake monster whose level is less than the player's level - 35 will always try to flee (and a fraction of the monsters whose levels are less than the player's level - 28 also flee). There's a more involved calculation, taking into account the player's and monster's hitpoints, that can cause a monster whose level is less than the player's level - 20 to flee. In all those cases, the monster does not necessarily have the afraid timed effect.

That may explain the behavior of the wild cat (level 2) and crow (also level 2) facing a level 50 rogue.

from what I can tell in the code such monsters aren't marked as "afraid" so they won't trigger that check but if I make sure the borg doesn't do it twice in a row he will, hopefully, wait once then approach. If the monster steps away we may see a stutter-y approach until the monster is pinned down. I could add a check for mon level + 25 vs plevel. Not sure it is worth it. Chances of this being a problem is pretty low. I am even having trouble duplicating it using this "attack" at all.

added https://github.com/angband/angband/pull/6516 which should help.