eekee

It is ROCSeed. I copied its value from a newer save, and found BG surface features. Testing was the hard part; they don't spawn in instantly, so I twice thought it hadn't worked. For my first test, I cheated a rover to Vall as its features are some of the easiest to see. I drove around a bit and saw nothing to the point that I was starting to think it hadn't worked. Then, I turned around and saw 5 or 6 cryovolcanoes erupting simultaneously. (I think they do that when they're newly spawned.) I still had a question: were they forming because I'd changed ROCSeed or because I hadn't been to Vall before, in this save? So, I had to explore Kerbin too. I drove a rover for quite a while without seeing anything, but I didn't think to turn around. Seeing no baobabs on the grasslands, I cheated the rover to the middle of a mountain range to look for crystals and immediately found a baobab. This left me wondering if they were only spawning in regions I hadn't seen before, so I looked at an area I've seen more of than any other, the grasslands between KSC and the mountains, and found a baobab there. I think it's safe to say all the bodies have BG surface features now, and the cause can only be changing ROCSeed. Incidentally, I thought I saw 2 ROCSeed lines in one of my saves. Both had the same value. When changing it, perhaps search the file in case there is a second instance.

I started this save-game with intent to build infrastructure; mining and colonizing the whole system. The distribution of ore turned out to be exceptionally suitable for this plan; it's very unlikely that I'll ever have another save with such a good distribution of ore on Minmus or an ore-rich Mun crater in the right position for direct-ascent launches to LKO. This save has both. However, being one of my early games, I started it before I installed Breaking Ground. I miss the surface features. So, can I force BG to add surface features to this existing save? There are as yet few bases, no colonies, and most mining ships are in flight. I intend to make a backup before adding the features, and if any bases or ships are damaged by features appearing where they are, I can load the backup, move them, then re-add the features. Or, can I generate a new save with the same random seed? I could then move my ships bases and everything to the new game. As above, if something is damaged, I can go back to the old game, move it, and re-transfer. I'm trying some things, but if anyone really knows, I'd love to hear about it. Edit: I think I've found it. Copying Seed and ROCSeed from the save in question to a new save made the new save's ore distribution the same as the old and removed surface features. I think this is because ROCSeed is -1 in the old save but a positive number in new saves. In the morning, I'll try setting the old save's ROCSeed to some positive value and see what happens.

It's certainly possible to model translation and rotation correctly, and I'm sure this world contains tens of millions of people with the mathematical skills to explain to the devs how to do it. Mathematics makes things easier when you understand what you need to. The fact that KSP 1 has gone so many years without fixing its horrible occlusion bugs is a sign of persistently poor choices, and I'm dismayed to see KSP 2 chasing down the same rabbit hole of poor choices. The answer here is math. Math would fix KSP1 model, math is necessary for correct implementation of a depth & normal-only render, and math is necessary for any other solution. Learning the math necessary for these jobs may be hard, but once learned it makes the jobs so much easier. The only sword that can slay the Kraken is Mathematics! (Read that in ShadowZone's voice. ) Perhaps not true for some tentacles of the Kraken, but I thought we needed a little humor.

This concerns loading time in KSP1, especially the time taken to launch from the VAB or SPH. For quite some time, I've been complaining that the more active vessels you have in a KSP1 save, the slower loading gets. This may be true in a small way, but not nearly to the extent I thought. Rather, a different issue is primarily to blame: single bugged vessels. Let me tell you what I've experienced. I began playing KSP with a single sandbox save called Silica Cubicle. (Please excuse the pun.) I kept my early experiments if they had enough delta-V to go places. I started building refueling infrastructure with mining ships, tankers, and a couple of space stations. I launched relays and exploration vessels. I developed spaceplanes. By the time I had 30 vessels in flight, launching from the SPH got so slow as to hinder development. I started a new sandbox game, Test Bin, just for development. Fast-forward a couple of years. I installed KSP on a different computer and copied my old save games. Eventually, I found launching in Test Bin to be very slow. This was strange because Test Bin only had 3 active flights. I deleted just 1 ship and found launching from the VAB to be as fast as a new game! Then I noticed launching from the VAB was fast in Silica Cubicle too, and remembered I'd deleted some early experimental probes. The ship deleted from Test Bin was nothing special. It only had 36 parts. The other two vessels were larger; a big relay drone with 87 parts and a spaceplane with 53 parts. The probes deleted from Silica Cubicle had only 25 parts. The problem vessels have something in common: octagonal struts (both kinds), connected node to node. The Test Bin ship had 2 runs of 6 octagonal struts. The 3 Silica Cubicle probes each had a run of 3 cubic octagonal struts with strut connectors bracing them. I hypothesize that if we avoid using either kind of octagonal strut in KSP1, our games will load much faster. The uniqueness of octagonal struts Octagonal struts (both kinds) are unique in being structural pieces with no autostrut option, indicating they behave unusually in the physics engine. (If there are other parts like this, I'd appreciate corrections.) I wonder if runs of them are treated as a single part. If so, loading them would requiring extra computation to determine if they're offset or rotated. Perhaps this code is slow. It's worth noting that octagonal struts are also problematic in KSP2 which aims for fast loading times. Optimizing code can introduce some very difficult bugs.

I'm concerned because I heard that the developers of KSP2 are relying on the community's opinion of KSP1's aerodynamic model; saying it's predictable and intuitive. I was in open source software for a long time, and so I've seen many examples of people entirely forgetting the learning curve they once had to go through. They declare things to be "simple" and "intuitive" when they're really nothing of the kind, and I'm concerned that this is more of the same. Thinking lightly of KSP1's aerodynamics is nothing like the dizzying, surreal heights once reached by Git fanboys, but it still won't be good for newcomers to KSP2 who have never played KSP1. Let's compare KSP1 aerodynamics with real life. Real Life If you're outside the vehicle, looking all around it, what you can see affects lift and drag. What you can't see doesn't. You need some education to understand how the profile of a wing affects its lift, and more to understand supersonic and hypersonic airflows, but these are all things which can be seen with the help of wind tunnels. KSP1 Parts with a designated wing area affect lift and drag even if they're hidden, unless the very center of the part (not shown in the editor!) is inside a cargo bay, unless again the part is a helicopter blade in which case it'll work inside a cargo bay too. Worse, parts which look hidden or at least shielded from airflow still create drag and are affected by reentry heating. Fitting parts side-by-side does not turn them into a lifting surface when it looks like they would be. Fitting hidden wing-parts to compensate adds mass without reason. Parts without a designated wing area have some effect on lift and drag, but it's inconsistent in unpleasantly surprising ways. The following examples may fairly be called bugs, but they are all the result of statically giving each part specific aerodynamic stats instead of evaluating the shape of the entire vehicle. A 1.25m fairing made into a long cylinder with a point on the end will, when at an angle to the airflow, have several times more drag than an identically-sized cylinder of fuel tanks with a nose cone on the end. (There's some evaluation here, but only on the fairing part. It wasn't matched to the other parts.) Mk2 parts have both wing and body drag, resulting in vastly greater drag than expected at some angles of attack. I wouldn't be surprised if this one detail is responsible for the majority of failed SSTO designs. It's infuriating to find, after very carefully fixing your craft's aerodynamics in the SPH, that it behaves completely differently in flight. Mk3 parts = ??? I've seen very high drag from Mk3 cargo bays, but is the drag the same as a same-size Mk3 fuel tank, is it similar to 3.75m parts, and most importantly: why would a newbie ever think to check if cargo bays or all Mk3 parts are different? And it's not very easy to build a spaceplane big enough to compare big Mk3 and 3.75m parts. In place of wind tunnels, we have the aerodynamic overlay in flight. It's useful, but it's easy for a long drag triangle to be hidden inside a long fuselage. And why do the aerodynamic and cargo shielding systems work together so hard to prevent you making custom cargo bays? I just watched a video with a nose cone attached to a hinge and a fairing closed on the nose cone. Perfectly reasonable, normal, intuitive engineering, especially when you consider the docking ports used as a catch to hold it closed. When it got out into space, the hinge was not allowed to open! What even is this? What line of logic tries to fight such basic simple practical engineering? It's as intuitive as a door in a house, but something about the design of KSP1's aerodynamics system made whole teams of developers think it was right to prevent it. And the alternative of using those tubular parts from Making History leaves everything inside the tube exposed to drag and heat because the node at the nose cone end isn't "properly covered". That's less intuitive than half of MS-DOS! The only "intuitive" thing I can think of about KSP1's aerodynamics is that you can add up the wing area of all the parts which have such, but I am so tired of adding up all the different wing parts to even get an idea of my build's lift/mass. KSP is a computer game, it runs on a computer, why can it not compute the wing area and tell me what it is? And, here's the really interesting bit: if it's computing the wing area, why not instead make the more complex but realistic calculation of overall lift based on vehicle shape, as the FAR mod does?

Thanks Maxsimal! And the rest of the devs too! It's been great. I started playing in 1.8. I'm glad I didn't start playing before the advanced burn time indicator was present, I don't think I could have coped without it. There was something in 1.8 I was glad of too. Can't remember what it was now, but I think some of the "moar boosters" launched my first successful orbiting craft. They definitely launched the insane rockets by which I discovered what a big difference it makes to launch with or against Kerbin's orbital direction when leaving its SOI. My first ion probe was sent on an interstellar trajectory without even using any of its own propellant! As for 1.12, I've wanted steering adjust ever since I first played. I'm sure it'll be a big help. It's also great to have a rover stability guide to refer people to, except for one point which is rather backwards, if you'll excuse me saying so. Under braking, there's this: Uh... I guess this could happen with EXTREME REACTION WHEEL! but my experience is reaction wheels help tremendously when accelerating or decelerating. When accelerating, the natural tendency of a wheeled vehicle is to throw its weight onto its rear wheels, pitching up.1 Reaction wheels or RCS respond to the same key with pitch down torque. Thus, under acceleration, reaction wheels fight the rover's tendency to wheelie and flip onto its back. They also increase traction by keeping the front wheels pressed to the ground. When engine braking (for want of a more appropriate term), the ground wheels are trying to pitch forward while the reaction wheels are trying to pitch back. Just the same as when accelerating, the chance of flipping is reduced and traction is improved. Since driving on Minmus, I never use the actual brakes of a rover except for parking or to supplement engine braking. 1. Cars mitigate this with careful design of suspension geometry; not easily done in KSP and not as effective as reaction wheels anyway. I'm also experimenting with applying roll with yaw for stability in steering; A+Q and D+E keys. It "should help", but I haven't properly tested it because I'm not focusing on rovers right now. I'm too busy with spaceplanes. Negative camber is another thing I want to test. 15o (one snap) of negative camber greatly improved steering stability of my "speed rovers", (my 2nd project in KSP, ) but I'm not sure why.

The stock fairings are fine if you're fine with sharp angles or just don't care what they look like. If you want smooth curves in profile, you gotta work!

I'd like a way to make a whole craft (with fixed panels) to track the sun.

I'm pretty sure I once worked out that it's lighter than any other engine+tank combination of similar power, but I don't have the figures any more. I don't know if I'd use a single boar. It's great as a lightweight engine-tank combo, but I think it would be a bit naff if it lost the weight advantage. In fact, I thought the Twin-Boar was naff until I saw its weight advantage.

Hahaha! Very funny video, and yes, EVA construction does have some terrible issues triggered by just picking a part up ready to place. Twice, I've had it suddenly decide not to let me place a docking port anywhere, not even to drop it. I couldn't even pause the game. I was almost surprised when it responded to F9. The first time, I didn't even have a quicksave & could only force-quit the game. However, I have successfully placed a number of struts and docking ports without these issues in EVA construction, so I still believe in it. ... I just make very sure to quicksave first.

It's definitely better than nothing, but absolutely has room for improvement. I launched a small fleet of rockets in 1.11 and found just how horrible the tracking station UI is when you need to find the next maneuver of any ship. I couldn't have executed all the burns without quicksaves; had to quickload twice. 1.12 came soon after that and alarms helped tremendously for the next mass flight, but adding and especially updating the alarms was still a bit unpleasant. Maybe I should have 'just' made a monster ship which separated once it got to Jool, but as I get more ships in flight, (and with my plans, I will,) I'm going to need to know the next burn for any craft without looking through a list which puts all the burns in small text and hides them half the time.

Don't forget you can fit conventional struts in orbit since 1.11. I guess it doesn't really help with docked craft unless you want to get an engineer out on EVA with every dock and undock operation. Now I think about it, adding struts might be realistic for craft docked to space stations which need to turn. Space stations aren't generally expected to turn very often AFAIK. I didn't know autostrut existed until recently, so my docking procedure included turning SAS off the moment the docking succeeded and I didn't build stations. I started to build stations in 1.11 when EVA construction made it possible to add external struts. The procedure was: dock, SAS off, add struts, SAS on. It worked fine, except for one station where one of the ships had loads of parts as cargo but carried externally, including a lot of struts. That one was kraken bait. All the same, I think I'd prefer autostrut to go through docking ports if it doesn't cause issues. EVA construction is a little bit tough.

I'm not going to comment on KSP 1's future, but I'd like to relate the story of the survival of Transport Tycoon Deluxe. It has something in common with KSP: it doesn't dumb things down very much. Newbies can easily get stuck and it's easy to find very hard challenges. I remember one time, a guy who'd played Railroad Tycoon avidly from version 1 to version 10 (how many years is that?) came on TT-Forums looking for help because his train network wasn't working. He'd got his trains into a mild form of deadlock - something natural to train networks. It was a thing every Transport Tycoon newbie quickly learned to deal with, but... well, Railroad Tycoon wasn't that real, Transport Tycoon was. In those days modding wasn't really accepted by game publishers, but nonetheless a modding patching community got going and "TTDPatch" got a large number of improvements and extensions. TTDPatch was very much alive 10 years after the release of Transport Tycoon Deluxe or 12 years after the original Transport Tycoon - many years after the publishers had stopped selling the game. In those days, games didn't really get updated. They were released, maybe had a few variants, and if they did well, maybe sequels. Transport Tycoon had 3 or 4 versions which were more art changes than program updates. Deluxe has some extra train signals over the original and some different terrain generators; that's about it for code changes. So I guess its last release was probably about 1996, but TTDpatch was still going strong in 2004. By 2004, another fan project was ready for prime time: OpenTTD. With all new code, OpenTTD is a clone of Transport Tycoon Deluxe, a faithful reproduction but not bound by the same licenses. Until about 2005 or so, you had to have the original graphics data to play it, but as the coders matured they got uncomfortable with that. They started a project to get open source graphics; compatible but looking a little different. Some of the many "NewGRF" artists were willing to contribute, so OpenTTD was soon able to include a complete set of open-source graphics. It's still going strong; you can today play Transport Tycoon Deluxe much like it was originally (but with much better pathfinding), or with almost all the extensions from TTDPatch and many more. In short, fans of a complicated, technical game had the technical skill to make sure it survived and to make it better than the original. It's still going strong today. I'm almost certain the same will happen to KSP 1. For reference of the sort of activity level I mean by "still going strong", here are links to OpenTTD's news page and TT-Forums.

Good to know! I had to check out this thread because one of my early-ish plane ideas was simply to go as asymetric as possible. I never tried it because I got distracted by another weird and wonderful idea, but my basic plan for asymmetry was a long wing on one side with a stack of 5 or 6 strakes on the other. I don't think I could build it with the unique-part limitation. I think the rule change could lead to a different aesthetic because I see planes here tend to look like scrapyard builds, but mine would probably come out looking like something from an alien civilisation. (I tend to build neatly even when I'm building wierd stuff.) Up to you if that's what you want or not. ... but now I'm wondering if I could build such an alien plane with unique parts. Ooh... I've learned a trick since I last thought about this; a top secret trick! Edit: Looks like I missed a few posts. I'll have to get busy building... if I can find the time between all my other planned builds and in-progress missions!

I missed that one, but now I'm super-curious! If... if they allow launching new craft, and if they can be taken to other bodies and incorporated into bases, I will be a very very very happy kerbal! I was thinking of a mod, if it exists or if my skills were up to making it: Honest Harry's Construction Company, in which you take parts to a location and build your base, then tell the mod to make it a site, optionally with launch facilities. If mobile launch pads are what I hope, then between them and the ground anchors we won't need a mod to do this. But would it work for launching planes... Yes, with a little ingenuity.

I'm not one for weapons as such, but this news makes me grin like Jeb driving too fast!

If it is the game and if it's applicable to every wheel, I'll be very sad. My ranger Carragorn already needed 20 wheels to get around in moderate gravity, and I already had most of the workarounds I needed for rover stability.

I have so many craft in my SPH, the game stalls for a moment, or sometimes almost a minute, when I click Open. I build a lot when my health isn't good enough for accurate piloting and the craft just build up. Got some junk, some craft development revisions (especially for the really weird designs), a few bug tests, and some surprisingly fun planes. (It's super-easy to build planes in KSP if you've got a very basic grounding in planes and aerodynamics plus just a little practice. I'm really happy about that. Oh hey, OP's title: More of an Atmosphery Guy; nice!) I haven't had time to look at the folders yet, but I'm super-happy KSP has finally got this basic feature (*cough cough chuckle*) and very much look forward to using it.

I know this agrees with the in-game description (and I know it's been nearly a week), but I have to disagree. I've used the Convert-o-tron 125 continuously, unmanned, without serious problems. However, it is extremely slow if unmanned, and producing liquid fuel and oxidizer together isn't workable. (I forget why.) When producing a single liquid at a time, it will trickle along at about 96% efficiency. (This is with ambient temperatures of Kerbin or Minmus.) As for speed when unmanned, it takes somewhere in the region of a whole Kerbin year to fill two Rockomax Jumbo-64 fuel tanks. Those are the largest 2.5m tanks. When controlled by a maximum-level engineer, it took about 2 weeks if I remember right. (I can't find my notes.) I can't remember if it can produce lf+ox together when manned. A note on cooling: Radiators don't have to be physically near the part to be cooled. They do have to be attached to the part itself or the part which it is attached to. In 1.8, I found ore tanks wouldn't pass heat, but this seems to have been fixed by 1.11. For my vehicle on Minmus, 2 small radiators attached directly to the converter are quite enough. The only time the radiators heat up is if I time-warp while 'flying' the vehicle. That must be a bug because they don't heat up at any other time. The bug is with the radiators themselves; the drill's radiators heat up too.

For wings, I want precise fitting with the shape of my craft. Procedurally building them out of parts wouldn't work. I want to place panels and trim them to fit. Otherwise, I agree with your post. Thinking a bit more, what I really want for fuselages is to place lengths of generic fuselage and divide it into sections with different purposes: Passengers, fuel/ox, fuel only, cargo bay. However, this really would conflict with the found-parts theme described by Single stage to ocean above.

Here's a full description of the dead end I've gotten into: I'm packing self-refuelling gear into Mk2 cargo bays. It's a big drill and a small converter; a combination I've found to be useful in a different vehicle (with maximally-levelled crew). In the bays of a spaceplane in flight the drill has to sit horizontally, so it's mounted on a big hinge. I'm trying to use KAL-1000 controllers to coordinate deployment and pack-away: bays opening and closing, hinge angle changing, and drill extending and retracting. Having got tired of doing simpler sequences (no hinge) manually, this is an obvious job for sequencers. Because I can't control drill deployment with analog tracks, I have two controllers: one to deploy, one to pack away. When I test this, each controller works fine the first time it's used. However, after first use, play position of each is stuck at the end position and it does not work. My question is: How do I make a controller play from the beginning on every keypress? I tried to do it with another pair of controllers controlling the first pair and each other. It might work, but I'm very confused now.

I grew up with LEGO. I absolutely think KSP should have procedural wings, fuel tanks and cargo bays. I've been balancing lifting-body spaceplanes by rearranging fuel tanks & cargo bays. It was a lot of work and repeatedly veered into the 'not fun' category. Wings -- to bridge gaps in the lifting-body structure or make the overall shape into a delta - would have been both much less work and neater if they were procedural. Granted, if wings were procedural, I might never have discovered that wings buried in bodies still count for lift. What an interesting feature that is... Mweheheheheeeee I must disagree. Real-life making-do has always had a procedural element. Consider saws, knives, hammers, and just plain bending and snapping stuff.