The new update is a mixed bag for me. Many things are better, they did more than they said. But there seem to be big problems with memory management... a loop somewhere. That or scripting problems. I'm thinking it might be CPU-related, but not in the way people have been discussing. I've seen similar things playing with bethesda mods and their atrocious scripting system. What I'm observing is that if you have a long enough session, or trigger the wrong things in conjunction, your frame rates will drop and hold steady at an unusually low point. What you see isn't this janky stutter, but more like capping frame rates below 50fps. Just this constant jitter, or maybe 'grit' to the motion.
That's happening more now. And the only fix is to save and restart the game. I lose and gain back 30-40fps that way. So somewhere in there is a memory and/or script-related bottleneck.
For all of the complaints about memory issues, I think it might actually be a scripting problem. Interestingly enough, the most common bug for me is hanging GUI elements. Hover over an item in the worldspace and get its info blip plastered in place on the screen. Mantis crosshairs getting stuck on screen in safe areas. Steps in dialog/animation sequences not tripping. Music loops that get stuck indefinitely. V's "cybersick" effect hanging around forever. None of this being persistent with saves. You can save and reload while it's happening - it will go away. Which makes me think...
This is the kind of stuff I expect with dirty scripts. I've had stuff like this happen tossing stuff together in FO4 just enough to see how it works out, before I go in and put a bow on it. I've also found mods that missed stuff and caused massive dips to shockingly steady frametimes in certain areas, as though they're being capped. That's because all of the stuff happening with scripting has to go before another frame can get tossed. The CPU is waiting for them to either resolve or time out before even telling the GPU what to draw.
Betting that's the case here, too, at least for what I am seeing. Stringing the GUI stuff together in order to test the features that the various elements are meant to call and trigger. It would also explain why a lot of the calulations meant to be shown in the menu are either wrong or absent, and why certain elements don't trigger with the rest, as well as why it sometimes 'hangs' briefly on producing entire layers of the GUI. In other words, the GUI and menu likely were not finished. I doubt their engine is so bad that it has actual memory conflicts that could be capable of causing this. Even Bethesda manages to avoid that. If so, it would always be like that.
It seems like the GUI was mostly finalized and the code is mostly there, but it never got those final cleanup passes. This alone can actually lag your whole game, as various things happening in the world are also controlled by that same system. Pop into the menu, but something doesn't close/resolve or there's a conflict? Bye bye frames, until that script is halted. And it won't unless you shut the game down. Maybe it doesn't happen all at once, but stacks up as you enter and leave the menu more. Just piling up instances that go nowhere. Eventually it hits that tipping point where things have to queue across separate passes and it all goes to shit. Up until then, it's fine.
Can also happen with the BDs, which are obviously full of scripted effects and a total GUI swap (crossing parameters for separate, non-concurrent GUI elements seems like a no-no but looks to be involved.) Take those away, you've got a normal game environment in freecam underneath. If things related to the GUI, or any triggered effects are looping alongside of worldspace and actor scripts, it's hogging whatever compute and memory resources are supposed to be there only for those things... things like light sources, pathfinding, general actor behavior, triggered animations, inventory maintenance, status effects... really so many things. If it's well optimized, it is saving as much as possible for everything else, to ensure better framerates. They're heavy at times, but not the heaviest part of making a game run. So only what is really needed gets dedicated. And yet, due to being early in the chain of things happening, sometimes dirt in the wrong parts of just one script can even lead to conflicts that break everything, and then you CTD.
It's easy to take this for a memory management problem. But in reality, that could be working as intended and you could still have lag among other issues like this. Part of the memory management system deals in allocating oomph and space for scripts to run code and move information. The scripts themselves are upper-level code. In many modern games, the allocation is dynamic and able to be altered by whatever factors it tracks as well as manual overrides in the code, but at any given time there is a maximum amount of resources it will allow all of the scripts running to utilize, usually predetermined based on a set of expectations hard-coded in further down. If it goes over what that system is built to accommodate, they have to start queuing. And these loads are often linear... especially GUI scripts, but also NPC behavior. It's mostly a lot of polling. Even lighting and stuff to do with render distance, weather too... lots of stuff is running constant little checks to plot its next move. So if you have checks and loops not meant to be there piling up, they start forcing other things within the bones of the game to wait, and the result is a soft framerate cap. That is the common culprit... checks that don't get shut off when they should. Waiting by the phone all night long.
So say you load a BD. That's a whole new set of parameters and checks. New data pools that need to be monitored and altered accordingly as things transpire. When nothing happens, they still continue to check for input. Whether they're doing anything or not tends not to influence how many resources they use. If they don't get input, they simply wait for their next pass to check again. What do you suppose happens if you manage to cut the input without first letting those scripts check for a 'stop' parameter and then immediately start running other scripts? They'll just keep on checking, statically eating up resources. If you're smart, there won't be conflicts with the scripts that run after those are left behind and nothing will crash. But because that polling is still happening, you're using more power than the code regulating the allocation is expecting to see. There is effectively less to go around that the game thinks there is. And you essentially have a bum script masquerading as a deeper memory issue. Sometimes, you can make it so these things clean themselves up, but you sort of have to plan for every situation where it can happen to make it reliable.
Of course, I'm not a coder. I've modded just enough to never want to work in a game studio. So I'm just basing this on limited experience modding a much more dated system. But I'm betting this is just as much an obstacle for TW3 modders. And maybe even more of an issue in this game, due to the settings and all of the various things happening. It's a whole lot more heavy duty. The community will have their work cut out for them when it comes to more elaborate mods.
That might take some time to comb through and fix, but compared to other causes, it would be a good thing. As bad and totally broken as it looks in game, it is basically guaranteed to be fixed. The save bug would've been harder and they did fix that. This isn't problem-solving, just routine work that takes nothing but the time and effort needed to iron out. Like sanding a freshly cut piece of wood for a tabletop. Just gotta stand there and do it. Modders might even be able to fix it.
