Dib

The problem I think you're trying to get at is you want to be able to calculate the value of Max Q on a given rocket flight upfront, as "what is the Max Q at various speeds" is a question that makes no sense (the answer is to that specific question is always set the altitude to 0 for maximum atmospheric pressure, resulting in the highest Q for every speed. Not very useful). This is a problem that has more variables than just pressure and velocity though, as pressure and velocity themselves in a rocket flight are directly dependent on the rocket's TWR, atmospheric drag coefficient and flight profile. For instance, if you take a rocket straight up on a suborbital trajectory, you will exit the thicker portion of the atmosphere at a relatively low velocity. This will inevitably result in a lower Max Q on that flight than if you take the same rocket and fly it on an orbital trajectory using a gravity turn, where you'll see significantly more velocity at the same altitudes throughout the flight, resulting in a higher Max Q at some point during that flight than the highest Q you saw during the suborbital flight. I don't have the time right now to try and figure out the math behind that calculation. The simplest way I can imagine it happening is that you'd have to determine the overall flight profile you want to fly in advance, then discretely integrate the TWR (determined by engines, staging and time), drag component (determined by drag coefficient, current speed and altitude) and gravity loss (based on angle of thrust versus ground, determined by current altitude and flight profile) over time to determine the speed of the rocket throughout the flight, creating a speed vs altitude graph in the process. Then you would apply the dynamic pressure calculation on the speed vs altitude graph to create a dynamic pressure versus altitude graph, and finally search for the peak value of dynamic pressure on said graph. And you would have to do this for every flight profile of every rocket design if you wanted to know them all.

Recently I've taken to trying to be a little more intelligent about launching into inclined orbits so as not to waste precious delta v in orbit doing a plane change burn, but I didn't want to just eyeball it. After some searching around the internet I wasn't able to find any mathematical solutions to the problem posted publicly, so I spent a few hours taking some basic measurements using Minmus and worked out the algorithm needed to figure out at what time you need to launch to align with the ascending node of an arbitrary positioned inclined orbit on any given day in a year from Kerbin, and I thought I'd share it. I haven't gotten around to testing if the "orbital parameters" given in rescue missions and satellite launch contracts are actually accurate or just arbitrary, but I suspect they may be real and this algorithm can help you time your launches for those missions. If you just want a very basic calculator to do the job, copy the spreadsheet linked into your own spreadsheet processor program and modify the target's longitude of ascending node through Kerbin's equatorial plane, as well as the day and year of launch. Do note the accuracy might fall off the further in years you go (I don't have very good yearly correction yet, so I need to simulate a test universe and get some 100+ year Minmus measurements first), so it's only useful for the first few decades until I or someone else increase the measurement accuracy of one particular value. Remember to launch a couple minutes early to account for Kerbin rotation during launch, unless you use hyperedit you won't reach your target orbit instantly and you're still rotating with Kerbin during the launch). For some math stuff, read on, though note that I am not outright assuming the reader knows all the relevant orbital mechanics along the way and do a bit of explaining where I feel necessary, which may or may not be enough. Disclaimers: Although I think the current values will remain accurate for the long term, there's a simulation error I have to account for and I don't yet know if the error per year is constant (which I'm assuming it is for now), or if it varies year by year in random directions (forward in time or backward). I'll update the spreadsheet once I've collected more measurement data later, but years 1 and 2 should be pretty spot on at least :P. Also, don't try to calculate something for day 426, it's a "day" that only lasts 30 minutes or so, so I didn't feel like adding more complexity for that one corner case. Also, using this document or any knowledge gained from this post does not make me liable for any rockets you blow up https://docs.google.com/spreadsheets/d/1jBTy8BPa9WdoNE20Un85TGO5uIlvXiM05Rlz0nE4BM4/edit?usp=sharing To solve the problem of when to time the launch, we need some basic information about Kerbin's coordinate systems that isn't apparent at first glance. If we load up a spacecraft on the launchpad and use Kerbal Engineer to view our surface information, we can see that the launchpad has a Kerbin longitude of approximately 74.5753 degrees. We need a reference body orbiting Kerbin to compare this with, and the only default body to work with is Minmus (the Mun has no inclination, and is therefore USELESS!). We as a proper space institution have gone to the astronomers and asked them for Minmus's orbital parameters (read "data miners posting the information on the wiki"), and they told us that Minmus has a longitude of ascending node of 78 degrees, or in Kerbalspeak if Minmus was a ship it would have a Kerbin ascending node cutting through Kerbin's equatorial plane located at 78 degrees longitude. But what's important to understand here is that even though it's specified as a longitude, it is a "Stellar Longitude", not a "Kerbin Longitude". If you think about it, the point through which Minmus ascends through the crossing of Kerbin's equatorial plane is fixed at a point of space relative to Kerbin, while Kerbin itself is rotating. Therefore we need a relatively stationary reference point outside of the solar system in order to accurately record the position of the ascending node, which we call the "Vernal Equinox". In the real world we typically use a relatively stationary star a long distance from the Earth to indicate the direction of the vernal equinox, but in KSP this is simply the X-axis direction in the simulation's universal coordinate system. From the closest point on the surface at any given time, the Kerbin longitude of Minmus's longitude of ascending node is constantly decreasing because Kerbin rotates counter clockwise as viewed from the Northern hemisphere, making one full sweep through all longitudes at a rate of approximately once per day. So if we know that the Kerbin longitude of Minmus's longitude of ascending node is constantly decreasing in a fixed and predictable way, then all we have to do is wait for it to match the launchpad's Kerbin longitude, and then we'll be perfectly aligned for a launch. But we need an initial condition where we know with certainty exactly where Minmus's longitude of ascending node is in terms of Kerbin longitude a known time in order to run the clock forward and calculate the launch window. So for this bit, I played astronomer and used Kerbal Engineer to find a few reference values. The "real" Kerbin astronomers (wiki) have told us that Minmus has an inclination of exactly 6 degrees, so to find the time Minmus's ascending node passes over the launchpad, we have to wait for our vehicle on the launchpad to have a relative inclination to Minmus of exactly 6 degrees, while the craft moves through it's decending node through Minmus's plane of orbit. A few times at which these conditions hold true are approximately year 1 day 1 01:01:29, year 1 day 8 00:55:35, year 2 day 8 00:55:40, and year 2 day 301 02:47:51. So now we need to know the rate at which Minmus's longitude of ascending node decreases in terms of Kerbin longitude over time. There are a few factors involved here: First, Kerbin's rotation. A single Kerbin day takes a total of 21600 seconds. So 21600 seconds divided by 360 degrees, or 1 degree per 60 seconds. Second: Orbital motion correction. A single Kerbin day measures how long it takes for Kerbin's sun (Kerbol) to reach the same position in the sky, but because Kerbin is orbiting Kerbol, if Kerbin had no actual stellar rotation then we would observe one day per year with Kerbol moving backwards through the sky. Therefore we have to subtract one day per year's worth of rotation from Kerbin's rotation. Third, yearly procession. I assume that mathematically if exactly one Kerbin year passes we should get the exact same rocket launch windows as the previous year, but due to limitations in simulation precision, when we take data from year 1 day 8 00:55:35 and year 1 day 8 00:55:40 there's a drift of approximately 5 seconds per year that needs to be corrected for. This is the roughest measurement I've collected so far at the time of this writing, because I need to extend the simulation time much further to get a more accurate procession value or if it's even a constant per year, so for now the linked calculator's accuracy is limited to a few decades at most. Finally, if you account for all those factors, there's still an error on the order of 0.0128 planet rotations per year. I haven't pinned down what's causing that yet, I'm sure it's something simple and stupid I missed, but I'm blindly adjusting for it at the moment. I first thought it had something to do with the Kerbin year not aligning exactly on the boundary of a Kerbin day, but the amount of error I'm seeing doesn't match the error from cutting out the extra 32m 24.6s. Something for me to think about later. Combining all four factors yields the rotation speed of Kerbin from the stellar reference frame. So if we take the now known rotation of the planet in the stellar reference and run time backwards from our first Minmus measurement, we can compute that Kerbin had rotated by 61.4847 degrees from the time of the Kerbin epoch Year 1 Day 1 00:00:00. We also know that the launchpad was at stellar longitude 78 degrees at the time of that measurement, and the launchpad always has a Kerbin longitude of 74.5753 degrees. Putting the pieces of data together, the Kerbin longitude of the Vernal Equinox at Kerbin's Epoch is therefore 58.0600 degrees, and the launchpad's position in terms of stellar longitude at the time of the epoch was 16.5153 degrees. Now we have all the pieces we need to compute our launch windows, because we have the stellar longitude of the launchpad at the epoch, and we have the rotation speed of the planet. I won't go into too much detail about how the algorithm itself was constructed because it's pretty basic and I don't hide the calculations in the document, so if you generally followed the explanation above then it shouldn't be too hard to follow what it's doing. One thing to note is the document bases its calculations by the percentage of how far the planet has rotates per unit time of day and applies orbital corrections after the fact, rather than just multiplying time by the true stellar rotation speed directly. If you want to let the user specify any particular day in the year to perform the calculation on, this method is a bit easier to design around. The algorithm will first figure out what the launch window time should have been for the first day of the year using the difference between the launchpad's longitude and the target's longitude at epoch, and then will apply the corrections for Kerbin's orbit around Kerbol based on the year/day given.

Dream Chaser's been publicly in development by Sierra Nevada Corporation for awhile now. It competed as part of Nasa's Commercial Crew Transport Capabilities program, but was eventually dropped in favor of the Dragon V2 and Dreamliner offers from SpaceX and Boeing. This didn't stop SNC from continuing development on their own however, and although subject to delay its initial unmanned test flight is planned for November 2016, launching from Kennedy Space Center on top of an Atlas V rocket. The cargo version of Dream Chaser has already won a NASA contract through the Commercial Resupply Services 2 program (CRS-2), and is guaranteed a minimum of six flights booked for the program. It's mainly a bit cuter smaller, has fold-able wings for fitting inside a payload fairing on ascent, and has something akin to a "trailer" that burns up on re-entry. So that version at least will certainly fly, though time will tell if the crewed version ever sees the light of day.