#230 Out-of-Sight Trap Patch

diffs vs svn
open
nobody
6
2009-09-22
2009-08-30
Anonymous
No

Inspired by a recent feature request for more specific descriptions of known but out-of-sight traps. The major change is that the specific type of trap will be reported ("[A dart trap.]", for instance), where it would have previously just been described as "A mechanical trap", "A magical trap" or "A natural trap".

DNGN_TRAP_MECHANICAL, DNGN_TRAP_MAGICAL, DNGN_TRAP_NATURAL and NUM_TRAPS are mostly unused now, in place of more specific dungeon feature types like DNGN_TRAP_DART. For testing general trap categories, you may call the functions "trap_is_mechanical(trap_type trap)", "trap_is_magicial(trap_type trap)" and "trap_is_natural(trap_type trap)". [As a side effect, it is now theoretically possible to have traps belonging to multiple categories, although none are currently implemented.] Undiscovered trap implementation is pretty much unchanged.

There are additional minor changes as well:

-Attempts to disarm traps that can't be disarmed now result in custom messages based on the trap type.
-Because I noticed that the warning prompt for entering a known Alarm Trap specifically asks if you want to step "onto" the trap (as opposed to "into" for all other trap types), I decided to make it so that Alarm Traps aren't triggered by airborne creatures. I don't think that will terribly unbalance anything.

One thing that I wanted to do, but was unable to figure out how to implement (or find the relevant code), was to add a prompt asking for the direction that you want to untrap (or open/attack) when using the (* + direction) notation for the "interact with tile" command. (I think that the code must have been hacked in such a way that a single CMD is sent, like with the chorded Control+Direction notation, when preferably the *+direction notation would cause two CMDs: One to prompt for input, and the second to perform the prompted action.)

Discussion

  • Nobody/Anonymous

    Submitter here, I forgot to mention one thing:

    I wasn't able to test the tiles-version. I wouldn't be surprised if there were some graphical glitches associated with the changes in how out-of-sight trap tiles are represented; if someone could test the patch with the tiles-version of crawl, that would be great.

     
  • dpeg

    dpeg - 2009-08-31

    While you are at it: may I suggest that alarm traps are changed? Currently, they are annoying *after* they went off for the first time. Monsters walking over some alarm trap, time and again, produce unholy message spam. The most modest modification seems to be this:

    Give alarm traps a number of uses (just like ammunition for mechanical traps). Each trigger will reduce that number by one. Remove the trap when the counter is zero.

    This is more an FR but it seems non-controversial; I discussed it a bit on ##crawl.

    Many thanks for the patch! Who are you? :)

     
  • Phony Eponym

    Phony Eponym - 2009-08-31

    > Many thanks for the patch! Who are you? :)
    I guess having a username would make things easier on everyone, huh. :)

    I like the idea of making alarm traps limited-use; I'll try to see if I can code that in when I get home this evening. Actually, it probably wouldn't be difficult to make all traps optionally limited in the number of times they can be set off (with shafts, teleports and Zots defaulting to unlimited uses). That would open some interesting possibilities, like a Translocations spell that turns an unoccupied floor tile into a one-use teleportation trap.

     
  • Phony Eponym

    Phony Eponym - 2009-09-11

    Just a quick update on my progress:

    I am finding more and more that the current approach to how traps are implemented is difficult to maintain and extend. I am considering rewriting the whole trap framework, making 'trap_def' into an abstract class interface, and then having specific traps encoded as sub-classes like 'trap_def_dart' or 'trap_def_teleport'.

    Hopefully when this is done it should be easier to make minor changes to traps of existing types (examples: making traps of certain types harder to evade or disarm based on dungeon level, or setting a specific trap to only trigger once before disappearing), and to add entirely new trap types.

     
  • dpeg

    dpeg - 2009-09-14

    I just wanted so suggest we use the patch but now your last comment seems to indicate otherwise. What to do?

     
  • Phony Eponym

    Phony Eponym - 2009-09-17

    I think it makes sense to wait for the full rewrite; I'll try to get a first draft patch for viewing in sometime this weekend.

     
  • Phony Eponym

    Phony Eponym - 2009-09-22

    Re: Extensive trap rewrite:

    Disregard all that; it's not happening. (I ultimately found the trap codebase just too massive and too deeply bound in with the rest of the code; the amount of effort required just isn't going to be worth the extremely minor tangible benefits that would result.) Sorry for leading you all along like that.

    You're free to merge in the already-submitted patch, of course. It still needs to be tested to see how tile graphics respond to the changes, since I didn't check that.

     
  • dpeg

    dpeg - 2009-09-22

    Thanks for the reply. Don't worry about the missing refactorisation.

    I suggest we take the original patch.

     
  • dpeg

    dpeg - 2009-09-22
    • priority: 5 --> 6
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks