MildlyFootwear

How so? Is the game hanging without displaying the main menu? Not able to start a new game? Crashing after starting a game or loading a save?

Yeah, modifying them in memory isn't really possible. With "[x]StringToFile" the ENB would have to reload it. As for script delays and quests, hidden "quests" are how a substantial amount of scripted mods work. Stuff like Project Nevada, B42 Quickthrow, and even MCM menus use hidden "quests". The delays are just a number you set on the quest menu.

So I'm going to start off by saying a lot of you want is possible, but it's complicated. I'm going to get into some details, but I'm not going to go super indepth. Here is a link to all/most of the functions available in the GECK, with NVSE, with JIP LN NVSE: https://geckwiki.com/index.php/Complete_List_of_Function_in_Fallout_New_Vegas You can parse through it pretty easily by searching for keywords ("Get", "Set", "Cell", "Worldspace", etc), but can take a bit to look for what you want in specific. 1) Yes. It's not simple. You'll have to use the commands ReadStringFromFile, sv_find, WriteStringToFile, let, and a bit of ingenuity. 2) Yes. GetParentCell, GetParentWorldspace, GetCellCoords, etc. It's complicated and would take a bit of work for what you want in specific, but it is possible. 3) The ingame time? Year, month, day, hour, etc are all global variables and can be accessed with scripts (I'd advise against modifying them, however). 4) Rain is a specific "weather", as far as I know. This area isn't really in my ballpark, but a lot of information for weathers can be set and retrieved with scripts. 5) Now we are completely out of my ballpark. It might be possible, but I'm not certain. In any case, it is possible if you are willing and able to write a NVSE "extension"/dll file, but that is far more complicated than anything you can do with scripts and requires C++ experience, if I'm not mistaken. 6) Most scripts you'll write are related to setting a delay in one manor or another. Every "quest" in the game processes this way, and "passive" scripts will be atleast vaguely related to quests as quests are how the game executes them in the first place. The only scripts that aren't explicitly tied to a delay are object scripts, "trigger area" scripts, and some others. If we want to be technical, event handlers aren't explicitly tied to delays, but they tend to be set with quest scripts, so are atleast vaguely related to it. If you want to look up scripts from Nevada Skies, FNVEdit is a good place to start as it allows you to view everything contained by any plugin in categories and lets you view the source for a script.

New Vegas Tick Fix is the closest we've got. NVSR is great, but it only gives a ~5% performance boost and much better mininums. On modern hardware it's not the most noticeable thing anymore (in my experience).

There are a couple more things I'll throw out there for ya. If you are using NVSR on Windows 10, that will consistently cause crashing every 15-30 minutes. This is something that trips up a lot of new/long-term-break modders. Use FPGE (https://www.nexusmods.com/newvegas/mods/66726) instead of CAGE. CAGE is very outdated and doesn't include any post-game content (i.e. the world won't be updated to reflect endings). This is very much personal preference, but I don't think AWOP is worth the performance/stability hit. If it is to you then feel free to keep it, but if you don't feel strongly about it I would think about dropping it.

I didn't note that those benchmarks all used the same route (Freeside Open East Gate to Strip Gate). I didn't control for time of day, but that's partly why I did the "after restart" benchmarks too. Something important to note that I forgot to, was that in both cases the game hanged for approximately 7 seconds when opening the pause menu (after playing for 3 hours). If there was a large impact solely from texture packs I imagine that would've varied more, but that is just speculation.

Chiming in with a couple extra benchmarks (largely done because of convenience): Baseline with NMC Large after 3 hours of gameplay: 11-05-2019, 13:49:51 FalloutNV.exe benchmark completed, 2665 frames rendered in 60.407 s Average framerate : 44.1 FPS Minimum framerate : 23.1 FPS Maximum framerate : 53.7 FPS 1% low framerate : 17.6 FPS 0.1% low framerate : 11.1 FPS Baseline with NMC Large after saving and restarting the game (after previous benchmark): 11-05-2019, 14:01:15 FalloutNV.exe benchmark completed, 3056 frames rendered in 61.188 s Average framerate : 49.9 FPS Minimum framerate : 17.1 FPS Maximum framerate : 65.8 FPS 1% low framerate : 14.2 FPS 0.1% low framerate : 5.8 FPS Baseline with NMC Small after 3 hours of gameplay: 11-05-2019, 17:09:36 FalloutNV.exe benchmark completed, 2128 frames rendered in 57.859 s Average framerate : 36.7 FPS Minimum framerate : 14.4 FPS Maximum framerate : 53.4 FPS 1% low framerate : 10.9 FPS 0.1% low framerate : 3.5 FPS Baseline with NMC Small after saving and restarting the game (after previous benchmark): 11-05-2019, 17:41:24 FalloutNV.exe benchmark completed, 2713 frames rendered in 58.797 s Average framerate : 46.1 FPS Minimum framerate : 16.3 FPS Maximum framerate : 58.1 FPS 1% low framerate : 14.9 FPS 0.1% low framerate : 10.2 FPS It's no where near controlled enough to say for certain, but with the lack of comparable benchmarks that I can find, I'm inclined to believe that the discrepancy others have seen is more due to the game not properly purging irrelevant data than the fault of any texture pack (or RAM limits being "just right" to cause it).

"The more it impacts performance" means average framerates or lows that lasted more than a second in my mind (stutters too, but that's difficult to properly test considering the 1/0.1% lows being locked to just those percentages and there not being much of a way to prevent load screens from factoring into benchmarks). With the lows that shows still being the same, I think that under typical circumstances it won't influence it heavily. If I knew of a better place to benchmark it I would. I suppose The Strip Open would be a good place to start, even though it's... not very representative of "average gameplay being taken down to 60FPS by load".

While that's logical, it's also not strictly true. I've added 4 new benchmark situations reflecting it. Excerpt: Baseline: 08-05-2019, 19:09:51 FalloutNV.exe benchmark completed, 3681 frames rendered in 57.016 s Average framerate : 64.5 FPS Minimum framerate : 23.6 FPS Maximum framerate : 82.9 FPS 1% low framerate : 17.5 FPS 0.1% low framerate : 9.7 FPS 08-05-2019, 19:12:29 FalloutNV.exe benchmark completed, 3756 frames rendered in 56.984 s Average framerate : 65.9 FPS Minimum framerate : 27.7 FPS Maximum framerate : 83.8 FPS 1% low framerate : 21.0 FPS 0.1% low framerate : 11.5 FPS Baseline w/o NMC Large: 08-05-2019, 19:14:45 FalloutNV.exe benchmark completed, 3754 frames rendered in 57.750 s Average framerate : 65.0 FPS Minimum framerate : 29.6 FPS Maximum framerate : 83.5 FPS 1% low framerate : 28.7 FPS 0.1% low framerate : 16.0 FPS 08-05-2019, 19:16:48 FalloutNV.exe benchmark completed, 3810 frames rendered in 57.187 s Average framerate : 66.6 FPS Minimum framerate : 28.8 FPS Maximum framerate : 85.6 FPS 1% low framerate : 25.7 FPS 0.1% low framerate : 17.4 FPS Baseline w/ ENBoost: 08-05-2019, 19:29:04 FalloutNV.exe benchmark completed, 3768 frames rendered in 58.531 s Average framerate : 64.3 FPS Minimum framerate : 27.9 FPS Maximum framerate : 81.9 FPS 1% low framerate : 27.0 FPS 0.1% low framerate : 17.0 FPS 08-05-2019, 19:33:21 FalloutNV.exe benchmark completed, 3662 frames rendered in 56.750 s Average framerate : 64.5 FPS Minimum framerate : 30.4 FPS Maximum framerate : 81.9 FPS 1% low framerate : 26.8 FPS 0.1% low framerate : 14.3 FPS Baseline w/ ENBoost w/o NMC Large: 08-05-2019, 19:36:01 FalloutNV.exe benchmark completed, 3692 frames rendered in 57.250 s Average framerate : 64.4 FPS Minimum framerate : 30.4 FPS Maximum framerate : 82.9 FPS 1% low framerate : 29.2 FPS 0.1% low framerate : 14.5 FPS 08-05-2019, 19:37:55 FalloutNV.exe benchmark completed, 3725 frames rendered in 57.516 s Average framerate : 64.7 FPS Minimum framerate : 27.6 FPS Maximum framerate : 83.8 FPS 1% low framerate : 27.4 FPS 0.1% low framerate : 13.3 FPS I am curious as to the reasons why, though. I will admit it's not something I thought about. I'm going to hazard a guess it is related to New Vegas only slamming 1 thread regardless of configuration (atleast on a modern processor), like ENBoost not relying on that "main thread".

"Unless you hit your VRAM/RAM limit" is the important thing. Between ENBoost and 4GB patch I don't think anyone will be hitting that during normal sessions.

You can view the raw benchmarks here: https://docs.google.com/document/d/1ivERHUX35O0shJlyV377p3xaNUk1yRhUhoG_bcmhxNo/edit?usp=sharing This isn't really a guide, but I'll go over my notable results and make a lists of the no/low/high impact mods I tested. Important Notes: 1) Messing with priorities or limiting the game to X threads does nothing but hinder performance. 2) Texture packs shouldn't impact anything other than load times unless you break your VRAM/RAM limit. 3) Windows 7 by itself was a 4FPS gain for me, with NVSR being another 2FPS or so (and substantially reducing lows). This isn't very surprising to those who know of those spectre/meltdown exploits, but if you absolutely must have the best performance the only thing I'll suggest is make sure your BIOS is set to legacy or UEFI with CSM if you have a modern computer/motherboard, otherwise you won't be able to install Windows 7. 4) Shadowplay, Firefox, etc don't impact framerate substantially. YouTube, however, even with v-sync forced off would result in the game attempting to sync to 30/60. I'm unsure if this is a driver bug or a YouTube bug, but it is likely one of the two. 5) Even with the appropriate INI tweaks, New Vegas will only slam one core, though you can expect up to 3 others reaching 50% utilization (though not all at once). If you want "max performance", disabling all but 4 cores then overclocking those as far as you can isn't the worst idea, though if you don't already know how to overclock I can't say I'd recommend it. This isn't shown in the benchmarks (for the most part) but was shown by MSI Afterburner while I was doing them. Now, for the mods; Notes: 1) Any quest mods listed were sitting at the "haven't started" stage. Quest mods will occasionally impact performance differently depending on what stage you are on. 2) Some of these will be redundant if you are familiar with modding, but I'm choosing to include them anyways. 3) Pretty much all of these tests were performed with New Vegas Uncut - Freeside Open, as it is the only natural, reliable way to get the game to drop below 70FPS on my computer other than using The Strip Open. No Measurable Impact during non-combat gameplay: NMC Large Realistic Wasteland Lighting Yukichigai's Unofficial Patch JSawyer Ultimate EVE/EXE/Impact - CE B42 Quickthrow Enhanced Item Info Spice of Life Inventory Search Universal Item Sorter Sticky Ragdoll Camera Mojave Arsenal Mojave Raiders Mojave Wildlife JIP Companion Command and Control JIP Improved Recipe Menu All Weapon Sounds Overhaul + Scripted Patch One HUD Immersive Minigames The Weapon Mod Menu Roberts NV exeter's Type3 Base Game + DLCs Autumn Leaves DEIMOS New Vegas Bounties I Russell FOV Slider Securitrons in CRT Low Impact - these mods can be expected to shave 1-2 FPS off each if you aren't consistently hitting 60. Wasteland Flora Overhaul CASM - will shave 2FPS off whenever the player is moving. The Living Desert The North Road Remastered The Initiation + Eliza New Vegas Bounties II FNVLODGen + Resources + LOD additions and improvements + Much Needed LOD - shaves 2 FPS off a hundred, but that's a lost frame if you are under 60. High Impact - these mods can be expected to shave 2-6 FPS off each if you aren't consistently hitting 60. Qwinn's New Vegas Redesigned 3 - shaves 3-4FPS off of 65. NV Interiors - shaves 6FPS off the Freeside route - see document for more details.

These results are taken from a plugin I wrote today: https://www.nexusmods.com/newvegas/mods/66931 You can view the exact results here: https://drive.google.com/drive/folders/1ElqfIY4X95lZ3tUOyPOTI82Xo_BMiVWb I plan on updating this post as I test more scripts, but I'll cover the important stuff from what I've already tested: Set vs Let: 1. "set" is notably faster than "let". When using simple values or math (i.e. setting iTemp to 1 or 1*30/5), set is anywhere from 2-10x faster than let. 2. When using "GetName WeapNV9mmPistol", "set" is consistently one hundred and fifty times faster than "let". This is likely a quirk of how strings are handled by "let", as a similar discrepancy occurs when "sv_construct" is combined with let. If using "ToString"/$ or entering it as raw text (i.e. let String := "Test"), it performs correctly. 3. 5000 loops using "set iLoopTest to iLoopTest + 1" takes approximately 12ms to execute, with "let iLoopTest += 1" taking 22ms. 4. Despite these, it takes approximately 0.0020625ms to execute "let iTemp := 1" and 0.0001875ms to execute "set iTemp to 1". You should not be afraid of using "let", though you should avoid it when possible. "set" should be used unless you are in doubt, performing math that has a chance of silently failing (i.e. dividing by 0), assembling a complex or long string (strings with a length of over 50 generally can't be assembled or executed properly without "let"), or interacting with arrays, but it is not something significant (unless you are combining string variables with it). "while" loops "while" loops don't impact performance in a notable manor themselves. Executing "let sTemp := GetName WeapNV9mmPistol" 200 times with a "while" loop or by entering it 200 times takes approximately 20ms on my rig either way. This isn't really surprising, but I feel it's of note anyways as I personally use "while" loops to execute a significant amount of code somewhat often. Functions vs Integration "call" with a user defined function appears to take twice as long to execute compared to integrated code. This does appear to scale with the complexity of code, as a script that calculates the DPS of a fully modded weapon can take 300ms to execute 10000 times when integrated into a script but takes 600ms to execute the same amount of times when executed via function, with simple code being capable of under 100ms either way. SetFuctionValue appears to not affect the amount of time it takes substantially, as using "set to call UDF" with SetFunctionValue vs "call UDF" with the UDF setting a quest variable under the former circumstances (10000 executions of modded weapon DPS calc) would take approx 600ms to execute either way. "Let" continues to heavily impact execution time, with "let := call UDF" taking 2-3x as long as "set to call UDF". set xVariable to call function, let sTemp := xVariable vs let sTemp := (call function) Due to the already mentioned penalty to execution speed when a UDF is combined with let, "set sString to call function, let sTemp := sString+[text]" notably outperforms a similar execution with "let", with 5000 executions taking approximately 900ms for the former and 1400ms for the latter. Something similar but much more exaggerated also happens when constructing a string using multiple weapon DPS calculation UDF calls, with the fastest execution being "set iDPS to call function 0, set iDPSR to call function 1, set sTemp to sv_construct '%.4f, %.4f,' iDPS iDPSR" taking ~220ms to perform 5000 executions, and the slowest being "let sTemp to $call function 0+', '+$call function 1" taking 1400ms to perform 5000 executions. I'm not expecting terribly much out of this thread, but if others want to share optimization tips/experiences they would be most welcome.

Title is pretty self explanatory. Retyping the file name every time gets old quick, and I've had atleast one case where someone has assumed my mod doesn't work because I forgot to set the "Show Requirements" flag and they didn't read the description. The former is kind of on me, but still. I don't imagine this would be too hard to implement.

I've seen it mentioned frequently (and noticed it personally with Project Reality years ago), but the only things I know to cause it are non-destructed strings in function/object/effect scripts and spawned in objects/NPCs that aren't cleaned up with MarkForDelete. I've had a few quick searches on Google and in this subforum but I haven't really found anything else.

Are you sure about that? Quicksaves are technically recreated, then the last one gets automatically deleted i.e. they are not really being overwritten. If you quicksaved seconds ago, that save should appear on the top of your list. It might be because I'm playing New Vegas, but it works that way here.