Lisias

You need to account for the extra mass. Assuming the math above are correct, you will need 45 units of LFO to each 1000 units of Xe. There're fuel tanks more or less with this capacity, the R11 Bagueta, the Round 8 Toroidal and the R-12 Doughnut. Their mass is about 0.33 tons (full). So your probe will carry such extra mass, what will impact your D/V - but at least this mass will lower as you consume the fuel. Then there's the mass of the Fuel Cell itself, the Fuel Cell Array will cost you 0.24 tons, and this mass is constant the whole mission. This will give you 18 E/sec, what's enough to feed two Ion Engines. On the other hand, a PB-NUK RTG costs you 0.08 tons in mass each, but gives you only 0.8 E/sec - so you will need 12 of them for each Ion Engine (or you will need to have batteries to accumulate the energy produced by the RTGs). Or 0.96 tons only for the RTGs - and this mass is constant for the whole mission, but you will not run out of fuel, as it will happen with the Fuel Cells. Going back to our Fuel Cells, you will be better served by them as long you plan to consume 2.000 units of Xe or less per Ion Engine (as the tanks and fuel needed will cost about 0.66 tons of mass, and you will need a Fuel Cell Array with additional 0.24 tons). Otherwise, the Equation of the Rocket will start to bite you and you will be probably better served by using the 12 RTGs per ion engine. Of course, I'm conveniently ignoring the cost in Funds of the whole ordeal. RTGs are pretty expensive, 23.300F each!

Of course not! The Dres Planetary Society is still working on the case!

This one is recent, but looks like something made on the Old Days!

Nope . System Heat is a whole new set of PadtModules and I need to check them in order to know what to scale and what not. Even by using something like All Tweak, the thing will misbehave because the new PartModules aren't supported.

I can understand that, but the criticism I had read demolished the whole show, not only the plot. And, as a matter of fact, I found the plot pretty interesting. The plot twist on the last episode of the season caught me with my pants down. Some characters were completely rewritten, but the essence of the main characters was there - obviously, with a heavy hand on consequences. I had watched the original show about 16 years ago, and yeah - it's also excellent. But the live action have a more mature content, I think. Well, I just finished the first (and only) season, and I found it great. I can only mourn the show was cancelled, however. The way the plot was going as very promising!

System Heat is something I need to work out yet. The good news is that Seasons is coming, and I will have free time to work on the Companions again! https://github.com/TweakScale/Companion_Frameworks/issues/7

Well, I just downloaded this craft and had a test run using it on KSP 1.12.5 with the latest TweakScale et all. (ignore the warning about the missing module HitTracker). Then I launched the thing, cheated my way into 50Km high (just for the lulz), and did a test run using the chutes. I pressed F-12 to visually check the drag, as well have the Debug activated, and checked the drag on the PAW too. Everything working as expected... It's really something pretty basic, I don't understand why you didn't managed to check it yourself.

You can check it yourself!

Yep. On piston engines, you pay a price for the extra kick. The intended real life counter part, Pratt&Whitney R-4360 Major Wasp, had the exact same problem - you need to use an oil radiator to keep the engine working at higher RPM. An oil radiator (as well an intercooler) part is something that are in the plans to be implemented this year, but got delayed - as usual - due RealLife™ and DayJob© demands. Oh, well, soon will be seasons again. In the mean time, you can try the Engine Pre Cooler as a step gap on large airplanes. On smaller fighters, they just took the toll : they never used the engine at max throttle for too much time otherwise the engine would fail by overheating. It's the meaning of Military Power (initially War Emergency Power): a power regime that the engine can sustain for a brief time, but will meltdown if used continuously without extra hardware. Since that extra hardware cost mass, they are used only on heavy fighters and bombers that could absorb that extra mass with little to no cost on performance.

Hey, Lebowski just released a new album! Great!

I'm finally watching Cowboy Bebop (2021). Already watched the first two episodes, and they are very good. Why this series got so miserably reviewed it's beyound me. It's really good, at least the first two episodes!

I don't know Ohscrap and Scrapyard in details to give you a proper answer, but in principle, no, they are not supported - i.e., there's no Campanion adding support for them. If additionally they are fundamentally incompatible with each other, I never checked. To make things clear: Incompatible with TweakScale: something that breaks if TweakScale tries to mangle with it, or that breaks TweakScale by trying to mangle with, that fights TweakScale leading to a game crash when both are installed. ex: Kerbalism. as it have a on-rails engine for simulating things when crafts are on rails, and there's absolutely no way for TweakScale to work with it as TweakScale is a off-rails only add'on. Unsupported: things that need some code or patch in order to work with TweakScale, but otherwise don't do any damages (other than not being scaled, or being partially scaled). ex1: Firespitter, as it adds new PartModules that someone had to teach TweakScale how to scale them (in this case, using the TweakScale Companion for Firespitter). ex2: BlueDog_DB, as it adds a lot of parts that I need to analyse and then write patches for it (what will be done on TweakScale Companion for Rockets as soon as RealLife™ and DayJob© allows!). Without analysing these two add'ons, I can't say in which one they fit! I will try to do it in this Seasons, pending agreement with RealLife™ and DayJob©

In 1984, when things started seriously to go South, making cartridges were cheap enough to independent developer be able to buy 3.000 of them in advance for launching their game. It was still a steep threshold, but not too much worst than buying an expensive Game Engine license for professional use. Nintendo may was charging about 17£/unit for manufacturing for you less than 50.000 cartridges (royalties included), but what you are forgetting is that you didn't had to buy from them. Bootleg manufacturing was way cheaper (Activision anyone?) and rampant at that time. It was doable. Besides, the VideoGame crash was terrible for… Hardware Manufactures, but not for Software. The Home Computer Era was beginning, and even Atari jumped ship on it porting their videogames for home computers (even Apple II got some ports). The indies of that era were programming on 8 bits home computers, not on videogames - and they were one of the reasons for the Crash, as people started to prefer buying Home Computers instead of VideoGame Consoles. But they kept buying games: people that played Moon Patrol on the Atari VCS not rarely bought it again for the Atari 400/800. We were in the Golden Age of gaming in the early 80's too. Guess what? That Golden Age passed, leading to the Home Computer's Golden Age that, well, also ended in the early 90s when the PC era, fuelled by WinTel, started (and are still lingering). I'm afraid you don't understand exactly how an industry is interconnected and interdependent. The big boys get screwed, the money they pump into the rest of the industry dries, causing a chilling effect on the supply chain: Indie developers have free or cheap access to Unity3D because the big guys subside them with their fat fees. If the fat fees slim down, they start to charge more on the Indies. I'm hearing a bell ringing somewhere? Online Stores have a pretty significante (if not most) part of their income from the AAA titles without this income the Stores will be forced to raise their fees into the Indies too. With less money circulating on the industry, we have potentially more layoffs This is already happening, by the way More unemployed developers tend to squashed salaries And so the good ones are incentivised to switch industry as a way to preserve their incomings And with less experienced developers having to take the O.G.s duties as they leave, titles will suffer and we have a self-feeding crisis The big difference between this crisis and the ones before is that this time, the problem is on the Software. On every past crisis, the devastation played havoc on Hardware Manufactures: From VideoGame Consoles to Home Computers From Home Computers to the PC 8 Bits Consoles to 16 bits 16 bits Consoles to the 32 bits era etc. And on each one of that changes, gaming got better and stronger. AFAIK, we never faced a Software crisis as what's happening now.

Still about the ongoing dumbing down process of the game, it's not something specific to KSP2 as it appears. Apparently this is happening on the whole industry: It's a pitty such discussion is happening a the same time the Game Industry is suffering some serious drawbacks on employment: Video game company layoffs are creating an industry crisis Things are going to be harder to fix now, I really think we may be reaching another VideoGame crash as we had in the 80s.

No apologies necessary. Miscommunication happens, and when the sides don't share a common mother tongue and culture, it happens a lot. Usually I would say "let's not do it again and everything will be fine", but that would be naive from me. None of us intended this to happen, and yet none of us made anything purposely wrong - so there's really nothing to be "fixed" and, so, well… This is probably going to happen again eventually. So I would just say instead "everything is fine, and if this happen again, we will handle it as we did this time and it will be fine the same". :) Worst case scenario, I walk from the discussion a couple days to put my temper under control and come back later. I'm grumpy, not evil! (not what happened this time, see below) Apologies not necessary, really. Had you didn't got defensive and just walked away, we would not have the chance to make amends and the exchange would be a complete waste - so, really, no apologies necessary. No hard feelings at all. Don't worry about, I'm grumpy, not evil. Note: I'm on a temporary medical condition that is hindering my ability to operate computers, but yet still have some pressuring issues on Day Job© and so I end up prioritising my "stamina" on Day Job© and ended up neglecting you in the mean time. There's not too much I can do about until I'm healthy again, so I ask your patience in the near future about my response time! Cheers!

Not yet, sorry. Real Life™ and Day Job© are still bitting. I expect to have an open window for developing on KSP again on December, hopefully on the second week at worst.

Today is this one (great song, listened to it ad nauseaum in the 80s). Curiously, never watched the clip before! First Time! Raf - Self Control.

Didn't knew this one, thanks for the tip!

As far as I know, yes. But I never tested it. TweakScale doesn't touch Tech Trees (what's a conceptual bug itself, TS should be inserted in the tech tree somehow - but I have more pressuring tasks at the moment).

TL;DR: I'm not criticising being criticising by you. I'm criticising the criticising itself ergo, I'm not criticising you neither I'm not mad by being criticising - sometimes I'm a bit annoyed, but never mad about it. (but being annoyed is on the Maintainer's job description, so it's my problem - not yours) Please understand that I'm talking about how you did something, not about you doing it. Neither do I. I'm in "engineer mode", I'm trying to address the problems, not the people. We, engineers (being from Software or anything else) have this habit of going straight to the point, without mincing words - usually jumping straight to the throat of the problem. We are problem solvers, and we don't solve problems by being tender to them - on this subject, we are pretty aggressive: we want them dead. What leads to the point that triggered my "engineering solving mode": you wasted your time working on a problem you think you found without the necessary background. I'm not even complaining about my time, because I don't see explaining KAX's designs as a waste of time (it can be a bit annoying sometimes, but this is my problem). But your time and effort I would prefer to be used on problems that are really problems, what we will not manage to get if you jump into conclusions without the proper background. There're things on KAX that need improvement for sure and I'm unaware, these are the problems I would prefer people focusing on. The key word is "immersive". Players need immersion in order to be involved on a simulation, otherwise what we get is a Fantasy game with unusual rules. Anyone with the most basic knowledge of the Space Race or even the initial attempts of Flight (on Air and on Space) have problems with the current Tech Tree, and you will find evidences on add'on authors trying to fix them on this very Forum, on the most diverse tech trees (or the very interesting Unkerballed Start). The very purpose of an Add'On (or "mod") is exactly to provide something not found in the base game, not to just extent it - we are not Private Division's employees, we are not free workmanship to be used to do their work. We do things because we want them in the base game, because we think the base game is incomplete or unbalanced or whatever - i.e., we are not extending the game, we are kinda of rewriting it as we want it to be. A bit at a time. So, by definition, talking about game balance on an Add'On that thinks the game is unbalanced and so need some parts is, well, a pleonasm and a redundancy by itself. KAX is one of these Add'Ons, trying to fix a terrible gap on the Tech Tree - damn, starting your first airplane with jet engines? Seriously? Yes, and that's the "problem". You weren't able to identify the engine's use cases because you don't have knowledge enough to understand them. And, so, ended up wasting your time and efforts on calculations and theories that were completely unfunded. I.E., you missed the whole point of the Add'On at best, and the point of modding KSP at worst. But yet, simulations need to have some degree of realism otherwise we lose the immersion and the game lose its meaning. That's the different between a SHMUP and a KSP game session using BDArmory. We are going to need to agree on disagree on this one. I'm not meaning to be rude, but I'm not going to be subjected by what I consider rudeness neither (i.e., disrespect for my time). Well, you said (emphasis are mine): And this is a criticise: But, and again, I'm not criticising you by criticising me - you are entitled to disapprove something I do, and you are welcome to pinpoint my faults (otherwise I would not be aware of them and, so, will not fix them - failing on my role as Maintainer). Of course, I'm entitled to agree or not. I'm criticising your criticising because I would like a better use of your time and efforts, in a more productive way. Of course, you are entitled to agree or not. Yep, and a clarification I tried to provide. Our communication failure was probably due the assumption that I got annoyed or offended by being criticised (or whatever), while I was being plain objective and straight to the point. On my line of duty, we consider this polite - why forcing the reader to read 20 words when the message can be sent using 10? Their time is so valuable as mine.

Nope, the game's engine works fine. ALL, absolutely ALL the problems TweskScale is facing right now are due mishaps on Editor. Had we problems on the game's engine itself, we would have problems on Flight Scene since KSP 1.3.1 - but what we are facing are exactly the opposite - older KSP versions work better then newer. Thanks. I will check them by night. Now that I stablished exactly in which KSP the problem started to happen, I have a benchmark to do some interesting testings in order to locate exactly where the problem is being triggered and, with a bit of luck, also why. I need to understand why TweakScale is being used as a trigger for the problem - otherwise I risk replacing a bug with another one, potentially worst (as it happened recently on that links I published above!).

Stock parts are anything but balanced: the first space flight was not manned. The first powered aircraft was not a jet engine. Turboprops were invented after the jet engines. The very reason for KAX to exist is to provide aircraft parts to fill the Stock gaps on the tech tree, so you can fulfil the initial aircraft contracts with more historically accurate parts if you want to add a challenge to the game. Or just play sandbox and do nice historical things like (craft by kcs123) You are criticising the "balance" of the parts as they were power ups on a SHMUP game. You are essentially telling us that the following aircrafts are exactly the same thing:

I'm afraid TweakScale is triggering something on some 3rd party, or more probably KSP itself. When TweakScale detects its part is not scaled, it literally shut itself down (Monobehaviour.active = false), and so there's not much of a chance of it doing something that could lead to the crash. This is a known issue. KSP's Editor is completely messed up, it screws the PartModules on loading when the root part of the subtree is a part with variant. I worked around this. Now there's another problem exactly related to the Alt+Click, where things get messed up under the same circunstances (subtree's root is a variant), but the fix for this problem ressurrected the loading problem - so I had to choose the less worst of the problems for now. (it's interesting to note that the loading bug only happens on Editor - if you launch the craft directly on the Launch Pad or Runway, it's loaded fine) In a way or another, I pinpointed the point of rupture for sure but the fix will imply in a bit of refactoring on TweakScale to cope with the messed up Editor's life cycle without screwing with the Flight Scene's one. related issues: https://github.com/TweakScale/TweakScale/issues/314 https://github.com/TweakScale/TweakScale/issues/307

Yes. The AeroSport is a turbo-propeller engine, while the D-25 is a piston radial engine. The modelling is more or less accurate to the Real Life™ counterparts. And it's by design. If you want to build WW2 or early Cold War airplanes, the piston engines are the way to go. If you want to build modern era, general aviation aircrafts, you use the AeroSport. This is a (pretty cartoonish, admittedly) simulator, not a SHMUP. The technological level of the part is part of the use case.

How they are staged? Everything is decoupled at the same time, or one by one? I'm assuming the decouplers are scaled, right? It would help me a bit if you could send me a minimum craft where the problem happens. edit: the patch above is useless, the problem is completely unrelated to TweakScale's scalings. — — POST EDIT — — I tried the following test: Both the TD-06 Decoupler as the HECS were scaled up twice. I staged them sequentially. I cheated my way into orbit, and hit Stage 3 times. Everything worked fine to me, with Force Percent =0 as well =100. I'm pretty sure this is a problem on something in your rig at this point - can you send me your KSP.log too? — — POST POST EDIT — — I think I finally understood. You found yet another bug on KSP 1.12.5 (I'm betting happening since 1.8.0 or something later, as I never got this on 1.7.3 and 1.4.3, my KSP versions of choice for serious playing). When launching a craft, there's a chance (not sure the statistics) that the first satellite being decoupled by hitting stage would be decoupled into the Infinity. The new vessel is not computed as destroyed, I think it's being launched into Kraken's sphere of influence instantaneously. I managed to (more or less) deterministically reproduce the problem the first time I launch a craft when I load a savegame. Reverting to VAB and launching the thing again fixed the problem on every further attempt, until reloading the savegame from Main Menu (didn't tried quicksave/quickload). Additionally, I also determined that the problem never happens when using the Decouple button on PAW, it's something that I only reproduced by hitting Stage! So this is not something I could handle on TweakScale (being its fault or not), because the decoupling itself is working as expected, it's something that is only happening when the decoupling is executed by the code that handles the Stage keypress. Closing KSP and inspecting KSP.log and Player.log, I found this : [LOG 16:47:08.315] Packing Untitled Space Craft Probe for orbit [LOG 16:47:08.327] ObT : NaN M : NaN E : NaN V : NaN Radius: NaN vel: [NaN, NaN, NaN] AN: [4527.46041793627, -686736.988244428, 0] period: Infinity [WRN 16:47:08.327] [OrbitDriver Warning!]: Untitled Space Craft Probe had a NaN Orbit and was removed. What confirms that the first stage of the first launch of a recently loaded savegame is leading to the annihilation of the new craft when it's created by decoupling using the Stage button. I want to emphasise again that manually decoupling the decoupler via PAW never leaded to this problem on any of my tests. TL;DR: this is a new misbehaviour on KSP, present for sure on 1.12.5 and absent for sure on 1.7.3 and 1.4.3. (other KSP versions weren't tested). TweakScale apparently is a trigger to the problem by reasons beyound me at this moment. Was the problem happening too when manually decoupling the thing, I could consider TweakScale as a possible suspect, but since the problem only happens on staging, I can't blame other than KSP itself at this moment. — — — POST POST POST EDIT — — — The misbehaviour was reproduced with UNSCALED PARTS, completely ruling out TweakScale from the equation. When the part is at default scale, the Module TweakScale deactivate itself to save some CPU and, so, it's incapable of misbehavings. It's still possible that the presence of TweakScale on a part can trigger the problem, but in this case I think that any other add'on would trigger the problem the same because, well, TweakScale is inactive on unscaled parts - unless KSP itself would be calling an inactive MonoBehaviour what, frankly, would be a very stupid move. — — — POST POST POST POST EDIT — — — KSP 1.8.1. did not presented the problem. — — — POST POST POST POST POST EDIT — — — KSP 1.9.1 did not presented the problem. The misbehaviour were reproduced on KSP 1.10.1 and KSP 1.11.2 . So it's something that started to happen on KSP 1.10.x as it appears.