micha

Eh, it was aimed at the author, not at end users Thanks for posting your MM patch! Hopefully AK will be back soon to make a proper release. EDIT: As for lines being removed, then re-added, that's just the way diff works sometimes, depending on the changes. It's not meant to be used directly by a human for editing files!

I wasn't meaning to sound negative with that headline, perhaps the words have different connotations in different cultures. I'm all for publicising our efforts in space exploration, raising awareness. Otherwise I wouldn't have passed it on!

FYI, if you're not aware of it already, bit of fun: http://insight.jpl.nasa.gov/newsdisplay.cfm?Subsite_News_ID=38315

Played with it on a couple of VM's. Really dislike the interface, but then again, a lot of OS/App updates are going the same way (flat shaded, few/no borders between GUI elements, kindergarten colours (or, even worse, just greyscale), etc etc). There was a reason we went from flat stuff to faux-3d. Seems all the new graphic designers have forgotten that and want to stamp their own style on the current gen of GUIs. Meh, at least give users the option to skin the interface back to something sane. Or at least ensure there's a huge boost to performance. Apart from that I'm somewhat wary about the amount of tracking; I've turned it all (or as much as is possible via the standard interfaces) off, but packet scanning still shows lots of traffic going to Redmond. Also wary about forced updates, I hack all of my Win7 boxes to NEVER update unless I tell it to (involves various hacks otherwise even Win7 keeps turning stuff on, gah!, worst thing when you come into the office the next day to find your boxes have rebooted and you've lost work). Core-OS functionality-wise, it seems to be ok, but I'll wait and see how the rest of the world gets on first. So I don't see myself performing the "upgrades" from Windows 7 on my actual machines anytime soon. Not that I use Windows much at home - 99% of my time is in Linux anyway. Unfortunately various hardware vendors (eg Garmin) refuse to support other OS's.

I've managed to collect all the way back to 0.7.3. The game sure has come along a bit since then..

What a totally ........ thing to say. You will definitely die no matter what you do. Dying of a motorbike-related incident does raise your chances of dying earlier than otherwise, but that depends largely on yourself and to a lesser extent those around you. I've been riding motorbikes for nearly 20 years now (initially Australia, now UK), although I did get onto them a lot later than most (mid-twenties). Haven't had a major incident yet, although there were some close shaves. To be fair some of my mates haven't been so lucky, and usually the fault was not with them but with the other party involved. So the point about being more vulnerable is not one to take lightly. I think what aided me in keeping out of trouble (apart from a good dose of luck) was that I was well-versed in general street craft by the time I got onto one, and I got a totally underpowered one to start off with, which meant I couldn't really do anything too silly even if I had wanted to. By the time I got onto a more powerful bike I had learned some additional respect. Bikes can be a heck of a lot of fun, but you really need to develop a sixth sense to watch out for all the numpties on the roads, and there is very little room for error. But you have to also ask yourself, apart from getting to/from school, where would you go, and would wherever you go be better than where you are (for now)? Developing a fun local hobby definitely has benefits, and you have far more opportunities for that than people a few years ago did. Just having access to the Internet and all of its information is HUGE. Pretty much anything you want to pursue you can find out so much information about, specialists only a few decades ago would have given their right arms for. I also grew up in a smallish village and had a 10km ride (pushbike) to school. One way. Against the wind. Uphill both ways. In torrential rain. Yaddayaddayadda.. Apart from that I had a local library and took up various hobbies (flying kites, astronomy, reading,...) until technology (and my savings) progressed to home computers. Never looked back after that! Learn to code. Addons for KSP, since you're already here. Creative and potentially job-creating in the future. - - - Updated - - - Starting on a moped (as opposed to a full bike) would definitely be a Good Thing IMHO. A) you're properly part of the traffic, unlike on a pushbike, so you'd be getting used to road rules etc. It's too slow for you to do anything stupid on, so you'll get the hang of handling yourself in traffic without the temptation (or better, the ability) to drag-race or do any number of other silly things. While that might sound prejudiced, it's what (most) young people will (want to) do. I know I did.. C) You'll find out whether motorbiking is your kinda thing or not without spending huge amounts of money on it Whether you then move on to a car or a bike is up to you and your experiences on the moped. It'll extend your range a bit over a pushbike, but yeah, if you really want to go a bit further afield it's only a stop-gap. Although you can get mopeds which do over 60mph these days too... not sure of the license requirements though.

Mr.Scruffy; agree with your points, but I think there's still scope for "interesting" areas even away from "interesting geometry". Also the poles would just be chock-full due to the way the geometry system works. But yes, the contract system does need a bit of an overhaul. OTOH, you're not forced to take contracts - I only take contracts which further my own in-game goals. (Eg, I'm building a base around the Mün, so I'll take high-paying contracts to, eg, send a satellite there. Along with it, I'll send another station module. Then I leave the satellite until I get an Impact contract (mod), or use the satellite as a ScanSat (mod) satellite, irrespective of what the original contract wanted me to do with it). So still somewhat constrained by contracts, but I never spam 5 launch a satellite contract for no reason other than funds. Better would be a larger overhaul - but anything I can think of requires time-based mechanisms, which Squad hasn't, and, by the sounds of things is unlikely to, implement. For example, periodic budget payments, based on rep which decays over time, and missions attempted/completed, so you can't just timewarp to get infinite funds. But you'd also need other time-based expenses and events (eg, life support, Kerbal Construction Time, etc) to balance it. There'd still be a place for contracts, which would be private companies wanting you to do stuff for them. That way your primary mission (get all the science) is mainly funded by the budget, but you can also earn pocket-money and extra rep with contracts. Not a trivial thing to design and balance so it's fun. Fully agree on using Science as the "high score" though - this is something I've posted before too.

As someone else said, once you've done it once, any hand-generated special terrain will not really have any replay value. It's also a LOT of work for the devs, something which may come eventually, but for now I daresay they have their hands full with other work. And while procedurally generated content may not have the sparkle of hand-crafted content, it is better than nothing and essentially available for free once the underlying routines are written (which is no small taks either). After that it's just setting (or generating) seeds and having the engine create content for you. Still a lot of work, but not as much as modelling precise scenes. And it's also a LOT kinder on your Computer specs (no need to keep procedurally generated content in memory when not looking at it). Replay value in KSP is different things for different people. However, in the context of (surface) exploration, it is having more stuff to do. So I fully support having some sort of "interesting feature" generator which can populate the area around you with some special stuff. Although I'd argue against random generation and have deterministic generation instead - that way if you find something neat, you can tell other people to land at X and they'll also see it. Even though it's outside the scope of this thread, I also like the idea of a procedurally-generated solar system with a "fog of war" forcing you to send out probes first to discover the details of planets and moons before sending out landers or kerballed missions. Again, this should be deterministic in the sense that you should be able to share the seed value with other players so they can enjoy the same system. Finally if the deterministic generator only places "interesting" stuff in a few locations around a planet, rather than everywhere, that could tie in nicely with the contract system which could then generate contracts to land people near the special content. So yes, you can still discover it on your own by luck (I found an anomaly on the Mün by luck), it would mostly be by following contracts, and those contracts should only be generated after some sort of planetary scan.

Don't know about the other guy, but I like VirtualBox.

The driver is (probably) installed fine, but the NVidia Settings application is a separate install (at least on Debian). Try this: $ sudo apt-get install nvidia-settings

Both 32-bit and 64-bit versions are installed for Linux. The 32-bit binary is called KSP.x86. The 64-bit binary is called KSP.x86_64. Simply run the one you want(*). If you use a launcher or script you may need to adjust it accordingly. This thread has a lot of good info, but beware some may be outdated. (*) You need a 64-bit version of Ubuntu to run the 64-bit version of KSP. Conversely, if you're on a 64-bit version of Linux and want to run the 32-bit version for some reason you need to install a whole pile of 32-bit compatibility libraries.

True; but then what's to stop people using that system everywhere. Bingo, you effectively have full perfect autopilot everywhere, something Squad has been against since forever. I also can't think of any good in-game justification why it would ONLY work while probes are occluded. Furthermore, the maneuver node system as-is is insufficient for landing burns. Such a system would also prevent things from going hilariously wrong. When the player performs a burn there's always the chance the burn isn't perfect. Hitting the wrong key, drifting off course, getting the timing wrong, etc. And this is, arguably, what a lot of KSP is about. Sure, a lot of people play KSP closer to a Sim, but for those people there's mods.

Is it actually the rocket flipping all over the place, or the camera? When you enter an orbit your camera mode automatically changes; the same happens when you go from orbital to sub-orbital flight.

No problem with suborbital at the start of the game returning a Science Junior. Just put a heat-shield on for the counterweight so you re-enter "properly" - it's hardly surprising you don't slow down enough if you re-enter front-first. Edit: You can adjust the amount of ablative on the heatshield to suit so you have enough weight but not so much that you can't make sub-orbit. Also remember to remove your RCS fuel from the pod.

Worked out of the box for me using Debian GNU/Linux and KDE (the starting it from a shortcut thing). If Ubuntu and Unity can't do that, create a small helper shell script, which you can then double-click to run. In the same directory where the ckan.exe is, create a new file: #!/bin/sh mono ./ckan.exe Make it executable (you can use the file-manager, or, from a terminal, the "chmod" command), and then double-click on it. CKAN should start up. You can also rename the launcher to whatever you want (it doesn't need the .sh ending either; that's just convention).

Actually, just found this out through the Squad bugtracker, you -can- rename vessels which you don't have control over. Go to the Tracking Station, select the vessel, then open the Info Panel. You can click on the top-orange bar and rename the vessel. This -only- works in the tracking station.

That's a great little mod; thanks! I shall have to incorporate that into some of my more complex designs with interstage fairings holding landing craft. I try to deorbit everything (either destructively or ala SpaceX), but with interstages I end up with either a small adapter or a separator (depending on whether I'm using stock fairings or Procedural Fairings), and I have no (easy) way to deorbit that.

There is an educational version of KSP - I haven't used it myself so I don't know how it differs from the standard version (apart from licensing).

Had a bit of a muck about, and the following patch seems to work (only tested near the launchpad so far). It allows anybody to attach/detach the experiments from the ground without any tools (use the H key for this). Still need a Scientist to actually run the experiments. Couldn't get them to explode on the launchpad just dropping them, but they did make nice fireworks on Minmus. Actually attaching the parts instead of just dropping them fixes the explosions. Now they are still exploding on drop, but work nicely when attaching. diff -Naur MunarSurfaceExperimentPackage/Parts/InteriorHeatProbe/part.cfg MunarSurfaceExperimentPackage.mw/Parts/InteriorHeatProbe/part.cfg --- MunarSurfaceExperimentPackage/Parts/InteriorHeatProbe/part.cfg 2015-06-11 14:33:00.000000000 +0100 +++ MunarSurfaceExperimentPackage.mw/Parts/InteriorHeatProbe/part.cfg 2015-07-27 22:08:35.327243120 +0100 @@ -55,26 +55,18 @@ MODULE { - name = ModuleKISItem - shortcutKeyAction = drop - usableFromEva = false - usableFromContainer = false - usableFromPod = false - usableFromEditor = false - stackable = false - volumeOverride = 50 - editorItemsCategory = true - moveSndPath = KIS/Sounds/itemMove - equipable = true - equipMode = part - equipSlot = leftHand - equipTrait = - equipRemoveHelmet = false + name = ModuleKISItem + volumeOverride = 50 + equipable = true + equipMode = part + equipSlot = leftHand + equipTrait = equipMeshName = body01 equipBoneName = bn_l_mid_a01 equipPos = (0,-0.04,0) equipDir = (80,0,0) - allowAttachOnStatic = true + allowPartAttach = 0 + allowStaticAttach = 1 + staticAttachBreakForce = 0.1 } - } \ No newline at end of file diff -Naur MunarSurfaceExperimentPackage/Parts/IonDetector/part.cfg MunarSurfaceExperimentPackage.mw/Parts/IonDetector/part.cfg --- MunarSurfaceExperimentPackage/Parts/IonDetector/part.cfg 2015-06-11 14:33:12.000000000 +0100 +++ MunarSurfaceExperimentPackage.mw/Parts/IonDetector/part.cfg 2015-07-27 22:08:34.339232325 +0100 @@ -57,25 +57,18 @@ MODULE { - name = ModuleKISItem - shortcutKeyAction = drop - usableFromEva = false - usableFromContainer = false - usableFromPod = false - usableFromEditor = false - stackable = false - volumeOverride = 100 - editorItemsCategory = true - moveSndPath = KIS/Sounds/itemMove - equipable = true - equipMode = part + name = ModuleKISItem + volumeOverride = 100 + equipable = true + equipMode = part equipSlot = jetpack - equipTrait = - equipRemoveHelmet = false + equipTrait = equipMeshName = jetpack_base01 equipBoneName = bn_jetpack01 equipPos = (0,-0.15,-0.12) equipDir = (10,90,10) - allowAttachOnStatic = true + allowPartAttach = 0 + allowStaticAttach = 1 + staticAttachBreakForce = 0.2 } } \ No newline at end of file diff -Naur MunarSurfaceExperimentPackage/Parts/RetroReflector/part.cfg MunarSurfaceExperimentPackage.mw/Parts/RetroReflector/part.cfg --- MunarSurfaceExperimentPackage/Parts/RetroReflector/part.cfg 2015-06-11 14:33:24.000000000 +0100 +++ MunarSurfaceExperimentPackage.mw/Parts/RetroReflector/part.cfg 2015-07-27 22:08:33.539223583 +0100 @@ -55,26 +55,18 @@ MODULE { - name = ModuleKISItem - shortcutKeyAction = drop - usableFromEva = false - usableFromContainer = false - usableFromPod = false - usableFromEditor = false - stackable = false - volumeOverride = 100 - editorItemsCategory = true - moveSndPath = KIS/Sounds/itemMove - equipable = true - equipMode = part + name = ModuleKISItem + volumeOverride = 100 + equipable = true + equipMode = part equipSlot = jetpack - equipTrait = - equipRemoveHelmet = false + equipTrait = equipMeshName = jetpack_base01 equipBoneName = bn_jetpack01 equipPos = (0,0.21,-0.05) equipDir = (280,0,0) - allowAttachOnStatic = true + allowPartAttach = 0 + allowStaticAttach = 1 + staticAttachBreakForce = 1 } - } \ No newline at end of file diff -Naur MunarSurfaceExperimentPackage/Parts/SolarWindSpectrometer/part.cfg MunarSurfaceExperimentPackage.mw/Parts/SolarWindSpectrometer/part.cfg --- MunarSurfaceExperimentPackage/Parts/SolarWindSpectrometer/part.cfg 2015-06-11 14:33:52.000000000 +0100 +++ MunarSurfaceExperimentPackage.mw/Parts/SolarWindSpectrometer/part.cfg 2015-07-27 22:08:31.939206102 +0100 @@ -55,26 +55,18 @@ MODULE { - name = ModuleKISItem - shortcutKeyAction = drop - usableFromEva = false - usableFromContainer = false - usableFromPod = false - usableFromEditor = false - stackable = false - volumeOverride = 100 - editorItemsCategory = true - moveSndPath = KIS/Sounds/itemMove - equipable = true - equipMode = part + name = ModuleKISItem + volumeOverride = 100 + equipable = true + equipMode = part equipSlot = jetpack - equipTrait = - equipRemoveHelmet = false + equipTrait = equipMeshName = jetpack_base01 equipBoneName = bn_jetpack01 equipPos = (0,0.0,0.01) equipDir = (280,0,0) - allowAttachOnStatic = true + allowPartAttach = 0 + allowStaticAttach = 1 + staticAttachBreakForce = 0.1 } - } \ No newline at end of file PS. Couldn't find a GitHub (or similar) repo, so not sure how else to send you the patch.

I look at it more as being the probe's flight-computer executing a pre-programmed set of instructions; an AI would be able to adjust to each situation automatically. The difference only really makes sense once you introduce a game mechanic where you lose communication with the flight-computer, as the proposed Communications System will have. Ie, a Flight-Computer must be pre-programmed (eg, burn for 20 seconds retrograde), and can't change its programming (although it can and should perform additional minor adjustments if, for example, the craft veers slightly away from retrograde heading while under acceleration) unless in communication with a controller; whereas an AI can do whatever it needs to in order to execute a broad objective (eg, enter a circular polar orbit at 200km).

If you burn while letting the maneuver node drift away from your actual heading, the resultant orbit won't be what you plotted. That may or may not matter much depending on the actual burn. But to end up with the exact orbit you plotted, you need to stick with the maneuver node; whether you do it manually or via a skilled pilot / advanced probe core.

Waypoint Manager mod FTW And yeah, apart from the occasional fling I've never gotten into the planes aspect of KSP. About the only part I want out of the entire aero sub-tree are the airbrakes which are nice (but not essential) for building recoverable launch stages in the SpaceX style. In my current career I haven't even bothered upgrading the SPH or Runway.

Great stuff! And thanks for posting what you did to fix it - could help someone else down the track.

Also, there's default or override (I don't know which) graphics settings stored in ~/.config/unity3d/Squad and ~/.config/unity3d/SQUAD (yes, case-sensitive means they are separate directories in Linux; at some point someone should raise that as a bug-report to Squad). By default, "dot-files" (starting with a period/dot, ie".") are hidden. There's no separate "hidden" attribute for files like there is in Windows/DOS. So you'll have to "show hidden files" in your file manager (or use "ls -la" on the terminal - list long all) So if you edit the config file manually to change the resolution, either delete those directories (they'll get re-created next time you run KSP) or make the same changes in them. - - - Updated - - - I changed mine to use Left-Alt like the Windows default, but if you do that you have to also disable Left-Alt in your Window Manager (either for the KSP Window specifically if your WM allows it, or generally) - that may or may not be possible in Unity. Still, Right-Shift-F12 should do the trick, unless Unity (or your keyboard? You mentioned an FN key) overrides that as well. - - - Updated - - - You can also edit your config file to change (or add) an extra key to be the Modifier key in the settings.cfg; I don't think Unity uses the Windows key so that'd be a great choice.

The Linux version of KSP doesn't have "exe"'s. If your binary is called "KSP.x86_64.exe" you've got the wrong download. The easiest way to get some more information is to open up a terminal window, "cd" to wherever you've extracted/installed KSP, and try to run the binary. eg, You've installed it in your home directory, ~/KSP (I'm making this up, I have no idea where a non-Steam install goes), then you'd do the following (where "$" means your command prompt, it's not something you'd type in): $ cd ~/KSP -> This changes directory to the KSP directory; replace "~/KSP" with wherever you installed/extracted KSP. $ ls -l -> This lists (in -long format) the directory; check to make sure you have KSP.x86 and KSP.x86_64, and that they do NOT have the .exe endings, and that they are executable. $ LC_ALL=C ./KSP.x86_64 -> This runs the KSP.x86_64 binary (assuming you're in the correct directory, the binary exists, and it is executable). The "LC_ALL=C" is kinda optional, but it reduces problems on enough systems that I always recommend to add it; it won't break anything. You should now either get KSP starting up, or get some sort of errors popping up on in the terminal. Please post the result. As for fixing opening ".exe"'s on Linux, generally you'd need to install Wine (Wine Is Not an Emulator) which gives you access to some Windows APIs, allowing you to run (some) Windows binaries under Linux. How you'd break the association with pypar I don't know - that depends on your desktop environment. If you're running standard Ubuntu that would be Unity, and I haven't used that in years, but there should be a configuration option somewhere.