Change corpse graphic
Good questions OldnGrey. If I remember the next time it happens I'll see. I can tell you that the item does exist in the data files because if you unsecure the container and let it decay the item will appear. It's just like it gets hidden by the container somehow. When we were players we used to RP it was stuck under it but ofcourse that was not really what happens because moving the container did not expose it.
-
Marilla
heh.. you must have VERY forgiving players, then. I would be having panic attacks from my playerbase if an item disappeared like that, without explanation, even once; We started on 092 with a WoD-like script set (Ackadia, actually - not WoD) years ago, and I'm 99.99999...% positive that if a SINGLE item had disappeared in the way you describe, I'd have had players up in arms over it until it was explained and fixed.Yukiko wrote:*nods*
Well, it happens once in a blue moon. I have seen it happen in versions of POL as early as 092 with secured containers on a server that used Bishop's original static housing package. Also on POL 094 using WoDs housing system. As for anything after 094 I've only heard reports. Again though it's like once a year or so that it seems to happen. With that infrequent occurrence it's hard to believe it would be a totally script related issue. Guess it could be though. Anyway, it isn't a big problem because it happens so infrequently.
But if it's really happening THAT infrequently, it seems to me much more likely to be human error, and maybe the people reporting it just are kinda 'forgetting' some details of the situation...
It might be human error occaisionally but the two times it happened to me I know I dropped the item on top of the secured container. The first time the container had nothing in it prior. I went to retrieve the item and the container appeared to be empty. I paged a GM and was told that the container showed something was in it when they used some sort of count command. The second time there were lots of things in the chest and still the item was not there when I emptied the chest. The shard I was on was Journey's End at that time and it was a known bug. The solution was to let the container decay and the item would be dumped out. So it wasn't like we were losing the items.
The reason my players didn't panic was that most had come over to Hope Lives from Journey's End when Sigismund pulled the plug on JE. So most were familiar with the bug already.
Like I said it ain't a critical issue since if it happens it is a recoverable bug.
The reason my players didn't panic was that most had come over to Hope Lives from Journey's End when Sigismund pulled the plug on JE. So most were familiar with the bug already.
Like I said it ain't a critical issue since if it happens it is a recoverable bug.
-
Marilla
Here are a couple trees to bark up:
First, it kinda sounds odd that a GM would say they have some command to 'see' the item exists, yet they cannot do anything to it. Maybe they misinterpreted the 1 return value of container.item_count as meaning there was an item in the container (item_count always returns 1 for the container itself, when empty). But if they had a command that was iterating through the items in the container, it seems that they would have tried creating a command at some point to let them SELECT an item and have it moved to their backpack, or to the ground, or something... it seems like waiting for an item to decay to 'fix' a bug is a pretty kindergarten solution :razz: At least you're looking to do more than that, so kudos there
Next, though; If this item was truly in the container, and could not have been accessed by a script at all, then when that container decayed, the item would NOT have been dropped to the floor. It would have been destroyed right along with its container. That's why I asked the above; Why didn't they just make a command to list the items in a container, and draw one out?
Because if the container decaying fixed this, I guarantee I know what was happening: They had a fairly commonly implemented script (which I do not use myself) that runs when a container is destroyed - the script moves every top-level item from the container to the ground where the container was. Only a script would do that - the core does NOT; it deletes items from containers that it is deleting.
But here's another tree to bark up: Maybe this 'bug' actually has something to do with what the items are. There are some items which simply will not display properly in most containers. You drop it in, and in it goes... but you'll never see it. It'll show up in EnumerateItemsInContainer(), etc... but no matter what you do, you'll never 'see' the item in the container.
But put that same item on the ground, and viola'; There it is! An example of an item to which this applies is a hair object, for example. Other items will show as 'No Draw' or some other invalid graphic, unless they are in a certain container (such as game pieces). Perhaps the bug is actually related to the ITEM, then - not the container.
It could also be that an item's graphic is being changed to something invalid when being inserted into the container, causing the same effect. For example, we have an equippable 'Death Shroud' on our shard. However, for it to work so that people can actually see it in their backpack, the graphic needs to be changed when it is unequipped. Otherwise, it would be in their backpack, but completely not visible. Dropped into a 'secure' container, it would seem to have the same 'bug' as here, when all along, the problem is with the item itself.
The fact that this seems to happen to items in 'secures' also really strongly suggests to me that this is a script bug; Since secures really are a completely script-based feature, something in the process of making an item a secure must also be causing this to happen to items. The fact that it has happened to non-secured containers too *may* only mean that those containers used to be 'secures', but were released improperly such that they still have the OnInsert/CanInsert or other such related scripts running, thereby still causing the bug.
I would definitely try to remember or see if there is any similarity in the types of items this has happened to. Perhaps there is some similar script to the one I mentioned for our Death Shroud that is being 'broken' somehow by script that runs on the secures On/CanInsert.
First, it kinda sounds odd that a GM would say they have some command to 'see' the item exists, yet they cannot do anything to it. Maybe they misinterpreted the 1 return value of container.item_count as meaning there was an item in the container (item_count always returns 1 for the container itself, when empty). But if they had a command that was iterating through the items in the container, it seems that they would have tried creating a command at some point to let them SELECT an item and have it moved to their backpack, or to the ground, or something... it seems like waiting for an item to decay to 'fix' a bug is a pretty kindergarten solution :razz: At least you're looking to do more than that, so kudos there
Next, though; If this item was truly in the container, and could not have been accessed by a script at all, then when that container decayed, the item would NOT have been dropped to the floor. It would have been destroyed right along with its container. That's why I asked the above; Why didn't they just make a command to list the items in a container, and draw one out?
Because if the container decaying fixed this, I guarantee I know what was happening: They had a fairly commonly implemented script (which I do not use myself) that runs when a container is destroyed - the script moves every top-level item from the container to the ground where the container was. Only a script would do that - the core does NOT; it deletes items from containers that it is deleting.
But here's another tree to bark up: Maybe this 'bug' actually has something to do with what the items are. There are some items which simply will not display properly in most containers. You drop it in, and in it goes... but you'll never see it. It'll show up in EnumerateItemsInContainer(), etc... but no matter what you do, you'll never 'see' the item in the container.
But put that same item on the ground, and viola'; There it is! An example of an item to which this applies is a hair object, for example. Other items will show as 'No Draw' or some other invalid graphic, unless they are in a certain container (such as game pieces). Perhaps the bug is actually related to the ITEM, then - not the container.
It could also be that an item's graphic is being changed to something invalid when being inserted into the container, causing the same effect. For example, we have an equippable 'Death Shroud' on our shard. However, for it to work so that people can actually see it in their backpack, the graphic needs to be changed when it is unequipped. Otherwise, it would be in their backpack, but completely not visible. Dropped into a 'secure' container, it would seem to have the same 'bug' as here, when all along, the problem is with the item itself.
The fact that this seems to happen to items in 'secures' also really strongly suggests to me that this is a script bug; Since secures really are a completely script-based feature, something in the process of making an item a secure must also be causing this to happen to items. The fact that it has happened to non-secured containers too *may* only mean that those containers used to be 'secures', but were released improperly such that they still have the OnInsert/CanInsert or other such related scripts running, thereby still causing the bug.
I would definitely try to remember or see if there is any similarity in the types of items this has happened to. Perhaps there is some similar script to the one I mentioned for our Death Shroud that is being 'broken' somehow by script that runs on the secures On/CanInsert.
I assume that the reason no GM scripted a command to test the container is because only one person had access to the scripts at that time and that was Sigismund and I suspect he, like most people, was skeptical about the reality of the bug. It was, after all, a rare bug. Plus since we only put things we needed and wanted to keep in secures we usually couldn't wait around for Sigi to take our box and mess with it with a script. Besides, it was easy enough to recover the item by letting the container decay.
I really have no idea what the GM at that time used to determine what, if anything, was in the container. I only assumed it was a count command like exists for players on WoD.
I really have no idea what the GM at that time used to determine what, if anything, was in the container. I only assumed it was a count command like exists for players on WoD.