Rodhern

As far as I know, it would not matter; the part(s) would stay in the inventory as 'text'. Maybe do a KSP backup and try it out?

The KSP Weekly mention a "1.3.1 pre-release". Isn't that unusual for a KSP patch version? So is it a good, bad or neutral sign?

Hello. I noticed that KeepFit (and possibly most or all of the mods that use Connected Living Space) have a CLSInterfaces.dll included. In KeepFit's case it is in the folder "GameData/KeepFit". I think it works, so that is fine, I am just wondering what the most correct way to handle the CLSInterfaces dependency is. Is the CLSInterfaces.dll supposed to be in there? In the mod folder? Should it be updated occasionally?

Cool, I will aim to release a build for KSP 1.3 in the week that is coming up. I will post a link when it is done. And again, thank you for keeping KeepFit around for as long as you have already. To me it is the perfect middle ground between hardcore life support mods (which is too strict/harsh for my kind of play) and the sandboxy stock gameplay where Bill, Bob, Jeb and Val flies all missions.

When I played with StageRecovery in an older KSP version, the 'tidy up' would trigger the refunds. I wouldn't get the message, but I would get the funds.

It sounds to me like the editor might 'think' you are holding an item with your cursor. I don't know how to convince the editor that you let go of the item already. Maybe try clicking somewhere 'blank' some more (?).

Ahh, thanks. So maybe I can reuse/copy one of the intake parts and make a pseudo ram air turbine clone instead.

Thank you @KerbMav, that is a really helpful explanation of usable upgrade system MM config syntax. Have you considered adding it to the database of MM patches (if it is intended for free use by everybody). In the database thread there is already another good example, that moves the Stayputnik to an earlier tech node. I was thinking that maybe I could add a 'ModuleResourceIntake' that would generate electricity when moving through the atmosphere, much like an airliner ram air turbine. My naive attempt (shown below) failed. Is there an easy fix? @PART[probeCoreSphere] { MODULE { name = ModuleResourceIntake resourceName = ElectricCharge checkForOxygen = true area = 0.005 intakeEnabled = true intakeSpeed = 1 intakeTransformName = Intake densityRecip = 1 resourceUnits = 1 } }

I only recently 'discovered' how convenient it is to use module manager patches to tweak the tech tree (otherwise I would just edit the config files themselves). I see @Kerbal101 already quoted an excellent example. For the most part I like the stock tech tree, but it is nice to be able to tweak it a little. To enhance the immersion you might even want to change the display name of some RD nodes: @TechTree { @RDNode:HAS[#id[stability]] { @title = Basic Flight } }

Maybe build a large tank on some girder feet. Add a KAS fuel line socket. Tow it in place next to the 'stock' fuel tanks. Finally add some mod trickery that will magically refill the fuel tank. At least that sounds easier to me than doing the proper solution, although the proper solution would be very cool.

Using the TJ-1 / TJ-2 (Telescopic Joint) with a JS-1 (Joint Socket) for refueling gives a shorter range (about 2 meters) compared to the older KAS pipes. Is that on purpose to encourage more creative Infernal Robotics creations, or have I missed a more obvious KAS refueling option? Edit: Oops, sorry, just noticed now that an RTS-1 flexible pipe is on the TBD list quoted in the OP.

Timmers, do you know if there is work to be done, or if it is a 'straight forward' (syntax) matter of compiling it for KSP 1.3.0? Have you looked at it already? If not, do you think it is a good idea if I fork your repository and make an attempt to release a build? (probably won't be this month though).

I have been playing around with Github a little now (still a novice but no longer completely blank). I am more scared of the scenario where the binaries and the source code do not match up, than I am of the rather exotic scenario of blatantly malicious source code. There are two main ingredients to this 'fear': To make a new release on Github I simply drag a zip-file to the Github dialog. To be really upstanding I should make a fresh checkout of the tag, then run my build script on the new checkout, then package up the artifacts and upload that. In practice it is very tempting to instead press the Visual Studio 'build' button and just refresh the assembly dll file in a copy of my previous zip file. It takes a bit of effort to build one of the Github KSP addons. At least it does for me. I have to update/downgrade/modify the solution files incl. KSP assembly references before I am able to build. (Of course, subject to license terms, the upside is that you get unlimited mod customization options).

Ahh, I see. Thank you for your quick answer. I didn't realize there was a technical reason for the 'missing' wrapper.

As far as I remember the current recommendation for interacting with KCT from third party mods is through Unity/.Net reflection. Now that we have a convenient ScrapYard API wrapper, I could get a little greedy and wish for a KCT one too. In my potentially upcoming mod I would like to offer a contract that removes (some or all) items from the ScrapYard inventory and rewards the player with science points and/or KCT build points.

Hmm, just an extra observation. If I add a cockpit and re-root then the pitch control surfaces do count in the editor. When you take the 'Static Analysis' panel, enter a 'pitch setting' (e.g. 1) and press 'Sweep AoA' you can see the control surfaces deflect. They do not deflect on the command seat only version. That is, they do not deflect in the editor, but they do deflect in flight. Maybe somehow this quirk some times carries over to the outside flight scene? (I mean if FAR somehow got confused and did not deflect the control surfaces then a 'nose down lock' all of a sudden might not be such a far fetched behaviour). In that case it is probably a 'Take Command' related issue.

The genius of Bill and Bob is that they made a blatant copy of your design and put their names on the side - the little buggers. Seriously, it is your design; take your uploaded craft file, remove the reaction wheel and move back the two pitch elevons somehow (e.g. the empty liquid fuel parts as shown). Maybe you have encountered some kind of bug or formula edge case - your initial 'nose down lock' experience still doesn't make much sense.

Bill and Bob removed the Reaction Control Wheel and went for a test flight. Except for the first part of the take-off run where the craft skids on its bum before getting airflow enough to raise the tail, it is a perfect little plane. (Wright 2E.craft). Bill and Bob buzzed the tower at mach 0.5. They claim it is one of the best planes they ever got to fly. Very stable with no discernible ill tendencies.

That is indeed strange. The craft on the above image flies just fine for me. I have no explanation what so ever for why it would lock itself in a nose-down attitude.

Hi @aluc24 Thank you for sharing your fun little craft. It is interesting and it doesn't actually fly quite as bad as you seem to indicate, but it is fairly easy to loose control though. There is a few little quirks to this answer. First, the root cause of the problem most likely is that your pitch control surfaces do not have much of a lever arm. You may not notice it when you fly but the pitch control is mostly provided by the small reaction wheel. Eventually the aerodynamic forces will be too great for the reaction wheel to keep the craft entirely stable. Another reason you may not notice this, is that, at least in my KSP, the FAR Editor gets somewhat confused by the elevon pitch control on your craft. Once out on the runway though it all makes sense. I know I don't win any fashion competitions for this design; but I do believe it tells you in just one image what the problem/fix is:

That makes fine sense. At some point browsing access to the inventory would probably be interesting, but no rush. Maybe you could also have the 'override funds' option exposed through the wrapper, so that you know if the inventory is 'payed for' or not.

Hi @kbios and @Virindi . I have a new idea how we can maybe debug the wildly changing stability derivatives (#177). I have written a snippet that can be used to output FAR Wing Interaction Influences data to the log file (just some text lines). In my scenario what is happening is that after the first load I have a good number of "nearby wing modules". After another few (two in my case) loads there are no "nearby wing modules" left in the lists. If this happens in your games too, then Ferram can try to see if it still does not happen in his games. A compiled version of the script/mod (compiled against KSP 1.3 but seem to work for KSP 1.2.2 as well) is here: FerramDebug ver 1 . License is all rights reserved. Source code is here, and source for the F-sharp core is on Github. When in the SPH with a relevant aircraft loaded press F1 (I think F1 is also the screenshot key, but that didn't pose a problem to me) and a line for each wing interaction influence value is written to KSP.log (and trace listeners).

Hi I downloaded the wrapper for Scrap Yard. There is a function called "GetPartsInInventory". As I understand it, and please correct me if I have misunderstood the functionality, it works pretty much like running through a shopping list. Let us say I have four items on my list, a solid booster and three basic fins, and that there are two solid boosters and two basic fins in the inventory. Then it will go like this: "Do you have a solid booster?" - "sure" - the solid booster is included in the returned list. "Do you have a basic fin?" - "sure" - the fin is included in the returned list. "Do you have one more basic fin?" - "sure" - this fin is included in the returned list too. "Do you have yet another basic fin?" - "nope, all out" - no further fins are included in the returned list. So, I can walk up to the "ScrapYardWrapper" clerk and show all kinds of exciting shopping lists and get accurate answers. But I cannot simply ask "what is in the store?"; is that correct?

Hi Drew. You are definitely not off your rocker with this suggestion. In my opinion one of the greatest difficulties in using the derivative numbers is that they are not all that intuitive in their current implementation / interpretation. I haven't really played that much Kerbal for quite a while, but I did 'update' the derivative interpretation in a private fork (Github); I haven't added a fix for the annoying change in derivative results at recalculation though. The update will not make it to the official FAR builds (Ferram has looked at my formulas and they seem to contradict the formula interpretation conventions of historical real-world aerospace literature). If you are interested, please let me know if you want to give the 'alternative' derivatives a try. And if they make sense to you, then at least we will be two, and we could maybe try to create a cheat sheet, chart or something.

You sir, are a true Kerbal.