Lisias

This time it's something else borking on you: [LOG 22:10:29.042] Resource tantares_sp_full_friction added to database [LOG 22:10:29.043] CodeAssetLoader: Compiling all code assets [LOG 22:10:29.047] ExperienceSystemConfig: Added Effect 'DeployedSciencePowerSkill' to Trait '#autoLOC_500103' [LOG 22:10:29.048] ExperienceSystemConfig: Added Effect 'DeployedScienceExpSkill' to Trait '#autoLOC_500105' [EXC 22:10:29.052] NullReferenceException: Object reference not set to an instance of an object GameDatabase.CleanupLoaders () (at <cd473063d3a2482f8d93d388d0c95035>:0) GameDatabase+<CreateDatabase>d__71.MoveNext () (at <cd473063d3a2482f8d93d388d0c95035>:0) UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <12e76cd50cc64cf19e759e981cb725af>: That's something missing or broken on your KSP. (This happened because to speed up things on loading, Squad had to wave some try-catches (a handful but very CPU consuming programming technique). So if something goes badly inside a thing we call "hot code" (something that it's used many, many times and so we need to do things fast there), the whole game just gets stuck.) Problem is that DeployedScienceExpSkill is a stock thing, so it's something else that handles Science blowing up. The last thingy added successfully to the database was tantares_sp_full_friction , so I searched for it on the patching log to see what's processed after it (not a rule, but sometimes this can help to sort out the problem): [LOG 22:10:28.977] Config(PHYSICMATERIAL_DEFINITION) TantaresSP/resources/tantares_sp_physics_materials/tantares_sp_full_friction [LOG 22:10:28.977] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.977] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.977] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.977] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.977] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.977] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.977] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.978] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.978] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION [LOG 22:10:28.978] Config(EXPERIMENT_DEFINITION) TantaresSP/resources/tantares_sp_science_definition/EXPERIMENT_DEFINITION And I think we may have a confirmation: there's something missing or broken on Tantares. You need to seek help from the Tantares maintainer. I ditched Windows 10 years ago, I can't help. Sorry. Cheers!

You perhaps, but not other people. Forcing your way of playing into people is not the best way to make friends. I would understand such limitation on Editor, because Editor needs to know how many Kerbals the part support to draw the slots - by Editor could take this value from the part instead of the prefab, but whatever. But there's no such limit on flying time. And, again, if the problem would be the number of available seats, the criteria should be applied on the prefab itself too. Anyone can shove 100 Kerbals on a MK1 Cockpit using a patch, but TweakScale can't shove 3 by scaling the cockpit up. Again, sounds arbitrary and unneeded.

This is going to be somewhat dense and technical, so I suggest to anyone reading this to grab some popcorns. That's the history: OOP may be messy sometimes, but it's still to this moment one of the best approaches for controlling complexity - and a Game Engine is anything but simple. But OOP has a drawback (there's no free lunch, the complexity always "leaks" to somewhere else), OOP makes the initialisation and the deinitialisation way too CPU intensive. Objects has a thing called Constructor, and the runtime call this Constructor every time you say "new" to a class. And once the system became more complex, you have Objects inside Objects inside Objects in many, many levels - and each one of them needs to have the Constructor called when the Top Cat, I mean, the Top Object is instantiated (the technical term for what happens when you do a "new" to a class). Once an object dies, the runtime does the same, but calling the Destructors this time. And again we have lots and lots of CPU time being used on cascading calls. On C# things are yet a bit more messy because you don't "kill" objects, you abandon them until the Garbage Collector realises there's an abandoned object lingering around and goes for it to free the memory. Unity choose a different approach for this problem: realising that most objects are initialised to a same state (i.e., have the same initial values once instantiated), they choose to "run the Constructors" on building time only once (instead of every time the Object is created) and save the state on a blob, that so would be injected inside a "fast track constructed" object. A memcpy is way faster than a lot of calls doing settings and gettings scattered on the heap. Obviously, this also has a cost: these Fast Track objects can only have a "default constructor" (i.e., the Constructor must not have any parameters), as a Constructor with parameters will create at runtime a State that it's impossible to precompile at building time (you would need a blob for every possible values - or combinations of values - of the parameters of the Constructor!). The collection of every premade blob for every Game Object is called the prefabs - pre-fabricated objects. And this makes loading and initialising things a lot faster (as long you obey by the rules). And this is where things get interesting on KSP - Since the very first release, KSP was fiercely intended to be modded. And Fiercely is the keywork here - every single measure or idea that could improve moddability was tested and some were implemented. One thing that makes harder to mod a game is… the prefab!! How to safely mod a part, if their data is carved on stone on the prefab? And how to mod a modded part without screwing up everything? Just imagine two guys trying to change a part at runtime at the same time, one undoing what the other did... Yep. Terribly messy. And so the KSP's creator decided to wave a bit the speed of the prefabs (remember, there's no free lunch - and you can't have the cake and eat it too!) by waving building the prefab at the game's building time, to create the prefabs on loading time! Every time you boot up KSP, instead of reading a giant blob full of prefabs, KSP loads its essential bundles (with some prefabs already premade) and then go hunt for Config Files on the file system. These config files are then "compiled" and used to create the prefab of the parts of the game. Once the game is loaded, Game Objects are "cloned" (as instantiate is not the correct term anymore) using these prefabs built at load time. And this is the reason KSP is so moddable - you don't need to decompile the prefab of a part, change the values you want, recompile and then replace somehow the original blob with yours (and then hope for nobody else trying to do the same on the same part). You just change a Config file, or write a new one, and voila!! A changed or new prefab without the need to recompile the whole shebang! #HURRAY!! So, and going direct to the matter now, when you take a Cockpit from the Part's Pallet and attach it to another part, KSP does that process I described above: it clone the part, inject on it a copy of its prefab (to fast initialise everything), and then attach the part to that another, and now you have a new living part to use. My kludge with the Crew is exactly that: if I write a patch to shove 100 Kerbals on a MK1 cockpit, KSP will happily allow me to shove 100 Kerbals on the MK1 Cockpit, completely disregarding the number of seats of the IVA. But if TweakScale tries to do the same, KSP will reject it. But, hey, you don't need to trust me on this, you can verify yourself! Shove this patch somewhere in your GameData (I suggest __LOCAL, so you can localise it easily and remove the stunt later): @PART[*]:HAS[!MODULE[KerbalEVA],!MODULE[ModuleAsteroid],!MODULE[ModuleComet]]:FINAL { @CrewCapacity *= 100 } And see what you can do now: 12 Kerbals (still have 88 slots available) on a MK1 cockpit - and the thing has only one seat. Github issue: https://github.com/net-lisias-ksp/TweakScale/issues/44 Last time I bored to try the stunt here.

ANNOUNCE Release 2.1.1.5 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. Significant performance enhancements and CPU savings 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. Guys, this is the real deal - all the work on the Experimental releases (more some late minute fixes and adjustments) are consolidated on a formal Release! (this is also the last time I use the SpySat to take the pictures - I'm learning my way on Cameras, next release I will use something else!! And a screenshot using the hint from @rextable: See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Right Now. SpaceDock. (By Saturday, probably, as I need to push some changes on NetKan) The rationale is that Real Life bitten me this week (again!), and I ended up pushing ahead some tasks (as CKAN)

I disagree. I can shove how many crew I want on the part config, the game engine let it pass. It only throws the exception when the current crew size is bigger than the prefab, not when there're more Kerbals than seats. And I can even mangle the prefab at runtime to overcome this less than happy decision, the only criteria is the current crew size being larger than on prefab - mangling the prefab kinda work around this BS, but by doing that I would screwup everybody because is known to squash the data on the living part config using the prefab when loading a savegame. I want to build a bus, Kerbals would travel on their feet! There's a lot of 3rd-parties add'ons without enough seats on the used (stock) IVA, and there're some add'ons that just don't provide a IVA at all (as the bus parts I built for me). If the game engine would be counting available seats, I would (reluctantly) agree - but I can type 100 Kerbals on a MK1 capsule's config if I want, things will work fine the same. So there's no real reason to disallow doing that programatically. If the KSP engine can accept a config with more crew than seats, why not from a PartModule? This sounds arbitrary and targeting. I will give this a peek tomorrow in the morning. It can by anything, but at least I can try to rule out TweakScale before escalating it "upstairs".

WAIT! Did you used CKAN to install this stuff??

Got it. Let's crack this nut! At first, I see you have a lot of different module manager versions installed: [LOG 20:30:05.698] [AddonLoader]: Instantiating addon 'ModuleManager' from assembly 'ModuleManager' [EXC 20:30:05.703] MissingMethodException: PopupDialog PopupDialog.SpawnPopupDialog(UnityEngine.Vector2,UnityEngine.Vector2,string,string,string,bool,UISkinDef,bool,st ring) ModuleManager.ModuleManager.Awake () (at <cba76a7283cc4ffd86d84aad05dc451d>:0) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) <LoadObjects>d__90:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>d__71:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>d__11:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) LoadingScreen:Start() [LOG 20:30:05.703] [AddonLoader]: Instantiating addon 'ModuleManager' from assembly 'ModuleManager' [LOG 20:30:05.712] [ModuleManager] version 4.1.3.0 at D:\KSP\Kerbal Space Program\GameData\ModuleManager.4.1.3.dll won the election against Version 4.1.3.0 D:\KSP\Kerbal Space Program\GameData\ModuleManager.4.1.4.dll Version 4.1.3.0 D:\KSP\Kerbal Space Program\GameData\ModuleManager.4.2.1.dll And this include a really old one: Mod DLLs found: Stock assembly: Assembly-CSharp v0.0.0.0 ModuleManagerWatchDog v1.0.1.1 Scale_Redist v1.0.0.0 / v2.4.5.9 KSPModFileLocalizer v0.2.3.7 ModuleManager.2.7.5 v2.7.5.0 <------- !!!!!! ModuleManager v4.1.3.0 ModuleManager v4.1.3.0 ModuleManager v4.1.3.0 As we can see from the following log, this very old MM version is running together the newest one! [LOG 20:30:05.698] [AddonLoader]: Instantiating addon 'ModuleManager' from assembly 'ModuleManager' [EXC 20:30:05.703] MissingMethodException: PopupDialog PopupDialog.SpawnPopupDialog(UnityEngine.Vector2,UnityEngine.Vector2,string,string,string,bool,UISkinDef,bool,st ring) ModuleManager.ModuleManager.Awake () (at <cba76a7283cc4ffd86d84aad05dc451d>:0) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) <LoadObjects>d__90:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>d__71:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>d__11:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) LoadingScreen:Start() And, by plain luck, it tries to use something on an old Unity version that it's not available anymore on newer ones - otherwise you would have TWO instances of MM running on your rig, with unforeseeable consequences (as they would be trying to patch everything twice). Being not bad enough a pretty old ModuleManager is being run together newest ones, from the newest the one winning the "election" is the oldest one!!! [LOG 20:30:05.712] [ModuleManager] version 4.1.3.0 at D:\KSP\Kerbal Space Program\GameData\ModuleManager.4.1.3.dll won the election against Version 4.1.3.0 D:\KSP\Kerbal Space Program\GameData\ModuleManager.4.1.4.dll Version 4.1.3.0 D:\KSP\Kerbal Space Program\GameData\ModuleManager.4.2.1.dll I suggest you delete all the Module Manager DLLs from your rig but the newest one, ModuleManager.4.2.1.dll . Really, remove the older Module Managers. There's a newer version from it for a reason - the 4.2.1 release has fixes needed by some add'ons, and you may using one of these add'ons. You have ModuleManager WatchDog installed on your rig… I wonder why it had not barked on this problem…. I also found a file called WatchDog.cfg on your GameData. If this if the file I think it is, this is the wrong place for it. It must be inside ModuleManagerWatchDog folder. I think you have something messed up on installation, because MMWD also didn't found Scale.dll (the TweakScale dll that loads its code)!!! [LOG 20:30:13.204] [WatchDogForScaleRedist] Version 1.0.1.1 /L [LOG 20:30:13.204] [WatchDogForScaleRedist] DETAIL: No clients found. Sanity Check aborted. And this solves the mistery. You have the TweakScale patches installed (I found the folder), but you don't have the Scale.dll installed!!!! So there's no TweakScale code at all on your installment, there's no one to run the scaling data on the part... Reinstall the latest TweakScale and things will scale normally. Additionally, I also found that you installed the Extras directory on your GameData. This is an error - the Extras directory contains patches that can be only applied under determined circumstances, you need to read the README.md inside these directories to know if you need them or not. Again, Remove the GameData/Extras (and read the installing instructions before installing things by hand!). I also found this exception on your KSP.log: [LOG 20:30:12.441] Load(Audio): Bluedog_DB/Sounds/GeminiWhoop [EXC 20:30:12.458] MissingFieldException: Field 'KSPParticleEmitter.pe' not found. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) And this is being repeated a lot on your machine, this in hindering not only the Bluedog_BD parts but also your peformance, as this is being logged hundreds of times per second!!! [EXC 21:33:26.757] MissingFieldException: Field 'KSPParticleEmitter.pe' not found. UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 21:33:26.776] MissingFieldException: Field 'KSPParticleEmitter.pe' not found. I think you have a installation problem on Bluedog too. I suggest you reinstall it from scratch, as well as you need to do with TweakScale! Cheers!

Hi! TweakScale maintainer here. As explained above, I need the KSP.log in order to understand what's going on your game. Post the KSP.log on dropbox or something like that, and then post the link here - from this point , I can help! We believe you! Me, Santa and Easter Bunny!

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!