Lisias

Take an Airliner (of that era) and fly it as it was an barnstormer! The whole vídeo is a source of inspiration for KSP flying! (how I wish we had weather on KSP now - some stunts need winds!) (Someone needs to do a KSP video like this!)

Not to mention that Kraken damned "-h" option, man. Holly Krakens!!! Nope. At least for MacOS, both 1.8.1 and 1.12.3 still present the problem. The GUI gets unbearable by setting the Texture Quality on the Main Menu / Settings / Graphical page.

No. On DU, there's no way to only "include" files, only to exclude them. And on the BSD/MacOS, the option to exclude files is "-I". Don't ask, just accept it. So the way to quickly compute the number of blocks used to store the data (that it's what really matters on time spent on I/O) is to calculate all blocks used on a clean GameData, and then exclude the number of blocks used to store everything but the DDS - and the resulting number is the number of blocks used by the DDS! My initial numbers were completely screwed up because, somehow, the… less then smart… dude that coded the -h (humanise) option thought it would be a good idea to humanising the accumulator itself, and not only the numbers being displayed. This leaded to rounding errors being piled up on the accumulator! Without the -h option I got the real numbers in KBytes, the unit of measure used on the storage blocks. Then I "humanised" the final result myself. I'm o MacOS. On Linux where I think you are working the option is a more reasonable one, "-X". What's a huge problem on MacOS! Safari, Chrome, Firefox… All of these makes heavy use of the VRAM for everything on MacOS, as the whole Aqua GUI makes heavy use of GPU acceleration. So it's best to keep the textures on RAM and upload to VRAM only the ones needed on the current scene - otherwise the whole rig will start to stutter due VRAM dispute - watching tutorial videos while playing KSP can be a challenge due this. What's not a problem when you are selling Fruit Salads. I play KSP, the full package. I don't play "vanilla" KSP. This is not a technical benchmark, this is a study to make KSP more bearable on crappy MacPotatoes and, perhaps, Linux and Windows too. Newer (full) KSP have more features? Yes, they have. But they also loads slower and eat more memory - and these are the constraints I intent to work out. Additionally, with or without more features, what's matter in essence to the problem at hands is not the number of features or the KSP version itself, but the total number of Textures, how much space they use and how much time they need to load. Analysing these data for the best TexCount vs TexSize vs Time To Load ratio, we will find the best compromise possible between all the KSP versions we have around, and I will have a guideline to resize 1.12.3 ones and still keep the Look and Feel I have on the older ones (i.e., the textures will be so crappy as the ones I use now, not crappier). Yes, it's exactly this. The difference is that I'm not using DX11, I'm running Metal or OpenGL (in MacOS). Linux users should be having similar problems, I think - but I don't know Vulkan enough to be sure about. These constrains were implied when I described the rigs being used on these tests - I will detail it further on the OP. Now that I fixed the Disk Space numbers above, let's go back to the original discussion: Nope. You are. I described exactly the environment in which these values are valid. I'm working with the hardware I have at hands and, if I manage to cut it, we can then check if the same measures would be beneficial for Linux users - or perhaps older Window rigs with crappy GPUs (there're a lot of old notebook users around). Linux users can be potentially be beneficed by using BTRFS with transparent compression for storing the KSP files (as I do on APFS). Windows users too, as NTFS also has transparent compression (and it's even easier to set it up). So we already have a common ground to work with. I expect that Linux users may have more or less the same GPU problems I have. On the other hand, Windows users with DX11 will not for sure, as you explained above. On MacOS (and I think Linux too), KSP 1.8.x was an absolute nightmare for performance - but this was due Unity's stupidity. See this thread for the reason - once I applied this trick on my rig, KSP 1.8.1 not only started to perform pretty decently, but also the CPU runs it cooler!! Faster and cooler (at least 2ºC cooler, more on heavy loads). Interestingly enough (and au countraire to what I was thinking at that time), RAM starvation is less than a problem on MacOS due transparent memory compression. As long the current Scene doesn't needs more RAM/VRAM than reasonably available on the rig at the current load, things are working fine here even with a swapfile eating 4 to 6GB of disk space (implying a over commit at least twice that, due transparent memory compression). Switching Scenes can be a pain, though. ReStock is a hell of a nice job. When I added DOE support for it (before they added new PartModules, that then broke the support), I had to check exactly how they were building the parts, and the reuse of meshes on the thing is laudable. It's a class on how to build objects in KSP. But it also changes a lot of things on KSP that I'm not willing to cope right now - not to mention that I still use a lot of add'on that looks better with Stock. Even even ReStock also imposes a lot of overhead on my rig the same Stock does. So instead of doubling my amount of work by trying both Stock and ReStock (as I need to keep that add'ons running too), I choose to go to the easier path and rework Stock textures and call it a day. I can extend the work later for ReStock if someone asks for - assuming the dude/gal will not do it him/herself as I will publish the script that will do that.

Really? Toolbar Icons still get blurry to me… But my memory can playing me tricks, I will double check this now. I had thought on doing it, but concluded that they would not made any significantly diference on the stats - and I like them, as I have some older Add'Ons that rely on them, so it's technically "stock" for me. But I should had explained that on the main text, fixing it. The size of the textures, per se, is not the problem. The medium in which they are stored (spinning disks on my case), the memory available and the CPU are the main bottlenecks. And since my rig is already bottlenecked by dozens of Safari pages, Visual Studio, a bunch of terminals et all, my loadings were (purposely) hindered - my goal is to more or less benchmark KSP on real life conditions. Our PCs are not videogames, we don't reboot the machine just to play a videogame, we just open it the no matter what's already opened on the rig and and that's it. And the current state of the memory pool also tax the process: with so much loads and reloads of KSP, I triggered one of the numerous annoying Kernel Panics on MacOS (seriously, my Mac is never turned off - I reboot it only when there're critical updates, power failures and Kernel Panics - these last ones the more frequent, I really abuse my rig). KSP 1.12.3 was being loaded at 8 minutes more or less, after the reboot it clocked 5! So I had to redo all the timings to keep consistency. On the long run: the timing that matters is the one on your rig. I don't care about how fast you load KSP on your machine, is the loading times on mine that burdens me. I maxed out everything! For all KSPs. All the tests were made with all the graphical settings at max, in all KSP versions. Using Texture Quality at minimum, I think I remember getting similar values as your. The "problem" I was going to measure later (and that you had caught already) is that most people can't use KSP with the Max Settings nowadays, they are intended to 4K GPUs. Nothing wrong on it, absolutely not wrong on it - except by the loading times and storage. IMHO the 4K textures should be offered as a downloadable DLC for people that effectively have 4K GPUs and would make good use of them. In the end, what I intent to do is to write a simple proof of concept by just using ImageMagick to reduce the DDS sizes to more or less what was done on KSP 1.4.5 (really impressed optimisation work, apparently — see below) My stats is always with the full DLCs (when available). Because it's how I use them (this was specified somewhere on that wall of text). But since we're here, let's go for it. Using the same command I did above (du -ah [-I *.dds]): On 1.12.3 I got ~949 MB On 1.11.2 I got ~289 MB On 1.7.3 I got ~192 MB On 1.2.2 I got ~96 MB We have some serious discrepancies here!!!! Let's dig on the 1.2.2 as it's the smaller of the gang. This is how I got into these numbers: HOWEVER… You didn't pulled your numbers from the hat, you calculated it somehow on Windows. And these assets are the same for everybody, so what in hell we are getting here? Looking on that listings again I found some 0B entries. Normal, DU works on disk blocks, and since I'm using APFS that minimises block waste by grouping smaller files into a single block (don't ask how they handle the mess), some files ends up using "0 block", as they were stored on a shared blocked (and only the first entry uses a block on the report). Anyway, let's calculate this crap again, but without the -h option to see the numbers "in raw" So 522800K - 325712K = 197088K = ~192 MB !!!!! DU is screwing me up!!! DAMN!!! I'm fixing that numbers, and then I'll come back to you!

Dude, your guesses were interestingly accurate! Give a peek on the numbers of this post:

While on a discussion about KSP for Mobiles, I remembered how well KSP 1.4.3 (as well KSP 1.3.1) was running on my old MacCrap, a Mid 2011 MacMini 5.1 - i5-2415M (2.3GHz dual-core Intel Core i5 with 3MB on-chip shared L3 cache), 8GB RAM and HD3000 with shared memory, max at 386MB VRAM (i think). Now, on a less older MacCrap, a Late 2012 MacMini 6.2 - I7-3615QM (2.3GHz quad-core Intel Core i7 (Turbo Boost up to 3.3GHz) with 6MB L3 cache), 16GB RAM and HD4000 with shared memory, max at 1536MB IIRC), KSP 1.4.3 runs magnificently. Really, really good. Since I'm running on MacOS, I'm using OpenGL or Metal - and not DirectX. However, this same configuration is just plain terrible for KSP 1.12.3 (besides being not that bad on 1.8.1, just saying). Thinking about, I realised that once you work around Unity's… less then smart  … decisions, any minimally decent budget PC nowadays should be able to run an KSP - as long you restrain yourself from building crafts with hundreds and hundreds of parts, of course. Probably even beefy tablets should do. Problem: memory and loading times. In the same way Unity is sabotaging your CPU by wasting processing on useless loops (spin locks), having 4096x4096 textures when you are using 720p or 1024p tops on your rig is, well, plain waste. But how wasteful is being KSP nowadays for dudes like me playing KSP on Potatoes? Well, someone has to calculate it, and I already spent a good fraction of my day debugging KSP, why not me and today? The whole Circus is already set, anyway. So... The following table depicts the data gathered on a MacMini 6.2, i7, 16GB RAM and HD4000 (1.5GB VRAM shared) under MacOS Mojave (10.14.6). The machine is purposely overloaded, simulating the load I get on KSP when I have that urge to waste a bit of time playing KSP during the day - or just doing a long mission on the second monitor while I work, as it would be a fancy screensaver . Really, whatever I could had done to make the rig's life a misery, I did. All the test beds are running from spinning disks, the times I got from the best of two consecutive runs (to take advantage of the disk caches), absolutely pristine installment. Not even MM is there. The Spread sheet is to big to be pasted here, so here goes the link on Google Docs. And here is the summary: Resolution KSP Version 1.3.1 1.4.3 1.4.5 1.5.1 1.6.1 1.7.3 1.8.1 1.9.1 1.10.1 1.11.2 1.12.3 Part Count: 298 364 364 364 364 414 426 427 438 453 461 DDS Count: 582 705 705 759 804 892 908 848 965 1014 1061 Size onDisk MB: 203 346 347 428 505 605 659 620 755 798 866 Proc Mem GB: 2.37 3.23 3.73 3.69 3.73 6.21 7.1 7.2 7.2 9.87 10.59 Time to Load: 0:01:29 0:01:38 0:01:37 0:01:33 0:01:34 0:01:47 0:01:59 0:01:54 0:02:21 0:05:00 0:05:29 And on the spoiler the values (badly formatted, sorry) for people unwilling to feed Google's craving for personal data. There're a lot of conclusions to be taken from this data set - in particular, the 1.12.3 numbers are terrible (not to mention almost 3 times the disk space for essentially the same material). The measures were made from firing up KSP until the Main Menu is shown by checking the timestamps from KSP.log, from first entry to the timestamp for the ""Scene Change : From LOADING to MAINMENU. Terrain Detail, Scatter Density, Render and Texture Quality are all at tops on the Settings/Graphics. Looking into these numbers, it's perfectly understandable why KSP 1.4.3 and 1.4.5 were my favorites on my older rig. I only managed to play 1.7.3 on the less old one, used to gather these data. I will not even try to get the numbers from my older rig (still available as my secondary professional rig). And as a matter of fact, KSP 1.8.1 once it got stabilised, it's pretty good!! Too bad that at that time I didn't knew about the MONO_THREADS_PER_CPU=1 stunt yet, as this made KSP 1.8.1. and KSP 1.9.1 useable on this rig - but not so much as 1.7.3. These numbers also explain why I essentially waved most of the Add'Ons I was used to use on KSP 1.4.5 era when I jumped over to 1.7.3. Keep in mind that these numbers are for the graphical settings maxed out. Reasonable people will downgrade the Texture Quality to save memory - but the infinite KSP's bugs will bite you if you downgrade too much, as everything is downgraded including the User Interface, and you will get Icons and widgets blurred. Plain terrible, and unacceptable to me, being the reason I intent to use these data I intent to rework the Stock textures to save loading times and memory without using the Texture Quality setting. If I manage to bring KSP 1.12.3 to the same level as KSP 1.7.3 more or less, I may be able to finally start playing something on it - otherwise, I will probably be stuck with 1.9.1 (once I make some optimisations on the damned thing, as I like to use Add'Ons, damn it!). Wish me luck! — — ADDENDUM — — The file system used is Apple's APFS, no deduplication were applied and all relevant directories and their contents were compressed using: find . -name . -type d -exec afsctool -c -v -9 "{}" \; The numbers for the DDS files sorted by resolution were obtained by running this UNIX command on the (clean) GameData of each KSP test bed used: # This one was being fooled by spaces on the pathname! #find . -name "*.dds" -exec identify {} \; | cut -d " " -f 3 | sort -n | uniq -c # This one works as expected! find . -name "*.dds" -exec identify {} \; | sed -nr "s/^(.+) DDS ([0123456789x]+) .*$/\2/p" | sort -n | uniq -c The disk space was calculated subtracting the values given by the following two UNIX commands: du -a du -a -I *.dds There's no way to use du to get the sizes only from files specified by the mask, the mask can be used only to ignore some files. So I got the total value for the whole GameData, and then subtracted from the value given but everything but the DDSs - resulting on the number for the DDSs themselves. The zDeprecated assets were included on the batch. They are not big enough to significantly affect the numbers, and I have a lot of Add'Ons that need them anyway. So I consider them Stock for the purposes of this essay. — — Addendum's Addendum — — DU has royally screwed me up. Using the '-h' (humanise) option is was giving me scrambled numbers, and this invalided all the disk size info above [EDIT: Already fixed]. I'm re-running these values and I'm updating the spreadsheet and later this post. — — addendum's addendum's addendum — — I was fooled by some spaces on the pathnames - I completely forgot Windows programs are used to have it (way less on Unix, but MacOS is a mess on this). I fixed the command lines for a more robust one, and fixed the values. Nothing really changed, but an error is an error - and should be fixed. ------ Note: This is a follow up from this thread, but addressing different problems!

NOTAM I BLEW THIS ONE. It's a TweakScale bug!!! Fixing it on TweakScale (obviously) https://github.com/net-lisias-ksp/KSP-Recall/issues/42 Thanks to @Alexsysby the report! Cheers.

Uh, dude. You got bitten by a nasty KSP bug on a thingy Assembly Resolver yada yada yada. TL;DR. when something borks being loaded due a faulty dependence, everything else trying to load something (or to use a thingy called Reflection) borks relentlessly due the bug. And since TweakScale makes heavy and critical use of exactly these two things. TweakScale yells when it detects this happened (because a faulty TweakScale will ruin your whole savegame). On your rig, the problem is a old release of Firespitter: [ERR 13:01:28.990] [AssemblyLoader] Exception when getting assembly attributes: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. Additional information about this exception: System.TypeLoadException: Could not load type of field 'Firespitter.FSparticleFX:pEmitter' (4) due to: Could not resolve type with token 01000057 (from typeref, cl System.TypeLoadException: Invalid type Firespitter.FSparticleFX for instance field Firespitter.engine.FSgroundParticles:particleFX System.TypeLoadException: Invalid type Firespitter.FSparticleFX[] for instance field Firespitter.engine.FSvelocityController:particleFX When KSP migrated from Unity 2017 to Unity 2019, some older code that was still relying on deprecated assets on 2017 broke on 2019 because the deprecated things were, well, removed. Firespitter is one of these. The latest Firespitter has this solved - update it and the problem will go away.

The Martin P6M SeaMaster A Flying Boat that was a Bomber. And that was planned to be nuclear powered. o.O https://en.wikipedia.org/wiki/Martin_P6M_SeaMaster]

Well, I took some time but built a KSP 1.12.2 test bed for your case. You are using KSP 1.12.0, but I don't have a working 1.12.0 available anymore, so let's check things on 1.12.2 - worst case scenario, I rebuild a 1.12.0 test bed on the weekend. From the TweakScale point of view, yes. Not using these parts will not trigger anything on TweakScale - but these parts will be there lingering and waiting you forget about and use them by accident. But ince they are blowing up Exceptions when TweakScale is installed (or besides TweakScale being installed), it's better to just remove TweakScale from them. If the error persists, at least we will have one less variable to worry about. In a way or another, I just fired up KSP 1.12.2 with the latest KSPIE (1.29.6) and found no issues on my rig. Worst, I didn't found any parts with the same name from the ones borking on your KSP.log, these parts are just not on my rig. However, looking for them I found this recent issue with the exact same problem you have among others, and by comparing this rig with yours and mine. I had noted that you both have something called Interstellar Technologies (I dumbly assumed it was part of KSPIE, but it doesn't) - and, in time, nice part set! I wish I had paid more attention to @ttr's KSP.log and noted it sooner! Oukey. Downloading it and installing it too. Anyway, since the Interstellar Techonologies package is a bit old, I removed everything, installed the latest KSPIE and then only the InterstellarTechnologies one (avoiding overwriting newer versions with older), except by TweakScale, that it's up to date on that rig (newer version than the one on KSPIE). And… I finally reproduced your program on my test bed. Oh, well… @ttr you need to see this, I misdiagnosed your case. My apologies. Right now, I don't have the slightest clue about the reason this is happening. What I know for sure is that the TweakScale data on the ConfigCache is valid, so no problems related to TweakScale will happen because of this. I can only register what's happening in order in the hope of helping anyone from Interstellar Technologies to diagnose the root cause: [LOG 21:14:55.289] [TweakScale] ERROR: part=Interstellar-Technologies.AMCatGasdynamicMirror (KSPIT KR-342 AM Cat. Gasdynamic Mirror Cell Fusion Drive) Exception on at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x00000] in <8861f4ca916d41ddac4d879a32ad34b2>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <8861f4ca916d41ddac4d879a32ad34b2>:0 at ConfigNode.CopyToRecursive (ConfigNode node, System.Boolean overwrite) [0x0014a] in <8861f4ca916d41ddac4d879a32ad34b2>:0 at ConfigNode.CreateCopy () [0x00006] in <8861f4ca916d41ddac4d879a32ad34b2>:0 at GameDatabase.GetConfigNode (System.String url) [0x0002f] in <8861f4ca916d41ddac4d879a32ad34b2>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (Part p) [0x0002a] in <126b44db42594e4685eedd1483b9eaa0>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (Part p) [0x00000] in <126b44db42594e4685eedd1483b9eaa0>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00417] in <126b44db42594e4685eedd1483b9eaa0>:0 at error:0 The problem is on the CopyToRecursive method. Apparently, when we ask the GameDatabase for the ConfigNode using GetConfigNode, it internally gives us a deep copy of the object (to protect the original data from being mangled, probably). And by some reason, this ConfigNode is missing, corrupted or incomplete on the Main Menu scene. How this happens is a mystery to me. Interstellar Technologies is a parts only add'on, no code - all the code is on KSPIE, that doesn't behaves like that on its own parts. You (and @ttr) will need to reach both IT and KSPIE maintainers for further help on diagnosing this one - even by being something I can do on TweskScale, I need to know what's happening first. Alternativelly…. You can apply this WorkAround on your GAMEDATA (I suggest GameData/__LOCAL for easy finding it later and avoid deleting it by accident). — — WORK AROUND — — Work Around: Download Extras/TweakScale/Workarounds/InterstellarTechnologies.cfg Click on the Raw button, see image below*. This file will be included on the next TweakScale release package. Save the file into yours GameData/__LOCAL/TweakScale/Workarounds folder. Restart KSP *"image below" Source: https://github.com/net-lisias-ksp/TweakScale/issues/245

The refining was OK IMHO. The never fixed bugs on the codebase are the culprits. Had the Texture Quality be correctly implemented, you could just reduce the Texture Quality and keep playing normally. Proof of Concept: make a full backup of the whole KSP 1.12.3 installment and on the copy, run ImageMagick resizing all DDS files with more than 64x64 pixels to 75% or even 50% and then go for a test drive on your old rig. If you trimm the resizing to use the better algorithm for each image (some complex textures look bad on the fastest ones), you will get a significantly enhancement in the performance without too much impact (if ever, if you are really on a Potato like me) on the Visuals. The ground texturing is also a CPU hog nowadays -by the way. I don't think the extra burden on my rig worths the visual enhancements, but that thing is locked on high qualify no matter the setting I use. Apparently the increased size of the PQS cache on 1.4.4 screwed me up royally on my old MacCrap. I would had made good use of an option to set the size of the PQS cache to the one used by 1.4.3. --- POST EDIT --- In a nutshell, right now I have a computer with twice the cores, twice the RAM e 3 times more VRAM and yet KSP 1.12.x performs 4 times worst then KSP 1.4.3 running on my original machine. I used to get 60 FPS on small crafts on the older rig. Now I get 15 to 20 tops on the Space Center. Loading a simple craft into flight drops the FPS to 13 or 14 - with blurry graphics, because I had to lower the texture quality and it screws up the User Interface.

KSP 1.4.3 runs absolutely fine on 2012 hardware (if you max out the memory, it's nearly perfect). The worst bottleneck since KSP 1.8.0 are the crappy Unity handling of threads (busy waits everywhere - also known as spin-locks) and the Parts revamp that nearly doubled the RAM and VRAM consuption without functional gains (and with the UI bug applying mipmaps on GUI glyphs, lowering the texture quality renders the UI nearly unusable).

I don't know if the root cause has a solution. IIRC, the problem is the low precision of the floats used on the physics engine. As you distance yourself from the craft, the lack of precision of the floats starts to kick, and on one of these unavoidable roundings your collider would unduly hit another collider and then… BADA-BOOM…. When you had to add or increment the float's exponent, you lose an entire order of magnitude of the available precision. More than enough to make touching colliders to "invade" each others space and trigger a catastrophic event.

Yay, it's some time since the last time someone reported one of these… I think more than an year.. Well, I need the full KSP.log in order to check what's happening. The parts you quoted are only telling me what happened, but not where and why - only the KSP.log has these informations. Publish the whole thingy on dropbox or something and post the link here. What I can say for sure is that someone else is borking when TweakScale checks its data on the Main Menu. Most of the time this happens because some other PartModule has inconsistent data on their own module data and borks when TweakScale "awakes" the Part to check the TweakScale's module data consistency and probing the total mass and the resources' mass in order to calculate the dry mass of that part (I need to calculate the dry mass of everything, so checking for problems is essentially cost free at this point). Most of the time is due a faulty dependency, more likely patches - some parts ends up partially patched and when you try to use the parts, they blow up. In a way or another, the answer is on the KSP.log - I can't say I can fix them, I'll probably code a WorkAround to remove TweakScale from these parts to prevent TweakScale from touching them.

Today I decided that it's more than due time to play Blimps on KSP 1.12.3. So I updated Hooligan Labs Airships to it! Parts that were problematic (sinking on KSP 1.3.1, being skyrocket on KSP 1.4 to 1.11 or just blowing up in KSP 1.12) were fixed and they are now working flawlessly… From KSP 1.3.1 to 1.12.3 , no savegame was left behind! Ascending on the kerbal way!!! Craft available on Kerbal-X and on my site. A Release Candidate for HLAirships is available on this thread.

ANNOUNCE Pre Release 7.0.0.2 **BETA** is available for downloading, with the following changes: Revamping parts: HL_AirshipEnvelop HL_AirshipEnvelop_Octp HL_AirshipEnvelop_Hecto HL_AirshipEnvelop_LudoBlimp OMG_Airhips (DeathStarBattery) No need anymore for World Stabiliser and the parts are fully functional on KSP 1.12.3 Added HLAirships Watch Dog to prevent installations mishaps and some other problems plaguing KSP. New Sample Craft (Panorama Blimp) This is a PRE RELEASE, with controlled distribution. Pending formal agreement from the upstream for relicensing. See OP for the links. Notes You need to download the latest full release of HLAirships and remove the folders GameData/HLAirships/Parts/Aero/AirshipCap GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope_Cirrus GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope_Cirrus_Real GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope_Dodec GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope_Hecto GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope_LudoBlimp GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope_Octo GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope_Ray GameData/HLAirships/Parts/Aero/HL_AirshipEnvelope_Una GameData/HLAirships/Parts/Aero/OMG Airship GameData/HLAirships/Parts/Aero/Probe Envelope GameData/HLAirships/Parts/TweakScale.cfg GameData/HLAirships/Plugins in order to use Core with the full set of HL Airships parts. When Core **BETA** is installed together HLAirships (full), the Parts from the Core will be deactivated in favour of the full package (so you need to remove any older assets from it). TweakScale support will not be affected. I expect this is the last Release Candidate (and also the last one that needs the KSPe installed, see the Release Notes on the Download Link from Github). If everything goes as I expect, the next release to be published (hopefully) before the Weekend, and then merged into HLAirships (Redux?). — — — — — This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. On Hooligan Labs Mods. Will not be published yet, as this is still **BETA**.

Nice view! Nice launch! Nice rig! My own moaned in despair just on displaying it on a browser!! (keep your fans clean and use good thermal paste - my MacPotato started to run almost 8ºC cooler last time I did this)

We are open for business!!!!

Time!!! If you know someone selling it, I'm buying!!!!

This is something that I had already spent a lot of time figuring out. What happened: on KSP 1.4.0 a thingy called "Physics Easing" (or something like that) was introduced. I don't know exactly why it was introduced (perhaps to tackle down the problem of Ground Bases being kicked into the air sometimes?), but I know that when some requirements are met (and AirPark by accident triggers them), the thingy is slowly dragged down into the ground (or something with colliders, whatever is hit first - but I need to check that code, it's some time since I looked on it). I managed to force my hand on the thing on one Part (the root) of the craft, and it apparently worked - but the Physics Easing kept acting on the remaining parts, and this ends with craft being ripped apart. Then my time window for the stunt ended, and I didn't came back to it yet. I would love to find a way to turn off the Physics Easing for a craft. This would help the issue a lot.

I was bitten by a nasty KSP bug on a thingy called Assembly Resolver. Something else has borked a dependency, and when this happens, everything and the kitchen's sink start to bork too when loading DLLs or using Reflection, two things that TweakScale does a lot. Post your FULL KSP.LOG here and I will inspect it looking for who is causing the troubles.

ANNOUNCE Pre Release 7.0.0.1 **BETA** is available for downloading, with the following changes: Enhanced TweakScale Support Part fixing bulkheadProfiles on the parts descriptions AirshipCap texture now on the right orientation! Code Better resilience on some key features Somewhat better KSP 1.12.x survivability Small improvements on the PAW Caveats Some parts (temporarily) deactivated on KSP 1.12.x Some parts needs World Stabiliser on [1.4.0 <= KSP <= 1.11.3] See Issue #2 for details Compatibility extended down to KSP 1.3.1!!! #HURRAY!! Cleaning up the distribution from ARR artefacts Only parts and assets derived from the last known MIT release, HooliganLabsAirships-3.0.0, are available from now on Core. Full assets will be available when downloading the full package from Hooligan Labs Mods. This is a PRE RELEASE, with controlled distribution. Pending formal agreement from the upstream for relicensing. See OP for the links. Notes You need to download the latest full release of HLAirships and remove the folder GameData/HLAirships/Plugins in order to use Core. When Core **BETA** is installed together HLAirships (full), the Parts from the Core will be deactivated in favour of full package. This is expected to change on the next full release of the HLAirships (full). TweakScale support will not be affected. — — — — — This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. On Hooligan Labs Mods. Will not be published yet, as this is still **BETA**.

Announce! Hooligan Labs Airships Core is available in early access on this thread. Hooligan Labs Airships CORE is a joint initiative from @JewelShisen and @Lisias to push Hooligan Labs Airships ahead while maintaining compatibility with KSP from 1.3.x era to nowadays (or providing an additional package for such, if needed).Core will be in charge of the Plugin Development and a minimal set of assets (the ones from the 3.0.0.0 release). Everything else will be available only on the full package, to be distributed on this thread — — POST EDIT — — Core Release Candidate 7.0.0.2 was published for the early adopters!

Hooligan Labs Airships CORE is a joint initiative from @JewelShisen and @Lisiasto push Hooligan Labs Airships ahead while maintaining compatibility with KSP from 1.3.x era to nowadays (or providing an additional package for such, if needed). In a Hurry: Current Release: 7.0.1.0 for KSP >= 1.3 (2022-0503) It works from KSP 1.3.1 to KSP 1.12.3! Seriously! How to check Compatibility on CurseForge. IMPORTANT This release TEMPORARILY needs the latest KSPe installed. The final release will be shipped with KSPe.Light embedded. Module Manager is needed for handling the patches. Read this post before updating! Announce for 7.0.0.1 Announce for 7.0.0.2 7.0.0.3 never happened… Announce for 7.0.0.4 Downloads on GitHub (for early adopters and beta testers) on SpaceDock. On HooliganLabs Mods for the full package. (eventually) Description: HLAirshipsCore (for shorts) will be in charge of the Plugin Development and by keeping in working condition a minimal set of assets (all of them from the 3.0.0 release times, under the MIT). Further developments may happen on Core, as well on eventual new spinoffs of the franchise. Hooligan Labs Mods will keep the distribution of the official packages, as well suggestions for new feature and similar stuff. HLAirshipsCore (this thread) will be in charge of issue tracking and bug hunting - as well beta releases for early adopters that don't fear the Krakens and are willing to Livin' La Vida Loca on the bleeding edge! License: Hooligan Labs Airships Core is licensed under the MIT (Expat), as HLA was originally. Assets from HLAirships other than the ones currently on Core are not covered by this license agreement. Float Safe!!