Lisias

It's possible, but I think it's unrelated. I had written that Resourceful stunt and there's nothing on it that it's influenced by anything else but the presence of RESOURCES and some Editor and PartModule life cycle events. Of course, it could be somehow triggering something else to misbehave, but then it should be happening before 0.0.4.1, and you made it clear that the first time you got the stunt was on 0.0.4.1 . So I'm guessing it's something that changed between 0.0.4.0 and 0.0.4.1 . The first thing I tried was to create a test bed for your SFS, and by loading it: It works for me. Oh, well... Now we are back to inferring, it's cold around here, where I put my Sherlock Holmes style hat? Let's trying a differential, what changed on 0.0.4.1 that could trigger something on you? The Resourceful's PartModule code had only one change, on the PAW definition, and it only made explicit something that was implicit without changing any previous feature... BUT... I had a complain about Resourceful failing to help a FS, and investigating, I realised that such FS were adding RESOURCE at runtime on a part without resources on the prefab. In order to fix that, I rewrote the patch to shove Resourceful on anything, as it's impossible to foresee when something would apply a resource on something else in the middle of the gaming, and Resourceful is well behaving enough to detect when there's no resource available and waive running. It's not a decision I took lightly (I hate to just shoving things where it can be not needed), but I could not came with anything else that would not need a hell of an extensive research on every Fuel Switch available (and then hoping for no one changing them). So this change can explain why something involving resources happened to you on 0.0.4.1 but not on 0.0.4.0 . But why in hell a kraken damned engine? Engine has no RESOURCE, only PROPELLANT! Well, the answer are on the craft file, indeed. The restock-engine-pug has resources: RESOURCE { name = LiquidFuel amount = 18 maxAmount = 18 } RESOURCE { name = Oxidizer amount = 22 maxAmount = 22 } Part of the mystery is solved. I now know why you got bitten. But still don't have a clue about how. -- -- -- POST EDIT -- -- -- I have a theory - it's more a wild guess, but it appears to make sense. Since KSP 1.5 or 1.6 (I just detected it on 1.7), KSP has a thingy called UpgradeScripts (using another thingy I still learning about called SaveUpgradePipeline). It appears to be, essentially, why you can load older KSP versions crafts and savegames and still be able to use them besides all the changes KSP had passed through. Of course, I don't have the slightest idea when this thingy runs, but since I know how and when Resourceful runs, and knowing that this upgrade thingy shoves zeroed missing RESOURCEs on a part when it differs from the prefab (it was how I detected it, I used to toy with the SFS on the 1.4.x era and when I migrated to 1.7, I couldn't do it anymore the same), I think that somehow this migration script acted on the very same time Resourceful was caching the resources. Foreseeing this possible toe stomping fest, Resourceful restores copies of the cache using a critical section (but the critical section only works for Resourceful own data structures, it can't magically protect internal KSP engine ones). So, there's a tiny little time window on this process in which something (and I'm guessing is the UpgradePipeline) could be injecting zeroed resources on that engine, and then some part of KSP could had fetched this data by plain bad luck, and then Resourceful restores the intended data and you get what your screenshot shows: a GUI saying you are out of gas, but the rest of the game would be using the restored resources where there's some gas. Take what I said on this post edit with a huge grain of salt - it's all inferences. Pretty well educated guess, but still a guess. I couldn't think on anything else, however. --- post post edit --- I failed to explain why the UpgradePipeline may be involved on the mess: once you install 0.0.4.1, a part that wasn't being previousl patched, now is. So some parts on the prefab now have the Resourceful, while on the savegame not. Then you load the savegame, the UpgradePipeline detected the engine's prefab has somerhing missing on the savegame and decided to act. And by some metaphysical twist of fate the engine with resources would had triggered the misbehaviour I suggested. -- -- post post post edit -- -- -- "All of those clever reasons were wrong." -- House, Gregory. M.D. -- -- POST POST POST POST EDIT Not all of them. T, Lisias. BDFH

Yep. I will try to figure out exactly from where this acceleration is coming from. Please update TweakScale to latest (currently 2.4.3.21). The .20 has a mishap of mine on handling RogueDuplicates, and the mishap may be biting you, as I see on your latest log.

Fabulous! And Boeing even had a Simulator for the pilots trying the stunt! FANTASTIC CONCEPT! https://www.thespacereview.com/article/1608/1

Can you send me this ship for analysis, please? Besides being more an annoyance than a problem, I don't know why this is happening and there's a chance that this could be the trigger for something else. In time, I nailed the problem on the Staging. it's something unexpected on the KSP API that I didn't realized until now (see here). As soon as I get this one on Resourceful under control, I will release the fix!

What's your KSP version? I'm using KSP 1.10.1 right now and I reproduced the decoupler's problem - its related to Driftless, I just don't understand how. Yet. But that other problem on the DeltaV. that one I couldn't. I'm firing up KSP 1.9 to see if Resourceful is involved on this one. It may be also a Unholy Interaction between modules (Kraken Food). Please send me your KSP.log, perhaps it has a hint about where to look for this one. -- -- -- POST EDIT -- -- I found the problem with the Staging! I should had paid more attention to the API Documentation! I'm using OnActive and OnInactive in an attempt to save a tiny little bit of CPU by avoiding checking things again and again on the FixedUpdate, and didn't realized that overriding OnActive would automatically means it's stageable - it makes no sense to me, but it's documented on the API, so... This one is tackled down.

ANNOUNCE KSP Recall 0.0.4.1 in on the Wild, featuring: A fix for the infinite NRE on the dedriftification - some parts just don't have a RigidBody, and I didn't told the code about it. Kerbals on EVA suffers 20 times more drifting than the craft used on the testing(Aegis 3A). They now drifts less too. Saving a tiny bit of CPU doing smarter handling of inactive and rigidbodyless parts. On my tests, I managed to leave a craft alone for 15 minutes without drifting a single degree, but once I got about 22 degrees after 45 minutes (still better than 1 degree each 2 or 3 seconds, though)- as I said: it's a work around, not a fix. Female Kerbals apparently drift more than males - the spurious velocity on males never reaches 18mm/s, but the females reached about 20 to 21mm/s. At least, on my rig. This information may be biased however, apparently VesselMover is spawning preferably females on my savegame, and so perhaps the extra drift is due this Kerbal being spawned second. For sadistic Kerbonauts that don't refrain themselves from torturing their gaming machines, adjusting the Maximum Physics Delta-Time Per Frame to 0.03 gave some marginal positive results on the crafts on my i7 MacPotato, but the Kerbals drifted sensibly more. Given the randomness of the amount of drifting we get on every game restart, take this information with a huge grain of salt. Note: Wheels and Landing Legs also drifts, but due different reasons - so, in fact, we have two sources of drifting on KSP >= 1.8 right now. The present Recall version does not (yet) fixes the wheels' drift (besides helping a very little bit, as there's one less source of drifting now). Finally, the Driftless PAW now appears only on flight. Resourceful still appears only on Editor. Good Luck! This Release will be published using the following Schedule: GitHub, reaching manual installers first and users of KSP-AVC. Right now. CurseForge, Right now. SpaceDock (and CKAN users), Right now.

Without logs, I'm alone on the dark with a pretty nasty SAS biting beast around. But in 0.001% of the cases, that beast is so smelly that we can identity it without the log just by sniffing. And with 600MB of log, it's hard to upload this monumental pile of bad news to to any service (even by zipping it). I don't have a solution for this case yet (huge logs). I think we are in the need of a in situ pre-analysis tool... Had not I messed up this one, and then it would be a a rogue interaction or mispatching, extract manually the needed info from that 600MB of logs would be a hell of a job. Well, I borked so magnificently on this one that I'm surprised it took so long to someone to kick my balls on it. I forgot that on loading savegames, the OnStart is not called, just the OnLoad. #facePalm. If you are on KSP 1.9, delete 999_KSP-Recall/Plugins/Driftless.dll for while. if you are on any other KSP, delete the whole thing for now. You will have a fix for it tonight. Stay tuned, and sorry for that. -- -- POST EDIT -- -- Found the problem! Boy, that was just... "stupid". [LOG 20:21:42.985] [KSP-Recall-Driftless] TRACE: telescopicLadder:FFFAA7DE has no RigidBody. Since I'm on the code, I'm trying to fine tune the work around to see if I can improve the stunt. In a way or another, I will release the fix in two hours more or less (unless something else happens, of course - Murphy is hearing!!!) -- -- POST POST EDIT -- -- Interesting... Kerbals are being Started, Initialized, Saved, etc, twice... [LOG 20:41:07.894] [KSP-Recall-Driftless] TRACE: OnAwake femaleEVA(Clone)(Clone):FFF9D694 [LOG 20:41:07.962] [KSP-Recall-Driftless] TRACE: OnAwake femaleEVA(Clone)(Clone):FFF9D694 [LOG 20:41:07.966] [KSP-Recall-Driftless] TRACE: OnInitialize femaleEVA(Clone)(Clone):FFF9D694 [LOG 20:41:07.966] [KSP-Recall-Driftless] TRACE: OnInitialize femaleEVA(Clone)(Clone):FFF9D694 [LOG 20:41:07.977] [KSP-Recall-Driftless] TRACE: OnStart kerbalEVAfemale (Maxeny Kerman):FFF9D694 Flying True [LOG 20:41:07.978] [KSP-Recall-Driftless] TRACE: OnStart kerbalEVAfemale (Maxeny Kerman):FFF9D694 Flying True No relation with anything, just something curious I wanted to keep registered somewhere... -- -- POST POST POST EDIT -- -- Interesting². Kerbals have twenty times the maximum "spurious velocity" than the Aegis. I Wonder their events above being called twice also implies that the FixedUpdate are also being called twice? This would double the amount of noise on the parameters I'm suppressing with this stunt...

You **NEED** to watch this video:

Yes, it will work for you. [The Module Manager patch] But will break someone else sooner or later. Now I understood how it works (it extends the Stock Part Module). So you will be "automatically" be patched up on any part using ModuleDeployableSolarPanel, but with default values on the PartModule (loosing any previous values from the original config node). It's somewhat inconvenient (on Atmospheric Autopilot, we lose the control's surfaces settings and need to reset from scratch once it's installed - it extended the ModuleControlSurface the same way you did for the Solar Panel). In a way or another, by creating your own Exponent you don't risk unintended and unforeseen consequences, as a patch that would depend specifically of ModuleDeployableSolarPanel's exponent will fail because it vanished. And since this Exponent is a "stock TweakScale" one, everybody takes it for granted if :NEEDS[TweakScale] is satisfied. So, my best advise is one of what follows: TWEAKSCALEEXPONENTS { name = KopernicusSolarPanels chargeRate = 2 temperatureEfficCurve = 2 } Or, if you don't foresee any problems if this Exponent is not available before Module Manager starts the patching chain (borderline situation, but not impossible): +TWEAKSCALEEXPONENTS[ModuleDeployableSolarPanel]:NEEDS[TweakScale,Kopernicus] { @name = KopernicusSolarPanels } This will copy the current ModuleDeployableSolarPanel into a new Exponent called KopernicusSolarPanels, inheriting any previous values. And this is an example why we should not replace TweakScale (or any other add'on) default artifacts - if you just rename the Exponent as previously proposed, anything in need to do similar things will fail when Kopernicus is installed - a mess not too fun to diagnose. -- -- test drive -- -- It works, whatever is the problem I got before, it will not affect you (I omitted Kopernicus because I don't have it installed on this test bed): [LOG 11:12:00.881] [ModuleManager] INFO: Applying copy __LOCAL/TweakScale/k/+TWEAKSCALEEXPONENTS[ModuleDeployableSolarPanel]:NEEDS[TweakScale] to TweakScale/ScaleExponents.cfg/TWEAKSCALEEXPONENTS[ModuleDeployableSolarPanel] -- config cache -- UrlConfig { parentUrl = TweakScale/ScaleExponents.cfg TWEAKSCALEEXPONENTS { name = KopernicusSolarPanels chargeRate = 2 temperatureEfficCurve = 2 } }

This will work only if KopernicusSolarPanels has the same values as ModuleDeployableSolarPanel, and it will render any part still using ModuleDeployableSolarPanel misbehaving on scaling as it will loose its exponent. As a rule of thumb, rewriting "Stock" TweakScale Types and Exponents will lead to problems on existing crafts and savegames, as it will change the behaviour of things made using them. The best way is to write a new TWEAKSCALEEPONENT for the KopernicusSolarPanels. On a somewhat educated guess: TWEAKSCALEEXPONENTS { name = KopernicusSolarPanels // hummm... this thing extends PartModule and doesn't adds any parameters... } I remember having trouble trying to use MM ordering modifiers on root nodes, so perhaps you would have some trouble trying :NEEDS on it (don't remember if I ever tried). I hear someone calling my name?

Got it. Found the explosions on the Log. "Unfortunately" there's no Exceptions around, so this is not something obvious - I'm going to create a test bed specifically to your case, and try to reproduce the stunt here. In the mean time, I found one Exception on the KSP.log that I'm sure it's unrelated, but since it happened inside the Simulation thingy, I think it worth a shot: [LOG 17:59:04.128] KerbalEngineer -> Exception SimManager.StartSimulation() // System.NullReferenceException: Object reference not set to an instance of an object at KerbalEngineer.VesselSimulator.SimManager.StartSimulation () [0x00054] in <df610534f02e44eabb2fe7c95c06a0aa>:0 [LOG 17:59:04.128] KerbalEngineer -> at KerbalEngineer.VesselSimulator.SimManager.StartSimulation () [0x00054] in <df610534f02e44eabb2fe7c95c06a0aa>:0 Remove the KerbalEngineer from the GameData and try again, just to see what happens. I will come back to you as soon as I have something new. -- POST EDIT -- Install ZeroMiniAVC. There're some MiniAVC.dll on your instalment, and this thing is known to be borking seriously on KSP >= 1.8 -- -- POST POST EDIT -- -- Hey, you are using Infernal Robotics! I thought it was a Serenity issue. Retesting! (yeah, I need to pay more attention while reading issue reports!!! ) -- -- POST POST POST EDIT -- -- Yeah, I reproduced the problem - it happens when you disarm the claw. I think the claw throws the ore tank with a huge acceleration and the thing just de-materialize on the ground (I noted an destroying by collision on the mission report). Not sure if it's a bug on Infernal Robotics or TweakScale - the test session I did was made on KSP 1.10, and I tested releasing the tank on it. Since some things had changed since them, I will reproduce the craft I used on 1.10 on 1.8 and see what happens.

It depends. If you forgot to remove all the old TweakScale files before updating the new one, then it's a known issue: please clean up the TweakScale folder before updating, some files are changing a lot and the aftermath is that you end up with old lefties from the last version lingering around and playing havoc. If that is not the case, then we have a cause of rogue patching, and I will need your KSP.log (and the MM logs too!) in order to identify who is the toe stomper. But there're some recurrent old "friends" that I can guess: if you are using TMasterson5's TweakScale patches, please remote it and install All Tweak instead. That one is one I'm uncertain is an error at all. Sometimes, we really have more than one instance of something on the GameDatabase, and so something else choose that instance to use. It's like the multiple ModuleEngineFX on part, that are later selectively activate/deactivated by MultiModeEngine . At that time (it's more than an year already), I had not such knowledge, so I decided to mark the issue to be pursued when I would had time to spare on it (or when something else happens that would force me to deal with it). Perhaps such multiple KerbalEVAs are intentional - I just need time to research the matter to confirm it. But as we can see, I still don't have time to spare on it.

It gave me a hell of a run for the money, but I fixed the stunt. It's working on Macs, and I don't see a reason why it would not run on Linux (but I didn't really tested yet the realpath way). Please download the DLL on the last post of https://github.com/net-lisias-ksp/KSPAPIExtensions/issues/6 and give it a try, please.

Well, I tacitly assumed it was a MS bork, but I was wrong apparently. I will need the screenshot of the Houston you got, so I can try to understand where else it could had failed. Could you please publish it on the issue? https://github.com/net-lisias-ksp/KSPAPIExtensions/issues/6 -- post edit -- never mind, I finally fired up the right testbed and reproduced it!

That's the fun fact: you can use any one of them, as long you are using the MM Experimental thingy of mine that "undo" what was done on the "Stock" MM that breaks the Welding tool. I think "my" version does one thing or two better, but the true is that the official one on the OP also works (on the Experimental MM). Hi, sorry answering so late, I remember reading your post and marking it to answer later (I was kinda busy that day), but... forgot. I never tested the tool against welding parts into an already welded "mega-part". What I'm seeing appears to be a recursion aborted by an error. On a wild guess, the code that welds symmetries ignored half of the craft because a welded bunch of parts has no symmetries, so the code wrongly concluded that there's nothing more to do after finishing the left side. Again, it's a wild guessing, but.. Try to weld all the parts at once, without using intermediary weldings. The true is that I never tested doing this way, it never crossed my mind before! It's something on MM that changed some time ago (and IMHO it didn't had to change, it was kinda gratuitous). Have it "fixed" on my Experimental fork of MM, it will allow the tool (both the official one and my fork) to work without further hassle. You will have the whole story on this post. There're some practical limits on the size of the things you can instance on KSP. Too much big things (as your elevator), and the floats imprecision start to bite (too much big or too much small values, and we start to lose precision on the number - it's like a rounding). And then these craziness start to happen. There's this thread explaining why space elevators can't happen (at least, without a lot of help of heavy scripting) on KSP: And the reasons are still valid. SWDennis almost did one on a video in 2018, but I can't link the video here because he express in splendid colours all his frustrations on the video, and that made it Forum rules unfriendly.

Ouch... I didn't thought about that. And I should, because my main gaming also uses symlinks, but since it's on 1.7.3, I didn't was caught by this. It's not exactly a problem on the KSP-Recall, it's a leaking abstraction on the KSPe thingy. Issue here, I will work on it on the first time window. Perhaps a BIND could be used to work around the problem in the mean time? Thanks! Now I need to find a way to do the same on the Wheels. We have two source of random yaw forces on the game, I managed to work just one of them - the wheels will be another fight!

Hi! I made a simple test with downscaled Claws and Ore Tank (without robotics), and nothing exploded. Yet, at least. So it's something related to the Robotics, I think. What's your KSP version? Can you publish on DropBox your KSP.log, after making the ore to explode as you described? If it's some code misbehaving (or perhaps a rogue interaction between some other module), the KSP.log will hint me. In the mean time, I will try to reproduce the issue using Robotics! Cheers! -- -- POST EDIT -- -- I used robotics this time. Works the same, i.e., works for me. It's something else on your KSP, I think. Or perhaps a specific combination of parts. Please publish your KSP.log, as well the craft you used to reproduce the problem. What I could do with the information I have, It's done. Cheers!

I made a Work Around for a pesky problem on KSP since 1.8 : I think I kinda stopped the left or right drifting of the craft after she is launched! That's the history: while (ab)using TweakScale, I ended up realizing why crafts starts to drift to the left or to right on launching! To tell the true, the crafts drifts all the time, but on the launching we have the airstrip to have a reference and so we perceive the problem more easily. In fact, we have two different problems: a drifting on the wheels, and a drifting on the craft herself. Two different problems happening at the same time. I managed to work around (this is not a fix!) the craft drifting on the latest KSP Recall, and I would appreciate the help of brave Kerbonauts willing to help me testing this before publishing it widely on Spacedock and CKAN. The latest Release is available only on Github for while. In time, the drifting induced by the wheels are not being handled yet - the workaround above helps a bit, but not enough to overcome the wheel's problem. But I expect that crafts without wheels will stop changing headings by their own from now on.

ANNOUNCE A new Work Around is now available on KSP Recall 0.0.4.0 and it's available for the brave Kerbonauts willing to risk their SAS with this stunt. On KSP 1.8 and newer, parked crafts (even without wheels) drifts the Heading to the left (or to the right, it's kinda random) when leaved at their own. The drifting is a bit severe, reaching many degrees by minute. KSP Recall 0.0.4 introduces a fix that alleviate or cancel this drifting. On my tests, I managed to leave a craft alone for 15 minutes without drifting a single degree. Note: Wheels and Landing Legs also drifts, but different reasons - so, in fact, we have two sources of drifting on KSP >= 1.8 right now. The present version does not (yet) fixes the wheels' drift (besides helping a very little bit, as there's one less source of drifting now). Additionally, a smarter way of selectively patching the parts in need of the Work Arounds is now in effect, making it feasible to install KSP Recall on any KSP version (needing it or not) without impacting the loading time: the parts are now selectively applied, instead of being applied not matter what and then being cleaned up by code. The cleaning code is still there, anyway, as a last line of defense. Good Luck! -- Screenshots or it didn't happened! -- Setup of the tests: 4:25 MET - No drifting detected. 9:09 MET: No drifting detected on the testing vessel (but the Kerbals wandered a bit) 15:56 MET: The testing craft are steady on her Heading! Success! 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.

(yeah, I made an Announce on the wrong thread! a new proper post will be here the next few minutes! ) Now a proper post! I think I succeed on working around one of the problems discussed here. The stunt appears to work fine, and it's available on the latest KSP Recall. On my initial tests, the craft kept her Heading steady for more than 15 minutes, and I detected a 0.5 degree drift on more than 25 minutes of the testing - by I strongly suspecting this drift was induced by the two Kerbals that drifted into contacting the hull. Please note that this test is related to the craft herself (the wheels are raised on the tests). The drifting induced by the wheels will be tacked down on a next opportunity - I want to make sure this is a proper workaround before trying the wheels! Start of the test: 15:56 MET : I declared a success. I leave the thing running unattended for more 10 minutes, and then got this: And that's it. Unless I detect something new that would need coding something, by the end of the night I intend to release the 0.0.4 KSP Recall to Curseforge, Spacedock on tomorrow's afternoon. If anyone is willing to help me testing the stunt, the latest release of KSP Recall is here. I reworked the patching mechanism, now you can install it on any KSP version unchecked (the patching process now is smart enough to just patch things on the KSP version it's intended, ignoring the patching otherwise). Cheers!

I felt a disturbance on the force. Maybe @purpleivan is around?

Is there anyone using TweakScale Companion for SMCE? If yes, please read this on the Companion Program Thread:

Requests For Comments How many people (if any) are using TweakScale Companion for SMCE? Right now, I have a problem that I should had foresaw before, but ended up missing it... The original patches for the SMCE add'ons doesn't exactly follows the current TweakScale guidelines and, so, they don't have exactly a place on the Companion Program. I'm currently rewriting the already published patches and new ones for the other excellent SMCE's Add'Ons, but doing it the right way. I'm also patching the PARTs to be usable to KSP up to 1.7.3, as this is a minimal effort - 1.8.x and up may need further work, and I will let this for another time. BUT... This will render current savegames unusable. It should be used on new savegames only. So, what I'm going to do is to incept a TweakScale Legacy new add'on (and, so, it will be marked as incompatible to any Companion reinventing the wheel), and I will focus the Companion for SMCE on the new way of doing TweakScale. Problem: if anyone is using this right now, you will have problems by updating - you should remove the Companion and install the new Legacy one to be published at the same time I release the Companion. Thoughts? -- -- POST EDIT -- -- The latest TweakScale 2.5 Beta fixed the problem that would affect new savegames. The skies are clearer now.

How about 1.7.3? It's still the version for my "serious" gaming. It performs pretty well on my "new old rig" (better than 1.10, believe it or not). And it should handle SpannerMonkey's add'ons pretty well (most of the time). Virtually all the current Add'Ons fixes can be backported to it too (it's what I do). And at least some patches for SMCE are being worked out to fix them on "more or less modern" KSP. (shameless self-promotion: TweakScale Companion for SMCE) But if that is not feasible, I don't mind keeping Kerny on 1.3.1 - I prefer good content to bells and whistles on visuals (and ships allow you to explore also the oceans for histories, not only dry land).

Completely remove all TweakScale folder contents and reinstall. You applied a new TweakScale version over a old one, and since some files had changed, you ended up with old lefties around!