EatVacuum

If you limited each experiment to one transmission per biome per mission but the points generated were always the same percentage of the max, maybe adjusted upwards a bit to balance, it could allow you to a reasonable amount of science for a lot less clicking. I'm also not fond of the diminishing rate of return, in the RW sometimes early experiments reveal less data but open up possibilities - more questions or more theories to test. The classic example is the last moon mission - a single rock picked up by Shmitt, a geologist, answered more questions about the age and formation of the moon than all of the rocks gathered on previous missions. Hmmm, this situation might be a better argument for the "breakthrough" idea previously mentioned than for my own. I'd love to have seen a science system where doing science generated ideas for new experiments. The science bay could just be a container for carrying the experiments to where you can execute them. The results would be the usual science points plus new experiments until you reach tthe end of the chain for each biome. Hmmm, I wonder if this could be modded... Lastly, you should be able to transfer science between docked vehicles. Right now you can't do the Apollo style command module + lander missions. You have to bring the lander back to get the science home. :-(

There is only one right way to play KSP and that is my way! Kidding... but there really is only one way and that is the way that you find fun. I'm not trying to force my choices on anyone, I am trying to provoke a positive and meaningful discussion in the hopes that if many people agree with me, then someone from Squad will see that there is a general opinion that things should change and they will take note. And if this discussion causes a different consensus of what is fun or what the community would like to see, they may convince me, but whether or not I agree, perhaps the game will improve as far as the larger community wants it to. I made the comment that my post was meant as an attempt at constructive discussion, not criticism of KSP or Squad. I kind of resent that you are accusing me of "forcing my opinions on anyone else". That kind of comment is exactly what I hoped to avoid, I've seen too many vituperative comments ruin what should be a positive exchange of ideas. If you don't like an idea, don't just nay say it or attack the originator, suggest a better one. But for anyone else who would like to see the science process in KSP get even better, what are your comments?

Agreed. It makes sense to start with just a probe and the other limited parts rather than a capsule. It's not like you can't earn your first advance or two by just walking around the space centre reporting and sampling anyway, so those who want a capsule could get one quickly. To my mind, some other things make even less sense. Like the fact I can get all of the necessary parts to build a high performance jet from the Tier 5 Aerodynamics tech node... but wait, the small gear bay is in a different, otherwise almost useless Tier Five box that has those and the (to my mind) almost useless tiny landing legs. I actually built a plane before I noticed them missing, and even tried launching it using girders as skids! Finally got it into the air using JATO (seperatrons for lack of a better small rocket). And don't even talk to me about ladders! How the <expletive deleted> can a frakkin' ladder be in Tier 6? So much for landing a plane and collecting samples 'til I'm most of the way through the tech tree... or doing EVA's on any planet.

I both love and hate the new science. I love that it has given me a whole new reason to play the game, and to go back to stock parts and flying missions that had long become boring. There's a reason to go out there again other than to test new ship designs. I even love the implementation of the science devices, with only a few minor complaints. But I absolutely HATE HATE HATE HATE HATE HATE HATE (repeat a dozen more times) the repetitious spamming of the "do research", transmit it, wait for batteries to power up and do it again for slightly less gain until eventually, a fraction of a point at a time you finally milk every last science point out of each experiment you are carrying in each biome. I actually got sick to death at somewhere around experiment 70 or 80 of my trip to Minmus. I had to shut the game down and walk away. Grindy is not fun! The fact that you can keep spamming and transmitting takes away the value of actually bringing the experiments back home. Why bother when you can transmit the same lab experiment 20+ times and actually get more than what you earn from the sampel you carefully carry back to Kerbin? The way science works, especially for probes is pretty straightforward - you design an experiment to test a theory or analysis a material or behaviour. You conduct the experiment. You analyse the results and design a new experiment and try again. And there isn't much you can do to redesign an experiment when it is a few million miles away on a probe, although it has probably been done in very limited fashion. Repeating the same experiment 30 times is only needed when you are doing statistical sampling. There should be limit to how many times you can use a science part on a mission - probably only once or twice each per mission for the materials experiment since you'd use up the supplies. But something like the thermometer and maybe the goo should be useable once per biome per mission. Transmission home should be a way of ensuring something gets back in case the mission ends horribly, or if it is a one-way probe. And, if you transmit data home, you should still have the experiment (unless you reset it) onboard and should be able to get the remaining points (up to the original 100% value of the single experiment) if and when you get it home. And only get points for transmitting once per experiment. If however you carry two Science Juniors then presumably you would have them set up for different experiments and so could transmit once each and/or bring home once each. And lastly, while our current space programs (pitiful as they are compared to the grand old days of Apollo) are almost entirely based around sending out robots to anywhere more than 400km up, boots on ground should be more effective than sending out pitifully limited robots to do research. Not to undersell the results of Spirit, Curiosity and others, but the reality is that a few well trained humans on Mars could have done more in a weekend than once accomplished by most of the robots sent to date. I'm sure that last statement will generate some hostile response, and it may be a bit of an exaggeration. But the main value of sending many probes or rovers vs. one manned mission is purely that you can land in more places. To prove my point about having properly trained humans on site, one rock (Troctolite 76535) picked up by an Apollo Astronaut (Harrison Schmit, a trained geologist) probably answered more questions about the formation of the moon than all of the other rocks brought back combined, human or probe collected. If he hadn't been there and decided to scoop it up because it looked a little different to him, then a lot of "science" would have been lost. I love what Squad has done with the game, so take this not as a scathing criticism, but as a constructive one in the hopes of making what is already great even better. I invite other to make their positive comments in the same spirit, but flamers need not apply

Agreed, but I'll add my comments about what I find really annoying in my own post in a bit. Don't stop the transmission. Don't quote me on this, but it seems science is sent back in data packets. I gave gotten the "not enough power" warning, but then shortly after as the power level came up, it seemed to keep transmitting and I got science points. It should require less power, at least when you are close to Kerbin, but more the farther out you get. And anyway, solar panels are way over powered in KSP so gaining it is not a problem, just add a few batteries to every mission and viola, it's fixed. The tech improvements for communications should be about making more sensitive detectors back at KSC (or in orbiting satellites) rather than needing more power at source. Presumably there are severe limits on the amount of memory available for storing data (i.e. reports), there certainly were in real life until well after the Apollo missions. But reports can be transmitted without loss, if you have the power. If you are talking samples in the sense of soil samples, then there are (still) definite weight considerations. Only a few hundred kilograms of rocks came back from the six moon landing missions, and the amounts brought back by the Luna probes is measured in grams. I'd agree if I had yet had that problem. My problem has been trying to figure out how to get a data out of some of the old science parts when I used it unnecessarily. The only way I've found to free up a thermometer is to transmit the data, and unlike the new devices, you can't even do that from the device. And try and find the tiny little antenna on a big rocket that's on the dark side of a planet! <Additional Edit> - I did another run to a Mun crater and discovered what I think might be a major loss of data... if you tell an science device or the capsule to transmit another experiment home before the transmission antenna has completely finished it's "close" animation (and 1 suspect for at least a second after it stops obviously moving), it seems to me like your stored data goes away and there doesn't seem to be a report of data sent. And I've tried it a couple of times, so I'm sure this is happening to me. Anyone else? Also, on rereading your post, are you sure you are not transmitting it? Or running the experiment multiple times and not transmitting it home before redoing? Each device seems to store only one result, and each Kerbal can only carry one eva report and one sample at a time. Similarly the capsule can only store one each of eva reports and soil samples from a single biome at a time - it won't let a Kerbal reboard who is carrying a duplicate of a report/sample already stored - and it does warn you and you have to dump it to get in. Next time check your science count at the start of the mission and add up the value of the science you do during the mission. Then when you get back, before recovering your craft, check it again and see if you got the transmitted science value increase, if any. And only then, recover the vehicle and see if the science score goes up again. If you are absolutely not getting any data, then it must be something you are doing because it seems to work for the rest of us, once we figure out how we should be getting and delivering the science. The better you can document the problem, the easier it will be for us to suggest possible mistakes you are making, or if it is an actual bug, for the devs to analyse it.

Don't need it personally. My rate of design failures and staging screwups more than makes up for it. But seriously, I was hoping that R&D would be about not just getting new parts but about improving existing. Do you go with the old reliable rocket engine you've had for years or put in a new, more efficient but untried one would be an interesting design decision. Random failures would make it worthwhile to have escape systems that aren't needed now. Other than the useful but unrealisticl revert to launch and F9 options of course. On the main discussion point though, implementing a drag model where the cross section of what was pushing through the air and the aerodynamic design of the parts, especially those at the front and back of the rocket would go a long way to eliminating asparagus staging. In KSP a really long thin rocket is harder to control than a short stubby thick one. Not sure that is so in the real world. It is easier to vertically balance a long thin pool cue or broom on your finger than it is a coke can or a ball. But as it is the game mechanics actually seem to favour it. Not to mention the height of the VAB being a problem if you go too tall.

It comes in when the mod maker puts in the two lines of code needed to add each part into the tech tree. Or when you do. Or you can add the mechjeb core to the stock parts. Instructions on how to put the mod parts in the tech tree are posted on reddit and here in the forums. Try this link http://forum.kerbalspaceprogram.com/threads/53328-ksp-22-and-mods But better, check spaceport and the addons support forums as (at least for the mods whose devs are active) .22 versions are being posted daily. I can attest that the mechjeb version I was running a month ago under .21 works fine under .22 at least for me. Hope this helps

Jet engines are useful for regular rockets, not just space planes, but you have to consider the gains vs. the losses. For a "straight up" rocket, they are maybe less useful than they are for something that spends it's time in atmosphere, but you have to consider a couple of things other than raw thrust. Take a look at a couple of stats comparing the jet engine with a close equivalent, say the LV-T45 engine (data taken from their configs); Jet Engine - maxThrust = 150 PROPELLANT { name = LiquidFuel ratio = 1 DrawGauge = True } PROPELLANT { name = IntakeAir ratio = 15 } atmosphereCurve { key = 0 1000 key = 0.3 1800 key = 1 2000 } LV-T45 - maxThrust = 200 PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 370 key = 1 320 } The LV-T45 does have 1/3 more thrust (200 vs. 150), but look at the numbers for atmosphere curve - the numbers that are bolded are the Isp at various altitudes (well atmospheric pressures really). For those not familiar with the config files, the first number after "key = " is the atmospheric pressure, the second is the Isp. So at sea level the jet has an Isp of 2000 vs. the rocket's 320. At zero pressure, the rocket has moved up to 370, and the jet is (theoretically) down to 1000. Theoretically because of course the jet will flameout before it gets to vacuum. Since Isp is your "miles per gallon" it would seem that the jet engine gets somewhere between approximately 2.5 and 6.5 times as far on a tank of gas. But, it's actually way better than that - the rocket engine burns fuel and liquid oxygen in about a 9 to 11 ratio, and it has to carry both of them. The jet burns fuel and intake air - and in a 1 to 15 ratio, and it only has to carry the fuel - the air is free (well, you have to have an intake or two). So at sea level for the expenditure of 1 fuel and 15 free intake it generates (1+15 times 2000 =) 32,000 units of thrust. Burning the same amount of carried combined fuel and oxidizer (0.9 fuel + 1.1 liquid oxygen, halved) you get 160 units of thrust. At the (theoretical for the jet) vacuum pressure, the numbers would be 16,000 vs. a whopping 185 units of thrust. So the weight saved using jet fuel to get you your first 600m/s of velocity and 17-18km of altitude (doable with a couple of intakes per engine) is not inconsiderable. The jet fuel expenditure is so low, you probably only need one tank of jet fuel for a handful of jets used as boosters for your rocket. In a "straight up" flight profile, what you need to do is decide if the weight of fuel saved is worth the extra parts - the weight of the jet engine isn't a concern if you are jettisoning it like a used booster. For a space plane or some other form of SSTO, the weight is a consideration. But for a space plane, your ascent profile is designed (or it should be) to get you to 20km and 1000m/s before you switch over to rockets, and you will spend a lot more time getting there, so the fuel savings are greater. But, what if you could keep using the same engine in both air breathing (i.e. jet) and closed cycle (rocket) modes and get the advantages of both? That is the idea behind the Reaction Engines Sabre engine that is in development (http://www.reactionengines.co.uk/sabre_howworks.html). At this point I would put a shameless plugin for an addon I'm involved with, but since I'm not sure when it (if?) it will get done, I'll instead direct you to the B9 Aerospace pack. Buried in the dozens of other parts and pieces are a 1.25m and a 2.5m Sabre jet engine, so if you are one for playing with add ons, it could be the best of both worlds for you.

Here is a good start - an addon that shows you what experiments you have done, how much science you have earned, and how much remains that you can earn by repeating the experiment... http://kerbalspaceprogram.com/rdoverview/ It does not show you every experiment possible, only the ones you have done. But I kind of like that - knowing everything I can do to get science points would be a huge spoiler. I am happy to keep trying new things, clicking on every part to see if there are science possibilities, carrying experiments to new places to see what pops up. If you want the full list, I'm sure it will get produced at some point, but in the meantime this addon is really useful to help figure out what you have done, and what remains to be done for the experiments you have tried.

Please remember that when you bought KSP it was sold to you as early access. Right on the KSP site they state "The game is currently under heavy development. This means the game will be improved on a regular basis, so be sure to check back for new updates". And then there is the terms of service... "Please keep in mind: Squad is not under any obligation to release any updates, expansions or titles at any time. Each release may very well be the last one. Squad is under no obligation to implement any given set of features prior to the final release for KSP or any future title. All posted lists of planned features are unofficial and do not imply a promise by Squad to deliver anything listed in them. Squad reserves the right to add, remove and modify content on any of its software at their own discretion, without prior notice. Squad is under no obligation to maintain any level of communication with the player community, choosing to do so at their own discretion. The minimum hardware specifications are posted for reference purposes only. KSP is a work-in-progress, and as such, may not perform as expected under any given hardware configuration. The Software is made available as-is, and may contain bugs and/or manifest undesirable behaviour. Squad does not guarantee any level of stability or performance for the Software, and takes no responsibility in the event of data loss or damage ocurred as a direct or indirect result of using the software. Use at your own risk." You got the game for a fraction of what it will cost when it is complete and polished, you are in effect being the play testers for Squad. If you can't deal with it then go away and come back when they have put out the final version and then you will have the final product, and still have got it at a discount. Or, you can play with it for now and send in your occasional dump files and post up what you see as the problems with the game, which I sure the devs will read and in most cases will action. But please people, do it in a positive and mature fashion. Whining over some issue and calling it "laughingly stupid" is not helping. Report it as an issue, describe what you see as the problem and suggest how you think it could be done better. And if it makes sense and a lot of people agree, then the devs will almost certainly pay attention. Please be respectful of both the developer's efforts and of other people's wants and opinions. If you can do that, I (and probably the developers) will find it a lot easier to respect YOUR opinions. If everyone can do that, this forum will be a lot more pleasant to visit.

Treat it just like any other plugin. I copied the "ScienceLog" folder into ...\Kerbal Space Program\GameData and it came up fine.

The only thing hard is not having a clue what to do. But just go out and try doing stuff. MINOR SPOILER - You can buy a couple of advances with the science you can get without even launching a rocket. You can do a crew report and eva report by putting a capsule on the launch pad and then having the Kerbal get out. Walk down to the grass next to the launchpad and collect a soil sample and that's more science points. I gues you could walk down to the sea and collect another eva report because it is a different biome.

Maybe because EA and Rockstar are companies worth hundreds of millions of dollars and can afford big server farms and Squad is a little indie company who can't? Boohoo, so you have wait a little longer for such a great game. Your sense of entitlement is amazing. You should be thanking Squad for doing such a great job, not griping if you can't get it in fifteen minutes or less. Oops - this was in reply to someone whining about the first day download slowdown, but the quote went missing. Still, great job Squad. Illegitimi non carborundum!* * Don't let the bastards grind you down!

I've cobbled together a "good enough" 1.25m Sabre engine model to play with while Cpt. Kipard works on the real models; no intake animation on close/open and standard rocket fx. And with that I have been working on the Sabre engine; getting a better understanding of config files through experimentation and rewrites, fine tuning the performance to get it to as realistic a flight profile as possible, and lots of test flights of course. Here's my test plane and engines - I should have had the logo run along the side of the engine rather than around the circumference. I'm not expecting this to be the final look (that is in the modeller's hands) but I needed to differentiate my test Sabre from the one in the B9 pack which I've also been test flying for comparison. The widening of the engine from front to rear is a pain for putting onto planes built on 1.25m fuselage and the stock landing gear - the things tend to scrape the runway on take off. This won't be a problem with Skylon though as the fuselage is proportionately much bigger because of the low density of LH2 fuel and resultant high volume needed. But it could be for people who want to reuse the part. Right now I'm still using the LACE model (Liquid Air Cycle Engine - i.e. using a modded intake to produce oxidizer from intake air and an engine that really only works in rocket mode) for testing. But I've been looking at the creative commons license B9 is packaged with and while I'd like to get a confirmation from Careo or Bac9 (and if either of you read this, let me know if you mind please), I think that as long as we give due credit we can use the Exurgent Engineering .dll to get the true open/closed cycle mechanism. If not, I guess it's a crash course in C# programming for me. And, another idea I've been having - after doing all the research on Sabre, LACE,turborockets, scramjets, ramjets, ramrockets, air augmented solid fuel boosters and so on for this project, I have a hankering to make an add-on pack with all of those variations of engines. I've had little luck with Eve landers so far and air augmented rockets would work great on Eve. You'd need oxidizer but making use of that atmosphere as additional working mass will still result in higher ISP than conventional rockets. But that can wait until this project is done.

I'm just thinking that complete sections with oxidizer and (whichever) fuel we go with would be more reusable than giving them a tank with fuel only, especially if the oxidizer is in the cargo bay section. That was why I was also thinking of providing liquid fuel plus oxidizer versions even if I do figure out the hydrogen resource thing - more reusability. Also - Design conversation in the forum is good because it gives us useful feedback from interested players. But I'm thinking we should have a contact channel other than going through the forum, both in case it goes down again and to allow us to exchange our WIP files at some point. I'll need parts to be able to validate the configs, and you'll need the vice versa. And if we end up having to get someone else to import your parts into Unity, they will as well. Speaking of, I did spend time trying to get a sample part into Unity and there is some learning curve, I haven't gotten it right yet, I guess it's more tutorial watching for me.

Now that the forum is back, I have a few thoughts about the parts list and earlier comments; I think this list is good, but a couple of thoughts. Some people will want this as a kit to fly a realistic Skylon, but it would be a bonus if the parts were also useful for building other craft. You're making a start on that by going with one of the existing part diameters rather than going with the exact 64% or 50% resizing. I think we should continue this a bit further - I'd like to keep the fuel and oxidizer in the same tank/part, but that said, it doesn't change where you cut the parts. How much fuel/oxidizer goes into a part is controlled by the config file, not the actual volume of the part. We also only need to reach 40% or so of real world orbital velocity to get into Kerbin orbit, so having a bit less fuel than we could won't likely be a problem and should even leave a reserve for powered landings. Another thought, related to the previous - if you cut the nose cones etc. at points where the diameters match existing diameters then it would make the parts more reusable, for instance maybe parts like the nose core can be cut off where it reaches the 1.25m or 2.5m diameter point, even if it is a bit off from the logical divisions based on function. Same thing for the orbital maneouvering system, RCS and so on. I was going to suggest splitting the engine into two rather than three, but on second thought, doing it does allow someone to use the intake and engine without having to stick to the "banana" shaped overall shape, so go with that. It would also make it easier for people to model the Lapcat, since the Scimitar engine doesn't seem to have the banana curve. With the forum down, this suggestion may have arrived too late, but if not, give it some consideration. As always though, this is largely your project, so the modelling choices are best left to the modeller. Yep, looked at the video, that and Figure 11 "Suborbital deployment..." in the Skylon user manual definitely confirm the positioning of the pitch/yaw thrusters right at the bow and stern. That leaves the roll control up for question, but making separate attachable RCS for the wings and including roll thrust in the bow and stern would allow for both options. I'll look at that for sure. Depending on when .22 comes out, we may not have to do that. If it should happen that different fuel technologies are part of the R&D tree (and I think that would be a realistic option to allow for developing more efficient engines), then we may have more options than just going with generic liquid fuel or making a custom hydrogen (Krydrogen?) resource. If not, then I should provide both options - hydrogen-based fuel tanks and generic fuel. Now a last question - what colour should we go with? The black paint scheme shown in the RE videos is appealing, but should we consider going with a paint scheme that better goes the existing common colors? I expect that once/if Skylon becomes a reality, it would sport different colors for the companies that fly it, just like airliners, since it looks like they are expecting to sell them commercially. So we don't have to be tied to what Reaction Engines is using. Any thoughts?

To quote what someone earlier said about my speculation on where to put the thrusters "That sounds suspiciously like an opinion...". I haven't come across anything stating that the fuselage is a lifting body, but if it is, we can do it. On the other hand, I did come across something that indicates that Skylon has a pretty high takeoff speed in this forum; "With a takeoff speed of M0,5 (over 250KIAS) and rocket engine like thrust, it should climb... almost like a rocket". If this is correct, at Mach 0.5 (actually 330 KIAS, knots indicated airspeed, which is about 350mph) Skylon would be going more than twice as fast as a typical airliner, or almost twice as fast as a typically combat loaded F16 at takeoff. That will go a long way to making up for the small wings. But I haven't found anything official that confirms the forum quote is correct. So if anyone can prove either of these statements, we'd appreciate you providing the source. In the meantime, in case we do need to go down that road... It's a simple change to the config file, I can probably make any KSP part into a lifting body. As proof I offer the amazing lift-cubes; all the lift of a delta wing, but much more space efficient. I hope to market them to any Kerbal nation that uses aircraft carriers or is plagued by narrow hangar doors... And in case anyone is doubting the lift is provided by the modified QBE probe cores, you will note in the SPH shot below the Centre of Lift is clearly on the cubes. The flaps are needed for flight control and the 1x1m structural panels are only there because I needed something to attach flaps to, they wouldn't go directly on the cubes.

Definitely, but there's a couple of obvious ways to do RCS, depending on the geometry of your space craft. For a relatively short shape like a sphere or a relatively stubby cylinder like an Apollo service module, you can just stick a bunch radially around the middle/waist, usually four works well because of our tendency to think up/down. left/right, forwards/backwards - it's how we define space and how our controls tend to work, from joysticks on up. Four RCS allows them to work in balanced pairs for most of the combinations of rotation and translation, except for forwards/backwards and roll where all four can be used. Something long and thin like Skylon has a higher moment of inertia (don't flame me if I'm using the wrong term, university physics was a long time ago) for yaw and pitch. So it makes sense to have sets at each end to give you more leverage to rotate the thing. Given that the Skylon is proportionately much longer and thinner than a shuttle, it's pretty much going to have to have RCS at the ends. On the other hand, those wings are stubby, so you'd think that if the Space Shuttle didn't need wing thrusters, then Skylon wouldn't either. But there's a couple of heavy engines going on the ends of those wings, which is going to increase the roll inertia, which wasn't the case for the shuttle. So I'd think that Skylon might need them after all. That's my opinion, but it's based on some consideration and analysis, your mileage may vary. It's likely that the wing RCS are going to be implemented as separate components, based on Cpt. Kipard's parts list earlier in this thread, so I guess you will have a choice in any event.

The pictures and explanation are great, that helps a lot. You just hit another big concern, those wings are tiny compared to the size. I haven't figured out exactly how lift works, but getting this thing off the ground on the existing runway might be a challenge. To add to it, KSP rocket fuel tanks are heavy foor their size, this thing (and a lot of the new rockets) are using hydrogen which is very light compared to kerosene and the other historical fuels. Compare the relative size of the Skylon's hydrogen and oxygen tanks here (expand the picture next to the "Material Construction" title) with that of the Saturn Five where the oxygen tanks are double the size of the RP-1 (Kerosene) fuel tanks, here. Admittedly part of that huge difference is because so much of the oxygen needed (about 250 tons) is used in the air-breathing stage, but you can look at other hydrogen-burning rockets to see. Note to self - in the .cfg files put in a lot less fuel than usual for the equivalent size, and also, don't use the usual 11/9 ratio. I am intrigued by the OMS system - from the description it doesn't sound like just a typical RCS system (which is generally a single propellant gas under pressure or a hypergolic mixture), sounds more like a lower thrust conventional rocket motor. The blurb describing it, found on the Skylon link above says; "Whilst in orbit the main propellant tanks are vented and allowed to warm to ambient conditions. Propulsion and attitude control are provided by the Orbital Manoeuvering System (OMS) or Reaction Control System (RCS). This uses a common LH2/LO2 propellant storage which is heavily insulated and cryogenically cooled. This system can remain operational on orbit up to 7 days. The RCS employs gaseous propellants supplied by the Gaseous Propellant Supply System (GPSS). The GPSS also supplies reactants to the fuel cells and the auxiliary power turbines." The second sentence makes it sound like the OMS and RCS are the same system, but then the third and fifth sentences imply they are separate. From the point of simulating it in KSP, I think we need to treat them as separate. It's also interesting that the main tanks are allowed to vent, it may be that only the auxillary fuel tank, which is very small, will have fuel for deorbit, unless it's cold enough up there that they still have some usable hydrogen and oxygen after it comes up to ambient temperature (and presumably vaporizes). That also implies a completely unpowered landing, which is pretty hard to do in KSP. Powered space plane landings are challenging enough. I would have thought 50% would be the scale, based on Kerbals being 1m tall, here's good ol' Bill standing next to a 1.25m tank and Jeb's Big stick (a measuring tool someone made). The thinner lines are .1m, the wider one second from the top is the 1m mark. Bill comes up to the 8th 0.1m line, but there's about .2m below the stick. So definitely 1m tall, but I guess most people aren't 2m (6'6") tall which 50% scale would make Bill if we rescaled him. But on the other hand 64% only makes him 1.56m (5'1"). I guess 64% is good, and if it seems to be the standard, it works for me. Once you have built the models we could always use scale and rescale in the configs to make 3.75M version, or even smaller. And related to your ponderings on where to put the thrusters, there is a convention described in the Wikipedia article on RCS; "Location of thrusters on spaceplanes The suborbital X-15 and a companion training aero-spacecraft, the NF-104 AST, both intended to travel to an altitude that rendered their aerodynamic control surfaces unusable, established a convention for locations for thrusters on winged vehicles not intended to dock in space; that is, those that only have attitude control thrusters. Those for pitch and yaw are located in the nose, forward of the cockpit, and replace a standard radar system. Those for roll are located at the wingtips. The X-20, which would have gone into orbit, continued this pattern." If we find out otherwise, we can correct, but I don't think we will go far wrong is you go with this as a basis. So, I am thinking the fuselage itself should break down into six components, from the bow back - small nose cone w/rcs, big forward fuel tank, cargo bay, big aft fuel tank (including RCS fuel), a thin aft tail section w/RCS, a small OMS rocket. There'd also be two more wingtip RCS units. The more I look at this, the more I realize how huge a job modelling this is going to be, what with animating the cargo bay doors, retractable under carriage etc. I guess I do have the easy part

You are right, they are different engines, a lot of shared technology but different. I'm not sure why the Sabre is curved the way it is, you'd think the airflow inside the engine would work better if it was symmetrical/straight. In any event, the geometry is going to make it challenging for you. The wings and engines do appear to be below the centre of mass, but I'm wondering if the downward tilt of the thrusters actually lines them up with the CoM. If they do, I think you are right that the Skylon will always be flying a bit nose down when it is in space. On another note, I'm a bit worried about the positioning of the wings and canard - I tried building a smaller but proportionate space plane using mostly stock parts, and with a canard that far forward, it dragged the centre of lift forward of the CoM, and that makes for an unstable plane. Of course, the stock model was only a rough approximation of the real thing but it is something I'll worry about until we can test fly. I was thinking about scale of this thing - if you build the model true to real world scale, it will be enormous, the hull will be more than 5m radius, i.e. bigger than the Nova Punch rocket parts. On the other hand the Kerblanauts are less than half the size of a human, so maybe we should consider making the scale to be proportionate to the size of the Kerbals not to conform to real world measurements? I don't want to end up with something like the Buran and Canadarm in the Robotic Arms pack - they seem to be made to real world scale and the result is the Canadarm is taller than most of my rockets. Right now I am frankly simulating Sabre by using an air intake to collect air and convert it to oxidizer. My engine is always burning oxidizer but I'll quote Aerospaceweb.org to justify this and then I'll explain the actual process; "The purpose of both the jet engine and the rocket engine is to combust a mixture of fuel and oxidizer. This combustion process generates a high-pressure exhaust that creates thrust to push a vehicle forward. The fundamental difference between the two types of engines, however, is where the oxidizer comes from." So in reality, a rocket can be thought of as a jet engine that gets it's oxidizer in liquid form, or alternately, a jet engine is just a rocket engine with a hole in the front that gets its oxidizer for free. I'm using an air intake to produce and feed oxidizer to a rocket engine. How it is done is as follows; 1) The air intake, while open takes in air and converts it to oxidizer. This is purely a game mechanic, air is oxidizer, or to be accurate air is 20% oxygen and oxygen is by definition an oxidizer. The rate is such that one intake can feed one engine up to about 22km, after which it falls rapidly behind. At that altitude you should close the intake to reduce drag since the oxidizer collected is too little to be useful. 2) The fuel feed mechanism of KSP delivers the oxidizer to where it can be used, either to the rocket motor to make thrust or to a fuel tank. 3) The rocket engine is always burning oxidizer, initially the intake provides enough but eventually it has to start using the oxidizer stored in the rocket fuel tanks. I've modified the engine's atmosphere curve to be equivalent to the Sabre's - a jet-like Isp of 3240 up to about 22km and a rocket-like Isp of 420 from 23km up, with a brief transition between the two Isps in between. A purist might point out that I'm really simulating a LACE-type engine (Liquid Air Cycle Engine), but the net effect is the same as if the air was actually being consumed directly. Sabre super cools the air to allow it to function at such height and speed, but it doesn't actually cool the air down to liquid like LACE does. If you compare the Isp and altitude numbers to those quoted for Sabre, you'll see I've cut them back by about 10%. Kerbin's atmosphere height and orbital velocities are smaller than Earth's, using the full values makes it more effective than I think it should be. I'd like to have a true jet/rocket hybrid, I've been looking at Careo's HydraEngineController which is in the B9 pack. Using it would give me a true dual mode engine, but I haven't found any licensing info for his stuff in B9 Aerospace. Until I do, I won't rip off his work, hopefully he'll be willing to let us use it in return for giving him credit.

Cpt. Kipard, I responded to your last post in the "[REQUEST] Skylon & Saber Engine - Reaction Engines Ltd" (sorry, I haven't figured out how to put in the URL to link the title to that thread), if you're good with it, I will join you here. Whether or not you agree, I do have a couple of thoughts; I'm still barely into understanding how Unity works, but I believe that the actual orientation of the models does not control how thrust, lift or drag works, they are defined by transforms that are attached to the models and which you point in an appropriate direction. If so the thrust could be offset to align with the centre of mass, I'm pretty sure that since they will have to account for that in the real Skylon, it can be achieved in KSP. If nothing else, thrust vectoring might be able to compensate. I can look into that if you like, and if so, then you can make an accurate model. But if there is anyone out there who is more familiar with Unity who can explain this, and how to do it, I'd love to know for sure. They probably haven't figured out the RCS yet, the images and videos published are promotional materials, Reaction Engines is, as the name implies, interested in building a hybrid engine. I would assume that the Skylon and LAPCAT images are just concepts to show what it could be used for. Where the thrusters will go is going to have to be based on where the Centre of Mass ends up. Some non-intrusive RCS units could be another thing to add to the list of models you'll need to build Skylon. Like the engines themselves, I'd love to have those - it offends my sense of aesthetics to make a sleek, well proportioned space plane and then have four objects that look like four-way lawn sprinklers sticking out where they would screw up the airflow. Take a look at this image - http://ca.photos.com/royalty-free-images/space-shuttle-discovery-ov-103-nose-detail-port-left-side/150495422 As you can see, on the space shuttle the thrusters are streamlined, just holes in the fuselage, not "lawn sprinklers". I'm pretty sure that's the way they'll be going for the Skylon. If you look at some design images for the shuttle it should help you to figure out where to place them. Hope this helps.

As mentioned B9 does do the Sabre engine which will hopefully one day power the Skylon, although it is a big pack to download if you only want the Sabre (70MB, 176 parts, a handful of .dlls). You can read my rather lengthy thoughts about that on a Sabre thread here - http://forum.kerbalspaceprogram.com/showthread.php/23728-REQUEST-Skylon-Saber-Engine-Reaction-Engines-Ltd?p=647091#post647091. But B9 has a lot of nice stuff so by all means get it if you have a use for all the other parts. There is also a rather nice Skylon model already produced by a guy named Lando, available on the Space port here - http://kerbalspaceprogram.com/skylon-pack/ although you should note the developer's comments about the engine still needing some work. The engine's also a bit too effective as a rocket engine, it has the same Isp as the LV-N at 1/3 the weight and with 3 times the thrust, and that Isp is almost double what the real Sabre (and any other chemical rocket) can produce. But if that doesn't bother you, his model looks pretty nice.

I'm not a big fan of doing all sorts of math to figure out the launch angles but I do use two tools. First is a phase angle chart that is out there. The second is the Alarm clock addon. It can be programmed to tell you when a transfer window is coming; I like to leave myself a day's warning. When that pops up I launch my ship and while I wait for the window, I use the maneouvre node thingy to figure out the trajectory. Like going to the Mun you want to leave orbit when Duna is coming over the horizon to gain the advantage or Kerbin's orbit and rotation, so place the node at that point in your orbit. Then pull the prograde arm until your planned trajectory reaches Duna orbit. You won't likely get an encounter right away but you will probably be close enough that you will get the closest approach markers. At that point you can start adjusting the prograde/retrograde arms and the two arms that point towards and out from your orbital plane and see what effect that has on the closest approach markers. Keep fiddling until you get an encounter. Any encounter will do, you can fine tune doing course correction when you are out of Kerbin's SOI. And don't forget you can also grab the maneouver node and drag it prograde and retrograde in your Kerbin orbit to adjust your trajectory. Once you have it set, you can do your ejection burn using the navball to guide you. Or if you use Mechjeb, just hit "execute next node" and away you go.

I usually have the opposite. When I get into the SoI of the planet I often see a dog leg trajectory that bends well inside the planet surface. I have to burn to get my trajectory up to 50 or 100 km.

It's hard to tell from the picture but there seem to be a lot of struts for something that is essentially stationary and shouldn't undergo much stress. I believe using the docking port sr (the big one) would reduce wobbliness allowing you to remove many struts. Removing the RCS tanks and thrusters is also a good suggestion I count 9 sets so that alone is 45 parts gone. Anything that is duplicated or in higher multiples is a good candidate for cutting back.