Pand5461

Это очень сурово. Я отключил Revert Flight, но оставил загрузку. Играю с kOS (только для полётов за пределы атмосферы), FAR, Unmanned Before Manned, Kerbal Construction Time и KRASH - в итоге тестирование крафта в симуляции зачастую выходит дороже нового. А тестировать надо много, потому что с kOS редко когда всё идёт сразу как хотелось. Как итог, нужны деньги, которые до открытия космических капсул фармить нечем, кроме как контрактами на сбор науки (потом появляются туристы в количествах, ограниченных только жадностью и уровнем центра управления миссиями). И норовят появиться, конечно, какие-нибудь сейсмографические исследования в горах. Без возможности загрузки посадку с живым экипажем можно уже считать большой удачей. До нужной точки после этого ехать обычно уже не на чем. Контракты на спасение с орбиты вообще отключил, т.к. запускаю с Байкербанура, а спасать обычно надо с экваториальной орбиты. Кстати, то, что есть контракты на спасение из частей без шлюза - недоработка модеров, в стоке такие части включены в "чёрный список" и в контрактах не выпадают.

О, а тут ещё и Муна в разных контрактах разного рода.

Он даёт функции САС даже когда в экипаже нет пилота и не стоят зондовые модули. С другой стороны, у меня всё внеатмосферное летает с кОС, а космодром передвинут на Inland Space Center - 20 градусов широты. Поэтому считаю оправданными некоторые послабления в самолётной области Возвращаясь к основной теме: доделал посадку на Муну в кОС.

А мне вот этот автопилот нравится, особенно полёт по метке (хотя это читерство, да).

It worked, thanks!

Close enough. Kerbalism. Found the post about this issue. So, it's going to be there for most configurable parts, it seems.

I have always exactly 0 times recovered for all crewed capsules (KSP 1.2.2, SY 0.9.4.51), even when I apply part inventory. All other part seem to get inventorized just fine. Is this the intended behavior?

Посадил самолётик с первой попытки. Недосчитался всего лишь двигателя.

То есть там есть такое, что масса и драг выше, УИ ниже, цена тоже низкая? Для баланса что-то такое я подразумеваю. LGG молодец вообще с поддержкой модов. Сейчас он занят вроде бы портированием всей этой кучи на 1.3, так что можешь не торопясь допиливать.

Смотрел обзор у Котабоса, идея прикольная действительно. А там, кроме внешнего вида, есть существенные отличия в характеристиках?

Не убил Билла при запуске автоматизированного корабля (почти подходит под последний челендж, но для выхода Билла в открытый космос всё-таки пришлось включить интерфейс).

Не совсем. Перегрузка связана с ощущением веса, поэтому у покоящегося на поверхности тела равна 1 по определению, а ускорение равно нулю. В невесомости же перегрузка равна нулю, а ускорение равно местному g.

Там же G-Loss-of-Conciousness Meter, т.е. шкала потери сознания от перегрузок. И она зависит от устойчивости к перегрузкам конкретного кербала. А на навболле просто G-Force.

Выискивал, какой из обновившихся для 1.3 модов сломал мне сейв . Оказался конфликт KSCSwitcher и облаков (sic!) в SVE.

Заметил тут у видеообзорщиков, что шкала справа от НавБолла названа "Ускорение", хотя по смыслу должна быть "Перегрузка" (ускорение было бы "Acceleration", а там "G-Force").

I, too, was quite surprised to figure out the problem wasn't in Kopernicus or somewhere else, but in the cloud part of SVE. In the end, no idea what happens. Just flattening works with two MainClouds nodes and doesn't work with either one of them. Everything also worked with either config when I forgot to copy Textures into the SVE folder. Moving KSC to another place works, just ground there isn't becoming flat, so maybe be some interaction with PQSMod_MapDecalTangent... For now, I made a MM patch which adds that missing cloud layer back. Should I provide the logs or let it be a weird problem for weird people who are not satisfied with stock KSC?

For some weird reason, this caused KSCSwitcher to not work properly (no more ground flattening around non-stock launch sites). KSCSwitcher works with SVE-1.2.2 cloud config, does not with SVE-1.2.3. Does not matter whether I use original SVE-1.2.3 or copy EVE_CLOUDS part into SVE-1.2.2 config. Will give more details later, after more investigation.

I just realized, however, that you may rather easily calculate the deltaV for burn that makes the orbit "as circular as possible", given the craft's current position and wanted SMA. In fact, for the most circular orbit, the craft must be at the apsis of the new orbit. That should be like this, I guess: double AdditionalE = OrbitE - TargetE; Vector3d pos = v.orbit.getRelativePositionAtUT (Planetarium.GetUniversalTime ()); Vector3d vel = v.orbit.getOrbitalVelocityAtUT (Planetarium.GetUniversalTime ()); Vector3d up = pos / pos.magnitude; double Vmag = Math.Sqrt(vel.sqrMagnitude + 2*AdditionalE); Vector3d HorizV = vel - up*Vector3d.dot(vel, up); HorizV *= Vmag / CircularV.magnitude; // set new velocity directed exactly horizontally double DeltaV = Vector3d.Magnitude( HorizV - vel ); v.orbit.UpdateFromStateVectors (pos, HorizV, v.mainBody, Planetarium.GetUniversalTime ()); v.orbit.semiMajorAxis = Target;

Another note: while engines have smallest accumulated chance of failure, parts that have the greatest are parachutes. The rebalance of this is literally vital (to kerbals, that is).

Thought a bit more about it, found the idea of increased chance of failure making no sense at all with the current mechanics. All it's adding is an extra annoying step of launching vessel and recovering it prior to actual launch. And increased build times with KCT. Maybe it will make more sense if failure chances transfered to the next launch if part was set to fail but didn't have enough time before recovery. But then, as a player I wouldn't like to just watch the rocket on pad for 30 minutes just to be sure it won't explode next time.

Judging by the code on Github, what the mod does is emulation of a prograde burn from where your ship currently is to get to the orbit with a target SMA. This ensures that ship does not change its position in space after correction (the initial and new orbits intersect exactly where ship currently is). But when orbit is going to change to a new one, and the new one isn't intersecting the old one at ship position, then the ship needs to jump. And the question is, where exactly should it jump and how is it physically possible?

Thanks! So far, so good. First flight: got failed reaction wheels and leaky tank, failed to get to orbit. Second flight: did a test, recovered, flew for real. Got a stuck winglet on the launchpad. Reaction wheel stopped working midflight. First test are well, I suppose. Now, question. What are generations and how to increase them (especially, in Sandbox)? Some feature requests: - Failures for solar panels and antennae (would be fun to see panels fail to retract and burn on reentry) - Width of failure time distribution depending on part type. For engines, about Isp/2, for other stuff 30 minutes is actually an excellent value (meaning most failures happen within the first orbit). - If possible, a change of failure model for engines. Currently, the total chance of failure may be expressed as min(1, chanceOfFailure*(TimeInUse/1800)), TimeInUse is time in seconds part actually stays attached to the craft during the mission. From here, you can clearly see the flaw: lower stage engines are going to have much lower failure rates because they don't stay together with the rocket for very long. A model for engine failure, if I may: 1) At the initialization, set a flag for each engine if it's going to fail at all on this mission. 2) For each engine to fail, choose whether it's going to happen at ignition or midflight (say, 75% from the total fail chance is at ignition, other 25% midflight) 3) Choose the failure mode. 4) For engines set to fail at ignition, apply the failure mode when engine is activated. 5) For engines set to fail midflight, calculate failure time when they're activated. 6) For more realistic behavior, time to failure should be gaussian with standard deviation 1-3 min, so let it be Isp/2, where Isp is vacuum specific impulse in seconds.

OK, started game afresh, now KCT can't build anything at all. Wasted the old save in the process. Last time I built a ship with only KCT installed, then copied ScrapYard and UPFM to GameData, and managed to launch. I suspect my MagiCore from KCT is inconsistent with ScrapYard or something. Found the code which sets the failure time. Uniform time distribution and 30 minutes put the typical time to failure of first-stage engines too far into the flight. I think, it's better to set gaussian-distributed failure times (here is the explanation how this may be done) with standard deviation, say, 2 minutes for engines and 30 minutes for everything else. Another mathematical issue is this: if (SYP.TimesRecovered > 0) chanceOfFailure = chanceOfFailure * ((SYP.TimesRecovered / expectedLifetime)); Maybe try this way: chanceOfFailure = 1 - (1 - chanceOfFailure) * Math.Exp(- SYP.TimesRecovered / expectedLifetime); This ensures that chanceOfFailure always < 1 and eliminates the need for "if" check.

The only log line with UPFM in it is: [GameParameters]: Loaded custom parameter class UPFMSettings. So, probably, nothing at all. Is mod supposed to work on Linux? I haven't gone past LKO, though. Log file And time of failure has something like gaussian distribution? From what I can understand in the code engine is only going to fail if it's on at the failure time. So, if an upper stage engine is set to fail 1s into the flight, it won't do so? If so, maybe it's more realistic to reroll after each staging? It also would help to set engine fail times within a minute or so, so they have higher chance of being not yet jettisoned when scheduled to fail.

Tried a launch in Sandbox, nothing bad happened. Disappointed Do not want to test this in career because of possible save breaking. So, a question: is it possible, for testing purposes, to make a failure chance multiplier somewhere in Settings or config file? Raise Also, how is the mod supposed to know mission duration for a part to fail at certain chance per mission? Or all the failures just happen at launchpad?