Lisias

Hi! I tried to reach you without success, so I'm posting this here as a remind to myself about the issue. Without the KSP.log, my hands are tied. The information I need to diagnose the problem is on KSP.log , and not on any other log. The ModuleManager log is pretty useless for this one. (and you need to authorise me to access the log anyway, or I will not be able to download it! Please remember to turn the thing public next time!) cheers!

Using kitchen salt and candies as rocket fuel! _ "Dr Khermann, we run out of LFO!!!" _ "Keine Probleme bekannt, call the Chief in the kitchen..." In the background, Jeb yells "Get your greasy hands out of my snacks!!!!"

Locking up the joint to prevent a jacknife effect is something very kerbal, indeed!

Today is this one. Lucky Man, The Verve.

1980'a racing. Dutch style!! (some close calls, by the way - you need to have more guts to watch the race than running on it!) This is how Kerbals should do a Race!!!

It's something that I need to figure out. On KSP, the buoyancy of a part is derived from a thingy called Drag Cube. The Drag Cube is, well, a "virtual cube" used by the physics engine to calculate the drag of a part - doing proper drag calculation based on the real shape of the collider is cumbersome and costly, so the game developers choose to use a shortcut by using the DragCubes. It works, by the way, this is not a complain. However, when the devs implemented buoyancy, they also calculated it using the drag cubes and this starts to be a problem when you scale the part, because you need to scale the drag cubes too otherwise the thingy will have the same drag as it had before being scaled up! (and yeah, this is a complain! ). Look, this is what happens: So, in order to scale things "properly", I need to figure out a way to "decrease" the buoyancy attribute of the part as I scale up and down the damned drag cubes in order to preserve the original buoyancy of the part!

It depends if you have a discrete GPU, or are using a shared memory one. If you have a notebook with 8GB and a discrete GPU with 2GB of RAM, you will be fine as long you lower the Texture Quality a bit. However, most of us (including me) are using a shared memory mobile GPU, and this means that part of the CPU's memory is borrowed to be used by the GPU, and so 8GB is not enough - because you will "lose" part of the memory. If you are using an i3 with HD Intel graphics, you will lost up to 1.5GB of RAM, but if you are an i3 with UHD you can lose up to half the CPU's memory to it. In a way or another, keep an eye on the VRAM consumption and never allows it to exhaust. When this happens, the GPU driver starts to use the CPU's RAM to store the extra textures and this makes everything absolutely terrible - your FPS will plummet. You can have a decent game play even using a CPU with HD3000 graphics as long you manage to keep the GPU's VRAM usage under 384MB (that it's the maxium VRAM used by a HD3000 GPU)!

Just passing by to thanks the nomination (and clicking on the Submit this time!!) - before I forget to do it again. I having some wild weeks due a lot of things on Real Life, but I'm still around - besides now and then I post something but forget to click "Submit"… Cheers!

You have a terrible installation problem! [LOG 20:04:14.623] Load(Assembly): Airplane_Plus-26.5 (1)/GameData/ModuleManager.4.1.3 [LOG 20:04:14.624] AssemblyLoader: Loading assembly at D:\New folder\steamapps\common\Kerbal Space Program\GameData\Airplane_Plus-26.5 (1)\GameData\ModuleManager.4.1.3.dll And this is only one of the problems I found - there're too many to list here. For starters, completely remove the folder Airplane_Plus-26.5 (1) from your GameData. If by removing this folder, you still get errors, send me a new KSP.log and I will check it.

It's BARISBridge again! [ERR 21:20:01.952] AssemblyLoader: Exception loading 'Buffalo': System.Reflection.ReflectionTypeLoadException: Exception of type 'System.Reflection.ReflectionTypeLoadException' was thrown. at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(System.Reflection.Assembly,bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at AssemblyLoader.LoadAssemblies () [0x000e6] in <39c0323fb6b449a4aaf3465c00ed3c8d>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'BARISBridge, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'BARISBridge, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' I think we already had diagnosed that before, I'm pretty sure this is not the first time you reported this one - I think you are being hit by one of the bad practices from the Scene, shoving all the dependencies on the same ZIP. You probably installed a add'on that have an older DLL of Buffalo, and that DLL still needs the BARIS.

A new beta release was published for the early adopters and fellow Kerbonauts willing to fly on the bleeding edge and don't fear the Krakens! https://github.com/net-lisias-ksp/HLAirshipsCore/releases/tag/RELEASE%2F7.0.1.4 Lots of fixes related to attachment nodes, and one on the Category (some things were broken when installed together the legacy HLA 6.4). About the attachment nodes, in special on the HL Envelope ones (Hecto, Octo, and normal), you now will need to press ALT if you want to attach the Envelope "laterally", as now you will have the assistance of two more convenient Stack Nodes for this task. Without pressing ALT people used to the previous "attachement system" will get the thing shifted 90°. This happens because I fixed the node that is means to attach Gondolas! From now on, it will be way more easier to build your craft from the Command Pod towards the Envelopes, instead of starting on the Envelopes due the messed up attachment node. Thanks for the @ColdJ for the tip, I kept this cooking for 3 months until I finally had the time to spend on tinkering the thing! Additionally, from now on I finally got my .. hum… things together and created a proper KSP 1.12.3 test bed without KSPe - I should had done this before, to tell you the true. I took so long to realise the mishap fixed on 7.0.1.0R2 because I had KSPe installed everywhere here, and forgot to remove it on some test beds after a lot of bug hunt sessions I did in the last months... Well, MacOS nowadays use a CopyOnWrite approach while copying folders and files on the filesystem, so I really have no excuses to had failed on creating a proper Teste Bed for Releases, instead of blindly trusting the tests made on the development test beds (that are able to detect functional problems, but not environmental ones as that one…). Cheers!

On Milesto 2.2.0.0 , I will dedicate this one to support parts still not supported on Stock, and to reevaluate ReStock to see what they changed on it and implement. https://github.com/net-lisias-ksp/DistantObject/milestones/2.2.0.0

As a matter of fact… I had! Sorry! How it is behaving with TweakScale? Let me know if you find anything behaving weirdly!

Yes, it is - this last release paved the way for new features related to this. In fact, I have a similar request already scheduled : https://github.com/net-lisias-ksp/DistantObject/issues/9 , and once this one is implemented, yours will be trivial! And now it's scheduled too : https://github.com/net-lisias-ksp/DistantObject/issues/22 As a matter of fact, I will have more trouble cooking up a options menu for these two features than implementing your suggestion (onde #9 is done, of course). The 2.1.2.0 milestone is the next one to be worked out, and besides I'm not being able to give you a deadline (that would be overrun anyway, as deadlines always do on KSP! ), I can tell you I will work on it as soon as Real Life allows. It's the third on my queue list (after the next releases of HLA and TweakScale)

Hi! Known problem. What happens is that KSP uses the drag cubes to calculate the buoyancy, and TweakScale needs to scale the drag cubes otherwise the parts will not behave as expected while flying. It's a catch 22 situation. I'm trying to workaround the situation on this issue: https://github.com/net-lisias-ksp/TweakScale/issues/252 Firespitter has a PartModule for buoyancy and, together the TweakScale Companion for Firespitter, perhaps it can be of use?

I may have a dull, thick head - but once the correct information finally passes through, things happen fast! I'm finishing proper testings for the 7.0.1.0R2 with this punctual problem fixed, and I will publish it on SpaceDock in the next hour tops! — POST EDIT — Done. SpaceDock (and CKAN) is updated to 7.0.1.0R2 .

You are right! @Reylan, I think this explains your case too. Somehow, the binary I uploaded to github (and later to SpaceDock) as 7.0.1.0 was compiled against KSPe (full), but the VS project file committed and tagged to 7.0.1.0 is telling me that it should had been compiled against KSPe.Light.HLAirships.dll . A short term workaround is to install KSPe - https://github.com/net-lisias-ksp/KSPe/releases . But this is not the agreement I have with Jewel Shisen, HLAirshipsCode should not have external dependencies on Releases. I'm trying to understand what happened, I will come back to you guys ASAP. I will have this fixed as soon as I understand what krakens gone wrong on this. — — POST EDIT — — Found the problem, but didn't understood what happened yet. I didn't messed up this time, it's something wrong on the building stack. The project is telling VS to compile against the KSPe.Light.HLAirships, but by some reason beyound me the DLL is looking for KSPe itself instead!!! — — POST POST EDIT — — Found the mishap. I forgot the KSP Dependencies tags on the AssemblyInfo.cs …

Yep, now I see. There's really something missing in your screenshots. Looking into your KSP.log, I found this: [LOG 16:13:22.678] PartLoader: Compiling Part 'HLAirshipsCore/Parts/Aero/HL_AirshipEnvelope/part/HL_AirshipEnvelope' [ERR 16:13:22.682] Cannot find a PartModule of typename 'HLEnvelopePartModule' And this repeats on every HLAirshipCore part, what implies that HLAirshipsCore DLL was not loaded. What is effectivelly happening: [WRN 16:10:47.161] AssemblyLoader: Assembly 'HLA.WatchDog' has not met dependency 'KSPe' V2.4.0 [WRN 16:10:47.161] AssemblyLoader: Assembly 'HLA.WatchDog' has not met dependency 'KSPe.UI' V2.4.0 [WRN 16:10:47.161] AssemblyLoader: Assembly 'HLA.WatchDog' is missing 2 dependencies [WRN 16:10:47.161] AssemblyLoader: Assembly 'HLAirShips' has not met dependency 'KSPe' V2.4.0 [WRN 16:10:47.161] AssemblyLoader: Assembly 'HLAirShips' has not met dependency 'KSPe.UI' V2.4.0 [WRN 16:10:47.161] AssemblyLoader: Assembly 'HLAirShips' is missing 2 dependencies You are using a beta release of HLAirhips, not the one published on SpaceDock and CKAN. The Beta releases are compiled against KSPe, and you need to have the latest one installed in order to use the Beta releases, you can find it here: https://github.com/net-lisias-ksp/KSPe/releases . However.. Are you really sure you need to install a Beta Release? I'm fixing a thingy or two on them, but most of the mishaps I'm fixing are related to coexistence with the (AFAIK deprecated) HLAirships 6.4 . You are welcome to "go beta" if you want, but if the current Release (available on CKAN and SpaceDock) works for you, you may want to stick on it and save the hassle of manually updating things. As a matter of fact, while checking your issue, I detected I had committed some typos on the latest betas release and I will issue yet a new Beta Release today or tomorrow... In time… There're a lot of NRE on a lot of your parts. This is hindering your game, as these parts are not usesable and you can't know what parts are affected or not. You may want to seek for help on them, the are verry numerous to list here but by opening your KSP.log and looking for NullReferenceException . GU_Parts, TAC, WildBlueIndustries and MKShuttle are some of them - what suggests that there are someone else screwing up things for everybody. Unfortunately, I don't have the time to keep digging this one for you… Sorry. I'm reasonably confident you got the same issue above! Send me the KSP.log so I can be sure. Cheers! — POST EDIT — It was a mishap on the AssemblyInfo.cs file! See below!

Talking about interesting gunshots, this one if from the F/A-18 at night! Source.

Send me your full KSP.log after reproducing the problem (be sure to quit KSP - or at least to go to the main menu - so KSP will not truncate the log). I need to check what's installed on your rig in order to have an idea (please send me the KSP.log, not the Unity's output log). Additionally, send me also a screenshot where the icon is not present, but should. And.. Who's KOG?

Could not reproduce it on Stock+TweakScale. This is what I did: Created a missile: Probodobodune OKTO scaled down to 0.313m Small Nose Cone scaled down to 0.313m Rockomax Jumbo-64 Fuel Tank, scaled down to 0.313m LV-T45 Swiwel LFO Engine, unsurprisingly also scaled down to 0.313m Called the thingy "Missile" while saving it. Loaded an Stock ship called Aeris 3A Shoved a TT-38K Radial Decoupler on her back (and scaled it to 50%) Load/Merged the Missile craft and attached it to the TT38K. The missile's fuel tank had (the correct amount of) fuel after merging it. I launched the Aeris, took of and while airborne launched the missile. I could control it normally - at least after about a minute after the fuel is exhausted, as the internal battery drained and I lost control of the thingy. Flawless. I think you have some bad interaction with some of the add'ons you are using. I will use your KSP.log and craft file on a test session - but probably on the weekend (perhaps sooner, if I get lucky and dayjob gives me a break). <post merged by forum> Well… I was right. About the subassembly bug… It's not TweakScale, it's KSP. KSP-Recall tries to workaround it, but it only works with subassemblies that already have the KSP-Recall PartModules installed. Check this post for details, I found that by loading the SubAssembly using craft managed and then saving it again as a subasembly, the KSP-Recall part-modules are correctly added to the parts! https://forum.kerbalspaceprogram.com/index.php?/topic/192048-18/&do=findComment&comment=4150351

Use DropBox, Google Drive or similar service, and then paste the link here!

Oukey, I found the reason. Or reasons... I made a pretty lame mistake on my personal fork for MM/L that ended up breaking it when used on… 1.2.2 . I fixed it and published it on github. disclaimer to the general audience: if you don't know what's MM/L, it's because you don't need it! KSPe.Light. I forgot that the HLA Release was compiled against KSPe.Light, and this thingy is tied to KSP > 1.4.3 and Unity >= 2019. KSPe (the full package, distributed on its own zip) is the one that knows how to seamlessly handle different KSP and Unity versions. You would need to have KSPe installed on your KSP 1.2.2 and/or 1.3.0, and have HLA binaries compiled against it - not the one being published on SpaceDock (as this is compiled against KSPe.Light) On the bright side, I was apparently right - the thing appears to work on KSP 1.2.2 (and, so, on KSP 1.3.0 - as it works on 1.3.1 for sure) once you compile it against KSPe (full). I still need time to do a full playing test session on it though - not throwing exceptions on loading is not enough, I will try to do something about on the weekend.

Incredibly kerbal!!! This thing must have a Inline Stabilizer somewhere inside...

Send me a minimum craft file where the problem can be reproduced, as well the KSP.log with the problem being reproduced. (rememeber to quit KSP before taking the log, to avoid having it truncated - or you can just quit to main menu, as by that time anything that would be truncated is not relevant to the problem at hands!).