@kevL_s helped me with the solution to an issue, which I believe needs highlighting …
If you are a builder who “strips” PCs (companions added at a roster) of items upon entering the module, then please note …
If you were to then to use GetObjectByTag on an item that had just been stripped/destroyed, it will return a VALID object, even though it should be INVALID. This fixes itself if the player should save and reload a game after any item destruction, but you can also simply change the TAG of item just prior destruction (thanks KevL!), which “hides” (*) the VALID “INVALID OBJECT” until the player reloads, when the issue no longer exists.
(*) Basically, set it to a TAG that you know will no longer be used in your module searches.
Thanks!
EDIT: Actually, the issue also runs a little deeper if you allow some items to be “kept” with imported PCs, as these will remain VALID objects even after usage until the game is SAVED & RELOADED at least once after the items have been imported. EG: PC imported with a cure light wounds potion. If it is not stripped, and the PC uses it later, the GetObjectByTag will still detect it as a valid item if the game had not been saved and reloaded prior to its usage.
UPDATE: On further investigation, some of these issues appear to be related to some “rogue” items that have crept into my module, and which do not appear to have any real location. They should not be there and are interfering with the function. I am currently trying to track down how their presence can be explained.
Only if it makes sense in the context of the plot. People in pre-modern societies did not walk around naked. The higher the PC’s level at start, the less likely they would begin with nothing.
If you do strip the PC on start up, make sure it’s clearly stated in the game description, justified by the plot, and appropriate gear is readily available that follows the story.
Players should be surprised by the next encounter, not an arbitrary decision.
As a player, I find item strips and hard class/race restriction distasteful because they reduce replayability and I love replaying the mods I love. But I accept that sometimes its a part of a creator’s vision. They do seem a bit pointless in a community where half those that would play are builders themselves and the other half have long list of console commands to pull from.
You trust your players or you don’t, I guess. On the one hand, yeah, players will likely get bored fast if they are too powerful so you are possibly protecting them from themselves, but I am not sure it is worth it. That said, I am not a builder myself. I only have experience with design in the pen and paper arena. So my opinion should maybe be taken with a grain of salt.
Lance and i (mostly Lance) have been hashing out the issue in PM. ( the issue here is not “do you like to play x” /shrug )
The issue seems to be that when overriding stock objects, using those same stock tags to equip creatures that may appear via Encounter-triggers, the function GetObjectByTag() can/will return rogue items (or as I call them, mystery items) in a pseudo-valid way … they have no Possessor and they are not found in any of the module’s Areas. Lance and i went through 64 messages trying to figure out wtf
[edit: It might have something to do with the caching of Encounter creatures.]
Eventually Lance began removing areas from the module that the fake-returns were happening in – and noticed that the mystery items stopped appearing when certain areas were removed. He then tracked it down further to Encounter-triggers and the fact that some of the creatures in their encounter-lists had equipment that he’d overridden in the Campaign folder.
remove the Encounter from the area and all good. Or don’t override stock equipment with items that have the same stock tag, and all good enough (the rogue items still happen but it’s inconsequential). Or don’t use GetObjectByTag() in a module that has Encounter-triggers until you’re sure the player has saved and reloaded.
@Lance_Botelle will probly have a bit more to say about this later … I think he has a few more hours of testing yet to do
ps. When the player saves and reloads it sorts itself out ( the save-write routine probably ignores such false items )
pps. The issue first manifested when a PC is stripped on initial entry. Lance was checking if PC had a certain item w/ GetObjectByTag("unique_tag") only to find that it was returning several instances when there should have been only one (or none) in the entire Module.
Now I am aware of the issue, l am likely to recheck where I am using the GetObjectByTag function, and double check current encounter items.
Hopefully, I can address code where rogue items may be an issue, and work with the save and reload solution with imported items.
As KevL says, this is a post about a coding issue rather than one of play pref.
Thanks.
EDIT: By the way, there is sometimes very good reasons to strip items from PCs. Otherwise you can end up with duplicated plot items or duplicated one off items that we need to find only one of.
Please now refer to this post (IMPORTANT BUILDER INFO)