Asterra

Most of the time, this seems to be a slightly brownish gray. You can see it through holes/cracks in the wall in some cells, like shacks or McCarran. I'm not referring to the cases where flat meshes have been pasted on the outside of the walls. I mean holes that stare out into featureless, mesh-free space. It's almost certainly not: Image Spaces, Lighting Templates, or the cell's own settings. Changing anything in any of these produces zero effect. Always wondered about this.

I know about that resource and saw that function. There was nothing to indicate that it would serve the dual purpose of indicating whether or not the target was a pile, as opposed to a normal corpse, and it's still not clear how that would be done. After all, I'm starting with the NPC's ref, so all the function would hypothetically return is the same thing I started with.

Yeah. Just looking for a way of figuring this out. I doubt there really isn't a way of doing this already.

I've been taking it for granted that these things were working the way their names imply. But it turns out that a frame or two of "GameMode" can commence even before a game has finished loading, followed by a long span of "menumode" as the game finishes loading. HasLoaded3D does not seem usable in figuring this out, as it's happy to report that the player has loaded 3D, long before the whole cell has loaded and the player is given control. And as I've already noted, simply watching for "GameMode" is not terribly useful since the game seems happy to allow some GameMode during non-GameMode moments.

I'm not really necessarily looking for what the title suggests. Here's my predicament: The mod The Strip Open, a pretty old mod, converts The Strip from two halves into a single unit. Unlike some unfortunate people, I never had any technical issues using the mod. But it had a quirk: it would not make assets visible if they were in "lod" territory. Meaning that anything past a certain point in the distance was simply not shown, leaving a void. At the time, I figured it was just a limitation of the game engine, or a consequence of there being no lod assets for The Strip's interior. But subsequent to this, I finally took the plunge and started using Freeside Open, which, once again, I have had zero issues with. Freeside Open is an even larger world than The Strip Open, yet it dutifully shows everything in the far distance, albeit typically only loading stuff when the camera points in that direction. Basically this means the problem I'm having with The Strip Open has the potential of being corrected. Sadly, I don't know what I might need to do to get it to work. I need the game to render stuff in the distance, the same way it does in Freeside Open. Meanwhile, what I see at the far end of The Strip is open, featureless desert, and that sucks.

StopVATSCam functions in this manner: When it's called, it will wait for the next attack in the queue, and then immediately end VATS cam. So fast, in fact, that the attack it was waiting on actually occurs outside of VATS cam. I have doubts that this behavior is what they were shooting for when they made the function. Changes to AP/ammo/whatever are ignored by VATS playback. If you remove all of the player's ammo, it'll just stay at 0 and fire anyway. If you remove all of their AP, it'll just overdraw into the negative. Anyway, I think I got the problem sorted out, or at least have a solution in progress, thanks to TrueCourierSix.

Before anyone says anything: I am aware of StopVATSCam. That's not what I'm after. What I need is a way to end VATS as if the last shot fired was actually the last shot that was intended to fire. What that means is that rather than ending instantly (as with StopVATSCam), there's a good couple of seconds of dramatic pause. Here's the deal. If you line up several shots in VATS, let them rip, but then open the console mid-playback and type: player.evp, guess what happens? Exactly what I'm trying to get to happen: VATS ends then and there, but it still does the dramatic pause, just as though the last shot fired had always been planned to be the last. But try this in a script? It ignores it, and continues to play the rest of the VATS playback. I need a way to achieve in a script what I'm able to do with the console. For the record, I've tried forcing VATS to end elegantly in other ways, such as killing the player's action points and removing their ammo. The game flat out ignores these irrelevancies and proceeds to play the entire VATS playback, unless I do it via the console........

On the surface, the behavior NPCs adopt around a player who is in danger (they scream and run for the hills, no matter how brave they are) seems non-defeatable. At least, not without, say, a script that perpetually changes their action, or something along those lines. Hoping I'm very wrong. I am looking to prevent both the running and the yelling. ("Whoa!")

Interesting. I hadn't really been aware that gambling in general had CTD issues. I've played a thousand hands of blackjack without a single problem. Never had issues with slots. Only roulette. And roulette is about a 50% guarantee of CTD for each spin of the wheel—a figure so awful that nobody could possibly shrug it off as "sometimes buggy." NVAC doesn't seem to have an impact on this. Though I'd be tempted to wager that running the game in Windows 10 is a factor. Weird new crashes are simply a thing when it comes to this game and Win10.

The phenomenon: Interacting with the roulette wheel puts the game in a state where a CTD is likely-to-inevitable. Typically, upon exiting the wheel, doing almost anything—interacting with something, opening the Pip-Boy, hitting start to open the save/load menu—causes the game to either freeze or CTD. Less typically, proceeding with the game will soon cause 3d assets to vanish, and the framerate to descend below 1fps. Worse, the instability instigated by whatever is wrong is something which affects any save file made after using the roulette wheel. As attested by these earlier victims: 1, 2, 3. I concur with the first individual linked: This happens to me on a completely vanilla, fresh installation of FNV. Not even using ENB. Not even using a mod organizer. All I can do is narrow down the circumstances: Merely opening up the roulette table: No crash. Opening the table and moving the cursor around: No crash. Opening the table and placing a chip down: No crash. Opening the table and moving the cursor and placing chips: Crash imminent. Opening the table and spinning the wheel: Crash imminent. I fully acknowledge that this is some kind of rare circumstance, and that there's absolutely no reason why the same exact game files which cause no issues on most people's installations should consistently cause a handful of people problems, especially across 3+ completely different PCs. I thought about bringing this topic up during my last playthrough, but reasoned that I only ever use the roulette wheel as the final gamble (to hit the 1-in-35 jackpot), and it's just far less effort to spin the wheel, restart the game if I lose, and cross my fingers if I win. This time, I really think I want a solution to this instead.

I've never really fully understood the hidden minutiae of the dialogue system. But this one is pretty baffling. The simple act of duplicating, say, Veronica's "GOODBYE" topic (151A06) will cause said topic to stop appearing. No more "Goodbye." as an option. All I'm doing is copying that form into a separate .esp. I'm not changing a thing. But that is, somehow, plenty excuse for the game to ignore the existence of that topic. This doesn't feel like something that is open to intuition. Going to have to have somebody carefully explain why this is breaking things.

Not sure why nobody spotted this yet. https://geckwiki.com/index.php?title=SetActorVoiceType I used it myself in my last comprehensive mod. GeckWiki is really the place you should be going to determine whether what you need exists. As far as I've experienced, the only thing they don't list that does exist (and they have a link for it) is IsRefInList. The rest is all there in their list of functions.

The difficulty is in knowing where to check. If a mod moves your stuff, it moves it to... probably some container it's arranged for itself. You have no way of knowing which mod, let alone which container. I have a big list of function requests on the JohnnyGuitar forum. They've been inactive for months, so it's not going to happen. The JIP guys have been ignoring requests since long before that. What would be needed here is a sort of "GetEverySingleItemRef" for a given base object. Should be possible. Parse the game/save data for all item ref records of where some custom mod weapon is being stored in-game, and present it as an array. Can pull containers from that data if need be. Honestly I'm kind of amazed this hadn't already been done. I mean, obviously, mods are going to mess with the player's inventory in ways that other mods need to be able to monitor, yet right now we have nothing.

Now's your chance. I'm asking a question that's comparatively non-esoteric. I just don't know if there's a function for accomplishing this. Say some mod has a sequence where it moves your gear to a holding container for safekeeping. And you want to know where it's been moved. RemoveAllItems does not trigger OnDrop, contrary to what OnDrop's article suggests. It does trigger OnActorUnequip, however. Unfortunately, the latter does not return item refs—only the base objects. Which kinda makes it rather less useful than it should be. I honestly don't know how I might go about this. RemoveAllItems also destroys the original item ref, so I can't even do any preemptive work to solve this. Edit: So while I'm at it, how about when a mod adds stuff back to the player? RemoveAllItems -> player doesn't trigger anything at all. Certainly not OnAdd.

OT, but that sounds like a very legacy feature that's ripe for a tweak.