Pand5461

No, I believe throttling on ascent stages is primarily for other reasons: To limit g-loads and drag, as pointed out many times If there are boosters, it's beneficial to save fuel in the core stage for longer burn after booster separation (Delta IV Heavy, Soyuz) To equalize the wear on engines (landing engines of reusable Falcon 9)

Probably not. But there are other reasons. Sometimes it's just good to have another control variable (throttle level) for guidance algorithm. Imagine burning a maneuver node in KSP, and the full-thrust burn is 30 seconds long. Ideally, you want to start approximately 15 seconds before node. And, let's say, you are really impacient and accidentally start burning 20 seconds before the right time, or 35 seconds before node. In LKO, such an error in timing can lead to your orbit being quite different from what you want it to be. BUT you can correct if you burn not at full thrust but set a throttle level that makes your burn 70 seconds instead of 30, and it's still going to be split in half by the node. For powered landings, throttle control is absolutely essential. There is the "ideal" suicide burn trajectory which needs precise knowledge of gravity field, atmosphere, engine stats etc. and starting engine at very precise moment. If engine is lit a split second later, rocket is going to come to stop a few meters below ground. A split second earlier - and it's going to stop a few meters above the ground. For Falcon 9 stages that cannot hover the latter is not much better than the former. And you cannot start an engine at a very precise time, so throttling during powered descent allows to compensate for errors, deviations and disturbances.

While this is true I think locking access to the mod is the right decision. Now everyone here has an example of what can happen if people don't think twice before getting into argument with mod authors about their work.

@Sergio22 без модов особенно ничего и не требуется. С модами можно добавить больше жилых модулей - избыток места во многих модах на СЖО делает кербалов счастливее, и они дольше остаются в рабочей форме. Также с СЖО имеет смысл добавлять модуль для припасов. В стоке этого всего нет. Имеет смысл добавить научную лабораторию, в неё можно загружать отчёты об экспериментах, которые со временем будут преобразовываться в дополнительные очки науки. Можно добавить топливный модуль, тогда станцию можно использовать как заправочную для аппаратов, отправляющихся в дальний космос. Такой модуль включает большие баки ("морковки" или 3,75 м) и, если хочется, конвертер руды. Руду нужно возить с Муны или Минмуса.

Weird alphanumeric codes really add a nice touch (like Soyuzes are 7K-OK, 7K-L1, 7K-MF6, 7K-STMA-M etc.). Especially for the pod, because stock ones don't have any.

Soyuz 5 is also a new launcher but RKK Energiya hasn't come with a better name for whatever reason. And now I looked into the main topic, "Big Khleb" is a nickname (may as well be what "Amerikans" call it), while the BK-50Y-Z is exactly what I said about crazy abbreviations.

Both, actually. I mean, air/spacecraft modifications names are usually the name of the base craft plus some abbreviation vaguely related to what the modifications are about.

You made English even more weird for me. Actually, "Bolshoy Khleb" wouldn't make much sense either. Really Soviet-themed name would be "Khleb BIG" (as in "Soyuz TMA" ship, "DM" upper stage or "Soyuz-FG" rocket). This one would be "Khleb BIG-R" then, R standing for "Rasshirenniy" (Extended). If anything, this is not a demand, just me thinking aloud.

Here's me again with some inappropriate suggestions. Found a nice website listing spacecraft failures: http://claudelafleur.qc.ca/Scfam-failures.html Looks like tank leakage is not a problem at all, at least not as big as tanks sometimes randomly exploding (Apollo 13, AMOS-6, Vostok-2M explosion at Plesetsk in 1980). And stock tanks are so ridiculously heavy already, it is easy to imagine they are shielded from any micrometeorites and the walls are thick enough to not crack from internal pressure. Loss of pressurization gas can be an issue however (resource permalock?). From what did fail or malfunction, engines certainly have the worst record, or just everything else doesn't have a chance to fail after engine explosion followed by RUD. There were loss of performance, emergency shutdowns, turbopump explosions and even some premature starts (Nedelin's catastrophe is a notable example). Some ideas for more failures: A fairly common malfunction is attitude control failure but I have no idea how that can be implemented in-game. IRL it was usually wrong wiring so roll commands went to pitch thrusters or were executed in the opposite direction. Antennas fail quite a lot, either not deploying or just losing the signal (sudden drop of antenna range?). Reaction wheels are destined to fail eventually, so maybe set failure chance to 100% BUT introduce a minimal operation time (that increases each generation starting from a few hours and capping at maybe decade). Not sure how to deal with turning RWs on and off. Increase generation of every part returned from space / upper atmosphere (if it's possible to keep track of that). Cap the generation that can be achieved without returning parts (simulates limited capacity to test things in lab). Increase generation after completing part testing contracts. Increase base reliability of all parts each RnD / VAB / SPH upgrade Add decoupler failures - one mode is "failed to decouple", another "violent decoupling". The latter is a random damage to one of the attached parts (so a decoupler either damages a tank below it or an engine above it) and only for inline decouplers. Increasing decoupler strength in the right-click menu increases the chance of damage but also increases chances of successful separation, and vice versa.

@1greywind хотел бы посоветовать kOS для автоматического вывода аппаратов на орбиту, чтобы на стримах не тратить время на исправление ошибок, проматывание лишних орбит и т.п. Я писал обучалку на ссылка удалена модератором, там же есть примеры скриптов (также выложены на GitHub). При некоторой практике можно научить его делать полностью автоматически совершенно потрясающие вещи, вроде отправки посадочной миссии на Муну c ненулевой широты, орбитального сближения на наклонных орбитах со стартом сразу в нужную плоскость и т.д. Явный недостаток - на подготовку скриптов уйдёт, скорее всего, больше времени, чем на весь стрим в текущем виде. Даже если возьмёте у меня что-то "почти готовое". Особенно если kOS для вас в новинку.

May I ask, why is it "Big Khleb" and not "Bolshoy Khleb"?

Well that was a bit above it. Thing is, the higher you go, the larger orbital period becomes. So, what was a "low thrust" maneuver at low orbit becomes a "high thrust" maneuver at higher orbit. For example, imagine a day-long burn. In a low-earth orbit, it's a long maneuver because orbital period is about 1.5 hours. At the height of Moon orbit, however, this may be considered as almost point maneuver due to orbital period of 28 days. Therefore, what starts as a tight spiral unwinds quicker and quicker each orbit until it turns into hyberbola. Theoretically. When I applied this reasoning for Dawn probe (which, to my knowledge, is the only one spacecraft to leave LEO using electric propulsion) with 0.1 N thrust and 1000 kg mass, the distance where "low thrust" becomes "high thrust" turned out to be larger than radius of Earth's SOI.

Centaur is the circularization / 3rd stage in the above classification because boosters work as 1st stage and core as 2nd. It just adds last 2 km/s to get to the orbit and the flight is almost horizontal already.

This should print vlan out: set xi to arcsin( cos(incl)/cos(latitude) ). set vlan to azlan(xi). set launch_now_lan to vlan + 2.5. print launch_now_lan. Inclination must be higher than latitude of course and azlan function must be loaded to work of course.

Hell yeah! And aren't spin-stabilized sounding rockets cute? (Do you have Persistent Rotation btw?)

It's not as easy. High TWR certainly reduces gravity losses if you just launch rocket vertically to a suborbital trajectory. On the other hand, you need to either steer more aggressively to get a gravity turn or spend more time at high pith angles if you have too large TWR, increasing losses in both cases. Also note that gravity losses scale approximately as g / (a - g) = 1 / (TWR - 1), so going from 1.1 to 1.5 is vast improvement, from 2 to 3 - not so much. That said, it's best to have maximum possible TWR at liftoff but probably not higher than 3 in the maxQ region (mainly to limit aero stresses, drag losses are usually negligible IRL, contrary to KSP). After rocket passes dense atmosphere, it needs to steer, so high TWR leads to high steering losses here. Therefore, something between 1 and 2 is the choice (sometimes even lower, like Saturn V with 0.8 at second stage). For circularization, TWR does not matter much so IRL it's usually low because smaller engines are cheaper. Ironically, the closer you are to the ground, the higher acceleration you actually need, which is absolute opposite to what really happens at rocket launch.

I see signs of UbM here.

That's easier. Let's say you have the inclination i. Then, the trajectory crosses the meridian at the angle xi = arcsin( cos(i)/cos(latitude) ) Then, if you are instantaneously at that orbit, its "virtual" LAN is given by the following function: function azlan { parameter xi. local Vvirt to heading(xi, 0):vector. local nvirt to vcrs(body:position, Vvirt). local ANvirt to vcrs(nvirt, V(0,1,0)). local vlan to arctan2( vdot( V(0,1,0), vcrs(ANvirt, solarprimevector) ), vdot(ANvirt, solarprimevector) ). if vlan<0 set vlan to vlan+360. return vlan. } As @Reddy mentioned, he planned launches 8 minutes before orbit passes over launch site, which translates into Earth rotation by 2 degrees. Therefore, adding 2 degrees (maybe 2.5, to be on the safe side) to the calculated value is more or less what you want. EDIT: if you want to launch at other time than "now", just calculate angle of rotation as 360*(ETA to launch)/body:rotationperiod and add that to previous calculation.

That's what I did. Thing is, lambdaDot goes crazy way before 10 seconds to finish. At tgo = 120 sec it has magnitude of over unity, so I need to scale it down. The constraint for rd being on a very specific trajectory is too harsh, I guess. Here's about as close as I can get: Just burn maneuver prograde / Vgo vector, it must be just fine.

Ну так, на всякий. Плюс, следы английской грамматики из русского надо вымарывать. Если что, у меня самого это получается только изредка и то после многих итераций. Поэтому за переводы особо не берусь - тяжёлая работа.

"Его тягу можно поднять впрыском кислорода в рабочее тело". Старайся на каждое слово смотреть несколько синонимов и, по возможности, выбирать самый короткий - иначе перевод распухает по сравнению с оригиналом (у переводчиков считается допустимым увеличение числа символов на 10%).

@prcreeper а может, вообще "шестиреакторный"? И по смыслу соответствует, и лучше понятно, о чём речь. "Корчеватель" хорошо , хотя stub - ещё и окурок, огрызок, обрывок... По виду, "Обрез" может подойти. Хвостовик - верхняя утолщённая часть некоторых деталей машин или инструментов, служащая для закрепления или присоединения других деталей и механизмов. Может, подойдёт для boattail? Звучит, правда, очень жаргонно на мой вкус.

О, а мну FAR перевёл, можно мне ачивку? "Шестизонный", может быть? В реакторах "core" - это по-нашему активная зона. Или шестикамерный - в химических двигателях есть же камеры сгорания.

Can't agree more. The problem with "realism" is of course that real-life missions do not use the same equipment for long-term and short-term flights. Any sane person will try to develop reliable equipment for deep space missions rather than use failure-prone one and pray to Kraken it will last few dosen times its MTBF (OK, USSR in the years of the Space Race did exactly the latter but we're not in a hurry here). So, there must be an option to increase the reliability for a specific vessel for extra fee or time if that vessel is supposed to go for a long mission. As for tanks specifically, their reliability may be based on the volume - a micrometeoroid is arguably less likely to hit a small tank than a huge one. First, this encourages players to not overdesign. Second, the further a spacecraft goes, the smaller tanks are usually left on it, so large MTBFs are naturally important mostly for small tanks.

@Jim DiGriz Setting the lead time to J/L actually improved the convergence a lot. Now ship does not try somersaulting from the very beginning. Still wants to misbehave by the end of the burn, but I just restrict magnitude of (lambda dot) * J/L. The accuracy of apses for a stock 6-minute 850 m/s prograde burn is now Ap 10320 km (target 10217), Pe 94 km (target 86.75). SMA is rotated by a few degrees unfortunately. I'm trying to find out whether I need to restrict steering a bit more or allow more aggressive steering. UPD: restricted magnitude of (lambda dot) * J/L to 0.15, that improved accuracy of maneuver. Test case: cheat craft to 686750m orbit (min available from cheat menu), maneuver node 850m/s with equal NRM and PRG components. Initial TWR 0.23, "nominal" burn time 5m35s. Result: plane difference 0.15 degrees, AoP difference about 0.5 degrees, SMA difference about 0.5% (didn't check eccentricity). Ap accuracy is about 50 km, much better than burning straight along node prograde. However, the maneuver took extra 65-70 m/s. I've noticed also a small error in kOS update procedure. dVsensed is the velocity gain measured by accelerometers, so it does not include effect of gravity IRL. So, setting dVsensed = Vcurrent - Vprevious introduces a bias to the initial guess of Vgo at the start of PEG loop. This gets corrected after one or two iterations of course but convergence is faster if gravity effects are subtracted at loop update routine.