Mystique

Should've been 1.2 (I'm updates via CKAN regularly). I've had an issue of crash during loading since KSP 1.3, was sorta solved by rolling back module manager to 2.7.6 (last 1.2.x version). Game launched normally, but I can see that strange things happening (like kerbonauts in main menu got some strange parts on their backs instead of normal EVA backpacks), perhaps, it's also MM version-related problem. Couldn't launch KSP 1.3 with MM 2.8 (though it launches well w/o mods and w/o MM and all those mods that are using it). Will try to play with mods and MM around, perhaps it's actually my local issue.

Really? My KSP 1.3 launched without any objections with MM 2.7.6 (while it's crashing around end of loading with MM 2.8.0), while KSP.log is spammed with "[something] has no database record.Creating" entries.

Since 1.3 one of my ships fails to load, saying that missing "us.1r110.wedge.kiscontainer". When I search for it in game folder, I find GameData\UniversalStorage\Parts\US_1R110_Wedge_KISContainer folder with files KASContainer.dds, model.mu and US_1R110_Wedge_KISContainer.cfg. At first look it seems that part should be there, but not detected on loading savegame. In save's persistent.sfs I found record: "... PART { name = US.1R110.Wedge.KISContainer ...", while in US_1R110_Wedge_KISContainer.cfg I see "name = US_1R110_Wedge_KISContainer". Could it be that naming changed after update and game can't like part from mod's folder to existing vessel?

Try rolling back MM to ModuleManager.2.7.6.dll, it's available in corresponding topic, helped me to launch game at least.

Had startup crash issue, only thing that helped to launch game was rolling back MM to ModuleManager.2.7.6.dll. Not sure how stable it'll be though.

See no problem using SRBs as 1st stage, if they provide required thrust to avoid extra gravity losses (I do it often, especially with smaller rockets, which need 2-3 SRBs+a sneeze to get to LKO). The only possible issue is control - as SRBs lose mass and gain TWR, it becomes quite hard to control rocket with winglets&reaction wheels, if such problem occurs, having some LFO engine with good gimbal range is a good idea. On the other hand, I use SRBs as TWR-booster only for large rockets and/or when available LFO engines can't provide enough thrust.

Use this sometimes when ship's config allows to freely rotate both ships and I'm too lazy to do normal docking. But it feels somewhat cheaty and totally not as funny as to dock ascent vehicle w/o RCS (no questions why it didn't have RCS) to powerless orbital module (big fuel tank with docking port, doing this sometimes to reduce mass and get more dV), which is rotating due to accidental collision with ascent vehicle. And yeah, that ascent module has power for sas for ~1 minute of maneuvers, about 20 dV and sun is almost set, so forget about solar panels.

Can someone enlighten me how to use landing predictions from landing guidance window for bodies with atmosphere? I set up my orbit so that I should land in some sport after aerobraking, as shown by predicted trajectory. But when I actually enter atmosphere, predictions suddenly starts changing as I start to actually lose speed, which breaks all plans P.S. Had same problem with Trajectories mod, removed it as soon as noticed that feature in MJ, since they seem to produce same results.

Sorry, didn't notice previous report. Thanks for keeping it running

Sometimes (much more often than needed) clicking SM button on toolbar doesn't do anything or clicking any item in SM menu produces same 0 effect). Here's a screenshot with log entry after clicking on stuff inside SM window:

For jets - start engines and hold brakes as long as they can hold craft in place (sometimes viable for low-TWR designs). For rockets doesn't make sense, they go to max thrust output generally instantly, so holding them on ground will be waste of dV and risk of craft breakdown.

Sorry, just got back to KSP to do it. I was able to recreate bug in this way only so far: 1. Build cargo for hauling (say, cupola+hitchhiker container). 2. Rotate it upside down - this seems to be 1/2 major steps. 3. Attach docking port or decoupler to cupola (seems to be same effect). 4. Build command pod and all other stuff below that docking port, including lifter stages. 5. Select command pod (normally facing) as new root - 2/2 major steps. 6. See that KER dV calculation (and TWR) is different from MJ as shown on screenshot. 6a. Strange thing is: if I detach lowest stage, dV/TWR reading become the same, when I put that stage back, MJs data becomes incorrect, though lower stages shouldn't affect dV/TWR of upper ones in any way. Saving/reloading craft didn't help. Hotfixed by reattaching cargo (starting from stack separator, i.e. first part attached to new root). Guess it's cause by MJ not updating new part hierarchy (wild guess, I dunno how it works under the hood anyway ). Craft file on dropbox

Not a drop of it on this craft, just some monoprop+LFO. Also noticed that I had a docking port (used as decoupler between return pod and attached station module) staged, it also cause dV miscalculation in flight (MJ calculated MJ and if this stage must've been immediately dropped, unlike KER; was solved by putting docking port stage in top of list, i.e. even above chutes). Still think it was caused by rerooting (and also by flipping initial root parts upside down), will test on other crafts.

Using build 2.6.0.0-685. dV readouts on VAB are strange - when I attached new stage, it recalculates dV amount for upper stages as if it ignores decouplers of something (nothing unusual, simple vertical rocket). KER shows normal calculation at the same time. Any ideas (besides stopping using untested dev builds )? Temporarily fixed by changing root to other part then changing it back + reattaching all those lower stages, dV came back to normal and corresponds to KER. Really strange anyway, though, only guess so far is that I used rerooting at early stages of building, even before attaching first stage (I've made station module, then made a tug, selected tug's pod as root, then detached and attached module, which was "above" tug in VAB, maybe is misguided calculation somehow).

Good research. I'm not really math type (unless it comes to money), but generally tried going as close as horizontal/0 degrees pitch as possible, while avoiding terrain features and keeping vertical velocity somewhat above 0 (totally 0 isn't good idea in low altiltude, since sooner or later something big and rocky will appear in your way). Which your math did totally confirm

You pushed stage button, chute on dropped part deployed and got ripped apart by aero forces/heat, but part itself ("unpacked") was still there, this is what SR checks for, it doesn't take into account deployment state of chute. To avoid these messaged, you may just jettison parts without deploying/arming chutes at same time, it'll still work in SR. P.S. I get same minor problem, even though I use Realchute with arming when staging, so it should just arm, not get deployed immediately. It doesn't affect anything from recovery point of view, just doesn't look that cool.

Updated to 1.3.6 (CKAN), this is what I get from SIGINT: Is it working as intended?

Launched station with SIGINT. SIGINT antenna is deployed, but doesn't connect to network, despite being on LKO. Is it working as intended? I didn't even thing about adding any other antenna because of this monstrocity.

Or you can use MJ's (or any other mod's, there definitely should be some for this case) handy "prevent jet flameout" utility, which will automatically throttle down up to point of 0 throttle and don't bother with engine/intake placement order.

Can't see anything about immediate level up difficulty option. I've enabled is (since, wth, guys just inserted that flag into Mun surface, didn't he get more experienced right now?), but green guys get leveled up upon recovery, as before. Don't see anything on forums about this issue, maybe I'm the only lucky one?)

I've noticed that when I rename vessel and type "y" somewhere, TCA gets turned on (guess I just found its hotkey w/o reading manual). Is it working as intended? Kinda strange that hotkey toggles, when text input window is active.

Sorry, maybe I missed the point, so: is there any way for TR'v visor (real-time) + Scatterrer to work together normally, at the moment?

Sorry for bumping old question, is there any fix for "dark bar" issue? I'm talking about thing like this, when there is transition line clearly visible at some angles:

Yep, switching was the only way I found to do it. Seems like there is no other option (quite strange, though, stored science really ask for some more convenient browser/manager, especially for miltiplanet trips).

I finally decided to ask a question that was annoying me since ~0.18: If I have multiple science reports in 1 part, then I click "review" in right-click menu and then I must do something about each of them (i.e. keep/discard/transmit). Say, I found and transmitted the only report I wanted, how to quickly close that window without clicking "keep" for each report (vessel switching/EVA doesn't count)?