cantab

To clarify, I didn't call it close, just brilliant.Anyway, still not gotten, so Hint 4: I expect you can find one in your home.

Just to throw out some possibilities: Stock levels and stock levelling only. Means what you describe, needing to train kerbals by flight to fix stuff. Stock levels with paid Dang It training. From a DI point of view acts like at present, but it messes with the stock game a bit, you could get a highly-trained engineer without them leaving Kerbin. Dang It levels with paid training. Closest to existing DI behaviour I think, the main change being tying into the stock jobs. Dang It levels with paid training *and* a cap from the stock levels. This could be interesting, the toughest of both worlds, to fully train a Kerbal in DI requires levelling them up in stock and paying them in DI. An advantage could be that you could reasonably make the stock level needs quite low, eg Level 2 in stock is enough to get max level in DI.

A thought I had is to map Mechanic > Engineer and Electrician > Scientist, or otherwise make some repairs require a scientist rather than putting it all on the engineer. Scientists aren't much use in the stock game, so giving them some use in Dang It! would help. Oh, and another request: Can it be possible to remove the glow from a failed part? I don't want to turn glow off outright because it helps me identify which part has failed, but often my response is to ignore the fault and then I have a red glowing part on all my screenshots.

In my view: Fix the existing bugs. I for one will tolerate bugs in new features but will be Really Rather Cross Indeed if bugs that plague 0.90 are still in 1.0. Reviewers and new customers and potential customers won't draw that distinction though, and will see all bugs as problems. And "the fix would be made obsolete when we update to Unity 5" is not going to wash as an excuse at all. Neither, for that matter, is "It's a Unity problem" really going to wash as an excuse for any bugs either; if there is a Unity problem, it's Squad's job to work around it, like they already did to deal with floating point precision issues. Specific incredibly annoying bugs: User interface clickthrough. Apple, Microsoft, and others worked out how to handle this in the 1980s. There is no excuse for clickthrough in 2015 and for that reason it's my single most hated bug. The every few seconds stutter. This seems to affect some players more than others and some situations more than others; I've found the best test is to get into low Mun orbit, look down, and go to 10x warp and the stutter in what should be a perfectly smooth motion is very apparent. It totally breaks immersion in the game. Speculation is the stutters are due to Unity's garbage collection. The infamous memory leak. I think that might only affect certain builds, I've not suffered it myself on Linux 64-bit, but for those it does affect it's a major issue making the game sure to crash in major playing sessions. Ridiculously slow load times - as in, way way slower than is normal even for KSP - with certain network configurations. IMHO this needs fixing because it's so downright weird and non-obvious players are going to struggle to work around it. Reviewers who happen to be affected may well review the game with "The game took fifteen - yes, one five - minutes to load on our $6000 Dream PC. The game might be playable on slower computers, but it won't be loadable on them." As for other things, ISRU and newstock aero want to be in 1.0 to support balancing the game better. None of ISRU, aero, or the game balance need to be perfect, but they need to basically work and be as bug-free as is reasonable.

Brilliant! Wrong, but brilliant. It fits most of the riddle so well. Nor is it a telescope, computer, or CCTV camera. And "flash of inspiration" was not a hint.

On the other hand if you do have multiple engines - even all on the one tug - you can tweak the thrust limiters on them to compensate for any misalignment. If you have KER it will even tell you the thrust torque, just play with the limiters until that's near zero.

More noes. Surely someone must have a flash of inspiration at some point.

Are there monoliths in your town? Not book, library, bookshop, matter, or shop.

Not a memory and not the internet. And I suppose we can have another hint. Hint 3: You can almost surely find one in your town.

From a quick look at KIS, I'd say I'd rather not see Dang It! depend on it. It seems like a lot of complexity which means potential bugs, and a lot of extra capability which can mean an "easier" game.

Meet it it solar orbit, nice and far from Kerbin. This takes more delta-V, but that's delta-V when you're not pushing the asteroid so it's cheap fuel-wise. There's a tutorial on how to meet asteroids in solar orbit but the key idea is to leave Kerbin's SOI in the direction the asteroid is set to come into it. Once you've met it, course correct for an initial aerocapture. Give yourself a margin of safety, for example aim for a periapsis of a few thousand km. Alternatively, correct for a gravity assist from the Mun into a closed Kerbin orbit. Either way this should not require much delta-V. Make final corrections in Kerbin's SOI. Again, not much delta-V needed unless you have an awkward desired orbit. I captured a 500-ton class D using this tug with nuclear engines and half an orange tank of fuel. Extrapolating from that, three orange tanks should be good for a class E. Double that if you're using chemical engines. As for how to handle the asteroid, I used detachable control sections dotted round the asteroid. They turn the rock and the rock turns the tug. Another way is to not try and turn the rock round at all, but instead fly the tug and claw facing the desired way to push/pull it.

Maybe this is a dumb question, but if things are going to be changed why not standardise on 1 unit = 1 kilogram? Then CRP doesn't have to worry about density at all, it's a matter for the people making storage parts to consider. And say Modmaker X reckons their tanks should hold Argon Gas at 150 bar and Modmaker Y reckons it should be 300 bar, both just give their respective parts the configs they reckon are right and neither is ignoring any density assumed by CRP.

Nobody will sell the Space Centre any fuel, so the Program has to obtain it itself using the Kethane mining mod. All rockets and planes are rolled out empty and manually fuelled up on the pad. (Exceptions are sometimes made for "simulations", mainly because I couldn't design a working spaceplane without a lot of flight testing.) It's set me doing so much I otherwise wouldn't have done. Flying a solar plane to the northern icecap where the Sun could barely keep the propeller turning, physically adding more boosters to a fully fuelled and wrongly designed rocket sitting out on the runway, fighting to get a kethane tanker plane airborne from the bumpy desert sands, and considering my one kethane miner currently in space an absolute invaluable asset that I really hope Dang It! doesn't break.

One other gotcha with satellite contracts: "Power" means a power source, ie solar panels or RTGs. A stack of batteries doesn't count. But the game starts giving you satellites when you unlock any power source in the tech tree, and that includes the launch clamps!

I looked at 64k and I think Jumbo32, but I just didn't like the way the terrain got flattened. I like having steep slopes on the planets. As for full RSS, I'd love to do that at some point but I'd rather have a better PC first, one that can handle higher part counts with less lag. I use a custom KIDS preset, reducing the engines to 0.85x their usual Isp. This brings them into the range of real hypergolic engines, mostly offsets the reduction in delta-V to orbit in FAR, and makes space travel require a bit more fuel than usual. Of particular note is it puts a single-stage Tylo lander on the edge of what's possible.

All wrong from MoonRover, and likewise from DMSP. Xannari certainly has an idea writing it all on one line, since ideas can and do flow across multiple lines in a poem.

Made orbit in the revised version of my Curtis Special, this time with 2 tons of cargo on board. Other than minor fashion tweaks (and maybe putting the ladder back on...) I'm calling this finished. Finally.

Incorrect still. Maybe I made this one a bit too tricky...

Definitely seems like a bug in whatever program you're using to monitor processes. Maybe try a different one.

You'll both have to reflect on the riddle a little longer I'm afraid.

When it takes my underpowered spaceplane something like 20 minutes to get to the altitude where I light the rockets...yeah, trial and error becomes a bit less appealing.

Wrong, wrong, wrong, etc etc Stores of knowledge no-one may see Abutting spacetimes; energy Is needed yet to make them real As the strings the present must feel. That present may elude our grasp When what's to come we spy in glass. Week foll'wing week, day after day, A year or more to maybe stay. I've not tried to make this easy But I do hope it is not cheesy. Hint 1: You can find one in the solar system. Hint 2: You can find one on Earth.

How can I work out the speed for best rate of climb for a plane? Since spending ages getting to altitude sacks. Wikipedia mentions it's the speed with maximum excess power; FAR shows a "Specific Excess Power" data point so do I just want that high?

From the screenshots and the problem description, that sounds like KSP started using more memory for whatever reason, and it caused the system to "thrash" - when it spends all its time swapping data between RAM and disk and hardly any time actually doing useful work. The best solution in my experience is to kill the offending program as fast as possible. On most Linux systems Ctrl+Alt+Esc activates a "kill cursor" then left-clicking on any window will close it immediately. (If you don't want to kill a program after all just right-click instead). If you need to force the whole system to restart, try REISUB As for causes, how much physical RAM do you have? It looks like 8GB, so KSP alone oughtn't to crash unless it really starts chewing up memory like crazy, but are you running anything else RAM-hungry?

Refuelling at the Mun or Minmus helps because your interplanetary transfer then requires less delta-V than going from Low Kerbin Orbit. For how much less we can use the Kerbin chart here: http://www.reddit.com/r/KerbalAcademy/comments/1qu5jv/deltav_charts/ If you consider the type of transfer where you have a low periapsis over Kerbin to exploit the Oberth effect then whatever our destination we have to go through the Kerbin-Mun Transfer and/or Kerbin-Minmus Transfer nodes as appropriate. The saving is then the difference in delta-V needed to reach that node. That's 760 m/s for refuelling at Minmus orbit and 590 m/s at Mun orbit. A good saving on a typical interplanetary departure of 1000-2000 m/s. Of course that delta-V has to be made up for and more to get to Mun or Minmus orbit to begin with, but by requiring less delta-V on the spacecraft at once you require less fuel storage which makes the ship lighter, and then you can potentially reduce the number of engines and keep the same TWR making it lighter still. The drawback to refuelling at the Mun or Minmus is you need to time your departure burn from their correctly to put your Kerbin periapsis in the right place for your interplanetary transfer burn. This can then constrain your departure burn date to be away from the optimum date in the transfer window. The effect is worse for a Minmus refuel than a Munar one, and either way it's generally bad for Moho which has short transfer windows but tolerable for other destinations. As for refuelling in Low Kerbin Orbit, well while it's a reasonable place to refuel I don't much see the point of a fuel station. Ships small enough that the station could top up many of them are probably small enough to launch fully fuelled, while ships large enough that you can't launch them fully fuelled are probably large enough to drink all the station's fuel in one go and therefore you're just better off sending up a simple refueller to fill just that ship than running a station with all its extra complexity.