Lisias

That was a very good call. it wasn't the cause for this problem, but it could be and if it was, I would be chasing my tail for days. By testing it, I was leaded to what appears to be the real cause, so it totally worth the effort. Thx!

I could not resist to the joke

I logged the exception on that code of HullcamVDS: try { PartLoader.getPartInfoByName("kerbalEVA").partPrefab.AddModule(EVA); } catch (Exception e) { Debug.LogException(e); } And got this: I didn't had the time to test it properly, so I don't know (yet) if the NRE is coming from the getPartInfoByName or from the .prefab. But this is something for the weekend. In a way or another, it's a change that happened after KSP 1.4.1, and the empty try-catch prevented us to see the problem. Since the nasty collateral effects are being echoed by all the game, the getPartInfoByName appears to be working, and so the real problem is that kerbalEVAs doesn't have a prefab anymore, or perhaps we have a race condition where tow modules (and I include Squad's on the basket) are concurrently changing that part. — POST — EDIT -- I killed some day job and did MOAR TESTS on the subject. I changed the code to this: And got this: I intentionally added a non existent part ("kerbalEVAthatDoesntExists") to see what happens. That inexistent part works "fine", getPartInfoByname returns null for it, and then the if suppress the command, The other four "kerbalEVA" do exist, but they don't have a prefab atribute[It's the Modules atribute that it's nulled!]. At least, yet - perhaps we are facing a race condition, in the same way I was on TweakScale.

The kerbalEVA* issue that happens with HulcamVDS , doesn't happen on a identically installment on KSP 1.4.1 - I literally copied the MODs from 1.4.5/GameData to 1.4.1/GameData - being the only difference the Squad's folder (of course) and the absence of the SquadExpansion folder. DeaflyReentry, however, blew up on millions of colours - but I put that on the "no supported version" basket. Not an issue. So I decided to test KSP 1.4.5 with and without SquadExpansion, and got the very same results: NREs on kerbalEVA. But at least, I know have a hint: it's a problem between KSP itself and some mods (not TweakScake). — POST — EDIT — Test done. No news. Same behaviour. ``` [ERR 20:52:15.960] [TweakScale] Exception on kerbalEVAfemale.prefab.Modules.Contains: System.NullReferenceException: Object reference not set to an instance of an object at PartModuleList.Contains (Int32 classID) [0x00000] in <filename unknown>:0 at PartModuleList.Contains (System.String className) [0x00000] in <filename unknown>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__4.MoveNext () [0x00000] in <filename unknown>:0 ``` This happens on KSP 1.4.3, but not on KSP 1.4.1. Compiling the DLLs against newer KSP libraries doesn't changed the behaviour.

Dude… I should had paid more attention to your post. Imagine the following scenario: TweakScale V-1 generated a code. Then some revisions later, the synthetic methods are generated in a different order or whatever. As long such synthetic methods are used only by the current DLL, no problem - but if by some reason such methods are not "internal" to the DLL, and other DLLs manage to link against them, then we have chaos - clients calling one thing thinking it's other completely different. It's a looong shot to imagine that such mishap would had been allowed to leak - but… I already saw some problems being solved by merely recompiling the thing, so…. I think I'm going to start another recompile fest tonight. You will need to ask the Launchpad's maintainer for that info, as I don't know (at least, yet) this module's guts in order to help you. Sorry. But once that info is available, building the patch would be relatively straightforward..

A Pull Request will be hugely appreciated!

Orbiter is magnificent. I don't think we will ever have another Space Simulator that will reach this level of excellence and accuracy in the next decade. KSP is incredibly fun. Besides some tears and teeth grinding , KSP also rendered me some of the biggest laughs this year. This kind of fun you will not get from Orbiter. So, in essence, it's like comparing a SitCom about Scify with serious SciFy movies. You can like and love both, but you will choose one by the type of entertainment you want/need at the moment. However, both Orbiter and KSP share a common issue that it's both the reason for the success, but also the reason for their problems: the Programming Language There're not a single way that Orbiter would reach its level of excellence using anything else as C++, however, C++ is not for everybody and this decision also limits the number of people willing to build things on it. The lack of a physics engine also is a problem for people willing to play mishaps in the way we have on KSP. So… Nops, Orbiter is for the die hard C++ programmer or to people willing to "play serious" on orbital mechanics. KSP, on the other hand, got this popularity due the flux of people writing add-ons for it, what would not had happened in such abundance using C++. C# was the key for this success. However, C#'s VM is not par to the task (and please, please, don't whine about. High performance commercial applications are switching back to Java due this, and we did performance checks before committing to the task), and Unity, frankly, is an eternal source of headaches. The key for the KSP's success is also it's major weakness. In the bottom line, it's a real pity that I can't manage to have time for both.

Oh, delight. I tried KSP 1.4.5 + TweakScale + TweakableEverything + Deadly Reentry + "MM /L Experimental" and the test KSP capsized before even finishing the load! By deleting TweakableEverything, KSP managed to finish loading and I could confirm the behaviour. But, and I want to make this absolutely clear, TweakableEverything was working absolutely fine on the previous testings (Impossible Innovations + B9 + AirplanePlus). "My" /L Experimental fork for MM has a kind of a weakness that I'm exploiting to check the DLLs health: due being fired up early on KSP load chain, and due relying on KSPe services (that constantly probe all the loaded DLLs by Reflection), anything, absolutely anything wrong on any, absolutely any DLL blows up everything. So, I have an early and screaming notice of something that would silently fail later. (this weakness is so useful at the moment that I didn't bothered to fix it yet! ) By coincidence, or not, this Exception are repeated ad nauseam until the bitter end: [EXC 20:52:09.573] ReflectionTypeLoadException: The classes in the module cannot be loaded. System.Reflection.Assembly.GetTypes () KSPe.IO.File`1+<>c[ModuleManager.ModuleManager].<FullPathName>b__6_0 (System.Reflection.Assembly assembly) System.Linq.Enumerable+<CreateSelectManyIterator>c__Iterator14`3[System.Reflection.Assembly,System.Type<>f__AnonymousType0`2[System.Reflection.Assembly,System.Type]].MoveNext () System.Linq.Enumerable+<CreateWhereIterator>c__Iterator1D`1[<>f__AnonymousType0`2[System.Reflection.Assembly,System.Type]].MoveNext () System.Linq.Enumerable+<CreateSelectIterator>c__Iterator10`2[<>f__AnonymousType0`2[System.Reflection.Assembly,System.Type],System.Type].MoveNext () System.Linq.Enumerable.FirstOrDefault[Type] (IEnumerable`1 source) KSPe.IO.File`1[ModuleManager.ModuleManager].FullPathName (System.String partialPathname, System.String hierarchy, Boolean createDirs) KSPe.PluginConfig.ForType[ModuleManager] (System.String name, System.String filename) ModuleManager.MMPatchLoader..cctor () Rethrow as TypeInitializationException: An exception was thrown by the type initializer for ModuleManager.MMPatchLoader ModuleManager.ModuleManager.Update () Did you noticed the "MoveNext()" on the StackDump? Me too. All of this hint me that perhaps I'm chasing ghosts on trying to find an add-on (or set of add-ons) badly incompatible with TweakScale. The problem appears to be not on the Add-On, but on something on the environment where some add-ons bork by stumbling on the very same thing "my" MM stumble (but, being in the critical path of the load process, blows up everything on the act). I know for sure that the absence of a DLL that it's a dependency of another one causes this critical failure on MM /L (frankly, it's a failure on the Mono's VM by leaving its internal data structures in a inconsistent state, but whatever - it's me the one that have to workaround it). So, I'm guessing that, in reality, we are facing some kind of dynamic linking problem. And such linking problem is tampering the add ons that relies on Reflection.

Given the numerous "forkings" from my argument, I decided to consolidate them in a (hopefully) few words: It's unlikely that TTI/Squad would ditch CurseForge for officially support SpaceDock due: Lack of a business plan from SpaceDock, where: Clear rules for Content Creators would define what can and what cannot be published associated with KSP's Intelectual Properties, image, whatever. And so, there're uncertainty about the nature of the content and the acceptability of such content, causing: Uncertainty for the content publishers about the content "survivability" over the time - the maintainers can decide, under their sole discretion, to delete anything at any time. There're no clear rules, there're no contract between parts. Therefore, uncertainty for the advertisers about the content in which they advertises would be associated to. And no, the good will of the current maintainers are not enough. A clear Revenue Stream, where partners would evaluate the risks on investing on such partnership: Should I invest my money on this site? Or the other one would add more value to my product over the time? It will be there in 2 years? If the site closes and the content is lost, how bad this will look for us? Will this site accept advertising from companies which product or services are not compatible with our current and future consumer base? Our consumer base would be exposed to such advertisings? Please note the absence of an item "2". The technical excellence from SpaceDock is good for the users, but the users would not be the ones providing the Revenue. And Funding is not enough - where is said that SpaceDock will not accept donations from Hustler?

Sausages, Laws and Software - it's better to do not know how they are made while consumption. IMHO, this "broken mess" is not cause, but an effect. A collateral effect from the extreme mod friendly posture of Squad. I see, too, some good opportunities for improvement on KSP, but I also see the consequences of such improvements on the mod scene. And, frankly, right now, my worst problems are on what i'm calling "Unholy interactions between add-ons" that I jokingly complement "is what Krakens feed on". Of course, they do some mishaps regularly, and I think they need to better address that on future releases - but, and again, IMHO, they would mishap a lot less if they didn't wanted to keep this mod friendly environment we have. TL;DR: Yes, we must keep complaining about bugs. But we should restrict our complainings to the bugs.

I'm not questioning the "survivability" of SpaceDock. It's very possible (almost a sure) that SpaceDock would survive most of the commercial sites that are being born today. But without a business plan, potential partners would be unwilling to be associated with. Take, as an example, what's happening to Youtube: they are loosing (ou had loose, I don't know if this is still happening) advertisers due some undesired content in which their products are (were?) being advertised on. (I prefer not to disclose the kind of content). A business plan is a protocol of intentions. Companies tends to associate with others where their business plan is "compatible". You will not see toy makers advertising on some… "interesting and peculiar" ;-) sites. And you will not see Playboy advertising on CurseForge. And this is not due the "good will" of that site maintainers, but due a clear and enforced policy of content (that are depicted on that business plan). It's like the saying: "Caesar's wife must not only be honest but must also be seen to be honest". Marketing is hell, one single mishap and your product looses value.

Revenue is money earn in exchange of services, no matter the company offering the services being a non-profit or not. It's not only semantics, is the core of my argument. A company, in order to be attractive to other company's business plan, need a Revenue (ideally, a sustainable one). Revenue Streams are, usually, result of a successful Business Plan. Otherwise, it's too much a risk to rely on them.

I may be wrong, and language barrier is a sunny beach, but… Donations are 'funding", not "revenue" as far as I know. Would they charging for the Service itself, I think they would be violating some of the Forum (and KSP EULA) terms. https://www.thebalancesmb.com/where-do-nonprofits-get-their-revenue-2502011

Frozen, not ended. If anything wrong are discovered, a new "edition' will be issued. So, the current one cannot be said as "final edition". But can be the last edition when the F9 reaches end of life, and the Falcon9 Program is finished. This is the reason I'm stressing the diferences between a Program and a Project. KSP is like Elite Dangerous - an ongoing effort to deliver a Game - it will never be "finished" - unless Squad decide to switch it's business model to something like GTA - GTA1, GTA2, GTA3, GTA4 and now GTA5 were sold separately, and even developed by different developers. It's the reason GTA is called "a Franchise", by the way: it's not even a "Program", but a series of different Projects that happens to use the same name.

Read my post again. "final edition" is not exactly the same as "last edition". It's the difference from the artifacts made by a Program from the ones made by a Project.

Reading the posts after mine, I'm considering that I'm answering the wrong problem. But it worths to mention anyway: I attach the "protective" part on the hull. If there are not a node available where I want, I attach it on the nearest one and move it to where I want. Then I attach the chair to the protective part, doing the same if needed. As long the Kerbal is on the seat, and the airstream is hitting the protective part, he's protected - with or without a cargo bay. Remember, however, that drag is omnipresent in the stock physics. Everything do drag, even inside cargo bays. (Don't ask)

Makes sense! I have it too on my Installment! Tonight I'll fire up a testbed with minimum mods to reproduce the problem! — POST—EDIT — False alarm, or perhas this is not the only trigger. I made a copy of my installment where this problem happens determiniscally, deleted HullCameraVDS and fire it up (after deleting Module Manager cache) and the exception are still there. [FALSE FALSE ALARM! IT WAS EXACTLY THIS CODE! SEE MORE AHEAD!] Next step is to build a clean KSP installment with a minimum set of mods *and* HullCameraVDS in order to have (or not) a counter-evidence. But this. just by night for sure.

Nops, this is a flaw on KSP physics. I think (but didn't tried yet) that FAR does it correctly - but there're a trade-off, FAR have their own set of glitches too. You choose your shoes in function of where you feet hurts (not how bad this got translated to English). One thing that you can do is to put a shield (ablator, perhaps?) to protect the Kerbal. You can clip that shield on the part just in front of the Kerbal for aesthetics, but you will have to live with the extra mass.

I already did it. The mods, alone, works fine. It's a combination of mods the trigger for the Kraken poo storm.

The problem appears not to be on the patches, but on the code itself. There're a combination of mods that, when installed together with TweakScale, plays havoc somewhere on KSP. One mod that was being "victim" of this combination was B9. In testbeds with TweakScale and B9 only, everything works fine. But on my installment with about 140 mods installed, something makes B9 go crazy, that so makes TweakScale goes crazy (or vice versa), and then some parts became anchored in the tridimensional world - and things explode by stress when you hit the gas pedal. Now I have notice that one mod that I have installed on the same installment and until the moment had no entry on the log, now is being "listed" on TranceaddicT's KSP. So things appears to be not deterministic - the "taint" appears to choose another mod in circumstances that happens on his KSP. So, ContractConfigurator and PatchManager cannot help me on this. At least, not yet.

No, no! I want you to run it on a copy if your KSP install!!! Humm… Now I'm worried (anyone remember Alfred E. Neuman?). I have AirplanePlus on the very same installment I found this DryCost thing, but only (some) B9 parts got this error. Could you, please, send me your KSP.log? All the info I will need (as mods installed) is there. post-edit: the .ckan file was helpful, thanks! But the KSP.log will be yet more helpful!

That was my initial thought. But once some specific per-mod code is unavoidable, where some mods support would be mutually exclusive (i.e., if you install TweakScale_ModX… you should not install TwekScale_ModY…), perhaps could be a good idea to expand the concept to optional sizes. Usually, users don't want to cope with files, they want to check up what they want on a user interface, click "Do it" and forget about. The current package would be a meta-package, with dependencies that would build the current status-quo (or near it, as I think that some mutually exclusive support are already there, being that the reason for some glitches on my KSP installment). So, minimal fuss with legacy.

I plan to support Stock on the main download. Too much options are not necessarily a good option to the end user, most people usually resent too many options. On the other hand, some people do like "MOAR OPTIONS", and I agree with you that I should think on something. Disclaimer: pure brainstorming on the Spoiler below. Nothing will be changed on the Orthodox branch and, so, nothing will be change on the Mainstream Releases. Assuming this will work fine on Heterodox and this "sub-packs" idea sticks, an additional pack of settings for "Advanced Users" can have your patches added. And then, we could keep both sides of the equation satisfied. Sounds viable to you?

Well, I didn't had this problem. When I needed to upload a add-on compatible with 1.4.1, 1.4.3, 1.4.5 and 1.5.1 (but not with 1.4.4, where it borked), I could. But, granted, I didn't hushed to upload a 1.5.1 compatible mod. I tested it properly before.

Well, that's a reason to look for alternatives. One thing that people should understand: it's all about the money. It's always about the money, Everybody have bills to pay and mouths to feed. Any other considerations are secondary. You want do make a deal with a business? You need to have a business. It's simple like that, I'm sorry being the one telling you this. And some of them gone Kerbal Stuff. CurseForge is still there. Do you see a pattern here? One thing that people need to understand. If you don't pay for the product, you are the product. The only single reason a commercial site serves you "for free" it's because someone else is paying them for such. And who're paying are the clients. [not who are using] The sore purpose of any business is to serve their clients, not their users. And users are not clients - unless they are paying, of course.