Lisias

NOTAM Well, it's a bit embarrassing, but sheet happens and people borks. So do I now and then…. Since 2.4.6.10 TweakScale is trusting KSP-Recall to keep KSP on its toes, applying fixes and patches for KSP's idiosyncrasies so TweakScale can focus on its core business (scaling) instead of trying to survive such idiosyncrasies (not to mention doing things in a way that could damage 3rd parties the same way KSP did to TS). However… I missed a detail… When KSP 1.9.0 came and royally screwed up TweakScale on Editor, I didn't fully understood the problem at that time (I had less than 2 years of KSP modding at that time, I was still a rookie on this business) and ended up concluding it was a change on the KSP engine (and not a bug on Editor), so while doing my attempts to understand the problem, I ended up with a kludge on the Scale Engine core that resulted on things happening the way I intended on KSP 1.9. But that broke scaling for KSP < 1.9 (in special, KSP 1.4.4 to 1.7.3), what I "fixed" by adding yet another kludge on the Scaling Engine for [1.4.4 <= KSP <= 1.7.3]. Then, recently and after 2 years developing KSP-Recall, I became (hopefully) more experienced on this thing and realised that what I was doing on TweakScale was way less than ideal. Then I coded a proper work around for the problem that was screwing up TweakScale on KSP-Recall (this one reusable to every 3rd party with the same problem if needed) and released TweakScale 2.4.6.10. But... I forgot to remove the second kludge, and the after math is that TweakScale started to misbehave from KSP 1.4.4 to 1.7.3… (sigh). This appears to explain why I detected some increasing usage of older TweakScale versions (as 2.4.5.x ones) in the last months…. Oh, well… At least people found their way around the problem. To reflect this, I downgraded TweakScale 2.4.6.10, 2.4.6.11, 2.4.6.12 and 2.4.6.13 on CurseForge to be compatible only on [1.3.0 <= KSP <= 1.4.3] and [KSP >= 1.8.0] . TweakScale 2.4.6.8 and earlier should be fine (pending verification). On the bright side, now that I know about the problem, I published a (hopefully) fix on the TweakScale BETA 2.5.0.44 (available only on github). Brave Kerbonauts that don't fear the Krakens are invited to beta test it on every supported KSP version for eventual bugs I may had allowed to pass trough - the Scaling Engines were significantly simplified on the process, and I think it's safer to spend some time double checking things before publishing a proper release with the fix. For people willing to further learn about the problem, see https://github.com/net-lisias-ksp/TweakScale/issues/249. Cheers.

Found it! [LOG 11:20:09.486] AssemblyLoader: Loading assemblies [WRN 11:20:09.488] AssemblyLoader: Assembly 'Kopernicus' has not met dependency 'ModularFlightIntegrator' V1.0.0 [WRN 11:20:09.488] AssemblyLoader: Assembly 'Kopernicus' is missing 1 dependencies [ERR 11:20:09.620] ADDON BINDER: Cannot resolve assembly: Kopernicus, Culture=neutral, PublicKeyToken=null [ERR 11:20:09.620] ADDON BINDER: Cannot resolve assembly: Kopernicus, Culture=neutral, PublicKeyToken=null [ERR 11:20:09.626] AssemblyLoader: Exception loading 'ParallaxSubdivisionMod': 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 'Kopernicus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'Kopernicus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' Parallax could not be loaded because Kopernicus wasn't loaded, and Kopernicus wasn't loaded because you forgot to install ModularFlightIntegrator! Install ModularFlightIntegrator and things will be fine! Cheers!

A lousy dependency handling is a sure way to ruin your gaming experience - unless you have a part-scaling mod that yells when this happens so you can fix it before it ruins your gaming experience.

Fact. But on the other hand, Cyberpunk didn't had to cope with a Series of Unfortunate Events™ as KSP2 is coping now. This was precisely my thinking until this year's early February. Right now, given a lot of uncertainty on the World's politics, economics and some other situations I don't think it's worthing to be mentioned here, I suspect that delaying the game could improve their chances of success. Of course I can't talk for anyone else but me, but I'm going to have a hell of a year - whatever happens to me, however, will be done at the end of the year at most and next year will the the year in which I will start recovering. So, nope. I'm not going to spend too much money on gaming for some time (unless things changes dramatically in the next few months, but experience taught me to be conservative). I know some people in the exactly same situation, and if people enough are on the same boat as me, this may impact the market for sure.

O probably had share it already, but hell, I love this music. Hunger Strike, Temple of the Dog.

Yes, it's on the back log to support (or at least to try!) Stock Plumes: https://github.com/net-lisias-ksp/TweakScale/issues/27 It's taking a bit longer than I had anticipated, however… In the mean time, you can install SmokeScreen and RealPlumes-Stock . TweakScale is supported by SmokeScreen: On the other hand, Waterfall is also supported (with a glitch… ) by installing TweakScale Companion for Frameworks: https://github.com/net-lisias-ksp/TweakScaleCompanion_Frameworks/releases The thing has a glitch that I still didn't managed to fix: when reverting to launch, the Waterfall effects lose the scaling… But other than that, it works.

ANNOUNCE KSP Recall 0.2.2.4 is on the Wild, featuring: Closes issues: #41 Investigate a possible (bad) iteraction with Procedural Parts (RO) V2.3.0 #37 Check about a missing use-case on AttachedOnEditor #21 Update KSPe.Light for KSPe This release, besides with minimal changes, was really worksome and stressful. One of the problems on trying to work around systemic problems is that you end up triggering or diagnosing unrelated problems from 3rd parties that not only are usually not obvious (and so people resist to acknowledge them), but could be also the trigger for some of the systemic misbehaviours I fighting against. I will decline to further discussing the matter here, as it's everything documented on the respective issue. But it's enough to say that everytime you disrespect the KSP's Life Cycles (and there's a bunch on this game), you are potentially screwing up someone else (usually KSP itself). The Editor bug from KSP 1.9.0 to nowadays that royally screws up TweakScale is a perfect example of the problem. So, breaking a long standing tradition of tackling down only KSP idiosyncrasies on KSP-Recall, this release also offers a fix (and this is a fix, not a work around) to a 3rd party add'on, as the upstream didn't acknowledged the issue as a problem and not tackling it down myself would render the add'on under discussion unusable on rigs where KSP-Recall's AttachedOnEditor must be used. Making things somewhat harsher, while diagnosing the problem I ended up agreeing on being a beta tester for some 3rd-parties' add'ons to avoid having KSP-Recall (gratuitously, as the problem was detected on them - Recall was the screaming victim of the problem) declared as a Conflict with them - what essentially would render TweakScale unusable for some users - unless I would reintegrated the fixes on TweakScale (with all the problems it would incur), but that will make TS triggering the same problems and so on the long run, TweakScale would also be declared a Conflict. Given the options imposed to me, the less worst option was agreeing on beta testing some 3rd-parties add'ons on KSP-Recall. This extra burden will, definitively, delay future KSP-Recall releases (the same way this very simple release was delayed by a full month). On the bright side, all that fuss uncovered a missing use case on AttachedOnEditor: if the attachment node's positions were uninitialised during the OnLoad phase, so the orientation and the size were too! So now AttachedOnEditor is also recovering them. Last, but not least, I want to make absolutely clear that the development of KSP-Recall fully respects Forum rules, the KSP EULA, USA and Brazil's Legislation - in crescent order of significance. And this will not change. No borderline legal or potentially EULA or Forum policies infringements practices are allowed on KSP-Recall (not because I consider them imoral, but because some few others may consider them ilegal now or in the future) - I'm making every possible effort to be sure KSP-Recall can be legally downloaded and used on all countries on the World (specially the ones with draconian copyright laws as mine). I'm not anyone's (but my own son) father, tough. I'm not telling you what you should or should not download and use - use your own discretion on deciding what's best for you. — — — — — This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right Now. CurseForge. Not too Soon™ SpaceDock (and CKAN users). Eventually™ The rationale is to gradually distribute the thing in order to prevent something I could let pass trough to spread too much before being detected.

You (and Parallax) are being bitten in the SAS by a nasty KSP bug on the Assembler Resolver thingy yada yada yada. TL;DR. when something borks being loaded due a faulty dependence, everything else trying to load something (or to use a thingy called Reflection) borks relentlessly due the bug. And since TweakScale makes heavy and critical use of exactly these two things. TweakScale yells when it detects this happened (because a faulty TweakScale will ruin your whole savegame). Publish your full KSP.log on dropbox or something, and I will inspect it looking for the troublemaker. Chances are that there's a dependency missing somewhere, or perhaps something else conflicting with Parallax and then triggering that KSP bug I mentioned above. Cheers!

You almost surely is being victim of a nasty KSP's bug on the Assembly Resolver (yada yada yada). But since I just realised you had posted on TweakScale's thread, we will further expand the subject there. TweakScale is the very thing preventing a lot of problems from screwing up the user's savegames - because it yells on anything that can cause harm, instead of letting things go as they are hoping for the best. Even by not using it, by merely having TweakScale installed a lot of problems will be detected before causing harm - and just it already worths having TweakScale installed!

Thanks for the thorough report! The problem was diagnosed, apparently something needs to be implemented. I moved the issue to the TweakScale Companion that will be in handle of Fuel Switches. I'm planning to work on it on July (pending agreement with Real Life™), there're more Fuel Switches in need to be properly supported (and withdrawn from the TweakScale main codebase as it's know, as it's too much hacky to be maintainable). https://github.com/net-lisias-ksp/TweakScaleCompantion_FuelSwitches/issues/2

Hi! I'm regularly diagnosing issues on TweakScale's thread about SandCastle, and I finally realised the reason. ExtraPlanetary Launchpads is a hard dependency on the ELHelper.dll library. [ERR 10:08:57.830] ADDON BINDER: Cannot resolve assembly: Launchpad, Culture=neutral, PublicKeyToken=null [ERR 10:08:57.843] AssemblyLoader: Exception loading 'ELHelper': 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 <46478292153440df94e04a2a2ddd1062>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'Launchpad, Version=6.99.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'Launchpad, Version=6.99.0.0, Culture=neutral, PublicKeyToken=null' Problem: since KSP 1.8.0, when a DLL fails to be loaded it triggers a bug on the KSP's Assembly Resolver yada yada yada. TL;DR. when something borks being loaded due a faulty dependence, everything else trying to load something (or to use a thingy called Reflection) borks relentlessly due the bug. And I mean everything else (it only happens that TweakScale yells about the problem instead of ignoring it). Checking on the SandCastle's source code I confirmed that ExtraPlanetary LaunchPads is a hard dependency of ELHelper, i.e., you need to have ExtraPlanetary Launchpads installed otherwise the ELHelper will not be loaded, and then it will trigger the KSP Bug on Assembly/Resolver, and then everybody else in need to load a dependency or use Reflection will be screwed up. Interesting enough, Sandcastle.dll itself appears to do not use neither ELHelper neither ExtraPlanetary LaunchPad. What I confirmed by removing ELHelper.dll from the plugins folder and firing up KSP sucessfuly. So we ended up with two choices: Declaring ExtraPlanetary Launchpads a hard dependency, and not only a suggestion Removing ELHelper.dll from the distribution file, and providing a package to be installed when both SandCastle and ExtraPlanetary Launchpads are present Otherwise, installing SandCastle on any rig without ExtraPlanetary Launchpads will render KSP in a inconsistent state, triggering folly exceptions on any other 3rd party Assembly that tries to load a dependency or to use the C#'s Reflection.

Life imitates art Kerbal. looks like a MK2 Cockpit, by the way...

It's not a conflict. It's a bug on KSP (Assembly Resolver, yada yada yada). Publish the KSP.log and I will diagnose what's triggering it. — — POST EDIT — — I installed Sandcastle to see what I would get. Found this: [ERR 10:08:57.830] ADDON BINDER: Cannot resolve assembly: Launchpad, Culture=neutral, PublicKeyToken=null [ERR 10:08:57.843] AssemblyLoader: Exception loading 'ELHelper': 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 <46478292153440df94e04a2a2ddd1062>:0 Additional information about this exception: System.IO.FileNotFoundException: Could not load file or assembly 'Launchpad, Version=6.99.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'Launchpad, Version=6.99.0.0, Culture=neutral, PublicKeyToken=null' You probably, as me, didn't installed all the dependencies. On my case, the dependency is ExtraPlanetary Launchpads. Mysteriously, EL is listed as recommended, not as a hard dependency - what it is now. @jebycheek, install ExtraPlanetary Launchpads and the problem will be fixed. — — POST EDIT — — Alternatively, you can remove GameData/WildBlueIndustries/Sandcastle/Plugin/ELHelper.dll if you don't want to install ExtraPlanetary Launchpads. — — POST POST EDIT — — Sandcastle's maintainer diagnosed the problem and it will be fixed on the next release! Cheers!

I think that the peak players can be used (with some grain of salt) to estimate that. Once you buy a game, you spend some time on it immediately, If you like the game, you keep playing it - otherwise, you try a refund or just leave it alone on your inventory and forget about (not unusual when you get the game for cheap). It's worth to mention that crossing the peak players timeline with the discount sales one, the peak players usually raises a bit on the sales - suggesting that there's a correlation between these numbers. Interesting enough, the average players usually dropped after these sales on KSP releases that were perceived as bad by the Community, Ok, we need to keep in mind that Correlation is not Causation. But for our purposes here, it's good enough. On a side note, these numbers doesn't reflect my own opinions about the subject. These numbers I mentioned above implies that KSP 1.4.x series were "terrible" - but I play 1.4.3 until nowadays (it's one of my favorites), and most of my long term gaming was done on 1.4.5 and I really enjoyed it (once the most immediate problems were fixed or worked around) . And, additionally, all these metrics by themselves are pretty bleak. Usually we get way better insights about the "health" of the game by comparing it with other games where the market share are known (or with better estimations). Crossing the KSP timelines with games like Flight Simulator 2020 is interesting, as well Hollow Knight. One of them is promoted as online, the other is completely offline. https://steamcharts.com/app/367520 https://steamcharts.com/app/1250410 https://steamcharts.com/app/220200 It helps to try to make sense of the numbers, perhaps mitigating a bit your objections.

Estimated, not defined. Without telemetry, it's pretty hard to infer the real numbers. But the the numbers on Steam drops, it's reasonable to conclude the same is happening to off-line users too.] See above.

Here, I fixed the quotes for you: From where I replied: And I want to emphasise: "as it appears". The whole argument is KSP not being economically viable to fix. One of the possible explanations is the "free everything forever" policy. I assumed his assessment of the situation as valid, and argued that if the "free everything forever" policy is a problem, is because KSP failed to expand the user base to a level in which would be profitable to fix KSP bugs. I want to emphasise (and I ask you to pay special attention on this) that an userbase is not the collection of every single guy that ever bought the game, but the collection of people that are using the game and willing to spend money on it. In 2015/May there was an average of 7,399.9 (yeah, dot nine user ) playing KSP on Steam, and the month had a peak of 19,079 simultaneous players. In last April, the average was 3,307.7 and the peak was 5,512 simultaneous users. I hope I don't have to explain you how this is not exactly a growing user base (besides the April numbers not being exactly bad - there're more expensive games around with way less playing users on Steam). Source: https://steamcharts.com/app/220200 — — IN TIME — — Source: https://comparecamp.com/steam-statistics/ So Steam Charts is an excellent metric to infer the current size of a game's userbase.

Nope. Someone else is, please read the whole sequence of replies. I suggest you read a bit more before doing it.

The number of add'ons is rarely an issue nowadays, we learnt how to cope with complexity as time passed. The number of add'ons you install at the same time is more a risk than anything else, because this is where the uncertainty is. TAC-FS and IFS used to work fine with TS, but I don't remember about Configurable Containers… I will give it a shot in the mean time. EDIT: I tested Configurable Containers with latest TS, latest KSP-Recall, latest KSP itsef and a bunch of random add'ons. Tried the known use cases that used to bork in the past (root as non-variant, etc). It passed with flying colours, I'm pretty convinced that it's something else on your rig - at worst, it could be being induced to misbehave by something else. Here! Roll to the end of the OP and expand the Spoiler on "Support:". Looks like something is inhibiting TweakScale, or perhaps overruling it with prefab values….

Thor. A ship with a thorium molten salt reactor... I'm not convinced they are going to really build this, but this is too good to ignore! https://www.autoevolution.com/news/molten-salt-reactor-ship-thor-breaks-the-norm-with-incredible-capabilities-187654.html

I found this on your KSP.log: [WRN 20:10:39.528] AssemblyLoader: Assembly 'Kopernicus' is missing 1 dependencies [ERR 20:10:39.700] ADDON BINDER: Cannot resolve assembly: Kopernicus, Culture=neutral, PublicKeyToken=null [ERR 20:10:39.701] ADDON BINDER: Cannot resolve assembly: Kopernicus, Culture=neutral, PublicKeyToken=null [ERR 20:10:39.707] AssemblyLoader: Exception loading 'ParallaxSubdivisionModDART': 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 'Kopernicus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'Kopernicus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' System.IO.FileNotFoundException: Could not load file or assembly 'Kopernicus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. File name: 'Kopernicus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' So, yeah, it makes sense. The DART mission used a specialised Kopernicus build IIRC, and it was not compatible with the "Stock" one. Digging further on your KSP.log, I found [LOG 20:10:39.268] Load(Assembly): DART/Plugins/KopernicusDART [LOG 20:10:39.268] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\DART\Plugins\KopernicusDART.dll <yada yada yada yada> [LOG 20:10:39.365] Load(Assembly): Kopernicus/Plugins/Kopernicus [LOG 20:10:39.365] AssemblyLoader: Loading assembly at C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\Kopernicus\Plugins\Kopernicus.dll And it's exactly what you said. What happened is that KSP "short circuits" all duplicated Assemblies into the first one, the DART one in your case. But some other things were linked on the "Stock" Kopernicus that was intended to be loaded later, but was short circuited to the DART one by the Assembly Resolver. Then everybody else that was relying on the Stock Kopernicus borked on loading - and this triggered that nasty Assembly Resolver bug that induces everybody and the kitchen's sink to bork too while trying to load a Dependency... Cheers!

But it does!!! It's working with TweakScale alright! https://github.com/net-lisias-ksp/KAX/blob/master/GameData/KAX/Patches/KAX_TweakScale.cfg And since the very first release. If you are unable to scale KAX besides having all the dependencies installed, publish your full KSP.log and MM Config Cache and I will check what's happening!

Not a problem. But keep in mind that you still have the problem, and it eventually will hit something else. You just installed a version of TS that doesn't complains when things are wrong. Cheers.

Frankly, people in the past used to be a lot more Kerbal, not? But this is one of my favorites from all time! Source: http://www.douglas-self.com/MUSEUM/TRANSPORT/oddtank/oddtank.htm

Try a Steam Controller!! It's absolutely excellent! (once you get used to it… ). Humm… Would the Steam Controller, once configured on the PC, work on a Console?