Borg bugs and feature requests

[backwardsEric]

Level 7 rogue spell choice

A borg that's a level 7 rogue seemed to get stuck at the prompt for which spell to learn. According to the borg messages, it wanted to study "Stinking Cloud", but the only spell available is "Phase Door", option 'b'. Looking at how the borg responded to the prompt in the debugger, in one instance it responded with 'a' and in another 'd'. At that point I interrupted the borg, saved the game, and then reloaded and restarted the borg. After that, it had no problem learning "Phase Door".

[agoodman]

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.

Ah, this selection must be new or at least new in 4x. It used to be that chaos just did a random breath. I am not sure how easy this fix will be. I am going to have to look at all activations and see how to tell which ones require a selection plus I will need to make sure the calculations on which to use is right in the attack damage estimations.

[agoodman]

A borg that's a level 7 rogue seemed to get stuck at the prompt for which spell to learn. According to the borg messages, it wanted to study "Stinking Cloud", but the only spell available is "Phase Door", option 'b'. Looking at how the borg responded to the prompt in the debugger, in one instance it responded with 'a' and in another 'd'. At that point I interrupted the borg, saved the game, and then reloaded and restarted the borg. After that, it had no problem learning "Phase Door".

not sure what happened here. It should know which spells are learnable and it should be pulling what spells are available at what level from the game.

btw, if you turn on borg_verbose it will tell you what keys it is pressing in the borg messages window if you want to avoid debug.

[agoodman]

I think forcing "a" till I can do a revamp of activations in general is what I should probably do to get a fix in relatively quickly and see if it also fixes the other issues. I have a feeling you are correct about it as a possible cause and they are connected due to it getting keypresses lost trying to activate.

I think the borg activation code in general should be rewritten to be more generic. This likely has the same issue coming up with dragon breath potions and anything else that might have multiple activations. It doesn't look like any artifacts currently do but that could change in the future.

Ugh.

[backwardsEric]

I think the borg activation code in general should be rewritten to be more generic. This likely has the same issue coming up with dragon breath potions and anything else that might have multiple activations. It doesn't look like any artifacts currently do but that could change in the future.

A randart could pick up the WAND_BREATH, DRINK_BREATH, or DRAGON_MULTIHUED, DRAGON_CHAOS, DRAGON_LAW, DRAGON_BALANCE, or DRAGON_SHINING activations. All of those allow for selection of the type of element. In the standard objects, there's potions of dragon breath, wands of dragon's breath, multi-hued dragon scale mail, shining dragon scale mail, law dragon scale mail, chaos dragon scale mail, and balance dragon scale mail that allow for selection of the element.

[agoodman]

A randart could pick up the WAND_BREATH, DRINK_BREATH, or DRAGON_MULTIHUED, DRAGON_CHAOS, DRAGON_LAW, DRAGON_BALANCE, or DRAGON_SHINING activations. ...

Really? I thought the randart at least used to be limited to the activation list of the original artifacts. I think the borg code might count on that. It's list of power bonus for artifacts ** is "has x activation, get y power bonus" and I think the list is from artifact.txt. If a random artifact can have any activation... well, any not on the list won't be used by the borg to start with. I don't think there are scenarios where he would try and get a crash but there certainly could be some I am not thinking of.

** see borg4.c around line 4900 under comment "/* an extra bonus for activations */"

[backwardsEric]

Really? I thought the randart at least used to be limited to the activation list of the original artifacts.

Any activation from lib/gamedata/activation.txt is possible on a randart. As an example, see kineahora's bug report here, http://angband.oook.cz/forum/showpos...6&postcount=28 , about a randart that had the FOOD_WAYBREAD activation (not present on any artifact in the standard set). For the value determination in borg4.c:~4900, one might have special cases but then fall back to using the power field for the activation as the basis for the additional value of that activation. For tactical decisions about when to use an activation, that, in general, would require looking at the effects the activation invokes.

[agoodman]

Any activation from lib/gamedata/activation.txt is possible on a randart. As an example, see kineahora's bug report here, http://angband.oook.cz/forum/showpos...6&postcount=28 , about a randart that had the FOOD_WAYBREAD activation (not present on any artifact in the standard set). For the value determination in borg4.c:~4900, one might have special cases but then fall back to using the power field for the activation as the basis for the additional value of that activation. For tactical decisions about when to use an activation, that, in general, would require looking at the effects the activation invokes.

Well, this will take some work. I can't really just use the "power" field because borg "power" not really the same as an objects power. For example the borg gets 60000 "power" for wielding an unidentified sword at low levels to encourage him to use it to find out what it does. Or 2500 "power" per point of AC up to 15 then 2000 up to 75 then 1500 after that... Just weird numbers made up way back when to influence the borgs decision making. Right now activations generally get a base 500 plus some for damage they do or if they do something that makes the game easier like mapping. The whole power thing could use a rebalance as has been pointed out by the borg doing stupid things like picking the wrong sling or ring. Ah well, on the to-do list. Activations first, power later...

[backwardsEric]

Well, this will take some work. I can't really just use the "power" field because borg "power" not really the same as an objects power.

If there's no clear relationship between the power in activation.txt and the value the borg assigns to an activation, then one approach would be to add a field to activation.txt, say 'borg-value', add the parsing necessary for it in obj-init.c (how parse_act_power() is used there can be an example), and add storage for that field to struct activation in object.h (and if a non-zero default value is desired for that field do that in obj-init.c's parse_act_name()). Then the value of that field can be used rather than if/else block at borg4.c:~4900. Those changes are more intrusive to the rest of the code but fit well with the principle of moving what someone is likely going to want to modify from the source files to the data files.

[agoodman]

If there's no clear relationship between the power in activation.txt and the value the borg assigns to an activation, then one approach would be to add a field to activation.txt, say 'borg-value', add the parsing necessary for it in obj-init.c (how parse_act_power() is used there can be an example), and add storage for that field to struct activation in object.h (and if a non-zero default value is desired for that field do that in obj-init.c's parse_act_name()). Then the value of that field can be used rather than if/else block at borg4.c:~4900. Those changes are more intrusive to the rest of the code but fit well with the principle of moving what someone is likely going to want to modify from the source files to the data files.

That is a possibility but I always dismiss any change that involves changing base code to make the borg work. I have always taken it as a design limit that changing base code for the borg was, in principle, forbidden. The result of this is that there are several arrays and functions I copied into the borg code that could just have the "static" removed from them in the base code. The exception to this is screen saver code and things that have to be in the UI like watching for the ^z.

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.

[agoodman]

Just making sure I understand the way the base code works...

artifacts have activations. random artifacts can have any activation.

ego items might have activations but, from reading ego_item.txt, none actually do.

Other objects just have effects. So shining dragon armor doesn't activate to the DRAGON_SHINING activation, it just has an effect which may or may not match up to an activation (for example, there is no DRAGON_WHITE activation)

[backwardsEric]

That's right. That ego items use activations rather than one or more effects is a fairly recent change (post 4.2.4), see https://github.com/angband/angband/issues/5451 for some background on that.

[backwardsEric]

Borg: necromancers and light sources

With the default borg.txt, started up a necromancer with the borg, and the first messages are "Need to refuel but cant!" and then the borg went to the general store to buy torches. Since light at the player's square affects a necromancer's spell casting failure rate and necromancers can see without a light source, necromancers don't start with a light source and are picky about what light sources (or any gear with a bonus to the light radius > 1) they use. I haven't looked at how to adjust borg.txt to account for that.

[backwardsEric]

Attached is a save file where, using the default borg.txt, the borg character gets caught bouncing back and forth between a down stair and pile of rubble next to a vein. Eventually that loop tightens to back and forth diagonal moves next to the pile of rubble before the character dies from starvation.

[agoodman]

Attached is a save file where, using the default borg.txt, the borg character gets caught bouncing back and forth between a down stair and pile of rubble next to a vein. Eventually that loop tightens to back and forth diagonal moves next to the pile of rubble before the character dies from starvation.

okay, back from traveling and taking a look at this.

a quick debug says it seems to be flowing toward the "dark" trying to find a up stairs. Forbidden from going down because it is low on food. It can't dig because that uses too much food/energy so it runs back to the stairs it knows. Rinse, lather, repeat.
I can try a couple of things here...
1) it should explore a new area if it checked and can't dig
2) it shouldn't make a goal of something it needs to dig if it can't dig
3) at some point it if it is hungry enough, it should dig.

btw, you have "base delay factor" set to 40 (= d) so he is gonna be slow.