[Announce] FrogComposband 7.1.salmiak released

[Sideways]

Thraalbee's right; but also, that character you cite switched his secondary realm, studied spells in the new realm, and then switched back to his original second realm having forgotten (and needing to re-study) every spell in it.

[Kodiologist]

Sideways, are you accepting pull requests or patches? It looks like development has been largely you for the past few years, and there's an almost year-old PR that you didn't reply to. https://github.com/sulkasormi/frogcomposband/pull/277

[archolewa]

Sideways, are you accepting pull requests or patches? It looks like development has been largely you for the past few years, and there's an almost year-old PR that you didn't reply to. https://github.com/sulkasormi/frogcomposband/pull/277

He replied on the character dump I ran to test my changes: http://angband.oook.cz/ladder-show.php?id=24022. As well as in the thread itself http://angband.oook.cz/forum/showthread.php?t=10280

He also pulled in one tweak I made to allow people to see all the possible Rage Mage spells in each book. Only being able to see the spells you can learn right now is silly on a class that consumes its books to learn spells.

So I don't feel like I've been ignored (and honestly I made the changes mostly for my own enjoyment, and figured I'd throw them up there for people to see).

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

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

[HugoVirtuoso]

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

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

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

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

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

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

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

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

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

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