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 ]