There are multiple factors at play here. First the game engine is indeed messy, with all these external events eating time from the main loop (that's the main game thread that "does everything"). Most if not all of the code of CE is synchronous, which was not really an issue for the LAN-party context it was made for, but of course becomes quickly overwhelmed by an online context with many actors. Physics engine being a prime offender here.
the Anthem of Creation didn't take off either.
Atm yes it does. If you hear explosion, you have players in your radius. Players = assets to load = SC struggle to add the assets to your low memory = low fps.
Why would they need to load a player just so you hear an explosion?
They are working on it for Vulkan. They work also on the direct access to GPU.
SC compensate with virtual memory. On a 8GB system, the main part of the memory used by SC is in the pagefile. That's why it's unplayable on HDD for low memory system.
They are pretty confident for a release in the next months. They are on it since a long time
Because when you open the door of your room and look at the window in the corridor, the game has to show you the battle. The assets must be loaded before.
That's because they were preloaded to your system. We can't have players round the corner and then start to load them in a FPS. You'd assume there is no work to be done while you're in a cubicle, makes sense. But I'd expect a shooter not to lag spike when suddenly a player appears in sight.
The radius of loading assets is HUGE in SC (at least 10km). The spaceport is the worst place to be for your system. EVERYTHING in at least 10km around you is loaded in your memory.
I was playing for a long time with 7 GB free memory + SSD.
No - i am talking about the main game engine code here and not about the render engine. The game loop is synchronous (and it is in Unity as far as i know too, same problem, same consequences) which gives a lot of troubles when something hogs the cycle time. If you never dabbled in real time programming (and RT/OS, embedded devices..), i suggest you start looking at that first...
It goes back to one of the core issues exposed in the Jennisson letter: that no-one ever thought about the asset budget under some bonehaded assumption that "the engine will sort it out". No-one bothered to figure out how much they had to, or should, load the game down with to maintain good performance, so everyone just piled on more and more junk unti it broke and they had to figure out a way to remove some of that pile on the fly (rather than not just pile everything on to begin with).
And with the door closed, none of that should matter to the FPS because they should not be processed unless the engine is a huge mess that fails to cull irrelevant assets from the rendering process. You're confusing two very different things: having assets loaded into memory, ready to be used, and processing and rendering those assets. Loading new assets can happen when a new actor enters the area, but can also be deferred to the very last moment when that asset is actually needed for the rendering. But then we have zoning and pre-loading -- standard techniques that CIG has tried to suggest are very new and advanced under the monicker OCS -- which lets all of that be sorted out as needed slightly before any rendering becomes a necessity.
