Pulstar

Or temperature will be biome, altitude and day/night dependent.

I think Gilly, Bop, Pol, Dres, Eeloo and maybe even Vall should be hidden when you start the game. Along with any new celestial bodies that would be added. The Voyager probes discovered a lot of moons after all.

It is a mystery, but maxmaps has been mentioning that he has big things planned from time to time. There was a Kerbalcon poll a few months back on the form it should have. So there will probably be an announcement with the details once everything on Squad's side is ready.

I think he was referring to this year's Kerbalcon. And I don't think it will be budgets, see HarvesteR in near the very end at 59 minutes and beyond. So R&D polish and probably new science mechanics with some vague unrelated to science things that were being pushed for later.

I guess it will be posted today, probably there was something important that delayed it.

Same here, wouldn't mind it being toggled off for a hard, hardcore or ironman difficulty mode but nobody should be forced to play like that against their will, this game can be rather unforgiving even with quicksaves. Just don't know about terminate flight, I think it is a non-issue really since it has little effect on gameplay (doesn't give you any advantage, has the same penalties as blowing up everything). I use it mostly to get rid off improperly flagged debris cluttering the vessel list like decouplers ending up as probes rather than debris. Also I think it would be very kerbal to have a self-destruct device on everything, just in case Jeb needs some new years fireworks and an old abandoned space station happens to be in the sky above. Also it would explain why everything explodes.

The issue isn't just multi-threading, unity does that to a degree but not in the area that is the performance bottleneck for KSP. The problem is specifically with physics being ran in a single thread on the CPU, using a very old version of physx from an ancient era before it used Nvidia GPUs for physics acceleration (I am wondering if one of the 10 people that still own a Ageia Physx PPU card experiences better performance with it in KSP). Skyrim works the way it works because it uses a much newer physics engine, a fairly recent version of havok which makes uses of all the recent technological advancements in PC hardware. The old version of physx KSP uses does not, hence the performance difference. Overall the only way to get around KSP's physics bottleneck problem would be to license a new physics engine and integrate it into the game (or write a new physics engine from scratch but that's too much for a small developer team such as squad). That is doable and one developer using Unity did do this for their game, I don't remember that game's title or the developer team's but they switched to Bullet physics, it was mentioned on the forums a few times. The issue is whether or not Squad has the resources to do that at this stage of development (or ever in the future), it may be that they rather wait for Unity to make the smart choice and upgrade the physics engine it uses, if Unity would do that it would save Squad money and probably time. I would like to see a better and newer physics engine in KSP just like probably everyone would like to see it, but I figure that if such a choice has not been made by Squad so far there must be significant technical and business issues standing in the way. That's the gist of it in my understanding of the issue, after seeing "beating the dead horse" of the KSP performance topic for over the nearly year I spent on this forum.

Well the resources will be random with random locations, so while biomes will be "biased" towards having certain kinds of them (water ice being more likely to appear at Duna's poles in larger quantities, heavy metals at impact craters and similar), it does not entirely eliminate the need for scanning. Also scanning is good for exploration, since you want know what resources you can expect where at first and even then you want know which deposit is the best. Some deposits will overlap with deposits of other resources. Sure knowledge of where the game is most likely to spawn some resources will be helpful but it won't tell you exactly where the deposit is, apart from seas, oceans and polar ice caps most biomes are defined as being primarily made of resource X or Y.

IIRC in one of the dev streams from earlier this year HarvesteR said he doesn't think such scanning is a fun mechanic. But my memory could be off on the details. To be honest current Kethane scanning wouldn't be that time consuming and dull if there was a wide scanner scanning three or more hexes wide at a time as it passes over them. Overall I think that mining/converting and time-warping is not much of an issue. It is an issue for things like getting income or science or tech every X days since the player can just warp and get stuff with no effort while still on the launchpad. With mining and refining the effort is finding the deposit, landing there and using those resources for bigger things (like refueling or possibly construction). Mining and refining could be instantaneous, but having it work while warping like kethane mining/refining does now would have little negative effect on gameplay if any (other than still having to wait, but not much). Also push button>get resource would work oddly with power generation, you would need to stack batteries, recharge them, dump power into conversion/mining, recharge again. Click, click, click, click until you get the desired ammount. Doesn't really eliminate the warping issue as you still need it if the mining/refining uses power, not making it use power would be plain silly and inconsistent. Clicking once to turn on the drills or the refining module and warping is less mindless busywork and like I already said it isn't really a "press one button, get rich with no effort" button. Also I just remembered how lovely Nova's models for the resource parts looked. That water-pump drill and rock drill for instance. With the biome system implemented you could do some pretty cool stuff with random resource generation.

I explained why HarvesteR and squad probably decided to focus on that first, re-balancing the entirety of the economy (costs for over a hundred parts plus income values on all the things that would give you money) every time you add a new system that radically changes craft designs would take too much time. Better do those systems before the economy, then do the economy once and properly with only minor tweaks. Less time wasted on balancing everything, more time to work on new stuff that needs to be implemented. Yes, they should design them at the same time more or less in the aspects of how they will interact, but implementing everything at the same time would be both troublesome for balance as systems would keep changing and evolving all the time requiring co-dependent systems to be rebalanced. I think that also explains why they did science in 0.22 rather than budgets and missions, because balancing money income, costs and rewards when you don't know what crafts the player will be able to build at what stage, would be kind of like drawing a map of place you never been to or saw even just on pictures without really knowing what the terrain there looks like. Still those are just my words and not theirs and possibly they had other reasoning.

It is not going to be in 0.23, HarvesteR actually said that during an interview on bigsushi.fm from 5 days ago. Originally he planned to focus on budgets, money and the economy, but the idea now is to polish up science, fixing the obvious issues with it and fleshing out the related mechanics more so that the system is as complete as it possibly can be at this stage of development. So budgets will be in 0.24 probably. Why? Well he said that science polishing is not the only thing that will be in 0.23, he did say that a feature that kept getting pushed back too much will be the other focus of 0.23 development (not resources). Maxmaps or C7 also mentioned in the last squadcast that the next update will take a bit longer to develop than 0.22 IIRC. This is probably something that needs to be done now so that it doesn't mess up balancing the economy when costs and income get added. My guess is it will be re-entry heat and possibly an aerodynamics rework since those will change how we build crafts a lot, and such a change would require a part cost or income re-balancing if it was added after an economy. But that's just speculation on my part, there could be some other feature that got delayed a lot and is needed now that I may not know about. A dev blog entry will be posted sometime soon detailing what the focus of 0.23 will be so we'll find out soon enough, either via it or via the weekly. Either way it is important to consider that if a major new addition that changes how we build rockets happens, it will result in having to re-balance the economy. It would be best if loose end features that would require a complete economy overhaul get added first.

I remember finding that by accident when looking for some new jazz on youtube. I do not remember who the composer is but he is listed in the game credits.

Somebody made a Mun hovercraft, it was insane but it worked. Not sure if it survived April though. Also it is possible to build solar powered ion engine planes for Duna (which did *not* use the infiniglide bug). I remember I posted a few images of mine but I think they got eaten by the forum time traveling incident in April. I also managed to do a one kerbal solar plane but I'm not sure if the infiniglide bug made it fly or not, it only worked on Kerbin though and possibly Eve. 500 Newtons of thrust is not as little as you think, the issue is just getting enough solar panels and the tile ones are the best due to power/mass ratio and g-force tolerance but they need structural parts to put them onto. The advantage of Ion Engine rovers is that they can go much faster than regular rovers (40 m/s on Duna easily), however they can not climb hills. You could use RCS as an afterburner to help them with those but it was a limited resource. Also if you think driving rovers on the Mun now is hard try driving one which uses landing gear which has no suspension. I think that now that is pretty much a death wish considering the addition of procedural craters.

Like I said that is still being worked on, I don't remember if HarveR, C7 or maxmaps said it during one of the recent squadcast streams or in the recent interview on bigsushi.fm (that one has some nice hints at the end on what 0.23 is going to be about, but I digress), but basically it was confirmed that it's not ready yet for release unfortunately but still being worked on.

It is true that reactors need some use first as there aren't many power-hungry things in the game. The most obvious would be for resource mining and processing, which is probably why blutonium was featured on the chart and I don't think it was just to fill up the LV-N, solar panels would definitely be too little to power refineries. I also think that they could make ion engines useful for bigger vessels assuming their power output to mass ratio would be enough to power large ion thrusters or big clusters of them. Then there is the possibility that we could get a VASIMR equivalent as a lower ISP but higher thrust engine requiring more power.

If tweakables ever get added maybe it would be possible to have surface panels as a an option on fuel tanks? Treat them as one part with the tank, kill two birds with one stone so to speak. The downside could be that they're a bit heavier and more fragile as far as impact damage goes than regular fuel tanks. Also would be a good option for wings IMO.

Multicore support can only happen if unity developers do it, otherwise it would have been implemented a long time ago. The issue is mostly with the PhysX implementation that unity uses, it is simply very old and squad can't do much about it on their end. However a major code overhaul is coming soon, as the optimization was supposed to be featured in 0.22 but got delayed since it still needs to work out some issues. It is supposed to be a significant performance boost.

It was/is a test planet for the PQS system and some other new code that needs testing on a "live" subject like new planetary features, procedural craters etc. I wouldn't expect it to appear in the game as that's not its purpose, although its concept may get reused. Either way it is unrelated to Gas Planet 2 which will probably appear sooner or later in the game.

I'll add that the OP may have missed the purpose of biomes on Kerbin a bit. Well apart from the fact that it makes no sense not to have those there when other places will. It's a measure to both teach the player that there are biomes and how they work in practice (also it helped testing the system obviously), but also it prevents new players from running into a science dead end. There's still incentive to do stuff *in* space, for one it actually gives you far more science even for basic low orbit. If you fail the first couple of times in getting into orbit you still end up somewhere with some science and get to unlock more parts. A new player is likely to miss stuff, especially that there are no tutorials or help messages like "you can click on some parts like the command pod to do an experiment, recover it to kerbin or transmit it back to unlock new parts" regarding science in the game. Even with those he could miss it, but overall by the time he does get into orbit he should probably have it figured out.

Going fast sideways is more important than simply going up. Docking is hard and the concept borderline insane, which makes the fact that you can do it both in real life and in KSP even more amazing.

In the future is the only thing we know about when, as with all things squad plans. It could get added in the next update but the focus is on career mode for now so IMO that is unlikely. Then again who knows, there will be an announcement soon as to what will be the focus of 0.23 as soon as the developers, maybe there will be a new planet thrown into the mix. One thing that has been mentioned is that a planet discovery mechanic would be implemented first before more new planets get added. They will come eventually though. EDIT: The technical problem that prevented adding more new planets has been solved in one of the last few updates. Basically before the game stored all the planet terrain data (or was it textures?) in memory when it didn't need it, like say Eve's terrain when you were at Jool. Now it loads it only when it needs it, also saving on memory use. At least that was my understanding.

I think it would be difficult to have the game properly determine terrain inclination. For one terrain is 3D, then there is the issue that you have multiple small slopes forming bigger slopes and which one exactly would such a feature pick to show it's direction? The biggest one? The most steep one? It would be better for the player if he could see a 3D radar image of the terrain chunk right below him in a separate window, preferably with the option to display terrain shape using just wireframes or a heightmap. But I am not sure if it is possible to "cut out" a chunk out of the whole terrain like that. Although you could have a camera that display a shot of terrain "below" the craft (relative to your point of control) with wireframes shown, or indeed with a relative height-map. Wireframes would give you shape, the heighmapt would tell you where the terrain is most flat (less tone change=more flat). Not sure how much work would that be or if it is indeed possible for technical reasons.

I also agree with Kerbal Alarm Clock, I would also say protractor or similar but KAC mostly has the biggest reason why you need protractor covered, since it gives you time to transfer windows. KAS for fuel lines, power lines and grappling hooks. Those last would be really good to land on something like Gilly and stay put. Makes sense mostly once resources get added with in-situ fuel production which Kethane now allows. At least basic vessel stats in the VAB like from Kerbal Engineer and similar would be nice. Not necessarily delta-v per stage but mass and thrust are a must, seeing how long you can burn the engines at maximum thrust before you drain the tank would be welcome as well. Procedural wings and fairings. Last but not least I would really love seeing stock counterparts of electric propellers or rotors from the firespitter mod along with balloons. Airship probes on Eve or Jool would be fun.

Well we would have to learn to make thin rockets for one and landers that fit inside payload fairings, without hinges I would need to rethink some of my wide and safe lander designs. Also technically we would still get off the ground but it's just that there would be bigger penalties to asparagus staging overkill. But it wouldn't kill it off completely, just make the lifter designs more sane and definitely less wide. Re-entry heat would be a bigger difficulty increase, aerocapture the way it works now would require either heavy heatshields increasing mass and decreasing delta-v. Or it would possibly still be quite lethal so you would have to aerobrake at say laythe at a higher altitude, and burn retrograde after you exit the atmosphere to get into orbit around it since otherwise you risk burning up. It would actually be cool if heatshields were ablative and had a finite amount of heat they can take, meaning you would have to consider not just for the temperature of re-entry but also the duration of it.

I think it is fine, you just need to practice landing inside a crater where it is fairly flat. Those things are big, there's plenty of room. Neil Armstrong didn't just land the LM at then exact spot where his descent trajectory took him to, he had to hover for a bit to find a suitable landing site. Although for him rocks were the issue and not craters.