S4qFBxkFFg

Fair enough, I'll probably put together an extended config file for the stock parts and if anyone wants to use it they can - anything to help whoever ends up coding kerbal first-person movement inside craft...

My favoured solution to this problem would be for the Windows/OSX KSP installers to set up Linux as a dual boot then just install the Linux version... (I think the licences allow this?)

Apologies if this has already been pointed out, but assuming I'm reading the config files correctly, there seem to be a lot of parts that aren't marked as passable that nevertheless appear passable when viewing them. Is this just because no-one has submitted data for them? If so, I'd be happy to work through the parts and provide the necessary text to go in the configs. However, there are some cases where a decision isn't obvious - for example, decouplers appear hollow, so it should be fine for a Kerbal to physically pass through them but would they even be pressurised? I'm of the opinion that we should just ignore the concept of pressurisation until someone mods it into the game. (This could have an amusing result - if it does get implemented, and the decoupler isn't designed as a pressure vessel, we could see it "decoupling" laterally when Jeb opens a hatch in the next compartment...) Other things that should probably be passable are the 2.5m battery (it's got a hatch in its texture) and the 2.5m probe core (which appears to just have a black circle in the middle that might just be a hole - presumably so a kerbal can crawl inside to deactivate it when it goes HAL 9000). For two types of part in particular, I have no idea whether they should be passable or not so I'd like to hear what more people think before making any configs. The first category would be the bi/tri/quad couplers - for some of them (where it's 1.25m nodes on both sides) I'm not sure there's enough space for a Kerbal to fit through, whether the part is hollow or not. Also, should kerbals ever be able to be inside modular girder parts? If a docking port is connected to a modular girder adaptor, which then has more modular girders on its end, it's easy to imagine it being used as a type of corridor, albeit one that's open to space.

This is as far as this one goes - I pigged out on mods, so the save game is essentially broken and irretrievable and I've no idea which (if any of them) is to blame.

No probs - this seems to be a very strange issue, and if I'm the only one it's happening to, probably not that common. In any case, if it's going to be irrelevant from the next version then it probably makes sense to make that as good as it can be rather than tracking down weird bugs. btw, I really like the idea of turning the shrouds into service modules - it should allow for some elegant designs.

OK, I did some testing, and I'm not able to reproduce the suddenly-appearing-2.5m-fairing with a near-stock configuration. I can however rule out Kerbal Joint Reinforcement because even with that removed the same thing happens. Going to try the new config files now...

I support this idea, and also propose that it includes at least one full loop. e.g. http://cdllife.com/wp-content/uploads/2012/07/Screen-shot-2012-07-02-at-11.05.01-AM.png (because Kerbal)

Thanks for the config files - I'll try it the next time I'm able to play some KSP and let you know how it goes. Also, I have a tentative feeling the joint reinforcement mod might, perhaps, have something to do with this (it's the only one I can think of that actually fiddles with the connections between parts) so I'll try loading my problem save with it disabled and seeing what happens. random thought: are attachment nodes something that can be changed using tweakables? This seems like it could satisfy everyone if so - use either node (or both, if your designs can exploit it) as you prefer.

Also... I asked Ferram about the coming-in-sideways re-entries, and I don't think the CofG is a problem; it seems FAR uses unattached nodes in its calculations, so only using one of the lower Radish nodes causes drag problems. link to the relevant post: http://forum.kerbalspaceprogram.com/threads/20451-0-23-Ferram-Aerospace-Research-v0-12-5-2-Aero-Fixes-For-Planes-Rockets-1-7-14?p=987181&viewfull=1#post987181 So, my question is, is it possible for me to change this by editing any config file? What I'm wanting to do is essentially create two versions - one with a 1.25m node and one with a 2.5m node.

An excellent mod, but would it be possible to disable the 'i' hotkey while typing text? It's a little bit annoying when it keeps flashing in and out when typing a description for the rocket.

I have a save game where loading it just after starting KSP will cause this consistently, not sure how much use it will be (lots of mods involved), but I'll PM you the link to download it, as well as the KSP.log file. I should say that I don't know what's causing this bug, and that it may be nothing to do with the HGR mod, with all the mods I run it could be anything, but I thought it was weird that I built the rocket without using the 2.5m node, and its 2.5m fairing appears suddenly when loading the game. edit: for anyone else that reads this and has the same problem, I've figured out a workaround, I load my sandbox game first, close that, then load my career save - and everything works as it should edit 2: when using the load-another-game trick you have to actually load a vehicle (just placing a pod on the launch pad and recovering it is sufficient)

I've discovered what might be a particularly nasty bug associated with the 2.5m fairing, summary of how to reproduce follows: 1. build rocket using 1.25m parts, 2.5m attachment node unused 2. launch to stable orbit 3. go to space centre view 4. exit game 5. restart 6. go to tracking station 7. fly spacecraft BOOM, spontaneous disassembly, pod remains apparently undamaged in cloud of debris, pod has 2.5m fairing attached. Strangely, if I quickload, it goes to my previous quicksave without any problems.

@ferram4 Couple of questions, one of which may not even be FAR related: I've been using the HGR-57 "Radish" pod (http://forum.kerbalspaceprogram.com/threads/60974-23-Feb-12-HGR-New-spherical-pod-available) and have noticed some strange behaviour on re-entry - if often orients itself pretty much side-on to the airflow instead of tail-first, sometimes its own reaction wheels are enough to rectify this, sometimes not. On one occasion, it was performing as expected above M1 before "flipping" to the side-on attitude when speed dropped below M1. More details here: http://forum.kerbalspaceprogram.com/threads/64897-Reconstruction-a-0-23-career-mode-story One detail that may be relevant is that this pod has two attachment nodes (for 1.25m parts as well as 2.5m), one of which will normally not be used, and I saw in an earlier post that this could affect drag. The question: is there something in this pod's design that would need tweaked to work with FAR, or is there something else that's more likely to be causing this behaviour? The second question: does it make sense to build a swing-wing aircraft with FAR (using Infernal Robotics, or similar)?

In one of the earlier posts, the author said the hotkeys were disabled while typing - but in the latest version, it seems they're now enabled again. Easily reproducible by clicking on the rocket name, then typing for a while in the description box that appears.

Intended to enter polar Münar orbit, the 4d design is essentially a 4c with additional boosters and more life support supplies. Making its début is the dust sensor which we expect to provide more information about the interplanetary medium. The celebrity (Jeb) is finally back in the Kerbonaut roster, and will be joining our Münar veteran, Bartdrin. MISSION REPORT Crew: Bartdrin Kerman, Jebediah Kerman Result: undetermined Status: Orbiting Mün Details: Due to the six solid fuel boosters, thrust was extremely high - aerodynamic heating was observed for much of the ascent so it is likely much delta-v was wasted fighting atmospheric drag. Nevertheless, the fairings held up and no damage was apparent, allowing a (higher than usual at about 300km) stable parking orbit to be achieved. The Münar transfer was performed with a significant normal component so that the vehicle would go "over the top" of the Mün, entering a polar orbit. However, the resultant orbit was not as inclined as expected, and it was necessary to expend more fuel to increase inclination such that most of the Mün's surface could be overflown at approximately 30km altitude. An extensive altimetry scan was carried out, during which several observations of unfamiliar areas of the Mün were made from EVA. In total, 82.8% of the Mün's surface has now been mapped at a low resolution, the exceptions being the polar regions. Throughout the flight, samples were collected by the dust experiment, this appears to have collected moderately useful data. Due to the limited delta-v available, the vehicle appears to be stranded in Münar orbit until some sort of rescue mission can be attempted; this has been given maximum priority.

Third Münar flyby, this will probably be the last time we use this flight profile as we want to actually enter Münar orbit at some point. Some minor changes have been made, including the removal of the Communotron 16 antenna. Bartdrin is taking a well-deserved rest; Jim and Mildred have been selected for this flight - their first to the Mün. MISSION REPORT Crew: Jim Kerman, Mildred Kerman Result: Success Status: Recovered Details: This mission proceeded largely as planned although it appears there are diminishing scientific returns from Münar flybys - to increase mission productivity, the next mission should involve a (preferably polar) orbital insertion, requiring more fuel on the upper stage. Atmospheric re-entry was again problematic - it was impossible to orient the capsule in a tail-first direction but fortunately neither the capsule or its parachute appeared to sustain damage.

Would making the orbital paths appear "thicker" when closer to the point of view be helpful here?

I may be repeating the words of others here, but the lack of re-entry heat in the game does seem like an obvious omission (the obviousness being exacerbated by the visual effects). BLUESTREAK's post put it very well. I do think the temperature parts of the game need improvement in general though - at the moment we have a bunch of mods filling these gaps in different ways - deadly re-entry, KSP Interstellar etc. Also, the point about restricting "crazy" "Kerbal-ish" design: imagine one of Whackjob's creations loaded up in a game with deadly re-entry enabled, and coming in to atmosphere with enough heat shields added to survive - wouldn't that be a sight to see? Re-entry heat wouldn't stop your crazy contraptions - it would inspire you to make them even crazier.

YOU CAN DO THIS?!?? That's up there with learning that staging can be locked and that manoeuvre nodes can be clicked and dragged.

I agree with everything else you say (the first idea will appear in the stock game, I think and the last one can be done with the KAS mod for now). Specifically on magnet power, a concession to realism might be to have docking ports consume a lot of electricity when their magnets are activated, and yes, perhaps make them a little weaker.

It's easy enough with this: http://forum.kerbalspaceprogram.com/threads/54533-0-23-VOID-Vessel-Orbital-Informational-Display . What I did was get them in a roughly circular 250km altitude, then thrusted back-and-forth prograde/retrograde until their orbits were exactly 44 minutes (sort of - in reality 43:59.9 was easier to get). I used the Vesta engine tweaked in-flight to 5% for the fine manoeuvres. Definitely - I want to get some progress before 0.24!

Our second Münar mission, with the same flight profile as 4a, will continue study of the Mün and surrounding space with some additional instruments - mobile lab, mystery goo, and an altimetry sensor. The reach of the LOCOM network will also be verified with dish and omnidirectional antennae. The 4 Globe I boosters have been exchanged for 3 of the newer Globe Vs Bartdrin and Bob have been selected as crew; despite the two flights in a row for Bartdrin, he appears sufficiently well rested while our attention has been directed at the LOCOM missions. MISSION REPORT Crew: Bob Kerman, Bartdrin Kerman Result: Success Status: Recovered Details: Ascent and Münar transfer went as planned although it was not foreseen that the middle stage would remain in orbit around Kerbin - we should probably figure out a way of stopping this happening in the future, or how to fix it if it does. The LOCOM network is inadequate for supporting missions to the Mün and Minmus - communication via its satellites was impossible from approximately half-way between Kerbin and the Mün. The mission was scientifically productive, if perhaps not as pioneering as 4a. Return and re-entry were successful; enough fuel was retained to provide some braking, and the capsule's heat shield did not fully ablate. The improved capsule maintained a tail-first attitude during the supersonic phase of re-entry without the need to use the reaction wheels although at slower speeds there was still a pronounced turn to a side-on position relative to the airflow. This did not appear to have any significant effect although the crew described it as slightly disconcerting. The capsule landed several hundred km east and slightly north of KSC near a shore; recovery was uneventful.

We have a new pod/lander - the "Spud" - this ground test while checking out the science instruments on the runway should allow Jim to get a feel for it. MISSION REPORT Crew: Jim Kerman Result: Success Status: Recovered Details: This pod gives a better view than the other two that have been tried - we're seriously considering using it in landers or perhaps a long-duration station orbiting Kerbin.

1c - Radiators and deployable solar panels have been added - two small fixed panels have been retained for backup. 1d onwards - This design looks adequate for the task - no need to change it until the constellation is complete. MISSION REPORT Crew: n/a Result: Success Status: Orbiting Kerbin Details: Satellites 1c through 1f were launched in sequence and manoeuvred into roughly circular equatorial orbits at 250km altitude. Their relative longitudes were adjusted such that they formed a pentagon centred on Kerbin and orbital speeds were matched to achieve as close to 44 minute orbits as possible, to preserve this arrangement. While the pentagonal configuration was viable, the decision was made to launch one more satellite to improve the robustness of the network by shortening transmission distances and increasing the clearance between the lines-of-site and Kerbin's horizon. Incidentally, LOCOM 1b appears to be coping with heating effects and we hope will reach a state of equilibrium before sustaining mission-threatening damage. We now appear to have a reliable communication network capable of supporting missions in the near-Kerbin region of space - this is expected to encompass most of the way to the Mün's orbit, with the exception of the higher/lower latitudes of Kerbin. One of the tasks of the next Münar mission will be to determine the distance at which communication with Kerbin is no longer possible. If desired, we have tentative plans for LOCOM satellites in highly elliptical polar orbits to allow communication with the rest of Kerbin's surface.

This is something I discovered while adding a description to my rockets in the VAB - when I'm typing in the text field (the one that appears when you click on the rocket's name), all keys still have their "non-text" functions. For example, when using the cursor arrows to move through text, the view rotates also. My suggestion is that all key shortcuts that don't apply to editing text be disabled while there is a text cursor (the blinking thin vertical line) active.