Is there any way to change a corpse graphic?
So far I have only one idea: create and npc with the wanted graphic, move all items from the corpse to the npc, kill it, change the new corpse desc to match the original corpse desc, move its corpse where the original corpse is and destroy the original corpse
Any cleaner way?
Change corpse graphic
I had once had the idea of using a different way of handling character "death" because I see it as kind of lame that one keeps dying and getting ressed. I wanted to replace the corpse with a backpack and the RP of "death" would be that the player was seriously wounded and had to drop their pack in order to be able to get to the healer and get healed. Thus no one "dies" as far as the RP is concerned. Then I found the only way to handle this was to create a pack out in the "black" area and then transfer all items in the corpse to that pack, destroy the corpse and move that pack to the corpse location.
So like many other things, until they get added to the core, we script around them.
So like many other things, until they get added to the core, we script around them.
OK
Guess not then.
If you are thinking "perma-death" == Character gets deleted, I bet most players wouldn't go for that. But if perma-death == character must go to a special place and fulfill a quest before being allowed to return to the living, I can see how that might have a better chance of getting a thumbs up. But hey! Who am I to guess the mind of people?
Guess not then.
If you are thinking "perma-death" == Character gets deleted, I bet most players wouldn't go for that. But if perma-death == character must go to a special place and fulfill a quest before being allowed to return to the living, I can see how that might have a better chance of getting a thumbs up. But hey! Who am I to guess the mind of people?
-
Marilla
Umm... question; Has no one else figured out how to make secures work on POL? I have secure containers on our shard that work just fine. The last time I really worked with a distro was back at 092, but I guess I assumed someone else used the features available since then to implement secures in POL.
So, are there no secure containers in the distro? If not, here's basically how to do it:
You first need to be sure -ALL- container items that are -EVER- 'out in the world' in players' hands (and therefore, could be secured) use the same scripts for CanRemove and OnUse. You could, possibly, leave out CanRemove, but I strongly recommend implementing that, as well (as otherwise, someone with Injection could manage to 'hack' their way into a container and remove any item they would like)
The OnUse script can actually NOT be set on containers by default. In fact, I recommend that; no sense having the code run on everyone's backpacks, sub packs, etc, etc. You also likely have other OnUse scripts set to containers for other special purposes.
But, when the container is secured, it should also be set to have the OnUse script and CanRemove scripts you will write. It should also set a CProp to the serial of the house sign, or whatever method of house-access-control you have (you could use such code to implement "town secures" too, or whatever).
The actual scripts themselves (CanRemove or OnUse) would first check to be sure the container really is secured. ('locked down', and has a valid serial of a real house sign in which location it is contained). IF not, it should remove its OnUse script and just send the player a SendViewContainer() and exit.
If it verifies that it is still inside the house, by getting the house sign serial, and loading a ref to the house sign and checking the bounds, it can then access the friends/co-owners/owner list and verify that the person trying to open the container, or remove an item (depending on which script we're talking about) really is allowed to do so. You could implement separate 'friends' and 'co-owners' containers, or again, whatever you like. I also recommend checking the .locked member of the container, and preventing access if it's locked.
In the OnUse script, if the above checks pass, you just send SendViewContainer() to the player. You could be really 'cool', and also implement house refreshing on that.
In the OnRemove script, of course you just return 1, so the player can remove the item.
Otherwise, if any of the checks fail, you tell the player they can't do this, and return 0.
When a container is unsecured, you should remove the OnUse script and the CProp pointing to the house sign serial (but also still have the code mentioned above that double-checks).
And that's basically it. That system has worked perfectly for us ever since we've been on 095. I would post my code, but our town stone and housing systems are both deeply intertwined and completely unique, so the code would be confusing. Those interested can take my explanation and create the code fairly easy - we're talking maybe a dozen or two lines of script total.
So, are there no secure containers in the distro? If not, here's basically how to do it:
You first need to be sure -ALL- container items that are -EVER- 'out in the world' in players' hands (and therefore, could be secured) use the same scripts for CanRemove and OnUse. You could, possibly, leave out CanRemove, but I strongly recommend implementing that, as well (as otherwise, someone with Injection could manage to 'hack' their way into a container and remove any item they would like)
The OnUse script can actually NOT be set on containers by default. In fact, I recommend that; no sense having the code run on everyone's backpacks, sub packs, etc, etc. You also likely have other OnUse scripts set to containers for other special purposes.
But, when the container is secured, it should also be set to have the OnUse script and CanRemove scripts you will write. It should also set a CProp to the serial of the house sign, or whatever method of house-access-control you have (you could use such code to implement "town secures" too, or whatever).
The actual scripts themselves (CanRemove or OnUse) would first check to be sure the container really is secured. ('locked down', and has a valid serial of a real house sign in which location it is contained). IF not, it should remove its OnUse script and just send the player a SendViewContainer() and exit.
If it verifies that it is still inside the house, by getting the house sign serial, and loading a ref to the house sign and checking the bounds, it can then access the friends/co-owners/owner list and verify that the person trying to open the container, or remove an item (depending on which script we're talking about) really is allowed to do so. You could implement separate 'friends' and 'co-owners' containers, or again, whatever you like. I also recommend checking the .locked member of the container, and preventing access if it's locked.
In the OnUse script, if the above checks pass, you just send SendViewContainer() to the player. You could be really 'cool', and also implement house refreshing on that.
In the OnRemove script, of course you just return 1, so the player can remove the item.
Otherwise, if any of the checks fail, you tell the player they can't do this, and return 0.
When a container is unsecured, you should remove the OnUse script and the CProp pointing to the house sign serial (but also still have the code mentioned above that double-checks).
And that's basically it. That system has worked perfectly for us ever since we've been on 095. I would post my code, but our town stone and housing systems are both deeply intertwined and completely unique, so the code would be confusing. Those interested can take my explanation and create the code fairly easy - we're talking maybe a dozen or two lines of script total.
The bug of which I spoke relates to the dropping of an item on a closed secured container. This bug manifests itself sporadically so it's hard to fix. What occurs is the item sometimes does not appear in the container when you open it. POL "sees" the item as being inside yet it does not appear there. If you unsecure the container and let decay take place POL drops the item on the ground when the container decays.
I assume the bug has to do with certain critical timing events that are at times in the right or in this case wrong sequence which causes this error. Probably something in the OnInsert scripts.
This bug has existed since Bishops original Static Housing package. I found it happening on World of Dreams housing system as well.
It may also be a problem in general with dropping on closed containers but I think we only saw it happen with secures.
I assume the bug has to do with certain critical timing events that are at times in the right or in this case wrong sequence which causes this error. Probably something in the OnInsert scripts.
This bug has existed since Bishops original Static Housing package. I found it happening on World of Dreams housing system as well.
It may also be a problem in general with dropping on closed containers but I think we only saw it happen with secures.
-
Marilla
-
Marilla
Hmmm.. that's really odd. I've never seen anything like that at all. I would think it'd be a pretty big thing for players if items they drop in containers started just disappearing, but I've never heard of any such thing.Yukiko wrote:Yeah. It's strange indeed. It doesn't happen only with secures I guess either. Oh well. It is rather rare so it ain't too bad and you can recover the "lost" items if you release the chest and wait til it decays.
I can't imagine what a script would have to do with that at all, either, aside from an On/CanInsert script. So I'd suggest carefully perusing those scripts to look for what might be happening.
*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.
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.
