Landwalker

Last night I finished setting up my own KCN (Kerbin Communications Network). It's much lower, though: I've got four satellites, all at roughly 282,374m of altitude. I like the look of the Keostationary triangular network much better. It just seems... cleaner. Also, on ComSat Kerb-L1, I forgot to attach any KER monitor parts, so I don't actually know some of the details (like orbital period) that I would like to know. The other three ComSats did have the readouts, but it's that first one that's a bit of a problem. Between that, and me having no idea how to set up satellites in a perfect 90º formation relative to one another and thus just eyeballing their distribution, the network isn't ideal. It's just low enough, and the satellites are just not-quite-square-enough, that occasionally the connection between two of them will get clipped by Kerbin's surface. Fortunately, this is just an aesthetic problem, since they can always talk "the other way around" and also communicate through the Kerbin surface network. On the other hand, aesthetic problems are serious. Pay no attention to the two target kolniya orbits mucking up the picture. I have contracts for those but wanted a ComNet before attempting them. As you can see, the comm satellites are barely high enough in orbit to clear Kerbin's surface most of the time... Once I get a little more cash in the piggy bank, I'm thinking about replacing KCN-L (Kerbin Communications Network - Low) with a KCN-H using three keostationary-or-thereabouts satellites, but I'm honestly not sure how to ensure I achieve that right now given that I can't even figure out how to get my KCN-L satellites to be in a perfect square.

Started out yesterday doing a lot of science and contract grinding. In addition to a lot of field research missions in and near KSC using the Science Kart, I also took out my first atmospheric flight craft, the Volt I, which handled like a drunken water buffalo, but which was still able to get around (a little bit) and land safely back at KSC: After a lot of "busy work" on contracts and a lot of maddening work on my end trying to identify (and, eventually, succeeding) a mod conflict that was causing all solar panels to start out extended and never be able to retract, the space program was finally ready to launch some "real" satellites, starting with ScanSat Kerb-1, my first SCANSat scanning satellite ever. I was able to slide this boy into a nice polar orbit and knock out the low-res altimetry scan without too much fuss. Sharp-eyes viewers will notice a pecularity about ScanSat Kerb-1—there are two in-line parachutes, one on each end of the craft. That's because I done goofed. The chute closest to the engine was actually supposed to be on the stage below this for StateRecovery purposes, but I stuck it in the wrong place. So to the satellite itself got two parachutes, and the lifter stage got... zero. Rip lifter stage. I finished off the day getting started on my Kerbin Pretty-Equatorial Relatively-Low-Orbit Communications Network: ComSat Kerb-L1, pictured here, as well as all of the ComSat Kerb-L series, are basically just knock-offs of the ScanSat Kerb-1 that replace the scanner with a larger solar array and the two smaller solar arrays with comm dishes. One dish points at the Mun, one at Minmus, and the Communotron-16 handles conversations with the surface and with most other things in closer-than-about-a-megameter-and-a-half orbit around Kerbin. So far, three of the four planned satellites in this network are launched and in position. ComSat Kerb-L4 is under constructions as we speak, and once the network is finished we'll be able to more reliably embark on a number of other probe-related missions, including (hopefully) finally going to / near / generally at the Mun.

It's been a bit of downtime, as I got sucked into the early access for Airport CEO, but I've good news: The problem has been solved! For anyone ultimately encountering the same problem, here's the solution: It seems that, as of this writing, there is a conflict between changes made as part of Ven's Stock Revamp (version 1.9.6) and Kopernicus (version 1.3.0-8) when running on KSP 1.3.0. I was able to get the solar arrays working again by removing \GameData\Kopernicus\Config\SolarPanels.cfg. I did a quick test and have not noticed any problems in my game associated with removing this config file—the solar panels still soak up sunlight, face Kerbol, etc. There may be some lingering, not-instantly-obvious repurcussions to this, and if I notice any I'll follow up here, but until then, I can finally start building long-term satellites capable of enjoying Kerbol's glowy sustenance.

For folks more experienced than me, which build do you find the most stable in a 1.3.0 installation? Should I go straight for the 1.3.0 dev build, or use the 1.2.2 build (or something even earlier)?

Reckon that'd be it, then. Time to roll back to 1.3.0. Thanks.

This is no longer appearing on CKAN (nor is EVT). Any word?

Ah, of course. https://www.dropbox.com/s/uv513cmxpa47awo/output_log.txt?dl=0 I'm afraid I might have mucked up the log by attempting some crude troubleshooting of my own over the course of a few game launches, but that's what I've got to work with.

I realize this is a very vague question, but, uh... All of my solar arrays start out extended when I attach them to a craft, and they're all unable to ever be retracted, both in the VAB and if I stick 'em out on the launchpad as a test. I honestly don't have any idea what specifically could be causing this. I use a lot of mods, but I'm not exactly sure which one might be behind this, and going through using process of elimination would be... well... Let's just say that if I don't have to use process of elimination, I'd prefer not to use process of elimination. I'm hoping that someone out in the gallery might have run into this before and knows off-hand either what is causing this to happen, or where the appropriate places to look might be. Any help would be much appreciated. Edit: I'm realizing belatedly that this somehow ended up in the "Unmodded" tech support forum instead of the "Modded" tech support forum. If anyone with the power to do so could move this over the "Modded" forum, that would be great. Sorry for the mix-up.

I restarted my career due to a gross misunderstanding of the USI Life Support mod on my part putting me in an unsustainable situation. Just for kicks, I replaced USI-LS with TAC-LS, and started a new career. After spending the whole day on the new career and getting back up to the "orbital probe" point of the career, I decided to remove a few more mods and add a couple more (one of which is actually @Angel-125's Pathfinder mod). However, when I went into my new career, I couldn't find the new parts anywhere. I concluded that I must need to restart my career for them to "take," so I reluctantly did so... and they still weren't showing up. Then I realized I had downloaded the mods but had not installed them. One actual installation later, and I'm finally back in operation... albeit, also back at Day 1. Well, at least I'm getting efficient and getting through the first couple of tiers on the tech tree...

Ah, thanks again. I'll give Pathfinder a look. I like the... opportunity for colonization, but unnecessary complexity is not something I really need right now (he said, with 120 folders inside his GameData).

Ah, thanks for the clarification. I'm just trying to get a cohesive and cooperative set of mods together for my first career game (and first any KSP game) in two years, so wading through what mods work well with which is a bit of a challenge when I've been out of the loop for so long. Are you still using/supporting USI Kolonization (MKS/OKS)?

Thanks @ExplorerKlatt, that explanation was helpful (once I knew where to look :P). One more question, though: Is there a way to increase default Hab/Home time at lower tech levels? Or does it really just boil down to "Use bigger command pods but with the same number of kerbals"?

Yemo (and others), if you don't mind me asking, do you prefer / recommend USI Life Support or TAC Life Support with the SETI MetaModPack? Any particular reason either way?

Ah, good to know. I wasn't sure if one of the SETI configs changed the base "Hab multiplier" from 1x to 0.25x, but it sounds like that's not the culprit. Thanks for the clarification.

Apologies if this is addressed elsewhere, but I didn't see it in the (admitted-to-be-outdated) OP, and figured folks here would know pretty quickly. I'm doing a 72-hour manned orbit contract, and Valentina has helpfully converted to a tourist instead of a pilot due to exhausting her "Hab" and "Home" reserves. I see above that veterans are no longer immune to various effects, but I'm not clear how to actually improve the "Hab" and "Home" numbers in the first place to prevent them from running out all the time. I've played around a bit in the VAB and the only way to improve "Habitation" seems to be slapping more crew modules on the craft (at a rate of 7d 3h per one crew slot), but surely there are other options so that a lone kerbal can spend more time in space? I also see nothing at all regarding the "Home" reserve number. So, ridicule me for my ignorance if you must—as long as I can get pointed in the right direction for a sort of "instruction manual" on all of this, I'll be happy. Disregard me, I finally found an explanation of the Hab/Home system. I'm not sure why my system defaulted to an 0.25x multiplier for Hab/Home, but that's what resulted in the 7.5-day "starting time" for the Mk1 Command Pod. Was that change something that was made as part of this mod, or does that sound like a config from somewhere else (SETI, I'm looking at you...)?

Jebediah completed the first crewed orbit of Kerbin, as well as the first spacewalk. Racked up quite a bit of science (and funds) in the process! Meanwhile, Bill took the Sciencemobile out for a spin to try to do some surface temperature and seismic scan contracts whose locations were all within about 8-9km of KSC. He managed to get half of them done, and then totalled the vehicle by plowing into the slope holding up the runway at about 25mph. Bill emerged unharmed, but the Sciencemobile has to be rebuilt in order to finish the seismic scan contract.

I only voted on Question 3, but I'm not sure it "took" since I didn't vote on Q1 or Q2. Basically, I don't even use the Stock Tech Tree (so the first two questions don't apply to me), because the sequencing is nonsensical and the reversal of manned/unmanned and lateness of atmospheric aviation are both quite off-putting.

Ah-hah. Perfect (and sneaky). Thank you for the help.

A quick question for the gallery of peanuts: I'm trying to do Contract 03.1: Orbit & Recovery. The parameters: Vessel Type: Probe Orbit, then land/splashdown on Kerbin Okay, great. Except the game isn't recognizing my vessel, which consists of zero kerbals and is cored by a SETI ProbeSTACK 1, as a probe. Which begs the question: If this isn't a probe, what is a probe?

Just puttering along in my career game last night after a long hiatus from the game. Had a contract for some low-altitude atmospheric scans about 70-80km southeast of KSC, so I took my ungainly mule of a monoplane out for a flight. The thing can only muster around 50m/s, so it was a long flight out and a long flight back, but the scans were completed, Jebediah was safely returned to the runway at KSC (as was the plane itself), and monies were received. Trying to scrape together enough scratch to upgrade my R&D facility and unlock surface samples.

Yeah, one of the things I concluded (but have not yet tested) from last night's experiments was that if I'm multi-staging to LKO, as I was originally trying to, I need to have a much smaller and later-activated upper stage that's primarily for the circularization and de-orbit burns, and a lifting stage capable of shoving that orbital stage at least close to the desired apoapsis (and therefore needing to burn longer than it was in my original design). A scheme for testing tonight, perhaps...

Well, after spending the whole evening doing exhaustive testing, I was able to come to a few conclusions: The leading cause for my single-stage craft cartwheeling was not a CoM issue, it was a drag issue. Namely, I didn't have any, and the rocket was big enough so that if it got even slightly off-center from prograde it could lose control entirely as the air "grabbed" the front of the rocket and threw it backwards. Extensive testing identified the Science Bay parts from DMagic's Orbital Science mod as the culprits. All designs without these parts did not suffer from cartwheeling unless I really janked up the piloting. Even without those parts, the craft was unstable in a turn (probably a secondary CoM issue). So my solutions: Per the suggestion of @Aegolius13, rather than adding stabilizing fins / winglets to the rocket, I added Elevon 0's. This immediately solved my control problems on the "no-science" craft design and allowed me to basically waltz into an orbit for a hair over 3,300m/s. Even with the elevons, the "yes-science" craft suffered from very fussy controls. It handled better, but slight errors could doom it. As a result, I encased the "probe stage" in fairings in an attempt to hide it from the janky aerodynamics. This worked marveously. There were probably more efficiencies to be had, but that particular orbit weighed in at exactly 3,350m/s dV. Relative to Streetwind's launch, that was about 97% efficiency, which is well within my "acceptable margin" range.

Okay... So how do I make that not be a thing? It also doesn't explain why this rocket also has a tendency to reach a certain point and then cartwheel uncontrollably: My assumption when I had trouble with this particular design was similar to the issue you point out: As it burns fuel, the CoM moves further back until eventually it catapults the back of the rocket forwards as soon as it gets the chance (due to minute deviations from prograde). But I can only find ways to move the CoM so far forwards on the rocket.

After some practice, trial, error, and blatant imitation, I've been able to mostly-replicated Streetwind's launch profile. Not as efficiently—I seem to be between 3,400 and 3,500m/s of dV burn, which isn't exactly 3,261m/s, but it also isn't 4,200m/s, so there's that. The next challenge, of course, is taking my launch profile knowledge and building a rocket capable of actually, you know... following it without flipping out (figuratively and literally).

Man, I've got a lot of comments to catch up on. Here we go. This was great. Thanks a ton for doing this! I noticed some big differences between your profile and mine—for example, by the time you reach 10km, you're going twice as fast as I am and are about half the angle to the horizon that I am. It seems like from there, you close in on the horizon angle more slowly than I do. I assume that's a function of going much faster much earlier "holding" your angle better, where as I tend to be going slower throughout the ascent. I've been driving my rockets more like a freight train. For practice, and because I learn best through imitation, I slapped together the same craft to see how I could do trying to recreate your launch profile. On my first attempt, I came in too steep (again), but still managed to end up getting things circularish (102x94km) with around 200m/s left. For some reason (I think related to RealChute altering the mass of the nose parachute), my start dV was a little lower than yours, but I still chewed through probably 3,500m/s of dV to get up there. Which is still a huge improvement over where I was at, so that's a good starting point for further practice. Yeah, that was my initial inclination when I was first running into problems. But as I mentioned before, the dV map I'm referring to is clear that its figures are vacuum dV, so my understanding is that if a craft on the launchpad has a hypothetical vacuum dV of (let's say) 3,800m/s, that should be more than enough to get into orbit and get back down. Still, I think a lot of my problem is boiling down to "I'm going too slow and spending too much time at low altitudes." So I end up wasting a lot of potential vacuum dV by dickering around with things like "gravity." The launch TWR in that readout is deceptive, because it's assuming the Reliant will be firing at full power—which is not how I was operating it. With the Circe, I was launching just on the SRBs, and only engaging the main LFO engine when the SRBs ran out. I just happen to put my main LFO in the same stage as the SRBs as a "just in case" option just in case I decide I need to engage it before they finish burning out. The actual launch TWR, with just the SRBs, was 2.16. Yeah, I'm thinking that the Pug is too weak for what it's being asked to do. The upper stage is too heavy for it to handle when gravity is still at issue. For giggles, I rebuilt Circe by replacing the Reliant with a Swivel and losing the SRBs: Unfortunately, this tended to get pretty unruly when I tried to turn it. I slapped some basic fins on the back and it handled a little better, but still got kind of wacky after a bit—I got the nose pointed too far away from prograde and it just started fish-tailing. I rebuilt my second craft from earlier in the thread, as requested, and here are its control balls: Whew, lots of stuff. With that out of the way, it's time to get back into practicing. Yes, the probe core and reaction wheel are both in the uppermost stage. Don't worry, I've made that mistake with the reaction wheel before...