Lisias

NOTAM Well, that was unexpected. It's not exactly news that TweakScale suffered some regressions recently when I removed some "gambiarras" from the code tree. The rationally was simple: I was (potentially) screwing up 3rd parties the same way KSP-Editor was screwing up TweakScale - not exactly a nice move, and a sure source of headaches in the long run. One of the problems I unleashed confused me because it was causing misbehaviours downto KSP 1.4.3, where KSP Editor should be behaving since the Editor's problems started to bite TweakScale on KSP 1.9.x . I was wrong. The KSP Editor problems started to happen on KSP 1.4.3 (probably on KSP 1.4.2, the Brief) and me, without being aware, shoved a brute-force solution directly on TweakScale. When 1.9.x's Editor broke TweakScale again I thought it was the first time, and then I decided to write KSP-Recall to counter-screw the Stock's misbehaviours. By moving the counter-screws from TweakScale, I resurrected the problem on KSP versions that I thought was Screw Ups free - and then concluded that I had removed something I shouldn't, but could not find what as by "fixing" things on 1.4.3 I got back the screwups on KSP >= 1.9: it's hard to fix a bug that doesn't exists! Well, aftermath: KSP Recall 0.3.0.2 was released, shoving AttachedOnEditor on parts' SAS downto KSP 1.4.3. So, yeah, it's official. The last KSP version really "almost" bug free is, indeed, 1.3.1 I lost weeks (mainly due time scarcity) chasing my damned tail on TweakScale bugs that don't exist, instead of diagnosing the ones that really do. Again. Next TweakScale release will demand KSP Recall from KSP 1.4.3 and upwards. Annoying, I agree. But it's the less bitter solution from the range of possible solutions. In a way or another, how much KSP < 1.8 players like me are still around? On the bright side, TweakScale's code base will probably have another cleanup. There're good chances that the few remaining "gambiarras" can also be tracked down to some still unknown pretty old KSP's idiosyncrasies that at that time I misdiagnosed as TweakScale's problems. And "gambiarras" don't pile up nicely, I can assure you.

ANNOUNCE KSP Recall 0.3.0.2 KSP Recall 0.3.0.3 on the Wild, featuring: After some weeks of denying, it was finally realised that AttachedOnEditor is needed downto KSP 1.4.3 - on the very first ModulePartVariant implementation. Fixes a small brain fart of mine on the INSTALL.md file. Updates KSPe.Light to the latest release (2.4.2.1 at this time) Closes issues: #55 The KSP Editor is screwing things since 1.4.3 #50 Not sure how to install 0.3.0.0 Thanks to @tomtheisen for the heads up! On 0.3.0.3, an annoying warning was fixed - the AttachedOnEditor thing is now intended to be installed downto 1.4.3, the warning was bogus. It's unlikely that this release will be of use for too much people, I don't thing there's many people using KSP as old as 1.4.3 as me - but a fix is a fix, and I lost some time chasing my tail on this krap anyway, so published it was. While trying to diagnose a regression on TweakScale, I tracked down the problem downto KSP 1.4.3 . Since it was current knowledge that KSP 1.9.x was the one that screwed the Editor, I convinced my self that I had somehow screwed the craft load on TweakScale somehow. Only after exhausting all possibilities that a certain aspect of the misbehaviour was TweakScale's fault that I realised that the problem at hands may be, in true, two different problems - being one of them our old friend KSP Editor screwing up crafts on load. So, yeah, I was wrong - KSP 1.9.x did something new on Editor que at that time had screwed again TweakScale, but the origin of the problem was KSP 1.4.3 (or 1.4.2, the Brief?), with the very first implementation of the ModulePartVariants. I'm not exactly thrilled but the discovery, but it explains why TweakScale was, until recently, potentially screwing up 3rd parties the same way it as being screwed by KSP Editor: I was playing tug-of-war with KSP Editor since 1.4.3 on TS's code. As result, KSP-Recall is needed downto KSP 1.4.3 now. Oh, well… Better late than never - they say. — — — — — This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right Now. CurseForge. Right Now. SpaceDock (and CKAN users). Right Now. Being a minor, bug fixing release, all Distribution Channels were updated at once.

Alternatively, you can deactivate the DOE's SkyBox Dimmer! It's called "SkyBox Dimming" on the DOE's Setting window. Cheers!

You need to install KIS! [ERR 20:24:48.806] ADDON BINDER: Cannot resolve assembly: KIS, Culture=neutral, PublicKeyToken=null [ERR 20:24:48.810] AssemblyLoader: Exception loading 'SuperKerbal': System.Reflection.ReflectionTypeLoadException: Exception o f 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 'KIS, Version=1.20.7062.41416, Culture=neutral, PublicKeyTok en=null' or one of its dependencies. File name: 'KIS, Version=1.20.7062.41416, Culture=neutral, PublicKeyToken=null' Cheers!

Found this one today. Not bad! Lasciate ogni speranza voi che entrate - Nueva Era

ANNOUNCE Release 0.6.0.0 BETA is available for the brave Kerbonauts that don't fear infuriating the Krakens by taking selfies with them! No crashes, no dumps, no Exceptions on the KSP.log to this moment. But other that accepting Contracts and fooling around with Tourists on the KSC, not too much was tested. This is a significantly huge release, with the following changes: Enhancements since the last official release: Full support from KSP 1.3.1 to the latest. #HONEST!! Support for RealChutes For KSP < 1.6, KIS is needed to allow removing Helmets. Added a new ability: SkyDive Rebalance of the abilities for each Tourist Level Allowing Tourists to remove the helmet when they can EVA on KSP >= 1.6 MOAR CONTRACTS Swimming contracts for Bodies with Ocean And lots of Anomalies added to Contracts. (more to come) No Spoilers!! Anomaly Contracts are only issued after you scan then on KerbNet! No-nonsense requirements You will not be offered a Contract to a Celestial Body unless you had gone there (and came back in one piece!) You must had landed there in order to get a Walk contract. You must had splashed there in order to get a Swim contract. Rep Farming Contracts Low payment, heavy work contracts for recovering your reputation! if you are lucky to get them! Configurable requirements (Points of Interest and Celestial Body Accomplishments). Bug fixes: Memory Leaks removed! Mitigating (not properly fixing, however) an issue where the Selfies where being taken too soon and not registering the Kerbal’s emotions. Surviving KSP’s Upgrade(Update?) Pipeline Tourists restrictions are not lost anymore on loading savegames Tourists on External Command Seats (or similar parts) are now correctly handled. Including the ability to take selfies. Contracts for absent Anomalies are not issued Planet Packs (as JNSQ) that remove/change the Anomalies are not a problem anymore Contracts tailored for Planet Packs are now possible! Known Issues: SkyDivers will poof if they go beyound the Physics Range of the focused vessel. #3 The Contract payments don’t scale with the difficulty, they are a flat rate. #4 Support for EVA Fuel/Enhancements/Follower are temporarily disabled. #8 Closes issues: #2 Prevent creating Contracts for absent Anomalies See OP for the links. — — — — — This Release will be published using the following Schedule: GitHub. Right Now. CurseForge. Hopefully Soon SpaceDock. Eventually! Lasciate ogni speranza, voi che entrate This is a beta release for testing and troubleshooting, not meant for wide public consumption. Bugs and mishaps are expected, do not use it on valuable savegames! Use at your own risk. Your attention please You need (temporarily) to install the latest release of KSPe in order to have this release working on your rig: https://github.com/net-lisias-ksp/KSPe/releases

Kourageous Tourists /L is the sequel for the venerable Kourageous Tourists, from @whale_2 (the great). In a Hurry: Current Release: 0.6.0.1 for KSP >= 1.3 (2022-1128) It works from KSP 1.3.1 to KSP 1.12.4! Seriously! IMPORTANT Module Manager is needed for handling the patches. Read this post before updating! Downloads on GitHub (for early adopters and beta testers) on CurseForge . on SpaceDock. Description: Space Tourism is the Future, and the Future is now for Kerbals! Kourageous Tourists /L is the sequel for the venerable Kourageous Tourists, adding different and challenging (or not!) rewarding missions related to tourism to the game: Skydiving on planets with atmospheres Swimming on planets with hydrosphere Expeditions to many Points of Interest scattered on the Kerbol System and more to come! Tourists need to be trained, you just can't let a rookie to sky dive on Laythe without proper training - how to do it and still be profitable is the real challenge! Don't forget to allow your tourist to take selfies! Remember, "Pictures or it didn't happened!". Support: I need help in order to proper help you. Open the spoiler for instructions about how to get support:

Nope. The right log is called KSP.log, and it's located on the same folder where KSP.exe is.

So did I. The KAX hack is… well, a hack - and I don't like it neither. Things worked pretty good when Firespitter was well maintained. Originally, helicopter parts were implemented using Firespitter's PartModule made specifically for helicopters. But then FS was literally abandoned without a good replacement, and the less worst that it could be done was done on KAX. The way to do it on KAX is by setting the rear blades torque to zero. They are just for visuals nowadays - but you can (ab)use them on custom designs, being the reason I didn't nerfed it at once by removing the ModuleEngineFX from them. I'm trying to simulation the main rotor's torque using Stock Modules, and so the rear blades would be useful again. The hard part is having time to tinker KAX on my scarce free-time… Good call. I would add it as a suggestion, however - you really don't need it. It's laborious, but if you balance correctly the craft and cut the torque of the rear blades, the thing is flyable. Challenging flyable, but some people are here for the challenge. You can also add powefull wheel stabilisers to help to control the thing if it's too big and the engine's stabilizer is not enough. But, again, nothing of it (even TCA) cames close to the playability of the Firespitter PartModules. Letting FS to rot was one of the worst mistakes of this Scene. And a Wheel Stabiliser to make the damned thing minimally controllable. I'm starting to conclude that the gimbaling is the problem by the way - we should use gimbal to compensate the CoM, and use the embedded stabiliser for pitch, roll and raw. The gimbal's Module was not meant to react fast enough to be useful on rovercrafts and helicopters as you already realised. And this is how FireSpitter did the work on the Golden Times! I found even animations to reflect the pitch on the blades' meshes! (unsure if FS used it - the whole thing gets blurred as the engine reaches operational RPM). Additionally, FS had its own "TCA" specialised to helicopters. It was really the better experience for people willing to build helicopters that fly like helicopters but are not all that hard as hardcore simulators. You have the best of both worlds - a reasonable decent helicopter simulator and niceties to make it easier for the casual gamer. Same thing - they were built on the FireSpitter era - and once FS ceased to be well maintained, these wheels didn't coped too well with the new Stock modules. It's exactly what I'm working right now (as scarce time allows) - but on KAX first, as that thing has only one wheel, makes things easier to prototype and check. Trying stunts on AirplanePlus can be problematic...

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 .