Set Terrain Memory Cell

[BainIhrno]

Just started alpha testing the Redemption port. Does the set_terrain_memory_cell() node work? I had it set to lock a door to impassible status (that was previously passable). But it doesn't seem to have any effect. Am I doing something wrong, or does this node just not work?

 

I had it at set_terrain_memory_cell(4,0,200); (4 for the terrain script, 0 for the memory cell to adjust, and 200 for the new value).

[Ess-Eschas]

20 hours ago, BainIhrno said:

Am I doing something wrong, or does this node just not work?

 

The call works, but it's a little finicky! This is especially the case with doors, which have their own peculiar characteristics.

 

The reason why this isn’t working for you is because memory cell 0 is only called in the init_state of the door script. In other words, it’s only checked the moment the door is loaded into the engine, but it’s never checked again. You’re correctly changing the cell, but the game never gets around to checking it again!

 

Generally speaking, it’s better to deal with locking/unlocking doors using flags. Memory cells 2 and 3 of the door script give the first and second coordinate of an sdf. If a door is originally locked, then setting the value of this flag to 1 will unlock the door.

 

That is all well and good, but it’s a little more complicated the other way around. If a door is originally unlocked, then the sdf doesn’t have any effect. You can get around this with some trickery, however.

 

One intuitive approach might be to first set the door as locked through memory cell 0, and then set the sdf to 1 at some point, maybe in the town’s init state. Setting the sdf back to 0 should lock the door again, having the desired effect, right? Sadly, no. The way the engine seems to behave, at least in my experience, is such that it ‘remembers’ when a door has been unlocked. If it’s been unlocked once, even with an sdf, locking it again is a little more tricky.

 

There may be a nicer way of doing this, but I get around this by using a modified door script. All I do is to add one additional line to block_move_state, namely this, at the very top of the state:

 

i_am_locked = 1;

 

This ensures that the door is always locked when it’s closed. If the sdf is set to 1, it opens itself again but, if not, it stays locked (with whatever difficulty you originally set, so it’s best to set the starting value memory cell 0 to 200).

 

Of course, in your script, you’ll also need to make sure that the door is shut whenever it’s set to being locked. This comes with its own problems! While it’s possible to detect the state of the door using get_terrain(), and then to close the door manually using flip_terrain(), the game also remembers whether the door was originally open or not. So, even if you’ve closed it manually, the game still thinks the door is open!

 

One way around this is to add a manual check in your new door script. Create a call at the beginning of seach_state and block_move_state that checks a flag held in memory cells 4 and 5. Have this manually ‘close’ the door if the flag is set to 1 (by setting i_am_open == 0), and then set this flag elsewhere whenever you want the door to be locked. It’s a bit of an awkward workaround, but it should do what’s needed!

 

Of course, maybe I’m overcomplicating things! I do have a tendency to do that in this engine ...

 

Edit: Incidentally, I should have said that you’re more than welcome to my modified door script if it would help – it might save you from replicating the work! Drop me a line if so.

[Kelandon]

Yeah, tl, dr, you probably should use the flag in cells 2 and 3. Set the memory cells so that it's impassibly locked, set the flag that unlocks it in a one-shot on initially entering the town (or beginning the scenario, or whatever), and then when you want it to be locked, set the flag to zero. Haven't tested this, but it seems like it should be straightforward.

[Ess-Eschas]

7 hours ago, Kelandon said:

Haven't tested this, but it seems like it should be straightforward.

 

This method should work from a logical standpoint, but unfortunately it's not that simple! The flag in cells 2 and 3 unlocks the door forever when the door script is called, even if you change the flag subsequently. Once a door is unlocked this way, it can't be locked again.

 

To cut through my verbosity, I got around this by creating a new door script, one which manually keeps track of the door's state (i.e. whether it's locked or not, and whether it's open or not). This stops the game 'assuming' the door's state, meaning you can do with it what you want. It's available to anyone who might find it useful!

[Kelandon]

1 hour ago, Ess-Eschas said:

This method should work from a logical standpoint, but unfortunately it's not that simple! The flag in cells 2 and 3 unlocks the door forever when the door script is called, even if you change the flag subsequently. Once a door is unlocked this way, it can't be locked again.

Really? It's in the INIT_STATE, so it seems like it would check it every time you enter the town. Errrrr, or does the INIT_STATE for a terrain script not run each time you enter the town, as I thought it did?

 

But, come to think of it, Bain is clearly trying to have the door become locked from within the same town, so my method wouldn't work anyway. So yeah, for that you'd need to do a slight modification on the door script to have it check the flag whenever you walk into the door, instead of whenever the INIT_STATE is run. (The problem, evidently, is that the i_am_locked variable gets dealt with in the INIT_STATE and doesn't check the relevant memory cells again in the BLOCK_MOVE_STATE.)

[Ess-Eschas]

10 hours ago, Kelandon said:

Really? It's in the INIT_STATE, so it seems like it would check it every time you enter the town. Errrrr, or does the INIT_STATE for a terrain script not run each time you enter the town, as I thought it did?

 

Oh, I see what you mean! Yes, init_state is indeed checked whenever the party enters town, so setting the flag as you suggest would work for most situations – my use of forever in the above is a tad strong! In fact, it looks like Bain’s original suggestion would work in that case too – although setting the flag is still probably better practice, since I feel the approach is a little more transparent, and it's easier to debug.

 

As you say, the problem is because the variables describing the door’s state (i_am_locked and i_am_open) persist, and are only checked in the init_state. Actually, I now realise that my script is more complicated than it needs to be! Just copying the text from the init_state into the other states should work. It does have to be copied into every state, though, otherwise you get some strange behaviour. (On my first attempt, you could open permanently locked doors just by looking at them, which is not hugely desirable).

[BainIhrno]

I actually did find something helpful - apparently Frostbite by Lazarus uses a modified door script for some of it's doors that allow you to set a flag for cells 4 and 5 - just copied that script as a second door script, set the flag there, and that did the trick! Thanks anyway. 

 

But yeah, alpha-testing in BoA is going to be quite bit of work. I'm sure Kel can relate.

 

Something else kinda odd though - the "move_party" node isn't recognizing the coordinates of the town I'm moving to - in the new town, the party is placed in the coordinates of where they left the first town through - maybe this has something to do with using teleport_party() earlier?