Years ago i reportet this bug and its till there

[Stardustfire]

on a mostly complete different machine btw (new CPU, MB, Memory, OS, Bootstorage...)
a very few minutes after loading a game the game starts a massive HDD action, causing the game to freeze for around 10-20 sec. i mean hey i have one otehr game where i got that long ago, and that was when i played FO4 in 4k when the game was on a mechanical HDD. you cant tell me this game needs to shovel the same mass of texture data, especialy bnecause it happens not directly after a jump into a new systrem but mostly midaction.
my old CPU was already big enove to handle anything, and you cant tell me that my new one (9800x3d with 64gb memory) lacks the power for this game and needs a gigantic dumpfile for buffering on my data hdd....
and it only ever happenms after loading a game, and like already mentioned i already reported it literal years ago. so that measn it gone several game versions unfixed...

[Nordil(Hun)]

What type of HDD you have? Because actually its Read/write speed is the most important in this regard.
Even if you have a lot of memory, good raw CPU power, the HDD can cause a bottleneck if it has abysmally bad read(and write) speed.
Fragmentation also can cause some slight issues, but usually not such dire ones. (Unless there is something seriously wrong with the HDD)
What part of the game do you keep on the HDD, do you even keep anything regarding to the game/system on the HDD?

[Stardustfire]

you total miss the point i pointed out big and fat above. it happens when all the data loading is already done and there shoudend be anything left that coud even cause this data shovel havoc.

load saved game
play 3 - 5 minutes
data shovel massacre that even cause the game to freeze for several seconds...

so all data shoud have long ago be pressed into the memory and it only happens after loading a saved game, not when starting a new one.
and the read (or even write) intensity is like i also already sayed like FO4 trying to load all Textures for a new cell in 4k (so we talk truckloads of data here, compareable to DL one of this Bloated AAA Titles in Steam, and evn than the HDD isnt so stressed like it is in the actual situation) , or the game somehow trys to make a gigantic dumbfile (what woudend be needed with that hardware)

[Nordil(Hun)]

Originally posted by Stardustfire:

you total miss the point i pointed out big and fat above. it happens when all the data loading is already done and there shoudend be anything left that coud even cause this data shovel havoc.

load saved game
play 3 - 5 minutes
data shovel massacre that even cause the game to freeze for several seconds...

so all data shoud have long ago be pressed into the memory and it only happens after loading a saved game, not when starting a new one.
and the read (or even write) intensity is like i also already sayed like FO4 trying to load all Textures for a new cell in 4k (so we talk truckloads of data here, compareable to DL one of this Bloated AAA Titles in Steam, and evn than the HDD isnt so stressed like it is in the actual situation) , or the game somehow trys to make a gigantic dumbfile (what woudend be needed with that hardware)

The other examples mean nothing to me as i do not know what they are:S So i cannot even figure out if there any common things among them.

However there can be various issues why it happens with SH.
But without a proper analysis it is damn hard to reproduce and thus figure out the issue. I absolutely cannot for instance replicate it since i run the game from an SSD, i dont play in 4K. And i also never encounter anything similar you mention.
Btw i am guessing you notice it is a hard drive issue because you are monitoring its utilization?

[Death Approaches]

dude none of us get that, it's just something with your setup. drivers, probably. java is about as widely tested as any server software in the world is. and the libraries this game is based off of are years, decades old, they'd have found whatever's wrong long long ago.

What GPU? are you using the iGPU on the processor or an AMD dGPU? if so, it's probably the AMD. lots of AMD drivers are very screwed up with OpenGL. some cannot even run on top-end 2026 models, they have to downgrade drivers over and over to find the right old one that provides good OGL support, then upgrade back up again. (apparently once it's fixed it stays fixed.)

check out the AMD related posts in the support section. it's extremely widespread. that's where I would start. there's no other reason. it should be instantaneous. it's a java game starts with 2GB and can take up to 4GB from the JRE, and only does OpenGL3 graphics. it should run like lightning on your toaster or a 2007 original iPhone 1. (ok that might be a bit too far, iP1 had 128M of RAM, but you get the point.)

[Stardustfire]

What GPU? are you using the iGPU on the processor or an AMD dGPU? if so, it's probably the AMD

remember THIS

on a mostly complete different machine btw (new CPU, MB, Memory, OS, Bootstorage...)

right at the start of my post?
i work as a PC Hardware Technican and have a (outdated) MCSE Qualification, and i build my Rig myself, so on that coast in form of Hardware compatibility and configuration you can give me alot of slag.
i dont sayed it explicitly, but i got enove money to have dedicated GraCas in the old and new rig (yep also different in both)

[Death Approaches]

great, hello fellow certification-collecting slave! remember when we were gods? now we're lucky to make 100k as less-glorified car mechanics. I HATE CHANGE. (when it negatively affects my career, anyway.)

but you know you didn't say you were on a dGPU or iGPU and left it to assumption... just omission of data doesn't count as "saying it"

if using the proc's iGPU baby which hey, it's fine, again it's OpenGL not some DX12 thing expecting a NV 70 series and 8GB minimum VRAM...

well it doesn't matter, then you are well aware of the AMD OpenGL issue if you're a capable systems builder. but please, please check that out and verify, don't just click update and take the most current, cause it. does. not. work. that. way.

there's no other reason for it. I'm sure you ran burn-in tests when you first built it, then the 2nd thing you did was install a couple benchmark suites to see how much better it was than you old rig. cause I would too!

what else could it be, then? what has the ability to hold up a burst transfer from the drive controller? nothing. we live in an era of hardware abstraction. nothing but drivers can talk to hardware directly.

you should load up on a 3rd/4th gen SSD in about 1.0 seconds, and that's fully parsed, ready to play... even a in a 1000, 2000 DAY old save with tons of visited systems at the far end of the galaxy about to transition to the next, even then saves are like ~50MB, nothing, nothing at all to a drive that measures reads/sec in Gigs, not Megs.

no idea if AMDs expecting to deprecate it, the way Intel threw away DX9 support and relies on MS's D3D9On12, I think OGL will be here at least 2, 3 decades. cause it's OpenGL. :-) but whoever is on OpenGL driver duty at AMD for ~2022-current era has been taking a lot of days off, I think.

[Death Approaches]

could it be you don't have it pre-allocating the faked VRAM with RAM in BIOS, and you're letting the runtime allocate? that might cause a slight delay, certainly not minutes, even if RAM was full and it had to pageswap out some stuff to steal the RAM to use for the iGPU.

I'm running out of suspect here. maybe attach a debugger to the process and see exactly what's hanging it up, by thread / process?

[Stardustfire]

it was a 1070TI SLI in the old system and a single 5070 ti in the new one. the old system was fueled with a 5820k, the new like stated a 9800x3d. the game itself is on a 3TB mechanical datagrave (Toshiba HDWE140) , my swapfile (while i doubt it ever get used, only parked it there so win11 dont get funny ideas and write my boot 9100 to death because of a fluke) is on a mechanical 1/2 tb black WD. the read/write i get when the "performace dunk" happens after each session load comes from the data grave (the HDDs have hearable differences when working)