33 réponses à ce sujet

[Gem Hound]

Those functions didn't work well for me.

How did they work then for you?

[Tchos]

Poorly, or not at all when companions were included.

[Gem Hound]

As in PC companions or NPC Companions? ahh I see what you are talking about, everything would get mixed up in the same place.

[Tchos]

I tested with both PC and NPC companions.  I don't remember what the particular results were for each aside from not working properly and consistently, but since I needed both to work in my campaign, I decided not to use the functions.  I also noted that they act by storing the information about which items are equipped and in which slot on the items themselves, and cycle through the inventory checking every inventory item for those variables when it's time to restore them.

[Gem Hound]

hmmm, then do you think this will work better? The chest with item descriptions and names copied over as well, and then checking item names and descriptions for each item when it gives them back? So as to not pile everything into one person's inventory AND place everything in it's proper slots.

[Tchos]

The way that worked best for me was to loop through the equipped items of the whole party and storing variables on each party member in the form of local objects for the items that were in the slots, and which slots they were in (I don't know why this is necessary, when a chest item can only be equipped into a chest slot anyway, etc.)  The action seemed to equip/unequip all items at once, not with a 6-second delay between each, but there were still issues with occasional unpredictable aborts of the script, leaving some party members without the items equipped.  I thought a problem might have been arising with the number of possible slots overwhelming the action queues of each party member, so I limited the items equipped to only the chest, hands, and I think head too.  This worked better.

 

Using local objects means you probably can't use the CopyItem function to move them, because the copies would not be the same object stored in the variable, so it would probably return OBJECT_INVALID.  Not certain about that, but seems reasonable. 

 

Edit: kevL pointed out a good way to deal with that last bit.

[kevL]

store 'local_objects pointing to the Copies' ...

but, it's likely not gonna be seamless*. Again, I'll advocate removing the IPs and using a pseudo-heartbeat to restore the permanent ones -- make the copies only as safeties (stamp them with the owner's name, then get the server to delete them later).


A quick HB, even a hundred of them, is not gonna be an issue (i doubt). Even so, it should be possible to construct only one or a few per character, esp. in a low-magic environment & esp. if the affected IPs were filtered

/cofee

 

 

* i for one'd be p-o'd when my carefully arranged inventory items suddenly go random.

[kevL]

oh before getting carried away with Local_Objects

 

there are conditions, unsure what, they disappear -- i had to deal with it once when transitioning to another module IG.

 

 

a/ the database might be required to make such variables truly persistent.

[Gem Hound]

I think I have an idea of a more stable version of this, but it will take more work. It would work by Ip-safe adding a new property to the item, but the property having the opposite effect of one of the previous properties.(EB + 1 will get an EB - 1 sort of thing) This would require me to make more item properties, but it would work just like weapon of impact or greater magic weapon.