Angband 4.2.4

[Estie]

I don't really like this proposed solution, as it could be very problematic in a combat situation. Failing the device, I don't want my @ to keep trying ad infinitum while some monster is breathing down @'s neck. @ should be able to switch tactics in the heat of the battle, rather than mindlessly trying to repeat an action that didn't work immediately.

I completely agree, and have pointed out above that I dont like it either. But it would still be _much_ better than the current situation.

As ewert pointed out, it wouldnt be as bad as you make it to be - youd be disturbed by the same things that disturb your digging and you could set the # of attempts lower than for digging, maybe 10 or 20.

[ewert]

I don't really like this proposed solution, as it could be very problematic in a combat situation. Failing the device, I don't want my @ to keep trying ad infinitum while some monster is breathing down @'s neck. @ should be able to switch tactics in the heat of the battle, rather than mindlessly trying to repeat an action that didn't work immediately.

Digging already disturbs the repeat if monsters do stuff. The same mechanic could/should be used for devices.

I agree with the idea that failing devices when there is no disturbances around the character is a quality of life issue rather than a tactical issue, and I would be very happy to have repeat-attempt-until-success-or-disturbed be the mechanic.

[Ingwe Ingweron]

...For the latter, if you really insist on there being that bad device skill, it could be automated like digging; so the game retries without forcing the player to input action - react - input - react _all the time_....

I don't really like this proposed solution, as it could be very problematic in a combat situation. Failing the device, I don't want my @ to keep trying ad infinitum while some monster is breathing down @'s neck. @ should be able to switch tactics in the heat of the battle, rather than mindlessly trying to repeat an action that didn't work immediately.

[Estie]

Lategame is mostly activating devices, especially for the warrior.
Now tele other is a case where time is of the essence; but most other actions are not: typically, you have time to use rods/staves of detection, restoration, speed.

For the latter, if you really insist on there being that bad device skill, it could be automated like digging; so the game retries without forcing the player to input action - react - input - react _all the time_. Or maybe activation has high chance of success, but takes more than 1 turn, more or less inversly proportional to the device skill. I dont really like these ideas, but something would have to happen.

The level 20 troll warrior finding an ood rod of restoration can have as low a chance to activate it as you like; but at high level, when eventually all the items become available, you give the player the choice to play suboptimally or go insane. This is exactly the same issue as digging, and in that case the devs had mercy.

[Nick]

Maybe I have missed it, but please someone tell me _why_ all this was started ? What was wrong with the existing parameters ?

Because the old formula had no way to make really bad device skill possible just by adjusting the data files. I also liked the shape of the curve from the new formula, which places most of the improvement in the middle game.

If people really hate the reduced device skill, it can be fixed by adjusting the data files now (probably by improving warrior device skill).

[Estie]

It is 18/70. I remember that the other H-troll warrior I played had absurdly high int (18/*** starting in midgame) thanks to randart fickleness, which would explain why I didnt notice anything amiss.

Before the change, H-troll warrior already had the worst device skill and it was arguably the biggest detriment to that race/class combo. There is no need to further push that theme to the point where playing the it becomes frustrating.

I did read through some of the above linked threads about this topic; there are many posts about how to achieve it, but I didnt find anything speaking to the why of the matter.

Maybe I have missed it, but please someone tell me _why_ all this was started ? What was wrong with the existing parameters ?

[Nick]

Well, its borderline unplayable. It feels like playing with server lag, only much worse.

Why was activation chance lowered ?

Here is where the original discussion about it happened; subsequent complaints appear in multiple threads

[Ingwe Ingweron]

So I am playing a half troll warrior and any item I want to activate takes an average of 3 tries. Has there been a global change to activation chance ?

What is your @'s Intelligence? Starting out, Half Trolls are incredibly stupid. They suck at activating magic items for quite awhile until they get their intelligence up. To me, that seems appropriate.

[Estie]

Well, its borderline unplayable. It feels like playing with server lag, only much worse.

Why was activation chance lowered ?

[Sphara]

So I am playing a half troll warrior and any item I want to activate takes an average of 3 tries. Has there been a global change to activation chance ?

Horrible activation chance for certain items was already in 4.2.3. version.

http://angband.oook.cz/forum/showthread.php?p=154790#post154790

[Selkie]

So I am playing a half troll warrior and any item I want to activate takes an average of 3 tries. Has there been a global change to activation chance ?

But you can see the activation chance when you 'e' look at your inventory. Is it around 50 per cent? A half troll warrior is going to have pretty much the lowest activation success in Angband

[Estie]

So I am playing a half troll warrior and any item I want to activate takes an average of 3 tries. Has there been a global change to activation chance ?

[backwardsEric]

Maybe it's just the SDL Sound/Mixer that has been compiled without .mp3 support? I don't know how to check that easily without writing & compiling some code.
We can migrate this discussion on the git bug tracker if you prefer?

That's possible. SDL mixer is getting the mp3 support from libmad0 on Debian. Slackware's description of the libraries linked in by the SDL package doesn't seem to include a library that provides mp3 support. In any case, the cleanest solution to this would be in SDL mixer: Mix_LoadMUS() is the one that acquires the file descriptor and doesn't release it when some errors occur.

Also, if you want to switch back to the SDL2 front end, the most recent nightly build, https://github.com/angband/angband/r...4-7-g3097e3fd8 , fixes the problem with editing keymaps that you found.

[animal_waves]

Which Linux distribution is this? Do you know which version of SDL and SDL mixer are installed?

I'm using Slackware 15.0, which is shipped with SDL 1.2.15, SDL Mixer 1.2.12 and SDL Sound 1.0.3.
SDL Mixer is also patched with libmikmod (http://mikmod.sourceforge.net/) for whatever reason.

https://slackware.nl/slackware/slackware-15.0/source/l/sdl/

You can find the whole build process (including compilation options if that matters) here:

https://slackware.nl/slackware/slackware-15.0/source/l/sdl/sdl.SlackBuild

What I'm seeing on Debian 11 (with Debian's packaging of libSDL 1.2.15 and libSDL-mixer 1.2.12) is one file descriptor opened the first time a sound is played and with 200-some sounds listed in lib/customize/sound.prf that wouldn't be enough to hit the limit on the number of open file descriptors.

That's also the case on my Debian 9 system: only one file descriptor is opened per .mp3 file, even if the said file is played multiple times.
On the problematic system, the process open a file descriptor each time a sound must be played (and fails to plays it), even if the descriptor for said file is already opened.
So, after trying to play +- 10XX sounds (which may be about an hour of gameplay?) the limit is reached and the process is not able to write anything anywhere.

Maybe it's just the SDL Sound/Mixer that has been compiled without .mp3 support? I don't know how to check that easily without writing & compiling some code.
We can migrate this discussion on the git bug tracker if you prefer?

[backwardsEric]

99,99% of those 1025 files are the .mp3 files from the sound folder opened several times each (the use_sound option is set to yes), which I'd say may be a bug?

Which Linux distribution is this? Do you know which version of SDL and SDL mixer are installed?

What I'm seeing on Debian 11 (with Debian's packaging of libSDL 1.2.15 and libSDL-mixer 1.2.12) is one file descriptor opened the first time a sound is played and with 200-some sounds listed in lib/customize/sound.prf that wouldn't be enough to hit the limit on the number of open file descriptors.