Lisias

Use ModuleManager 3.1.3. Something changed on MM 4, and Ubioweld didn't coped very well.

They're more a Public Disorganization.

It's some months since my last bork on the code (now I bork the packaging! ) indeed. Most of the problems I see nowadays are collective borks - a series of small mishaps that, by themselves, are not serious but when they gather together… It's hard, extremely hard to publish faultless artifacts on a collective work. And as time goes by, things that used to work stop working because something else had to change. And this includes KSP itself. I agree that some borks are easily avoidable with some extra efforts on the "development process", but others, frankly, are unavoidable - things we think will happen sometimes just don't happens , or happens in the exact opposite way. Some times, you just can't win - all that remains to be done is to lose the less painfully it's possible so you can fight another day. What doesn't means that we can't work to make things better - or less worse in the worst case. We fix the small thingies, and there're less things to be fixed by people that knows better that things. Well, enough chitchat. Let's get our dirty paws dirtier: [ERR 10:47:17.362] AssemblyLoader: Exception loading 'B9_Aerospace_WingStuff': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 This is the root cause of your problems. My best guess is that WingStuff is missing a dependency: System.IO.FileNotFoundException: Could not load file or assembly 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'KSPUtil, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' If I'm right, by installing KSPUtil the WingStuff will loaded fine - and then the Mono's bug on the Reflection will not be triggered, and then KSPe will not be killed by the bug, and then everything else that uses it will work fine. Yeah, this is sounding as an Aircraft Crash Report at this time…. — — POST EDIT — — Incredibly (or not that much), I just realized that I had analysed the wrong KSP.log! Interesting enogh, it had the exact same problem as yours, except that the guy was using KSPe while you, in reality, is not. Well, not so Interesting - I'm archiving the KSP logs sorted by bug, so picking the wrong one is easy. (getting old is a pain in the SAS)

Thanks! Let's see what's there (it's the right one): [LOG 07:33:22.157] [TweakScale] INFO: TweakScale::WriteDryCost: Concluded : 3 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 0 Show Stoppers found; 16 Sanity Check failed; You are good, no FATALities. That 16 Sanity Check means that there're some parts that TweakScale doesn't knows, yet, how to scale correctly - so I withdrew TweakScale from them to prevent nasty collateral effects (zero mass, negative mass, bad scaling). I will implement it soon, details on the roadmap. Ignore these for while, these messages will vanish gradually on the next releases. That three failed checks may be or not a problem -it's not knowing the real problem: [LOG 07:33:22.101] [TweakScale] ERROR: part=wheelReg (TR-1L 25" Ruggedized Vehicular Wheel) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object [LOG 07:33:22.101] [TweakScale] ERROR: part=wheelReg2 (TR-1L 22.5" Ruggedized Vehicular Wheel) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object [LOG 07:33:22.102] [TweakScale] ERROR: part=wheelReg3 (TR-1L 25" Ruggedized Heavy Duty Wheel) Exception on Sanity Checks: System.NullReferenceException Interesting. They are from Grounded: [LOG 07:33:22.101] [TweakScale] ERROR: part=wheelReg (TR-1L 25" Ruggedized Vehicular Wheel) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object [LOG 07:33:22.101] [TweakScale] ERROR: part=wheelReg2 (TR-1L 22.5" Ruggedized Vehicular Wheel) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object [LOG 07:33:22.102] [TweakScale] ERROR: part=wheelReg3 (TR-1L 25" Ruggedized Heavy Duty Wheel) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object However, I'm using Ground too on my installments and this doesn't happens to me! Before blindly trying removing Add'Ons, I think a better initial approach would be checking your ModuleManager.ConfigCache (its on GameData/ModuleManager.ConfigCache). Publish it and link it here, so I can give a peek on it. With luck, I can understand what's happening and eventually improve the Sanity Checks! Scale safe!

Just some thoughts about this issue, but using an equally famous and iconic game. Elite 1 was fantastic. People even spent some money on extra hardware (BBC Micro's Tube Processor) for extra juice. Then Elite 2: Frontier came, and smashed Elite 1. Elite 3: First Encounters were a very significant evolution, graphically smashing Frontier. And now, from the same author (David Braben), Elite Dangerous simply obliterated everything else on the family. I own all of the games. Legally. Yeah, I'm that old. Spent most of my time playing First Encounters. I should have about 2 or 3 hours on Dangerous, but I spent a whole year playing First Encounters when they reengineered it to run on high resolution graphics on Windows in 2010 more or less - in 1995, when I bought the game, I was attending college and had little to no time to play with it. Now? I'm playing KSP. My point is that it's highly premature to say anything about how KSP 2 will affect KSP 1 and vice versa. It's unlikely that every KSP 1 player will migrate to 2, and I can say with reasonably confidence that some KSP 2 will end up coming back to 1. To tell you the true, there're die hard Kerbonauts still playing 1.3.1 (and I know of at least one that were using 1.2.2). There're people playing First Encounters until this date, by the way. https://www.frontierastro.co.uk

That's the point - I want to game my system, that's why sandboxes are meant to. I don't mind a milestone gaming approach, I just don't want it to myself. There's Career, Science and Sandbox modes on KSP1. I hope KSP2 have similar approaches. Or Total Annihilation! Every single multiplayer game I ever spend some time suffer from this syndrome. But yet, it's not really a concern to me as long I have the option of not needing that feature for game progressing. I don't mind having people accomplishing things in easier ways than me - I'm not a trophy collector. hummm…. Perhaps we are guessing a yet non announced feature? Trophies? That would be a good reason for "preventing people from gaming the system". So you are talking about another guy. Or are trying to poisoning the well by inducing people to think I'm talking trash when I'm not.

Being the only reason I could be talking about, as that guys are under a Non Disclosure Agreement - so they will never tell us. "I don't need to outrun the bear. I just need to outrun you." I don't mean to be accurate. I mean to be reasonably not too wrong.

What makes you think I can't? What makes you think I don't know about software projects? What makes you think I don't know how many time are needed to such project, or that I don't know since then they are working on it? Star.Theory are not the first Company to be built from scratch to a new big project. You see, the Game Industry has some decades by now. There're a whole World that you don't know out there - a World of experienced people able to do reasonable good guess based (or biased) on knowledge gathered over the years. This doesn't makes such persons automatically able to correctly predict the what's happening - but it helps to have a reasonable idea, and once you learn that you don't need to be right all the time, but it's good enough to be not too wrong, you will learn that such speculations are not only an exercise of the intellect - but actually fun!

It was a straight and direct question: "Will KSP 2 have micro-transactions?", not a vague one. The dark side: the wording is not straight. A "No, as well we will not do in-game currency and loot boxes" would be enough. But they choose to say "a multitude of micro-transactions", not only 'micro-transactions". Of course, this can be the result of a marketing guy doing what they were trained to, so I took it with a grain of salt. The bright side: they answered it at all. I may not had liked the answer, but they did answer it. And upfront answered two another concerns (loot boxes and in-game currency). And these ones, were done straight to the point. I think we can be cautiously optimistic on the matter.

I agree. I initially though on Xmas 2020 not only for the season sales, but also due the work I expect to be done on ironing out bugs, glitches and mishaps that every big project as this one are prone to. On the other hand… And I'm guessing here, perhaps they want to iron out the problems with the users so in the hot sales season, they have already a solid product to sell. Perhaps they want to easy a bit the burden of launching a new, unproved product on the Xmas seasons (as it happened with KSP 1.6). In a way or another, KSP has a tradition of incremental features deliverables. As long they don't go No Man's Sky style, I think they will be good. Designing a game, and implementing that game, are two tasks that usually are better tacked down by different people with different expertises. But since the best engineers never goes to the Space, I will not dare to even cogitate that we saw all the development team on that Video. So my speculations on the matter ends here. I think, and frankly I don't know if I want to be wrong or right on this, that KSP2 will be a somewhat different game than KSP1 - besides sharing a common conceptual base. It will not, definitively, be the same game and that's already a fact. Colonies will grow by reaching milestones, not by management over time: you do something remarkable, Kerbal Babies are born. I don't exactly like this approach, I'm more an "design and manage" kind of people. But there's always the Sandbox - let's see how they managed (if available) a Sandbox game option. I don't really mind KSP2 having a multiplayer option. I agree with you, and I will probably not use it all all after one or two sessions. I'm a bit concerned about the tight time window they have to do all of that, and also a multiplayer mode - but as I already said, KSP has a long tradition of progressive deliverables - and perhaps these features will be added in successive releases. Perhaps a "final product" would be ready only for Xmas after all. I also agree with you on the user's expectations concerns. They do that progressive release of features the wrong way, they could get somewhat burn when the Big Season comes. But this is a risk on both ways, so perhaps this early access approach ends up being the best (or lesser worst?) option. I have a full dollar of concerns . Believe me, you are in better shape than me!

In your case, SXT, RO and/or "Stock" i.e. KSP itself. TweakScale was the Messenger for problems that it cannot handle, so new TweakScale versions will not help on these. The only situation I'm aware that a hot-fix can be deprecated by updating TweakScale is when the problem is a TweakScale patch (as the M2X and M3X patches that should be gone, and one or two more in the past that are fixed now). These, I will advise on the TweakScale new Release Announces.

Obligatory mention:

Did you deleted the current installed KSP before trying it? I never used this feature, however - I prefer to use Steam Console.

Exactly. What could mean the API manipulation to reach that, by preventing any "competition" to be stable. I don't wanna to get into technical on this, but the industry is full of examples of such things (lets use DR-DOS versus Microsoft on the Win3 era as an example). So I'm very skeptical that micro-transactions will be used on the game, as this potentially would push away content Authors they, apparently, intent to gather with. On the other hand, the wording appears to carefully avoid closing such door. My opinion? It's implied by this time. Yes, the wording is carefully crafted, but the logic tells me too that the historical need of content Authors to keep the eco-system satisfied on an indie game strongly implies that it's unlikely that micro-transactions will be used in the near future on KSP2. Of course, I'm not even touching the DRM questioning, that would weight somewhat on my opinion. — post edit — Anyway, as Carl Sagan said once: "Absence of Evidence is not Evidence of Absence." — when explicitly asked by an evidence of absence of micro-transactions, they gone silent on the issue. So I hardly blame anyone here for speculating about.

Exactly! Who didn't said that you were not capable of understanding a so simple concept? Well, I'm not saying neither that you are a rational human being, capable to understand simple sentences and understanding the concept of subtexts. Not an argument to that. So It's logical to ignore you, and keep the conversation with the ones here that know how to argue without poisoning the well, appeals to authority or spin-doctoring.

Your logic it's flawed. The GP has a point. By carefully choose of words, you can say sonething to induce people to believe you have answered a question without really doing it. The wording is clear: there will be not ingame currency, but no words about micro-transactions means that they DID NOT answered the question about it. So by logical inference, it's a "maybe". I see some problems on a friendly modding game that have some kind of micro-transactions: How to prevent Add'ons to provide the fearure you intended to earn some money from? — POST EDIT — I heard from here that there will not be DRM at least on Single Player. Without DRM, micro-transactions are unfeasible. There's still a chance that DRM would be applied to Multiplayer - what's make sense. So, if micro-transactions will be ever implemented on the game, will be on the Multiplayer.

PC Gamers article about Colonies and Population Growth aka "How Kerbals Make Babies" https://www.pcgamer.com/amp/kerbal-space-program-2-dev-reveals-how-baby-kerbals-are-made/ I hope there's a Sandbox style game too. I don't see me having the time needed to do things as it was described.

Welcome! 1. Yes. This is the reason for that pesky warning when a hot-fix is found. About knowing when.. Well, every time the affected Add'Ons are updated, you will need to delete the hot-fix and fire up KSP to see what happens. As long you don't load any savegame, no harm is done. 2. For the problems we solved now, for your current instalment, just the SXT cockpits are liable to problems. Anyway, I strongly advise to use SAVE (link in the OP). If something blews under the bonnet, SAVE will save the day while I fix any damage for you on the backup (once a savegame load and bork, the salvage is terribly harder)

Find and publish the unity log. Use the MacOS Console tool to easily find it (open spotlight, type Console). On Console, look for Unity and inside you will find the log. Publish it on Dropbox or similar and post the link here.

Yes. But with issues. It's better to use 1 4 or 1.5 due more compatible parts (parts with MODULEPARTVARIANT is the problem, it does weld weird). Once you weld, the part can be moved to newer KSPs. You need to use ModuleManager 3. The tool is not working on newer KSP due Module Manager 4 had changing something that broke the tool on the guts. There are alternative versions for them on http://Github.com/net-lisias-ksp but they're as is, I provide minimum support for them as I have my hands full at the moment. There're proper links some pages behind, i'm on mobile now. Found it. https://forum.kerbalspaceprogram.com/index.php?/topic/96670-14-253-2018-04-06-ubiozur-welding-ltd-continued/&do=findComment&comment=3641992

I found this on YouTube. Looks good, pretty good. Pre alpha screenplay. I didn't checked the source. POST EDIT — They put the video in private. POST POST EDIT -- Someone else found a new copy.

Hi. Sorry for that. I'll need the KSP.log and most of the time the GameData/ModuleManager.ConfigCache too (it helps to cook HotFIxes and Overrules when needed). I found this tutorial that will explain how to locate the folder in which installed KSP from the Desktop Icon you use to launch the game - these files will be there, together the EXE file. Be careful to do not move out anything from there by accident. Open an account using DropBox, Google Drive or any other file sharing service, publish the link here and then I can check these files to see what's happening. Don't worry, no savegame is left behind around here. We will fix things for you. (but I need that files first!)

Got it. Sorry for that. Your log says: [LOG 23:52:43.579] [TweakScale] WARNING: **FATAL** Found a showstopper problem on batteryBankMini (Z-200 Rechargeable Battery Bank). [LOG 23:52:43.580] [TweakScale] ERROR: **FATAL** Part batteryBankMini (Z-200 Rechargeable Battery Bank) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 23:52:59.754] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTInlineAirIntake (XM-600 1.25m Air Intake). [LOG 23:52:59.754] [TweakScale] ERROR: **FATAL** Part SXTInlineAirIntake (XM-600 1.25m Air Intake) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 23:53:27.954] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTOsaulNoseCockpitAn225 (An-124 Cockpit). [LOG 23:53:27.954] [TweakScale] ERROR: **FATAL** Part SXTOsaulNoseCockpitAn225 (An-124 Cockpit) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). [LOG 23:53:27.955] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SXTOsualRadCockpit (An-124 Cockpit Radial). [LOG 23:53:27.955] [TweakScale] ERROR: **FATAL** Part SXTOsualRadCockpit (An-124 Cockpit Radial) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). These are essentially two problems: a older SXT version (the newest release has this fixed, pleas update it), but also the exact problem of the fellow Kerbonaut above. I have a patch for this problem, however by some reason that patch is not working exactly as I expect, and I'm tweaking it to make it work properly. Stay tuned, I'm working on it right now. In the mean time, update your SXT to the latest (link to SpaceDock). This will solve all the FATALities, but one - the one I'm working on the patch now. — — post edit — — I finally came to terms with the patch - it was, well… a kind of silly typo - I used a "@" when should had used a "%", and didn't realized the mistake until our fellow Kerbonaut @Buflak found a second way to solve the problem - and then a ring did bell somewhere in my dull head. @The Kerbal King, this will solve the RO glitches on your installment: Download this file. (click on "Raw"). Move it to a directory under your GameData. I suggest GameData/__LOCAL/TweakScale/HotFixes - but anyone will do. You must remember where you put, however, as eventually it will not be more necessary and then it can harm the game. It's the reason an Advise will popup on startup when HotFixes are active. Sorry the late. I intended to publish this by morning, but ended up waking a bit late today and just managed to find time now. Kick me here if you need more assistance. Scale safe!

Well… If the RO guys would agree on following the MM rules for patching, that would help. We would not had the need to applying that patch at first place. The patch needs a :NEEDS to avoid patching TweakScale on systems without it, and a way to make sure it is applied after TweakScale ones. — post edit — I failed to correctly explain all the problems with that patches. The :NEEDS is the lesser of them, the real problems are that RO's patches are being applied without using "%", what ends up adding up a new "type" datum on the module's section. This is what triggering the #34 FATAL error, as this is, essentially, what makes things indeterministic while patching: relying on Module Manager's legacy patching, then blindly applying new values without deleting/editing the older ones disregarding whatever is there. And this is also the reason I can't, now, just shove the "::FOR" on TweakScale patches and solve some problems for good. A lot of patches are doing exactly like this, and the exactly instant I publish patches using ":FOR", TweakScale will not be run on legacy anymore, and an awful amount of patches will silently FAIL and then people will say "TweakScale works funny with specific parts." "T" is on the end of the alphanumerical ordering, right? Everything named before TweakScale will just break. — — post post edit — — A full explanation about how to fix these patches were already discussed on this post.

On that we have an agreement! @PART[batteryBankMini]:FOR[RealismOverhaul] // Good for ReStock { %RSSROConfig = True @RESOURCE[ElectricCharge] { @amount = 20500 @maxAmount = 20500 } @mass = 0.07731 @MODULE[TweakScale] { type = RealismOverhaulStackSolid } } https://github.com/KSP-RO/RealismOverhaul/blob/master/GameData/RealismOverhaul/RO_SuggestedMods/Squad/RO_Squad_Electrical.cfg