Wall trap, line of sight triggered in Design Philosophy

ID:764032
 
May 22 2012, 12:51 pm
I have been thinking about the different methods of developing a wall trap that is triggered via line of sight. I can think of a few programmatic ways to achieve this, and I'm curious as to which ones you think are best, and why?

1. At world start, a wall trap looks up the tiles in front of it continuing in one direction until it reaches another wall and "subscribes" them to a look up list. If these tiles are entered, they will "tell" the trap someone is there and the trap will trigger.
^While I understand the concept of this one, I've not developed it yet.

2. A trigger area (put on the map) manually connected to the trap. When the area is entered, the trap is triggered.
^Really easy, but will not allow any extra areas to be used where it is taking up space.

3. Default turf behavior is to check for nearby traps every time its entered, trigger trap if conditions are met.
^least efficient?

Any other ideas?
#1 May 22 2012, 12:56 pm
FIREking wrote:
2. A trigger area (put on the map) manually connected to the trap. When the area is entered, the trap is triggered.
^Really easy, but will not allow any extra areas to be used where it is taking up space.

That's what the Region library is for. You can place the objects on the map and they trigger Entered/Exited events (like areas do) but unlike areas, they can overlap each other.
#2 May 22 2012, 1:04 pm
How are you doing it, default /area or /turf checks and triggers a specific obj type to run its own Entered() or something similar?
#3 May 22 2012, 1:53 pm
I think it checks in the mob's Move proc. Each turf keeps a list of what regions it is in. When you enter a turf that's in a region you're not already in, the region's Entered proc is called. The /region object is a type of /obj (so it can be placed on the map) but they're all removed from the map at runtime.
#4 May 22 2012, 2:36 pm
You think? Didn't you write that library? haha
#5 May 22 2012, 5:00 pm
I haven't looked at the library in a while =)

It used to use the turf's Entered() proc to check, but I figured that people might override turf/Entered() and not call ..(). I changed it to use mob/Move() since it's less likely that people will override Move() and not call ..(). I'm pretty sure it only uses mob/Move() now.
#6 May 22 2012, 5:20 pm
Hmm. Looked at your libary. It creates 2 lists on every move. Those lists might be faster if they are just persistent. Not sure if list initialization multiple times vs list initialization once is a performance difference in the "VM"...