On-Ground Traps: a way to make them

Discussion in 'Assorted Tech' started by Agetian, Jun 28, 2006.

Remove all ads!
  1. Agetian

    Agetian Attorney General Administrator

    Joined:
    Aug 14, 2004
    Messages:
    2,526
    Likes Received:
    0
    After spending a lot of time developing the Editor's Helper Script (ed.py) I'd like to attempt to come up with a solution to create an on-ground trap using some weird scripting. Unfortunately, I don't have much time to code anything outside of ToEEWB right now, so it's mostly a DIY type of thing (do-it-yourself ;)), but I'd like this to get discussed in case we need to create on-ground traps in the future. I'll try to help as much as I can.

    So...
    First of all, every on-ground trap created with this method will have an activation rectangle. When a player enters this rectangle, the trap is activated and some code for the trap is executed (after which the trap may be disposed). In order to search for such a trap and disable it, we will need a special tool (a new item, like "Thieves' Trap Detection Tool" or something, I dunno) which, upon being used (san_use), will make a roll against the neighboring traps' DC (just search the surrounding area for trap objects with the given ID, and, if any are found, roll against their DC which can be stored in one of the unused padding fields - like, obj_f_item_pad_i_1 or whatever they are called). If the trap is detected, a floating line may be sent (or maybe a dialog with the trap object may be started) saying that the trap is found and presenting an option to disable the trap. Afterwards, it's pretty straightforward - make another roll for Disable Device vs. the given DC which may be stored in yet another padding field, and if successful, dispose of the trap object.

    First of all, whenever a trap object is spawned, its heartbeat must start a routine which will check for player's presence every few milliseconds (say, set a time event for every half-a-second (500ms) to detect whether a player is within the trap object's activation rectangle). The routine that can be called to find out if the player coordinates (X,Y) correspond to a certain rectangle RECT (which is the rectangle denoting the activation area for our trap) can be done, for example, like this:

    Code:
    def coords_are_in_rect(x, y, rect):
     	if ((x >= rect[0]) and (x <= rect[2]) and (y >= rect[1]) and (y <= rect[3])):
     		return True
     	else:
     		return False
    
    RECT here is defined as a tuple of four elements (x0, y0, x1, y1) - for example, a Python tuple (0,0,100,100) can be used to denote a rectangle from (0,0) to (100,100).

    So, for example, later we can check whether the given player, for example, party[0], is within the activation rectangle by using the following simple code:

    Code:
    x,y = location_to_axis(game.party[0].location)
    rect = (505, 457, 520, 490)
    activates_trap = coords_are_in_rect(x, y, rect)
    
    If (x,y) are within the rectangle from (505,457) to (520,490), 'activates_trap' will contain 'True', otherwise it'll contain 'False'. This way we can easily tell if a certain player (or another object, e.g. NPC or a monster if necessary) has entered the activation area for a trap and, therefore, needs to make a saving throw.

    The time event is used in order to make constant checks for objects inside the activation area. Many different time events at the same time, running fast enough (500ms and faster), can cause slowdowns, but my tests have showed that you can have a bunch of such time events (at least three or four) on the same map, running at a decent speed and at the same time writing out time-critical information to the disk, and still experience literally no slowdown. So, I think it'll be possible to create at least a few such traps per map without causing visible gameplay slowdown.

    The time event itself can be done in a way much similar to the way sector painting is done in my Editor Helper's Script (check out the blk_on, blk_core, blk_off routines in Ed.py for instance). Whenever a trap object is disposed of, it stops sending time event routines and, therefore, can no longer be activated. Whenever it's activated, it can first execute the trap code on the activating object (which can easily be gotten by iterating over player objects within the trap's activation rectangle at the time a time event is created, and applying certain bad effects to them), and then dispose of itself if necessary.

    This may be a good start. Global flags/variables, as well as object's padding fields may be used to store some temporary or permanent data about the trap, such as its detection/disable DCs and so on.

    I hope this can get us started on the way to creating some ground traps. ;)
    Let's discuss this, if anyone feels up to it and thinks it's interesting.

    - Agetian
     
    Last edited: Jun 28, 2006
  2. rufnredde

    rufnredde Established Member Veteran

    Joined:
    Apr 8, 2006
    Messages:
    266
    Likes Received:
    1
    I'll try this out in my next release, it looks like a useful script, have to implement it then work out the details of how to find it, though, see how it reacts to different actions in game. It will be nice to just lay something out that a party can walk right into and save or die:). Call it the End Slides trap, cause that where it takes you:)

    But seriously though this has a lot of possibilites as a trap or even as a warning alarm to bring critters running. There is alot to think about though, when it comes to detection, example does the racial bonus for elves, come into play here, as far as finding secret things, and...

    Any ideas anyone has regarding this, please go ahead and post them. It doesn't matter if you understand the code. I'm looking for how you would like to see it in the game as well.

    I'll talk to you about this soon Ag, and anyone else that is interested in seeing this in the game:)
     
  3. Kalshane

    Kalshane Local Rules Geek

    Joined:
    Aug 6, 2004
    Messages:
    1,650
    Likes Received:
    0
    I know this is pretty much completely unrelated, but the topic made me think of this.

    Back in the day Livonya removed the XP awards for setting off traps because the game would keep awarding the XP over and over again.

    Is there any way to make the traps function like the majority of them in D&D function (goes off once and then it's done until it's manually reset) and restore the XP award? The problem in the original game wasn't the XP award so much as all the traps functioning like only the most advanced ones should: automatically reseting themselves and going off again and again.
     
  4. Agetian

    Agetian Attorney General Administrator

    Joined:
    Aug 14, 2004
    Messages:
    2,526
    Likes Received:
    0
    Yup, all of these definitely need to be worked out, but there's nothing impossible here since we have the possibility to get the race of the player and then make an IF-ELSE branch that would do something extra for elves, and so on. :)

    I'm glad you liked the idea, I really hope this will get developed with time.

    - Agetian
     
  5. Agetian

    Agetian Attorney General Administrator

    Joined:
    Aug 14, 2004
    Messages:
    2,526
    Likes Received:
    0
    Btw, I just reviewed my old Editor's Helper Script (ed.py) code and found out that the time events in there happen every 10 milliseconds (1/100th of a second) and yet no slowdowns are experienced during the painting. This opens up some room for opportunities. ;)

    An extract from _blk_on_core() in ed.py (adding a time event to happen at every 10ms):

    Code:
    game.timeevent_add(_blk_on_core, (), 10)
    
    - Agetian
     
  6. rufnredde

    rufnredde Established Member Veteran

    Joined:
    Apr 8, 2006
    Messages:
    266
    Likes Received:
    1
    I happily disagee with you on this point Kalshane as this is exactly the kind of feedback I asked for when I said, "It doesn't matter if you understand the code. I'm looking for how you would like to see it in the game as well." This is a fine example of what you would like to see in the game.


    Yes, would be my initial answer to that, but I'll have to look closely through the code, to see exactly how it is implemented, and why Livonya chose that method of fixing it to begin with. But from where I am sitting right know, I don't see why I just can't add a virtual switch that needs to be manually reset and restore the XP.

    Gets on soapbox, this is exactly what I mean about the value of feedback, no one not even the best, can think of everything all the time, and while some others may be able to read minds, I can not. Listening to feedback is my only option:)Climbs off soapboxThanks and I'll see if I can get you a positive result on that soon. Could be a few days as getting 5.0.0 in the can is top priority at the moment.
     
  7. Zebedee

    Zebedee Veteran Member Veteran

    Joined:
    Apr 2, 2005
    Messages:
    1,755
    Likes Received:
    0
    Hmm. Could this trap be used to cast a web spell and then have spiders appear from above? And could a successful detection then be used to justify getting rid of that awful automatic surprise bonus spiders always receive?
     
  8. Shiningted

    Shiningted I want my goat back Global Moderator

    Joined:
    Oct 23, 2004
    Messages:
    11,798
    Likes Received:
    39
    A tool that had to be 'used' would be a pain. Surely we could simply regard this is a function of thieves tools?

    I think - just an idea - this would work better backwards, like spell targetting. Do it all from the trap: trap checks to see if someone is in range, if they are, they check to see if it is a thief with tools equipped in the tools slot: if it is, make a DC check with masterwork tools, racial bonuses etc taken into account.

    Perhaps one of the checks could be for sneaking: any thief 'sneaking' could be assumed to b moving slowly and thus checking for traps. Admittedly a thief sneaking past monsters has other things on his mind, but hitting 's' and moving forward to check for traps rather than having to open your inventory and crack out a tool - and do it again and again - sounds more playable to me.

    Just my ideas. If we can get this going, I promise to trap the hell out of the Keep to make it worth the effort :D
     
  9. Agetian

    Agetian Attorney General Administrator

    Joined:
    Aug 14, 2004
    Messages:
    2,526
    Likes Received:
    0
    Yup, sounds like a good idea, Ted! :) Any other opinions, btw? I see this as a better solution (from the player's point of view) and also a solution that might require less coding.

    - Agetian
     
  10. Kalshane

    Kalshane Local Rules Geek

    Joined:
    Aug 6, 2004
    Messages:
    1,650
    Likes Received:
    0
    The problem with this is thieves tools aren't used to find traps, only to disable them. Finding traps uses Search. Removing traps uses Disable Device (which means you get a bonus from masterwork tools.) A thief can find traps without having tools.
     
  11. Allyx

    Allyx Master Crafter Global Moderator Supporter

    Joined:
    Dec 2, 2004
    Messages:
    4,667
    Likes Received:
    136
    Agreed. Is the search function hardcoded? Or could ground trap detection be added into the search function (or even the sneak function)? Also, anyone can take ranks in search, all PC's can (or should be able to IIRC) assist the rogue/bard in searching for traps (they probably won't be much help, unless they accidentally trigger it - then everyone knows where it is, but that's not the point). The biggest complaint people had with Liv's ground trap was that you needed a damn good rogue to disable it, what if you have a non-rogue character with a high search skill, and no thieves tools? All characters should have the oppertunity to find traps that thier search skill will allow them to find.
     
  12. Kalshane

    Kalshane Local Rules Geek

    Joined:
    Aug 6, 2004
    Messages:
    1,650
    Likes Received:
    0
    Keep in mind, though, that traps with a Search DC above 20 (which is actually most of them) can only be detected by Rogues.
     
  13. Agetian

    Agetian Attorney General Administrator

    Joined:
    Aug 14, 2004
    Messages:
    2,526
    Likes Received:
    0
    @ Allyx: Nah, I believe Search and Sneak functions are hardcoded so their functions can't be modified without a really deep dll hack. So I believe we'll have to stick with the usage of a certain item (Thieves' Tools or some other item). If worst comes to worst, we may have to create an item in thieves' inventory whenever they start the game so that every thief comes with such an item, and this item will be used in order to use the new trap code.

    However, the way Ted explained it, I believe we don't need an item at all - we can just make a check for whether it's a Rogue and whether he has the Sneaking permanent modifier on him (that's another problem but I believe the permanent mods are being worked on), and if it's true, do the rest of the code which can include for various conditions such as DC20+ traps being only detectable by Rogues, various bonuses for Elves, and so on.

    - Agetian
     
  14. Lord_Spike

    Lord_Spike Senior Member Veteran

    Joined:
    Mar 25, 2005
    Messages:
    3,151
    Likes Received:
    0
    There are tools that aid in searching as well; and some traps couldn't be found without them. Or found without setting them off. It's a judgement call that depends on the scenario, and yet another example of something we must decide because the game isn't flexible enough to draw that fine of a distinction.
     
  15. Shiningted

    Shiningted I want my goat back Global Moderator

    Joined:
    Oct 23, 2004
    Messages:
    11,798
    Likes Received:
    39
    Well then when someone wanders into range the trap just checks against their search skill: easy as. If the search check fails, it goes off. If it succeeds, they get alerted and we go from there.
     
Our Host!