containers: bug or intended?

Error message

Deprecated function: implode(): Passing glue string after array is deprecated. Swap the parameters in drupal_get_feeds() (line 394 of /var/www/pied-piper.ermarian.net/includes/common.inc).
AuthorTopic: containers: bug or intended?
Shock Trooper
Member # 4180
Profile #0
This is a bit complicated to explain, so bear with me. :) I've created a custom terrain that's a "container" (in that it hides something else in its location). To simplify things (and keep from giving away too much of my plot), let's say that the very act of searching this container destroys it and turns it into a different type of (non-container) terrain.

If I simplify this a bit more and make the original terrain NOT a container, I can get the basic behavior I want: I can block the party from entering the square until after they search it, then call set_terrain to swap to what I want there after the container is gone. After that, the party can freely walk through the space (as long as my terrain script says they can).

However, as soon as I make the original terrain a container, the party can't enter the square after the set_terrain call replaces it with a non-container, even if the script explicitly calls block_entry(0) to let them.

IOW, once you place a container in a square, that square is apparently blocked to entry by the party forever and eternity after that, even if you change the terrain on the square to NOT a container and specifically grant access to the square in a script.

I can script around it (by leaving the original terrain not a container and just putting the item I wanted it to contain in inventory when the party searches the square), but it doesn't seem like correct behavior, to me.

-spyderbytes

--------------------
-spyderbytes
Posts: 200 | Registered: Wednesday, March 31 2004 08:00
Board Administrator
Member # 1
Profile Homepage #1
I have no idea what's happening here, but I do know this: when someone searches a container and block_entry is called, that only affects whether the party is able to get the objects in the container. When searching, block_entry does not affect movement at all.

If you are using set_terrain on the space, that the original terrain type was a container really shouldn't affect whether the space can be walked into or not. Odd.

--------------------
Official Board Admin
spidweb@spiderwebsoftware.com
Posts: 960 | Registered: Tuesday, September 18 2001 07:00
Shock Trooper
Member # 4180
Profile #2
Hmmm.... I'll do some more checking on my end to make sure there's not just some stupid error lurking in my code. But I can tell you this: if I comment out the

te_special_property = 40; // container

line in the definition of the original terrain, my code behaves exactly the way I want (except my item is not contained, of course ;) ). When I uncomment it, the party can't move into the square after the set_terrain() call.

-spyderbytes

EDIT: Harrumph! I decided to try it in 1.0 to see if that made a difference, and lo and behold!, it worked as it should with the original terrain being a container. So I figure, OK, it just got broken somehow in 1.0.1. But then I go back to verify in 1.0.1, and it's working THERE now. :( I haven't changed a line of code since it didn't work, I posted here (after hours of isolating it), then switching to 1.0 and back to 1.0.1. Go figure...

[ Tuesday, April 13, 2004 14:10: Message edited by: spyderbytes ]

--------------------
-spyderbytes
Posts: 200 | Registered: Wednesday, March 31 2004 08:00