Lisias

I'm running it on Mac OS Sierra 10.12.6 . No perceptible issues until the moment. (I got it from Steam, by the way) — — — — — Oh, yes… KJR is working fine on 1.6. As it did on 1.5. As it did on 1.4. As it did on 1.3. As it did on 1.2. (and yes, this is a joke. )

Hi. TweakScale is not working on 1.6 yet. Probably due the Version Checking (as KJR used to do) - a new release with only this issue solved is on the cooking right now. — — — — — — ERRATA — — — — — — — TweakScale 2.4.0.6 (latest at the moment) IS WORKING FINE ON KSP 1.6. I had tested a previous version by accident (I installed Impossible Innovations for testing, and it have embedded a old TwekScale version - duh). You can safely ignore the Version Check warning while launching KSP. Next (minor) release will have the warning fixed.

Neither do I! You know, you gave me some kerbal ideas..

Last time, I complained that they released the 1.5 on a Thursday - ruining my working Friday (it's hard to work without sleeping at night). Now the dudes released the game on a Wednesday! Do you have the slightest idea what happens with you with two consecutive sleepless nights?

Did anyone found the repository for the source code?

It's "KSP API Extensions /L" Toadicus refactored the "KSP API Extensions" part of the add-on some time later, and I didn't merged it yet (a lot of things improved since them on KSP) - so just the KSPe thing is really in development at the present time. https://github.com/net-lisias-ksp/KSPAPIExtensions In time, KJR/L and KSPe/L are Experimental . They are mature enough to be used by the end user without fear of breaking the game, but not enough (yet ) to be used other add-ons. I think we should move this discussion to this thread instead:

While talking about problems that happens when updating KSP and how KSPe, besides being a decent miner's canary to detect such mishaps, is not the tool we need for this, I started up a discussion about some crazy tools I do on UNIX to make my life easier on KSP. Link to the starting point:

It's problematic to rely on an add'on to warn about being incorrectly loaded as it must be loaded in order to emit the warning. Sometimes the code is "loaded enough" to do such job, most of the time, not. KSPe can be useful as it detects problems after being loaded, and it is the very first add-on to be loaded. But only me use it currently (it is in a pre-release state yet, almost promoted from Experimental - but some work still need to be done yet). And would be a clutch anyway, as its job is not this one. I have a very crude tool that could help - but it's UNIX only, Windows support is still RiP (Research in Progress) So it's unlikely I can deliver such a tool in the short term. Unless I manage to convince everybody to install Cygwin!

Because probes don't sing!

I need a full log. Usually, binding errors happen anywhere but on the place where you detect it. — — — — — I set up a minimalistic KSP 1.5.1 installment just for the peace of mind: KSP 1.5.1, MH, ModuleManager, Firespitter, CRP, KSPe+KJR (using the ZIPs from the github to be extra sure). And yes, things are working for sure: [LOG 20:20:56.745] [HighLogic]: =========================== Scene Change : From SPACECENTER to FLIGHT (Async) ===================== [LOG 20:20:57.472] [UIApp] OnDestroy: KSPedia [LOG 20:20:57.657] [PlanetariumCamera]: Focus: Kerbin [LOG 20:20:57.659] [UIMasterController]: HideUI [LOG 20:20:59.712] UICanvasPrefabSpawner FlightUI spawning Flight [LOG 20:20:59.753] UICanvasPrefabSpawner FlightUI spawning VesselLabels [LOG 20:20:59.754] [UiApp] Awake: ResourceDisplay [LOG 20:20:59.886] [AddonLoader]: Instantiating addon 'AeroGUI' from assembly 'KSP' [LOG 20:20:59.889] [AddonLoader]: Instantiating addon 'KJRManager' from assembly 'KerbalJointReinforcement' [LOG 20:20:59.891] [KerbalJointReinforcement] TRACE: Awake [LOG 20:21:00.104] [KerbalJointReinforcement] INFO: Configuration file loaded. [LOG 20:21:00.105] [KerbalJointReinforcement] INFO: User customizable file loaded. I can say for sure that it's something on your KSP. A full log will help us to detect the problem.

Yes. You have a missing, corrupted, duplicated, whatever DLL somewhere in your system. KSPe is picky - anything wrong on the hard bindings, it borks relentlessly. Your system would bork eventually anyway. A closer look on the .log file would pinpoint the culprit. PROBLEM IS… Apparently, the DLL loading phase on your logs looks ok! I was considering I borked again on KSPe+KJR when I found this: [LOG 19:59:57.444] B9TankSettings: registered tank type SSPXRocketParts [ERR 19:59:57.456] [ModuleManager] Post run call threw an exception in loading System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 [EXC 19:59:57.456] ReflectionTypeLoadException: The classes in the module cannot be loaded. System.Reflection.Assembly.GetTypes () ModuleManager.MMPatchLoader+<ProcessPatch>d__31.MoveNext () UnityEngine.Logger:LogException(Exception) ModuleManager.Logging.UnityLogger:Exception(String, Exception) ModuleManager.Logging.ModLogger:Exception(String, Exception) ModuleManager.<ProcessPatch>d__31:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) [LOG 19:59:57.504] [ModuleManager] Calling DustColors.ModuleManagerPostLoad() This is the thing what would bork KSPe relentlessly. I don't have the slightest clue about what's DustColors, but right now my guess is that you need to update or delete whatever the add-on that uses it. I also found this: [LOG 19:59:57.536] [AtmosphereAutopilot]: part 'DERP_Engine_02' config node contains ModuleGimbal, moving it [LOG 19:59:57.536] Loading KIS global settings... [LOG 19:59:57.629] PartLoader: Loading part database [LOG 19:59:57.630] PartLoader: Compiling Part 'Ablative-Airbrake/Parts/AblativeAirbrake/AblativeAirbrake' [LOG 19:59:57.651] EffectList: Created 16 effect types [ERR 19:59:57.709] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null [ERR 19:59:57.710] ADDON BINDER: Cannot resolve assembly: TestFlightCore, Culture=neutral, PublicKeyToken=null [LOG 19:59:57.748] PartLoader: Compiling Part 'AirplanePlus/Parts/Aero/anglewings/hanglel/hanglel' Same thing. Something is trying to use TestFlightCore, but it's not available. However, since this is not throwing a Exception, I doubt it's a problem. TweakScale suffers from this too. This is an annoyance, but not a problem. However… I found this too: [LOG 19:59:58.872] [MechJeb2] Starting the Dispatcher [ERR 19:59:58.881] MechJeb moduleRegistry creation threw an exception in LoadComputerModules loading System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e08 at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at MuMech.MechJebCore.LoadComputerModules () [0x00000] in <filename unknown>:0 [LOG 19:59:58.898] ManeuverPlanner initialization: found 17 maneuvers I don't have the slightest idea about this, I never saw MechJeb2 borking this way before! — — — — — As a rule of thumb, the presence of a "System.Reflection.*" Exception on the log is usually an indication that you have unsatisfied DLL dependencies (i.e. - some DLL tried to load another one, and didn't found it - or it had changed in a way that they didn't understand each other anymore). This usually renders your KSP unstable too, and that's the reason I didn't tried to workaround this weakness from KSPe yet - it ends up begin useful as a miner's canary - if KSPe borks, your KSP will bork sooner or later too in a very unexpected and unpleasant way (while playing).

What could be more simple than throwing parts until the thing just works?

Screenshots or didn't happened! (one of the best "What did you do" in all times)

Similar designs, completely different solutions. Had Buran the same problems too (I.e., debris hitting the heat shield)?

That really long ones must use the EAS struts. Impossible Innovations have some different ones, if you don't mind throwing the plausibility through the window. On your <KSP_ROOT>/GameData/KJR/PluginData (or <KSP_ROOT>/GameData/KerbalJointReinforcement/PluginData if you are using "my" unofficial fork), you will find a config.xml file where some parts and modules are listed. Check if your docking ports are listed there, or make a very small station using the same parts you are seeing the problem on yours and publish it here so we can give a look.

Elite Dangerous Elite Frontier and First Encounters also had some bug fix releases, what was a problem before the Internet times... World of Warcraft Rodina Eve Online Star Citizen No Man's Sky Not to mention the infinite updates from some mainstream games on PSN (as Assassin Creed). So… I don't think KSP is doing that bad after all. And KJR will probably be running fine on them.

(sigh). It's a bit more complicated than that. TweakScale needs to run all the variants to scale them too. I found code already scaling attachment points for ModulePartVariants, but that code doesn't touches the baseMass - probably due being a bit old, as the message logs stated "stockTextureSwitch" instead of "ModulePartVariants". It's some time since I'm nurturing an idea to better cope with these things. Fixing things on demand and then issuing a new TweakScale every time any module changes is cumbersome and counter-productive. The next release will be in the works on the holidays due the considerable amount of energy this is going to cost me, but I intend to give this "mess" an end. It's going to be better, but first, I will reduce the scope of supported modules - what will be not exactly a problem, as things are broken now for such parts. Thank you very much for your efforts. It leaded to a proper issue just for this. https://github.com/net-lisias-ksp/TweakScale/issues/13

This can or can not be an issue, as different parts have different "densities". Stronger parts has more material on its super-structure, and so when scales down, has less space for resources - ending up having less mass. This is a part of the code that I didn't really looked on, as things were exploding (pun really intended) somewhere else. But if this is a bug, it's already covered by issue #9. Meno male. At least it's just one part to check what's happening. Now I have a clear, punctual situation to observe, instead of chasing my tail. Thanks!

Marvelous! So now I have two problems with identical behaviours! At least things start to make sense now. B9 Part Switch appears to be involved on the Zero Mass Effect, and this is the Negative Mass Effect.

YES!! Finally another evidence! Thank you! *THIS* was the bug that halted the development of my novel! I need you to make a test: deactivate B9 Parts Switch (move it out from GameData), and try again. Then bring it back, and see what happens. B9 Parts Switch is the "screaming victim" of this bug, something (I'm guessing it's TweakScale), somehow, when see B9 Part Switch, injects in it a bad behaviour, rendering a part with Zero or Negative mass. Negative mass is bad, but zero is worse, as the part became anchored on the 3D space and all that thrust is then applied to parts as they would be connected to a concrete pylon firmly anchored on the tridimensional space until something fails, and it's blowup fest. A known work-around is to do not scale parts using B9 Parts Switch, do not use B9 Part Switch (using a patch to add the feature on B9 parts that rely only on it) or use only B9 Part Switch. — — — POST — EDIT — — — Issues related: https://github.com/net-lisias-ksp/TweakScale/issues/12 https://github.com/net-lisias-ksp/TweakScale/issues/11

You know, there're some forum rules that prevent me to follow up this. Damn it! I'm feeding the competition!!!

I could not agree less. Most of the hacks you complained before was due Unity's ones at that time. Switching Unity version was unavoidable, Squad was already on a corner. Almost all of the breakage came from getting rid of the hacks they had to do to cope with old Unity's idiosyncrasies, but also from the hacks they have to do to cope with new Unity's idiosyncrasies. Unity is a hell. I agree. But… Don't think that the other engines are so that better. Unreal Engine has its idiosyncrasies, and you should talk to someone that works with Frostbite. The main difference between KSP and the others is that KSP is 'program driven software', where most games are 'project driven'. On a project, once a game is ready and kicked out through the doors, you close shop and that's it. New game version is a new game project, with a new budget, and everything can be rewritten from scratch if needed (and money allows). Try to run Quake2 mods on Quake3. KSP is a program, like Windows or MS Office. The dynamics are different. I can't run all of the Win95 programs on my Windows 7 - but I can run some. Looks similar to KSP? Well, it is. I have a proposition for you. Gather people, fork the mods you want to use on 1.3.1, and back port the bugfixes. The license of most of them allows. Create a parallel ecosystem focused on 1.3.1. It's possible, all you need to do is to hack into some code. You will see that most of the problems are not exactly from KSP changing something, but from KSP getting better and everybody that relied to work on a idiosyncrasy needing to rethink things. And some of that most wanted mods (as KJR) is working flawlessly with the same binary on every KSP version I tested it since 1.2.2 (yeah, the very same binary, not even a recompile). This is something to think about. Believe me. Squad is one of these companies you wish. And the problems you are facing are the exact consequences of that. You can't have the cake and eat it too.

I agree. And I think you nailed the reason: not enough resources are being spent. However, resources must be earned before being spent, and this is the reason I think things are this way for now. They need to feed the cash cow, so they can have the milk to feed Q/A. This is, still, an indie game I could not agree more.

You can't have the cake and eat it too. Had Squad stayed on the 1.3.1 code-tree, we would had a huge amount of performance leaks and unsolvable bugs. Leaking Abstractions and Interface Brakes are a pain in the SAS, I agree and recognize it, but that's it or freezing the product into a bugged, unsellable situation. Now that I have near a year of KSP overseeing, I have some ideas about the reasons they are doing it, as well about the objectives. And besides getting really angry sometimes with the breaks, now that I understand the reasons, the angry vanishes fast - it's that or loosing KSP itself, this forum and everything else. All of this costs money. They need to feed the cash cow, otherwise they capsize with everything and the kitchen's sink going kaput. They know it. And this is the reason that sometimes they take some not exactly best decisions, that back fires and blow up on everybody's faces. I'm a professional software developer by trade and by formation, first played 1.3.1 and immediately 1.4.0 came, and I saw things happening (what include things that for the user are invisible), so please give me some credit on this: their lives would be insanely easier if they choose to drop the support they do for mods. They need to sell KSP for new users, but yet they compromise with features they didn't sold neither maintain in order to do not jeopardize (too much ) the legacy. Not for the faint of heart. I agree. KSP is a memory hog. My advice is to monitor the virtual memory size or, better, the swapfile size. If it reaches about 10% of your physical RAM, you are abusing your rig and performance will be sad. It's a design decision that works for the stock game: due some Unity idiosyncrasies, it's better (and easier) for they to just load everything into memory. The game is a open universe, and they didn't wanted you to get lags when flying your vessels around. When you cheat your vessel to be in the orbit of any body, there're no loading time, because everything is already in the memory. Load On Demand is possible, but not with the same user experience. Games like Assassin's Creed can do it because you are on a open world, but only the visible fraction of it is needed - A.C. don't need to load anything else but what's immediately visible to you. On KSP, on the other hand, you can send vessels to any place in the universe, and switch to them, and even build telescopes to see bodies beyond the immediate sight. Loading on Demand would render these somewhat annoying. For the sake of comparison, Orbiter does the same: you need to build a scenario file where everything you want to use is declared, so it doesn't have to load anything else (but the "Universe", that must be loaded anyway). Some scenarios I made took some time to load… But yet, I didn't had to load everything and the kitchen's sink at once, since we don't build new vessels once the game is started. IMHO, what you are asking should be handled by the modders. At least, while Squad don't cook something for them - what will take some time, as the Stock are still being loaded in a reasonable time. What leads me to another issue: KSP supports XBox and PS4 too, where memory constraints are tougher and not negotiable. Until the moment, KSP had a manageable footprint on them, but with MH and possible new DLCs coming, this is going to change fast - so I expect they would be working on something sooner or later. But this will be a point of inflection for KSP ecosystem, as the whole GAMEDATABASE subsystem will have to be reworked somehow - I foresee a huge breakage on the legacy mods (that can or cannot be easily fixed). As I said, you can't have the cake and eat it too.

Oh, a business opportunity! I have a proposition for you: a browser plugin that would monitor the uncover button tag, and every time you click on it, it checks the owner to the post, classify it, and send a signal by HTTP to a Arduino device that would be controlling three different devices (so you can be properly punished by the level of aggrievement you have with the guy): one would be controlling a truck horn one would be controlling a servo, where a boot would be attached in order kick you in the SAS one would be attached to a power relay that would cut the power from your home I guarantee that this contraption would prevent you from uncovering such posts.