Checking whether a door is locked

[Niemand]

Sort of thinking out loud here, but I can't determine whether this is easy and I'm forgetting how to do it, or it's just impossible: Supposing that I've discovered that some space in a town is a closed door terrain (suppose here that I'm a creature script), can I find out whether the door is locked?

[Lilith]

I can imagine some ugly workarounds that would basically require the creature to know the coordinates of every door in town that starts out locked, and the SDFs that are set when they're unlocked (and therefore a separate creature script for every town). But no, what you are wanting to do isn't easy.

[Ishad Nha]

If it is your own scenario you can ensure that all locking is handled by memory cell 0 in your terrain scripts. Somedays BoA is not all that flexible.

[Niemand]

Yeah, now that I'm wider awake I'm fairly certain that there's no practical way to do this. The stumbling blocks include: inability to get the number of the script, if any, on a space, inability to check what script a given terrain script is (is it good 'ol door, or is it wackydoor, which is the same but with memory cell usage mixed up?), and inability to check a scripts memory cells from another script (even though there is a call to blindly set them). I can envision a series of workarounds, but they would involve creating a chunk of code likely running well into the hundreds of lines and running a major risk of hitting the node execution limit.

 

@Ishad Nha: Even that wouldn't be sufficient, as it would only eliminate stumbling block 2, leaving 1 and 3.

 

Thuryl's suggestion is the closest to being practical, I think. It shifts some of the burden into the town script (in the implementation I envision) which would have to be hard-coded to write a big block of door information into a reserved section of SDFs during the INIT_STATE (you would theoretically need 300 flags for this, two coordinates and a lock flag for each of up to 100 doors), which would be rather cumbersome to maintain (although it could in theory be auto-generated by a special tool). Then, the creature script would still have to do a bunch of slow work to search the list stored in the SDFs. That is, the code in the creature script itself would be mercifully short, but would necessarily have a running time linear in the number of doors in the town. SInce the idea was to use this as part of a path finding routine, which would itself be very slow and have a high node execution count, that might be a problem. On the other hand, there might be a clever way to break such a path finding routine into steps, so that it wouldn't go over the allowed node count and would have some interestingly realistic behaviors, like running over to a door first and then checking to see if it is locked.

[Celtic Minstrel]

What about using messages? That is, edit your door script so that when it receives message x, it responds with message 0 if the door is open or message 1 if it isn't. If it's acceptable for the check to last two or three turns, this would seem to be fairly simple solution.

 

The only minor downside is that you can't tell who sent you a message, but that could be solved by having the sender set a reserved SDF to its creature number before sending the message.

[Niemand]

That might work; you'd have to be careful about the range of messages, though, as you only want one door to respond per request. Also, it's important to note that it would take a full round to get a result. You might also have to be careful if you have multiple creatures querying multiple doors; the creatures mustn't overwrite the 'to whom to respond' flag, and depending on how the doors respond (although it wouldn't be a problem if they do so using messages) they also mustn't overwrite each others' responses.

 

I do like the elegance of message in that it provides a way to get the game to figure out which terrain script is the relevant one (and in the same action communicate the signal to it).

 

EDIT: Considering more carefully my own comment above about broadcast range, I think that it may be a significant (but by no means unsolvable) problem to this approach. Suppose the creature is standing on a space with a closed door facing it from each of two (or more) of the directly adjacent spaces. Any message which reaches on door must also reach the other, so the creature need to be able to either make clear which door it is addressing, or receive and distinguish the replies from both doors.

[Lazarus.]

Set all your door scripts to run every turn. Then set your creature scripts to broadcast a message of radius 1 after every turn. When a door receives a message it responds within radius 1 with 1 for locked and 0 for unlocked. If a creature has a message it will assume that any door within stepping distance is locked, otherwise it assumes all are unlocked. The only problem that jumps out at me is if there are two doors within a 3x3 square. That's not too difficult to avoid if you lay out your towns well though.

 

Edit: Hmm you already figured out the range idea, so how about this for working around multiple doors in range. Creature broadcasts message 1 with radius 1. First door responds with 2 for unlocked, 3 for locked. Second door gets message and responds with 4, 5, 6, or 7 (4 if locked and other door is not, 5 if locked and other door is, etc.) Now you can tell the arrangement of up to two doors, and if you know which order the scripts are in you can know which door is which. I believe terrain scripts run from first to last, so you'd have to lay all your door scripts in a set order. For example door script numbers increase from left to right and top to bottom. This would be a pain in the ass. I don't know if message values are limited, but if you can go up to 256 then you can have info on what, 8 doors?

 

Edit2: And message lag shouldn't be an issue, since terrain scripts can be set to run even in between combat turns.

 

Edit3: And if message values can go up to 32768, then you can cut some corners by deciding to never put more than 1 door in a 3x3 square, and having each door broadcast its x/y/locked status in binary. Oh and have each creature broadcast its own number, that way you can't get "crossed signals."

[Ishad Nha]

"The stumbling blocks include: inability to get the number of the script, if any, on a space"

In cases like this in the A1 Template script "portalflag", I just manually wrote the script number into Cell 0.

"inability to check what script a given terrain script is (is it good 'ol door, or is it wackydoor, which is the same but with memory cell usage mixed up?)"

If it is your scenario you decide the contents of all scripts.

[Celtic Minstrel]

I was actually thinking of using the give_ter_script_message function to query the door, but I guess that raises a completely different problem...

 

Originally Posted By: Ishad Nha

"The stumbling blocks include: inability to get the number of the script, if any, on a space"

In cases like this in the A1 Template script "portalflag", I just manually wrote the script number into Cell 0.

But that won't work, will it? I thought someone was also complaining how you can't get a memory cell of a terrain or creature script other than the currently running one.

[Slawbug]

“Tell Niemand to get rid of the doors-in-walls entirely, and make new door terrains, so that one door terrain type can always be "locked and closed" and the other can always be "unlocked and closed." Switching the terrain is probably the simplest way imaginable of doing this. The only downside is terrain slots, and maybe checking for 4n terrains for pathfinding (where n = number of door sets).„

[Niemand]

I assume that this advice comes from TM?

 

Similar to other approaches, this rapidly becomes prohibitive if one attempts to apply it generally. It might, however, be a good way to go if one wanted to use a clever AI in a controlled situation.

 

Regrettably, the main application for this that I was considering, an entirely scripted pathfinding mechanism, looks like it may be prohibitive as well, due to the stringent constraints on number of operations performed, amount of memory used, and the impracticality of creating data structures more complex than an array or stack. I'm still working on thinking about the problem, though.

[nikki.]

TM:

 

"For every closed-and-unlocked door, have a "replacement" terrain that permits movement but cannot be seen through. Switch the closed-and-unlocked doors with their walkthrough replacements before pathfinding is computed. If the monster is near one of the replacement, walkthrough terrains, turn it into an open door and either deduct 4 AP (combat) or end the combat turn (town). Swap them back after the "am I doing anything?" call (town). I don't know the best place for swapping back after combat mode actions, and it may be inelegant/slow."

 

Also:

 

"Whenever the monster is one space away from a door, have the monster open it. (Deduct 1AP in combat.) You can enter in some checks to prevent monsters from opening three doors at once (for instance, before opening a door, check for an open door one space away, and then check if there's a perpendicular wall beyond the two doors)."

[Niemand]

Originally Posted By: TM

For every closed-and-unlocked door, have a "replacement" terrain that permits movement but cannot be seen through. Switch the closed-and-unlocked doors with their walkthrough replacements before pathfinding is computed.

You might be able to improve upon this: do the switching during path-finding, so that you only switch doors which the creature is considering trying to walk through. Actually switching the terrain temporarily is a good idea, I think, as it will mean that the blockage array will then unambiguously describe whether there's anything else in the way on that space.

Originally Posted By: TM

Swap them back after the "am I doing anything?" call (town). I don't know the best place for swapping back after combat mode actions, and it may be inelegant/slow."

If this optimization were used, I think that the problem of when to replace the original terrain would disappear: just switch the terrain back to closed-unlocked door directly after testing whether the space can otherwise be walked through. Then, later on, if the somehow chosen path calls for passing through a closed, unlocked door, it would be straight-forward to handle the necessary AP reduction and permanent terrain swapping.

Originally Posted By: TM

"Whenever the monster is one space away from a door, have the monster open it. (Deduct 1AP in combat.) You can enter in some checks to prevent monsters from opening three doors at once (for instance, before opening a door, check for an open door one space away, and then check if there's a perpendicular wall beyond the two doors)."

I'm not sure what this part is getting at; I don't see any special reason that the AI should open doors merely because they are nearby.