Baythan

Agreed! Now how do we present this idea to Squad in such a way that we can convince them a large number of people want this kind of change ASAP? I'm almost certain they understand that the current tech tree just won't work in the long run, but it may be a low-priority item for them and we may not see anything done for quite some time. As it stands, I believe the changes to the buildings combined with the current tech tree make Career Mode nearly impossible, or at the very least VERY grindy for several hours in the beginning. I'm looking for a modded tech tree right now so I can at least build some small planes early on to try to accomplish the survey missions without spending all my money on rocket fuel. I consider Stage Recovery to be a necessity for Career mode now because the cost of lost stages makes many contracts worth nothing. Gaining enough funds to upgrade the VAB and launchpad (to get over the 30-part and 18t limits) even with that mod STILL takes many hours(I haven't accomplished this yet) for me without the ability to do any 'fun' missions. Maybe I need to watch some more advanced players do Career mode, because I can barely get to orbit and return with fewer than 30 parts.

I too am hoping this gets updated to 0.90, but the changes to the tracking station probably made it harder to implement this feature. Patched conics is unavailable at the start, so my guess is that there was a major change to the code this plugin runs on. We should give Youen plenty of time to look into things and see what it will take to update. I might be wrong and it's an easy fix... but it would surprise me if it is simple.

For anyone who's considering this mod for career mode, USE IT!! I must hate myself, because I started a new 0.90.0 career mode with only 10k starting funds... and I'm having to grind like mad to make enough money to upgrade my VAB (almost 400k funds!). If I could build an airplane to run around and do a few of the surveys I'd be golden, but I don't have any landing gear yet! So, being able to recover ~60-98% of any stages lost as I hop about trying to fall through survey areas is really helping me gain funds rather than lose them. I just wonder why this isn't part of Stock KSP yet? With the new career mode it seems impossible to GAIN funds if you have to stage anything, yet it is not possible to build SSTO's early on. In my mind, this mod is a requirement. HUGE thanks to magico13 for updating so quickly! I'm not even mad about the accidental mistake in packing. I noticed my stuff wasn't recovering, came here, saw that there was a fix, viola! Kudos!

I like the ideas presented here for a tech-star/web. Most of the issues I have with the tech tree have already been discussed, such as landing gear being so far into the tree, meaning I can land on the Mun and Minmus long before I can land an airplane (or even take off). So many things in the tree are arbitrarily nested with other random items. I would really like to be able to research specific parts rather than groups of parts, or smaller groups of related parts that lead to better versions of those parts. I'm pretty sure there will be more parts added in Beta, but I disagree with waiting till they get added before changing the tech tree. I think a better tech tree using the current items would be much easier to add new parts to rather than waiting till there are even MORE parts to sort through to design a new tree.

I don't know about the rest of you, but I can't view the above-linked thread. I am curious about the AMD compatibility though because I use AMD processors and video cards in my current system. I've already had random crashes due to multicore processing issues with Unity, and I have no idea if those have been fixed yet.

It looks like a total lack of SAS apart from what's in command modules, having RCS on(I see RCS nozzles on the lander firing) and a rather over-done lift stage are all part of the issue. Were you controlling the vessel from the lander command module or the big command module? If the lifter or one of the docking ports was the current control center, it can also cause SAS and RCS to go wonky. If you use something that can calculate Delta-V for you you'll be able to design a lifter that drops its last lift stages just before circularizing and that nuke engine could finish the circularization burn and still have plenty of fuel to reach Duna. I just see too many engines in the middle of that rocket, which makes it really long and flexible. The problem with this idea is that he lifted the Duna lander separately, it wasn't built into that ship.

Now THAT is exactly what I need to know! I would not have thought to lower my Pe first before making an escape burn, I'd have just done it at the current Pe. Thanks!

THAT is an awesome picture. I approve of this idea.

Glad we could all be of help.

In the end, this is what I would do anyway for one simple reason. If I'm in an elliptical orbit with a high Ap and a low Pe and I just want to escape the SOI, I'd burn at Pe because the Ap is already closer to escape and therefore requires less ÃŽâ€v to move it to escape altitude. Of course, if you are in an orbit where escaping in that direction is BAD, say, because that is the direction the body is travelling and escaping is only going to be temporary, then you have to burn elsewhere anyway. So in the end, is there any specific situation where NOT burning at Pe would SEEM like a good idea but in fact be a bad idea? I've heard one or two people mention making use of the Oberth effect in KSP, but still haven't figured out any reason why this is something we wouldn't be doing as a matter of course already if we've learned how to fly efficiently without ever having heard the term or it's definition. In other words, what's the point? Aren't we already using this information without actually knowing it in these terms?

So, based on these definitions and descriptions of the Oberth effect.. the best(well, most efficient) time to change orbit shape(increase/decrease Ap or Pe) is at Periapsis because at the BOTTOM of the orbit, you are travelling faster. In other words you can raise or lower Ap more per ÃŽâ€v spent at Pe than you can raise or lower Pe while at Ap.

Well, I know my definition of ISP was not entirely correct as I didn't do much technical reading on it, I just checked the KSP wiki which linked me to the wiki and I gave a rough definition based on what that said. What it boils down to, if I understand correctly, is that higher ISP means the engine is more efficient. This doesn't mean it has higher thrust, it just gives you more ÃŽâ€v for amount of fuel used. A different engine might have more thrust and therefore accelerate faster, but uses more fuel to do so. This is the important part when mission planning, because if you can do longer burns, you want the more efficient engine, but for shorter burns you might want more thrust instead. Of course vehicle weight matters, that's where TWR comes in. And now I've lost my train of thought.

Exactly. ÃŽâ€v is change in velocity, or the amount of extra velocity you can give yourself in any direction, so burning against current trajectory adds velocity in the opposite direction, decreasing current velocity. So, in other words, ÃŽâ€v is POTENTIAL energy. Nothing about your vessels current ÃŽâ€v will tell you when to start doing a burn. Acceleration, caused by thrust, is how quickly you can make that change. As lajoswinkler showed with his math, the heavier you are, the harder it is to accelerate. If you have better engines with higher thrust, you can accelerate faster because you increase your TWR. As you burn off weight your TWR increases. KSP can actually calculate how long a burn will take depending on current thrust, as you increase throttle the time for a burn decreases. What KSP doesn't do is calculate that information for you BEFORE you activate engines, so switching vessels erases it's previous calculations for current burn times.

Oh! I failed to notice exactly where the tug engines were! Thats my fault. I see the design now. I had some problems with SAS ripping one of my vessels apart when trying to change direction for orbital burns and discovered it wasn't because of the 25+ large SAS I had(4 RCS claw vehicles with 6 SAS each attached radially via normal docking ports). It turns out I was trying to control the vessel from the middle instead of one end(extra fuel docked to the back of the RCS Claw carrier, again via normal docking ports), so the SAS was having trouble getting everything to orient correctly. I'd show a picture but I've since re-designed after unlocking larger docking ports, and now I'm getting Null-Refs on the new design. Edit: I think the new vessel is corrupted.

Nice, but it sounds so boring! At this point in my career as a Kerbonaut, my highest failure chance is at launch. If I skip that part the only explosions I'll see are when I crash something on purpose. Edit: I was also guessing that the more often we throw out legible instructions on how to do things manually, the more people will learn to enjoy the game. I understand the usefulness of MechJeb, but if too many people rely on it to do all the flying, are they really playing the game? Not saying it's wrong, not at all, there is NO wrong way to play KSP(except pirated, please, these guys deserve the money for what they've done). I just found myself getting bored by letting MJ do all the work, so I got rid of it to see what I could do with just Kerbal Engineer telling me what my ÃŽâ€v is.

I'll pretend I understand the difference. I was just trying to explain it as best I understood it in layman's terms. I'm no mathematician or scientist, just a relatively intelligent gamer that's learned a lot from this game and I have begun trying to share my knowledge from that perspective. I figure if some people explain it scientifically and others from a gamer perspective, people will find the information they were asking for somewhere in the middle. Same here, except for some stuff in the modding forum, I hadn't felt I had much to contribute until recently. My post count has more than doubled(if not tripled) in the last two weeks. Of course, some of my posts were lost back when the forums server got corrupted. Those SSTO's look awesome, but I don't know if they'll work on Eve due to the different atmosphere(I assume that was the lesson learned). As far as making them wiggle less, you have most of their mass in front of their docking port connection to the 'tow vehicle,' so it's PUSHING them through space, which I would guess makes them flex all over the place.

Well, the non-smarta** response is that (oh, post removed while I was writing, and others beat me to it as well) "Delta" or "ÃŽâ€" means "Change." It's a mathematics/science term. As you know, ÃŽâ€v means "Change in Velocity." How it's calculated is much more complex. On the launchpad, your rocket has a specific mass based on the weight of all of its parts and fuel. Each engine has a specific thrust and ISP (Specific Impulse, or amount of fuel used per unit of velocity gained). Some engines work better in atmosphere and some in a vacuum. As your rocket burns fuel, it gets lighter, and therefore easier to push. This leads to Asparagus staging being the most efficient method of rocket construction in KSP (not in real life, because fuel can't be pumped that fast between tanks) because you drop excess empty tanks to shed weight. Total ÃŽâ€v is advanced calculations based on how much fuel you have and how much thrust you can generate with that fuel. Sadly, without mods, it's not easy to calculate total ÃŽâ€v in KSP, and knowing how much ÃŽâ€v you have left mid-mission is even harder. Adding maneuver nodes helpfully tells you the amount of ÃŽâ€v needed to accomplish the burn, but nothing tells you how much ÃŽâ€v you CAN use. MechJeb and Kerbal Engineer Redeux are the two most common mods(that I know of) that calculate this for you. There are two major factors in knowing 'Whether or Not You'll Be Reaching Space Today'; ÃŽâ€v and Thrust-to-Weight Ratio(TWR). You could have 7,000m/s of ÃŽâ€v but if your TWR is less than 1, you won't move. When building a rocket, be sure that each stage has a TWR greater than 1. The higher the TWR, the faster you'll be able to change your velocity.

As far as the auto-circularization of Kerbin, I assume you mean from launch, I think that might be possible with some of the advanced features, but the amount of tweaking needed for each individual rocket is a bit higher than the minimal effort needed to just do it without autopilot (in my opinion). There are a number of ascent tutorials out there, and different ideas about when to do what, but I'll give you a simple rundown of how I reach orbit for 99% of my missions. Reaching a Circular Orbit Around Kerbin Step 1: Proper rocket construction and mission planning. Yes, this is always step 1. Most sources agree that the Delta-V needed to reach LKO (Low Kerbin Orbit, ~80 km altitude) is somewhere around 4,500m/s. Because I don't like to leave launch stages in orbit, I design my rockets launch stage(s) to have about 3,800-4,000m/s and let the rest of the orbital burn be done by my orbital maneuver stage. I find ~4,500m/s to be enough to get any orbit I want between 80-100 km, and I always give myself extra Delta-V in the later stages for corrective burns. Step 2: Launch. Use MechJeb to lock yourself on a 90° heading with 90° inclination and if you don't want to roll at launch, 90° roll (or turn your rocket 90° in the VAB, I don't know why you BUILD [with the camera]facing East but LAUNCH facing North). Yes, I have used MechJeb before so I know it can do this. Also, auto-staging and letting mechjeb limit throttle to keep you below terminal velocity help. I like to reduce the auto-staging delay to about 0.1s with 0.5s gap, or whatever they call those two settings. Step 3: Depending on rocket speed, begin turning towards 90° at either 200m/s vertical speed OR 10 km altitude, whichever happens first. Immediately after launch change the Mechjeb inclination to 75° BUT DO NOT ACTIVATE until you reach this step. As you climb higher, slowly lower the inclination by 5-10° at a time. Keep your Apoapsis on screen in a mechjeb window somewhere, and when it hits that orbital height of 80-100(whatever you want), turn off your engines and proceed to the next step. Step 4: Tell Mechjeb to do a circularization burn at Apoapsis and execute the node, then wait for it to do that. I believe the auto-ascent planner or whatever that function is can to Step 3 for you, but I never unlocked it in my Career mode, so I don't know how to use it. I also like doing the launch myself because it's fun. Once you get enough practice at it, you might try a launch or two without activating Mechjeb at all. Just use its info windows to get the readings you need, and lock SAS as you do the launch.

Those Ion powered hoverbikes look awesome. Now I want one. Edit: As far as traversing the Mun, I'd try for a VTOL with wheels myself, because rovers are slow and can't climb crater walls very well. I'm still designing my Mun rover, but the idea is to have a stable setup that can use engines to push it both forward and up so it can roll around at high speeds for the most part but also 'jump' over ridges. Potential Kerbal deathtrap? yes.

After 0.23.5, you could probably get away with only 1 strut per side tank, near the top, just to stop what little bounce happens.

I don't use Mechjeb much myself, so I'll be giving you the steps to end up in a decent orbit from that basis, but Mechjeb can do these steps itself if you find the right command. Also, use the Dev builds unless they have an official 0.23.5 release. KSP 0.23.5 kinda broke a lot of the maneuver planning for Mechjeb. From what I read on their forum while I was deciding between MJ and KER, MJ was waiting till you reached nodes to do burns instead of doing half the burn before the node and half after. Reaching orbit from impact trajectory: Step 1: From as far away as possible (to reduce Delta-V needed), increase Pe to desired orbit OR to a good aerobraking altitude (depending on astral body). For a prograde orbit, point to 90°, for retrograde point to 270°. Step 2: (Skip to step 3 if not aerobraking) If correct aerobraking altitude was selected, Ap should now be inside the SOI of target body. Create node at Ap to INCREASE Pe to desired orbit. Step 3: Create node at Pe to reduce Ap to desired orbit, which should be a retrograde burn. Step 4: Orbit should now be circularized. Even though the aerobraking has more steps, it can save you a LOT of Delta-V on Step 3, but only works on bodies with an atmosphere.

I suppose i should have remembered that this thread is about the Delta-V simulation code and NOT about the entire KER mod in general, so my previous post was in the wrong place. Sorry about that. Padishar, we really appreciate the work you are putting in make KER work for what we really want, which is that D-V info. Thank you, and great job!

That ok, there still seems to be some of us who like the idea of modifying the current system into something we feel would make asteroids more useful. But as I have no new ideas beyond my first post I'm waiting to see if there are other ideas.

I'm assuming you mean that it would be nice if the KER UI was more vertical in the VAB like it is when actually flying, and I agree. I'd actually really like it if the KER window was more customizable and you could separate the different sections and/or resize it. This would make it seem more like MechJeb, but without the autopilot and I can understand not wanting to appear to be mimicking someone elses work. I stopped using Mechjeb mostly because I DON'T want an autopilot option at all, I just want Delta-V calculations and orbital info on the same screen where I'm flying and staging.

Okay, so I just wrote about two paragraphs about how I'd like asteroid science to be changed and I discovered some problems, probably the same problems that led to the DEVs setting it up the way it currently is. Current Setup: Each individual asteroid is worth (I think) 60 science for each situation. So: 60 for orbiting the sun, 60 for orbiting Minmus, 60 for Mun, 60 for Kerbin, etc. Each asteroid is worth science even if its the same class as a previously tested asteroid because its not made of the same stuff. Problem(s): Moving large asteroid into all these different situation is more expensive(in delta-V) than going to other planets AND those planets are worth more because of multiple different science experiments. Idea: Each class has its own science value no matter the situation. A's worth 40-60, B's 60-80, etc. So bigger asteroids are worth more, but can't be exploited by moving them to other orbits. Problem(s): Why capture it? Just rendezvous, grab science, go home. Well shoot, no wonder they did it the way they did. The whole IDEA is to capture them, so WHY NOT make it worth more to put it in a different situation. So now I'm trying to think of a different way to do it that wouldn't require a whole lot of extra code designed to detect whether the asteroid has been redirected or not. If you limit the asteroids to only giving science if they are in Kerbin SOI, just wait till it's passing by and do science and let it pass. If you limit it to only giving science if its in safe Kerbin orbit, fewer people are going to bother with them at all unless they are worth a LOT of science(at least as much as a Mun surface sample). I think the best thing, for now, would be to make larger asteroids worth more. As it is, class A's are the best way to get science and class E's are just bragging rights.