pjf

Okay, the CKAN will no longer try to push bacon on you. If you *want* the bacon release, then `ckan.exe upgrade RealChute=1.3.0-Bacontastic` will work. If you've already got the 1.3.3.7 release installed, then the CKAN won't think that the available 1.3.1 release is newer, but the manual upgrade above (`ckan.exe upgrade RealChute=1.3.1`) will work (as will uninstall/reinstall), and the CKAN shouldn't try to move you off that unless a new legitimate release comes out, or stupid_chris decides to turn all parachutes into ice-cream! ~ pjf

Hi everyone! It's me, from the CKANverse here! While I wonder why *anyone* wouldn't want the bacontastic v1.3.3.7 release, you can push the CKAN into installing the more vanilla version by using the command-line: ckan.exe upgrade RealChute=1.3.1 I'm also in the process of updating the index so that CKAN won't offer to "upgrade" you to bacon any more. I'll post back here when that's done. ~ pjf

CKAN does a *very* simple check to see if something is a KSP directory. In particular, it wants to see: 1. A GameData directory 2. A "readme.txt" line which contains a KSP-looking version string somewhere inside it. If your readme.txt file was accidentally overwritten by a mod, then 2 is going to fail. You can potentially get away with a readme.txt file that simply contains the line "Version 0.90.0 Beta" and all will be well. ~ pjf

New release! v1.6.6 aka 16 Psyche * Uninstall can now use a regexp (thanks Ippo!) * Hotfix to allow for downloads from KerbalStuff on Linux/Mac/Mono (thanks Daz, linuxgurugamer, and nlight!) Note for Linux users Please `apt-get install libcurl4-openssl-dev` to make sure you've got all the new SSL libraries. Note for Linux/Mac/Mono users If you encounter any problems, try `mozroots --import` to update mono's certificate store. The hotfix means that download progress *will not* be shown when downloading form KerbalStuff. Your downloads are still happening, and this will be fixed in a later release. Download here.

So, the good news is that `sudo apt-get install libcurl4-openssl-dev` should *hopefully* get the test build to work happily under Linux. The bothersome news is that may install an extra 50Mb worth of packages.

Gosh dang it. I'm still discovering how curlsharp works underneath. Alas, falling back to http isn't an option (KS forces https), and the metadata doesn't allow for multiple locations (although you could configure to download from the CKAN mirror, which would probably help). As for ubuntu, can you try `apt-get install libcurl3` and then trying again? I'm *hoping* it's just looking for a local libcurl library and failing. ~ pjf

Hey everyone, We've hit a problem with mono not supporting newer forms of encryption of out of the box. If you're using a Mac or Linux machine, this will manifest as you being unable to install mods from KerbalStuff, along with the NetKAN errors that linuxgurugamer saw above. I'm working on a netkan fix, but I've got a testing version of the CKAN client that you can use for installing mods if you're on a Mac/Linux system. I'm still doing my own testing, but if everything checks out there'll be a new release in the next 24 hours or less. Please note that a side-effect of the work-around that I'm using is that the client won't report progress (it'll seem to jump from "downloading" to "installing") when it activates, and that files will be downloaded sequentially rather than in parallel. Neither of these are ideal, but they're a *lot* better than being unable to install mods at all. The work-around should have no effect under Windows (which uses the .NET native libraries rather than mono). For the technically inclined, we're falling back to blocking curlsharp calls (thanks to mgsdk for the suggestion). In future releases we should be able to convert everything over to native curlsharp, so we're not juggling two implementations at once. ~ pjf

That sounds pretty reasonable. You can always raise your perigee if you're happier with a slower and more gentle reentry. Making sure you don't have any extra mass is a good idea (if you've got heavy science instruments hanging off the side, you won't decelerate as fast in the upper atmosphere, and hit problems in the lower). Having a temperature of 1200°C sounds like your heat-shield is completely ablating (I can't remember when it undergoes pyrolysis, but I think it's about 800°C). If you don't have a heat-shield, then that's your problem. YES!! I experienced this after installing Ven's Stock Replacement to an existing game, and I've still not found any solutions. If you find one, I'd *love* to know about it! ~ pjf - - - Updated - - - Right now the "realistic wheels" still aren't very realistic. They're providing between 0.1 and 0.5 kNm of torque, which is pretty huge given the rest of their stats. The ISS has control moment gyros (CMGs) which weigh 272kg each, and provide only 0.258 kNm of torque. Here's some of the discussion on github, but the short of it is that the wheels are overpowered when it comes to torque per unit weight. (They're probably somewhat accurate when it comes to electricity consumption, if we assume they use modern techniques.) - - - Updated - - - There's a wiki page for all the altitudes (FlyingHigh, FlyingLow, InSpaceHigh, InSpaceLow) in RSS. Enjoy!

Downloading now. In terms of anticipated requests: - Mentioning the license and link to source in top-post (both are in the download). - Releases on github and/or kerbalstuff for easier CKAN indexing. - Display rotational period if not already present (so I can have craft with matched orbital and rotational periods, so they're always facing the body they're orbiting). - Ability to set desired rotation (defaulting to orbital period), and to gently "snap" rotation to this if the current rotation is "close enough" when warp is activated. (This means I won't have satellites slowly accumulate errors because I'm a second or two off with my period). Many, many thanks! ~ pjf

Wait, did we remove SRBs from starting tech? That doesn't sound like something we'd do intentionally. Can you expand a little?

That depends on how much memory you've got kicking around. I play RP-0 career mode, and have AIES, Chatterer, DMagicOrbitalScience, FASA, RemoteTech, SCANsat, SXT, UniversalStorage, and VenStockRevamp all installed as well-supported RO/RP-0 parts packs. (I run in x64 Linux, and so have no need to keep to a 4GB limit, either.) ~ pjf

New release (v0.27) out today! Bobcat's Soviet Engines have been placed, thanks to BevoLJ! <3

Non-supported parts are those that haven't been placed in the tech-tree. Because we're using the Community Tech Tree, they may already have the right position, but they haven't had a human go and verify that. What we love most of all is when we receive contributions of part-placements. All the parts are in an easy-to-edit file, and if you have a free github account you can even make the edits in your web-browser. Once submitted, they go to a bot which automatically checks for common errors, and then our lovely maintainers who verify that everything looks good and merge the changes. Even if it's not clear how much things should cost, just getting part placements contributions is *wonderful*. Indeed, one of the advantages of having the big "not supported by RP-0" labels is that they annoy me so much that I go and place the parts I want to see in my spacecraft. Oh dear. That's possibly more a bug in KCT itself, although I believe it can be switched off on a per-save basis in the KCT settings panel, so you can potentially recover your old save if you wish (assuming you started a new career). ~ pjf

For no other reason than I can, here's my latest RP-0 mission report.

Which is why I made sure I posted the MM patches to turn the feature off. A lot of RP-0, and KSP in generally, is *very* configurable. It's just the user interface for configuring that (placing .cfg files in GameData) is not.

Avionics are coming. This change means that a vessel cannot be guided if it exceeds the tonnage limit of the avionics parts installed, but you can still right-click parts, stage, do science, arm parachutes, and the like. This means that if you're starting a new game, then your sounding rockets will not be steerable until you progress up a few nodes. For those of you who are already part-way through the career, you'll need to think about how large your probes are, as heavy probes will needs lots of avionics to control, and at least the early avionics packs are heavy and power-hungry, although they become much lighter and more efficient as you advance up the tree. (This means that probe cores actually make a difference now, instead of using the octo2 for everything.) You may wish to set up some of your early probes for fly-by trajectories, and then jettison your power-hungry avionics modules for the long trip to wherever you're going. Avionics are additive. If you have two cores that support 1 tonne of craft each, your craft can weigh a total of 2 tonnes. Avionics will affect existing craft in flight. This is a bummer if you're part-way through a mission, so if you've got an existing career you can completely disable avionics by coping the pasting the following into a .cfg file in your GameData directory (I use `zz_hackz.cfg`): // Remove avionics on everything @PART [*]:HAS[@MODULE[ModuleAvionics]]:FINAL { !MODULE[ModuleAvionics] { } } If you're like me, and all your existing cores are built on an octo2 base, you can use the following instead to *just* remove avionics from the octo2, allowing existing craft and designs to function as normal: // Remove avionics on octo2 core. @PART[probeCoreOcto2]:FINAL { !MODULE[ModuleAvionics] { } } You can remove these when your missions are over, and the original avionics behaviour will be restored. You can safely put this config in your GameData directory with the current version of RP-0, in which case it will take effect only when you upgrade to the release, whichâ€â€if NathanKell remains under my psychic controlâ€â€will be in the next day. ~ pjf - - - Updated - - - That sounds like it could be a memory issue, since ATM tends to ease memory pains. Today I learnt there's a patch! Yes, you'll need it if you're seeing parts with funny white and red textures, and that bothers you. Otherwise you're fine without it. ~ pjf

Gosh dang I'd love this to be CKAN installable, but the file overwriting is a hurdle there. I've noticed the github repo has a lot more files than the release, are there any plans to make a stand-alone release of KSPIE, rather than one that depends upon KSPIBoris? I'm happy to offer my own humble gitomancy skills if they can be of assistance. Many thanks for all your great work! ~ pjf

The X-ray experiment requiring you to mash the button about six times for each biome/situation to get all the science back was a bug. You'll still get extra points for flying over tiny biomes. On that note, Science Alert is pretty much the best thing ever if you want to make sure you don't miss science at all.

New release! RP-0 v0.25 aka "What does the 'lox say?" Tech Tree Hydrolox engines now have their own tech-tree line. It may look empty, but each node unlocks new engine configs (identical to previous RP-0 releases). We're working on making engine configs visible in the tech-tree itself. If you've researched the old hydrolox nodes, you'll need to unlock the new ones. Existing saves with hydrolox researched will have construction nodes unlocked instead. Science X-Ray experiments now return their full science value on the first transmit. Updated placement and costs for many parts, including: radialDecoupler2 6S tubes Many FASA parts FASA Apollo parts in particular (thanks to @BevoLJ). Mini solar panels X-405 price lowered in preparation for avionics changes. RD-0105/0109 price lowered since there's no further upgrades any more. LR-105 added Placed and priced RTShortDish2 Wings, scoops, pylons, fuselages, ladders, lights, and tanks have more consistent costs US Hexacores Placed reaction wheels and Control Moment Gyros Various decouplers, clamps, and doodads. General bugfxies Fixups in Universal Storage parts and costs that were snagged on a bug. Launch clamps now have command capability Download here, or update via CKAN. (For those wondering, avionics *is* coming, but it's not in this release as it's still a work in progress. Contributions to the avionics branch are hugely appreciated!)

This is the best reason ever to take down a release! Thank you for saving everyone in the modosphere!

Update: I'm not quite sure why our indexing bot isn't running its regular updates, so I may have to escalate this to nlight or hakan. However I *can* manually reindex mods, so if there's anything that appears to be woefully outstanding then you can hop on IRC ( #ckan on irc.esper.net ) and either ask me nicely, or ".tell pjf Can you please re-index <favourite mod>" if I'm not around. (It's almost 3am here in Australia, so I'll be dropping into bed soon.) You can also ask nicely here, but I tend to see IRC messages first. On a more important note, the CKAN is proving to be so successful that we're very much in need of improved infrastructure to keep things running. If you work for a company that provides cloud infrastructure, or would be willing to cover our rather modest requirements, you can read more below. CKAN Infrastructure Sponsor Needed Many, many thanks, ~ pjf

TweakScale is now fixed. Thanks to archont for hopping onto the IRC channel and nudging us about it. However it appears that our index bot is currently AWOL. I'm taking a look around now and will try to nudge it as best I can. (However nlight is the expert on the indexing bot, and I'm hesitant to bother him on his birthday!) On that note.... Happy birthday nlight! :D

The following is my own personal opinion, and does not necessarily reflect that of the entire RP-0 team. It's *very* easy to hide parts which are not yet placed or costed in the RP-0 tree; much easier than tagging them with a notice. However it's also a terrible idea. A lot of parts in RP-0â€â€while not explicitly placed by handâ€â€will be at or near their final location. Many more of them will have RealismOverhaul support, meaning that their physical characteristics are correct, even if there's still discussion as to their cost, or their technology node. By clearly indicating which parts haven't finished the placement and cost process, we give players the choice of still using them if they wish. In some cases, one may consider this cheating, but as it's a single-player game, it's not like you're harming anyone else by doing so. In many cases parts are moved to earlier nodes, or reduced in price, so using the "unsupported" parts is actually a handycap. But there's one huge reason why having "unsupported" parts visible and tagged: we *know* they're unsupported. If these parts were hidden, there's no reminder when playing that their data needs to be updated. What's more, our users ask about the unplaced parts, and when that happens we can do something very, very cool. We can give them the power to place parts themselves. Anyone with a github account can edit the tech tree using that link. They don't need to be an existing contributor, they don't need to know how to code, they don't need any special software aside from their browser. Github makes sure that any edits are checked by both a bot and a human before they're merged. The game itself make the part identifiers visible in the VAB/SPH, so someone who's installed a mod and wants those parts supported can very easily start the process of making that so. A lot of RP-0 part placement happens because people want support for their favourite parts. Most of my contributions outside of the build system have been placing everything but engines. If you really want WIP parts to be hidden, I can probably give you a couple of lines of ModuleManager code that will do that for you. But from an overall project health, player balance, and project momentum standpoint, having parts which are tagged but not hidden isâ€â€in my most humble opinionâ€â€vastly superior. ~ pjf

Uh oh, you'll need to expand acronyms. I don't think we're using cascading style sheets to paint our craft gold and blue, are we?

Humble request, can the release on github be renamed to`v1.7.2` (instead of just `1.7.2`)? The CKAN core doesn't expect to see the 'v' at the front disappear. Many thanks again for all your amazing work! ~ pjf