tfabris

Aha, gotcha. Now I see what you're saying, and I agree, thanks! If transmitting everything allows me to use a rover to cover multiple biomes per mission with only one set of experiments (there are some areas where you can nail three or four biomes within a few klicks of each other), I would argue that transmit-only can theoretically yield quite a few more points per mission, right? Or am I misunderstanding how that works? Agreed completely. I aimed straight for solar panels and batteries in the tech tree, doing Recover missions up until then. I see your point there. Additionally, the keep-only strategy alleviates the need for a rover at all, and there's a lot of complexity involved in the rover, batteries, solar panels, antenna, etc, required for the transmit-only strategy. So yeah, I totally see your point. I think perhaps, I didn't realize at first that the Mun and Kerbin biomes yielded fewer science points than the other planets. Somehow I had it in my head that scouring the nearby biomes would yield more points simply because there were more biomes to explore. Also, I was deliberately trying to climb the tech tree while staying in my local neighborhood and using the biomes as an excuse to explore Kerbin and the Mun in detail. I was also having fun refining my data collection technique and doing interesting updates and revisions to my lander and rover to make them incrementally better. I have a lot of fun in the design screen, fiddling with every little detail. I had my sights set on going to Duna later, after I'd really refined the rover and lander designs. But you're right, if it was just points that I was after, I should have tried for the more distant planets sooner.

Exactly, that's what I'm doing. You say that's a bad idea, but, assuming that you hit more than one biome with that experiment-laden rover, doesn't that mean that you can get more science points per mission that way? That's what I thought I was doing... I'm not sure I understand that. Can you explain that in more detail? I thought that pressing TransmitTransmitTransmit over an over until it reads 0.0 points (which is what I'm doing) was the same as returning the sample once. Nice! Doesn't save me any mouse clicks though, does it? I mean, before I do that, I'll still have to press KeepKeepKeepKeepKeep on all the dialog boxes anyway, right? The maps on the KSP wiki are at a low resolution, and aren't lined up with a visible-color map reference. So I can't clearly see (from my rover's position on the ground) exactly how far I have to drive to cross a boundary into another biome. I try to land as close to the boundary as I can, so that I don't have to drive very far, but I still can't get it close enough. Here's an example: I just did a Mun mission where I landed near the boundary between the East Farside Crater, and the east-west canyon that runs eastward from that crater's eastern edge. Going by the map in the KSP wiki, I thought I had absolutely nailed the landing, I thought I was in the area that would be defined as "crater" and would have to drive only slightly eastward to hit the canyon. Instead, I landed, and I was already in the canyon biome, and had to drive about four kliks westward to hit the Crater biome. And also, along the way, managed to find a tiny patch of Midlands that wasn't even on the map. So although "look at the map" gets me in the neighborhood, that neighborhood is still many kilometers wide and involves a lot of driving. The only way, on that trip, that I could tell that I'd crossed biomes, was to run an experiment. The terrain didn't look any different. Even when the wheels are intact, I can't get very far on them before they break again, so the legs thing isn't helping me. And yes, my lander is large and monstrous. But it's also glorious. After a mission, I can fly back to Kerbin and land vertically, on my landing legs, in front of the space center, 50's-sci-fi movie style. That makes it worth it. :-)

I'm wondering if there are any interesting ideas out there for the most efficient way to collect Science, in terms of the way you build your ships? Here are some things that I have done, I'm wondering if (a) there's anything I haven't thought of, and (, if anything I've done here is novel: - All science equipment, including a transmission antenna, are mounted on a rover, allowing me to land my lander at the intersection of a few different biomes, pop the rover off, and then run around and collect data on all of the nearby biomes. Solar panels and batteries galore, to allow for lots and lots of transmitting, since I just leave the rover on the planet when I'm done. I can collect all the science data from space on the way to my destination, while the rover is still attached to my lander. I have to make sure to get all the space science on the outbound leg, because the rover's not coming home with me and thus neither are all the experiments attached to it. - Rover design is longitudinal, with all the fragile experiment parts along the centerline, and the wheels extended out on long booms, so that even if the rover tumbles in a low-g environment, the experiment bays are not damaged. (Of course the rover is designed to run fine even when flipped upside down.) - Bonus: With a transmitter antenna on the rover, I can do EVA Reports and surface samples without having to leave my seat. So I can do all science experiments, an EVA report, and a surface sample, all at once, and transmit them all at once. - External command seat on my main command module/lander section (in addition to the command capsule that's already there), so that I can EVA, move to the external command seat, and be able to do EVA reports *and* Crew reports on my landing approaches or takeoffs without leaving the seat. I haven't actually checked to see if I'd survive re-entry if I hit atmo at reentry speed, so I move back to the command capsule in those situations. But for the Mun or for situations where you're flying around in low atmosphere, it's great. - Assigning an Action Group Key that contains every science experiment observation, plus a Crew Report. So I just press a single key and the results of all the science experiments pop up on the screen, and then I hit TransmitTransmitTransmitTransmitTransmit. Also add an extra key for just the Materials Bay because I have to transmit that one so many more times than the others. Eventually, as the reports start approaching zero value, I'm hitting TrasmitDiscardTransmitDiscardTransmitTransmit, transmitting only the valuable experiments, to save time and battery power. Things I haven't figured out how to do: - How to add Surface Sample and EVA report to an Action Group key. I still have to use the mouse to do those, even though I can do all the other bits of Science with one key. - How to use keyboard commands to transmit samples, or perhaps a way to automate "transmit all samples all at once, skip all the dialog boxes". - How to keep the transmitting antenna extended all the time. I can assign an action to extend it, but then when it's done transmitting some data, it retracts again anyway. I'm trying to avoid that moment when it's folding back up and I press the Transmit button on my experiment, and nothing happens because the antenna was folding up. - How to figure out when you'e driven your rover past the boundary into another biome, without actually running a science experiment. - How to just Make The Lander The Rover, by adding wheels to my lander, so that I don't have to do the whole "separate the rover" thing when I get to my destination. All of the wheels are too fragile for my big complicated landers which are loaded with fuel and batteries and solar panels and experiments. The wheels just break when the lander sits upon them or moves much at all. I can repair the wheels, but it's useless if they keep breaking every ten meters. I can get the "giant" wheels to work without breaking, but they have a tendency to rip off of my lander body, making repair impossible. Any other interesting ideas?

I learned the hard way a while back that you can accidentally block the thrust of your rocket engines by placing something in a position that blocks it. For instance, I had a design where I had some landing legs which, when extended, got in the way of the exhaust of the lander's rocket engine. So when I extended the landing legs, the lander would just plummet even when I was applying full thrust. My question is: do RCS thrusters have the same thing? Should I be as careful with RCS placement as I am with main engine placement?

Okay, I see, from your linked thread, that the dev did in fact intend for the science from those experiments to be harder to transmit, without getting any corresponding reward for having been up higher in the tech tree. I'm disappointed by this, and I find it surprising considering the exponential nature of the prices in the techtree, but at least I know now that I'm getting the amount of science that they intended for me to get.

Hey look at that, I've never seen that Launcher screen before. I always just ran it from the Steam menu before. I see that the Launcher allows me to bypass Steam altogether. Nifty. I ran the Launcher, launched the game with it, but no "patcher" appeared in the folder: Directory of C:\Games\Steam\steamapps\common\Kerbal Space Program 10/21/2013 05:49 PM <DIR> . 10/21/2013 05:49 PM <DIR> .. 09/12/2013 11:06 AM <DIR> Ships 09/12/2013 11:06 AM <DIR> GameData 09/12/2013 11:06 AM <DIR> Internals 09/12/2013 03:16 PM <DIR> Screenshots 10/22/2013 05:54 PM <DIR> saves 10/29/2013 01:44 PM <DIR> KSP_Data 09/12/2013 11:06 AM <DIR> Resources 10/29/2013 01:43 PM <DIR> Launcher_Data 09/12/2013 11:06 AM <DIR> Parts 09/12/2013 03:53 PM <DIR> PluginData 09/12/2013 03:15 PM <DIR> Plugins 09/12/2013 11:06 AM <DIR> sounds 10/29/2013 01:44 PM 21,218 settings.cfg 09/12/2013 11:07 AM 9,952,256 KSP.exe 10/16/2013 06:46 PM 10,514,432 Launcher.exe 10/29/2013 01:46 PM 95,717 KSP.log 10/21/2013 05:47 PM 50 buildID.txt 10/16/2013 06:46 PM 116,002 readme.txt 6 File(s) 20,699,675 bytes 14 Dir(s) 474,278,756,352 bytes free

I am not running any mods, and the only change I made to the original files is the one that I want to reverse now. My problem is that I cannot find "patcher" on my hard disk (still).

Yeah, sorry for splitting this into two threads, but I wanted this thread to be about fixing the file back to the original installed version (stupid me for not making a backup). We can discuss the gameplay implications in the other thread. Do you know how to find the "patcher" file mentioned above?

I see your point about how I'm making an assumption about the nature of the bug. But without the multiplier, those particular science items generate a paltry reward. How is one supposed to afford the more expensive levels of the tech tree, if they are not rewarded for buying the more expensive science devices? I had to scour multiple biomes on Kerbin and Mun just to be able to afford those devices, and now you're saying that they didn't intend for ownership of those devices to be richly rewarded. I'm also not understanding the relationship between generating an amount of data versus generating an amount of science reward. Are you saying that those devices were supposed to generate more kilobytes of data to send home, *without* the player receiving a corresponding increase in the science reward?

From looking at the sciencedefs.cfg file, it looks like I could work around it by editing the baseValue and perhaps the scienceCap value. Can someone explain the difference between and the relationship between those values? For instance, the dataScale for the Atmosphere Analysis was 10 (if I recall correctly before I changed it to 1), with a baseValue of 20 and a scienceCap of 24. When I first ran an atmosphere analysis, the dialog box said I'd get a ton of points. I don't remember how much but maybe it was 240? I don't recall. The actual amount of points applied was miniscule though. So I'm wondering, whatever the original dataScale value was, should I multiply that by the baseValue and plug that in there? How does the scienceCap affect it and how does it relate to the baseValue?

There is an open bug where, the science items that are high on the technology tree (The atmopshere nose cone, the gravity detector, and the seismic detector), do not register as much Science points as intended: http://bugs.kerbalspaceprogram.com/issues/1578 I tried editing the sciencedefs.cfg file and reducing the multipliers to 1 (as described in the bug) and it didn't give me the result I was looking for. I wanted it to give me the number of points shown in the dialog boxes. Instead, it simply reduced the number of points shown in the dialog boxes to match the number of points that I'd actually receive if I retrieved the spacecraft. Since these science items are so high on the technology tree, I believe that the multipliers in sciencedefs.cfg were actually *intended* by the designers, and that a code bug is preventing those multipliers from actually being applied. In other words, I believe the designers intended for these science devices to give you high points, and the bug is preventing the high points from being applied. Changing the multipliers to 1 in sciencedefs.cfg doesn't fix the bug, it just displays the (unintended) low point value in the dialog boxes. My question is: Is there any way, via editing existing game files, to work around the bug and allow the high point values to actually be applied? Perhaps by editing some other value other than the multipliers. The reason I'm asking is because I'm mid-way through playing the career mode, having a lot of fun, and I just bought these items and thus hit this bug. This is a show-stopper for me: unless I can earn the intended amount of science points from these devices, I don't want to play career mode any more. I want to keep playing, but the amount of science required to buy the other items high in the technology tree is prohibitive unless I can earn more points from these devices.

Cannot find any file named "patcher" anywhere in the kerbal program tree, or my entire Steam tree for that matter. Is it perhaps under a different name?

Fantastic! Thank you!

Thanks! Can you help me understand what is meant by "Run The Patcher"?

So I spent all this Science on getting the seismic/nosecone/grav detectors, then immediately noticed the bug described in issue 1578: http://bugs.kerbalspaceprogram.com/issues/1578 So as an experiment, I went into the sciencedefs.cfg file and set those values to 1 as it describes at the bottom of the bug. I guess I was expecting the game to grant me high science amounts for those sciences, but instead, the game just reduces the amount shown in the window to match what it actually grants me. Based on that behavior, I guess the bug is: Those values were meant to be multiplied by the datascale amounts, but they were only multiplied in one place (the display window) and not in the other place (the actual granting of points). So, by editing the datascale values in sciencedefs.cfg, although I'm making the two values match now, I'm not actually getting the extra science points that the game designers intended for me to get. So what I'm wondering is: What were the original values for those Datascale amounts? I want to change them back but I was stupid and edited them without making a backup of the file. :-)

A funny thing happened last night: I was trying out the new Career Mode they implemented in 0.22. I'd gotten enough parts to make it to the Mun, and I managed to collect a ton of science points on the trip. I was keen to get some particularly big groups of science points back home in full 100 percent force rather than transmitting them at a reduced percentage, so I was planning my return trip carefully. I was able to fly the ship back from the Mun successfully, but just barely. I ran out of fuel with my Kerbin perigee pointed at 50k altitude. 50k is fine for a return to Kerbin, because the atmosphere starts at about 70k, so it means that I was aerobraking on each orbit and would eventually reach Kerbin. The problem was, the air at 50k is so thin that it was taking far too many orbits to get any serious amount of altitude reduction. Pass after pass, and my altitude would only decrease a small amount each time. It was taking forever. My ship had no rocket fuel left, and no RCS thrusters because I hadn't gotten that far in the tech tree yet. So I couldn't use direct thrust to get my perigee any lower. So I tried something that I wasn't sure if it would work: I got out and pushed. I pointed the ship in the retrograde direction at apogee, did an EVA, jetted around the to tail end, bumped up against the engine nozzle, and just thrusted forward with the jetpack. It did take me a few tries of going back into the capsule, checking my perigee, then going back out again. Also at one point I had pressed CTRL-ESC so that I could get back to the Windows desktop, and this left me with a stuck CTRL key in the game, and since CTRL is jetpack-thrust-down, it made Jeb shoot away from the capsule at high speed. It was a tense moment getting him back to the capsule, but I made it. In the end, it worked. At apogee, it took just a few rounds of jetpack thrusting, getting back in the capsule and checking my perigee, then going back out again. I successfully reduced the altitude at perigee a few K, enough so that the aerobraking had some bite to it, and I reentered normally and landed safely with parachutes. I landed the entire lander from the Mun surface, including landing legs and everything, landing vertically in a gentle touchdown. Total science points from the trip: 900! I had a great shopping spree when I got back. It only worked, though, because I was already on a reentry orbit path that was good, and all I needed was a slight tweak to the overall orbit. And small speed changes at apogee result in big altitude differences at perigee, and vice-versa. Still, it made me think of Leia chiding Han in TESB: "Would it help if I got out and pushed?" "It might!"

Yes, but, ignoring the precision question, which of the two things increases my height more, given the same fuel consumption? (or conversely, would doing one or the other require a slightly shorter burn to accomplish the same height change?)

I can poke at a forum during the day in between my other tasks, but I can't play Kerbal during the day. :-)

By the way, from what I hear you saying, I think you're saying that staying pointed prograde will result in a slightly more circular orbit, and that staying in a straight line will result in a slightly more elliptical orbit (with a higher apogee overall). Interesting. So the question isn't just which is more energy efficient, but, for a given amount of energy spent, what does that energy get spent towards?

I asked the forum so that I wouldn't have to test it myself. :-) PS: I'm not using MechJeb, just running stock Kerbal.

Agreed that *where* you burn is the most important thing, because there are places in your orbit that are more efficient than others for certain kinds of desired destinations. That's good general advice for navigation. But that's not the question I asked. Also agreed that staying pointed at the maneuver marker is the only way to ensure that you actually reach your calculated destination. Again, not the question I asked. My question was: *All other things being equal*, which is the more fuel-efficient burn for a given delta-v? Follow the ball or stay in a straight line? I think that your original answer, Mr. Shifty, was the one that got closest to the heart of the question: If you stay pointed at the maneuver marker in a straight line, then you're doing part of your burn pointing slightly down at the planet and thus decreasing altitude slightly and thus increasing the Oberth effect slightly for that portion of the burn. The question becomes, is that then offset by the portion of the burn that occurs pointing slightly away from the planet and thus decreasing the Oberth effect slightly? And overall, are those effects, in the end, mathematically identical to what I would have done if I'd turned my nose and stayed pointing prograde the whole time?

Actually, that's exactly the question I was asking, it was in fact the very thing I cared about.

Right, I know that by pointing away from the marker I'm diverging from the programmed maneuver. My main question was about the efficiency of the burn and the amount of fuel needed for a given delta v. So you're on the same side as Tavert, saying that following the prograde arc will give me a more efficient fuel usage?

Okay, Tavert and Numerobis are directly contradicting each other: Who's right? This is the core of my question.

Let's say I'm doing a burn using a maneuver marker. It's a simple prograde burn, in other words, the only direction I need to burn is prograde. This means that, as I approach the maneuver point, the prograde indicator on my nav ball and the maneuver marker on my nav ball will slowly converge. When I reach the maneuver point, my prograde indicator and the maneuver marker indicator on my nav ball will be on top of each other. After passing the maneuver point, the two indicators will slowly diverge again. Let's say for example that my burn is scheduled to be 2 minutes long. I know that standard procedure says that I should aim at the maneuver marker on my nav ball early, and burn in a straight line for an even amount of time on either side of the maneuver point. For instance, in the case of the two-minute burn, I should burn starting at T minus one minute and finish burning at T plus one minute. This, according to what I've gleaned from reading other threads, will get me the most accurate positioning for my calculated destination. But what if, instead of aiming at the maneuver marker, I aimed at the prograde marker on my nav ball? And kept turning my ship to follow it? Would this result in a more efficient use of fuel, thus allowing me to shorten the overall length of the burn slightly? Or would that be mathematically identical to the straight line burn?