Lisias

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

Hi! This is a feedback post. I'm doing some research about resurrecting the helicopter parts. This is where we are now: there's no way to do it properly. Using the trick done on KAX is far from being really good - what was done was to replace the helicopter module from FireSpitter with a Stock Engine, virtually transforming the thing into a high altitude hovercraft. The engine doesn't induces torque, and it's virtually uncontrollable without heavy use of Stabilisers - and I mean the word heavy. The tail rotor became merely decorative, as it would screw up controllability without setting the engine to 0%. But it is what can be done now with the PartModules we have at our hands. Better solutions are possible, but not on the short term. In anyone have any ideas, I'm listening.

Probably not, as apparently it is the bug fest trigger on your rig!

Gee… You have a lot of Reflection Exceptions. From your log: [LOG 22:18:53.012] PartLoader: Compiling Part '001KerbalActuators/Parts/Utility/SampleArm/SampleArm/wbiSampleArm' [WRN 22:18:53.049] [KSPCF] A ReflectionTypeLoadException thrown by Assembly.GetTypes() has been handled by KSP Community Fixes. This is usually harmless, but indicates that the "NextStarIndustries" plugin failed to load (location: "GameData\NSI\Plugins\NextStarIndustries.dll") ... [LOG 22:18:55.345] [MechJeb2] Starting the Dispatcher [WRN 22:18:55.395] [KSPCF] A ReflectionTypeLoadException thrown by Assembly.GetTypes() has been handled by KSP Community Fixes. This is usually harmless, but indicates that the "NextStarIndustries" plugin failed to load (location: "GameData\NSI\Plugins\NextStarIndustries.dll") ... [WRN 22:18:55.606] [KSPCF] A ReflectionTypeLoadException thrown by Assembly.GetTypes() has been handled by KSP Community Fixes. This is usually harmless, but indicates that the "NextStarIndustries" plugin failed to load (location: "GameData\NSI\Plugins\NextStarIndustries.dll") After that, tons of NREs on NextStarIndustries.NSIExplosionModule . You will need to uninstall whatever NextStartIndustries is. Sorry. On a side note: KSPCF error message is misleading and it's downplaying the importance and seriousness of the problem. Everytime time you have an uncontrolled ReflectionTypeLoadException , whatever it was meant to be loaded is not being loaded. And then, when KSP loads your savegame, anything that would had expecting that thing to be loaded will just be removed from the living parts - completely ruining your savegame. If the thingy failing to be loaded is TweakScale, all scaled parts will suddenly be unscaled back to defaults - completely screwing up your ships - but TweakScale is only the most visible and obvious victim of the problem! In fact, everything that failed to be loaded will suffer the same, but most of the time the problem is not visible to you immediately - silently corrupting your savegame as you play without being aware. So… No savegame should be loaded if you find a unhandled ReflectionTypeLoadException on your KSP.log! This is a Show Stopper problem, not a small nuisance that can be ignored!!

This will not install the game as the installer does, it will only download the game into the Steam's download directory. On the Steam Console, wait for the message "Depot download complete". It will tell you where the files were downloaded - then you just move it to where you want and run it: Alternatively, you may had reached an error message (they start with ">>>"). On this case, you may had did a typo, or perhaps the deport is not reachable anymore by Steam Console (that MRC stunt I talked about).

You can download directly from the Console - a bit worksome, but effective. Open your browser and type "steam://nav/console" and then: if you are using Windows 32 bits download_depot 220200 220201 2883479793978706603 If you are using MacOS download_depot 220200 220202 5793944360086434965 if you are using Linux download_depot 220200 220203 6355952238366872645 if you are using Windows 64 bits download_depot 220200 220204 2193386441228596454 The proceedings are virtually identical to what I had published on the post below (what changes is the manifest ID, that last big number): There's also a open source tool for downloading depots from Steam, called DepotDownloader. Recently (well, not that recently) Steam added a thing called "Manifest Request Code" (full story here - read to the end) for some downloads, and if by some reason 1.3 was flagged to need that MRC, then DepotDownloader is the only way to go (can't say, as I downloaded everything before the MRC stunt) Note: you can download any Steam published version of KSP, including DLCs and language packs - all you need is to grab the app, depot and manifest ids from SteamDB.

That was a surprise! I was betting the DLL would bork, not the parts! I can assume that the thing worked on 1.3.0 ? Anyway : https://github.com/net-lisias-ksp/HLAirshipsCore/issues/10 . I consider KSP 1.2.2 more a vanity feature than a necessity, but it's interesting to make things work on it as a way to understand how KSP evolved - not to mention in paving the way to update classic add'ons. Cheers!

We lost Olivia today. Also found this one - the first show I ever watched (on laserdisc, I think)

Please, and thank you! 1.3.0 I'm reasonably confident it will work - I'm not using anything that changed from 1.3.0 to 1.3.1 for sure (i.e., the Settings Page support). It's some time since the last time I developed something for 1.2.2, and I forgot the differences between 1.2.2 and 1.3.x, so I don't have the slightest clue if the thing will work or not. But it will probably be possible to compile a specialised version for 1.2.2 if worst happens - more as an academic exercise than anything, as I don't think there're people still playing on it nowadays!

It will work better if TweakScale is the first one to be installed - so you will know on the spot when you install a faulty one! In fact, I had recommended to some users that doesn't want to use TweakScale to install TweakScale (and MM WatchDog) as a Canary Mine - TS will always yell when it find something smelling funny! Once the rig is stable, you can always remove TweakScale (as long you don't load any savegame and use it).

One of the reasons to migrate is to have models with colliders and meshes fixed. Some parts don't explode anymore at launch, neither will sink trough the runway if not withheld by other parts. As well respecting F2 to hide UI, lots of NREs prevention, better (and safer) TweskScale support, proper bulkheads on the part configs, fixed descriptions, you name it. (and, contrary to what you claim, there're problems on the legacy code related to KSP 1.12!) But… your GameData, your savegames == your call. You are free to prefer a buggy environment if you prefer - being the reason Core will withdraw its parts from GameData when the older assets are present. Who am I to judge? We are both active on this one. I requested "my" thread to be moved into Development Forum, and I will update the Title accordingly - I should had created that thread on that Forum at first place. Neither from anyone else, as that code and assets are All Rights Reserved!

There must be a pretty older version of TweakScale! Well, assouming every DLL is at its rigth place (the 999_Scale_Redist.dll one is on GameData?), something else on your rig is failing to find a dependency, what is triggering a nasty KSP bug on a thingy called Assembly Resolver, yada yada yada. And this bug is what screws up TweakScale and everybody else - the only difference is that TweakScale yells when this happens, instead of allowing you to proceed and risk screwing up your savegames. The only sensible thing to do is to diagnose who is borking on your rig. Send me the KSP.log and I will inspect it (is you use MechJeb, please remove it from GameData, run KSP, quit KSP, send me the log and then reinstall MJ2 - MJ2, by some reason I didn't understood yet, messes a lot withe the usual order of events that I need to diagnose the problem!). Cheers.

You and half the KSP players! You are having a problem with Buffalo: [ERR 19:22:00.643] ADDON BINDER: Cannot resolve assembly: BARISBridge, Culture=neutral, PublicKeyToken=null [ERR 19:22:00.647] AssemblyLoader: Exception loading 'Buffalo': System.Reflection.ReflectionTypeLoadException: Exception of type 'Syste m.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' You need to install BARISBridge in order to use Buffalo. However, as far as I understand, the most recent Buffalo had removed the BARISBridge dependency, I think you should upgrade! https://github.com/Angel-125/Buffalo/releases/tag/v2.12.0 Cheers!

One can't be more Kerbal than this - on the most positive sense of it! (the dude trying it for 7 years is yet more Kerbal - but he succeeded on the process!!! )

Sounds like IT management: "What? i have to buy FOUR cellos for this show? NO WAY, there're 4 strings on the thing, take one and multi task it!"

The KSP-Recall's aim is to fix Stock. 3rd parties add'ons may or may not get fixed, depending of they following Stock rules for parts definitions. Well, I had had found some add'ons that don't. Once an add'on deviates from the Stock behaviour, it is at its own - it's virtually impossible to cope with every single possible idiosyncrasy created by a 3rd party (it's already hard enough to do it on Stock). One exception that confirms the rule is Procedural Parts, that fortunately I managed to find a relatively simple fix here. If it's what I think it is, nope. This happens with parts that doesn't follows KSP standards and then end up breaking things that relies on things being standard. One of the possible causes are parts that just don't care to initialise the Attachment Nodes on the Config File - and so anyone in need of them on the OnLoad phase are royally screwed. See the link above for an example (and if you understand Module Manager patches, you will understand how I fixed this one - by pure luck! ). If you manage to build a minimal craft where these things happens, by sending this craft I can try to analise it and see if a fix is viable with a Module Manager patch. If it is, I will create one and we will have at least one more 3rd party idiosyncrasy tackled down! Same thing. Create a minimum craft where the problem happens and send it to me. With luck, it can be fixed by a Module Manager patch!

Who are these guys and why I just discovered them today??? Barcelona Guitar Trio - Billie Jean

On my time, buying the album was the lesser of the problems. Finding the damned thing first in order to buy it was the hard part! Before online international shopping became a thingy, my only source for alternative music was Napster, mIRC and later eDonkey!!!

I think that we already have enough of "Continued", "Recontinued", et all postfixes on the Scene - who is the guy maintaining these? /L made it simple. DOE /L is Distant Object Enhancement under Lisias' Management - no further questions (por postfixes) needed.

Yes, it's intended. It's to differentiate the epoch in which I become DOE's maintainer from the ones from DarkBadger. Everybody and the kitchen's sink are used to use that SpaceDock link for DOE, so we choose to keep it as it is. But we need somehow to mark the new stewardship and adding "/L" looked as the less intrusive and yet clear indication that these releases are now under my shoulders! Cheers!

Found this today, and kinda liked it. Highly experimental progressive music from the early 70's - but I enjoyed listening to it while working. Irrlitch, Klaus Schulze. 1972.

Yet!

Because an image worths a thousand words!

Check this post: