Lisias

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

News from the Front Preliminary testings suggests that KAX (as long the latest FireSpitter Core is installed) works fine on KSP 1.12.2 - what completely denies a review (that I had ranted here): (on my country there's a legal thingy called "Direito de Resposta", and I'm pretty sure I'm legally entitled to demand it - but whatever, I will not draw attention to him/her) I have the feeling that the crafts are performing unduly well - it doesn't appears to be the engine, I think there's something different on the drag - I know these crafts pretty well, they are my test beds on every KSP I ever tested (most of the KSP-Recall work were made with them!), and it's clear that some of these crafts are behaving differently. The hard part is to understand exactly why, so I can rebalance these parts (or not!) without breaking something else that it's working. On the bright side, the engine model appears to be working fine (including the flame-outs), as the Vintage Propeller engines demonstrated: Unfortunately, some parts from FireSpitter itself (that match nicely with KAX's ones) have some problems related to heat on KSP 1.12.2 - by some reason, at least the FS1B bomber bay is being spawned with tons of heat, and on the sample craft (a modified PeaceMaker from previous versions using the new Long Cowl engine to be available on the next release - Thanks again @TheKurgan!!!) things didn't blew up probably only due the huge mass of the craft: On the bright side, the phantom heat was dissipated once you take her off. What's better than the ICAs (Instantaneous Craft Annihilation) we were experiencing on KSP 1.11. But still way less than ideal. I hope the remaining FS parts would at least survive the launch as the FS1B. It worths to mention that the physics engine on KSP >= 1.8 is slightly different from KSP <= 1.7.3, and so crafts made on that era will need some reworking on the AutoStruts. I had to make some changes on the PeaceMaker's auto-struts in order to make it fly on KSP 1,12. I really hope Keptin do a reboot on the FireSpitter models, they are ageing terribly . In a way of another, I spent the whole day playing testing KAX on KSP 1.12 - a privilege, given the current demands on my Day Job - and I think I identified and/or fixed any minor misbehaviour. The only thing I still want to do before release the new version is support for KSP's new Inventory System. Oh, yeah… On Kerbal-X. On my site.

Ow, well… English is not my native language, it's not unusual that I miss the tone and end up taking the words without context. Sorry by that. But, sometimes, I think we should be a bit more explicit about how complicated (besides not rarely being "simple" to code) solving interactions between Modules can be - not to mention time consuming. Detecting the root cause of the problem I mentioned on my last post took me almost two weeks of heavy testing (and the fix was, virtually, an one-liner!!). TweakScale is not exactly "hard" to code, once you know what you need to do. What takes a huge amount of time is figuring out exactly what you need to do (and fixing things, of course, because bugs - including mine! - are always around, misleading our researches), and - so important as, what you can not do. I don't dare to even consider that this is different for everybody else (B9PS is a pretty complicated piece of work, I can only wonder how hard was to make it tight!). I hope this helps to understand how deep is this bunny's hole: making patches is just the first step - we need to consider how different Modules will behave once you patch them on the Part, including the ones that were already there before you patched the new ones - and, also, to remember that sometimes a bug may be hiding somewhere, waiting to bite you in the SAS - and this bug is not always on your side of the keyboard.

Humm… I think I know what's happening - apparently the Waterfall module is destroyed and rebuilt when the craft changes, instead of being updated. But the TweakScalerWaterfallFX assumes that once the part is instantiated, the module is never destroyed, so when you add something and something else replaces the Waterfall modules for new ones, the Scaler keeps trying to use the older one and BADA-BOOM... If I'm right, it's an easy fix. I will come back to you ASAP. — — POST EDIT — — Problem confirmed. I'm testing the fix, if everything goes right a new release is near. — — POST POST EDIT — — Nah… Shoddy coding. I forgot that I don't need to (internally) scale Waterfall unless on Flight Scene, so I was making things unnecessarily complex. There's no data to be persisted (everything is being fetch at runtime on need-to-know basis), so there's nothing to be dealt on Editing… Unsurprisingly, by getting rid of unnecessary code, I ended up fixing the problem of losing the plume scaling on Revert to Launch. Oh, well… Visuals will be promoted to Release Candidate! #HURRAY !!! — — POST POST POST EDIT — — It's not consistent. I think I was too optimistic about the results… Some more testings are needed… — — POST POST POST POST EDIT — — Something happened, the plumes scaling ceased to work at all on some use cases. This will take longer than I expected - I will keep you informed, @Hohmannson

Sir, if I may ask something, I would ask for a reboot on FireSpitter. I really miss this one. (Let me finish my worst problems on TweakScale, and I will help you on anything I can if you need!)

Just a quick & dirty test on TweakScale and a pretty nice add'on I found called Cold War Aerospace! More on my site. Craft on Kerbal-X.

Hi! TweakScale maintainer here! Could you, please, enumerate the problems you faced with TweakScale? On the next months I'm going into a bug killing spree, and knowing the ones that bit you will help! Cheers! — — POST EDIT — — I made a very minimalistic test on CWA engines (usually a source of problems while scaling), and I didn't found anything evident. https://kerbalx.com/Lisias/CWA+TweakScale-Test

TweakScale's "inability" to reliably handle B9PS not rarely is/was due B9PS itself. Things are improving slowly, however, as not rarely I need to understand some third-parties modules and fix them myself. That said, any report about problems involving TweakScale should be redirected to TweakScale's thread, please. I can only fix what I'm aware about, and complaining about on third-parties' thread is not exactly the best way of making me aware of a problem.

Yep, it works. (oval closed wing plane). o.O Source: https://englishrussia.com/2009/03/05/ellipse-wings/

ANNOUNCE Release 2.4.5.2 is available for downloading, with the following changes: Raise the bar to KSP 1.12.2 (Finally) adds support for Parts and Modules from KSP 1.11 and newer. Implements the TweakScaleExperimental Patches Program. A lot of patches are not fully tested, and some Exponents will probably need revising. Since both these patches as well the unavoidable revisions that will follow may unbalance current crafts in savegames, it’s advised discretion on activating the Experimental features. Closes Issues: #186 Check and implement all Modules left behind from 1.4.0 up to 1.10.1 #184 Scale some unsupported parts on EXPERIMENTAL status #182 Get rid of TODOs related to updating scale types. #181 Support the new Parts introduced on KSP 1.12 and Update Scale Exponents to the new Modules #128 Support the new Parts introduced on KSP 1.12 and Update Scale Exponents to the new Modules #120 Support the new Parts introduced on KSP 1.10 #50 Support the new Parts introduced on KSP 1.11 and Update Scale Exponents to the new Modules See OP for the links. (Previous announce) Highlights TweakScaleExperimental support for parts and modules From 2.4.5.2, TweakScale is starting to support, as possible, all KSP modules - and not only the most visible ones, as well parts. In order to pursue that goal without risking your ongoing savegames (as changing Exponents will unbalance your designs, potentially ruining your crafts), some parts and modules scalings are only available on Experimental mode. Such mode will patch almost all KSP parts and modules (but Serenity/Breaking Ground as this one will be tackled down later, see the backlog for more information), including some that I’m unsure should be scaled - not to mention Exponents that I’m pretty sure will need some rebalancing. In order to toy with these parts and modules, you need to create a directory called TweakScaleExperimental in your GameData. The directory may be empty, it’s enough to have it on GameData so Module Manager will register it, satisfying the :NEEDS that enable such patches and Exponents. Please only enable these patches on disposable or non valuable KSP installments. These patches are going to change for sure in the near future, and these changes will be incompatible with savagames created with the previous set of Experimental patches. Standard mechanism to control TweakScale availability From 2.4.5.0 and up, it’s possible to deactivate TweakScale on some (or even all) parts by patching or on the user interface without affecting living crafts on the savegame (or even already existent craft files). A patching only feature can lock up TweakScale on the current state, making easier to create artefacts to automatically reconfigure a savegame for Challenges with specific rules. Again, without affecting existent crafts or savegames - once the craft is launched, it’s not affected by these options. See the Documentation for details. Parts with Variants Variants that change Cost and/or Mass are now fully supported, but TweakScale is struggling to support Parts with Variants that changes Attachment Nodes. I had planned to withdraw TweakScale support from such parts as I did in the past, but then I realised that most Version 2 parts from already scalable parts (as Terrier…) would had TweakScale withdrawn, and this would render some crafts and savegames corrupted. Since most of these parts didn’t misbehave on a noticeable way, I decided to just let it go as is for while. Just a few stock parts are misbehaving into a noticeable way, and these parts are (until the moment): The Mastodon engine The Structural Tubes T-12 T-18 T-25 T-37 T-50 And probably more, as Add'Ons starts to use such feature. The only workaround at the moment is to descale these parts before applying the variant and then scaling them again. Alternatively, just detach and reattach the misbehaving parts. A proper fix is Work in Progress, and is expected to be released on 2.4.4.1. Deprecating Patches Support for all non Squad parts are on a deprecating status and will be definitively removed on TweakScale 2.5. The TweakScale Companion Program will be the source for supporting third-parties add'ons. It’s advised to install the needed Companions as they reach Gold status. Sanity Checks Parts using Firespitter’s FSbuoyancy needs the latest TweakScale Companion for Firespitter, as only the Companion has the specific code that knows how to handle it. Overrules A overrule, as the name says, is a patch the overrules TweakScale (and anything else) in order to make things broken in a deterministic way. A complete essay can be found here. Hot Fixes A Hot Fix is a hand crafted patch that fixes by brute force patching problems, forcing the original intended result for a given KSP installment. The difference from an overrule is that Hot Fixes don’t break compatibility with sane installments, so you can start new savegames and share your crafts without worries. A complete essay can be found here. New Scaling Behaviour A new TWEAKSCALEBEHAVIOUR, ModuleGeneratorExtended , is available for parts using ModuleGenerator that wants to scale the INPUT_RESOURCES too. This feature wasn’t introduced directly into the ModuleGenerator’s TWEAKSCALEEXPONENTS to prevent damage on Add'Ons (and savegames) that rely on the current behaviour (scaling only the output), as suddenly the resource consumption would increase on already stablished bases and crafts. Just add the lines as the example below (the output resources scaling is still inherited from the default patch!). @PART[my_resource_converter]:NEEDS[TweakScale] { #@TWEAKSCALEBEHAVIOR[ModuleGeneratorExtended]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = free } } WARNINGS The known Unholy interaction between modules (Kraken Food), rogue patches or known incompatibilities between third parties Add'On that can lead to disasters are being detected on the Sanity Checks with a proper (scaring) warning being shown. A full essay about these issues can be found here. Unfortunately, such issues are a serious Show Stopper, potentially (and silently) ruining your savegames. This is not TweakScale fault, but yet it’s up to it to detect the problem and warn you about it. If this happens with you, call for help. A Cancelbutton is available for the brave Kerbonauts willing to fly unsafe. TweakScale strongly recommends using S.A.V.E.. Special procedures for recovering mangled installments once the TweakScale are installed (triggering the MM cache rebuilding) are possible, but keep your savegames backed up. And DON`T SAVE your crafts once you detect the problem. Reach me on Forum for help. TweakScale stills mangles further affected crafts and savegames with some badly (but recoverable) patched parts so when things are fixed, your crafts preserve the TweakScale settings without harm. THIS DOES NOT FIX THE PROBLEM, as this is beyond the reach of TweakScale - but it at least prevents you from losing your crafts and savegames once the problem happens and then it is later fixed. You will detect this by KSP complaining about a missing TweakScaleRogueDuplicate module (previously TweakScaleDisabled, renamed for clarity). You can safely ignore this. Keep an eye on the Known Issues file. — — — — — This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Right now. SpaceDock (and CKAN users). Right now. The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps.

ANNOUNCE KSP Recall 0.2.0.5 is on the Wild, featuring: Updating KSPe.Light.Recall Minor fixes and/or optimisations. NO NEW WORKAROUNDS OR FEATURES, this is a maintenance release. This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right now. CurseForge. Right now. SpaceDock (and CKAN users). Right now. Being a maintenance release, all Distribution Channels were updated at once.

To tell you the true, the last time I had read about people resorting to stunts like this it was the 80's when 8 bits computers were still a thing. The 6502 has a pretty fast and nice instruction to minimize delays while waiting for some hardware to be ready. When you need to react really fast - but really, really fast to the point that a NMI would be too slow (due the internal states to save the PC into the stack and jp into the handler), you would hook the signal to the SOB (pun not intended) pin, and then spinlock waiting it to change a bit on the P register using a TestAndBranch instruction (only 3 CPU cycles, against the 7 cycles needed by NMI, and even that if the CPU was'nt on a SYNC state). The x86 have the WAIT instruction for similar results: a spinlock implemented internally in micro-code, you can't beat this on software. And even the venerable IBM-XT already used interrupts for reading the keyboard instead of a busy-wait checking the keyboard I/O pins as it was done on Apple2 and similar machines. And we are talking 1981 and 1982 here. If you are not working with micro-controllers (single-task, single thread), if you even think on spinlocks you should have your commit privileges revoked and be sent back to a BASIC programming school.