..and 1 part preparation. As in: who's prepared a persistent chest script for use before I go through the painful process of writing one myself?
Thanks!
Success is 9 Parts Persistence...
Moderators: ALFA Administrators, Staff - Technical
Success is 9 Parts Persistence...
Enjoy the game
- AcadiusLost
- Chosen of Forumamus, God of Forums
- Posts: 5061
- Joined: Tue Oct 19, 2004 8:38 am
- Location: Montara, CA [GMT -8]
- Contact:
This is one case in which the work is already done!
Make sure the chest has the acf_plc_* scripts in the appropriate event slots, then just add a string variable to the chest (or other placeable with inventory) called ACR_PSO_NAME, choose a unique string for the value, say, "tsf_silvy_uni_pchest1" - this will be the unique reference for the inventory of the p-chest. Any inventoried placeables with the same ACR_PSO_NAME will share the same inventory, so be careful about defining this in the blueprint.
So long as you've set ACR_PSO_NAME for the placeable, the ACR should recognise it as a persistent storage item and manage it accordingly. For now, I'd recommend setting such placeables to plot/indestructable as well, as I suspect we haven't fully handled the OnDeath() event yet.
Make sense? (1. associate the acf_plc scripts, 2. set up a string variable called ACR_PSO_NAME, set it's value to something unique (like we did with tags in NWN1).
Make sure the chest has the acf_plc_* scripts in the appropriate event slots, then just add a string variable to the chest (or other placeable with inventory) called ACR_PSO_NAME, choose a unique string for the value, say, "tsf_silvy_uni_pchest1" - this will be the unique reference for the inventory of the p-chest. Any inventoried placeables with the same ACR_PSO_NAME will share the same inventory, so be careful about defining this in the blueprint.
So long as you've set ACR_PSO_NAME for the placeable, the ACR should recognise it as a persistent storage item and manage it accordingly. For now, I'd recommend setting such placeables to plot/indestructable as well, as I suspect we haven't fully handled the OnDeath() event yet.
Make sense? (1. associate the acf_plc scripts, 2. set up a string variable called ACR_PSO_NAME, set it's value to something unique (like we did with tags in NWN1).
Went to test persistent containers today and noticed that every time I use the Loot All button, I get an error message sent to my PC saying that the persistent container has not saved its contents. Considering that I just removed all the contents, that seems reasonable to me. Is there something else going on with the persistency system that I'm missing?
Also, when the SetSpawnIsEnabled is working, will the contents of a persistent placeable container go with it when the container child of the spawn despawns? Right now I'm getting piles of contents leftover because I've had to resort to DestroyObject to get rid of the containers to test their persistency.
Thanks!
Also, when the SetSpawnIsEnabled is working, will the contents of a persistent placeable container go with it when the container child of the spawn despawns? Right now I'm getting piles of contents leftover because I've had to resort to DestroyObject to get rid of the containers to test their persistency.
Thanks!
Enjoy the game
All right, further testing of persistent containers reveals:
1. Placed persistent containers, when destroyed ingame by a PC bashing it, take their contents with them ondeath. No contents are left to loot amongst the wreckage.
2. Spawned persistent containers, when destroyed by script upon a PC leaving the room, leave their contents on the ground. Upon respawning at the next PC's entry, they return with the items inside, also, meaning the items have been duplicated. I'm going to write a destroy inventory script to get around this in the short term. There was a NWN alfa include function for DestroyInventory or DestroyContents or something. Do we still have that in some include somewhere?
3. Both placed and spawned persistent containers work fine on module reload. They disappear with contents, leave nothing behind, and return with contents.
1. Placed persistent containers, when destroyed ingame by a PC bashing it, take their contents with them ondeath. No contents are left to loot amongst the wreckage.
2. Spawned persistent containers, when destroyed by script upon a PC leaving the room, leave their contents on the ground. Upon respawning at the next PC's entry, they return with the items inside, also, meaning the items have been duplicated. I'm going to write a destroy inventory script to get around this in the short term. There was a NWN alfa include function for DestroyInventory or DestroyContents or something. Do we still have that in some include somewhere?
3. Both placed and spawned persistent containers work fine on module reload. They disappear with contents, leave nothing behind, and return with contents.
Enjoy the game
- ç i p h é r
- Retired
- Posts: 2904
- Joined: Fri Oct 21, 2005 4:12 pm
- Location: US Central (GMT - 6)
1. This can be controlled by the builder. Persistent containers can be configured to either drop their items when destroyed or not. What you're describing is the default behavior. I can lookup the actual controls if you'd like. This should be documented in our wiki, if it's not already.
2. AL and I talked about this a couple days ago. This may either be a timing issue or an issue with triggering the OnDeath event with scripted DestroyObject() calls. The OnDeath script already does an inventory purge when a persistent container is destroyed, as you noted above, so it's not clear without more testing why it doesn't execute properly when a container is destroyed by nwscript.
DestroyInventory(object oStorage) is defined in acr_tools_i.
Edit: Added Persistence Options to the placeable configuration option list in the wiki.
2. AL and I talked about this a couple days ago. This may either be a timing issue or an issue with triggering the OnDeath event with scripted DestroyObject() calls. The OnDeath script already does an inventory purge when a persistent container is destroyed, as you noted above, so it's not clear without more testing why it doesn't execute properly when a container is destroyed by nwscript.
DestroyInventory(object oStorage) is defined in acr_tools_i.
Edit: Added Persistence Options to the placeable configuration option list in the wiki.
- AcadiusLost
- Chosen of Forumamus, God of Forums
- Posts: 5061
- Joined: Tue Oct 19, 2004 8:38 am
- Location: Montara, CA [GMT -8]
- Contact:
The problem in this case was that the configuration options weren't being obeyed by the pchest, when they were being called by the spawn system. Apparently something about how they were being created was overriding settings for ACR_PSO_ONDEATH.
After further testing, Wynna reported that the behavior seemed fixed if you predefined the ACR_PSO_NAME in the blueprint (as opposed to assigning it by scripts). [edit: scratch that, still doesn't work from spawned containers.]
Toolset-placed instances of persistent storage objects obey their ACR_PSO_ONDEATH settings correctly, though they still give an error when players use the "loot all" button, warning that contents may not be saved. Haven't worked that one out yet, though it doesn't seem to affect anything, since it only happens when there are no more contents to save.
After further testing, Wynna reported that the behavior seemed fixed if you predefined the ACR_PSO_NAME in the blueprint (as opposed to assigning it by scripts). [edit: scratch that, still doesn't work from spawned containers.]
Toolset-placed instances of persistent storage objects obey their ACR_PSO_ONDEATH settings correctly, though they still give an error when players use the "loot all" button, warning that contents may not be saved. Haven't worked that one out yet, though it doesn't seem to affect anything, since it only happens when there are no more contents to save.