LethalDose

They're trying to do exactly that with Reaction Engines Ltd's Skylon and Virgin's SpaceCraftTwo.

First, to calculate TWR, the equation is: TWR = F/gm, where F is thrust (in kN), g is 9.82 m/s2 and m is vessel mass (in tons). The TWR at launch for the vessel you've provided would be 315/(9.82 * 15.1) = 2.12 For stock aero (I play with FAR), the consensus seems to be you should aim for a TWR of ~ 1.5-1.7 at liftoff, but don't take that as gospel, at least from me. For what you're asking, Th3F3ar is correct: Getting those estimates is something of a fool's errand IMO. The end state of the flight is determined not only the starting TWR, mass, etc, but also the flight path. In general, I think stock aero takes about 4.5 km/s of dV to get into LKO with a reasonable TWR. That's a better target for vessel design than what it appears you're trying to do.

This highlights a good point. I think of dV like a currency. The dV remaining in your vessel is what's in your "wallet" or "purse", and the dV needed to make a maneuver is the "cost". In what Bob has described, "what everyone here has given" is the former, and "change in velocity needed etc" is the latter. Note both "kinds" of dV are in m/s, the same way both costs in a store and money in your wallet is represented in dollars or pesos or pounds or whatever. Trips from A to B, like from LKO to the surface of the Mun, can be done via multiple different paths with differing dV costs. The trick is to find a low dV cost path, and then design a vessel with sufficient dV (and TWR, but that's beyond this discussion) to fly that path. One final note: The dV costs of the trips are independent of vessel mass, which makes it a convenient measure for discussing and comparing orbital flight paths to reach various locations.

Learning FAR is learning to fly again. You've giving a lot of details that, IMO, is putting way more effort into figuring it out than you need. It takes about 4500 m/s to get into orbit under stock, and 3500 m/s to get into orbit with FAR. Just get KER to get these dV values. However you want to build a rocket that can get your payload into LKO with those dV totals will work. Start turning over just a few degrees right off the pad. Broader rockets will just add drag. Not sure you're locking all those parameters instead of just launching what you need. ALso, you don't need a 1.65 TWR in FAR, only need about 1.1-1.3. Addendum: Forgot your question near the top of the post: Is it worth making the switch? Yes. Stock aero is Krap.

Best Answer for this is Wuphon's response: With the addition that the CommTech-1 has a similar range to the GX-128, and 88-88 is probably the best dish for intra-system communication in the Jool system. Kryxal is right on both counts. Overall, it's really better to design your RT system to link directly between the target and Kerbin ("Kerbin" meaning a satellite relay in the Kerbin system). Bouncing between the planets gets messy and really doesn't save your any effort.

I would recommend DasValdez's series. Should be stock parts and only KER + KAC for mods. He goes through the whole thing: Design to recovery. It's a little long, but informative.

Thanks, that's a way more useful answer. I still need to add the "@" notation in front of the nodeName and key refs there when dealing making writing a MM patch, right?

I kinda have to assume you're answering my question above, so I'll respond, even though your response is so brief that its doesn't really help someone who is incredibly ignorant about how this system works. Are the strategies loaded through the "GameDatabase"? The strategies folder is in the GameData/squad folder, so... yes? And I have no idea if "STRATEGIES" is a valid config node. That's really the crux of my question since I can't find any reference to it in the documentation I've found.

A million times this. I've watched two or three live, and everytime max just wastes a huge amount of time demonstrating he doesn't know how to play the game he's in charge of but somhow gets to tell us what tools we need to play it while stringing the viewers along. So, yeah, I guess I "miss" their live streams because they're a massive waste of time.

Is MM able to manipulate strategy values? And if so, how do we call/refer to them? Everything in the documentation provides examples using parts. Do you just call the ConfigNode (Am I using that term right?) as: @STRATEGY[strategyName] { @minLeastDuration = <val> } etc? Thanx.

You may be able to find similar formations on Kerbin in the deserts...

Sorry you don't have cruise control. =P

Two points: First, in my first suggestion in this thread, I suggested that exploration contracts could be offered via both methods: Offered after other bodies visited (e.g. Minmus can be offered after the Mun is 'explored', or whatever the criteria is) AND when the SoI is breached. Second, "entering the SoI" isn't an explore contract criterion. The bolded part of your statement isn't part of the explore contracts (or at least it wasn't last time I checked, I've barely touched 0.90). The criteria are typically: orbit, return or transmit orbital science, land, return or transmit surface science. Yes, in my suggestion, you would need to go back to the Space Center to accept the newly offered contract, but you would certainly not have to leave the SoI to get the contract, then leave it and re-enter it. You would transmit science and make orbit after you accept the contract. I guess going back to the space center could be seen as a bit of a hassle, but that could be ameliorated with a dialog window/button in the alert you would get when the contract gets offered. However, again, I'm trying to minimize the coding for the devs, since that seems to make them krap their pants. Edit: Nvm the first point, you qualified entering the SoI "out of order". No need for it.

As an addendum to this, rover's need their own throttle control. We don't need to hold down Shift to keep the engines firing, so we shouldn't need to hold down any key to keep the wheels rolling. Rovers should just have a throttle that work like main engines do, because they work like main engines. If there's an issue with between main throttle control and a more "docking style" approach (holding down a key to fire RCS engines), then let us toggle between them. Basically, There should be a dedicated rover control mode. Actually, thinking about it more, I think having a rover throttle than set wheel speed would go a long way to end problems with rovers going too fast, because you wouldn't have to control speed by how frequently you press the key, or how long you hold it.

I think it depends on what you're comparing it too. In the larger picture, you could say Minecraft's graphics are "outdated", but still perfect. There's also the issue that more complicated models or higher resolution textures would further press an already limited RAM limit. I think the models and textures are fine compared to modern games, because they do what they need to do: Allow the player to differentiate various parts without requiring too high a floor for graphics cards. However, the water looks like crap and Kerbin needs clouds and cities. Those omissions make it "outdated".

Eh, I think this is pretty iffy. No other contracts give you credit for what you've done previously (Though explore contracts should be considered separate contract type). If you just offer the contract before you have the opportunity to perform any of the actions in the liste (e.g. enter orbit, transmit science), it avoids the problem with credit for previous actions. At this point (i.e. the next release is 'full release'), I worry about the "special kind of contracts" needing to be programmed in, whereas adding criteria to force the contract to be offered (could be triggered at SoI shifts) would, I expect, require less novel code. Just a different opinion.

I feel like there's a happy medium here. First, "Explore X" missions can pop-up whenever they do now. That allows the contract system to 'nudge' novice players as to what planets to explore next, which is part of the purpose of the system, from what I understand. However, when you enter the SoI of a new body for which you don't have an explore contract, you should get a notification (like a contract completed notification) that you've been offered a new exploration contract for the planet of moon you've just approached. The game would basically be forced to offer the contract if it wasn't already on the list. This way, the contract can show up on it's own, but the contracts are permanently LOST if you skip around how you explore the system (which total krap). It also doesn't make the achievements "automatic", so you still have some degree of agency about taking the contracts, which isn't important from a "game play" point of view, but it helps people keep track of things, in that they are selecting the contract, and are being made aware of the contract in game. Anyway, I agree that the current implementation of the explore contracts is frakking stupid.

Buy some of their overpriced merch if you want to send more $€£¥ their way.

No. I'm frankly tired of posters coming, belittling others suggestions and holding their own opinions up as being more valid than others. I've already addressed changing the term "navigation" in this thread. Thanks for reminding me why it's a waste of time to post ideas in these forums: My opinion is different than a moderator's opinion, so my idea is invalid. I guess it's time to start editing my posts without consent and handing out reprimands. So you have three opinions on who should provide orbital data: pilots, engineers, and scientists. I guess the only valid one is pilots, because that's just what it's supposed to be, huh? </sarcasm> I guess Bob and I need to sit in the back and learn to stay in our lane.

The first part is just plain wrong. IRL, the navigator is practically never the pilot, and the only time the pilot would perform navigation is if there were literally no-one else to do it, e.g. a one man crew or a very small crew where the other members have something much more pressing to do. A space vessel would be like a naval vessel, with one person reckoning location and course (the navigator) and one person setting heading and managing attitude (the Pilot, or helmsman). Or you know what, they could work this way, and it would be a good game mechanic to spread duties through crew members and encourage diverse crews. As far as the last part, Harvester has beat us over the head with how "time based mechanics" ain't never happening, so it's not really a valid alternate suggestion. The scientists already buff science transmissions and returns. - - - Updated - - - This isn't shoe-horning in navigation. It's a way giving the player important information they need (as delineated in the OP). This isn't shoe-horning anything any more than having engineers provide dV. Additionally: If this weren't a game, this may have been a valid point. It is a game, and hence, invalid. It's further invalidated by the fact that it's simply not a pilot task.

I'm curious why you think scientists don't need an in-flight utility, they're useless on missions where science collection isn't a priority. Pilots already have an ability, I'm not sure why you think they need more. Besides, the situations are needed for science collection. If it's clear that navigation is needed as an in-flight utility and scientists don't have one, then it seems a clear choice to add it to them. Yes, everything I'm describing is already done by mods. The point of this subforum is suggestions for stock. And if "Navigation" isn't the perfect term for what you think I'm describing, so what? again, the central idea is clear: Orbital data from scientists. Don't derail the thread.

I appreciate the feedback, but I think what you're proposing would be incredibly problematic for a number of reasons. First, what I'm suggesting merely displays data that is already tracked in the game. What you've described would require a ton of programming to build a system to generate those suggestions. I really doubt Squad would pursue this suggestion due to the work that would need to start from scratch this 'close' to release. Second, there are tons of ways to make burns to get the same result. If the stock game started suggesting one, it'd become the "right" way to do something and would cause problems in the community about how the game is making suggestions. Finally, IMO "suggesting nodes" is too similar to the game playing itself. There's little to no need for that function if the game has appropriate tutorials, while the information I've listed desperately needed in the stock game. I'm not going to debate this further, since it goes way beyond what I've suggested. If you want to suggest scientists can 'suggest' nodes, please pursue it in a separate thread. I'd prefer this thread not get derailed with a suggestion that's so far from the OP.

So, pilots activate SAS and various automatic headings, Engineers can repair parts and will soon be able to calculate dV for vessels. Scientists provide science bonuses for collection and transmission, but overall lack an "in-flight" utility. Scientists excel in observing the physical world around them, and using these skills could be very useful for informing spaceflight. Currently, there's no stock displays for condition, biomes, and orbital parameters. Scientists could provide this information in a manner similar to the way engineers may provide dV information in the future. A proposed level advancement for scientists, by level: [table=width: 400] [tr] [td]Level[/td] [td]Ability[/td] [td]Examples*[/td] [/tr] [tr] [td]1[/td] [td]Orbital "condition"*[/td] [td]In flight Suborbital Low orbit[/td] [/tr] [tr] [td]2[/td] [td]Biome[/td] [td]Desert Highlands Midland crater[/td] [/tr] [tr] [td]3[/td] [td]Basic orbital parameters[/td] [td]Pe/Ap Inclination Eccentricity[/td] [/tr] [tr] [td]4[/td] [td]Adv. orbital parameters[/td] [td]Anomalies & arguments[/td] [/tr] [tr] [td]5[/td] [td]None[/td] [td]None[/td] [/tr] [/table] *Data viewable in flight view The idea here is to provide useful data in the flight view that is currently unavailable (like argument of the AN), requires changing views (Pe/Ap in map view), or using instrumentation/reports (situation/biome) that need to be ditched afterwards. Some of this data is particularly important for some missions, e.g. satellite placement, but is currently unavailable in the stock game, which is absurd. The first and second level information could be combined into second level if the devs feel like it's important for 1st level scientists to be useless like they are now. The "justification" for the advancement is scientists gaining more experience observing the planets and learning to use stellar navigation to determine the values of the more advanced values (orbital parameters). The system is 'gamified' by gating the information that can be displayed by level. I understand that they tweeted we're getting "more knowledgeable" scientists, but I think this could also be a useful addition to the scientists, especially on missions that aren't specifically for gathering science. The various abilities could also be added to science parts (e.g. basic orbital parameters provided to the gravioli detector) similar to the manner that pilot abilities have been added to the various probe cores.

At a glance, I'd recommend moving CoL and CoM closer together. Also, Pre-0.25 I had luck with increasing the amount of SAS torque on the vessel to maintain attitude. It's a bit of a "brute force" solution, but it works. At least it used to, I simply haven't played enough past 0.25 to state for sure if this is still a functional solultion.

Well, to address this in the same tone of the post: You may want to start caring about what a Hohmann transfer is if you want to start going interplanetary. Doing the math yourself is probably the best because you're going to understand the basics of what has to occur to make the transfer effective. You're also probably going to learn why launching at day 60 is a bad idea, but I'll explain it anyway: Launching at day 60, which is way too early, will get the vessel to Duna's orbit ahead of Duna. To make that transfer work, you have to go well above Duna's orbit and linger there until Duna catches up, and catch the planet as you fall back towards the Sun. To launch in the appropriate ejection to get above Duna's orbit, I really think the "34 deg from retrograde" location marked on AlexinTokyo's image.