Lisias

I do by using a "weight" mask - a grayscale bitmap where each pixel would be used to sum the weight of the respective pixel on the skybox - essentially: skybox[x,y] = max(255, dim_factor[x,y] * skybox_source[x,y] + weight_map[x,y]) But I think the same result would be accomplished easier with my "3rd option" above. An opacity map, at a lower resolution to save memory and CPU/GPU juice, being drawn one layer above the skybox. Without light sources hindering the sight, this layer would have a 100% transparency, and the transparency would be decreased as the skybox need to be darken. The nice thing about this solution is that you can precalculate this shadowing_mask using the original skybox and weighting the mask using the brightness of the source pixels of a respective shadowing_pixel. It's like transforming a hires 1 bit image into a lores 4 or 8 bits grayscale - the number of lit pixels on a 4x4 (1 to 4 bits) or 8x8 (1 to 8 bits) box will give you the value of the grayscale. Then negate the value of that pixel for the mask. This shadow_mask, once it starts to be applied, will fade the skybox but not uniformly. Clusters of lit pixels on the skybox will fade slower than small groups of lit pixels due the shadow_map. Additionally, you can brute force regions of the shadow_map were you want the influence of the brightness of the sun and from the body you are orbiting, so the fade is more aggressive as large portions of the body is on the line of view (or when the star in visible). But that would be a bit computing intensive because you would need to recompute this brute force approach for every frame (and use some trigonometry and projections), being the reason the shadow_map must be on a lower resolution than the skybox (but not to extend in which people would perceive it). I think this can be easily prototyped using Python, numpy and Pillow - way faster to check the visual outcome than rebooting KSP all the time. I didn't knew about it. Dude, what a show my skybox became! Excellent tip! Since 5.4 Unity has support for HDR. So it's feasible, but this would probably need to reimplement the GalaxyCubeControl. What perhaps would not be that hard, but replacing the stock one without breaking everything may be a bit harder. But there's a draw back on this approach: I would need someone to rework the skybox. My approach above would reuse whatever is the skybox in use at the moment, and this is way more flexible IMHO. Modding an 12 years old game, IMHO, is where the fun really is! KSP2 (by example) will not need such a stunt, so if you want to sink your teeth on the matter, going back to older games is the way to go. There's none left. (I'm the TweakScale guy, remember? That one that made KSP-Recall too!) As a matter of fact, it may be even more fun doing things the 8 bit way. The feeling of accomplishment is bigger - doing the same thing everybody else already made is the best learning tool available, no doubt, as the feeling of being able to do it is nice. But the feeling of accomplishment really kicks when you score a stunt that nobody did before, like this: That said, unfortunately R.L sucks (and it sucks hard). Toying with this will be enjoyable, no doubt - but I will probably try it only on holidays or vacations or something.

Open the web page where the picture is, right click and select "Copy Image Address". Then paste the generated URL on a post, and Forum will do the rest. Now, if the problem is how to upload your images to a web page, I suggest learning about Imgur. Once you create an account here, all you need to do is to create a post, click on the button "Add Image" and then drag and drop the image from the Windows Explorer/Finder/Nautilus/whatever into the Pop Up that appears saying "Drop your image here". I like to keep my posts "hidden" on Imgur, so people needs to have a link to them to access them. Helps to keep trolls at large.

It will be interesting for sure. But being enjoyable is not enough, I need to have time available in order to enjoy doing this code without harming the other projects, as the consequences would be more than unpleasant. As the bug I just caught on that add'on I mentioned. Had someone already fixed it, I would not have to do it myself now. And so I would have more time available for doing enjoyable stuff. “Freedom " (and this includes freedom in Software) " is not an individual effort. Yours comes only when you grant others theirs.” - Aragonés, Sergio. That would create a new problem harder to cope with - currently, the flares are being visible trough atmospheres, and doing that would multiply the problem by thousands. Right now it's just an small annoyance, and the incidence of this problem is low enough to allow me to delay tackling down this one for some time. But in order to pursue this 4th idea, I would need to fix this one first, or I will create a (now very annoying) old new problem.. Not to mention that handling hundreds of additional flares is more GPU intensive than just dimming (or masking) the SkyBox.

I tried. https://github.com/net-lisias-ksp/DistantObject/issues/7 But now I have a problem: I have other tasks and duties, and diverting man-hours from these tasks to it now sounds counter-productive on the big picture. The nasty motherf…. uh… the project manager in me tells me to carry on these other tasks, as they are way more needed than this one. And there're also the bugs. Just fixed another one on an add'on I was using while testing this one.. - bug fixing always come first, as these ones propagates as rabbits on the code as time goes by. Kerbal proposes, Kraken disposes...

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. 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). Essentially what I detailed above. 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) 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). 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. 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.

I felt a great disturbance in the Force, as millions os parts suddenly descaled on a savegame... By obvious reasons, I disagree!!! Clipping parts disregarding the internal volumes is more of a cheating than using TweakScale - I had seen people clipping cockpits inside fuel tanks, and this is "cheating" for sure. Using TweakScale on a Career Game can spoil the game for sure, scaling engines in particular. But it can also save you a lot of parts, what could allow you to built more complex vessels without taxing your CPU - lowering the parts count to achieve the same result is always welcome. Using TweakScale on wings and control surfaces allows you to do more interesting wings, and scaling the Wheels is a necessity with the base game lacking diversity on these very needed tools. And about MechJeb's auto-pilot, I also disagree. Not everyone is a natural born pilot, and some don't even want to be. Doing challenges like circumnavigating Kerbin without some auto-pilot is self-torturing. Some people enjoy building things, other enjoy flying them. For the former, auto-pilots are a necessity, form the later, a valuable asset to be used on that long and boring transitions (or when you need to go to bathroom on the middle of a 2 hours flight between the poles). Give a chance also to the older videos from Scott Manley. There're some very valuable hints on these videos too!!

THIS is what I'm talking about! Thanks for the feedback! I can't say when I will try to tackle these down (and once I try it, if I will be able to effectively fix it), but I will not forget your suggestions: https://github.com/net-lisias-ksp/DistantObject/issues Right now, I'm inclined to close this development cycle and make a release, as I already have a nice feature set to be published - and I have some others urging issues on TweakScale I want to tackled down yet this week. But I can assure you I will go back to DOE soon enough - I have some interesting ideas to implement too, and they are itching on my brain on sleep time… Cheers!

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. 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...

Yep, now I see what you mean. TweakScale is optimised (perhaps too much?) to cope with the default BulkHead Profiles - as these are the standard diameters for parts in the Game - and since not all parts ends up making sense when scaled (as crewed parts, because the game engine throws an Exception on me if I try to increase the number of crew on a part - but I can reduce it…), most of people don't care for exact measures like you want to do - of if they care, don't bothered telling me, you are the second that talks about in all these years. All my attempts to rework the TweakScale's tweakables ended up in disasters. I didn't even committed the stunts, because the result was just terrible in usability - the current UI is terribly practical if you want to cope with the default BuldHeads, I didn't coped with anything else. And if me, he one that did he stunt, didn't liked to use the stunt, what to say about anybody else? So, by now, and after sleeping on the problem, I'm considering that perhaps a better alternative would be a Dialog with the scaling options for a part on the Editor. Some magical click, and a Pop Up appers where you can be picky about the scaling you want. And since now we the the AutoScaling (a feature that when active automatically scales the attaching part to match the parent one - most of the time, at least ! ), this can be a good solution for this borderline use case? Alternatively… And this may be a viable workaround for you - you are playing Reality Overhaul, RSS or something else? You know, you can rework the default scaling points by editing 010_ScaleTypes.cfg . If the default bulkhead of the mod you are using are different from Stock, then this is the best solution available to you: customise the Scale Factos (that snap points I talked about) to the bulkhead used on your game.

Creed, With Arms Wide Open. (it made me remembers the time my son had born)

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)

"By design". There's some "default" BulkHead Profiles on Stock (size00, size0, size0p5, etc) that are that small: 0.3125, 0.626, 0.9375 etc. Since these are common used bulkheads, TweakScale "snaps" into them by using the side arrows of the control. So, the "sub" scales between the profiles (that you select using the bar) ends up being calculated in a way that the increments and decrements "starts" and "ends" with these bulkhead profiles and that you can click on the UI using the pixels available to you - so this ends being limited also by yours current graphic resolution (moar pixels, moar increments). But that would incur in another problem - people using higher resolutions would be able to "subscale" things in way that people with lower resolutions would not, and so you would not be able to precisely "match" the parts manually if you change resolutions (besides the recently resurrected "Auto-Scale" feature would rescue you on this). So TweakScale sets also a "hard" increment on these values too to prevent this situation. And the after math is these scalings you have now. In your example, you are getting the increments available between 0.935 (size0p5) and 1.25 (size1), and this gives you a pretty narrow range os scales (just 0.315 meters wide), and so TweakScale ends up adding these minuscules "subsnap points" you see. In time… From what add'on is that marvellous propeller engine you are using?

ANNOUNCE Yeah, yeah, I know I said 2.1.1.3 was the last. I lied. Release 2.1.1.4 EXPERIMENTAL is available for downloading, with the following changes: Some adjustments while handling the vessel's Life Cycle on VesselDraw. CPU savings on DarkenSky and FlareDraw. Another huge performance enhancement on VesselDraw! If no bug report is filed, this is what will be the next release to be published on the mainstream next week, including SpaceDock and CurseForge! Downloads exclusively on the GITHUB (pre) release page. The OP (and the master branch on GitHub) will not be updated. Your Attention please!! This experimental release is essentially a Release Candidate. I think I finally nailed it. However, keep proper backups when using this, sheet happens after all! — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Will not be updated, this is an experimental release. SpaceDock. Will not be updated, this is an experimental release.

Fuel Switches are something that I need to address soon. From the multiple Fuel Switches available, only FS (using TSCo-FS) and B9PS are supported (and this one is still problematic). There's also ModularFuelSwitches that I want to support too (it's my favourite fuel switch! ). I want to believe that I will tackle down these ones in the near future - As long as I manage to kick TS 2.4.6.0 through the door (with an important update on a library that will be used on the Companions), I will have time to work on the Fuel Switches Companion. Cheers!

ANNOUNCE Release 2.1.1.3 EXPERIMENTAL is available for downloading, with the following changes: New Render Mode to allow smooth transitions at the cost of memory. Vessels are not removed from the cache, unless destroyed May use a lot of memory! Option to show the names of all visible bodies Use <ALT> while RightClicking the mouse. This is the last feature release - from now on, just bug fixes (if any - famous last words! ). If no bug report is filed, this is what will be the next release to be published on the mainstream next week, including SpaceDock and CurseForge! Downloads exclusively on the GITHUB (pre) release page. The OP (and the master branch on GitHub) will not be updated. Your Attention please!! THIS IS AN EXPERIMENTAL RELEASE. Being a visual only plugin, no nasty effects are expected, and the current features are working fine (most of the time! ). However, keep proper backups when using this, sheet happens after all! — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Will not be updated, this is an experimental release. SpaceDock. Will not be updated, this is an experimental release.

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.

News from the Front This is where we are now: Most (if not all) Stock parts works. At least some parts from ReStock works. A few parts of FireSpitter and/or KAX do not works. As the distance from the viewer grows, the precision in which the meshes are drawn plummets dramatically - it's entertaining sometimes. Performance is better, even by using ReStock on my puny MacPotato Apparently things start to drag their feet on my machine when the PQS kicks in - there's something on drawing the terrain on a higher level of quality that renders my rig on its knees. I think I introduced some hiccups when the viewable crafts enters into the viable zone (as I destroy everything when they are leaving the viable zone to save memory - you know, some people have a lot of crafts around) If this starts to get annoying to you, you may want to Render only the Targeted Craft. I think there's a way to minimise this at expense of delaying the visualisation of the craft, but I will run away on this to fight it another day. Using the Stock SAS to stabilise a Satellite equiped with a Tarsier Telescope is a challenge. The only thing that it's bothering me now is the parts not being rendered. I failed to understand why at this moment. The ReStock's Stayputnik is one of these parts that are not rendered, besides the Stock one renders fine. Curiously, some FS and KAX parts didn't rendered neither. So I instrumented the code to tattle the offending parts by name on initialisation, and, by my surprise, with this code active some of the missing parts started to show (as KAX) while others that were showing fine didn't. So I'm considering that perhaps this is not an error on the code itself (neither the parts), but on how to instance Meshes to be used - I may be failing to do something needed to make fetching the meshes from the GameDatabase reliable (or perhaps blowing up my VRAM capacity?). In a way or another, the last Experimental release is the best I can offer by now, and I considering releasing it on the mainstream next week. Currently, I'm working on understanding some current deployment decisions to allow a seamless transition on CKAN - I don't know (yet) what's the CKAN's "filter" thingy currently used by DOE, and I'm afraid of breaking something if I change it before doing it. I have some different ideas on how to support different planet packs, so I plan to phase out the "filter" thingy as long as I learn how to prevent breaking things on the wild by removing it. Cheers!

I'm playing Cold War using Spy Satellites!!! Do you want to do too? Ask me how!

ANNOUNCE Release 2.1.1.2 EXPERIMENTAL is available for downloading, with the following changes: Preventing some borderline situations to throw Exceptions on the MeshEngine Some more performance fixes Small mistakes corrected Downloads exclusively on the GITHUB (pre) release page. The OP (and the master branch on GitHub) will not be updated. Your Attention please!! THIS IS AN EXPERIMENTAL RELEASE. Besides nothing serious being expected (as this thingy does not changes anything on Parts, Crafts or Savegames - it's a visual only plugin), not all features are working as I would like. Proceed with discretion (and care), do not use this on valuable savegames - you know, sheet happens. Please remember to completely delete the GameData/DistanceObject folder before updating!!! — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Will not be updated, this is an experimental release. SpaceDock. Will not be updated, this is an experimental release.

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.

ANNOUNCE Release 2.1.1.1 EXPERIMENTAL is available for downloading, with the following changes: Huge performance improvements! Downloads exclusively on the GITHUB (pre) release page. The OP (and the master branch on GitHub) will not be updated. Your Attention please!! THIS IS AN EXPERIMENTAL RELEASE. Besides nothing serious is expected (as this thingy does not changes anything on Parts, Crafts or Savegames - it's a visual only plugin), really serious performance issues were detected on weaker rigs when ReStock is installed. Proceed with discretion (and care), do not use this on valuable savegames - you know, sheet happens. Please remember to completely delete the GameData/DistanceObject folder before updating!!! — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Will not be updated, this is an experimental release. SpaceDock. Will not be updated, this is an experimental release.

Texture Quality. You can adjust it on Main Menu / Settings / Graphics . You can set it to Full Res, Half Res, Quarter Res and Eight Res. It essentially lower the resolution of the meshes used on the game, allowing it to run on modest GPU rigs, as our Macs. Problem is that KSP applies the stunt indiscriminately! EVERTYTHING is downscaled, including widgets and small images for the UI - if you select Eight Res, you will barely be able to tell if a CheckBox is checked or not. There was a hack in the past that alleviated the problem by brute force reloading some images without the MIPMAP setting. I can't remember it right now, but I will edit this post with it once I recalled it - if someone else didn't did that first! — — POST EDIT — — @Hoozemans, I rememebered! It's Unblur! But I don't know if it still works on KSP >= 1.8, I will give this a try later...

Well, this one will demand some study to tackle down - but I will give it a try later : https://github.com/net-lisias-ksp/DistantObject/issues/2

ANNOUNCE Release 2.1.1.0 EXPERIMENTAL is available for downloading, with the following changes: Über refactoring Creating a shareable MeshEngine Decoupling PartModule details from the Engine Now it can be extended by creating new DLLs, instead of recompiling the thing! Adding (preliminary) support for ReStock To tell you the true, just a more thoughtfully implementation of Stock MODEL sections. Official support from KSP 1.4.5 to 1.12.2 Downloads exclusively on the GITHUB (pre) release page. The OP (and the master branch on GitHub) will not be updated. Your Attention please!! THIS IS AN EXPERIMENTAL RELEASE. Besides nothing serious is expected (as this thingy does not changes anything on Parts, Crafts or Savegames - it's a visual only plugin), really serious performance issues were detected on weaker rigs when ReStock is installed. Proceed with discretion (and care), do not use this on valuable savegames - you know, sheet happens. Please remember to completely delete the GameData/DistanceObject folder before updating!!! — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Will not be updated, this is an experimental release. SpaceDock. Will not be updated, this is an experimental release.

NOTAM The first session of hard coding is finished - I have extracted the "Mesh Engine" into a reusable component, and now DistantObject is not only easily extensible (i.e., you can add support for new Modules without recompiling the thing!), but also reusable on 3rd parties add'ons. Additionally, KSP down to 1.4.5 is guaranteed to work now - so it will run fine from 1.4.5 to the latest 1.12.2 . Support for KSP 1.3.x is feasible, I need to solve one small API glitch. Once I tackle this down, we will have full support from 1.3.0 to 1.12.2 (I may try 1.2.2 just for fun if I find time!!). The next step is to work out support for ReStock. Preliminary researches suggest that, well, ReStock does not uses anything "fancy" - it merely add many MODEL sections, each one with the mesh for a part of the part (pun not intended!). So, by example, ReStock can reuse the top and the bottom parts of a fuel tank into another one with the same bulkhead, but taller. The implementation appears to be straightforward. Stay tuned, an Experimental Release is on the works! — — POST EDIT — — Yep, it was simple like that. KSP 1.12.2 with ReStock is working now: ReStock, however, is pretty heavy on my machine. The performance was abysmal. I think I'm abusing the VRAM of my GPU, perhaps I should activate the MIPMAP for these textures? In a way or another, a Experimental Release is being cooked.