Lisias

Ouch, completely forgot... Yeah, it was on my 1.11.2 test bed and I forgot to clean it, I did it on rush. Yeah, just save the craft again and it will be cleaned up from anything you dont have installed. Sorry for that, I completely missed it. Or something else on my rig was masking one problem and promoting the other... Assuming a mod on my rig wasn't interfering, it may be an initialisation error perhaps? The bug is the RCS thrusters vanishing, but now and then another bug happens on the bug (an uncaught exception, perhaps?) leaving the RCSs in a semi deleted state: they were removed from the part, but the code aborted in exception before removing them from the World... I will fire up my rig again, this time after cleaning up the test bed, and give it a new shot.

Because sometimes things are not so obvious, and since developer's time is usually scarce, every minute you save them from trying to reproduce the problem is a minute they can spend on something else - including eating and resting. It took me some tries to get the problem, most of the time the RCSs just vanishes with the shroud. But I managed to create a craft with the sweet spot here. Launch the thing, cheat it into orbit and hit Stage.

Good, thank you. When the people that tested my worse solution try it and tell me that yours works, then I will switch to your solution. I will reach them in private. Until there, I will stick with what they tested for me until this moment. -- -- -- POST EDIT -- -- -- One of the beta testers confirmed the fix on a minimal test case of him (the one he cares), and he confirmed that the thing works (unsurprisingly). Also, unsurprisingly, he kinda complained that there's no visual cues from the fix happening - the Dialog shows the current, wrong values - the correct value is given back tough. So, your fix is not auditable and does not gives the user a visual cue that it's working. I think we need to improve that a bit to be a full replacement for the current, "worst and messy", solution. I will give this a shot as RL allows.

And how it's computed on 1.11? Good to know. However, I didn't knew at that time, and worked with whatever I had on hands relying the less I can on any related internal KSP mechanism that should be considered suspect at that time. I reinvented the "wheel" because I didn't trusted the wheel KSP was giving me. So instead of spending time (what I didn't had) on acquiring by myself all the details you provided now, I rewrote that part of the "wheel" (essentially about 15 to 20 lines of code) and called it a day. All the remaining code was already written on other workarounds, so this was the fastest way out of the mess at that time. Messy, yes. Intrusive? Nope. I added a resource and a module, exactly as every Add'On do to add a feature. The reflection was being applied on my resource, that resource is not used by anyone else, and no code are being injected on any other place. Doing it on a Module was the easiest way out of the problem at that time, and probably it still is - that stub you gave me on github need to be coded, tested and checked. The messy code I have now is already coded, tested and checked by the people that reported the problem. You see, there's a lot of man-hours already spent on the messy solution. I see no reason to throw it away and put a new code on the circuit to be tested again, unless the solution is proven to need more work than the work already spent on it (including testing by third parties). Until the moment, problems are being solved by applying patches instead of publishing new code. You are the one insisting on rewrite a working solution just because you find it "messy" (not arguing about being messy or not).. Give me a compelling reason to throw away my testers' time and efforts, and I will code a new solution. But until there, things will stay as it is for while, as I have no enough time to do the other things I have to do, not to mention the people that reported and tested the solution until the moment. That said, I'm not telling you that your solution is not better. It appears to be. It just happens that it's not proven to be best enough to justify waving some other important things I need to do. A good enough solution now is better than an optimum solution next week. Prove your point and I will listen. In the mean time, small MM patches can work around the current ones without the need of new code. I agree. But it's the rule, and sillier rules was already enforced before - I just don't wanna take risks on this. I agree. It matters. Not everybody is an North-American living under North-American legal system. There's a concept called "clean room design". This is legal on every country I'm aware of, and it's what I'm doing for coding my add'ons. Decompiling the KSP Assembly it's legal on North-America (as far as I know), but it's not on some other countries. Check about the TRIPS Agreement. So I will not do it (or admit I did). I agree. But different countries have different legal technicalities - so I decided to err to the safest side. Someone decides to mess with me on my country, I will spend money defending myself - my country is signatory of the TRIPS Agreement and it trowed my legal system on what we call "juridical insecurity" (something specially tricky on countries under the Roman Law system). I just don't want to take the risk, even by being pretty small.

Well, in a way or another I got this fixed. Apply this patch somewhere on the GameData (I suggest GameData/__LOCAL/KSP-Recall/StackableFix.cfg) : @PART[*]:HAS[@MODULE[ModuleCargoPart]]:AFTER[KSPRECALL-REFUNDING] { -RESOURCE[RefundingForKSP111x],* { } } @KISConfig:AFTER[KIS] { @StackableModule { moduleName = Attached moduleName = ChillingOut moduleName = Driftless moduleName = RefundingForKSP111x moduleName = Resourceful } } It will fix your issue with Stock Stackable parts, as well (hopefully, I will test it later) on KIS too.

Have you KIS installed? I completely forgot about it, I need to patch it to accept parts with Refunding as stackable. In a way or another, I reproduced the problem here using SEQ-9 and EVA Experiment Kits. I will get back ASAP with a patch to fix it while I don't update Recall. (Q.E.D, @Gotmachine, I can fix things on the field by using patches and by preventing locking things on the Module, as you suggested!)

Yep, every ugly hack is questionable - they would not be ugly hacks if they weren't. But still: But they will not work properly, AFAIK, for modules that change things at runtime, as Pay for Play. I need a simple and easily understandable solution that could be safely applied everywhere without relying on KSP, as I don't know where exactly the root problem is. Because, potentially, every part have custom modules that calculate the costs differently. Doing this way the Refunding costs will be echoed on the savefile, and where it can be audited and fixed if needed. Remember, I DON'T KNOW what's happening inside KSP as I didn't reverse engineered it as requested by Forum Rules. So an external and minimally intrusive (from the code point of view) solution is preferable. The Resource spamming is exactly the collateral effect I need to keep the thing auditable. But by them an eventual mishap on the calculation will be utterly harder to detect, not to mention that I would have to shove the Resource programatically instead of using a Patch. Keep in mind that the code only acts on Parts where the Refunding stunt is injected, so any conflict would be easily solved by preventing the Refunding resource to be injected where we know it will cause problems. I'm not the only modder around here. I need to cope with the fact that other people are modding things around here, and sooner or later this solution may stomp on someone's toes. -- -- POST EDIT -- -- Being not an native anglophone, sometimes I may miss the tone - so I thought it would be a good idea to clarify: I'm not telling you are wrong - you are not. I'm telling you I'm not wrong neither - at least, until further information about the nature of the root cause is available with the insurance it's Forum Rules compliant.

Yeah, it did the trick, thank you! I knew it would be something pretty simple but I ran out of time for playing (not to mention modding) the whole week, so I didn't even tried to look for a solution. For everybody (justifiably) annoyed by the Refunding resource on the UI, this will workaround the problem until I update Recall tomorrow night: @RESOURCE[RefundingForKSP111x]:AFTER[KSPRECALL-REFUNDING] { %isVisible = false } This patch will "fix" your rig in a safe way. Save it somewhere on your GameData where you can remember ir later (I suggest GameData/__LOCAL/KSP-Recall/RefundingFix.cfg) and you are done. The nice part of it is that the Refunding resource is still shown on the Recovering Dialog Box, so it's still auditable!

Of course it's a ugly hack. I have no access to KSP's code, I can't fix it properly. You proposition, if right, implies inner knowledge of KSP internals - something I'm not allowed to have due Forum Rules (See Legal Boundaries). I have no (forum compliant) means to know what the error on the code really is, so I choose to counter act the misbehaviour this way. Given the time constraints I had (and still have), this ugly hack it's the best a non Dev Team member can cook: It solves the problem Can be audited by 3rd parties As I don't have knowledge about what really is going on inside KSP's guts, I can't claim this will solve every problem, so doing this way will help people to find any missing use case And anyone can double check it, not only developers It don't get on the way of how KSP is doing things know, as I'm (ab)using a standard mechanism It allows me to use reflection only on an artefact I have control, instead of risking changing someone else's code Of course I have no special love for this stunt, something better (and Forum Rules compliant) is shown to me, I will throw this stunt on the bin can on the spot. But until there, I think it's safer (besides uglier) doing this way,

And that, my friend, it's why the GameData should be considered sacred land. No user configuration or editable data should be there, only readonly files . (I have a single use case of a fix I'm cooking where the original file was so messed up that I had to replace it - but this is still bugging me, I'm trying hard to find an alternative)

What's not working anymore... Send me the KSP.log in PVT. Chances are that I already had diagnosed it for someone else. Cheers!

Point taken... That it's used only by KSP. Unity still uses the original handler - so any problems inside Unity are only logged on the Player.log . But your argument that crashes renders your plugin useless is right - anything really needing the Player.log would be better handled externally, as on CKAN perhaps.

Yes. KSP.log is the.. .KSP's log. The Player.log is where Unity does its logging. Crashes and other inner problems are only logged on the Player.log. Granted, it's not needed every time. Perhaps as an option?

There's a thingy somewhere setting the Resource as hidden or something, but RL pressures prevented me to spend more time researching the matter and I launched Recall with I had on hands. Going back to this is already scheduled for my next KSP modding time window - it should be something extremely simple, by the way.

Yes. In order to avoid stomping on the mainstream toes, I make every effort to avoid confusion by not using the same places and files when possible. (and user editable/serviceable data on GameData is a terrible idea anyway).

Not necessarily. You can enable transparent file compression on Windows. it saves a lot of space, and on spinning disks even make the loading faster. If you are on Linux/BTRFS ou Apple/APFS you can use also Copy-On-Write - a thingy were two different copies of the same file shares the same space on disk until some of them changes, and then only the change will written on disk. This is a HUGE space saver, you can have two copies of the same KSP instalment taking only 5 to 10% of the space of a single copy. Unfortunately, ReFS (the new Windows file system) will be available only on Windows Server and Windows Pro Workstation, so end-users cannot use COW on Windows -at least, for while.

JNSQ? Humm... Nice idea! I will give it a try!

Ouch... Big Sur screwed up some keys, as it appears - I'm running Mojave (they will take it from me only from my dead fingers), and it works fine. Try sudo xattr -rd com.apple.quarantine ~/Applications/KSP/KSP.app where ~/Applications/KSP is where you installed the game. There's also this trick: sudo chmod -R 755 ~/Applications/KSP/KSP.app try the xattr stunt again after doing this one. Good luck!

TL;DR: WE HAVE A .2 RELEASE, PEOPLE! JOY UP! Not only that, it's a x.y.2 release - they listened to us. And this makes me very happy (at the same time I'm still angry due the other problems - these are not mutually exclusive options! Being a KSP enthusiast is an exercise on Schizophrenia, apparently... ). I don't know details about the costs, but building a release involve some on big companies - so, it's understandable when a company try to reduce the releases to a minimum. But when that nice pieces of paper hits the turbofan, someone have to concede - and hopefully we are going the 1.7.x way: incremental releases, tackling down the worst bugs and rushing up releases as the worst are fixed or worked around. (Fail early, fail often - but always fail forward) - the 1.7 releases are the best from the Unity 2017 era, almost as good as the 1.3 ones (being "goodness" that sweet spot where bugs from KSP and bugs from Add'Ons co-live together without screwing up the gameplay). It's not ideal, of course - ideally, there should be no bugs at all. But we don't live on an ideal World, Squad is not an Ideal Company and frankly, we are not Ideal Customers neither. So we need to find a compromise - they burn the Midnight Oil hunting the show stopper bugs, early adopters do the same testing the thing for bugs (or fixes), common users wait a bit while the others do their trick.

The first 500 is the hard part. Then something kinda snap and things start to happen by itself, I think.. The secret appears to be stupidly awesome on the screenshots and awesomely stupid on the jokes, I think.

As a matter of fact, you just reminded me that now I can write a Companion for IR, doing things my way...

I made this gizmo tested it on 1.7.3, 1.10.1, 1.11.1 and 1.11.2: And ALT_Copying worked as expected on all of them. Well, not an obvious bug on TweakScale as it appears. But since you are using Infernal Robotics, I'm sufficiently confident that the problem may lay on the Infernal Robotics itself. You see, IR have to cope with some of the problems TweakScale had to cope too, as it also resizes parts and, so, need to replace attachments nodes - and if the parent part borks on resizing its nodes, TweakScale will reposition the nodes wrongly too - Garbage In, Garbage Out. It's less than optimal, but had you considered to use a scaled down Tube? Two T-12, two cubic truss (as I could not attach the solar panel directly on the tube) and you are set. Cheers!

So it's not safe to just update to 1.11.2, you need to make sure to have the latest Kopernicus installed first! You see, it's not necessarily a demerit to break on a new KSP release - KSP has bugs too, and these bugs ends up inducing add'ons to bork. And the more complex is the add'on, the most likely it will bork when something change abruptly on KSP. One example of that it's TweakScale. Scaling parts on symmetry was working fine until 1.11.1, and now on 1.11.2 something has gone kaput - some code that fixed a bug on KSP just created a new one that is somehow affecting TweakScale in the end. And this is precisely the reason why, now, I show an "Advise" when TweakScale is running on a untested new KSP explaining that some new bugs can happen and strongly advising to install S.A.V.E. to keep things backed up automatically. And, in the end, TweakScale is working fine (just made the final test, while writing this post). Another Add'On was messing up its attachment nodes on KSP 1.11.2 - and then TweakScale used the messed up attachment nodes to scale things and got borked. Garbage In, Garbage Out. (what does not means TweakScale is fully functional on KSP 1.11.2 yet - there're a ton of tests to be made before being sure).

I'm still playing on 1.7.3 - never did anything meaningful on 1.8.0 and newer. Just don't worth the trouble. What's heartbreaking - because there're pretty good things on the newer KSPs - but by every good thing implemented, there're something else that broke (sometimes pretty important as this last one), and some of that things that broke I just can't fix without breaking Forum Rules (See 8. Legal boundaries). It's a catch 22 situation, sooner or later some people will be coerced to stop publishing add'ons here on Forum.

NOTAM KSP-Recall is still needed on KSP 1.11.2 , and it appears to be working fine. Happy Refundings!