ToME WikiOrvin: This is somewhat of a coding idea, but my knowledge of the code is minimal, so I haven't a clue whether this is implemented or implementable. The first part of the idea is for squares in a dungeon to have an additional optional attribute, hidden from the player, identifying to which "domain" they belong. For example, all squares in a certain "room" might belong to domain 1, while squares in a hallway in a different part of the dungeon might belong to domain 2.
The second part is to make certain events involving the player and X(=a monster or an object, for example) depend on whether the player and X are in the same domain.
Using this, you could, for example, designate areas of the dungeon as being "echoic," so that the player's effective stealth is reduced. If the player and a sleeping monster are both in this same "echoic" domain, the code that checks whether the monster wakes up would apply a negative adjustment to the player's stealth. However, this adjustment won't happen if the player is in a different part of the dungeon. Some mountainous areas might be "echoic," while forested areas might not be (or might have the opposite effect of dampening noises).
Note that domains need not be contiguous.
Another use of domains could be to cause a monster to become aggravated only if the player enters a certain area of the dungeon. For example, those novice priests really don't like it if you go near their temple (the room with the altars).
Another use might be to spread spell effects. For example, if a contiguous forested area belongs to the same domain, and a player targets a fire spell somewhere in this domain, there might be a chance that the fire would spread throughout the domain and burn the other trees there.
Another use might be to provide a chance for a "roof collapse" (i.e., falling debris) somewhere in a domain, each time a wall is removed from somewhere else in that domain.
You might also create a domain consisting of two squares, separated by a large distance, one a normal floor square, and one a locked (unbashable, unpickable, unpassable, etc.) door. If the player enters the floor square, he might receive a message, "The floor beneath you shifts and you hear gears moving in the distance," and the door on that other square might open. Or, the domain might have 10 squares, 9 with doors, and one which, when entered, opens all of the doors. That one square might be heavily guarded.
ShrikeDeCil: In the ToME 3 code, there's a new version of the Bree Thieves' Quest. There's a square that is 'trapped' to do certain things if one steps there. I could see this being extended to do most of what you've described. The square isn't really 'trapped' in that it won't be detected by 'detect traps', and it isn't amenable to disaming. But it _is_ a trigger. So... you could clearly do the last thing. The 'trigger' can activate what appears to be arbitrary code - so you could have it turn 'permanent wall' into 'cobblestone road' if you like. Or have scimitars rain from the sky, ignite the nearest 20 trees, or teleport you to level 666.
The code for 'floor type' and what can happen seems to be significantly more open also. So I _think_ you could make tiles that say 'Your footsteps echo loudly' and tie that to a mild aggravation effect. But I don't know if that requires adding a new set of flags attached to individual squares. That is, you'd define a new terrain type 'FEAT_ROCK_ECHOY' or whatever, and just use it wherever you liked. I could well be baffled though. (The ideas are interesting though. My only caveat is that 'traps' should show up as _traps_. Which I don't think they do currently.)
Orvin: Regarding using a new terrain type to implement echoes, as above, perhaps I don't understand how terrain types work, but I think this would not work as I have described. I don't want the echo to carry to every monster, only to other monsters in the same domain. For example, you might designate a single room in a dungeon to be echoic, so that if you and a monster are both in the room, your noise is effectively increased, but that if you or the monster aren't in the room, there is no effect on the monster.
Orvin: Thanks for the feedback. I am not knowledgeable about the code, but I wouldn't implement the above by creating a set of flags for each square. The way I imagined implementation would be this: For each dungeon, squares could optionally have an additional flag called domain, its value being an integer. At the end of each turn, there is a check whether the player is in a square that belongs to a domain. If so, there is a check against a list of domains for the dungeon, that list being something like: domain #, other party to consider, effect. For example, in the echo example I mentioned, the corresponding entry might be: domain 1, any sleeping monster, awaken. There would then be a check whether any squares in the domain contain matches to the "other party to consider" field, and, if so, the effect would occur. Whether this is codeable, I have no idea, but I want to emphasize that I didn't mean to associate with each square a list of flags like "echo."
Also, I suppose there is no reason why a square couldn't belong to multiple domains.
KhymChanur: 3.0.0 now has per-square flags, so each square can have an arbitrary amount of information associated with it. So you could do something like
cave(y, x).flags[FLAG_DOMAIN] = DOMAIN3
or
cave(y, x).flags[FLAG_DOMAIN3] = true
Orvin: Cool, thanks.