Modding in KSP 2?

[PowSeaPea]

While I know that Kerbal Space Program 2 is still in development, is there any idea on how modding will work. Will it be the same as now with KSP? I am assuming when the game is released the will be no mods around for the game for a bit. Could mod developers modify their mods to work with the second game or would they need to remake it entirely?

[Miguelsgamingch]

I Assume it will be similiar to KSP, But i dont really know.

And I Also Assume Mod Developers Will be needing to modify or redesigns there work to work for KSP 2.

[Incarnation of Chaos]

Developers confirmed that KSP2 will be easier to mod and more of the deeper functions will be exposed via APIs for modding.

[kerbiloid]

I believe, the 3d modelling and texturing will stay same easy/hard.

Because GIMP/Photoshop and Blender/Wings3d will stay same.

So, probably only plugins may change. Maybe be replaced with scripts.

[Spaceman.Spiff]

2 hours ago, Incarnation of Chaos said:

Developers confirmed that KSP2 will be easier to mod and more of the deeper functions will be exposed via APIs for modding.

I think it would also be interesting if they incorporated some of the more important modding tools/plugins that the current modding community uses.

Module Manager is pretty much a necessity for most mods, so it might be helpful if they had something like that in the base game.

It would also be nice if CKAN was integrated into the game. 

Regardless, i'm sure the modding community will figure out how to best improve the game. 

[jastrone]

i really hope they make mods more simple to download and maybe even like the modding for beam.NG thst updates mods and downloads mods in game but i think that is a bit to complicated to make

[OvinandRusk]

yeah

[Incarnation of Chaos]

On 1/18/2021 at 11:17 AM, Spaceman.Spiff said:

I think it would also be interesting if they incorporated some of the more important modding tools/plugins that the current modding community uses.

Module Manager is pretty much a necessity for most mods, so it might be helpful if they had something like that in the base game.

It would also be nice if CKAN was integrated into the game. 

Regardless, i'm sure the modding community will figure out how to best improve the game. 

They've incorporated a LUA scripting language that might be a Module Manager analog.

[probe137]

Yes.

[jwenting]

And of course it's going to have to have some system to make sure that mods are synched between players in the same multiplayer session. Always a pain.

[PunkRockZoologist]

I'll be interested to see which mods make the jump from KSP1 to KSP2. Given all of the base building functionality coming in the new game, and the better atmospheric visuals, most of the mods I use with KSP1 probably won't be necessary. So far it looks like only OPM and some form of Alcubierre-drive would be mods I'd look for, as those are both things they've said won't be in the base game.

Trying a new install of KSP1 right now with all of my favourite mods and it's still a bit janky.

[rextable]

I hope the devs can engineer a way for a heavily modded KSP2 to load more quickly than KSP1 does. Currently, KSP1 loads EVERYTHING upon game launch and thus takes aaaaaaaaaaages if you've got a bazillian mods. My current install (on a pretty much top tier PC) I can start KSP loading, go downstairs, make a fresh pot of coffee, let it brew for 5 minutes, poor my coffee.... slooooowly, go back upstairs to my PC and the fkin thing will still be chugging away on the load screen.

Cities Skylines - also a Unity game - does a similar thing. Although it waits to load EVERYTHING until you load a savegame rather than upon game launch. I wonder if this is a Unity thing - where it can't dynamically load and unload what it needs when it needs it. Anybody know? 

A modded Fallout 4 can be over 100GB in size on disk. But it only loads what it needs, when it needs it, so load times are perfectly acceptable. It may be an extraordinarily unstable game but at least you don't have to wait 10 minutes for it to fkin load every time it CTD. 

 

While I accept long load times for KSP1 as a fact of life, I do sincerely hope the KSP2 team can find a way to better handle mods.  

[Lisias]

11 minutes ago, rextable said:

Cities Skylines - also a Unity game - does a similar thing. Although it waits to load EVERYTHING until you load a savegame rather than upon game launch. I wonder if this is a Unity thing - where it can't dynamically load and unload what it needs when it needs it. Anybody know? 

Nope. Its a design decision.

Initially,  KSP's memory footprint was pretty modest (compared with nowadays), and the designer didn't wanted loading times while traveling on space - he wanted aalmost real life transition as you approach the planets and other bodies of the System.

The time passed, KSP multiplied its memory footprint (more than once) and nobody thought of a way to allow dynamic texture loading.

The textures are the main culprits of the loading times. On my rig,  I guess that 80% of the time taken is loading textures.

[rextable]

19 minutes ago, Lisias said:

Nope. Its a design decision.

Initially,  KSP's memory footprint was pretty modest (compared with nowadays), and the designer didn't wanted loading times while traveling on space - he wanted aalmost real life transition as you approach the planets and other bodies of the System.

The time passed, KSP multiplied its memory footprint (more than once) and nobody thought of a way to allow dynamic texture loading.

The textures are the main culprits of the loading times. On my rig,  I guess that 80% of the time taken is loading textures.

I see.  

Stock KSP is still pretty tiny by AAA game standards. It loads in the blink of an eye and is very snappy indeed. It's just those pesky RAM eating mods. There must be a way. If Unreal Engine can do KSP2 can do it right? 

 

....derp....

[K^2]

On 10/1/2021 at 2:29 PM, Lisias said:

The textures are the main culprits of the loading times. On my rig,  I guess that 80% of the time taken is loading textures.

Parsing of the part configs takes shockingly long, and that can definitely be fixed.

But yeah, given the way KSP2 is being built, there is a lot of data that will have to be streamed already. They might as well recycle some of that tech for the mods.

[Lisias]

1 hour ago, K^2 said:

Parsing of the part configs takes shockingly long, and that can definitely be fixed.

Frankly, this is not my perception (and I'm using a MacKrap, I mean, MacMini for gaming).

I have no doubt that loading precompiled prefab data would be way faster than loading assets one by one (the main problem here, not the Config files), but yet it's exactly this way of doing things that made KSP1 so friendly for modding. Anyone with a notepad can change almost every aspect of the game by editing the Config files, and I have no doubt that it was one of the key features that made KSP1 so successful.

In a way or another, "measure, don't guess". Let's make a test run on a slightly modded KSP 1.12.2 on my puny and overloaded MacMini (i7, 16G ram, HD4000 GPU with lots of Safari tabs opened, Visual Studio, you name it - the worst scenario possible!) using a spinning plate as medium, and after clearing all Module Manager data, so the patching also affects the timing. And this is what I got:

T0 : I typed "truncate -s 0 KSP.log ; open KSP.app ; tail -f KSP.log " and measure the time it took to log data start to pop on my terminal. It took 7 seconds to show that follows:

[LOG 21:14:34.917] ******* Log Initiated for Kerbal Space Program - 1.12.2.3167 (OSXPlayer) en-us *******
Kerbal Space Program - 1.12.2.3167 (OSXPlayer) en-us


OS: Mac OS X 10.14.6
CPU: Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz (8)
RAM: 16384
GPU: Intel HD Graphics 4000 OpenGL Engine (1536MB)
SM: 46 (OpenGL 4.1 INTEL-12.10.31)
RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RH
alf, R8, BGRA32, RGB111110Float, RG32, RG16, BGRA10101010_XR, BGR101010_XR, R16


Log started: Sat, Oct 02, 2021 21:14:34

So, 21:14:27 is the exact time in which I opened the KSP Application. Immediately after, KSP started to load Assemblies:

[LOG 21:14:34.958] ActionCanvas MASK: 3458764513820540928
[LOG 21:14:34.959] AppCanvas MASK: 3458764513820540928
[LOG 21:14:34.963] MainCanvas MASK: 3458764513820540928
[LOG 21:14:37.449] Load(Assembly): /000_KSPe
[LOG 21:14:37.450] AssemblyLoader: Loading assembly at /Users/lisias/Workspaces/KSP/runtime/1.12.2/GameData/000_KSPe.dll

By the source, I now that Module Manager is already patching the GameDatabase, something that it can only do when all the Configs are already in memory. And this was confirmed by the following log line

[LOG 21:14:49.499] [ModuleManager] INFO: Extracting patches

From 21:14:27 (when I typed "open KSP.app") to the first audio being loaded : ~16 seconds.

From open  KSP.app to the first message from MM talking about patching:  ~23 seconds.

The patching itself took ~53.5 seconds.

[LOG 21:15:40.815] [ModuleManager] INFO: Done patching
[LOG 21:15:40.816] [ModuleManager] INFO: Saving Cache
[LOG 21:15:40.987] [ModuleManager] INFO: Saving cache
[LOG 21:15:42.130] [ModuleManager] INFO: The Patch log can be found on PluginData/ModuleManager/MMPatch.log
[LOG 21:15:42.130] [ModuleManager] INFO: ModuleManager: 1754 patches applied
[LOG 21:15:42.130] [ModuleManager] INFO: Ran in 53.459s

This is already evidence that loading and parsing the Config files are not the worst time consumers on the process. So what could be?

Well, resources! The first audio was loaded at:

LOG 21:14:43.615] Load(Audio): Firespitter/Sounds/sound_brakes

and the last one at:

[LOG 21:14:52.064] Load(Audio): SquadExpansion/Serenity/Sounds/sfx_geyser_idle

So, loading audios was not the problem, only 10 seconds. Meshes perhaps?

[LOG 21:16:34.122] Load(Model): DistantObject/Flare/model
...
[LOG 21:16:43.702] Load(Model): TarsierSpaceTech/Parts/SpaceTelescope/model

Nope, less than 10 seconds too. And they were loaded before the Audio files, by the way (look the timestamps). So all the config files used were already in memory for sure.

Let's try the textures so:

[LOG 21:14:52.132] Load(Texture): DistantObject/Flare/model000
...
[LOG 21:16:34.095] Load(Texture): TarsierSpaceTech/Parts/SpaceTelescope/texture

About 100 seconds. Way more than the other resources, as we can see. So we have about 100 + 10 + 10 = 120 seconds just loading assets.

Now let's check about the "Compiling Configs" thingy, what appears be related to what you say about:

[LOG 21:16:57.074] Compiling Configs:
[LOG 21:16:57.074] Config(PHYSICSGLOBALS) /Physics/PHYSICSGLOBALS
...
[LOG 21:16:57.215] Config(@PART[restock-leg-3-rigid]:NEEDS[TweakScale&RestockRigidLegs]:FOR[TweakScaleCompanion_Restockplus]) TweakScaleCompanion/ReStockPlu
[LOG 21:16:57.216] Compiling Configs Completed.

Less than a second!  Obviously, the time eater is somewhere else. Let's try the PartLoader:

[LOG 21:16:57.408] PartLoader: Creating part database
[LOG 21:16:57.411] PartLoader: Compiling Part 'Firespitter/Parts/FS_BiplaneCockpit/FS_BiplaneCockpit'
...
[LOG 21:18:05.508] PartLoader: Compiling Internal Space 'SquadExpansion/MakingHistory/Spaces/Mk2Pod/Mk2Pod_Internal/MK2POD_IVA'

Well, about 70 seconds. Less than the time needed to load the textures, but way more than anything else.

It worths to mention that from this point to the Main Menu we have a few seconds more:

[LOG 21:18:51.636] Expansion makinghistory detected in path /Users/lisias/Workspaces/KSP/runtime/1.12.2/GameData/SquadExpansion/MakingHistory
[LOG 21:18:51.636] Expansion serenity detected in path /Users/lisias/Workspaces/KSP/runtime/1.12.2/GameData/SquadExpansion/Serenity
...
[LOG 21:18:52.110] ExpansionsLoader: Expansions loaded in 46.538s
[LOG 21:18:52.114] Loading Systems: Elapsed time is 257.1365s
[WRN 21:19:22.494] HighlightingSystem : Edge Highlighting requires AA to work!
[...
[LOG 21:19:24.076] [CelestialBody]: Kerbin's solar day length is 1d, 0h, 0m long. sidereal day length is 5h, 59m, 9s long
[LOG 21:19:29.155] [UIMasterController]: HideUI
[LOG 21:19:29.166] [HighLogic]: =========================== Scene Change : From LOADING to MAINMENU =====================

KSP gracefully gives us the time it took to boot strap itself: 257 seconds. So we have the following breakout:

Audio Load 			10
Model Load 			10
Texture Load			100
Config Compiling 		1
Part Loader			70
(other stuff)			66 secs (includes patches, made concurrently)
total				257

So, I'm right - but you are not wrong neither, compiling the parts (what includes generating the drag cubes, another expensive computation) also tooks a significative role on the time.

The question is: 70 seconds of load time worths losing the Config mechanism for defining parts? IMHO don't - mainly because you still have 120 seconds wasted to load the audiovisual assets, almost twice the time. Again, shoving everything on a bundle would probably save some time (as opening files on the filesystem is also a significant time waster).

But it really would worth losing the moddabilty we have on KSP1? Well, my opinion is not - but, of course, your mileage may vary.

About mileage, and out of curiosity, I decided to redo the test run after installing ReStock and ReStock+ (just because I'm already using them on another add'on and they are easily available). Let's see what we get this time, ReStock considerably reworked the Stock parts. To avoid the file system cache, I opened KSP 1.10 just to mess up things a bit. And then I opened KSP 1.12.2 again (with ReStock and ReStock+).

This time I will save all that trouble and I will go directly into the results:

Log started: Sat, Oct 02, 2021 22:46:46


[LOG 22:46:46.294] ActionCanvas MASK: 3458764513820540928
...
[LOG 22:51:43.468] ExpansionsLoader: Expansions loaded in 47.033s
[LOG 22:51:43.470] Loading Systems: Elapsed time is 297.1572s

And now the breakout:

Audio Load 			10
Model Load 			23
Texture Load			95
Config Compiling 		0.2 (!!)
Part Loader			68
(other stuff)			100 secs (includes patches, made concurrently)
total				297

We have some interesting numbers here!

ReStock took twice the time to load models, and slightly less on loading textures - what's not a surprise for who knows how to mod, because ReStock broke the meshes into reusable blocks (so tanks with different heights and same diameter can share the top and bottom ends). 

Compiling configs took surprisingly 200 milliseconds (don't have a clue why),  and the "other stuff" took ~35 seconds more.

And this is the interesting part! These "other stuff" is, essentially, where the Modules are initialised by the first time on each part. And this is something that shoving everything into a bundle would not help, because the modules will still need to be initialised in a way or another - and having precompiled prefabs will not help, because mods will need to alter something on the part in a way or another, and they need to respect whatever was the values on the part that they don't touch.

In the bottom line, ask any ReStock user if he would trade ReStock for a vanilla game loading in half the time and I'm pretty sure they will say no. Hell, I don't use ReStock and I would say no the same.  

I don't have the slightest idea how KSP2 will handle loading times.

But I say again: the KSP1 loading times are the price we pay for having a incredibly modding friendly environment - and taking this from us, modders, would damage KSP1 pretty badly. The savings for waving the Config files doesn't worth what we would lose. By a parsec.

[K^2]

22 hours ago, Lisias said:

The savings for waving the Config files doesn't worth what we would lose. By a parsec.

You are showing "Part loading" as 70% of texture loading time. That's not at all insignificant. And all of it is from parsing configs for individual files. Yes, the main config parsing doesn't take long, but the parts loading is still a parsing issue. When loading a few kB of text takes 70% of what it takes to load all the multi-MB textures of the parts, there's a huge problem. And fixing this would reduce loading time by about a quarter based on what you're showing here. Which is not insignificant at all.

[Lisias]

16 minutes ago, K^2 said:

You are showing "Part loading" as 70% of texture loading time. That's not at all insignificant. And all of it is from parsing configs for individual files. Yes, the main config parsing doesn't take long, but the parts loading is still a parsing issue. When loading a few kB of text takes 70% of what it takes to load all the multi-MB textures of the parts, there's a huge problem. And fixing this would reduce loading time by about a quarter based on what you're showing here. Which is not insignificant at all.

I think we are not on the same page. What do you understand as "parsing"?

The Part Loader's processes consist of  PartModule instancing, drag cube calculations and similar things. Anything related to "parsing" (definition on wikipedia) was already made, and it took 0.2 seconds on my ReStock run.

This is a excerpt of my log related to Part Loading:

[LOG 11:47:58.448] PartLoader: Creating part database
[LOG 11:47:58.451] PartLoader: Compiling Part 'Firespitter/Parts/FS_BiplaneCockpit/FS_BiplaneCockpit'
[LOG 11:47:58.491] EffectList: Created 15 effect types
[LOG 11:47:58.554] [KSP-Recall-Refunding] TRACE: OnAwake <NO VESSEL>-FS.BiplaneCockpit:FFFEABA0
[LOG 11:47:58.565] [KSP-Recall-Refunding] TRACE: OnLoad <NO VESSEL>-FS.BiplaneCockpit:FFFEABA0 True
[LOG 11:47:58.589] [KSP-Recall-Refunding] TRACE: OnAwake <NO VESSEL>-FS.BiplaneCockpit(Clone):FFFEAB80
[LOG 11:47:58.594] [KSP-Recall-Refunding] TRACE: OnDestroy FS.BiplaneCockpit(Clone):0
[LOG 11:47:58.615] PartLoader: Part 'Firespitter/Parts/FS_BiplaneCockpit/FS_BiplaneCockpit' has no database record. Creating.
[LOG 11:47:58.615] [DragCubeSystem]: Drag cubes not found or cannot be read for part Part. Generating New drag cubes.
[LOG 11:47:58.622] [KSP-Recall-Refunding] TRACE: OnAwake <NO VESSEL>-FS.BiplaneCockpit(Clone) Drag Rendering Clone:FFFEAAFE
[LOG 11:47:58.624] DragCubeSystem: Creating drag cubes for part 'FS.BiplaneCockpit'
[LOG 11:47:58.692] [KSP-Recall-Refunding] TRACE: OnDestroy FS.BiplaneCockpit(Clone) Drag Rendering Clone:FFFEAAFE
[LOG 11:47:58.997] PartLoader: Compiling Part 'Firespitter/Parts/FS_BiplaneElevator/FS_BiplaneElevator'
[LOG 11:47:59.062] [KSP-Recall-Refunding] TRACE: OnAwake <NO VESSEL>-FS.BiplaneElevator:FFFEAA60
[LOG 11:47:59.062] [KSP-Recall-Refunding] TRACE: OnLoad <NO VESSEL>-FS.BiplaneElevator:FFFEAA60 True
[ERR 11:47:59.108] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null

I choose this log because it's using a debug version of KSP-Recall, where the PartModule's life cycle is logged. The OnAwake, OnLoad, OnDestroy (and many others) are called for every module used on every part. There's no escape from this - the PartModules need to be instanced in order to fetch the needed data to build the part's prefab, that so will be used to instantiate crafts later.

I agree that this is pretty time intensive, but this is not related to "parsing" at all. This is the process of bootstraping the parts - the price we pay to allow us to create "customised prefabs" at runtime. We wave the Part Loader, no one will be able to customise Parts anymore - except by decompiling the prefab, changing it, recompiling it and them replacing the original somehow - and by now, kiss baby byebye to any interoperability between different mods, what to say different authors.

If everything Stock were already precompiled into the prefab - what I think it's what you are saying it should had been done to save time, we would had the following consequences:

• People would not be able to mod KSP using NotePad++ and PaintBrush
  • Believe me, this is the entry point for almost everybody - it was mine at least.
• Someone would had to hack KSP (using Harmony or something similar) in order to code a Part Loader equivalent, so people would be able to mod KSP
  • And by that time, we would had again the time penalty of the mechanism - and the penalty of using a hacked piece of code, most of the time without the minimal quality metrics we expect from proper, polished Product.
  • (and I'm not even touching the legal implications)

 

 

[K^2]

3 hours ago, Lisias said:

I think we are not on the same page. What do you understand as "parsing"?

Fair. I'm oversimplifying. "Compiling" might be a better term here. What I mean is taking the text data and turning it into the in-game representation - everything but the actual memory allocations, which, of course, have to take place at the runtime. All of the operations in building the internal data only really need to be done once.

3 hours ago, Lisias said:

People would not be able to mod KSP using NotePad++ and PaintBrush

Except that this is exactly how it works on pretty much every major game project and people do edit text files that get built exactly once. Caching of binary builds is a standard practice in games industry. If I edit a scene file, whether I did that with a dedicated tool or simply opened it up in notepad and changed markup data, the game will know that the binaries are out of date and rebuild them. Yes, when we ship games, we often only build the binary cache and many games ship with the build tools stripped out, but there are enough games out there that maintain the dev-environment behavior of checking for new/modified markup files and will rebuild parts of the cache that are out of date - often, specifically to be more mod-friendly.

[kerbiloid]

Spoiler

On 10/2/2021 at 12:29 AM, Lisias said:

The textures are the main culprits of the loading times. On my rig,  I guess that 80% of the time taken is loading textures.

And that's why irl they do it all white.

Spoiler

It saves the loading time on approach.

 

[Lisias]

10 hours ago, K^2 said:

Except that this is exactly how it works on pretty much every major game project and people do edit text files that get built exactly once

No argument on that.

But.. If we, people that love KSP1, would like any other major game available, we would be there - not here. And, so, we would not be having this conversation at all.

Your are forgetting something very important - KSP1 players like KSP1 for many reasons, being it highly and easily moddable one of the most important. Whatever KSP2 is doing to tacked down the loading times, it should have a fallback to allow easy modding (and, as we can see, at the expenses of loading times) otherwise it will not repeat the same kind of success KSP have (or had?).

What may be or may not be a problem - perhaps it's what Private Division really intend, a shining new user base. No argument at all neither, it's their product, it's up to them to decide about the strategy to sell the product (the main reason to do any commercial activity after all).

But one thing I can say for sure: by removing this incredible modding friendly feature without providing a fallback, KSP2 will be, effectively, a new product for a different user base (and probably a different Community) those only similarity to KSP1 would be the Green Creeters being blown flown into Space. 

 

10 hours ago, K^2 said:

but there are enough games out there that maintain the dev-environment behavior of checking for new/modified markup files and will rebuild parts of the cache that are out of date - often, specifically to be more mod-friendly.

A preload time "Part Compiler" that would regenerate the Bundle (the "prefab" and the assets into a single, optimised for loading,  blob?

That would do - it's more or less how we modded Quake1 after all.

But, yet, it must be done in a way that would allow people do what's being done on the Ubioweld thread: allow people to peek inside the game assets and create new ways of using them without having to resort to "decompilers" or other practices not exactly endorsed by Forum Rules! You know, we want to publish things here...

[K^2]

7 hours ago, Lisias said:

A preload time "Part Compiler" that would regenerate the Bundle (the "prefab" and the assets into a single, optimised for loading,  blob?

Doesn't have to be a single blob for everything, there are a lot of implementation options here, but that's the gist, yeah. Most of that data takes up considerable CPU time to prepare and very little disk space to store. Just cache it and invalidate cache if the source file updated.

Side note, I'd be shocked if there is no way to make processing a lot faster either, but if you cache it, it's kind of a moot point. No reason to over-optimize something that will only happen once for a lot of players, and only once per mod install for almost everyone else.

8 hours ago, Lisias said:

But, yet, it must be done in a way that would allow people do what's being done on the Ubioweld thread: allow people to peek inside the game assets and create new ways of using them without having to resort to "decompilers" or other practices not exactly endorsed by Forum Rules! You know, we want to publish things here...

I have encountered cases where build tools get intentionally cut from released game binaries because they contained some libraries with infectious GPL or similar licensing. Basically, if they were to release the game with these libraries, they'd have to publish source for the entire game. But I've also worked on projects where the tools are literally there in the published game, only with some editing features turned off, and the only reason people can't mod the game easily is because the source format and directory structure aren't publicly shared. In general, though, developers need a reason to disable these features, and because that's work, they usually leave all or huge chunks of them in. It's usually easier to ship a game with build tools than without.

For KSP2, baking part info in some way or form is going to be necessary. And caching baked files is going to be necessary for streaming. I think they're pretty much forced to write the tools we'd want for much faster loading. And because the developers don't want to wait for unnecessary build times either, they're pretty much guaranteed to auto-detect source file changes and build stuff on demand. Basically, all of the features we want. All Intercept has to do to make the game easily moddable and reduce loading times for everyone is just not turn off that feature when they ship.

That said, if for some reason PD or Intercept go back on modding and try to lock us out of critical tools, I'm here to help build replacement tools. Unless PD forces Intercept to install some sort of cheat detection, I don't think we have to resort to anything that would be a forum violation to share. In the worst case scenario, I still think modding is going to be worth it, even if it ends up against forum's ToS and all discussion of mods for KSP2 will have to be moved elsewhere. I hope that doesn't happen, but I'm confident that modding will be a big part of KSP2 either way.

[Staticalliam7]

On 10/1/2021 at 5:12 PM, rextable said:

I hope the devs can engineer a way for a heavily modded KSP2 to load more quickly than KSP1 does. Currently, KSP1 loads EVERYTHING upon game launch and thus takes aaaaaaaaaaages if you've got a bazillian mods. My current install (on a pretty much top tier PC) I can start KSP loading, go downstairs, make a fresh pot of coffee, let it brew for 5 minutes, poor my coffee.... slooooowly, go back upstairs to my PC and the fkin thing will still be chugging away on the load screen.

Cities Skylines - also a Unity game - does a similar thing. Although it waits to load EVERYTHING until you load a savegame rather than upon game launch. I wonder if this is a Unity thing - where it can't dynamically load and unload what it needs when it needs it. Anybody know? 

A modded Fallout 4 can be over 100GB in size on disk. But it only loads what it needs, when it needs it, so load times are perfectly acceptable. It may be an extraordinarily unstable game but at least you don't have to wait 10 minutes for it to fkin load every time it CTD. 

 

While I accept long load times for KSP1 as a fact of life, I do sincerely hope the KSP2 team can find a way to better handle mods.

the advantage of loading everything is that it's all there and loading after the load screen is much faster than it would be 

[mattinoz]

5 hours ago, Staticalliam7 said:

the advantage of loading everything is that it's all there and loading after the load screen is much faster than it would be 

Think about KSP is that you spend a lot of time either drifting in space or thinking about how to drift in space. The intensive bits with engines firing are actually shorted lived. The longer lived the better obviously.

So I'd think there is an awful lot of background processing time to load stuff that'll be needed probably soon. I'd think with multiplayer spacial grid there could be a way of having fairly efficient sub-saved games that could be loaded quickly an add to a shared pool of in memory assest as needed so a couple/few of these could be in memory to switch between.

[rextable]

Very interdasting.

I didn't realise it was the modability of KSP that made it slow to load. Well, I think slow loading is well worth the price of amazing mods and modding community.

On 10/2/2021 at 11:32 PM, K^2 said:

Parsing of the part configs takes shockingly long, and that can definitely be fixed.

But yeah, given the way KSP2 is being built, there is a lot of data that will have to be streamed already. They might as well recycle some of that tech for the mods.

 

By "streaming" do you mean 'loaded on demand' sorta thang or something else entirely?

 

9 hours ago, Staticalliam7 said:

the advantage of loading everything is that it's all there and loading after the load screen is much faster than it would be 

Agreed :-)