Lisias

It's my opinion you did. I had argued that KSP2 is the future, and that KSP1 is not a good option for long date players (there's a lot of people sticking on 1.3 and even 1.2). These are statements about the products. Then I argued that Squad appears to be willing to have the Quake, I mean, Cake and eat it to. Squad develops KSP1, so the correlation - besides being implied - sounded evident to me.

Squad is an independent Studio, or at least I found no evidence that they had sold themselves to someone. As far as I know, TTi bough the KSP IP. And exactly what this has anything to do with my original argument?

No. I had looked on the config parts from Squad (both 1.9 as 1.8.x and 1.7.x), and the craft files and persistent.sfs files before and after being converted to 1.9, as well ones created on KSP 1.9 itself. My concerning wasn't about the clamp itself - of course the feature would be working, as some minimal testing is expected to be done by the developers before the code is kicked through the door. The problem I was concerned was the possibility of that value be shoved on config files with default values that could break expected behaviour from living crafts on the persistent.sfs. But since I couldn't find evidences on the feature on that files, this meant that even if we find a bug somewhere on TweakScale about this feature, it will be not a killer one and the crafts file and persistent.sfs will be safe. This is one of that weird situations in which absence of evidence (of the feature) is an evidence of absence of the problem (corruption of the data files). Carl Sagan, forgive me. Complex (sub)systems integration tests is where, historically, KSP was consistently failing in the past. I couldn't be happier by being wrong about this one.

The log on the OP didn't had any crash dumps... It ended apparently normally. =/ Try to use KSP in OpenGL to see what you get. The post below explains how to do it.

NOTAM Our meteorological satellites had gone paranoid and detected storms of less than aromatic substances over our KSP 1.9 instalments. Analysis and checks found no evidence of problems - or at least, noticeable problems - leading to the conclusion that our meteorological satellites need a good revision, or at least to consult a shrimp. The hard part will be to find a psychiatrist willing to be belted on a tin can and be controllably exploded into space. The airspace over KSP 1.9 is open for TweakScale crafts, but proceed with caution until a full featured test session could be executed, probably on the weekend. Now an explanation about the stunt: TL;DR : Proceed with cautious optimism. Nothing exploded, but I didn't tested it thoroughly yet. On KSP 1.6 or 1.7 (I don't remember), a trick I used to use while tweaking craft files ceased to work. I was editing the craft file and switching fuels on some tanks, essentially doing the work of a fuel switch manually, trying to optimize the ratios for the crazy doohickeys I do. What I discovered is that from 1.6 or 1.7 and forward, the data from the prefab started to be injected on the craft file [and living crafts from the persistent.sfs] with default values on the missing data. As an example, I edited a LFO tank and switched it to be oxidiser only. On KSP 1.4 it worked fine, but on 1.7 (and perhaps 1.6?), KSP started to inject back the Fuel on the part, but with 0 units. Now, the Release Notes stated that minimumMass and minimumCost would be defined on the part's cfg. On vanilla parts this would not be a problem, but on TweakScaled parts the minimumMass would make scaled down parts get more mass on KSP 1.9 than on previous games. For example, a Rockomax fuel tank scaled to 1% would be clamped on the physics engine with that minimumMass thingy instead of the 1% of the original mass. This could surely make cubesats and small probes broken. Big crafts would probably not be affected, however. On the bottom line, I found no evidences of minimumMass and minimumCost on any CFG file on the Squad and SquadExpansion folder [using automated tools]. To tell you the true, the few config files I eyeballed are virtually identical to the previous release (1.8.1). minimumMass and minimumCost are defined on the API, however. The default for minimumCost is 0f, and for minimumMass is not defined on the API, but it states that no value less than 0.0001 will be accepted. In a way or another, I found no evidence that these values would be persisted on the persistent.sfs or the craft files. So, even if this is not working properly for scaled down parts (my time window for further testing is over by today), the savegame and the craft file is not being mangled, so no immediate damage will be infringed to these files. But a batch of proper testings are still in need to be done - and I need to teach TweakScale about these values too, what would demand yet more tests. Cheers!

By first run on KSP 1.9 had this freeze - all clicks were ignored, so I didn't proceeded enough to check if the thing would explode. The Task Manager (to tell you the true, the Activities from MacOS) told me that KSP wasn't responding. But the memory consumption wasn't rising neither, so whatever was doing the dead loop that crashed inside KSP, it wasn't trashing the GC. Weirdly enough, I fixed the issue by killing KSP and deleting the settings.cfg file.... Don't ask, it just worked for me.

Well, the article says it can be applied to OpenGL 4.5

Dude, given the marvellous storm (and I will refrain to mention what could be falling from the skies) if by some reason I'm right, METAR is the word - believe me!!

METAR Users of TweakScale are advised to DO NOT update their game to 1.9 for while - or try the update after a FULL BACKUP of all his crafts and savegames (the the KSP itself too!). The following line from the Release Notes may imply that parts being scaled down may (pending confirmation, I will download and check it myself in the next hours) not be cheaper and lighter that the specified "minimumMass" and "minimumCost", breaking your current craft files and also the living ones on the savegame! * Part Mass and Cost now clamp their value to avoid negative numbers results from Mass/Cost Modifiers - configured per part via minimumMass and minimumCost in each parts cfg. This precautionary measure are needed because once KSP loads a craft and savegame, all missing data are injected on the living parts and from that point, the craft and savegames will be saved with the new data - and so, TweakScale could not be able to change it back. An emergencial release, with a lock preventing it to work on KSP 1.9 may be released soon, depending from what I find on the testings. - -- -- POST EDIT -- -- -- Found not evidence of problems. To tell you the true, I found no evidence of the feature itself!

Yes, there're some. It happens there are no technical reason for that. Only political and economic ones. As @RealKerbal3x said above, SLS will provide way more jobs on the industry than SpaceX, and since politicians depends of votes to be elected, it's way more safe to keep SLS workers happy and willing to vote on you. And there's the economic factor: the SLS contractors are big and well established industry workhorses, some of them facing some financial troubles (Boeing, are you hearing?) Shutting down SLS would close a door used by the government to help these jobs behemoths to stay on business, risking them to have to fire a lot of people, badly damaging the country's economy as side effect. What would make a lot of people unhappy. Voting people. And there also a power play factor. Having SLS at hand will keep Bezos, Musk et all under control. They try some stunt, NASA shuts them down and use SLS instead, besides at huge more costs.

Building the next Space Station. I talked about tasks, not roles. Besides, STS was able to bring stuff back to Earth - something that SLS will never will.

To tell you the true, the guy is changing his bets about the future. Not a unreasonable bet, by the way. Until further notice, KSP2 is the future and KSP1 is far from being a safe Harbour for long date users. You can't have the cake and eat it too, and currently Squad appears to think they can. The problem is not what was broken. It's what was not fixed.

Yes. NASA managed to do harder things in the past. It's a matter of gathering the right people to do the job and the recent failures, besides being an embarrassment at best, on the other hand creates the political willingness to allow the right people to do the job. No. It will fulfill some tasks previously carried out only by STS, but it will not be able to be used on every kind of mission STS could do. We can criticise the STS for a lot of things, but the harsh true is that nothing made by man could ever do all the missions STS could do again. You will need a whole new fleet of different existent, in development or just wishing crafts to completely replace STS. It's crazy to compare Falcon Heavy to STS. Heavy is essentially a first stage, STS was the vehicle itself. Perhaps it could be possible to compare StarShip to STS - it will be able to bring back stuff to Earth?

I'm just the messenger!

When I as a kid, I used to think that Rational and Irrational numbers have this name exactly by this! Only at college is that I understand that Rational are Real numbers that you can get by Ratios (divisions), and not because they are reasonable.

Dude, I coud imagine a lot of small portraits on the bottom right of the video with images of scared people screaming their SAS out...

You are OK. What had failed is the Sanity of the part, and so the TweakScale module was ripped off in runtime to avoid unleashing the Kraken. The problem was worked around, you are ok to go. It's the checks failed thingy the problem, as the check itself had borked, and so I could not check the Sanity of that part, and the unknownness is the problem. (philosophical). I think I need to rephrase these warnings...

I think there's something fishy... 0.9999(9) is a Rational number that we got by 9 * 0.1111(1) , being this last equivalent to 1/9. So 0.99999(9) is 9 * 1/9, or 9/9, or 1. 0.9999(9) is already one since the beggining! So it's not considered 1, it is 1. source: https://en.wikipedia.org/wiki/0.999...

In which Set? In Natural and Integers Sets, there's no such thing as 0,99999(9)!! However, on the Irrational Domain, given f(x) = x , Limit(f(x)) when x approaches 1 is considered 1.

Yep. And there's a lot more of needed features on MM that would make life easier for a lot of people too. Not to mention avoiding breaking Add'Ons for no reason.

It's another kind of Warning, let me explain to you: This is the one that triggers the message you posted. (hey, pinky Kerbals? ). These ones are things in need to be fixed, implemented or revised on TweakScale due Modules that changed and stoped behaving as TweakScale expects. What's slightly undesirable, as when TweakScale is fooled by such Modules, it can inject zero or negative numbers on the Mass, and this is essentially the Kraken's favorite food. This one is not an warning anymore. At the time i wrote this, I didn't knew yet this was harmless. Good catch, I need to transform this on a INFO message. -- -- -- Now, the warnings I'm talking about on this post is like these one: It's the bottom right Dialog Box. And the warnings in question is like this one: [LOG 19:11:07.729] [TweakScale] ERROR: part=roverBody.v2 (Probodobodyne RoveMate) Exception on Sanity Checks: System.NullReferenceException: Object reference not set to an instance of an object at ConfigNode.CopyToRecursive (.ConfigNode node, Boolean overwrite) [0x00000] in <filename unknown>:0 at ConfigNode.CopyToRecursive (.ConfigNode node, Boolean overwrite) [0x00000] in <filename unknown>:0 at ConfigNode.CopyToRecursive (.ConfigNode node, Boolean overwrite) [0x00000] in <filename unknown>:0 at ConfigNode.CopyToRecursive (.ConfigNode node, Boolean overwrite) [0x00000] in <filename unknown>:0 at ConfigNode.CreateCopy () [0x00000] in <filename unknown>:0 at GameDatabase.GetConfigNode (System.String url) [0x00000] in <filename unknown>:0 at TweakScale.PrefabDryCostWriter.GetMeThatConfigNode (.Part p) [0x00000] in <filename unknown>:0 at TweakScale.PrefabDryCostWriter.checkForOverrules (.Part p) [0x00000] in <filename unknown>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00000] in <filename unknown>:0 And they generate a Report on the logfile as follows: [LOG 19:11:07.775] [TweakScale] INFO: WriteDryCost Concluded : 459 parts found ; 1 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 0 Show Stoppers found; 9 Sanity Check failed; 97 unscalable parts. See the "1 checks failed". Until today, I didn't had properly diagnosed this thing. In the past, it was happening due Making History adding some entries on GameDatabase at the Main Menu launch, that it's also where TweakScale does the Sanity Checks and the Dry Mass calculations - and so I had to overcome a race condition (ugly code, but it did the job). But now I have yet a new problem with the same symptom. But this one, I know how to fix properly now!

Yep. It's the reason I used emoticons, the whole thing is intended to be a joke on the Functors Theory, Subtraction would be "only" an Addition's endofunctor to itself. Subtraction is a stunt needed only for Natural Numbers (with reserves - there're no possible solution for "1 - 1" for Natural Numbers, as it doesn't have the Zero). Once we stablished the concept of Integers, subtraction is essentially only a special case of Addition. Subtraction isn't even a Property for the Natural Numbers, and (N,+) is a mononoid besides its identity element being a number that doesn't exists on the Natural Set - and this is a whole new subject for yet more infamous jokes!

You can bet your KSC it works. But we still need to diagnose the problem. We need better development and QA tools for Add'On Authors and Maintainers. A good, extensive and detailed KSP.log is just part of the solution - besides being the most important one. We need better tools. A post-mortem analysis tool is way more feasible with a consolidated log file. Spreading logs everywhere just make things worse for automated tools, as now we need not only to parse the log - we need to parse many logs and do cross-checking on them. Not to mention that KSP is a very complex collection of subsystems, and some errors are only diagnosed by analysing the events that happened before that thingy blew -- splitting logs make detecting these things almost impossible, unless you remerge all that data again (risking messing up the order of the events, and so, making things even harsher to diagnose). More code to write and do proper QA, not to mention more code to fix every time some happy-trigger code-monkey thinks it's a good idea to add or change some log format. That said... A tool to split the KSP.log in many different specialised reports, each one tailored to a specific need is a good idea. And it can even happen at runtime, as even Windows have named pipes nowadays. Let the detection tools shove all the data on the KSP.log, so each developer can write (and share) the Reporting Tools that better cope with the problem at hand.

Would be a waste of I/O, the needed info is already available somewhere else! Nope. I would had diagnosed this thing more than an year ago if MM was catching such a mishap. Well, I don't know enough (yet) about GameDatabase to be absolutely sure that a node's name should not be null or empty (""), but at least a warning I will implement on my personal fork to see how things develop from here. But it would help a lot the maintainers to diagnose the problem, not to mention the developer in detecting it before making a release. In a way or another, once a warning or error is logged on KSP.log, the MM's Config Cache has a dump for the affected part - and this helps on diagnosing the thing. Once we know what's happening, is way easier to find where it happened.

METAR I finally found at least one reason for the infamous parts failed being checked! (do not misunderstand it to parts failing the check itself) Some borked patches are injecting NULLs on the node's name, and since every single node needs a name in order to understand what's inside, this is a bug - at least for TweakScale. The first case with a successful diagnose (and fix) is on the spoiler. People getting the Warning above is advised to reach me here posting the KSP.log on dropbox, google drive or something. Now I know what to look for!