TheOrqwithVagrant

I have this proble as well, but I think it may just be that RealFuels is not yet updated to v9 in CKAN, while the latest release of RP0 is specified to require it. I'm going to try updating manually to RF9 and see what happens.

It's impossible for me to read this without 'hearing' it with a really thick russian russian accent. XD

I'll just leave this here for all the people who think they know what fairing sizes and shapes are 'realistic': http://www.ata-e.com/asymmetric-payload-fairing The real-world rocketry indstury has been very, very 'conservative' for a long time. There are a huge number of cool/crazy things that we could do IRL that we just haven't due to cost/risk. Kerbals, otoh, are not exactly risk-averse, and part of the fun of KSP is to do the kind of things in space that we humans COULD do if we had unlimited funds and weren't afraid of risk. Complaining about ridiculously shaped fairings being allowed in a game where your KSP personnel will happily OK launching whatever insanity you put on the launchpad even if it has 5 SRBs with their business ends pointed straight at the capsule in the middle rings pretty hollow. Also, a lot of pFairing protesters seem to think fairings are some kind of magical hard-coded drag-eliminators. They're not - at least in FAR, and I would presume in the upcoming stock aero model as well, they are subject to the same drag calculations as the uncovered payload - for them to perform better, they actually have to provide an 'aerodynamic advantage' to the non-covered payload. If sanely sized, they will, but some of the examples here would probably get to orbit with much more dV left if flown without the fairing - though those sticky-outy girders just might get torn off if you pick up too much speed too low in the atmosphere.

Yeah... I'm playing on hard myself right now, with DR, FAR, Kerbal Construction Time & RT. I enjoy everything about it except the facilities upgrade grind. That's not hard, just tedious.

Aaah... I haven't built anything truly huge lately, but this was "The Hulk", my RSS Launcher for particularly bulky payloads, and certainly the largest craft I ever constructed: Nowhere near as cool or intricate as many of the designs here, but RSS + full realism overhaul do favor more minimalistic designs. The entire middle structure is pretty much all fairing space - 25m wide and 60 or so tall - lots of volume. For a little perspective, each of the side boosters of The Hulk is wider than a Saturn V. I brought ~600 tons to orbit with it, but it had dV and TWR to spare, so it could do more. It was surprisingly reliable. The second picture is what was inside - the science/living section of a very large interplanetary research craft. The propulsive unit launched itself, and was itself almost the size of the Hulk launcher.

Looks like the 6.4 may need updating with the latest RSS - I upgraded, and some really odd stuff happened - my satellites that were in Minmus orbit ended up in solar orbit, and my Minmus lander showed up ON the sun! Now I'm launching a new probe, and it seems like Kerbin's SOI ends well inside Minmus's orbit, which probably explains at least how the orbiters got punted to solar orbits. Probably (hopefully) an easy fix - I'll see if I can figure it out myself. Just be warned, if you have a bases or elaborate stations/sats around Minmus.

Minor upgrade 'hiccup' to watch for for 6.4x Kerbin config users - after I upgraded from 8.0 to to 8.1.1, my lander on Minmus got teleported to 700m above the surface of the Sun, and the mapper and com relay sat I had in orbit also ended up in solar orbits instead of Minmus orbit. The sats were easily hyper-edited back into place, but the lander, alas, was a loss. Super minor for me, but if anyone has built big bases on Minmus, they may want to watch out for this. EDIT: Not a minor hiccup after all - something in the SOI calculation has changed, and now Kerbin's SOI ends just beyond the Mun, well 'below' Minmus's orbit, causing all kinds of craziness for the 6.4x Kerbin config. This probably needs fixing if the alternative configs are going to remain possible, unless there's some way to tweak SOI from within the RSS config that I've missed.

I'm seeing some rather weird heating behavior on launch - everything is increasing gradually and 'sensibly' (For my rather overpowered launcher) up to 60km, then suddenly temps pretty much JUMP 200 degrees in the space of a few seconds, and various pieces start blowing up. I'm playing with the 6.4x Kerbin RSS config - perhaps some values need to be tweaked, since it's neither 'standard KSP' or 'standard RSS'... Suggestions welcome. For what it's worth, I do agree pre 5.3 may have been a bit too forgiving - even with a lifting reentry, it shouldn't be possible to do a Minmus return and not shed 1 point off of your ablative shield... This, however, is feeling like there's a magic invisible wall in the upper atmosphere.

It actually isn't working completely, for me at least - I do get the money for the contracts, but not the reputation, which results in not getting the higher-level/better-paying contracts. This is a huge hindrance when trying to run the RPL tree. RSS/RPL/RO is rather unforgiving wrt. budgets...

I was suspecting the data collection rate wasn't "as intended" - it made the "first flights" unexpectedly challenging, as you have to get the WAC probe in actual orbit to allow it to stay up long enough for a rad reading, or keep it "flying high" for a whopping _15 minutes_ to aquire data to do atmospheric readings... It was actually a fun challenge (once!), but good to know the fix is imminent.

If that's the intent, then wouldn't it be more sensible to simply add ModuleDeployableSolarPanel panel functionality to the probe core and/or make its power-draw super low? Either seem to be less balance-breaking than making an early probe a super-battery. The extra tiny size of this probe core makes it attractive for other things than its "intended" purpose, but the way things are now, you'd end up with "cheaty" levels of charge by building a multi-probe around this core. I really like the custom experiments, and the way they make progression "accomplishment-based" rather than the "grind" of most other trees including stock. However I'm not entirely fond of the way it's currently implemented, turning probe cores into "single use" parts. Sure, you can re-use the probe cores just like their "stock" versions - the custom experiments just won't be usable - but once you start doing things that turn the probe into a "super-part" that is better at something than the very best dedicated parts for the purpose, way up in the tree, even that freedom to be creative is broken by the unabalancing. This is by far my favorite tree (and I'm now playing it the way it's intended with RSS/RO/RF and the whole shebang), but one things that does bother me a little is that it feels like this tree is becoming increasingly focused on replicating historical probes/missions, rather than providing "realistic" and challenging, yet creatively open progression, and the super-battery-probe seems symptomatic of this. One suggestion for the future would be to keep a set of relatively "neutral" probe cores that can be picked for their geometry, weight, and tolerances, and the custom experiments can be added as "tweakables", perhaps with side-effects such as any custom experiment for Jupiter/Jool or its inner moons adding mass due to rad shielding, etc.

I think there's a few zeroes too many in the electric charge of the Vanguard probe (300000 ec), unless it was intended to double as the most powerful battery in the game.

My very first in-orbit constructed mothership, the "KSV A Return to Order" (so named for being a focused effort following a particularly chaotic/anarchic era of Kerbin's space program). I can't even remember how long it took me to fully deck it out. Refuelling that beast was a project in itself - after docking multiple 500-ton refuellers to a 1000+ part ship at 3fps or so a few times, I am permanently a docking and rendez-vouz ninja. I don't think I'll ever build anything in KSP for which I'll have this much sentimental attachment. This was in 0.19, just in case anyone wonders. I haven't built anything of this "class" lately, as I'm playing with RSS/RO now, and building something of this magnitude with "Real-life" constraints will be challenging to say the least - I'm still re-learning the ropes.

I really like this mod, but the radio receiver/spyatron needs some serious nerfing. The amount of science it can provide on any single body (landed/space low/space high for _every biome_) is absolutely preposterous, particularly given that almost all readouts away from Kerbin are "static".

I recently started playing with this tree and I have to say after trying out a whole bunch of different tech trees (and toying with throwing some together on my own), this is the one I'll stick with. The layout and costs are logical AND gameplay-friendly, and I was struck with how much more sane my "early days" constructions end up looking, and how much less "grindy" the Science and progression feel compared to other trees. Disclaimer: I don't play with either RSS or RealFuels so I know I'm not truly getting the "intended experience" with this tree, and since RealFuels is listed as an essential mod, I'm aware I might run into problems at some point. Anyway - my main reason for posting is that I think the specialized experiments/probe cores are a brilliant idea and a large component of the "grind reduction" (also, finally a _reason_ to use something other than the Octos). However, I find the current "per-planet/moon" specificity too restrictive; I think a better approach would be for the probes to be optimized for a world "type" than a specific world. This may be a little less "realistic" (since IRL, probes are always custom-built for the specific mission), but I think it will make for better gameplay, since you will end up with a "set" of probes for different conditions, and if additional planets are added via PlanetFactory or eventually by Squad, you can use this "set" of probes on these new worlds too, as long as you pick one that is optimized for the conditions of that "type" of planet/moon.

Agree wholeheartedly with this one, and I consider the point about the inconsistency of having dV readouts on maneuver nodes but nowhere else to be particularly telling - it's almost as if the devs "indecisiveness" about dV planning is reflected in the game by having this fragment of "dV awareness" left in, but no real way inside the game to use the information effectively. Agree that reentry heat should be in, though I could have sworn last I heard a dev say anything on the matter, the word was that it was coming at some point, but not high on the priority list. I think it should probably best be implemented after the current aerodynamic model is replaced with something better. Either way, the current situation feels like there's an "infinite aerobreaking" checkbox on the "debug" menu which we cannot uncheck; to me, it feels no less "cheaty" to me than infinite fuel or unbreakable joints. Not having it removes a whole class of spectacular failures...for those who are into that kind of thing. I don't think we need to worry too much about the current tech tree, and its "tutorialness" - I would expect this to change dramatically. One thing that I actually haven't seen mentioned in the many alternative tech-tree threads is the impact on part cost and budgets for balancing. There will be a major difference in how the whole tree has to work, once all parts from a node are not automatically available when the node is unlocked. Again, I see no reason yet to worry that the devs are making questionable decisions on this point; tech tree and career mode progression are in early days still. Introduction of money, contracts, budget and reputation mechanics will introduce plenty of ways to balance risk/rewards with probe .vs crewed missions. Disagree with you on this one. Publishing a roadmap would just end up "locking" squad into directions they may end up not wanting to follow. Sadly, people just cannot seem to read these things correctly, and tend to translate "we're playing with the idea of" to "THIS FEATURE WAS PROMISED" no matter how many disclaimers are included. Squad should maintain as much flexibility as possible, with as little grief as possible, and I believe even tentative roadmaps would cause unnecessary flame wars. I agree with the statement that "if people think there's something wrong with the game, they have a right to criticize it, without being told to use mods and to create your own game.", but I don't think it's fair of you to direct this criticism at Squad. Though it is frequently used by people who for some reason have an urge to "squash" opinion or suggestion threads, I don't remember ever seeing this purported "attitude" expressed the devs, just a small portion of the forum-frequenting fanbase.

I personally only run the 64 bit linux version these days. With the amount of mods I use, it's infinitely more stable than the windows version, which would crash incessantly. With the linux version, I regularly see my ram usage for KSP up to 7Gigs while remaining completely stable. There are two caveats though - AMD cards, even fast ones, unfortunately have atrocious performance with KSP. I recently switched (back) to an Nvidia card, and the performance difference is night and day. Second - you have to apply the "binary patch" (can be found on the linux compatability thread), or any mod using png textures will crash the game.

Rocket Millipede! Amazing!

I have this problem too. My "workaround" has been to eject the connector, then fly to the end of the tether and grab the connector. Rather annoying, but it works. Be sure to retract the cable before bringing the refuelled ship out past physics distance, or the refueller sometimes randomly goes kaboom.

The "binary patch" is sadly still needed for those of us with lots of mods, and needs different offsets compared to before. Here are the updated fix commands for 0.23, for everyone who keeps segfaulting at start: echo "838077: 00" | xxd -r - KSP.x86_64 echo "83807c: 00" | xxd -r - KSP.x86_64

"Laythe is given an oxygenated atmosphere with volcanic components: ~21% 02, ~9% N2, ~35% CO2, ~35% SO2". Ouch, so much for habitability - Laythe's oceans are now a lovely mix of sulfurous and sulfuric acid! Good thing KSP doesn't model corrosion yet.

To add a relevant fact to this, Al Shepard hit 11.6 G during reentry from his suborbital flight, and had manual control through this peak load; he didn't let the automatic control system take over until after he was past peak G. So though I do like the idea of the Kerbals becoming incapacitated above a certain G, the limit should be a lot higher than 7G. We already know Kerbals are a significantly more durable than humans just from the falls they can survive without any noticeable injury.

I've found one thing that looks like a 0.22-specific bug: ALT:RADAR no longer works; it always gives the same value as ALTITUDE. I've tested the same scripts on 0.21 and 0.22 with both kOS 0.84 and kOS 0.85; kOS version does not matter; ALT:RADAR consistently works on pre-0.22, but does not work on 0.22.

The KSV Frozen Lake - the second ship in the Courage-class. This ship (and the "Courage-class" in general) started as little experiment to create a Kerbal version of the Eagles from Space 1999 from (mostly) stock parts, and turned out successful beyond any expectation. These craft are wonderfully maneuverable and fun to fly, and can get to and from just about any world in the Kerbol system short of Eve, Tylo, Laythe and Kerbin.

This is awesome! Now take it to the next level make a big one that launches a smaller one, which in turn launches Jeb! Perhaps a two-stage slingshot launcher could at least reach orbit on Minmus