Nao

Sigh why can't people check first before answering... Nope, they work quite well! Nope they aren't! The drag value goes down to 0.00 but the intakes still produce standard intake drag. Not really, back facing intakes produce constant airflow regardless of AoA. While forward facing ones lose efficiency with increasing AoA. This way for example for standard SSTO rear facing intakes produce almost the same airflow as forward facing ones when the plane is tilted by ~30deg (I can't remember the precise number of back facing intake efficiency thou).For example this is an SSTO that uses 16 intakes and can achieve orbital speeds inside the atmosphere while carrying enough fuel to have 2000m/s deltaV in orbit. No intake is facing forward. (roughly the same can be achieved on 16 intakes placed forward on cubic struts)

The answer to that and many other questions is 42.Also actually it's not the "decouplers" but every other radially attachable part (except fuel tanks) that can do it. I did make a suggestion in bug report thread like 1,5 year ago, to disable fuel crossfeed on most parts (that still allows them to transfer fuel if there are fuel lines attached to them) but i guess it went on unheard. I thought what I'd do was, I'd pretend I was one of that deaf-mutes. That way i wouldn't have to submit any bug reports to really old problems, that will not get fixed either way. (i'll be sad if you don't get the reference)

Hmm never given this much thought... But I think it's because when the engine asks for fuel, only the parts connected by stacking and fuel lines can answer. When it finds a fuel tank, then that tank starts asking around for fuel (in a stack and fuel lines) with the previous part in a chain (here engine) excluded. Then the next found fuel tanks asks again and the cycle repeats until there is no more fuel tanks available. It's a fail safe process. The problem occurs when we introduce parts that aren't fuel tanks or fuel lines, but can create a stacking connection with the previous parts. Now at this point the system starts searching for any fuel tank, not only through fuel line and next in a stack part but also radially. This can start only on a part that doesn't have (relevant) fuel on it. And there is also another problem of creating a loop. That is the radial connections and fuel lines must create a loop, and for standard designs it rarely happens since fuel lines and radial decouplers are usually connected to the same parts, creating only a "double flow" system and not an actual loop. TL DR: for a bug to occur, there needs to be a part without fuel but connected in a stack with a fuel tank, AND radial decouplers need to be connected to different parts than fuel lines creating an actual loops and not just double flow systems.

Here is a post from a year ago i made on the problem: link - there is a picture describing the fuel flow. (unfortunately i can't find even older thread where we discussed it in more detail). What i meant is to connect the SOLID boosters to each other with no fuel line connected directly to liquid drop tanks. The problem with your rocket is that there is a fuel loop because fuel from the small drop tanks can flow naturally by the fuel line AND downwards through the solid booster. The booster part itself is fuel crossfeed capable so it's normal, the thing that enables fuel flow is the STACK connection between liquid drop tank and solid booster. (This is designed for situations like when you have some parts between engine and fuel tank in a stack, the engine can still take fuel form the tank). Then the fuel can flow through other fuel crossfeed capable parts like radial decouplers and similar, creating loops which wreck havoc on fuel flow patterns (which is more of a bug but it's not easy to fix). Now since the fuel loop starts AT the solid booster (by fuel flowing through the decoupler), if you connect fuel lines from the part that has that decoupler (solid booster) the fuel line gets full priority and the radial decoupler is never used to transfer fuel, eliminating the loop. The fuel flow will go like this: - liquid droptank -> (stack connection) -> solid booster -> (fuel line) -> solid booster -> (fuel line) -> solid booster -> (fuel line) -> inner liquid booster. Alternatively i proposed moving the radial decoupler up to the liquid drop tank which would have the same effect of disabling fuel flow through it. Or disabling the whole fuel flow through crossfeed parts by removing the stack connection between liquid droptank and solid booster (place a decoupler between them or just attach the droptank radially). I'm glad that you were able to solve your problem thou Cheers!

You didn't read mine thou. Your new rocket has the same problem as the last one. Just move the fuel lines from drop tanks to boosters and it will work like a charm.

Wait... that bug is still in the game? The problem here is that fuel flows through radial decouplers that hold the boosters (just like through fuel line). To fix this put the fuel lines on the boosters (from booster to another booster) or alternatively attach the outer circle to inner by the drop tanks. Both solutions eliminate the fuel loop created with decoupler working as a fuel line. Alternatively you could include a part that has no fuel crossfeed (like a decoupler) between booster and fuel tanks on top of them, that shuts off the radial decoupler ability to transfer fuel.

Haha true that. But the first built fuselage was designed with confidence that there won't be any big problems that would need some major redesign, and will be used by the military after solving problems with subsystems. And (to my knowleage) it was a first time to build completely new type of craft without prototyping it's design. (As a engineer i find it extraordinary) Right now we have even better abilities to simulate and predict how the given design will work, (we got better programs, more computing power, deeper understanding of physics and generally more experience with modern prediction/simulation techniques than the guys creating the B2) So i'm hopeful it's possible that for mars mission we are just above the cost threshold for simulation (or approximation from limited tests) to be cheaper than full filed testing (like making a moon base to see if astronauts can build/live on other planets).

I share the OP's concern, and right now i see no economical point in returning to the moon. It's atmosphereless, so it can't really be used as test ground for mars mission since there is a lot of different engineering challenges on Mars that just don't occur on the Moon and vice versa. Testing growing plants and other low gravity stuff could be tested with centrifuges in low earth orbit. Also the cost is an issue, gathering experience is good, but at some point, it is just cheaper to do the homework well enough to be sure it works in the filed at first try. (For example the B2 bomber program, the plane was so expensive that it had no prototypes, or "test" aircrafts, the first one off the assembly line went right into service). The telescopes/deeps space surveillance is an interesting point, as it could shield the sensitive equipment from noisy earth. And there are a bunch of smaller research projects that could be performed at the Moon bases, but the problem is that these project's couldn't self sustain Moon base economically. As for mining, most of the stuff can be mined from asteroids at a cheaper cost, since not only we have more experience with space constructions but it is just plainly closer and more accessible. So maybe the first big thing that will kickstart Moon Bases will be be... tourism! (or Helium3 if we suddenly start needing it in large quantities)

And what if the pressure inside the synergine is for example 2 atm lower than pressure of surrounding air? (1atm) Also the same experiment can be done in space, where you take a volume of liquid at zero pressure and stretch it to higher volume.

Oh, I remember a Veritasium channel had a video on how very tall trees get water up to the top. They concluded that in the tallest trees negative pressure can reach -15 atm, it blew my mind! Trees are awesome

Meh, i understand why SQUAD did the new parts as they are, but I really don't like what it did to the *current* balance of the game (including lack of change to the 48-7S). Some of you say "don't like it, don't use it" or "new parts cost more" or "its natural for technology to progress over time" and all of it is reasonable, but in the end it does not change anything about the way the most efficient (and competitive) stock designs will be made in this patch. Maybe it is just a nostalgia thing, since in earlier versions of the game where we could have 4-6 engine types on one ship, each choice tailored to particular part of the mission and each a difficult choice that had to be backed by math. And right now It's either 48-7S or LV-N for space and either 48-7S or KR-2L for surface. I really like the already mentioned idea of filtering parts based on tech level thou. Each level would probably be too much, so maybe tech tree could be divided by only several "eras" like: early, middle and late. With parts balanced to each other in each era. (It would be more awesome if we could get improved versions of already existing parts in later eras, like for example: stronger struts, cheaper solar panels and more efficient engines). Edit: Also i really like and agree with Tiberion's post above

Ah yes sorry i'm dead tired. Thought about "Dealta-V requirement to target orbit", as a measure of efficiency. This also points on the my main problem, as common energy losses (gravity, drag, steering) can be shown in speed change (deltaV) over time. But i have no idea how to show dynamic energy changes during transfers from orbital state to another using different paths. (The best i know is about impulsive burns at Ap/Pe but that's no good for ascent where we never burn at orbit's major-axis)

Yeah, calcualtion of deltaV changes due to the Oberth effect is above my mathematical ability at the moment, that's why i turned with the idea to this forum . The one thing that i like about this it is that it solves every orbital and momentum related element of ascent (including vertical speed, angle of climb, lift due to centripetal acceleration) just by speed (and altitude) variable. And it could then be directly compared to another variable based on speed and altitude, the drag. It just looks like it could work. It would be hard to implement this to low TWR rockets, but i'm just trying to simplify the problem, to actually get a working solution for whole ascent. Actually even without looking at Oberth, the "fix to prograde" could be useful to weed out one variable from late ascent. I feel like steering looses would be one thing that would trend to zero during ascent with optimal path. And coming with the solutions from both sides of ascent path (vertical climb and late ascent) could potentially help determine the hardest part, gravity turn.

There is a concept on the subject I had on my mind for some time. It's nothing special but ill post it in hope of inspiring others with some ideas and maybe fresh point of view. After many launches I came to conclusion that maybe it could be possible to present optimal late ascent (after ~45deg) as a minimum losses between drag and dv lost to Oberth effect (with an attitude fixed to prograde simplification, just using throttle to control the ship). I have no math ability to present this idea in equations. But just looking at the problem: during ascent, after the craft manages to accelerate to have an Apopsis of 40-50km (an altitude where it can achieve orbital velocity), the optimalization of ascent is simplified to balancing the acceleration while on the path to orbit. The idea is to use thrust to control pitch with shape of current orbit. High acceleration rate will shoot Ap up quickly, minimizing thrust in the atmosphere, increasing Oberth losses. Slow acceleration increases time spent in atmosphere and drag. Different non linear acceleration profiles will give better efficiency. I think the idea of using attitude fixed to prograde late in ascent could really help simplify some equations. It shouldn't give much error too as steering angle looses can be quite big when burning more than 3-5 deg off prograde. At the same time calculating gains from Oberth also covers centrifugal acceleration as well as orbital vector elements etc. It's of course hard to quantify the gains/looses from Oberth effect, but when doing real (by hand or MJ assisted) launches this is what i try to optimize for. After many tests I can get to very similar deltaV results with different starting conditions of late ascent (angle, speed, available thrust etc), just by using the correct amount of throttle at the right time, and following velocity vector. Also assuming different target orbits another, even simpler, connection between target orbit height and "turn end" height could be made. Since for higher orbits its much easier to get out of the atmosphere. For example completing lunar insertion burn at Pe (0deg attitude) at 50km will be quite efficient and still will get out of the atmosphere quickly. Just comparing target orbit height with "turn end" on the basis of drag losses and Oberth gains, could give a simple but useful relation. Sorry if this sounds like gibberish. I just feel like trying to rely mostly on terminal velocities and turn angles will not give good enough results (especially for late parts of ascent). (Also damn, not filling up math equation quota makes this feel like an off topic post. Haha)

RUN Probe! RUN for your life, from my claws! (On a less off topic note, the most efficient landings (and ascents) are done as close to the surface as possible BUT, Tylo can have a nasty surprise for you as it has several high areas (up to 11km), at 1-2km/s speed they can come up faster than your craft can correct. Also hovering at 0,7g's make quite a drain on fuel so make sure your craft is prepared for quick, not 100% perfect landings) GL with setting that fast expo on Tylo Probe ... it will be right on time for my 9pool speed!

This is really awesome! Although i'm unable to help with math i really appreciate the work going into it. Thinking ahead i'm really curious about how big the maximum optimal TWR of a rocket will be (excluding v=0 of course, it will most likely be achieved during gravity turn around 30-45deg, probably 3-4 TWR). And then optimize it for minimal launch mass . Good luck guys! (PTW)

Nice job, but there is even better way to get to orbit from Mun surface. Use mouse to rotate the kerbal just like you would with rocket, and only thrust in one direction staying as low as possible. Thrusting up and froward at the same time generates only 1,47 of unit of thrust in one direction while consuming 2 units of fuel, and due to Oberth effect it's better to accelerate as low as possible. I didn't tried it much on current patch but 25km orbit should be pretty easy to achieve (starting from standard ~5km altitude). I do agree that land and ascent again is out of the question without some kraken / landing on head shenanigans

Not really unfortunately. I's hard to explain in detail. It's just that there are so many variables that optimal flight path would be very complicated function and would work only for one craft. Also one thing to improve in MJ ascent path would be to add reduction in velocity requirement as gravity drag decreases due to centripetal force (as the idea of terminal velocity is to have drag loss equal the gravity one). In the end, searching for minimal delta-v path is also not the end point of maximizing efficiency, as it is by principal not the most efficient for any given ship. That's because of engine weight, that is required to satisfy TWR demands, that impose higher weight cost than fuel saved from delta-v difference of less optimal path. For example we can do almost the same launch with lower engine mass (lower TWR), but constant 100% thrust, never reach terminal velocity and achieve orbit on less fuel spent even thou we used more delta-v. Going even further with lower TWR we can achieve lower launch mass for given payload by exchange engine mass for a little more fuel. edit: hmm that wasn't worded right either :|. Let's just say that the most efficient craft will hardly ever reach terminal velocity so its hard to create a profile based on its ability to follow such speed. edit2: And that would be my point... not only it would be hard to create optimal ascent profile based on things like steering looses (following vertical velocity vector) and balancing gravity and drag losses (following terminal velocity) but also depending on actual craft design there are more possible craft paths that give better results that mostly have a lot to do with craft dynamics (craft momentum, acceleration profiles, Oberth effect etc)

Yep, its really impossible to define "perfect" turn shape as it changes with different crafts and other parameters. Just looking at my previous post here with some data. The difference between best results for 100% shape and 50% one were only 6m/s Dv for KerbaX rocket and only ~25m/s less than the best 66% shape. Similarly even turn start at 3km with other settings tweaked could produce a good result within 28m/s of best one. While the 200m/s of difference in your example is quite big, the results of ascent are a sum of many parameters that work together, turn start is just one of them. If you for example take 6km turn start, just increasing turn end to like 70km and/or increasing turn shape could possibly increase efficiency to comparable levels. After very long time learning ins and outs of ascents in this game, I think the single most important parameter that defines ascent path is vertical speed (especially in mid ascent, during gravity turn). If you look at flights with different ascent settings, you can notice that the best settings produce similar vertical speed profiles, even on crafts with different TWR. Turning too early will mean not enough VS to get out of thick atmosphere fast enough, too much and you are wasting a lot of dV (both for accelerating craft upwards and loosing on Oberth effect later in ascent).

Care to explain why you think so? The only hard part of SABRE-s engineering wise is the precooler. And i've heard they have some working samples already. This of course does not mean it will ever lift something meaningful into space, as the whole Skylon idea will probably end up being too costly to develop. But i believe that the RAPIERs RL counterpart will at least work in testing, and maybe be used in the next generation of supersonic air transportation.

Actually, from game design standpoint, that's the best kind of balance possible. Nothing to be sad really. If there is no balance complaints that means you made something that isn't standing out in any way. And that mean it's bland and almost the same as the every other thing, boring. Probably all of the most prized games (especially multiplayer ones) out there are balanced on the notion of "fight OP with OP". That is, when something *feels* OP but doesn't affect the overall balance because there are other "OP" things out there to counteract it, It makes the game feel great to play and balanced at the same time. That's why i really like what SQUAD has done with RAPIER (although overall it's not perfect yet).

Not an entry (Yet!) but something to inspire maybe. It did use every part available just once (it was ~0.16? patch). This time around since we have much more fuel tanks and don't need to take every part it should be quite easier. I'll probably do a Tylo or Eve land and return mission, but honestly Tylo should have at least as much points as Moho, if not higher as it requires not only more deltaV to land but also more thrust. Personally i would rate it at 100. Also Eve ascent should probably be worth even more (150?) as you don't have enough engines and fuel tanks to stage (4 of each type max). And i don't think it's possible to ascent on eve with less than 3 stages stock. Whatever the points it should be !!FUN!!

Remember you can also train at Minmus! There are a lot of flat areas that are easy to hit and the KerbalX can do a land and return mission stock, unlike the Mun mission. To help throttle control , when you are low and slow over the body you are trying to land on, try limiting the thrust of the engine via the engine's right click menu (especially good on minus, as KerbalX needs only ~3% thrust for hover there, so 10-20% is enough. For Mun i would recommend 30-50%).Also regarding technique, there are two main reasons the rockets fall on the side: 1) too high horizontal velocity when touching down and 2) ground slope is too big. First can be reduced by training. (When landing keep an eye on the retrograde marker, if it isn't in the middle of the nav ball, turn the rocket in it's direction, while slowly descending. Also make sure the speed indicator is in "surface" mode, minmus has mountains high enough for it to automatically switch to orbit and mess everything up.) Second can be fixed by picking a better landing spot or making the rocket have low center of gravity and long landing base. Also when landing on slopes, remember to cut all power as soon as first leg touches the ground! SAS also can help in stopping the rocket bounding left and right after touchdown.

Actually depending on the entry and exit trajectories an highly eccentric orbit could be the best. If you think about it, most fuel will be burned by moving the heavy interplanetary stage. Even if the lander works on rockomaxes 48-7S and the interplanetary stage works on LV-N's if the lander weights more than 2.3 times less (confusing sentence ) it will be more fuel efficient to do any burns in orbit with it than the main stage. So the best parking orbit would be the one that takes the least amount of deltaV to achieve coming from interplanetary space (and we need to add the deltaV needed to exit the body in question, possibly in some other direction which complicate it even more). So this is actually pretty interesting question. By hunch i would say that if the lander is much lighter than the main stage, either highly elliptical orbit (Pe just over surface and Ap just near SOI end) or high circular orbit (Ap/Pe near end of SOI) would be the best parking spot. Finding that for bodies like Pol and Bop would be pretty easy, but let's think of Tylo for example. Lander weight for it would be more dependent on where the parking orbit is. So there could be some "in the middle" solution to the maximum efficiency parking orbit. edit: Of course lowest possible Pe is the best spot for orbit insertion burn, so an high circular orbit would be silly. Thanks Kasuha!

The BOX superlifter. Partcount 638 and Zero struts!. Achieved orbit without exploding. Old "Every part available used once challenge". Got this one into orbit too somehow. Smallest SSTO without clipping the engines, and its predecesor two stage booster. Wonky flier. It's controls were flipping at some speed due to mismatch between pod reaction wheels and aerodynamic controls. Flight characteristic was all over the place but it completed it's mission.