weezl

Not Hansolo.. Hohmann.. see this: http://en.wikipedia.org/wiki/Hohmann_transfer_orbit I understand your request, and if someone decides.. good.. more power. In the meantime please read my original post and this post for content.. and lay off the sarcasm, trust me on this.. its not helping you make your point. Its good information I am providing.. if you don't care for it.. that is fine.. just move on. Additionally.. there are MANY write ups on doing orbital rendezvous and Hohmann transfers on this very website. They translate the general concepts of the wiki quoted above to in game actions in KSP. Its how I learned to do a Hohmann transfer and orbital rendezvous.. It can't be all that hard.. I only picked up this game 5 weeks ago. And on the subject of orrery, I learned about them in elementary school in the 60s.. yes.. they are useful tools at visualization.. I don't deny that in the least.. Did you realize you don't need one? When you start up KSP you can go directly to the tracking station and then instead of picking something to control.. just run the simulation on the fastest time warp.. voila.. instant orrery (I realize you asked for an external tool.. and it wouldn't be as fully featured as something that could jump to a point in time.. but its better than nothing..). VERY easy to visualize what is going on there.. but a warning.. it still won't teach you about doing Hohmanns.. That is something you'll simply have to learn (assuming you are interested in fuel efficiency.. I can't know if that is important to you or not).

Really? To me an interplanetary transfer is nothing more than a Hohmann transfer writ large. What seems confusing at first is that you start in an orbit which is not the orbit you are transferring out of.. Kerbin to Duna is really Kerbin to Kerbin escape SOI to Duna.. the first is just achieving escape velocity and the other is just planning a Hohmann transfer between Kerbin's orbit and Duna's orbit. And based on the speed of the target planet when the target planet will be at the apoapsis of your transfer orbit. And since its just a normal Hohmann transfer, you can intercept at some point other than your transfer orbit's apoapsis, with a cost of extra fuel used to 1) achieve the intercept; and 2) match speeds @ the intercept point. I've been doing Kerbin and Mun and Minmus orbital intercepts for purposes of docking for quite a while now.. and the concepts of how to do that vs. interplanetary transfers are exactly the same. For people looking to learn how to do interplanetary intercepts.. the BEST training ground is doing gemini type missions in Kerbin orbit where two spacecraft must reliably rendezvous and dock. I've put refueling stations around Minmus and Mun as well as Kerbin so I could do this around multiple celestial bodies.. its great practice for doing interplanetary transfers. And it also teaches about how spacecraft act in orbit based on distance from the body they are orbiting, and how to orient them for easiest docking. Once you can reliably orbit and match orbital inclinations, make rendezvous/docking a routine maneuver and the solar system is open to you..

Is this sarcasm? I can't tell. I'll assume its not for now.. and in that light, my response: Buying something As-is means just that.. AS IT EXISTS RIGHT NOW. Which means you have zero leg to stand on to complain about anything. In latin they would say: Caveat emptor. Let the buyer beware. Want a full release product? Don't buy it until it goes full release. Anyone agitating for whatever they want done to the product has every right to agitate, these board don't prevent that. But the terms of the purchase with Squad are very simple.. Squad delivers what they want when they want. And what you bought is what you bought. Period. Full stop. I'm not saying Squad is ignoring the community.. far from it.. from the communications I've seen they are paying close attention. But they don't have to listen to any one voice per the agreement.. and that is absolutely the correct stance, especially in game development. I've seen many games where there is a very small but highly vocal (and frequently immature) minority that can push your game in the wrong direction if you just listen to them. Shooters are especially prone to this. Every game developer has that reality at the front of their mind when interacting with a community. They are building a game for a large potential customer base, not just for the folks who take time to post on forums. The kiddies don't like hearing this.. but its the real deal. Finally.. When posting on the internet.. keep this in mind: http://en.wikipedia.org/wiki/Poe's_law If you were being sarcastic.. its very easy to miss when things are in print.. remember that lots of folks post on the internet that have the reasoning capabilities of a hamster..

This begs another question.. since you need this much fuel.. how much of the Kerbian economy is totally consumed by production/transport of this fuel in preparation for use? And for how long? The biggest energy consumption I can think of on earth is oil.. which is produced at the rate of about 6.5 billion barrels/year... or about 1.044 trillion liters of oil. And the dollars required to just extract that from the ground are extreme.. but we are talking LOX and something like hydrazine.. which is MUCH more complex to make, and MUCH more dangerous to store. So if we go with 1000:1 efficiency difference (probably still too low), that gives us 1.044 billion liters of fuel per year... I don't have the calcs on hand for fuel density.. but it wouldn't surprise me if its at least century or more of production to get 250 billion tanks. And that is assuming you commit 30% of an earth based economy to production of just that one item. Of course.. no one has mentioned nukes.. I know they aren't in the game.. but for pure matter to energy conversion, you just can't beat it.. although the site where you are applying the force might have to be abandoned as a landing site for some decades after the adjustment event.

If I might be so bold.. please take your own advice.. many posters here have pointed out that this game is in development and that the aerodynamics are a place holder, you even say so yourself so I know you know this. Your reference to timeframes is pointless.. game development takes time.. especially for something like KSP that has so much to model to even look 'kind of' like reality. They will get to it. Please show patience. THAT is the point all the other posters are making. We all get you want it now. I'm pretty sure if you asked the devs they would want to program everything instantaneously too.. its in the nature of many folks to want to do their best. Unfortunately, making working code is time intensive. You are free to ask.. just don't expect everyone to agree.. we all want the best working game possible.. and many of us trust Squad with having good judgement.. and know the time involved in making something that works. Its not 'being defensive' to point these things out to you.

To the original poster: please check out the website quoted here.. its meets your needs without all the extra 'non-value-add'. Just visualizing something can be done inside KSP with the maneuver tool after you know the correct launch window.. and for that, the website is fantastic.

This. Although.. for the life of me, I can't understand why Alexmoon's site isn't the correct choice in this regard. It actually gives ideal launch windows, and shows the overall delta-V if you pick a non-optimal window. That is perfect for mission planning.

Design assumptions aren't generally affected by expression languages. And complexity increases as the size of the program increases. Its a Systems Analysis point of view. OO helps you minimize these effects by providing reasonable mechanisms for isolating modules.. but you can't ever change the affect of design assumptions on your future code and your between module dataflow issues in general. This is why all code bases have inertia. Its totally good to have the goal of minimizing it.. I've preached that for 20 years now. But so far I've not seen a large system that doesn't have that issue. And I've work on large systems pretty much exclusively since 1986 or so.. and by large systems I mean code under management of 3/4 million lines of code and UP.

Very good.. and as I alluded in the previous post.. good humor!.

There are minuses to too much communication.. Read please: http://www.commpro.biz/marketing/toeing-timeline-avoid-marketing-oversaturation/ I appreciate that you don't feel properly serviced by Squad right now.. but you might want to look at it from their perspective too.. that was my original point.

Exactly.. Most of the time the folks I work with refer to it as 'code inertia'. Code over time: 1. Gets bigger. 2. Bigger = more complex. 3. More complex = harder to change. 4. Harder to change = harder to test. 5. Harder to change/test = longer to change/test. This is true of all softwares I've ever seen, and all software projects. Good design can mitigate some of these effects, but never can it be eliminated. Developers ignore this reality at their peril.

This is correct.. there are also additional considerations which make things even more complex: All programs involve simplifying assumptions. That is as true of KSP as it would be of a modder's code module. As long as bringing a new feature into the current codebase doesn't change those underlying assumptions, all is well. But if an assumption must be changed.. it can have a frightful affect on a codebase depending on how the original coders managed the complexity of the code in the first place. If the code is nicely designed and all the modules nicely isolated, then changing an underlying assumption may be merely 'large' in its affect. But if it isn't (for any number of reasons), then changing a simplifying assumption could mean something approaching a major rewrite. I've seen this on a code base that was quite small (<40K lines of code). The original authors had written a mess (they were business folks, not computer science folks), and when we had to change some things, it blew up into re-writing 2/3s of the code. Note I'm NOT saying KSP is like this.. I just know what can happen when you make assumptions that are wrong 1 year from now. And.. I expect that KSP is larger as a code base.. which means underlying assumptions changing midstream can have a quite large effect. When you are writing code, you must try to keep the future in mind.. but the future you decide on might not be the one you actually see.. which is why some programs end up dying nasty deaths after 4-5 years. The process of designing and writing large programs is a series of line-bets on the future along with a whole lot of rigor to make sure things work correctly as you write each module and integrate it into the whole. I've met LOTS of programmers that don't make good line bets, and many that don't apply a lot of rigor.. as those bad things multiply, things get worse yet. Again.. I'm not implying anything about KSP, just trying to give real world perspective on the process of writing software.. Looking at the stability of KSP .24 vs. what it could be, I'm betting its a well organized highly unit tested piece of code.. which from any programmer is high praise. I don't know this for a fact, I'm just a customer.. but it seems like it is so.

As a developer.. I've learned to value the input of those business folks.. they look at the world through the prism of the cold/hard reality of being able to make the bills at the end of the month. Not enough developers look at things this way.. Just like there are bad developers, there are bad business folks.. at the end of the day though we are all trying to make money to provide for our families and find the best way to keep current customers happy and get new customers. The biggest mistakes I've seen from the business side is under-valuing how quality contributes (or detracts) from customer satisfaction.. and that software engineers invest in quality like all other software activity.. slowly. Cutting working code is a huge effort to get right.. and the more complex, the slower going. I think many of the really awful game releases in the last 10 years are a result of these things, combined: Software engineering overestimating what it can get done in a given time period. Business side under-budgets for already incorrect software schedule. They run out of money and decide to try to release anyway, with horrific consequences. I say this because I've seen it.. a lot. Thankfully, Squad seems to get the incremental delivery/good quality model right.... for a .25 product, KSP is amazingly stable.

I so totally agree with this.

Well said. Me too.

Sigh.. why must it always devolve to this? First.. I'm a developer myself.. and have lived that life for 30+ years now. Development work is very intense at times and requires a lot of focus. And at a certain point in development.. after the plans are set for the next release.. there really isn't a lot to say other than 'its coming'. There will ALWAYS be impatient folks wanting to be assured you are working on things, and you can NEVER make them happy, no matter what you do since their impatience will only be assuaged by the delivery, not the messages leading up to the delivery. You don't know what their intent is, and are leaping at some greed oriented 'cash grab' without even knowing them or what their current issues are in development. Please oh please show a little more consideration. These are folks with families trying to make a living.. and I can assure you that 99% of them are just trying to do the best they can. Some folks I've met in development are jerks.. but they are less that 1% of the total population.. the rest are just as I describe them.

I was going to post something similar to Nate's post.. but he already did it! So ditto for me on this message.. fantastic game. And we aren't even to release 1.0 yet!

Maybe I'm stating the obvious here.. but its a game, yes? Games approximate reality in some form.. until they don't. And when they don't they really don't. Squad is on to something beautiful with KSP.. it approximates reality where it is important.. and departs from reality where it is important.. that is called good game design.. or simply 'designing for fun'. I understand folks that want reality.. I really do.. but I feel ( like many ) that fun would be compromised if we get too caught up in making things mimic reality. If you are just commenting.. fine. But if this is a suggestion for change, I most heartily disagree with it. Right now KSP seems very well balanced between reality and fun.. There are things I'd suggest.. but they are more career oriented features and things focused on the game aspect.. what they've done to approximate physics but still keep things simple is just rocking from my perspective. For what its worth. Finally: Rockomax is not responsible for any rapid, unplanned disassemblies. LOL!

Really only if you aero-brake. If you burn and circularize at kerbin capture then your capture burn is about the same as your exit burn (in the mid-800s). You are still equalizing your velocity against the same amount of gravity, and at about the same distance from the orbital body.. Once exiting its orbit, once entering it. The *big* difference where Kerbin is concerned is that your de-orbit is not equivalent to your ascent burn at takeoff. You are letting the atmosphere do the same work for you coming down as you had to do on your own going UP.. so its a lot cheaper. No matter what, I tend to over plan a bit on deltaV to make up for the monkey behind the wheel (me). So I add 10% or so to many of the numbers.. ESPECIALLY the take off numbers and the landing on planetary body number that doesn't have atmosphere. The exit burn from the Mun and the capture burn are essentially the same.. but I think the exit from Mun is a tad less because of the gravitational force exerted by Kerbin.. One thing I tend to do to reduce landing cost on the manned missions is run an unmanned probe to my landing location and scout good flat ground to land on.. this gives me landing altitude information, and location on the body.. allowing me to run narrower on the missions that have to lift more raw weight. That said.. there is a BIG IF here.. all this depends on the pilot choosing an equivalent low energy maneuver for entry/exit to a planetary body's SOI. This isn't necessarily the most intuitive thing to do if you don't know orbital mechanics, although messing around with the maneuver nodes can be instructive in how you can plot intercepts that still work, but are more expensive.

Paraphrasing (for humor's sake): Come over to the Dark Side.. We have cookies!

I'm new to this game (3 glorious weeks now).. My background is sciences (physics/chemistry) and computer science.. so advanced mathematics is no stranger to me.. so I do all the delta-V calcs for all my rockets in a spreadsheet.. thanks to the folks who put together the kerbal wiki, I didn't have to look up all the equations in college texts.. so for me it that part took about 30 minutes. I also fly my own missions by hand and don't use any add-ons since I'm *also* heavily into flight-simulators.. If the maneuver interface wasn't in the game, it would make hohmann transfers mathematically challenging, since you would have to do all the equations for each transfer.. So thank god for the maneuver interface. I think even the Apollo planners had computers to fall back on for that.. but you get the point.. you'd need a program or spreadsheet to do the calcs. Keeping that in mind.. if you didn't have my background I can see the learning curve to get efficient rockets flying being a HUGE investment in time (like the investment I made earlier in my life getting the knowledge.. literally YEARS of my life to get the math and science skill to understand all this stuff) so to me if you don't have a background like mine it would make something like MechJeb basically mandatory (or the next thing to it). Adults just don't have time to get an undergrad in college mathematics and physics just to play a game. For me.. the mods would ruin MY fun.. since I already have the background to understand all this stuff.. but for someone with a background in something non-science/non-math.. it would ruin their fun to NOT have the mods. For them the builder/exploration portion is the fun part... This makes the use of mods a very personal choice. I for one am glad that are there for mods that allow folks to enjoy this game without all the math.. if you like math (like I do).. then don't use them! If not.. use and enjoy!