Spricigo

From Orbiter forum: Notice, is not about a game or another being more 'difficult' , 'realistic' or even 'interesting'. They are just different, and the apple/oranges kind of comparison that goes no where.

AFAIK 'old' asparagus (fuel lines, crossfeed disabled) should still work the same. Maybe check your settings [fuel transfer obey crossfeed rules] ? What I mentioned is the 'new' asparagus. Engines are able to use all tanks that are linked (attached directly or by decoupler/docking port with cross-freed enabled) and flow priorities define which tanks are emptied first. The booster keep being used until the very moment you drop then, just getting fuel from the next tank available. The fact you can run the booster for more time is advantageous, while the lack of a more obvious clue that tanks get emptied is indeed a bit annoying.

There is nothing to apologize. The idea of this forum is exactly to share our collective knowledge. Sometimes we can explain the bits we know better, other times we learn the bit we didn't grasped very well yet. Mind you that the way I write is a bit blunt at times but by no means meant to be aggressive.

You mean this thread: I'd point out that drag losses itself are not that a big deal people tend to assume. 100-200m/s if you can keep the rocket pointed close to prograde is about a common ballpark (even for some more powerfull rocket) .Deviating from prograde tend to be a more serious problem.

the issue he is facing is not that he is not reaching orbit but that he is using too much fuel to reach orbit. That method would makes his problem worse. Also, I strongly recommend that you stop using it immediately since you can be much more efficient even with a badly performed gravity turn. Sorry, but the idea that a gravity turn is in some form worrisome to pull out is just wrong. I can tell from my experience , doing a reasonable gravity turn is not only easy but trivial to perform. About 60% of my gravity turn are done like: 1. press space(to launch) 2. press space(to drop booster) 3.wait for apoapsis The rest are like: 1. press space(to launch) 2.set SAS to follow prograde 3. press space(to drop booster) 4.wait for apoapsis That's it, 2-3 key-presses/clicks and you go to orbit for less than 3,5km/s. It can be made even more efficient with some extra care for details, but most of the advantage can be achieved with a 'lazy' gravity turn like that. The only thing that is missing in your firsts attempt are the knowledge to know how much of a initial turn is required (/muscular memory for those that prefer the 'nudge' method.)

^this. The only thing missing is the hint that it's time to ditch the booster (engines stops). You need to open the part info window to see when the tank is empty. If the challenge allow it (I know it's unlikely) Smart Part mod have the Drainex that trigger a staging even when you reach a previoly set % of fuel in the tank.

The impact of the whells with the ground is just a particular 'kind of drag'. We don't call it that way but is just another resistive force that appears when we try to pass thru that medium. Wheel are particularly usefull for this stuff because it will have considerable less friction with ground than other parts and will slide instead of bouncing, so it's less likely yo your craft to tumble and hit the ground with a less resistant parts. Off course for this be most effective you need to land at a shallow angle so, either landing horizontal or at a slope. If you want to land vertically in a flat surface that is much less likely. You need a lot of crossectional area with very little mass. Excluding parachutes our best bets would be wings, control surfaces and structural panels monted perpendicular to the airflow. That looks like a horrible bet at this point. BTW aerodynamic drag is also a FORCE caused by the FRICTION of a moving body with the surrounding air. Words have power, be careful.

You may try a small flotilla, something like three vessels: -one to delivery the stuff you want to use at the derstination (landers/rovers/satellites/etc) -one supply ship (fuel/life support) -a crew transfer vehicle. This can be sent later in a faster trajectory to save ob life support supply. Even if you dock later, the vessels will probably be smaller by then. The drawbacks are pretty obvious: doing the transfer/capture maneuvers multiple times, the need for rendezvous and part redundancy. OTOH you don't need the bigger stuff and have better chance to avoid ridiculous long burns and woobling issues.

Well, not much the point but maybe he is. Drag losses tend yo be considerable less than gravity losses for a "typical" rocket launch even If the pilot is careless with the throttle.

While there is a few possible design flaws I don't see nothing severe enough to take the amount of losses you are experiencing. The only sensible explanation seems to be piloting. Either try to better describe how tlyou are flying, (e.g. what speed, altitude, inclination you are getting at time of staging and at some ballparks (5km, 10km, 20km)). You can also share a craft file, so people can test it and see if they can put it in orbit for dobsiserable less and explain what they did.

Well, not for rockets with TWR around 3, for those you want a more agrassive gravity turn. From my experience 5°+ right from the launchpad will do the trick for those. Don't do it. Using a less powerful but lighter engine can be beneficial because the increased deltaV budget, but throttling down just cause the gravity losses to increase*. As long as you can get the initial 'nudge' correct there is mostly** no reason to throttle down. It is a bit harsh, but flight adjustment are only necessary if you did something wrong earlier. Either the initial 'nudge' or something in the design. Designs with lower TWR(1.3 - 1.7) tend to be more forgiving since you have a longer time to orbit and will be at lower velocity at the time of the corrections. In any case those deviations cause cosine loses (thrust-velocity misalignment) and increase drag losses (larger area exposed to airstream) so you should try to avoid the need for those correction in the first place. For the 'nudge' practice, practice, practice. Or designs with pre-tilt in the editor. *If you have a readout of Max-Q and can keep your rocket at that speed ok, that is where [gravity losses] + [drag losses] are minimal. Otherwise focus on minimizing gravity losses , what you do by getting to orbital velocity ASAP. As long you are not overheating drag will be the lesser of those two issues. **too much drag can melt your craft. Also the above mentioned Max-Q.

You rocket is a bit too powerfull, what can make difficult to follow a proper gravity turn. Even then It shouldn't take 4100m/s to orbit. The problem is your ascent profile. Performing a gravity turn is in fact very simple, give the rock a small initial tilt and let it fly itself to orbit. The trick pat is to get that small tilt rigth, a degree can make the whole difference. So just experiment a bit to give more or less of a initial tilt until you find what is the ideal for each rocket. some rules of thumbs: -more powerfull rockets should be more agressive steered to start the gravity turn. -your rocket shuould be pointing very close to prograde (less than 5°) most of the time. -if your time to apoapsis is screasing slowly that is a good signal. -if you reach 10km with about 45° of inclination is a good signal. Lastly my offer of a craft that can do a gravity turn by itself, it is pre-tilted in the editor so you just need to press space to launch and stage. Its TWR is a bit high, mind you, but good to give you a idea of the kind of trajectory will put you in orbit reliabily.

Well, I can believe it. What I have doubt is if taking a screenshot is not easier than what you did. Anyway, have a nice landing.

...and the image show us how your screen is an excellent mirror. Why you didn't took a screenshot?

And that looks simpler than [1/(r-262)^2]. People usually have a reason to make things more complicated. Now go figures if was a good reason in that case.

That flexibility is not much of an advantage if it only allow you to stage at a bad moment anyway. It only really make sense if you plan to top those tanks somewhere along the way.

Sorry, not meant to imply 'lack of evidence'. Rather trying to point that more arguments along those lines can be usefull for defending your idea.

AFAIK in most cases the parts with mobile bits don't get affected by how loaded it is. So, they would, unrealisticaly, move the same way unimpeded or with several heavy parts attached to it. IMHO not how one want an engine to work. The (possible) exceptions I know are: -Winches from KAS/KIS -Crane parts from Konstruction -Infernal Robotics In any case. I don't know how those mods can be usefull for your ' propelled shaft' idea.

Is totally irrelevant. Your craft will be plasma way before you can be near the surface. Ok, that actually is something to consider. (Notice, maybe not enough to make the change necessary) Still up to you to demonstrate a significant difference between what "should be" and what is. Personally I don't have an idea of how much a realistic values "should be". From a gameplay perspective I'm satisfied with collecting that science being "very difficult", which is in line with the current situation. Another reason to not change. I'd hate if a change on the game made easier to reach a planet that I had designed to be nearly impossible.

While not sure, I suppose that is possible. However the issue I mentioned is a different one: For reasons I don't know, we don't have the adequate parts to build gearboxes, axles, pivots, etc. It can be done in stock with a good deal of improvisation or with a mod, but not with stock purpose built parts. The problem is not the engine, the problem is to link it with something else.

If the values you got at different distances are unrealistic that is a different matter. My point is that starting the calculation from the sun surface per se is not a problem. We are not supposed to be anywhere close to that distance anyway and, according to the scientific models*, there is some very counterintuitive effect of the complex physics happening inside the stars. So, as long the resulting in game effects are reasonable**, it even make more sense to not bother with "below surface" calculations and just calculate things from there. *thankfully those are solid and reliable models. It's not like we had much opportunity to collect a lot of data in locco. **and by reasonable I mean: provides a adequade behavior for the simulation and game have a adequate difficulty as result. If it is realistic really don't matter as much as if it makes the game balanced. Let's not compare apples to oranges? (Or rather gravitons to photons) The fact that flux is infinite at the surface of ther sun is irrelevant, you are not supposed to be there to begin with. Wich is more than enough reason to be unrealistic that you reached the surface of KSP analog to complain about its unrealistic behavior. The fact that I messd up my wording when intended to say "stars can be hotter outsise" don't change that. To sum that all up: -Behaviour at sun's surface is irrelevant, we shouldn't be there. -If is irrelevant it may as well be incorrect. My question is: what advantage it will brings to the part of the simulation where it is relevant? Also: Is that something that will improve the game for regular players in the stock system or something that only offer significant change for people with the heavily modded RSS/RO install? If the later let it be handled by mods.

The "philosophical" reason is that a mod does it so the stock game don't need to. The stock game is based in crafts made of "lego bricks". And, while is arguable true that several kind of bricks are missing, procedural parts are unlike to be added to fill the gaps. Fairings are an exception. I guess the devs had a too hard time trying to figure out to design "lego fairings"...

Granted I'm not a astrophysicist. But it seems to me that calculating flux from surface make more sense. If nothing else because IRL the surface is way hotter than the core.

The problem is not the engine itself but the lack of gearboxes, shafts and other stuff to transmit movement. Awhile ago I found a mod with "internal combustion engines" that produced "motrice force" and wheels and propeller that used this resource to work. Not much different than stock wheels powered by fuel cells.

Of course "plenty" is an exaggeration. But the only real riska I can foresee are 1) wasting deltaV in unnecessary maneuvers 2)mess up trying to reverse the orbit without raising ap first (because unexpected/unaccounted inefficiency). Both can be remedied if he saves in the current situation.