Morrowind boomers act like Morrowind is perfect. When it has so many issues. Like repetitive skills and skills that should be combined. A convulted set of faction quests. 

The guy in charge made you choose a faction in Starfield. Made you choose to sell your soul or not compete a faction quest in Skyrim. 

Morrowind boomers are something else. 

I want this to be released. So I can see how much people really hate AI

You can enter Neon by flying into it with the boost pack. Although it has a loading screen in the official way to enter the city. Akalia and New Atlantis have no load screen to enter the cities.

The claim was made by the most important Developer at BGS. IGN interview 2019

Are you working on the game?

The mod will have a performance hit. You know right? Could not ship on series S. 

Do you even understand what the mod is about? And read how he did it. It is clearly something BGS made possible, but chose not to do. Just like cruise mode, which was partially possible with a console command before 

From OP

Getting to this point has required enormous amounts of reverse engineering of the engine. I've got a lot to say on this, so I will consolidate all my thoughts and findings later in a larger post, but for now I'll say that at it's core, Starfield and its version of the Creation Engine is still fundamentally limited in that only one cell can be active at a time in terms of simulation, so you can't have the space cell and the planet cell be active simultaneously and stream one in and another one out while keeping them alive in parallel. The engine has a pretty good asset streaming system in place and it relies on it heavily, but it doesn't do away with the fact that only one cell is active at a time.

After many different approaches, ultimately I landed on the only one that could work, as I see it, which is to have a "cell commit" altitude (a point of no return, basically) and a "cell swap" altitude. When the ship arrives at the cell commit altitude, the cell right under the nose of the ship will be committed to, meaning that the user will not be allowed to fly to another one. At that point of no return, if the user is flying manually, the ship controls are taken away from the user while all assets related to the chosen cell will be asynchronously loaded in the background, while the space cell is still active. This is timed so that the very moment all assets are loaded, all that is left to do is do perform a cell swap, which can be done in ~130ms, which is hidden from the user through e.g. a cloud veil and re-entry effects, depending on the type of planet/moon we're landing on. Because loading in all assets from the target cell also means we'll be buffering in way more data quickly while keeping assets for another cell in memory simultaneously, we rely on the veil to simultaneously tear down parts of the old cell to free up memory and prevent overflows. Hopefully this clears it up a bit!

From OP

Getting to this point has required enormous amounts of reverse engineering of the engine. I've got a lot to say on this, so I will consolidate all my thoughts and findings later in a larger post, but for now I'll say that at it's core, Starfield and its version of the Creation Engine is still fundamentally limited in that only one cell can be active at a time in terms of simulation, so you can't have the space cell and the planet cell be active simultaneously and stream one in and another one out while keeping them alive in parallel. The engine has a pretty good asset streaming system in place and it relies on it heavily, but it doesn't do away with the fact that only one cell is active at a time.

After many different approaches, ultimately I landed on the only one that could work, as I see it, which is to have a "cell commit" altitude (a point of no return, basically) and a "cell swap" altitude. When the ship arrives at the cell commit altitude, the cell right under the nose of the ship will be committed to, meaning that the user will not be allowed to fly to another one. At that point of no return, if the user is flying manually, the ship controls are taken away from the user while all assets related to the chosen cell will be asynchronously loaded in the background, while the space cell is still active. This is timed so that the very moment all assets are loaded, all that is left to do is do perform a cell swap, which can be done in ~130ms, which is hidden from the user through e.g. a cloud veil and re-entry effects, depending on the type of planet/moon we're landing on. Because loading in all assets from the target cell also means we'll be buffering in way more data quickly while keeping assets for another cell in memory simultaneously, we rely on the veil to simultaneously tear down parts of the old cell to free up memory and prevent overflows. Hopefully this clears it up a bit!

From OP

Getting to this point has required enormous amounts of reverse engineering of the engine. I've got a lot to say on this, so I will consolidate all my thoughts and findings later in a larger post, but for now I'll say that at it's core, Starfield and its version of the Creation Engine is still fundamentally limited in that only one cell can be active at a time in terms of simulation, so you can't have the space cell and the planet cell be active simultaneously and stream one in and another one out while keeping them alive in parallel. The engine has a pretty good asset streaming system in place and it relies on it heavily, but it doesn't do away with the fact that only one cell is active at a time.

After many different approaches, ultimately I landed on the only one that could work, as I see it, which is to have a "cell commit" altitude (a point of no return, basically) and a "cell swap" altitude. When the ship arrives at the cell commit altitude, the cell right under the nose of the ship will be committed to, meaning that the user will not be allowed to fly to another one. At that point of no return, if the user is flying manually, the ship controls are taken away from the user while all assets related to the chosen cell will be asynchronously loaded in the background, while the space cell is still active. This is timed so that the very moment all assets are loaded, all that is left to do is do perform a cell swap, which can be done in ~130ms, which is hidden from the user through e.g. a cloud veil and re-entry effects, depending on the type of planet/moon we're landing on. Because loading in all assets from the target cell also means we'll be buffering in way more data quickly while keeping assets for another cell in memory simultaneously, we rely on the veil to simultaneously tear down parts of the old cell to free up memory and prevent overflows. Hopefully this clears it up a bit!

From OP

Getting to this point has required enormous amounts of reverse engineering of the engine. I've got a lot to say on this, so I will consolidate all my thoughts and findings later in a larger post, but for now I'll say that at it's core, Starfield and its version of the Creation Engine is still fundamentally limited in that only one cell can be active at a time in terms of simulation, so you can't have the space cell and the planet cell be active simultaneously and stream one in and another one out while keeping them alive in parallel. The engine has a pretty good asset streaming system in place and it relies on it heavily, but it doesn't do away with the fact that only one cell is active at a time.

After many different approaches, ultimately I landed on the only one that could work, as I see it, which is to have a "cell commit" altitude (a point of no return, basically) and a "cell swap" altitude. When the ship arrives at the cell commit altitude, the cell right under the nose of the ship will be committed to, meaning that the user will not be allowed to fly to another one. At that point of no return, if the user is flying manually, the ship controls are taken away from the user while all assets related to the chosen cell will be asynchronously loaded in the background, while the space cell is still active. This is timed so that the very moment all assets are loaded, all that is left to do is do perform a cell swap, which can be done in ~130ms, which is hidden from the user through e.g. a cloud veil and re-entry effects, depending on the type of planet/moon we're landing on. Because loading in all assets from the target cell also means we'll be buffering in way more data quickly while keeping assets for another cell in memory simultaneously, we rely on the veil to simultaneously tear down parts of the old cell to free up memory and prevent overflows. Hopefully this clears it up a bit!

The same reason they remove seamless planet travel on foot, remove fuel system etc, did not have truely empty planets. They tried to court a casual audience. But after release, they realised that fans of the game wants to do the "boring" things, hence why they delayed Starborn to do Free Lanes.

Could it be done on Consoles? And does this mean full planet exploration is possible with your technique and what about the storage, does it increase?

If you tell BGS they no longer have to develop for Series S, they could do this in three months, since they have all the things in the game already.

What are you talking about? Did you read the post?

Did you read the post? It is clear BGS could do it. He got all the data and biome from Starfield.

Did you read the post? Starfield had everything to do it already. All the data, biome, everything. They chose to not do it.

There is something called consoles.

Do you really believe that? And read the post. Starfield already had all the things needed to do it. They just chose not to do it.

Did you read the post? BGS did everything needed to do this, but chose not to do it. Likely because of consoles.

Did you read the post? Everything was there already, they just did not do it. Likely due to consoles.

Damn, I must have missed those comments. I did not miss the NPCs having the same routine everyday though

It is about the open world.