Borg bugs and feature requests

[agoodman]

The code that sets up the inventory items in borg9.c looks identical to that in player-birth.c. Since borg9.c calls inven_carry() on the starting items, the path through that function for a word of recall scroll should guarantee that obj->known is not NULL at that point (in that function combining should be false and in that case obj->known->grid is zeroed out). That leaves an alternate hypothesis, but more painful to debug: obj->known was overwritten between birth and when the borg tried to use the scroll.

Okay so further research showed that it was leather armor that didn't have known set. I think it was just filtering through items to list for the read and this was in inventory. Since it was a mage, the leather armor was either found or bought. If it was found, I can't see a path to not having know set so it must been bought so perhaps I am not creating store items correctly.
or known was overwritten, as you fear.

[agoodman]

another reported crash
Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140185572352000) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140185572352000) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=140185572352000) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=140185572352000, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007f7f7f425476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007f7f7f40b7f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007f7f7f40b71b in __assert_fail_base (fmt=0x7f7f7f5c0150 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55b5156bf6d4 "c", file=0x55b5156bf539 "cave-square.c", line=883,
function=<optimized out>) at ./assert/assert.c:92
#6 0x00007f7f7f41ce96 in __GI___assert_fail (assertion=0x55b5156bf6d4 "c", file=0x55b5156bf539 "cave-square.c", line=883, function=0x55b5156bfa70 <__PRETTY_FUNCTION__.15> "square_in_bounds")
at ./assert/assert.c:101
#7 0x000055b5154d382f in square_in_bounds (c=0x0, grid=...) at cave-square.c:883
#8 0x000055b5154d3b50 in square (c=0x0, grid=...) at cave-square.c:947
#9 0x000055b5154cf858 in map_info (grid=..., g=0x7ffd300a1eb0) at cave-map.c:132
#10 0x000055b515651608 in borg_update_map () at borg/borg5.c:3242
#11 0x000055b5156547d4 in borg_update () at borg/borg5.c:4573
#12 0x000055b51569d9d4 in borg_think () at borg/borg9.c:631
#13 0x000055b5156a2977 in borg_inkey_hack (flush_first=0) at borg/borg9.c:3180
#14 0x000055b5155e106f in inkey_ex () at ui-input.c:228
#15 0x000055b5155e36ea in textui_get_command (count=0x7ffd300a2650) at ui-input.c:1759
#16 0x000055b5155ddef2 in textui_process_command () at ui-game.c:518
#17 0x000055b5155de1d6 in textui_get_cmd (context=CTX_GAME) at ui-game.c:594
#18 0x000055b5155dee33 in play_game (mode=GAME_LOAD) at ui-game.c:921
#19 0x000055b5156b9ae8 in main (argc=1, argv=0x7ffd300a2828) at main.c:540
(gdb)

this one is a little confusing to me since I check square_in_bounds right before calling map_info which asserts grid.x and grid.y are good. map_info is also calling square() before this and it is working. The only thing I can think is that player->cave != cave but I don't know when those can differ.

[backwardsEric]

Okay so further research showed that it was leather armor that didn't have known set. I think it was just filtering through items to list for the read and this was in inventory. Since it was a mage, the leather armor was either found or bought. If it was found, I can't see a path to not having know set so it must been bought so perhaps I am not creating store items correctly.
or known was overwritten, as you fear.

How did the leather armor get through to use_aux() from do_cmd_read_scroll()? The filtering on the object type (cmd_get_item() is called with tval_is_scroll()) should have excluded it before that. From what I see the borg is going through what an ordinary player would when buying which should guarantee that obj->known is not NULL (store.c:1732-1745). The initialization of store contents in borg_resurrect() looks much the same as it does in player-birth.c: calling store_reset().

[backwardsEric]

this one is a little confusing to me since I check square_in_bounds right before calling map_info which asserts grid.x and grid.y are good. map_info is also calling square() before this and it is working. The only thing I can think is that player->cave != cave but I don't know when those can differ.

According to the call stack there, player->cave is NULL. I would have thought the intervals when cave was not NULL and player->cave is NULL would be short and that there wouldn't be a prompt for a player command in those intervals. pre_turn_refresh() (called just before the call to textui_get_cmd() which triggered the crash) does have logic to only update the map if character_dungeon is true (character_dungeon is false in the intervals when cave and player->cave are not to be used) so perhaps borg_think() or borg_update() need to be prepared for cases where they are called when character_dungeon is false.

[agoodman]

... perhaps borg_think() or borg_update() need to be prepared for cases where they are called when character_dungeon is false.

I am trying to figure out what the borg should do in that case. What keypress do you give for "cave still being built"? Space? I think I have to figure out why it is in there like that. It doesn't seem like the code should be getting to inkey_hack if it is in this state.

I am starting to wonder if something went wrong with the build that is giving these errors. Both gdb crashes seem... odd.

[backwardsEric]

I am starting to wonder if something went wrong with the build that is giving these errors. Both gdb crashes seem... odd.

If you are using configure, Makefile.std, or Makefile.osx for the build, the dependencies in Makefile.inc don't include the borg files yet (we could update Makefile.inc now for those dependencies but could also delay that till just before the 4.2.5 release) so the borg/*.o files can get out of date with respect to the headers. I know the addition BI_EMPTY in borg1.h caused some problems with the builds on the Mac until I forced a rebuild of all the borg/*.o files.

[Nick]

If you are using configure, Makefile.std, or Makefile.osx for the build, the dependencies in Makefile.inc don't include the borg files yet (we could update Makefile.inc now for those dependencies but could also delay that till just before the 4.2.5 release) so the borg/*.o files can get out of date with respect to the headers.

I think just update straight away, I'll be doing a final rebuild of Makefile.inc before release anyway.

[agoodman]

ok, I decided the bad cave issue was likely a "resurrection, then get back into borg code before the cave is refreshed". I added some code that will hopefully mitigate the issue.

[agoodman]

... we could update Makefile.inc now for those dependencies ...

I think I am going to need to leave the updating of Makefile.inc to you or Nick. I would have thought it was getting the object list from BASEOBJS which comes from Makefile.inc and has BASEOBJS := $(ANGFILES) $(ZFILES) and ANGFILES is in Makefile.src with ANGFILES = $(ANGFILES0) buildid.o and ANGFILES0 includes the borg files... showing yet again that I don't really get makefiles.

[backwardsEric]

In the attached save, the borg is sitting at the entrance to the general store and repeatedly reading an Enchant Armor scroll but then breaking out of the selection for the piece of armor to enchant (at least for me, the borg will resume that behavior when I reload the save and restart the borg with ctrl-z and then z).

[backwardsEric]

In the borg status window under "Temp Effects", fast casting and heroism use the same line so the string that is displayed is "Heroismt" where the shading of the "t" at the end indicates the status of fast casting.

[agoodman]

In the attached save, the borg is sitting at the entrance to the general store and repeatedly reading an Enchant Armor scroll but then breaking out of the selection for the piece of armor to enchant (at least for me, the borg will resume that behavior when I reload the save and restart the borg with ctrl-z and then z).

Well, borg7.c "borg_enchant_to_h" is trying to read a scroll of enchant ... armor? That ain't right!

[agoodman]

In the borg status window under "Temp Effects", fast casting and heroism use the same line so the string that is displayed is "Heroismt" where the shading of the "t" at the end indicates the status of fast casting.

Checked in a quick fix to this because it was easy. I think the status window probably needs some work. It likely doesn't have all the information it should have on it. I haven't really looked at it at all except to make sure it doesn't crash.

[backwardsEric]

Aim direction and resting

The borg got into a state where, according to the messages window, it is "Resting to recover HP/SP ...", but the last command issued was to aim a wand of annihilation. So the game asks for an aim direction but the borg replies with "&" as if it was responding to the resting prompt. The check, at borg9.c:3013, for the direction prompt doesn't succeed because borg_confirm_target is false. The other conditions in that check are true. I don't know how it got into state. When I escape out and save, reloading the save and restarting the borg has it go along on its merry way.

Not long after that, the borg got stuck again. It was on a down staircase on level 93. The last messages in the borg message window alternated between "Leaving via up stairs." and "Standing on dn-stairs". The game was asking for which wand to aim (only one choice available, a wand of annihilation), but the borg would respond with "<" as if trying to use an up staircase. Escaping out, saving, and then reloading the save and restarting the borg had it proceed.

(It's possible that the cause for the second one is the issue mentioned in the next post. The borg did have chaos dragon scale mail equipped and it was charging so the 'a' for aim a wand may have dismissed the prompt for the breath to use but then the borg was left out of step with the game prompts. I can't say if it was also the cause for the first one as I don't know if borg had equipped the chaos dragon scale mail at that point.)

[backwardsEric]

borg and selectable breath weapons

The borg has chaos dragon scale mail equipped. It seemed to have problems with the prompt about which breath to use (random ('a'), chaos ('b'), or disenchantment ('c')) after activating the armor, but unstuck itself somehow. It later got hung up again at the breath selection prompt. The borg is responding with '2' since it wants to melee the monster there (the last two messages in the borg message window are "Facing Itangast ..." and "Attacking with the weapon 'Mace 'Taratol' ...").

I guess that borg7.c:4283-4288 should be changed. With the game as it is, it would be safe to reply with 'a' to choose a random breath if you don't want to fine tune the breath to the monster's weaknesses. Also the comment there about genocide is misleading, Banishment does not use EF_SELECT.