nb. Lance you can add another case to the list: despawning a rostermember.
Workaround. If you really need to use GetObjectByTag() ( instead of an inventory function like GetItemPossessedBy() or GetFirst/NextItemInInventory() )
this should work …
object oItem = GetObjectByTag("tag");
if (GetIsObjectValid(oItem)
&& (GetIsObjectValid(GetItemPossessor(oItem)) || GetIsObjectValid(GetArea(oItem))))
{
// oItem is not rogue here
}
Yes, I thought that was going to be the case when I read this post … but the principle is the same.
That’s pretty much what I did for two of my functions.
Exactly … It’s all item types. (I just happened to be working on plot items when it raised its ugly head.)
Although, now we are aware of this kind of behaviour, I reckon we can still make good use of GetObjectByTag, as long as we consider this type of return as valid, even when not actually present. i.e. In some ways, this function is a “bonus” because it manages to locate potential items too! And is why in this instance, its unusual behaviour may actually help us locate and retag the various shard pieces as we need them.
That’s what i was thinkin’ too … so it’s additionally disconcerting to see that loading this testsave does instance a rogue-shard.
(but i don’t know how the rogue-instance happened in the first place)
[edit]
there’s a blueprint 30_reaver1.UTC that has a shard#8 but I don’t think that’s the rogue (only the shards possessed by Zhjaeve are the real thing) … because the .UTC also has nw_wplmsc006 Wicked Union scythe but GetObjectByTag() does NOT find the scythe as a rogue item.
Also looked at the module load and area load scripts (etc etc); none of them destroys any items …
Yet having unpacked and searched the files in the save, I can’t find it /aargh
note that Plot items can be destroyed without that line. Maybe placeables too … certainly not creatures though (?)
Ammon Jerro has silver shard 7 (fire and cold resistance) in his inventory as part of his starting equipment when he is created. He is where silver shard 7 originates.
The silver shard being in his possession is likely mentioned in a conversation, but I can’t think of which conversation.
The rogue shard will return as an instance until we have destroyed it and the game saved in the shard’s destroyed state, before reloading that “destroyed state” game. However, if you are saying that even in this case the instance returns, then maybe that would suggest a “backup” check is being made and a new instance being created? Or, I guess the issue could also occur, if a roster member is carrying a shard, and their state is not being updated between save and reloads somehow?
I put it in as a fail-safe, in case anything argued with me.
That’s surprising, considering what you say above.
OK, I’m intrigued to look too now.
I’m not sure how far I will pursue it, as it sounds like you already have it mostly in hand, and are likely to have solved it by the time I see anything. However, maybe I can help find something?
@Akhacha points out the key issues, which I also note.
To reiterate the issue as I currently understand it …
The UnequipPC function used in the script is not fit for purpose, as it overlooks both these issues, by assuming the Main PC will be the carrier of all the shards … and are also not being carried inside any bag containers the PC may be carrying. The issue is compounded (as already stated), if these shards are located elsewhere, like on a companion, and possibly even in a container they carry. And as shards may have also been placed on companions now currently despawned, we also have a continuity issue if that companion is taken back into the party with shards that are supposed to no longer exist.
I would add that there is another potential issue in a MP environment, where players can choose to switch leadership, meaning anything assumed to be on a leader, will certainly not be the case. I experienced this myself, when I recently played the campaign with a friend. After this cutscene, we noted that some shards remained in my inventory, because even though I had collected some, and he others, I would transfer leadership to him in some circumstances. (I guessed what had happened at the time, but did not look into it then, as all seemed fine elsewhere.)
ALTHOUGH, see UPDATE below, regarding Ammon Jerro speech.
0 ---- 0
Having considered the issue some more (and recognising the many potential locations the shards could end up), I am wondering (just as a suggestion) if it might be easier to approach this problem from another way … rather than try to locate all shards to destroy (at time of forging), maybe, instead, ensure all shards are forced to be carried by the host player. In a SP game, this would always be the leader anyway, and would also resolve the MP side of the problem. The “downsides” are (i) only the main PC would benefit from shard properties and (ii) we may need to give a story logical reason why this is the case. (*)
We would still need to address the broken item count in the UnequipPC function (remove it completely), but as the shards take up slots on the Main PC anyway, their destruction (at time of forging) would make way for any weapons needed to be unequipped as well as leave a slot for the new sword. EDIT: Actually, shards in container bags still needs considering if an inventory is full. I will consider that now.
(*) As the Main PC is supposed to be the “shard-bearer”, then maybe we can imply that any additional shards found can only be carried by them?
I believe reworking all shards to be placed on the Main PC (on any acquisition) may help resolve a lot of other headaches. It would require editing the k_mod_acquire to ensure any shard was placed onto the Main PC … A bit of a reverse of k_mod_unacquire, which would also need editing.
@kevL_sAlso k_mod_unacquire may explain why you have a persistent shard at times, as it replaces any shard “lost”? Although, if “destroyed”, I would not have thought this to be invoked.
If this alternative way was considered, then maybe this would work as the On Acquired script (edited official) … But bear in mind extra checks need to be added if being hosted by a DM, otherwise, they would end up with the shards!
// k_mod_unacquire
/*
Module unacquire item script
gets the tag of the item and calls:
"i_<tag>_ua"
*/
// ChazM 3/1/05
// BMA-OEI 9/26/05 moved concat below string trim
// ChazM 10/20/05 - hook back in to the x2_mod_def* script
// OC
#include "ginc_death"
///////////////////////////////////////////////////////////////////////////////
// JUST RETURNS FIRST PC IN A SP GAME. (NB: COULD BE A DM IN A MP GAME SETUP!)
// MP: ALWAYS RETURNS THE SAME PLAYER, BUT THEY COULD BE A DM.
///////////////////////////////////////////////////////////////////////////////
object GetTheGameHost();
object GetTheGameHost()
{
object oModule = GetModule();
object oGAMEHOST = GetLocalObject(oModule, "GAMEHOST");
if(oGAMEHOST != OBJECT_INVALID){return oGAMEHOST;}
// SETUP (BACKWARD COMPATIBLE)
else
{
object oHost = OBJECT_INVALID;
if(GetIsSinglePlayer())
{
oHost = GetFirstPC();
}
else
{
object oTestHost = GetFirstPC();
while(oTestHost != OBJECT_INVALID)
{
if(GetIsPCHost(oTestHost))
{
oHost = oTestHost;
// STORE FOR RETRIEVAL
SetLocalObject(oModule, "GAMEHOST", oHost);
break;
}
oTestHost = GetNextPC();
}
}
string sHOSTREF = GetPCPublicCDKey(oHost);
SetGlobalString("HOSTREF", sHOSTREF);
return oHost;
}
}
const string SHARD_TAG_PREFIX = "nwn2_it_shard";
int GetIsShard(object oItem)
{
int nChars = GetStringLength(SHARD_TAG_PREFIX);
return (GetStringLeft(GetTag(oItem), nChars) == SHARD_TAG_PREFIX);
}
void main()
{
object oItem = GetModuleItemAcquired();
//GIVE ANY SHARD FOUND TO THE HOST PLAYER
if(GetIsShard(oItem))
{
object oFinder = GetModuleItemAcquired();
object oHost = GetTheGameHost();
//this event would fire if the player passed the item to a party member, which we allow.
if(oFinder != oHost)
{
CopyObject(oItem, GetLocation(oHost), oHost);
DestroyObject(oItem);
}
}
ExecuteScript("x2_mod_def_unaqu", OBJECT_SELF);
/*
object oItem = GetModuleItemLost();
string sTag = GetTag(oItem);
if (GetStringLength(sTag) > 11)
{
sTag = GetStringLeft(sTag, 11);
}
sTag = "i_" + sTag + "_ua";
ExecuteScript(sTag, OBJECT_SELF);
*/
}
Oh! That may add another level of complexity. I’ll try to check that too, to see if it does complicate matters.
@Axe_Edge Just out of interest, has anyone tried selling a shard? Is that possible? I mean it does not show as a “plot” item in the item properties, so is a plot flag set somewhere else, which I cannot find. EDIT: I just checked an old saved game of my own, and it appears the plot flag has been set somewhere, as I cannot sell them.
0 ---- 0
UPDATE: Interestingly, Ammon Jerro says, "I do not believe reforging the sword will require all the shards – but as I have never done such a thing, I do not know for certain.", which means there is argument to suggest not every shard requires “destroying” upon its forging. So any shards remaining at time of its forging may be considered “not” an issue?
So, arguably, the only real issue is the items dropped at time of forging … reconsidering …
please don’t fuss too much over it. I’ve gone way beyond the original issue. So the cutscene script you’re looking at is very different from the one I’m (pretty much done) working on …
the PCs hand-items now drop only for an extreme case. Ie, only if all slots are really full and none of them are shards (like you suggest, shards shall be destroyed before the SilverSword is granted, to potentially open up slots on PcSpeaker).
also done: destroy all shards in the module and on the roster, and ensure no rogue shards remain.
Plus a whackload of changes to get that cutscene to play more immersively. Characters no longer fritter about or stare off into space, etc.
And note that for Nwn2Fixes i won’t (or at least shouldn’t if at all possible) make fundamental changes to ingame mechanics, like adding restrictions on shards,
long story short: it’s working. All that’s left to do is destroy any shards that player(s) may have stashed in chests in the other Modules. (and this isn’t even strictly necessary for the ‘commit’ im working on)
The question of Leadership is interesting. I’ve put in some code that assumes that the Leader (-> PcSpeaker) should be the shard-bearer, although I don’t think (atm) anything will break if Leader/PcSpeaker is not the shard-bearer. But I don’t have an MP setup to test things like yourself; perhaps you can/would like to take a look and test that after i get a reasonably stable version ready.
The (alleged) fact that I’m seeing a rogue shard immediately after loading a save is sort of a sidenote to all this. The code I’ve written for destroying the shards should handle it okay. But it is ofc relevant to our understanding of those rogue items in general; so id like to know what causes it in this situation. But, again, wait and i can send a testcase w/ changed scripts, dialog, and a Savegame to ya,
The original code, it seems to me, is attempting to destroy all shards. There’s no note saying one way or the other. Those lines of dialog could be alluding to an idea that there might be more shards ‘out there’ (but that never appear ingame, aka Lore).
but that’s a neverending discussion …
Re. Plot shards. Their blueprints in the toolset all have Plot checked here. (ofc this doesn’t mean that placed shards, eg. on AJ or in chests or on reavers or wherever, have their flags checked also).
At least it gave me a short diversion, and it was interesting to see how they handled the shard cutscene.
My only problem here, is that I don’t have a saved game in a position to test it, especially as the person I play with is at another location … their house and not mine. That said, if you ever manage to setup a saved game where a player can connect remotely for testing your code, I can help if that is possible?
Good to know!
Oh, I see … fair point. I think I would have pursued destroying all found as well anyway.
That’s weird, I only noticed non-plot in the module I loaded … but I guess they were set so elsewhere …
Your version appears different to my own setup. You appear to be able to edit the properties direct from the original instance, where mine are greyed out. Let alone have plot enabled
How are you accessing the OC module?
I simply copied the OC module to my module folder and look at it from there. I had always assumed it was write protected as such (where greyed out), as I can only alter copies of object instances from any OC module. IE. If I need to alter any object, I have to make a copy of it first.
bytesize is the same as yours, and the 1hr difference of the Modified date is just a quirk i notice every so often: am 99.9% sure they’re the same file, Lance.
I am using Win10 (updated from Win 7) and so there is some diff there …
I switched off VirtualStore for the folder, but that makes no diff.
I suppose switching to using a root folder rather via than Program Files may make a diff too.
I just gave full permission to the copies I made of them (moved to working folder).
I wonder if the 1hr diff is either a time zone thing, or perhaps because I have a “Limited Edition - Lawful Good” install that came out when first released?
I am running the same Windows (with many updates) instal since a Windows 7 install (many years ago), and so I imagine it’s quite possible my computer has some legacy code that affects this too.
I guess I may find out if there is a difference if I ever have to d a complete Windows reinstall … although that’s not something I am eager to have to do.
EDIT: OK, I found where the edit took place … It actually edited the OFFICIAL CAMPAIGN ONES!
(ie: Not the copies!) Perhaps the way the Campaign Editor works is affecting the files somehow?
There is something very strange going on when I try to alter copies of the OC files …
Copies of the campaign files are in my Documents Neverwinter folder …
Read/write permissions given.
VirtualStore turned off (as far as I can see) and no files in the folder.
Edited c_silver_sword_onhb (campaign script) (added TEST comment), and saved file.
Saved the campaign file with edit, and opened NSS campaign version and no “TEST”.
Reopened “same file” in toolset and “TEST” comment is there.
File info shows no changes to file! Huh!?
Any ideas? Where has my edited copy gone again … considering I cannot find it even in any potential VirtualStore location? (Which as far as I can tell, is switched off for this folder anyway.)
EDIT: OK, I found where the edit took place … It actually edited the OFFICIAL CAMPAIGN ONES!
(ie: Not the copies!) Perhaps the way the Campaign Editor works is affecting the files somehow?
Is there a way to do the following … as it does not appear to work for me …
Copy OC Campaign folders and modules to our Documents folder.
Edit the copied versions?
The problem I appear to be having (especially now VirtualStore has been disabled, which helps clarify what appears to be happening) …
If I load the copy of an OC module into the toolset, if I edit a campaign script, it edits the original campaign folder script (in the Atari folder).
I thought it would be a simple matter of reassociating module and campaigns with their appropriate “copies” via the Campaign Editor, but that does not appear to work … as editing a campaign script after this, still appears to edit the original Campaign Scripts in the Atari folder.
I can’t really alter the names directly, as it would likely break some internal code (referencing modules to load etc.), but it would be good to know if it is possible to setup a Documents Directory copy of the OC files to work on without compromising the originals. EDIT: Just as a test, I also changed the names of both campaign folder and module and tried reassociating these renamed copies of one another via the campaign editor, and still editing a campaign script altered the original Atari folder version and not the renamed copy.
So, is this even possible?
Apologies for going a bit off topic here … maybe continue via PM? (Unless others are interested in this?)
And where are the UTI files for the shards for you?
So, short of unzipping them into the campaign folder, did you do anything else to have them “available”? EDIT: However, even this did not work, as the system still appeared to redirect to the Atari file versions, ignoring any campaign copy I had redirected the module towards. Bizarre! i.e. The toolset still referenced the “template” versions (greyed out), even though I thought it may now reference copies placed in the copied campaign folder to which the copied module was now directed. But nope!
it’s just something I see every so often (on my machine) – very probably related to daylight saving time here … since the diff is always exactly 1hr. (have seen this discrepancy one way or another dozens of times over the years)
what with all the folders, paths, campaigns, and ‘override’ hierarchy going on … it’s a tricky business figuring out exactly what file(s) you’re looking at and/are being edited … (agreed). the toolset isn’t as transparent/forthcoming as it could have been …
Personally i installed Everything a long time ago – by far the best filename search/listing app I have ever used. If i had to pay the guy a penny for every time i used it … I wouldn’t use it because id be broke.
re. screenshot : are you copying the install/campaign folder to a mydocs/campaign folder? That doesn’t strike me as a good idea; that is, sounds like an easy way to confuse the toolset …
I’d leave the files where they are (in the campaign folder). Backup the file you want to modify (manually, in FileExplorer) then edit the copy. This should leave the toolset with only one version of the file to find. May require closing the toolset, making the backup/copy pair, then reopening the toolset and doing the modification.
eg. c_silver_sword_onhb.nss → backed up as c_silver_sword_onhb_bak.nss // backup
or c_silver_sword_onhb_org.nss // original
Etc.
(i actually use a tilde instead of an underscore so the files stand out in FileExplorer, like a sore thumb). eg
if you really want to edit and save official .MOD files … uhh …
it’s going to depend on a bunch of things, like if they’re in a window-protected directory like Program Files … idk, you might have the same problem with the idea above re. Campaign files …
I learned the lesson quite some time ago : don’t install a program that you might want to modify the files of under a windows-protected directory.
( such protection can be turned off or bypassed … but it could take a fair bit of googling if you’re not familiar already )
(but to be honest it sounds like windows is already allowing you to change files there … you know – the ones that you didn’t expect to be changed ;)
uh (no). I suspect the toolset is going to grab the first match it finds; could be under installation or Mydocs … so try not to confuse the poor toolset (or the nwn2 executable)
Personally to tinker with official .MOD files, I back up the original and open the copy and then save it as a directory under Mydocs with a different directory name like 3000_Neverwinter_A3_kL
close and reopen the toolset. (do not confuse the poor toolset :)
3000_Neverwinter_A3 but probably in a bunch of other .MOD files also
ok in /Data/Templates.zip
and a bunch are instanced (preplaced) in chests and on creatures (instanced or spawned blueprints)
I came across this textfile on my harddrive the other day … sry it’s not well formatted but it has info →
nope. I just open the toolset and they appear under Item Blueprints. If I modify one and save it, it should appear (as a .UTI file) in my MyDocs/nwn2/override folder …
Yes, originally, I had installed NWN2 outside the ProgramFiles directory … but on a Windows reinstall once, I forgot to change the install and didn’t have patience to install again … then history.
I also looked around (as you say) to try to determine bypassing such protections, but I think NWN2 toolset setup also has a number of additional factors that are complicating matters (as you say) …
Exactly … I now have come to realise this myself.
Yeh … that’s as close as I can get … but we still cannot directly edit the campaign files … so, like you, I keep a backup copy of the complete campaign directories to restore from after any tinkering I may do.
So, these are not greyed out for you from the start?
This is the weirdest part for me, as you appear to have a direct access to them compared to my need to create a new instance, normally by clicking on them and dropping them in an area to work with. Then that copy is not greyed out, and then I can save it to the module/campaign … but I dread to think where that UTI file will end up … probably part of a renamed module (I guess), but as for the campaign version of the UTI … I currently have no idea!
(I just happened to be working on plot items when it raised its ugly head.)
