Athelbras

I am able to block a NexusMods user from all of my content if that user has posted in one of my mod's forums -- by using that mod's Manage feature. However, there is apparently no way to block a user if there is no post by that user in any of my mod forums. My request then is to please provide a way to do that. [ or to please help me understand how to do it if that feature already exists and I have simply overlooked it ] Currently blocked users are shown in the Content Blocking tab of "My Nexus Account". Perhaps enhance that UI to enable names to be added. My reason for requesting such a feature is that there have recently been multiple NexusMods users who have deliberately uploaded my mods (or variations of my mods) without permission to various web sites ... but they never posted in my mod forums. I very much want to block those users from all of my content to help minimize abuse of my creative works. -- Athelbras

Here is a list of the Google Chrome extensions that were present. All were enabled. I disabled them. Google Docs Offline Logitech Smooth Scrolling Norton Security Toolbar Norton Safe Search as default for Chrome Windows Defender Browser Protection I then cleared all Chrome browsing data, restarted Chrome, confirmed those extensions were still disabled with no other extensions present, disabled Norton's Auto-Protect and Smart Firewall, then restarted Chrome once more. I think I did all that could be done, although I might be mistaken. The result was the same abysmal upload performance. So unless there is something more that I could do to isolate and identify the root cause, this is then just an FYI for other players using Chrome.

FYI, It appears to be an issue when using Google's Chrome browser. Switching to Microsoft's Internet Explorer resulted in reasonable average upload times for the 11 files that I just now uploaded in succession. Whereas Chrome continued to struggle with inordinately long completion times (or never completed at all). So perhaps something in Chrome changed for the worse a couple of months ago?

Here is an example from this evening (with similar results occurring back in May and June): Uploading a 3 MB file (very tiny) creeps and stalls its way very slowly to roughly 90% during a period of half an hour, then stalls there at 90% for the next half hour thereafter. I abort the upload after waiting a full hour and try again. The same thing happens once more. In the past, a 3 MB file would upload in mere moments. Because it is tiny (the only thing smaller being a file size of Kilobytes). But for a while now it seems as if Nexus Mods struggles with even the smallest of files and yields upload times that are more appropriate for Gigabyte files. Upon rare occasion a small upload does succeeds after taking half, three-quarters, or a full hour.

For the past two months or so the upload time for a new mod that is minuscule in size has tended to be upwards of half an hour to a full hour. This was not the case in past years, or even during the early part of this year -- upload times were relatively quick and quite reasonable then. But now the situation is quite abysmal, with uploads barely inching forward then stalling out with no progress for significant periods of time, then repeating the inching/stalling. Is Nexus Mods overloaded with too many games and too many downloaders? Does Nexus Mods need to upgrade its infrastructure to provide better service to Mod Uploaders (us folks from whom Nexus Mods derives its reason for being)? Hopefully someone will investigate uploading performance, if that is not happening already. Regards, Athelbras

Yes, this approach keeps weapons intact, with all of the correct mods and characteristics, including for Legendary dropped weapons. I verified that with multiple test cases.

Settlement Tidy Bot can be found Here.

Final Solution: The idea was to have scripting that removes dead things from the game, but which also recovers items from that corpse, including its dropped weapon. The RemoveAllItems() function works correctly to take everything from the Corpse. But not the dropped weapon, because it is not actually in the corpse's inventory. I am not able to directly determine the weapon an Actor dropped when it died: when using scripted functions on the corpse there is no way to get an object reference for the weapon, and when using scripted functions on the weapon there is no way to get an object reference for the corpse. So what I do is use the FindAllReferencesWithKeyword function, with ObjectTypeWeapon as the keyword, to acquire references to all weapons in the area. Found weapons that are currently disabled or deleted are removed from that list of known weapons. Then, for a specific corpse, I use Disable() on that corpse which causes the game to disable both the corpse and its dropped weapon and also causes the game to automatically delete the weapon. Next, I examine each of the weapons acquired via that "Find" function to see if one of them is now deleted. If there is a deleted weapon, then that is the dropped weapon. If there is no deleted weapon, then none was actually dropped. As a final step, the AddItem() function is used to acquire the deleted weapon. This function does not actually take the weapon (because it is deleted), but instead acquires a usable copy of the weapon.

@akiras404 If a corpse is disabled, the game automatically disables the dropped weapon ... but the game also immediately deletes that weapon right then as well, even though the corpse has not yet been deleted. And if a disabled corpse is re-enabled, the weapon remains deleted. There is no way to un-delete it -- once Delete() is invoked on something, there is no way to restore it back to how it was. I discovered all of this last week while experimenting, and so set that approach aside as being unsuccessful. But ... your post caused me to begin wondering: what would actually happen if my bot tried to take an already deleted weapon? Doing that didn't really make any sense. But I tried it anyway. The answer is that the deleted weapon is not affected. It remains deleted, and like all deleted things is eventually purged from the game. However ... an exact *copy* of that weapon is placed in the bot's inventory!!! A perfectly usable item that is itself not flagged as deleted, does not disappear when the corpse is gone, and which can be used normally thereafter. Perfect. So your suggestion was excellent! It sparked me to try something that I was quite sure would fail. But it worked! Thank you, and a Kudo, for helping me solve this problem. Athelbras

@OldMansBeard Thank you for posting your thoughts ... Yes, the get EquippedWeapon on the corpse does return None. None is also returned when directly requesting an owner reference from the weapon. Same for faction owner. [ I am using a dead Raider here for discussion purposes ] I can get a BaseID of the owner from the weapon, but it seems nothing significant can be done with that -- very limited set of functions available. I had hoped to use GetClass on a weapon's owner BaseID as a way to at least match that class with a (hopefully) appropriate nearby Corpse's class, but the class value changes when an Actor dies; e.g. it is no longer "raider". The idea was to maybe only process corpses for the very few defined "bad guy" classes (and leave the "good guys" to fend for themselves). Maybe I could do that same thing more broadly using the BaseID's themselves, but there are an awful lot of them. The issue that I am trying to avoid is this: if the bot's scan overlaps a shopkeeper's inventory where weapons are out on display, or overlaps a weapons rack a player has placed in a home, those weapons will all be taken if they are not filtered out. To avoid that, being able to directly associate a specific weapon with a specific corpse would provide that filtering mechanism. Actively tracking all of the NPCs within a settlement to know the weapon that was readied/used when they die ... seems likely to be successful, but it also seems potentially beyond the scope of this mod. I'll give it further thought; the suggestion is appreciated.

Okay, thank you for your insights about this forum. The 'bot is essentially an Undertaker who deals with the dead, as they pile up around a settlement. I've had multiple requests for it. The living are someone else's purview. <chuckle>

For what can be posted here .. as you noted, then someone must change the blurb for this forum, because otherwise it is a misleading and blatant falsehood. For example, I've been around here for years (as a very infrequent poster), and it has evidently misled me, because I took it at face value. [so is this forum (now) just a chit-chat forum? That seems to make "established mod author" irrelevant] Your everything-I-have-tried comment is valid. Apologies. I literally tried every papyrus linkage function and ownership function in various ways in both directions (as appropriate). The idea is/was to establish a solid one-to-one relationship, but would settle for at least a loose reasonably-likely association (e.g. an attempt to relate the corpse's known actor Class to the weapon's supposed owner's actor Class and coupled by proximity -- but the Class values returned for Actor corpses are broken/unreliable; as in an Actor can have a Raider Class but that Actor's corpse has a meaningless Class value). [ GetLinkedRef, GetLinkedRefChain, GetLinkedRefArray, GetLinkedRefChildren, GetRefsLinkedToMe, HasOwner, HasActorOwner, HasActorRefOwner, GetActorOwner, GetActorRefOwner, GetFactionOwner, GetContainer, HasContainer, RemoveAllItems, Drop, DropFirstObject, HasKeyword, GetClass, ... ]

Thank you for your reply ... I currently use Find that way as a make-shift mechanism. It works for finding weapons in the area, but there are notable issues with it, since the discovered objects can not (apparently) be related back to the specific corpses that dropped them. So I am hesitant to upload this mod (which is otherwise completed) because of those issues/risks. I was tempted to include all of that as part of my initial post, but figured it was already rather wordy.

Well ... according to the title blurb for this forum, this is indeed an acceptable place for this to be posted ... General Mod Author DiscussionA place for established mod authors to discuss anything they want So this is a problem that I would like to discuss, here, with the established mod authors, instead of with the multitude of less experienced authors who frequent other forums. [ no disrespect intended ]

Whoopsy!!! It is for Fallout 4. [ edited the content, but don't seem to be allowed to edit the title ]

THE QUESTION: For FO4, does anyone know how to get the ObjectReference for a Dead NPC's dropped weapon? I have scripted a 'Bot that goes around gathering items from dead NPCs, and thereafter removes those corpses from the game world. But it is not yet able to acquire dead NPC's dropped weapons ... When an NPC dies and has a drawn weapon, that weapon is dropped. When a player examines the corpse, that weapon is presented as being in the corpse's inventory and can be taken by the player. The weapon can also be taken directly from the ground instead. However, the dropped weapon is not actually in the corpse's inventory. This can be readily confirmed using console mode commands and scripting. Hence, the seemingly obvious solution -- the RemoveAllItems function -- does not in fact acquire that weapon (it fails to do that). And unfortunately, the dropped weapon automatically disappears if not yet taken when the corpse is disabled or deleted. Which means my 'bot can't simply remove the corpse after looting it and leave the dropped weapon to be taken by the Player instead. So the game evidently creates a special non-container association between a corpse and its dropped weapon. My current conjecture is that the corpse has a "linked reference" to its dropped weapon. But I have not been able to confirm that fact. I have tested all of the "linked reference" functions on the corpse in hopes of getting the object reference for the weapon. I tried the keyword ObjectTypeWeapon, the custom link keywords (LinkedCustom01 to LinkedCustom10), and also without a keyword via None. No success; they all return None, I also tested the linkage reference functions, plus the ownership functions, on the weapon in hopes of getting a reference to an actor (alive or dead) that I could then use for comparison. Also no success. EDIT: [ I literally tried every papyrus linkage function and ownership function in various ways in both directions as appropriate ... GetLinkedRef, GetLinkedRefChain, GetLinkedRefArray, GetLinkedRefChildren, GetRefsLinkedToMe, HasOwner, HasActorOwner, HasActorRefOwner, GetActorOwner, GetActorRefOwner, GetFactionOwner, GetContainer, HasContainer, RemoveAllItems, Drop, DropFirstObject, HasKeyword, GetClass, ... ] If the game does indeed use a linked reference, then perhaps I simply need the correct keyword value ... if so, does anyone know it? Or does anyone have a suggestion, or perhaps an actual solution, that takes a different approach to solving this problem? < Athelbras > [ Moderators -- please do not move this post to elsewhere -- these are the folks from whom I would greatly appreciate advice for solving this problem ]

@ELMOSTWANTEDXD You most likely used an older version of NMM for your installs. The current NMM version as of this reply is 0.65.8, which works correctly when installing EVE. Here is where to find the most recent NMM release: https://github.com/Nexus-Mods/Nexus-Mod-Manager/releases Regards, Athelbras EVE Support

RemoveAllItems seems to work fine for me where the source is a dead NPC companion and the destination container's reference is flagged as "persistent" in Worldspace and located in a different unloaded cell.

Something like this ... float fAnglefloat fSinfloat fCosfloat fHeight fAngle = Game.GetPlayer().GetAngleZ() + 180.0fSin = Math.sin(fAngle)fCos = Math.cos(fAngle)fHeight = Game.GetPlayer().GetPositionZ() pMyNPC.MoveTo(Game.GetPlayer(), 70.0 * fSin, 70.0 * fCos, fHeight, False) Note that the correct height of "ground level" at 70 units behind the player's character is not handled by the code snippet above. Might actually be higher or lower than the player character's, depending on the nature of the terrain. So that is something for you to resolve in your own final scripting.

The 2mm Electronic Cartridge ammo defined by CFW, whether found as is or created via either of the two recipes, works fine with all of the CFW gauss weapons when there are no conflicts. This can be readily proven in various ways. Note that CFW provides and uses only one type of 2mm EC ammunition; there are no variants. So you basically have a conflict between CFW and one or more other things that you installed. Assuming you mean CaliberX, the problem could indeed be the lack of proper compatibility. Try temporarily disabling CaliberX to see if the CFW gauss guns can then use their own ammo. Also, note that there is a CaliberX patch for CFW in "CaliberX Patches" by Morton which might solve the problem. Otherwise, the next step seems to be discovering exactly what is breaking CFW. You may need to either (1) use FNVEdit to look for conflicts, or (2) use the standard troubleshooting techniques to discover which mod(s)/patch(es) are breaking CFW ... as in temporarily disable things one-by-one or in small groups to see what causes the problem to go away when disabled, or else disable everything except CFW and then [re]enable things one-by-one or in small groups to see what causes the problem to suddenly appear when enabled.

There is no Projectile entry in the 2mm EC ammo record because the correct projectile item is specified in each individual weapon record; i.e. CFW2mmECProjectile. There are two recipes for creating 2mm EC ammo - regular (via Electron Charge Packs) and efficient recycling (via Drained Electron Charge packs). Science 40 is required in both cases. The gauss weapons all work fine for me, so I suspect that you do not yet understand the actual issue, whatever it may be - perhaps a mod or patch conflict. EDIT: the above reflects basic use of the current version of the CFW mod with no patches (of any kind) applied to it. So if you installed CFW-related patches (for compatibility purposes or whatever), then perhaps one or more of those patches is at fault.

See these links ... Menu Mode, http://geck.bethsoft.com/index.php?title=MenuMode Menu Mode functions, http://geck.bethsoft.com/index.php?title=MenuMode_(Function) Be sure to read the associated Notes sections. Some can be problematic, others are reliable. When used, test rigorously.

Just FYI, for folks with "alternate start" mods who may not be aware of the issue or the fix ... Background: When a mod skips/avoids the execution of quest MQ101's stage 405 it causes vertibirds to have silent engine sounds thereafter. Solution: Execute a one-time invocation of this command ... PCSMQ101PlayerHouseInt.Remove() ... where PCSMQ101PlayerHouseInt is a reference to the SoundCategorySnapshot property CSMQ101PlayerHouseInt The game itself does that in the papyrus fragment for Stage 405 of MQ101 when the player character opens the front door of his/her initial home. Explanation: While CSMQ101PlayerHouseInt is in effect, it overrides the volume multiplier settings for AudioCategorySFXvertibird, AudioCategoryZVertibirdEnginesExterior, and AudioCategoryZVertibirdenginesInterior, forcing them to be Zero. Hence there is no audio for vertibird engine sounds unless the Stage 405 papyrus fragment is executed. The Remove() function cancels that override. [ CREDIT: insight for this scripted solution was provided by Cubox in a post for "Another Life" ]

Looks like it can occur for *any* of the automatic packaging mechanisms. For example, selecting "Create Archive" from the Files tab, as well as the auto packing when uploading to Bethesda.net. So double-check the lists, and then add missing files. Or run Archive2.exe and explicitly select the files and folders to pack.

FYI, When uploading files to Bethesda.net, if you use the automated packaging of files into .BA2's, be sure to carefully double-check the files that are being included ... verify that *all* of the required items are listed ... because files can be missing / skipped-over. Check by examining the files in the list that is presented, or review the final packages using a tool such as Bethesda Archive Extractor (BAE). This issue happens consistently for me for certain mesh files. UPDATE: Not just Bethesda.net packaging for uploads. It can happen any time automated packaging is requested ... for example, selecting the "Create Archive" option in the File tab.