Borg bugs and feature requests

[agoodman]

Hey, I figured I would create a thread to track borg bugs and give an update on bugs that have been worked on

The following is checked into the borg_4x fork and a merge request has been created for V.
1) a fix to eating so more things, including potions of slime mold juice, will be snacked on when just "hungry"
2) a fix to eating when starving to include more things as above
3) a fix to making a hole in the inventory to not overflow integers
4) a fix to making a hole in the inventory to prioritize heavy objects
5) a fix to casting a glyph when just "playing with spells"

being worked
1) stepping on lava
2) dynamic calculation

[agoodman]

speaking of dynamic calcs in borg.txt

I really dislike the design of this stuff right now (I can say that without fear of insulting the designer... I did it years ago. Not sure what younger me was thinking). I was considering something like

AnyClass
[
    Power
    [
        value(trait, afuel): range(0, 6): reward(60000)
        value(trait, afuel): range(7, 10): reward(6000-(count()*100))
	value(trait, food): range(1, 1): condition(value(trait, ishungry) or value(trait, isweak)): reward(100000)
    ]

    Depth Requirement
    [
        depth(10): condition((value(potion, Cure Critical Wounds) + value(potion, Cure Serious Wounds)) > 2 or value(trait, clevel) > 30)
    ]
]

Warrior
[
    Power
    [
        value(trait, afuel): range(0, 6): reward(60000)
    ]
]

one major problem is formulas. Right now the are in reverse polish notation. RPN is really easy to parse and code for but a PITA to write and support. An example is

FORMULA072=_ITEM324 _ITEM327 + 3 >= 3 * 500 *
so, converting that to the new variables (same RPN) would be
Formula072 = value(staff, power) value(staff, holiness) + 3 >= 3 * 500 *
or, in a format people understand
Formula072 = ((value(staff, power) + value(staff, holiness)) >= 3) * 500 * 3
so if the total number of staffs of power + staffs of holiness is 3 or more, you get 1500 power points.
The problem is that parsing and calculating the formula written common algebraic notation is not so easy, especially if I try to take order of operations into account.

and when it comes to the general format of the values, I started considering JSON or something similar but the parsers for those are big and complicated and it seems like a bad idea to make angband dependent on an outside library just for the borg. Seems like a non-starter.

I am still thinking on this but welcome ideas both on formula formatting and parsing and on the general format of a "dynamic borg power language"

BTW, this got bumped in priority in my eyes because one of the first posts when I announced the resurrection of the borg was @Siemelink asking about editing borg.txt. Gotta give the users what they want.

[backwardsEric]

Null pointer use - borg6.c:6526

With 4.2.4-325-ge46382202 compiled from source on macOS with OPT set to "-g -O0 -DUSE_STATS -fsanitize=address -fsanitize=undefined", had the borg stop on a null pointer use exception from the undefined behavior sanitizer. The call stack at the point of the exception was

1. borg_launch_bolt_aux(y=46, x=77, rad=2, dam=144, typ=6, max=20, ammo_location=0) at borg6.c:6526:32
2. borg_launch_bolt(rad=2, dam=144, typ=6, max=20, ammo_location=0) at borg6.c:6633:51
3. borg_attack_aux_rod_bolt(sval=9, rad=2, dam=144, typ=6) at borg6.c:7333:11
4. borg_attack_aux(what=63) at borg6.c:8725:13
5. borg_attack(boosted_bravery=false) at borg6.c:9277:13
6. borg_think_dungeon at borg8.c:4766:9
7. borg_think at borg9.c:643:13
8. borg_inkey_hack(flush_first=0) at borg9.c:3180:13
9. inkey_ex at ui-input.c:228:12
10. textui_get_command(count=0x00007ff7bfefd820) at ui-input.c:1759:8
11. textui_process_command at ui-game.c:518:15
12. textui_get_cmd(context=CTX_GAME) at ui-game.c:594:3
13. play_game(mode=GAME_LOAD) at ui-game.c:921:4

At the point of the exception, k_ptr was NULL, *ag was { feat = 1, info = 1, glyph = false, store = 255, take = 1, kill = 0, hmmm = 0, xtra = 0 }, and *take was { kind = NULL, known = false, seen = false, extra = false, orbed = false, x = 0, y = 0, when = 0, value = 0, tval = 0 }, (rx, ry) was (75, 46), (x2, y2) was (77, 46), and the player's grid was (77, 36). There was a cutlass (tval = 11; sval = 5) at (75, 46) in both cave and player->cave. I've attached a clipped screenshot at the point of the crash though the grid in question is just outside what's displayed.

[Pete Mack]

There is no location zero in the quiver. It starts at 1, unless you have inscribed ammo.

[Estie]

A quick way to vastly improve the borg perfomance:

Once the item feeling is disclosed, leave the level if its not high enough.
High enough would be something like
3+ for dlvls 1-10
5+ for dlvls 11+

[agoodman]

A quick way to vastly improve the borg perfomance:

Once the item feeling is disclosed, leave the level if its not high enough.
High enough would be something like
3+ for dlvls 1-10
5+ for dlvls 11+

There is code to change the amount of time a borg will explore levels based on the level feeling. It doesn't work great because there are so many reasons a borg might decide to hang out, scumming money, lacking certain traits, etc.

[agoodman]

Null pointer use - borg6.c:6526

It looks like the borg was launching an attack at something it hadn't encountered yet (kind is null). I can add a check for that.

[agoodman]

testing dimension door was also an issue... fixing

[Estie]

There is code to change the amount of time a borg will explore levels based on the level feeling. It doesn't work great because there are so many reasons a borg might decide to hang out, scumming money, lacking certain traits, etc.

You can scum for money on a different level, with increased chance to find something good.

Whatever the reason is to be on the particular level, if the level feeling is inferior and there is no emergency, go to the next staircase and change level. Continue with whatever you were doing on the new level. I might be underestimating the difficulty of making him do this, but if its being done, it must improve the borg's performance.

[backwardsEric]

It looks like the borg was launching an attack at something it hadn't encountered yet (kind is null). I can add a check for that.

From what I understood in the code, it was the object's kind stashed in the borg_takes array that was NULL (thus leading to k_ptr being NULL when it was dereferenced at borg6.c:6526. I didn't dig enough to figure out why either that element of the borg_takes array hadn't been populated appropriately or the array index stashed in ag->take was not right.

[agoodman]

From what I understood in the code, it was the object's kind stashed in the borg_takes array that was NULL (thus leading to k_ptr being NULL when it was dereferenced at borg6.c:6526. I didn't dig enough to figure out why either that element of the borg_takes array hadn't been populated appropriately or the array index stashed in ag->take was not right.

I think the item in the borg_takes array is zero'd when something happens that means the borg needs to forget the item... perhaps it was destroyed in a previous fireball. I thought the code that did that also removed it from the grid array. Not sure how it could be blank in borg_takes but still exist in borg_grids though other areas of the code seem to expect it to happen sometimes and just check for it Like if we look at borg6.c's borg_flow_take() it does
/* Skip dead objects */
if (!take->kind) continue;
I am not sure if I should just be doing the same in this spot or track down why an item would be in the grid but not in the takes. It might have to do with stacks or ignored items...

I have been wizarding up L50 mages to run them for a while and see if I can duplicate this issue but so far no luck.

[backwardsEric]

I think the item in the borg_takes array is zero'd when something happens that means the borg needs to forget the item... perhaps it was destroyed in a previous fireball. I thought the code that did that also removed it from the grid array. Not sure how it could be blank in borg_takes but still exist in borg_grids though other areas of the code seem to expect it to happen sometimes and just check for it

One place where borg_takes is cleared and the grid array is not modified is borg8.c:4484.

[agoodman]

One place where borg_takes is cleared and the grid array is not modified is borg8.c:4484.

interesting. That code goes back as far as I have borg source for (3.4.0. borg goes back to 2.8.0 but I don't have the source for it) Easy enough to make that go through borg_delete_take and borg_delete_kill and that seems to work but I am not 100% sure that is the only place. I can add the check all the other places do as well and that big hammer fixes it. Well, I think that is the best path for now till I can track other places this might be happening.

[agoodman]

Program received signal SIGSEGV, Segmentation fault.
gear_object_for_use (p=0x556fbbfc8c40, obj=0x556fbc2b4580, num=1, message=false, none_left=0x7fffd5a66f24) at obj-gear.c:530
530 bool artifact = (obj->known->artifact != NULL);
(gdb) bt
#0 gear_object_for_use (p=0x556fbbfc8c40, obj=0x556fbc2b4580, num=1, message=false, none_left=0x7fffd5a66f24) at obj-gear.c:530
#1 0x0000556fb9e05c3a in use_aux (cmd=0x556fba0724c0 <cmd_queue+2816>, obj=0x556fbc2b4580, use=USE_SINGLE, snd=0) at cmd-obj.c:660
#2 0x0000556fb9e06052 in do_cmd_read_scroll (cmd=0x556fba0724c0 <cmd_queue+2816>) at cmd-obj.c:747
#3 0x0000556fb9e02d67 in process_command (ctx=CTX_GAME, cmd=0x556fba0724c0 <cmd_queue+2816>) at cmd-core.c:349
#4 0x0000556fb9e02e73 in cmdq_pop (c=CTX_GAME) at cmd-core.c:378
#5 0x0000556fb9e25c40 in process_player () at game-world.c:975
#6 0x0000556fb9e25fa5 in run_game_loop () at game-world.c:1085
#7 0x0000556fb9f05e38 in play_game (mode=GAME_LOAD) at ui-game.c:922
#8 0x0000556fb9fe0ae8 in main (argc=1, argv=0x7fffd5a67248) at main.c:540


From what I can tell this has to do with the resurrection code and I am probably not setting the known flag on all the equipment. I thought I had this fixed but apparently not.

[backwardsEric]

From what I can tell this has to do with the resurrection code and I am probably not setting the known flag on all the equipment. I thought I had this fixed but apparently not.

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.