Borg bugs and feature requests

[eschiss1]

Re #131, 134. Uploading a truncated log file that shows some of what happened, where the dungeon map probably contains the most information- will see if I can capture this at a point that shows what's happening more informatively rather than when the "infinite loop" is already well underway at 5 a.m. Not sure if I remember anything flowing towards me, but I may be misremembering.

[agoodman]

Re #131, 134. Uploading a truncated log file that shows some of what happened, where the dungeon map probably contains the most information- will see if I can capture this at a point that shows what's happening more informatively rather than when the "infinite loop" is already well underway at 5 a.m. Not sure if I remember anything flowing towards me, but I may be misremembering.

He is waiting for the "B" (crow) to approach. So, why isn't it approaching? I wonder if it is afraid or something. I can check for status afraid or stunned or confused. It is only supposed to do this when the monster is within a step so I will also add a "don't do this twice in a row" check. I am also going to change the message to
"waiting for monster {name} to approach"
just so we can be sure we know what we are waiting for and we already know what square we are on so that seemed like useless information.

[eschiss1]

it was either asleep, or in a holding pattern with its holding pattern, or... hrm. Good point. It's happened once (with wildcats) since but I'll see if I can find out next time...

[backwardsEric]

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.

[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.

[eschiss1]

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

[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.)

[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]

Will do and thanks. Thumbs-up

[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.

[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]

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.

[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.

[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]

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.