On-Ground Traps: a way to make them

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

 

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

 

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

 

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

 

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

 

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.

 

@ 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

 

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.