arisian

I have also been having this bug since 1.2, and it's still present in 1.2.1. I'm running KSP64 on linux (arch, linux 4.8.4-1, 64bit). GPU is a GTX 580, driver version is currently 370.28 (though I'm pretty sure I've updated the driver at least a couple of times since the problem started). I've tried playing with "image quality" settings, with no impact on the issue. There also seems to be some other minor texture glitches that look like Z-fighting to me (particularly around the launch pad in the main KSC view) that I don't remember from 1.1 and earlier.

Thanks, that did the trick! Maybe the OP should be updated with a note that the current CKAN build is broken?

I'm having an issue on Linux x64 where the module fails to load; anyone else seen it/know how to fix it? I get the following error message in KSP.log on launch: I'm using "AFBW-Linux 1.7-beta" installed via CKAN, libSDL2-2.0.so.0 is in /usr/lib/ (from distro), and I'm running KSP 1.1.2 (and I saw the same error in KSP 1.1.1).

Yeah, I know that, and I try to stick to it, but...there's just so much great stuff out there! First off, how can I live without quality-of-life enhancements like EnhancedNavBall or KerbalAlarmClock or ScienceAlert? I doubt those would conflict with RO/RP-0, but they're not listed as "supported" in CKAN. And then there's the fact that I think RP-0 is great for the "historical" missions; I've got no problem with more-or-less recapitulating history up to Apollo. But post-Apollo, the history is just kind of depressing. I want to simulate the alternate future, the one Gerard K. O'Neill envisioned! Sure, maybe heavy lifters turned out to be harder than he expected, and his population numbers weren't quite right, but it was such a hopeful vision of what the future could be. I want the version of history where funding stayed at Apollo levels, and the shuttle program didn't fail to meet its design goals for cost/reusability, and we wound up with permanent manned bases and habitats. And for that, I eventually need some parts that *aren't* purely "historically accurate", so I eventually start looking at things like USI Kolonization once I've worked my way far enough up the tech tree that I start wanting proper orbital habitats or moon bases, and AtomicAge so I can blast off using a (wildly impractical) nuclear lightbulb, and, and, and... ...and then I discover that I've added too many things, and everything breaks, and I have to wipe all the mods and start over with a clean install and a fresh game and go back to 1955 and try again. I fully admit that none of my problems are your fault, and I totally don't expect you to support my non-standard configs; you already do so much fantastic work here, for which I'm completely grateful. I was mostly trying to figure out what was going on because I was confused, not trying to lay the blame at your feet, or make more work for you (though if you want more work, I have to admit that I'm really looking forward to RVE hitting a semi-stable release... ).

It was a clean install, but I do have some other mods besides RP-0, including TAC-LS and some USI stuff. The craft in question had plenty of life support supplies, as evidenced by the fact that switching pilots solved the problem (i.e. re-load a savegame with the rocket still on the pad and re-launching using a different pilot). That was why I though maybe there was something going on with RP-0 or KCT. If it's an issue of TAC and USI fighting each other, then it's really weird that it would be tied to specific Kerbals, rather than vessels...

So, I'm not 100% this is an issue with RP-0 (i.e. might be a dependency like RO or KCT), but I can't find any information on it anywhere. I'm having a problem where, when I go to launch a vessel, I get a message saying "<pilot name> refuses to work", after which the game seems to treat the pilot as a tourist (i.e. can't take crew reports, can't do EVA). Is this a "feature"? If so, can someone explain it to me? What are the conditions under which a Kerbal will refuse to work, and what will remedy the situation? I don't think it's a problem with the vessel, since if I assign a different Kerbal to the craft, everything works normally.

So, not to distract everyone from The Noble Quest for 1.0, but is there any way to get mechjeb to use RCS properly for (non-docking) manoeuvres? I totally understand that real spacecraft use RCS for rotation, rather than "magic reaction wheels", and I think it's admirable that RO encourages us to do the same. Unfortunately, MechJeb seems built on the assumption that stock-like reaction wheels are present. When you're under thrust (and using a vectoring engine), this isn't a problem, but any time you're not under thrust (e.g. trying to orient to a manoeuvre node) it's a giant mess. Firstly, RCS needs to be enabled manually or it will sit there forever doing nothing. Second, once RCS mode is on, it spends far more fuel than is necessary, thrusting continuously (rather than an initial burst of thrust, patiently waiting, and then a final burst to stabilize, with perhaps a small correction or two if needed midway). Third, once the orientation is correct, it will continue to waste fuel indefinitely, making tiny oscillatory changes around the desired heading. Also, MechJeb has a tendency to make large shifts to heading during engine start/stops, which results in large and undesired rotations at the beginning or end of burns. So far as I can tell, all of this is a result of the fact that MechJeb assumes it has stock engines and reaction wheels, meaning that it thinks everything is infinitely throttle-able (including rotation), and that applying rotational torque is basically "free" (since electricity in stock isn't very hard to come by, this is generally an okay assumption), as well as assuming that most craft will have enough torque to rotate to any desired heading relatively quickly. Since none of these assumptions hold in RO, we have problems, especially with large craft. Is there something I'm missing that would get MechJeb to behave nicely, or is this just something I should go beg for on the MechJeb thread?

As I was playing around with the J-2T, I ran into this issue, and I agree that I can't imagine actually using this engine for its intended purpose without any kind of vectoring. Some searching on the internet found the following paper: http://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=1059&context=spacegrant It looks fairly recent, and clearly they haven't actually flown rockets with this configuration, but they did actually do experimental testing (as well as theoretical modelling). The effective vectoring range may be more limited than some types of bell-engine gimbals, but it looks like it's at least possible to do this kind of TVC on a toroidal aerospike type engine. The study wasn't specific to the J-2T, and it was pretty recent, so I doubt this was really part of the "original" J-2T design. But given that the J-2T was never put into production anyway, it seems reasonable to me that we could extrapolate these results to let the RO version of of the J-2T have at least a few degrees worth of thrust vectoring control. It would make it a heck of a lot more useful; without any kind of TVC, it's pretty useless in atmosphere (since you can't compensate for drag while doing a gravity turn), which rather defeats the point of it being altitude-compensating. Baring that, we could postulate a HydroLOX version of a vernier (e.g. LR-101 or equivalent), which could help compensate, but it would be significantly less elegant.

Looks like re-installing the tech manager and then starting a new game fixed it; still not sure what was wrong before, but the new game has all the stock parts I'd expect. Thanks for helping troubleshoot!

The install was done using CKAN; I didn't download anything manually (well, other than CKAN itself). If that's the timeline research is on in RP-0, I guess it's just something to get used to; if I'm supposed to have equipment I don't, on the other hand, maybe I should re-do the install.

So, I've just installed RO and RP-0 into onto a clean (stock) install, using CKAN. I love the idea of it, but I'm confused by some things. Firstly, the how-to seems to indicate that I should be able to put a thermometer and barometer on my first sounding rocket, but those don't appear to be researched (and they don't show up in the first two nodes I can see). I'm using the (modified) community tech tree. This makes getting research hard early on; about the only source seems to be the build-based research from KCT (on account of having to make ~10 rockets to get one where the engines don't loose thrust or shut down early). Then, once I'd finally accumulated the 25 RP needed, I tried to unlock the Early Orbital Rocketry tech, but KCT tells me it will take 625 DAYS to complete the research, despite having put two points into research (it says 1RP/day, which seems like it should get that tech done in 25 days). Is all of this "working as intended", or is there something messed up with my install? The only "non-recommended" mods I've got (i.e. apart from the stuff CKAN requires for RO and RP-0) is FASA and KW-rocketry.

Just another report that *all* parts appear to be hidden at all times using 1.15 (I've got a bunch of other mods installed, but never had a problem with any previous version of FilterExtensions).

The control setup I want for a rocket is not the same as the control setup I want for an airplane(/spaceplane). It seems to me that the easiest fix would be to just add yet another control type; "staging" for rockets (anything built in the rocket hanger), and "airplane" for jets (anything built in the plane hanger/flown from the runway). Maybe have a "use same controls as staging" option, the way is currently done for docking. I'd be happy to mod this in myself if someone would give me a pointer as to where to start, but I haven't found any mods that touch any of the control stuff. Anyone else have any thoughts for other/better solutions to this issue?