Lisias

At the present state, no. Scaling Breaking Ground parts is terribly trickier than it was by Infernal Robotics (that, by the way, implemented its own support) apparently due some implementation choices made by Squad (some other people is also trying to do so, by the way) - and this can potentially ruin savegames for good in a pretty similar way it happens with the Docking Ports now. And I also need some free time to focus a proper Clean Room Implementation for this (what's demand a lot of time), as the alternatives are not EULA (and Forum Rules) compliant and I don't want to get myself in hot waters. Hi. Let's see what's happening…. [LOG 08:10:12.572] [TweakScale] INFO: WriteDryCost Concluded : 2041 parts found ; 14 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 4 Show Stoppers found; 0 Sanity Check failed; 891 unscalable parts. [LOG 08:10:12.575] [TweakScale] "Houston, we have a Problem!" about show stoppers on patching was displayed You have 14 checks failed (what my not be a problem, the problem is that TweakScale could not check them), but what's really biting your SAS is that 4 Show Stoppers: [LOG 08:10:12.324] [TweakScale] ERROR: **FATAL** Part cargoContainer (SEQ-9 Container Module) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 08:10:12.324] [TweakScale] ERROR: **FATAL** Part smallCargoContainer (SEQ-3 Cargo Storage Unit) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 08:10:12.400] [TweakScale] ERROR: **FATAL** Part spotLight1 (Illuminator Mk1) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 08:10:12.401] [TweakScale] ERROR: **FATAL** Part spotLight2 (Illuminator Mk2) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 What it's exactly the same problem above. Some pretty old version of TweakScale were installed before and some deprecated left-overs are lingering on your installment after installing the new release, leading to these double patching. Completely remove the TweakScale folder and reinstall it from scratch. This will solve the 4 FATALities. About the other 14 "checks failed", I'm working on it. They are not necessarily a problem, but I will check why TweakScale is not being able to inspect these parts - just in case. — — POST EDIT — — @Xeithr, I made a clean install of KSPIE, then updated TweakScale, and found anything on the logs about TweakScale remotely similar to what I found on your log. So whatever it's happening, it's related to a 3rd party add'on - and I'm currently unable to keep pursuing this due my other duties (both on RL and on KSP). But since these are not FATALities, I think you are good to go nevertheless. On the other hand, I found something on your log (completely unrelated to TweakScale but that affected the distribution file) that, well, was my fault (somehow - didn't understood yet how it happened). So, thank you for your log - you helped me a lot on this obscure issue that I completely missed. Cheers!

Not a problem! Welcome back and Scale Safe! ---- POST EDIT ---- In time, check also the TweakScale Companion Program Thread. Another change that may bite you is that updated support for 3rd party add'ons are migrating to specialized "plugin's plugins". If you use any add'on that have a Companion on Release or Release Candidate status, you should install that Companion to get up to date support!

From someone that know the code, the problem is - frankly - lack of time to keep track of every change, every glitch, every workaround to avoid breaking things (and I will not even mention the need to do some non exactly Forum approved practices to really understand what you are doing, what recent happenings suggests is not exactly advisable - and the licensing terms of this work doesn't help on the issue neither). Handling all that is not fun - hardly something that someone would do for free on his/her leisure time -a pretty scarce luxury nowadays for some people (usually the ones that would be best qualified to handle these problems).

There's a file called KSP.log on your KSP's root directory, a file called MMPatch.log (or something) on KSP_root/Logs and a file called ModuleManager.ConfigCache on KSP_root/GameData . Please zip these files and post the zipfile on DropBox or similar service, and give the link. I will check these files and get into the problem for sure. — — POST EDIT — — Humm… Before that, completely remove TweakScale folder from your gamedata, and reinstall it (assuming that you didn't did exactly that on installing/updating). You may have a pretty old patch file lingering on that directory (I mean, really pretty old - probably older than an year) - but it's just a guess, I will only really know what's happening by inspecting that files I mentioned.

Ugh. Duplicated patches, it's some time since I had this thing happening around here. The problem with these doubling patches is that the patching was done uncontrollably, and it's unfeasible to know what was te right patch after the fact and, once you start a game with a patch set, you are committed to that patch set under the penalty of having your crafts unbalanced or even ruined by the different rules. So we need to be pretty picky about this, and anything weird detected is promptly yelled at. Well, yes. If you manage to remember all affected parts, by not using you are safe. But using them can be a problem, because the default (non tweaked) value of a ruleset can be a scaled value (tweaked) on another rule set - and then you may have a problem (it's not always a problem, but when it's a problem, it's a problem). Usually I would ask you for the KSP.log, MM Patch.log and MM ConfigCache so I could detect and fix the problematic parts - usually by issuing a pull request to the maintainer of the faulty patch. In advance, I can tell you to remove the TweakScale patches from TMaster5on if you have it installed (this one I never managed to fix). But since the parts involved are from Near Future, there's a better way out: Install TweakScale Companion for Near Future, direct link to the download here. These are better, updated, and properly curated patches for all NF add'ons. If even by installing the Companion you still have the problem, then I really need your KSP.log, MM Patch log and MM ConfigCache so I can diagnose and fix the problem. Cheers!

Nope. It's working fine, and I tested it on my dirtiest 1.12.2 test bed: And it's working fine (didn't checked TweakScale, I'm on working hours - I will do it later just in case). Please check if all the dependencies are met, and matching the KSP version you are using: Community Resource Pack Solver Engines My guess is that a hard dependency (perhaps Solver Engines?) is not installed or is badly installed, and so RF is not being loaded and so, do not works on your rig.

Since you have TweakScale installed on the tank, you have MM installed (forgetting MM was my first guess). On the other hand, It's a way long time since the last time I checked TS on RF, so there's a good chance that TS is "killing" RF by accident. Please post your KSP.log and ModuleManager.ConfigCache on the TweakScale's thread and I will check it.

Remembered this one today. Paul McCartney, Mageneto and Titanium Man. (I remember watching this one on LaserDisc (or it was VHD? We had bought VHD first and some time later, we realised LaserDisc were going to win the battle!). Way better quality than this video, I can assure you. )

Once you save and load/enter and exit TimeWarp/shift focus from/to the craft (anything that makes the game persist the craft) the game, DockingPorts start to drift/distort - with the effect being more proeminent when the Port is under stress. This is not something that may happen, it's something that will happen. This workaround affects every add'on that needs to address somehow the Stock DockingPort (some will break, others will just stop working) unless they are updated. This post talks about it. Additionally, once you install this one, every savegame (and craft you made) will need to have the DockingPorts reconfigured by hand, as installing this mod will make KSP forget about every DockingPort setting on evert part on your rig (including upgrades, I think). This may or may not be a problem for you, but probably will for people with longrunning careers. If we ever have a 1.12.3 release, when so you will not want to use this workaround, everything will happen again . There's a chance that KSP may handle the transition using a thingy called UpgradePipeline, but all the mods that had to be changed to cope with this will need to be changed again. GotMachine's way of applying this workaround avoids all these problems (the code used on this Workaround is solid, is how it's applied the problem).

The future of the motorized personal transport (I refuse to call this a car!)

Ouch! Thank you sir, you nailed the problem! I don't really remember this, but github does! The very first two beta releases of Refunding was using the default definition for isVisible (I always misundertand it with hidden, I'm getting old…), being it a true value, and I only fixed it on 0.0.7.6 . So this is the reason I could not reproduce the problem here, it's ages since I used the last buggy release, and I don't play too much on KSP >= 1.8 - so I didn't saved any of the test crafts as they were all disposable. Oukey, manually editing the resouce's isVisible to false will solve the problem on your crafts. Perhaps I should write a workaround on Refunding itself? I think this would be a little hostile, as someone could have a good reason to make this visible in the future...

That's the problem - Recall is doing it right, it's setting the Resource as hidden and this didn't changed from the previous release - in a nutshell, I did nothing about. What's happening is that some 3rd-parties are not strictly following the rules Stock does for showing/not showing resources. Stock does not shows Resources with the hidden atribute set to true on the in-game PAWs, widgets and tweakables, but shows the Resources (that have a price) using the tittle on the Summary screen when you recover a vessel. It's the reason you don't see Electric Charge on the Recovery Summary, besides not being hidden and having a tittle and having it being shown in-game. And this is what Recall does on the Refunding Resource, and it's the reason it works on a vanilla or lightly modded installment. However, some 3rd-parties add'ons don't cope with these rules, or cope with them loosely - Construction, by example, shows Resources with a Tittle on its own management Window, apparently ignoring the Hidden attribute (or perhaps using the presence of a Tittle on a hidden resource as a flag for something else?). Others add'ons just ignore the Hidden attribute and keep themselves a "brute-force made list" of resources to be hidden. And so on. This is the reason I asked for your logs and further data - so I can try to track down who is the one (ab)using the Refunding and then figure out something to fix it. (What I'm doing right now) — — POST EDIT — — First investigations ruled out Kerbal Engineer Redux. This is relevant because if KER is working fine on my test bed and not on the @Krazy1's rig, it means that something had changed the Refunding Resource itself to make it visisble - otherwise KER would not be showing it on his machine (not to mention the Stock Resources widget). People willing to follow up my researches can follow it on https://github.com/net-lisias-ksp/KSP-Recall/issues/19#issuecomment-907810327

Me too!!! (Let's ignore the solar panels on a WW1 design made on the late WW2 era… ) Full res images on my site, craft on Kerbal-X. Yep, I trimmed down the engine to 0.79 TWR and did a better job on setting up the flaperons (the lower ones were doing negative work!), and managed to do the stunt even better. Still need to find a way to lower that Gs (11.8 on peak) tough. Full scale images on my site.

The problem is that, on KSP Physics, by not doing that I smashed the ground because on the end of the second turnaround I ended up almost without airspeed and, so, without lift neither atitute authority. Having the engine on max gave me almost instant airspeed and so the control surfaces could act. This thing gets airborn in 3 seconds, so high is the TWR! Thanks for the tip! (To tell you the true, this test were made on my 1.3.1 test bed, that are meant to be constantly destroyed and rebuilt, so the set of add'ons are minimal!) I would not call it a loop, but something like a Pugachev's Cobra followed by a double turnaround on the wing's axis - what's possible exactly because the engine on max induced the physics engine to give me some attitude authority besides the low airspeeds on the control surfaces. You got the problem I described above - without engine, you have no attitude authority. The tendency to do left is inherent to the random number generator on KSP. It's the same phenomena that was making landed crafts to drift to the left in the past! I played a lot with Flight Unlimited on the golden days (yeah, now everybody knows from where I was inspired to make this craft!), and yeah, the Extra 300 had a lot of torque effect - you would literally be thrown out of the runway if you thrust the plane too much on landing... (and the manual of this game was something worth of being read)

And also KSP.log, as it may be something induced by 3rd parties, as it happened with Construction above. Perhaps the same stunt would work for you? Try this patch: @RESOURCE_DEFINITION[RefundingForKSP111x] { !displayName = dummy }

Hi. I didn't reproduced the problem (not even on KSP 1.12, so this is not some new behaviour on Stock). ' The only place where the Refunding is shown is where it's intended to be shown (to allow auditing), on the Recovering Dialog: What's needed, as since I'm not really fixing anything, without this visual clue the numbers would not add up - and then some users would (almost for sure) complain about it on 3rd parties add'ons...

The newer KSP add'ons visuals are something, I can tell you. Beautiful video! (and nice landing!!!! ) I gave this craft a run for its money on KSP 1.7.3 - my current line of research is to detect, as possible, the differences between KSP 1.12.2 and 1.7.3 (and later from 1.3.1 too) on the physics engine, and so try to trim the Physics.cfg file to allow keep all my crafts flying fine on 1.12. Until now, the differences are pretty subtle, the final performance of this craft on 1.7.3 was nearly identical to 1.12.2 - what changes is the between - on 1.7.3 the engine's power curve is less aggressive, I still can to a vertical but for less time. The craft also started to struggle with thermals a couple thousand meters sooner, but in both situations they reached 20K meters high - but, surprisingly, with pretty higher speeds on 1.7.3! In time, there's some adjustments that can be made for this craft: use TweakScale to make the rudder fin about 25% bigger (as it lacks yaw authority while flying and landing!), and turning off the auto-dumper&springs on the wheels, as this craft appears to be too light for the auto algorithm, what make it a bit "jumpy" on landing (what, added to the lack of yaw authority, makes the landing harder that it should). So my initial hypothesis vented on KAX's thread appears to be valid: there're some changes on the drag model and perhaps thermals on KSP >= 1.8 that, intentionally or not, ended up making some things 'easier'. Not exactly a surprise, as my hydrofoils designs demonstrated previously. What's happening is that now I'm gathering evidences of this happening on the atmosphere, and not only on water. I'm relatively confident that by mangling properly drag (and friction) on the physics.cfg we can mimic the 1.7.3 behaviour on 1.12, and my designs will work the same (what I really would like to happen). On KSP 1.4.1 I got somewhat similar results than on 1.7.3. (I have the feeling the the craft struggled a bit more to reach 20K meters high, and the thermals are definitively different - I think the thermals made more sense on 1.4.1, by the way...). What now leads us to the final step of the testings: KSP 1..3.1. Downporting crafts to 1.3.1 is a pain in the SAS, however… Most of my attempts usually ends on failure, and I end up rebuilding the craft from scratch - what I did. Things are way wilder on KSP 1.3.1 !! The craft took off instantly, and did a ballistic to 1.800 meters without any effort at all!! The SAS also behave way more smoothly, by the way. By a mile. The craft also climbed somewhat easier too, and the yaw authority appears to be better. The thermals look like the 1.7.3 behaviour, I think. So I may have to bite my tongue here about KSP 1.12.2… People coming from 1.3.1 may (at least under this preliminary report) fell more comfortable on KSP 1.12 than on the Unity 2017 times (KSP 1.4 to 1.7.3). Well, that caught me with my pants down, no doubt! (I had almost no playing time on KSP 1.3.1, when I finally bought KSP for my self birthday present, KSP 1.4.0 was the newest one and I started on it). (additionally, I'm using my own adapted FS that was instrumented to run from 1.3.1 to 1.12.2 using the very same package, so this may be a contributing factor, so I will need to revisit this issue later) Hint: use the flaperons to Pitch, and be able to do really crazy stunts!!! (Eat your heart out, F-35!!!) As usual, full albums on my site. Craft (including the KSP backported versions) on KerbalX - remember to click on the "Versions" thingy on the top left of the page.

By drinking lots of beer before shooting?

So I expend some time toying on 1.12.2 to see how KAX (and Firespitter) are behaving on it. End ended up reproducing the Apollo Soucek’s High Altitude Record. He used a Wright XF3W Apache biplane, so a biplane I did - but used a turbo-prop instead of a radial engine. I think this is the reason I ended up climbing to 20K meters high (7K more than him). On a fabric biplane… Anyway. This rendered some good screenshots and fun! After breaking the game, I mean, the record I managed to even "buzz" the tower at incredibly 40m/s , and then made a very nice landing approach, one of the best I ever did! And then I messed up. MOAR PICS on my site, Craft on Kerbal-X. — — — @Caerfinon, I feel your pain bro!!

Yep, and some others problems as attaching nodes (I think some data may be linked directly into the prefab, and so mangling it mangle everybody else). These pesky problems are the reason I postponed support for Serenity for so many time, things are probably going to blow on my first attempts, and I need a stable environment to try these stunts - or I will never know when I had screwed up or its something else on KSP.

Tachyonic fields. Imaginary (complex) Mass. Believe it if you can. The same of the "normal" mass. The difference would be a change on the signal of the slope of the gravity well - anti-gravity, if you prefer. That's beyound what I can understand, I barely handle Einstein… Yes, this is what the formulas say. However... Now and then I watch a video from Sabine Hossenfelder, and there's one that appears to be relevant to these subjects. Formulas are for Physics what Abstractions and Models are for programming - they are inherently "wrong" (in the sense they describes something by simplifying things in order to make it cope with the restrictions at hand, so they do not accurately describe the subject), but they are still useful on a finite scope of problems. Things get hairy when you start to believe that your models really match the Reality and try to apply them outside the scope they are proven to work. As you said above, mass is an abstraction. So Einstein's E=mc² is another one (as its fundament is an abstraction itself - no theorem can be more accurate than its corollaries) that it's proven to describe pretty accurately the Reality under certain restrictions, as positive "mass" and finite density. That was what was said when Einstein proposed a new Gravity model, ditching Newton's. But Einstein also said that about Quantum Physics, and evidences demonstrates that this thing work (so it appears that God really plays dice with the Universe). So I just sit comfily on my coach and what the videos - they are so entertaining nowadays as Star Trek, if you ask me.

Not a problem. TweakScale was problematic in the past, and the reason it's stable nowadays is because I hunt the bugs like they were zombies! (let me know if anything goes wrong involving it) Cheers!

KAX 2.8.1.0 is on the wild! https://github.com/net-lisias-ksp/KAX https://github.com/net-lisias-ksp/KAX/blob/master/CHANGE_LOG.md https://github.com/net-lisias-ksp/KAX/blob/master/INSTALL.md https://github.com/net-lisias-ksp/KAX/releases https://spacedock.info/mod/2150/KAX Changes: Officialise support for KSP >= 1.8 (up to 1.12.2 at least) Adds new part: Radial Engine Long Cowl (D-45) Thanks, @SpannerMonkey(smce) and @TheKurgan Some rebalancing on the engines Some care on the Localisation Some new Sample Crafts Adds support for KIS and Stock Inventory Startup checks Hopefully preventing less than careful reviewers from misrepresent KAX functionalities.

I don't think TweakScale would be playing a part on this one - to tell you the true, there's just no support at all for ModuleSimpleFuelSwitch neither ModuleSwitchableResource, these modules/sections are plain ignored. But Recall may have a hole on this, as there're two workarounds that mangle Resources - but, again, disregarding these two modules what makes them perhaps a trigger, but not the perpetrator. In which KSP this is happening? Depending of the Version, you would be using Resourceful or Refunding, and each one of these does different things on the Part's resources in different GameEvents...

Just found this one. Pretty much alike my low flying on KSP - the main difference being this guy manages to keep the plane flying