FiftyTifty

I already solved it, and it's not once a day. It's running each time a save is loaded or a new game is started. What is the solution??? I still cannot imagine anything would be more efficient than just doing a GetGameLoaded check in the GameMode of your quest script. I posted it. But I can somewhat elaborate. Here is the script attached to the quest, which only runs at the main menu. At no other point is it being processed in any way: scn AAAFyTyWeapReachQuestScript begin MenuMode 4 ;The quest script will only run at the main menu StopQuest AAAFyTyWeapReachQuest ;No need to have it run repeatedly in the main menu. Quest scripts are re-initialized every time we go to the main menu. if GetGameRestarted == 0 ;Safety check, just in case something is f*#@ed return endif SetGameMainLoopCallback AAAFyTyWeapReachQuestScriptUDFGameMode 1 1 1 ; 1 1 1 == Register the callback, run every frame, run only in GameMode end SetGameMainLoopCallback With my passed parameters, runs my UDF script in GameMode. And it will do so endlessly, unless my UDF script then unregisters the callback: scn AAAFyTyWeapReachQuestScriptUDFGameMode Begin Function {} Print "Test!" SetWeaponReach 0.4 WeapSwitchBlade SetGameMainLoopCallback AAAFyTyWeapReachQuestScriptUDFGameMode 0 ;Code that only needs to run once, has been run. So we stop the callback from being run again End Does that clear it up for you? Your approach runs your script every frame at all times in GameMode. This approach runs the script once, and once only, during GameMode. Same purpose. But better performance, and better practice.

I already solved it, and it's not once a day. It's running each time a save is loaded or a new game is started.

How would that work? That's only for MagicEffect scripts, according to the wiki. Whereas my script is attached to a quest. Yayaya. I've only met a couple people who know who the character is.

Figures. The tutorial was faulty then. The real way to do it, is as follows: scn AAAFyTyWeapReachQuestScript begin MenuMode 4 StopQuest AAAFyTyWeapReachQuest if GetGameRestarted == 0 return endif SetGameMainLoopCallback AAAFyTyWeapReachQuestScriptUDFGameMode 1 1 1 end scn AAAFyTyWeapReachQuestScriptUDFGameMode Begin Function {} Print "Test!" SetWeaponReach 0.4 WeapSwitchBlade SetGameMainLoopCallback AAAFyTyWeapReachQuestScriptUDFGameMode 0 End

I'm having a wee bit of trouble working my head around this. Don't understand why this wee setup doesn't work, after following this tutorial: https://eddoursul.win/menumode-4/ What I am wanting to do, is change the weapon reach of a bunch of weapons, by running a script once every time the game is loaded (i.e, GetGameLoade == 1). Purely as a learning exercise, really, but also a micro-optimization that I can apply to various mods. But for some reason, it just doesn't want to work. Below are my three scripts: scn AAAFyTyWeapReachQuestScript begin MenuMode 4 StopQuest AAAFyTyWeapReachQuest if GetGameRestarted == 0 return endif SetEventHandler "PostLoadGame" AAAFyTyWeapReachQuestScriptUDF SetEventHandler "NewGame" ({} => call AAAFyTyWeapReachQuestScriptUDF 1) end scn AAAFyTyWeapReachQuestScriptUDF int iArg begin function MyPostLoadGameHandler { iArg } CallAfterSeconds 0 AAAFyTyWeapReachQuestScriptUDFGameMode end scn AAAFyTyWeapReachQuestScriptUDFGameMode Begin Function {} SetWeaponReach 0.4 WeapSwitchBlade End Unfortunately, the function SetWeaponReach never gets called. When using GetWeaponReach WeapSwitchBlade in the console, it returns the default value of 1.0. Any idea why this might be?

Yeah you need to disable/enable it again. Also try Reset3DState, and Update3D

Uh, I doubt it's going to be a hardware issue. If it were, there'd be artifacting up the wazoo, rather than shaders swapping out. Have you tried disabling the Steam Overlay, and any other injectors (MSI Afterburner, FXAA injector via NVidia's driver, etc)? If you did the shaderpackage tweak, where you swap ShaderPackage19 with another, change it back.

Did you do that shaderpackage tweak? If so, undo it.

That's a worthless answer. @OP, Gonna need your specs and what you're running with. If you've got an ENB, they can impact the framerate quite heavily. My Vega 56 at 1440p would go down to the 30s with my preset, in intense scenes.

Already said why. Here's a simple video showing the performance deficit: https://www.youtube.com/watch?v=BORHnYLLgyY Ideally, you'd get a Ryzen 7 which has two full CCXs, or an APU which has one full CCX. The non-APU quad cores have 2+2 cores, and the hex cores have 3+3. New Vegas will use four or so, though heavily limited by the single-threaded driver. A Zen 2 CPU would be a good bump up, Zen 3 would be ideal but they're too expensive and not in stock.

You've got a cheapo CPU. Having such small CCX units is lowering performance by at least 20%, as there's a significant performance penalty when there's cross-CCX communication. Try using ProcessHacker to change the core that the driver thread is pinned to. See if that offers any performance gain.

You've got some cool stuff there. But I think I should be good, after that wee bout of testing. Now I've got to knuckle down and make a follower framework.

Hmm. So it seems that it's very spotty. I'll have a go at adding a follow package to a bunch of NPCs, then check if it persists, to get to the bottom of this. Edit: Good news, the packages added by AddScriptPackage are completely persistent. I tested two packages, one a Wander package, the other a Follow package. For each of them, I did the following: 1. Add to random NPCs 2. Save the game 3. Close Oblivion, then start it back up again 4. Load the save 5. Check if packages were still being run (they were) 6. Fast travelled 7. Check if packages were still being run (they were) Throughout all of that, the packages continued to run. They had the flags Must Complete and Continue if PC Near set to true.

I'm coming around to messing with Oblivion, and there's a rather big problem. There's no such thing as quest aliases, so we have to make do with adding packages directly, or using AddScriptPackage. Do packages added via AddScriptPackage get written to the save, so that an actor will continue the package when the game is restarted? Or does it have to be reapplied whenever the game is loaded?

It's not an issue of memory, but of draw calls. Ideally you shouldn't go over 3,000 draw calls or so. You can check how many are being issued in your cell by installing ENB and looking at the profiler section.

Remember, packages are sorted through from the top -> bottom. If there are no conditions on the first package, it will always be the package being run by the NPC. If there are conditions that don't pass, then it is skipped, and the 2nd package has it's conditions checked. So on and so forth.

Skyrim, and IIRC all Elder Scrolls & Fallout games, do not support compressed sound files. You could try using BSArch with its -share parameter.

IIRC, it doesn't set the flags properly. BSArch is what you should use.

A flag is an on/off setting. The archives for Bethesda's games have specific flags for the types of files contained in them. Don't use archive.exe, instead, use the BSArch tool made by Zilav. Sound files will not work in compressed BSA archives. So make your main archive uncompressed, and it's up to you if you make your texture archive compressed or not.

Texture archives only work without the embed file names flag, whereas the other archives typically require that flag. Don't risk game engine f*#@iness, keep 'em separated.

The reason that textures are packed into a separate archive, is that there's an engine bug with reading them. If the texture archive isn't compressed, the game will not read the archive, then it will crash as it failed to load it. You can actually decompress the texture archive (use the argument "-af:0x3" when packing it via BSArch), but you should still keep textures in their own archive. There are two types of compression. Lossless, and lossy. Archive compression is lossless, like FLAC is.

That's a great shout, I'll check it out. Thanks.

In a wee bit of a bind here. I need to convert a few textures to Skyrim SE's .dds format, but I can't find any of the .bat files I used back in the day to convert textures to SSE's formats. Where are these at?

There are files that need to be loaded inside an archive, otherwise it breaks game functionality. The .egt files are such examples. Performance between having BSAs and loose files is massive. Even on NVME SSDs. You can see this in benchmarks comparing single sequential reads/writes to 4k IOPS reads/writes. CrystalDiskMark is great for that. The ideal is to not extract files from the archives, but instead, use bsarch to create archives with no compression. That way, no CPU time is spent on decompressing the archives, but you get all the performance benefit of having large, singular files instead of hundreds of thousands of itty-bitty sized files.

The AI packages are sorted top-down. So the first package that has it's conditions pass, is the package that runs. For example: PackageWaitAroundMarker (No conditions) PackageMoveAfterWaiting (Get Global gWaitedAtMarker == 1) Even if gWaitedAtMarker is set to 1, that package will never run. The first one will always be used by the NPC, since it's the first to pass it's conditions (of which there are none, so it automatically passes).