Modding in KSP 2?

[t_v]

Not to discredit the current loading system but I think it would be great if there would at least be an option to have things load dynamically as needed. If you install more mods you take up more ram and eventually low end systems will run out of space to store parts and planets. I would love to get planet mods with thousands of high fidelity bodies (once I tweak the confits to get them compatible) but it takes up too much ram for my laptop to handle. If the loading system were well done, it would be cool to not have everything load at once and to have things unload and no longer in use. In game, individual parts would only take fractions of a a second to load in so there would be barely any difference when looking at the part list. As for planets, it is a little more complicated because I assume they would need to at least be partially loaded without textures and you can just tab to any planet on the map which might mean you would see them loading in, but hopefully a solution can be found for that. 

Edited October 5, 2021 by t_v

[SciMan]

I really doubt that KSP 2 will not have at least some form of dynamic load-on-demand for things. That should help out a lot with performance.

It would also allow things like even higher resolution part, planet, and colony piece textures, which would be nice, since we don't want this game looking like it came from 2013 do we?

As far as modding goes, I sincerely hope that there's some sort of system for adjusting the specifications and functions of parts that works similarly to how ModuleManager works for KSP 1, because I'm pretty sure that most of the mods for KSP 1 now require ModuleManager because it just makes things so much easier to deal with.

I also hope that it might be possible to use the Steam Workshop to handle the mods, that or build-in a mod manager of some kind (with the ability to install old/incompatible mods if you so desire, but default that to "compatible mods only" of course), that way we can massively simplify the way the mods work (would be nice if it could natively read the mods directly from .zip files too, I know Subnautica's modding system allows this and Subnautica also runs on Unity).

[K^2]

11 hours ago, rextable said:

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

In a tl;dr way, yes. But if you want a bit more detail, as far as it relates to games and game data, streaming is ability to load data from hard drive directly into RAM without involving CPU for anything beyond kicking off the process. And yeah, what that lets you do in practice is load assets when you need them, because you don't have to stop the game to handle the loading. The game engine notices that it's missing some asset data, issues a request, and just keeps ignoring any objects needing these assets until the assets are loaded. This can lead to pop-in if you are very aggressive about it, but can also be entirely seamless if you have a bit of a headroom on RAM and have different level of detail versions of your assets that can be loaded separately.

A good use case in a game like KSP is not loading high resolution terrain textures until you are in SoI of the planet that needs them. Possibly, even loading only select biomes for the highest quality versions. This might cause things to look blurry for a few frames when you are switching between ships, but you get a lot of flexibility out of it that usually makes it worth it.

One caveat relevant here is that any data you might want to stream has to be in the exact format you want to use in the game. Like, you wouldn't stream a JPEG image, because you have to decode JPEG before you can display it, and if your CPU has to spend time decoding the data, that often leads to choppy frame rate or freezes. Obviously, you can handle a few operations like that, and you usually have to, and a lot of hardware these days, notably all major consoles, support some sort of compression in streaming. You can think of data as being in ZIP files on the HDD/SSD and gets decompressed as it's being loaded by a dedicated chip, so again, no CPU use necessary. But otherwise, the data needs to be ready for use.

And this is where it gets a little tricky with modding. If the game expects data that has been processed, and you just added fresh, unprocessed data by installing a mod, something somewhere needs to figure out that this happened and prepare the data before it can be streamed. The way KSP mods work, some of that is done by the modding SDK you use to create modded parts, but a lot of data has to be built by the game. There are a whole bunch of ways to handle it. The simplest is to not worry about it until you actually try to load the data, and then do the processing if it's needed then. Yes, that will definitely cause a freeze in the game, but if that only happens once per install of a particular mod, that's not a huge deal. A more complete solution is generating a dependency graph and checking it when the game starts. For a game like KSP2, that shouldn't be too hard, especially, since you have a part list upfront and you can just check to see that all the data you need for every part is available when you start the game without having to actually load everything.

[Lisias]

19 hours ago, t_v said:

Not to discredit the current loading system but I think it would be great if there would at least be an option to have things load dynamically as needed. If you install more mods you take up more ram and eventually low end systems will run out of space to store parts and planets. [..]

Yep. Dynamic loading of Audio Visuals would help. And a lot!

The interesting thing... You need to know about every asset existent, but you don't have to load it all. You can load the smallest mipmap of it first, so your 3D engine will have something to draw while someone else load the hires image when it's the time.

Meshes, part definitions, text - all of that it's pretty small in memory footprint - you can preload these without worrying about memory,  and it's usually worse to load them on demand from the disk. Meshes are somewhat bigger, but they are "costly" to internalise (i.e., transform the bunch of bytes into a useable data structure in memory).

Sounds would be a problem - there's no acceptable way to have in memory a "lores version" of the audio to be played while loading the hires, so at least the sound effects would have to be preloaded at once too. But music and speech can be loaded on demand (and discarded after) without problems.

 

19 hours ago, t_v said:

As for planets, it is a little more complicated because I assume they would need to at least be partially loaded without textures and you can just tab to any planet on the map which might mean you would see them loading in, but hopefully a solution can be found for that. 

MIPMAPs to the rescue. KSP already use them, as makes no sense on scanning a 1024x1024 texture when the mesh to be drawn will use only 16x16 pixels on the video.

From things that would make a huge difference on KSP1 right now, having the textures' mipmaps cached and loading only the smallest versions (as well metadata about the texture) in advance would save a lot of I/O on loading - and also a lot of memory on the startup.

You will eventually load all the textures eventually, and so you will end up with the same memory footprint anyway - but you will be able to start playing sooner (and we always can try to unload hires textures not in use once you switch to a scene).

 

17 hours ago, SciMan said:

I really doubt that KSP 2 will not have at least some form of dynamic load-on-demand for things. That should help out a lot with performance.

Essentially what I detailed above.

 

17 hours ago, SciMan said:

It would also allow things like even higher resolution part, planet, and colony piece textures, which would be nice, since we don't want this game looking like it came from 2013 do we?

Why not?

There's a significant trending on retro-graphics on indie games lately. I have bought a lot of pixel graphics games lately, some of them pretty impressive (as this one on the spoiler)

Spoiler

 

As a matter of fact, a ReStock equivalent for low end computers is more than needed right now. Now and then I fire up my KSP 1.4.5, it's the second best performatic KSP version on my rig (only KSP 1.4.3 and 1.3.1 are better).

 

17 hours ago, SciMan said:

As far as modding goes, I sincerely hope that there's some sort of system for adjusting the specifications and functions of parts that works similarly to how ModuleManager works for KSP 1, because I'm pretty sure that most of the mods for KSP 1 now require ModuleManager because it just makes things so much easier to deal with.

Not only that, I would like full access to the "original" assets used on the game, exactly like what we have today on KSP1. Learning by example, looking on how the stock parts were implemented (and then tinkering with them) is one of the key factors that leaded KSP1 to its success, IMHO.

 

On 10/4/2021 at 8:16 PM, K^2 said:

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. 

That's a huge misconception about this license. You can release the game, and then the tools that use GPL code. You can't do it with both on the same package, you will have to distribute them separately in two downloads (that can be available on the same site, there's no restrictions about how and where you distribute GPL material) - what's exactly what we have here on the Modding Scene anyway.

You can mix GPL and proprietary code on the user's machine : once the user download the thing legally on his/her machine, he/she can do whatever he/she wants, and this is wrote in stone on the Copyright Act - I still waiting for someone with guts (and no brains) to challenge that (have some popcorn stocked, waiting for the show).

Write good interfaces (that should be public), be cautious about how and what you distribute on the binaries, keep proper (and curated) repositories for the open source tools (to avoid misrepresentations, the real problem on open source - you need to defend your turf!), and you are set.

 

Edited October 6, 2021 by Lisias
better phrasing.

[shdwlrd]

3 hours ago, Lisias said:

There's a significant trending on retro-graphics on indie games lately. I have bought a lot of pixel graphics games lately, some of them pretty impressive (as this one on the spoiler)

  Hide contents

 

Wow, that brings back memories of the games I've played as a teenager.

[K^2]

10 hours ago, Lisias said:

That's a huge misconception about this license. You can release the game, and then the tools that use GPL code.

Oh, absolutely. What I'm talking about is stuff that's been built directly into the game executable. Actual example from a recent game, we had to generate convex hulls for some geo for a feature involving physics particles for FX. It was handful of objects with low vertex counts, so it was cheap enough to do the build on demand. But because the library generating the convex hulls was under GPL (or similar license), the shared code containing that library would not get compiled in for release version. Which meant we had to move the generation of collision hulls to the builder, and now we had to track the dependencies to make sure that the collision hulls are built for all the right object and not for all the objects, and then platform-specific dependencies became a factor, and it was all in all a couple of weeks of work just to get the build process for these sorted, whereas the initial proof-of-concept on-demand loading was done in an afternoon.

And yeah, in principle, the entire builder could be released as open-source project with all of its libraries separately from the game. (Edit: Or as you point out, still as proprietary tool, but with open-soruce libraries that contain the actual GPL code delivered separately.) That's not going to happen for that particular game, because that's a whole another can of worms that the studio doesn't want to deal with, but it's not because of any legal restrictions.

My point, however, wasn't about situations where tools are intentionally released by the game developers to be used by modding communities. It was entirely about the situations when tools get left in because they weren't worth a hassle to remove. In the above example, if we could ship the game with that hull generator, we would have. There just was no reason to pull it out of the game other than licensing. And there are plenty of games out there with dev features left in the game either disabled or simply unused. And when you are trying to ship a game that is easy to mod, sometimes, all you have to do is absolutely nothing. If you already have build tools integrated into your executable, you just ship it as is.

Edited October 6, 2021 by K^2