Follow-up posting:
I've been looking a little more into what caused these issues on my end and i think i found the root of the cause.
I mentioned in earlier posts how, if PlanCo crashes upon loading a park,
or even crashes in the startup screen it might be due to the VRam size being set too low or the VRam being reserved by other data.
I mentioned, i recently encountered the following:
-frame rate drop
-switching between monitors stopped working (only, if game window is closed with windows key)
(move the mouse from the monitor running PlanCo over to a secondary monitor, i.e. to use the browser simultaneously)
-items/buildings vanish
-autosave is laggy and takes a long time to finish
First I went to check whether there might be shared .DLLs or .REGs,
or other configuration files that may be shared between PlanZoo and PlanCo,
though couldn't find anything obvious.
(i suspected so, because on the same day i experienced those issues an update was rolled out for PlanZoo)
It remains true there was a link between the update and the issues, but i will adress this below.
I fiddled a little with different VRam loads, sizes and hdd space (reason: limits the VRam size below settings/designated space)
On the day this happened my hard drives were running full, partly due to reserved VRam,
partly because of game updates in the queue (Steam reserves space for queued updates)
and cause i didn't purge my media files onto a secondary drive in a longer while.
My base RAM is 16GB
VRam is usually set to above 30GB
Issue 1/2: frame-rate drop / monitor switching(task switching via mouse-over on sec. monitor)
Combined issue
What happened here was, due to the little space available in the VRam, the graphics settings changed to 1920x1080 @30fps
I immediately noticed the 1080p (i usually run PlanCo on 4k res a 4k monitor),
but failed to see the frame rate was reset to 30fps in the settings.
I will assume the game does this when it can't run the game in the usual settings.
solution: after resetting it to 60fps, everything works like it did before, window-hopping works as per usual again.
-items/buildings vanish
i was eventually able to reproduce the issue.
It happens (only in few cases) when VRam is set higher than the actual available space and
only happens in a setup scenario where HDD space is running low
whilst VRam gives a wrong handshake (false information reported to the engine)
In this scenario I would assume the engine thinks it can hand off the data into
VRam but VRam can't store the data and discards it instead.
-autosave lag
and again, it looks like (aside from HDD speed) this is linked to VRam size and availability
Here's what i think, the game relies heavily on RAM to store the assets. And separately their inworld position, if spawned.
Whenever people experience extreme lag, or even crashes it's linked to the VRam. Either the HDD is too slow to handle all the
communication as quickly as needed, or the data priority in the VRam (the process of deleting temp data vs writing new data)
lags behind. In cases where VRam is too low, the game will simply crash upon loading into the desired park/scenario/sandbox savegame,
because it can't load all necessary assets to properly display the saved content.
Possible solution:
There probably isn't a solution to circumvent this other than to reserve enough VRam, HDD space (and)/or upgrade RAM to at least 32gb.
On the issue of the alleged communication fault between engine and VRam,
this might be fixable via an additional communication step between them.
Technically, on the user side this isse can be circumvented via the scenario editor and by filtering out unnecessary items
from the content list (best if done with a new park/sandbox project)
Hope this clears up some confusion on what i wrote earlier and on the loading issue that other users experience,
especially on lower-end hardware.
-----
@Paul_Crowther @AndyC1
