Traps, again

[Clearshade]

FYI,
@ now at DL18 and have found following trap types since DL1:
poison gas, acid, blinding gas, poison pit, pit, teleport rune, dart, and summoning rune

I am playing from a download of yesterday March 15.

[PowerWyrm]

I don't seem to be encountering any trap types other than trap doors and pits in the early game. (Messing about in debug mode with scrolls of Create Traps, it seems as if you only get those two types until devel 20, after which summoning traps show up, and then the other types don't seem to show until dlevel 40.)

Also, the trap.txt file has stray extra "visibility:0" lines at the end of the entries for 'summon foe' and 'hellhole'.

Yeah the probability calculation in pick_trap() is incorrect. Say you have 3 traps, first and third one of rarity 1 and second one of rarity 0. The correct probability table would be (100, 100, 200) but it's currently (100, 0, 100) since previous probability is only added for valid traps. Then there's an off-by-one error when picking the trap: if pick = randint0(200) returns 100, the code doing (pick > trap_probs[i]) returns the first trap when it should return the third trap with (pick >= trap_probs[i]) since you have two sets of equal probablility, one of (0-99) and one of (100-199).

Something like this:

for (i = 0; i < z_info->trap_max; i++)
    {
        /* Get this trap */
        struct trap_kind *kind = &trap_info[i];

        trap_probs[i] = trap_prob_max;

        /* Ensure that this is a valid player trap */
        ...

        /* Trap is okay, store the cumulative probability */
        trap_probs[i] += (100 / kind->rarity);
        trap_prob_max = trap_probs[i];
    }

    /* No valid trap */
    ...

    /* Pick at random. */
    pick = randint0(trap_prob_max);
    for (i = 0; i < z_info->trap_max; i++)
    {
        if (pick < trap_probs[i]) break;
    }

[PowerWyrm]

Looks like I might have messed up the trap selection process. Will check.

See above

Other remarks:
- square_note_spot() calls square_reveal_trap() without checking square_issecrettrap() -- maybe that's the reason stuff is detected out of LOS
- square_reveal_trap() does a flat "skill search < trap power", meaning that trap detection is an "on/off" switch -- is that intended?

[Nomad]

Amulet of Searching comes up as "an Amulet of 246:Searching".

[Nick]

OK, thanks for finding all this nonsense everyone (although I'm slightly hurt that my inspired name-change for "Searching has been reported as a bug).

Didn't get to do anything on it as planned yesterday because my dev machine had issues, but will get to fixing soon.

[Nick]

OK, fixed version has been pushed - should be built and on the nightlies page within the next half hour.

- square_note_spot() calls square_reveal_trap() without checking square_issecrettrap() -- maybe that's the reason stuff is detected out of LOS
- square_reveal_trap() does a flat "skill search < trap power", meaning that trap detection is an "on/off" switch -- is that intended?

I'm not sure that checking square_issecrettrap() is needed, but I did it anyway - I need to check the whole logic of that.

Yes, trap detection is meant to be on/off - if the player has sufficient skill, they will always detect the trap, and if not, they never will. There is (usually) some randomness involved in the visibility rating of the particular trap instance, but once the trap is created it's deterministic.

[chknflyrice]

I love that I read the entirety of those posts like I understand any of it.

[Nomad]

Traps are definitely more interesting now, especially in the mid to late game. I just tried to sneak past a sleeping AMHD and stepped on a siren trap. You don't get that kind of drama with always-visible traps!

[Ingwe Ingweron]

I was surprised when a rock dropped on @'s head and he was left stunned. Setting off the undiscovered trap at DL 100 and CL 46 was surprising in itself, but since @ had pStun, why did the rock falling not just cause damage but allow @ to avoid the stunning effect?