[Announce] FrogComposband 7.1.salmiak released

[Sideways]

Is there a limit to how heavily a monster could get buffed in terms of mpower or max HP? If so, it could make sense to calculate a maximum on that basis, since the idea is to show the player the worst case. No doubt some players would notice that the maxima are rarely achieved in practice, fail to take them seriously, and then eventually actually get hit for that much or close to that much, but them's the breaks.

In terms of random max HP that would make sense; though practically all major breathers, even the non-unique ones, have fixed max HP in any case.

Mpower, though, can go absurdly high. It's limited only by being a signed 16-bit integer, which means the highest value it can take is 3276.7%. That would mean multiplying many of the maxima (everything not otherwise capped) by 32.767 for display...

[Kodiologist]

Is there a limit to how heavily a monster could get buffed in terms of mpower or max HP? If so, it could make sense to calculate a maximum on that basis, since the idea is to show the player the worst case. No doubt some players would notice that the maxima are rarely achieved in practice, fail to take them seriously, and then eventually actually get hit for that much or close to that much, but them's the breaks.

[Sideways]

The spoilers use a slightly different format, outright giving the damage as 1d80+50.

In theory, that would be a nice format for the regular monster recall too; but there are some problems with it. One, an average damage is easier to adjust for resistances. Two, if I started displaying mana bolt damage as a range, say 51-130, I'd have to start displaying almost all spell damages as ranges... since even spells (or breaths) with non-random initial damage effectively develop a (small) range when resistance randomness is accounted for. Three, if I *did* display almost everything as a range, it would give players false assurance and they'd be even more surprised to see a monster hit them for more than the upper limit.
Which would still happen occasionally, when the monster has high mpower or is a non-unique breather with higher than average HP...

[Kodiologist]

Ooh, so it's mean damage. The interpretation of it doesn't seem to be described in the help section about recall, so yeah, I assumed it was like vanilla. I agree with Pete that the maximum is more informative, even though it's less representative, since what you need to know for tactical decision-making is what you can survive. But it would also be quite reasonable to include both the mean and the maximum, if there's room.

[Pete Mack]

1d80 is scary high variance. Ouch! I think I prefer angband's use of max damage for lore, even for low variance attacks that can never actually reach it.

[Sideways]

I just got killed by the mana bolt of a dark elven warlock. With easy_damage, I saw a message saying I took upwards of 120 damage, which is weird because the monster lore says "Mana Bolt (90, 1x)", which if I understand correctly means that the maximum damage is 90. But, I had a speed disadvantage (+2 for me vs. +10 for the typical dark elven warlock), so maybe the message summed the effect of several mana bolts.

90 is the average damage; mana bolts from a typical dark elven warlock are 1d80+50, so you rolled close to the upper limit of that range.

[Kodiologist]

I just got killed by the mana bolt of a dark elven warlock. With easy_damage, I saw a message saying I took upwards of 120 damage, which is weird because the monster lore says "Mana Bolt (90, 1x)", which if I understand correctly means that the maximum damage is 90. But, I had a speed disadvantage (+2 for me vs. +10 for the typical dark elven warlock), so maybe the message summed the effect of several mana bolts.

[Kodiologist]

Oh right, I keep forgetting that travel already exists. I should use it more often.

[Sideways]

In a 'band, I think the obvious way to start on autoexplore would be to expand the run code. Move the player in a path to the nearest unexplored accessible square, using the same stop criteria as for running, but ignoring forks.

I think expanding the travel code would be the more natural option, since the travel code, unlike the run code, already contains all the pathfinding needed. (It would need several hacks to be used by the autoexplorer; at a minimum, one to allow unknown areas as travel targets and one to keep going upon reaching the first target; but the second one could be borrowed from autoget.)

Writing a functional autoexplorer based on existing travel code would not be very difficult at all. More difficult would be deciding when it should stop, exactly which areas it should count as unexplored, how it should treat secret doors and areas hidden behind them, adding in a variety of options allowing the player to customize its behavior, etc.

[Kodiologist]

Can you elaborate more about what do you mean autoexplore? How do you want it to work? Any non-*band examples?

DCSS is famous for its autoexplore. The old joke is that you can play DCSS with just two keys: O to autoexplore and Tab to attack the nearest monster. ToME 4 also has fancy autoexplore. In both cases, the basic idea is to move the player towards unexplored regions of the map and stop if a monster is seen. Once the whole map is explored, autoexplore walks you to a staircase. When items appear in DCSS, autoexplore walks you to each item once, so you can decide if you want to pick it up, and thereafter ignores it. ToME 4 is generally played with autopickup on because there's an item that lets you sell stuff automatically, prompting you what to keep. (For the record, Angband-style no-selling is way better than automatic selling.)

In a 'band, I think the obvious way to start on autoexplore would be to expand the run code. Move the player in a path to the nearest unexplored accessible square, using the same stop criteria as for running, but ignoring forks.

As Sideways says, though, autoexplore could be dangerous. In a 'band, generally detection magic is important, and waiting until you see monsters face-to-face is asking for trouble. So it would only really be useful for the early game for non-squishy characters, or if you were on a dungeon level on which you knew there were no serious threats.

[Nick]

The problem with autoexplore in *bands is that it causes players to die.

(To be clear, that doesn't mean it couldn't be implemented; indeed, it could fairly easily build on the existing travel code used by commands like H, *j and ]J. You should be aware of the minor drawback involved, though...)

Vanilla has movement by mouse which is kind of a primitive auto-explore. You click somewhere and the character will try to run there - normal run interruption rules apply.

[Sideways]

Okay, thanks for explaining. If I submit a PR soon, it will probably just be code cleanup, so it shouldn't require any laborious playtesting to review. Autoexplore, even a very simple version of it, sure would be nice, but it would be challenging for me to implement. I'm decent at C, but I've never edited a 'band before.

The problem with autoexplore in *bands is that it causes players to die.

(To be clear, that doesn't mean it couldn't be implemented; indeed, it could fairly easily build on the existing travel code used by commands like H, *j and ]J. You should be aware of the minor drawback involved, though...)

[HugoVirtuoso]

Can you elaborate more about what do you mean autoexplore? How do you want it to work? Any non-*band examples?

[Kodiologist]

Okay, thanks for explaining. If I submit a PR soon, it will probably just be code cleanup, so it shouldn't require any laborious playtesting to review. Autoexplore, even a very simple version of it, sure would be nice, but it would be challenging for me to implement. I'm decent at C, but I've never edited a 'band before.

[Sideways]

I wrote in part of archolewa's pull request; and the rest of it got left in limbo because I did not want to either reject or accept it in its entirety, and was not sure which other bits to accept or adapt (even after discussing potential ideas with archolewa) without further personal play-testing of rage-mages, which I lacked the time for at that point. While development of FrogComposband is still continuing, I've been too busy with other stuff for much progress to happen lately.

In general I write all my own code and like it that way; but I will pay attention to any pull requests submitted, archolewa's one just couldn't be completely resolved without a much deeper look. If you want to submit a pull request (or propose code changes in some other way!) you are welcome to do so; but be aware I'll probably be even more busy in the next couple months than I've been so far.