Athelbras

@Fallout2AM Thank you for contributing to the discussion. Otherwise the explanation might have been a long time coming.

Note that even if the Respawn flag is set (as per the wiki), the NPC is still flushed upon cell reset; quite possibly because the exception only applies to statically placed entities - which of course makes sense (I was hoping it would apply regardless and thus provide a workaround).

Here we go ... this is the explanation. With regard to PlaceAtMe: "Actor references created using this function that are not set to respawn are removed upon cell reset." Would be nice if there were caveats and cross-referencing within the wiki's Disable and MarkForDelete descriptions. So the "problem" is/was merely an oversight on my part.

I suspect that the difference is in your approach versus mine. You have your NPCs statically positioned. Mine are put in place by means of a PlaceAtMe and then a MoveTo. My approach clearly allows the scripts to run. Yours does not. Why, I don't know. Look. This is silly. My approach works. Period. It has been in a companion mod for many months, with many such automated encounters throughout the game, and they have all worked flawlessly ... up until this recent discovery concerning PurgeCellBuffers. So telling me that what I am doing does not really work is non-productive. You are welcome to experience my implementation yourself: Buddy Bot. Once Buddy joins you, just proceed up the long road up the slope that leads up to the Mojave Outpost; that is the easiest one to readily trigger. There will be three separate encounters along the way. All of them have "Initially Disabled" and only become enabled via their own assigned script; ergo they have running scripts while disabled. To get the discussion back on track ... the real issue is whether or not PurgeCellBuffers should validly clobber Disabled objects (in this case with their own scripts) which do not have their Delete flag set. If so, that is not documented and is seemingly contrary to various descriptions in the wiki; see Disable and MarkForDelete. Meaning either the wiki is wrong, or there is a game bug; or maybe my interpretation of what is written is mistaken. My hunch - and it is no more than that - is game bug.

Let me cite you another reference: " Disabled references are not rendered, and disabled actors will not process their AI. Scripts will run on disabled references." See the description for Disable. Revisit the description on MarkForDelete. One possibility is that the sentence means that I can have a script that refers to / interacts with that object, versus meaning its script actually runs. I am interpreting as the latter, where assigned scripts do run: everthing I have created thus far gives evidence that it is so, without fail. My actual implementation seemingly counters what you posted: my NPC is defined as "Initially Disabled" via GECK/FNVEdit. I do not disable him via script. He has an assigned script. I create and position him. His script is now running. He is not visible and does not appear on my radar and does nothing because he is still Disabled. But, again, the script is running and the messages appear. When I approach him he self-Enables via that script, which causes him to appear and is then actively mobile and on my radar and attacks me. Doesn't that invalidate the example you gave which indicated this should fail? As for Zan's ... my follow-up reply (as the result of further investigation) explained fairly clearly that it was not after all a Zan's issue per se, but rather a PurgeCellBuffers issue. So I acknowledged that fact. Zan's merely exacerbates the problem by performing PCB in situations where the game ordinarily does not. Cite a reference for this opinion you stated? "In general it's not a good behaviour relying on a script attached to a disabled npc". I don't mean this as an antagonistic rebuttal, but rather a further effort to discover the truth as best we can. So ... from what I have read and experienced first hand, it still seems valid to conjecture that this "problem" is actually an unintended occurrence as the result of an underlying game engine bug which clobbers disabled objects when it should not. Alternatively, it is perhaps an undocumented fact that the game engine will deliberately remove disabled objects at some point, even when their Delete flag has not been set.

I guess I am not convinced by your view. Although I may indeed be mistaken. According to the wiki, disabled things remain in memory until their delete flag is set, for example via MarkForDelete. Otherwise they continue to exist and should not be destroyed by anything, even PurgeCellBuffers. See the accompanying information about disabled items embodied in the MarkForDelete description. So instead I am wondering if this is actually an unintended occurrence as the result of an underlying game bug. As for "In general it's not a good behaviour relying on a script attached to a disabled npc", can you cite a particular reference that supports that belief?

I am able to recreate the problem manually. In essence, issuing a PurgeCellBuffers command while in a separate zone/cell results in the disabled NPC (which has an active script) no longer being "functional" when you return to the outside world where it is positioned. It is not clear whether it has been "deleted". Since scripts do intentionally run on disabled thingies, I inserted passive message calls within the NPC's script as a kind of "I'm still here!" notifier. So as long as the NPC is present and "active" (as in still disabled but also still running its script), the message is seen in the upper left-hand corner of the screen. Without Zan's, once the messages begin to appear, I can step into that nearby building to transition into a new cell, and the messages temporarily stop - because I am no longer in that NPC's world space; which is correct behavior. When I step back outside, the messages resume. I can repeat the step in and step out as much as desired, and then walk over to be within trigger range and the encounter occurs. If I step into the building and issue the PurgeCellBuffers (PCB) console command, then step back outside again ... the messages do not resume. And the encounter won't trigger. If I do the step in and out with Zan's enabled ... the messages do not resume. And the encounter won't trigger. Creating a circumstance where the game issues its own PCB has the same negative results. This can be done by travelling to a sufficiently distant location (via COC or regular map travel). Upon return the NPC is again no longer responsive: the messages do not resume and the encounter won't trigger. Note that relatively local travel via COC and the map does not necessarily result in the game issuing a PCB, and so the NPC may still be active. Note also that issuing PurgeCellBuffers while simply remaining in the area has no effect. It only matters when in a different cell location. So my current conclusion is that disabled thingies that are executing their own scripts can't be absolutely relied upon, because a PurgeCellBuffers call (either via the game's own mechanisms or via a mod like Zan's) can potentially render them non-responsive/non-functional. Less so with Zan's because it issues PCBs in situations where the game itself would not.

The issue that I am about to describe may be quite obvious to more experienced modders. In fact my approach may even be a known bad thing to do. But it had never dawned on me before. So if nothing else, this is an FYI to others not yet in the know ... The Essence: "disabled" thingies [EDIT: with an active script] can be unexpectedly purged/deleted without your knowledge or desire if a player uses Zan's AutoPurge (or a similar data flusher). Zan's minimizes out-of-memory conditions by periodically forcing the game to flush "old" data from memory, and does so much more aggressively than the game engine normally would. This potentially causes problems. For example, if a mod has an NPC set to Disabled in order for it to be both inactive and invisible until triggered (perhaps with its own scripted Enable springing it into action), that NPC could then be unexpectedly flushed/purged/deleted before coming into play. One such circumstance is the Player character being outdoors and nearing that lurking NPC, but suddenly ducking into a building to check for other enemies before proceeding onward, then coming back out again. In doing so, that zone/cell transition invokes a purge by Zan's which causes the lurking NPC to cease to exist. And flagging the NPC as Quest Item / Persistent does not prevent it. With Zan's removed, the encounter plays out successfully, regardless of the player's actions, movements, and transitions. Knowing that behavioral characteristic of Zan's, one can of course use an alternative implementation to entirely avoid the issue. It is the mods (and modders) having no knowledge of Zan's behavior that are at risk. So modders beware. - * - Caveat: I have exactly the situation described as a test case. Fully reproducible at will. But of course am willing to learn that I am misinterpreting results if someone else has better insight into what is taking place.

One of the reasons for that happening is if a saved game uses a particular mod and that mod is now absent or disabled.

You are probably at the point where you need to remove less important mods and/or choose less demanding (lower resolution) texture mods. But try Roy's suggestion - it may help you squeeze out a bit more. Since crashes usually occur at around 1.4 GB and above for normal game play, your 3+ when using the 4 GB Loader is much better than "a little bit more usage". You are actually doing quite well. If you are not yet using NVAC, that can potentially keep you going in situations where you would otherwise experience a crash. See: NVAC - New Vegas Anti Crash by Queue. Note that physical memory (RAM) isn't relevant. The issues involve "virtual memory" usage, which for a 32-bit game like FNV is strictly limited to 4 GB max. Meaning what you are experiencing with regard to crashes would be the same whether you had 2 GB of RAM or 24 GB of RAM; the amount of RAM influences game play performance. Also note that Task Manager does not present a complete picture with regard to the game's currently active memory usage, so you won't ever actually see a full 4 GB in use; various underlying system services are not taken into account in the display even though they are consuming portions of that 4 GB of virtual memory.

@rickerhk, RoyBatterian Thank you!!! Those approaches are new to me, so I will certainly investigate their potential.

Now I understand. Thank you for your responses. Very much appreciated!

Please ... your script with the OnHit block ... what is it linked to? What actor / object / whatever uses the script? Or is it somehow an unlinked script that runs all by itself? My companion has a script which is specified in its SCRI - Script field, and it is that script that has my OnHit. How is yours setup?

There must be some basic difference between what you did for the video versus what I am doing. Where do you have that OnHit block that you used for your video? By "where" I mean: in what script? And to what actor/object/whatever is that script attached? That may be the crucial information. Could you please show the scripting that you used? My OnHit blocks are in a companion NPC's script or in a companion Creature's script. Here are simple test examples. msgPlayerHit is never displayed. It is only msgOtherHit that is displayed (when the NPC/Creature is hit), because the actor reference is never Player. BEGIN OnHit if this == Player ShowMessage msgPlayerHit elseif GetSelf == Player ShowMessage msgPlayerHit elseif GetIsReference Player == 1 ShowMessage msgPlayerHit else ShowMessage msgOtherHit endif END BEGIN OnHit Player if this == Player ShowMessage msgPlayerHit elseif GetSelf == Player ShowMessage msgPlayerHit elseif GetIsReference Player == 1 ShowMessage msgPlayerHit else ShowMessage msgOtherHit endif END So perhaps your OnHit was not in a companion's script - if not, where is it located instead? Are you maybe using NVSE? I am not. In my other reply, I did not mean GetLastTarget - that should have been written as GetCombatTarget. Apologies for the confusion.

Thanks! I appreciate the fact that you took the time to offer suggestions. But I am not sure those are workable. Here is the detailed reasoning ... - GetOwnerLastTarget does not have an entry in geck.bethsoft.com under the Functions category, so I wasn't aware of it. After reading your reply, I experimented with it a bit, but haven't figured out what the function really does or how it works. I had hoped that "GetOwnerLastTarget Player" would return a reference to an NPC if an NPC attacked the player ... but it always returns 0. - OnHit can't be filtered by "Player". It is strictly NPC-reference oriented; the NPC to whom the script belongs. This is so for BEGIN OnHit as well as BEGIN OnHit Player (the Player qualifier is ignored). - There appears to be no means of getting NPC actor references for those in the current cell, so I can't invoke GetLOS for NPC-to-Player or Player-to-NPC. Meaning, there is no function to simply get a REF to an NPC actor that is currently in the cell, and then get the next one, and so on. Hence I can't construct a proper GetLOS call. But perhaps you know of a way to get references for NPC actors within a cell? - I am familiar with GetLastTarget GetCombatTarget; I use it to evaluate the nature of a companion's opponent. But, since I can't get NPC references, I have no actor reference to use for invoking GetLastTarget to see if the result is "Player"; i.e. the same problem as for GetLOS. - I could not invoke IsInCombat and GetLOS (if useable) and have "true" be an assumption that the Player is attacked. Because it is very common for nearby enemies to be only attacking one of my NPC companions while my Player character is totally ignored. So that assumption could be incorrect quite often; which (for my purposes) makes it not useful. But even so, I'd be happy to receive any further thoughts or suggestions that you might have.

I need much finer (more detailed) control than what IsInCombat offers ... What I need to know for scripting is whether the Player was personally attacked. Not just whether an overall combat situation exists. It can be done for NPCs by using GetAttacked, which becomes 1 when the NPC is directly attacked, and then cleared to 0 by OnCombatEnd. A practical use is for preventing an NPC from joining in a fight until that NPC has personally been attacked. In other words "passive until you are attacked". For example, IsInCombat can be True/1 while a fight rages between you and enemies, and the NPC companion can be kept out of that fight until he/she/it is personally attacked (as indicated by GetAttacked becoming 1); at which point the NPC can be allowed to fight as well. All under perfect scripted control. That approach works very well, and quite reliably. But if you also want to script an NPC to not join in fighting until the Player's character is personally attacked ... it doesn't work correctly (except the first time), because Player.GetAttacked is never reset to 0. It stays 1 forever. The idea was to allow the player character to do long range sniping at enemies without companions charging forward too soon. In other words "passive until I am attacked". So the approach that works perfectly for NPCs does not work for the Player character being the trigger event. And, unfortunately, OnHit is not a substitute for a properly functioning Player.GetAttacked function call, since OnHit is *only* processed for an NPC, even though a "Player" qualifier can seemingly be supplied (OnHit Player) because that qualifier is ignored; the active reference is always the NPC for that script. If it *did* work, it could potentially solve my problem - I'd set my own player-was-attacked flag. - * - And, unfortunately, IsInCombat is too generalized for my needs. It isn't really an "active combat" indicator. Instead it is an umbrella status that covers a kind of "you're in trouble" situation. It certainly has a value of 1 during a fight. But is also 1 if "enemies are actively searching for the player" but have not actually found you, and so haven't even started attacking yet. It can also be 1 if enemies are attacking one of your companions while you are being totally ignored. Which means if I use IsInCombat, and my NPC is set for "passive until I am attacked", it goes charging off before I am directly attacked or fighting even begins. In actuality, IsInCombat can remain set to 1 across *multiple* instances of actual fighting (as demarcated by OnCombatEnd), with long intervals of nothing much happening in-between, and not reset to 0 until minutes after the last OnCombatEnd occurred. - * - My current conjecture is that Player.GetAttacked is never reset to 0 because there is *no* processing for OnCombatEnd using the Player's reference, which is where/how it would be reset (as per NPCs). And although you can script a separate "OnCombatEnd Player" block, the "Player" qualifier is ignored and the NPC reference is passed along instead. I had thought the Player.GetAttack issue might be a bug. But I am now thinking it is a "feature"; as in the Devs didn't see the need to have block processing for the Player reference; which includes OnHit, OnStartCombat, and OnCombatEnd. Which caused Player.GetAttack to be a broken function, which they either did not notice or did not care to fix. - * - So ... anyone have a suggestion or idea? [simply monitoring Player health feels like it would be crude and error-prone/unreliable]

According to the GECK's write-up for GetAttacked in FNV: "Returns 1 if the calling actor has been attacked. This value is cleared when the actor drops out of combat." But in my tests it never clears for Player.GetAttacked. It begins with 0 when a player character is initially created, but as soon as that character is attacked during its first combat situation, it remains stuck at 1 forever. This is true whether the function is invoked within GameMode of a follower script, or within OnCombatEnd, or within any other ON condition, or in any quest script, etc. Note though that GetAttacked *does* work correctly when used for an NPC, such as in the script for any of my companion mods; e.g. MBRipperREF.GetAttacked is properly reset to 0 when combat ends for that NPC. So the question is this: does Player.GetAttacked really work and something is wrong with my environment? Or is this a known bug? If a known bug, is there a known way to clear that status flag within OnCombatEnd (or elsewhere) so that calls to GetAttack for Player work correctly? Alternatively, I'll just use some workaround, but am wondering if there is a way to use the function as originally intended.

Looks like the "bug" can happen even with a target REF specified ... I recently discovered this problem in our EVE mod. It occurs when transferring loot from a corpse to a remains object (ash pile, goo puddle, etc.). The bug does indeed manifest when multiple armor / clothing items are equipped, and it occurs consistently for a given test case. When the situation arises, a regular RemoveAllItems call transfers only non-equipped items. This is the current behavior of our scripts. While experimenting to create a fix, I subsequently found that a repeated invocation ensures a transfer of all remaining items. Or at least it is seemingly successful in the limited instances tested thus far. What I am using as a preliminary solution is a "Third Time is The Charm" (aka "Third Time's Charm") rule-of-thumb: three (3) successive invocations of RemoveAllItems forces a complete transfer. Note though that two might in fact suffice. A bit more testing is needed to confirm the proposed workaround / "fix". EDIT: A pair of calls (one following the other) ensures a transfer of all items, and has no adverse side effects.

@OREOwnd Try these instructions for a basic install: http://forums.nexusmods.com/index.php?/topic/251916-4gb-fallout-new-vegas/page-138&do=findComment&comment=9732361 You can still have problems, even with a correct setup, as a result of an antivirus program preventing the FNV4GB launcher from working correctly. Couple of other things can interfere as well.

@ Luthienanarion The game appears to be more dynamic and resilient than you suggest. I use MMUE as well as WMX. Removing MMUE and its compatibility patches from my load order, thereby forcing WMX several steps higher (i.e. causing it to have a different load index), does not create issues with my existing saves. Weapons and attachments continue to work correctly even though their load order index changes. The steps that I suggested to Chypsyan have been known to resolve issues bearing the symptoms he described, regardless of the mod at fault or the particular type of item; albeit at the risk of the culprit(s) having to be discarded. Although admittedly it sidesteps the underlying issue, rather than properly remedies. <shrug> Perhaps the idea won't have merit; seemed worth mentioning in case it might.

There is a Mod called "Zan AutoPurge Crash Protector" which can help reduce out-of-memory crashes by periodically purging unneeded data from memory while playing. That, plus the 4 GB launcher that I mentioned in my earlier post, can help a great deal. Here is a link: www.nexusmods.com/newvegas/mods/49319/?

@RepublicDave Out of Memory errors usually occur for the following reason ... Fallout New Vegas is a 32-bit program. That means there is only 2 GB of virtual memory for the game to use by default. Your actual amount of physical RAM does not matter. So if you load up large textures and / or lots of mods, you will probably experience the game running out of memory. Crashes are particularly likely when transitioning into or out of an area that requires a complete unload / load of location data; that includes use of fast travel via the map. The game's available memory can be increased to 4 GB by using a special launcher. In many cases that may eliminate out-of-memory crashes, or at least greatly reduce their occurrence. Note that 4 GB is the maximum possible memory that a 32-bit program can reference (not enough bits for more than that), so it can not be increased beyond 4 GB. And, again, it is independent of actual physical system RAM. Care must still be taken to not overload the game with too much Mod data, even when using 4 GB. Here is a link to one of the downloads that enable 4 GB access: www.nexusmods.com/newvegas/mods/55061/?

@Chypsyan Just a thought. Might or might not help. With MMUE still enabled, dump *all* of your gear into a container. That includes everything in your inventory and everything that you have equipped. Save the game at that point. Exit the game and disable MMUE. Restart the game and load that saved game. Grab your stuff from that container, and see if you can continue from there. If the game crashes while taking everything at once, then reload that save and try taking the items one-by-one and note which item(s) cause a crash and then don't take them next time. If you crash when opening the container without taking anything, then start over with MMUE activated again. Drop everything on the ground instead of inside a container, save the game, exit and disable MMUE, reload, and then by trial-and-error determine which items you can safely pick up and leave the others alone. EDIT: remove weapon attachments from weapons before beginning.