gemini4

I'm still having the exact same problem. I tried replacing Kopernicus with the latest backport for 1.2.2, tried using both Scatterer 0.0300 and 0.0320, deleted your patch, checked that my EVE is the right version, checked that my version of RSSVE is the latest version, and nothing worked. I notice that I am unable to bring up the scatterer menu through Alt-F10 or Alt-F11, either in the menu or in-game. I wonder if that has any relation to my problem.

I just moved my RO/RSS install from 1.1.3 to 1.2.2, and, of course, I wanted a visual pack. I figured I'd choose something other than RVE, since that seems pretty outdated at this point. So, I was really happy when I found this mod, as it seems to fulfill the same purpose. However, I'm having the same problem that KSPLenny:D, RocketBlam, and Jack95970002 were having, which was the dark blue sky, fading to bright green and red as I gained altitude, while the night sky was completely black, and the scatterer features were not working at all. I made sure to install Scatterer 0.0300 as that seemed to be the problem for the last person I mentioned. However, this did nothing. I also installed the RSSVE patch thoughtfully provided by Galileo. However, this also failed to fix the problem. Currently, the sky in my install looks like in the pictures below. I've provided the output log below. Here's a complete list of mods I am using in this install. Semi-Saturatable Reaction Wheels v. 1.12 [x] Science! v5.6 AIES Aerospace v. 1.6.1 AJE v. 2.8.0 ALCOR v. 0.9.6 Alternate Resource Panel v. 2.9.1.0 ASET Agency v. 1.0 B9 Procedural Wings - Fork v. 0.40.12 B9 Part Switch v. 1.7.1 Community Category Kit v. 1.2.2.0 Community Resource Pack v. 0.6.6.0 Community Tech Tree v. 3.0.3 Connected Living Space v. 1.2.4.2 Constellation Essentials v. 1.4 Contract Configurator v. 1.22.2 Cryo Engines v. 0.4.6 Cryo Tanks v. 0.3.5 Custom Barn Kit v. 1.1.12.0 Deadly Reentry Cont. v. 7.6.0 Deployable Engines v. 0.3.5 DOE v. 1.8.1 DOE-RSS v. 1.8.1 DMagic v. 1.3.8 EVE v. 1.2.2-1 Engine Lighting v. 1.5 FASA v. 7.2 FAR v. 0.15.8.1 Filter Extensions v. 2.8.1.2 Final Frontier v. 1.2.7-3080 Firespitter Core v. 7.5.1 Firespitter Resources config v. 7.5.1 Forgotten Real Engines v. 0.7.1.0 Freedom Textures v. 1.5 Hanger Extender v. 3.4.9 JSI Advanced Transparent Pods v. 0.1.13.0 KCT v. 1.3.5.7 KJR v. 3.3.2 Kerbal Renamer v. 0.7 Kopernicus v. 2:release 1.3.0-4 KRASH v. 0.5.22.1 KSCSwitcher v. 0.7 KSP AVC v. 1.1.6.2 KW Rocketry v. 3.1.4 MagiCore v. 1.2.5 MechJeb2 v. 2.6.0.0 ModularFlightIntegrator v. 1.2.4.0 Module Manager v. 2.7.6 Persistent Rotation v. 1.8.4 Planet Shine v. 0.2.5.2 Procedural Fairings v. 3.20 Procedural Fairings For Everything v. 0.20 Procedural Parts v. 1.2.11 Procedural Parts- Mainsailor's Procedural Textures - Essential v. 2.0.0.0.1 Procedural Parts - Mainsailor's Procedural Textures - Complete v. 2.0.0.0.1 RasterPropMonitor v. 0.28.1 RasterPropMonitorCore v. 0.28.1 RCS Build Aid v. 0.9.1 Real Fuels v. 12.2.1 Real Plume v. 10.5.1 RSS v. 12.0.0 RSS Textures - 8192x4096 v. 10.4 RealChute v. 1.4.3.0 RealHeat v. 4.4 RO v. 11.5.1 RP-0 v. 0.54 Reentry Particle Effect v. 1.2a RT v. 1.8.6 Retractable Lifting Surface Module v. 0.1.3 RSS Date Time Formatter v. 1.1.0.0 SCANsat v. 16.11 Ship Manifest v. 5.1.3.3 Smokescreen v. 2.7.5.0 Solver Engines v. 3.1 Soviet Engine Pack v. 0.3 StageRecovery v. 1.7.2 SXT Cont. v. 0.3.12.1 TACLS v. 0.13.0 Taerobee v. 3.0 TestFlight v. 1.8.0.1 TextureReplacer v. 2.5.4 Toolbar v. 1.7.13 Transfer Window Planner v. 1.6.1.0 TriggerAu Flags v. 2.9.2.0 VSR v. 1.9.6 Output Log Images: The Sky's Messed Up Apologies if I failed to follow the proper bug report procedure. I tried to follow your instructions to the letter, but I'm sure I missed something. Thanks so much for your help.

Okay, so I thought the issue regarding space station contracts had been fixed. I launched a new space station, docked to it, then waited for the specified time. However, upon undocking, the contract parameter for "return the crew home" continued to track the station, not my crew capsule, as the return vessel. Another parameter, however, called "keep the station in orbit" also tracked the station. So, there are two problems I face. One, I didn't equip the station with a heatshield or parachutes, so I can't possibly return the crew in it. (Even if I did include those, it wouldn't be aerodynamically stable, and would probably tumble and burn up). Two, I can't keep the station in orbit and return crew in it! Is there a way I can get the contract to recognize my crew capsule as the return vessel? I though Contract Configurator had fixed this particular issue. Maybe it's an issue with the RP-0 contract itself. Does anyone have any advice on how to resolve this issue?

I solved the problem by just deleting the old contract from the save file. I thought that would lead to save corruption, but everything seems to be working. The "First Space Station" contract is now available from the mission control building.

@leudaimon I actually tried doing exactly that, but the game saved the vessel ID of the original station, and so didn't recognize the new station as the one for the contract. I think there's a contract in RP-0 for a "new space station," but I can't get that one to trigger. The contract configurator window for it says "unknown: not met."

Is there a way to reopen previously completed contracts? I had an issue (this was several months ago) where, when attempting the "first space station" contract, docking and undocking from the station would reset the "crew required" and time duration parameters. As a result, I was unable to complete the contract fairly and had to manually force it to complete through a text editor. After I was done, I destroyed the station to make sure I never tried another station mission, to avoid the hassle I went through the first time. Now, this issue has been fixed, and I'd like to start doing station contracts again. However, the only ones available are "station crew rotation," which tell me to rendezvous with a non-existent space station. Is there a way I can reset the "first space station" contract, so I can complete it properly this time?

Is there a way RP-0 could incorporate contracts to orbit satellites of specific masses, and adjust rewards accordingly? There doesn't seem to be a point to using the larger probe cores, or building heavy-lift rockets, for this reason. As a result, I don't find myself using a lot of larger, more expensive engines or probe cores, when lighter, smaller rockets and probes can fulfill all satellite contracts at lower cost. I'm sorry to bother you when you're working on a new release. It's just been a consistent annoyance for me in RP-0.

Is there a way to disable rated burn times in the difficulty menu, or do I have to manually edit config files for each engine? There are some great engines in RO that have low rated burn times. It might be slightly unrealistic, but I like to be able to have engines burn for very long amounts of time. (Ex. XLR81, which was designed to burn for only about 4 minutes, which I often use for stages with 20 min. burn times) I haven't used TestFlight for this reason, so I'd be really grateful to know if there's a way to fix this. Thank you.

I love solid rocket motors. They can be great for reliable, fairly low-cost launchers, and I the constraints they incur. However, I feel like the procedural solid rocket motors become useless by the mid to late-game. Their dry masses are higher than the existing solids provided, and they a procedural booster costs a lot more than a provided booster of the same size. Together, this makes them nearly unusable when you have advanced solids available, which is a shame. I really like the ability to customize solid rocket motors to my liking, but their performance isn't good enough to justify it. Also, I've noticed that, in my install at least, procedural SRBs can only gimbal in one direction, which can make control very difficult. They also don't seem to have thrust curves, which isn't a huge issue, but a nice realism touch to have.

@Fizwalker Are your fuels settled? For most upper stage engines, the fuel stays stable for a couple of seconds following MECO, but after that, it is often necessary to use RCS or solid motors for ullage. If your're not getting the message "[Engine] has encountered vapor in feed lines and has shut down!" when trying to start your engines, then your fuel is stable. You can see that in the engine icon in the lower left. If it is red, your fuel is unstable, and your engine should not be ingnited. Most engines also require certain resources to ignite. For instance, many kerolox engines require TEATEB, although this is included by default, and typically matches the number of ignitions your engine has. Most other engines require ElectricCharge to ignite (presumably using sparkplug ignition systems, or some power to open fuel valves). Other than that, the only thing I can think of off the bat is to make sure that your staging is set up correctly.

I remember that after downloading Mainsailor's part textures, I was unable to choose those custom textures on tanks on previously constructed rockets. Does the same issue apply here, and, if so, will using previously created rockets cause any performance impact (My thinking is that the tank part files are outdated, and might be handled differently for some reason)? Thanks for the response. I like Mainsailor's textures, but find myself not using most of them. I can definitely see myself using a bunch of these textures, though.

I love this mod! Outstanding work on these engines, they make a wonderful complement to FRE. I just want to make sure before I download, however, are these engines RP-0 compatible?

Never mind the issue I was having before. It was specific to KSP 1.1.2. When I upgraded to 1.1.3, everything worked fine. Thanks for your help, though, @nightingale.

Ah, thanks. I typically make sure the mods are working in a test save file before opening up my actual save. Most of the time, I encounter little difficulty, and many mods that I am using on KSP 1.1.2 were built for KSP 1.0.5 and run without incident. Likewise, I am also running many mods built for 1.1.3 without incident as well, but I guess since orbital drift is handled differently in KSP 1.1.3 than in 1.1.2, this was one of the mods that has been drastically affected by the change.

@ebigunso I checked both in the settings.cfg and the in-game menu, and I can't find any instance of Orbital Drift Compensation. I believe the feature was introduced in 1.1.3 to stop the phantom drifting of orbits at 1x time acceleration. That's what makes me wonder if my copy of Orbital Decay, which is meant for 1.1.3, isn't working on my file because 1.1.3 handles orbital drift differently.

Hello. I have been playing on an RSS/RO save file that is based in KSP 1.1.2, with several mods from 1.1.3 installed without difficulty. I tried to install the new Orbital Decay mod, after issues I encountered with a previous version forced me to uninstall it (I mentioned this in the Realism Overhaul thread). I have since reinstalled Orbital Decay (thanks for your response in the RO thread, Whitecat), however I noticed that my orbits were not decaying. As this is a rather central feature of the mod, I would really appreciate it if someone could fill me in as to why this is happening. Is the 1.1.3 version not compatible with KSP 1.1.2, and if so, is there a version of the 1.1.2 mod that is still available for download? If you need a log, just let me know, and I can post it. Thank you so much for your response.

I'm sure this is already a known issue that has been discussed elsewhere in this thread, and I sincerely apologize for asking this again. I have an RP-0 install that I have been running since KSP 1.12, and although several of the mods have since been upgraded without incident, many have not, and thus still remain in their original state. This includes my version of CC. When attempting the First Space Station contract, I encountered the now-known bug, but I was too lazy to upgrade and simply terminated the contract. Fast forward two months, and I had a Human Orbital (2/LEO) contract, which I preferred to use an already launched "station" (More a food container with docking ports on the side) to facilitate this mission. Unfortunately, upon completion of the orbital parameters, undocking reset the contract. A perusal of the Github releases showed that a recent release had fixed this issue. "Wonderful," I thought to myself. Very fortunately, I made a backup of my version of CC just in case anything happened. When I installed the new version and booted up KSP, I found that all contracts were divided into categories, and each category had a drop-down list of contracts (I'm not sure how long this has been the case, I've been using an old version of CC for a very long time and have had few issues with it). That wasn't a real issue. The issue was that, while the auto-accept contracts were behaving normally, every RP-0 contract had no description and no option to be accepted. Thus, I was left with only the contracts I had already accepted, one of which was corrupted. Sorry to bring this up, and I know others probably have done so already. Is there anything I can do to fix this? I'd love to be able to complete my 2/LEO contract without editing the save file, but I obviously don't want to destroy my game. Thanks so much for your response.

I also have some questions about RO's handling of solid rocket motors. I don't know if it's just me, but attempting to use many of the KW and FASA strap-on solids causes my rockets to roll during my pitch program. I think it's something to do with the nozzles, which are normally angled slightly away from the rocket body, but I'm not sure what. Even symmetrically attached motors cause rolls which can become nearly uncontrollable. In practice, this has often limited me to only a few solids with non-angled nozzles. I can't use the procedural solids either, as I've found through experimentation that they are inferior in almost every way to the solids already present through RO and mods. The procedural solids' ISP increase with tech level is quite balanced, in my opinion, but I think the fact that the case mass remains the same regardless of tech level, as far as I can tell, makes them second-rate compared to the late-generation solids with similar ISPs but much lower case masses. In addition, a procedural SRB costs far more than an existing solid motor of the same tech level. These disadvantages mean I find myself very rarely using procedural SRBs, which is a real shame. I would really appreciate it if you could address some of my concerns. Thank you. Edit: I forgot to mention that the procedural SRBs also don't have thrust curves, which isn't a huge deal, but just a minor realism detail I wanted to address.

I'm not sure if this is the right place to ask this question, but would it be possible to have satellite contracts for satellites of specific mass? I really enjoy building heavy-lift launch vehicles for satellite contracts, but have little incentive to do so when the contracts available only require specific science instruments, power generation, an antenna, and basic avionics. In addition, the base "Position satellite in a specific orbit of Earth" contract offers little incentive in the later game when its rewards pale in comparison to others offered. I'd love to see that problem remedied. Thanks for considering my request.

I tried Orbital Decay in my most recent career file. It would cause arbitrary decay rates, as far as I can tell. I lifted a MK1 capsule and storable propulsion module into a 450km orbit, and it decayed in about 4 hours, while the less -dense, greater cross-section spent upper stage I had used for insertion stayed in orbit for a few months. Also, if uninstalled, all debris that had "decayed," and been destroyed by the mod, is still present, and crashes the game when attempting to delete it. This ended up clogging my tracking station window with scores of objects, none of which I could do anything about, and which I suspect, although I am not completely certain of the cause of the issue, reduced my frame rate in the tracking station window dramatically, and made it all but unusable for the rest of my save. I'm not sure if I'm the only one who has had these issues, however.

I know I asked this before and didn't get a reply, but I still want to know: Could there be a config for fuel cells that allows them to use HTP as an input resource? I've done some research just to make sure, and I can't see a reason why HTP couldn't be used as an input resource for a fuel cell. It has several advantages over the LOX/LH2 combination available now, not least its storable, as opposed to cryogenic, nature. It would also provide both water and oxygen, in addition to power, in its energetic decomposition. Thus, I think the addition of an HTP config to fuel cells would make them far more useful, especially in the early to mid-game, when they well outperform the available solar panels. As they can only be used with LOX/LH2 right now, however, I find myself using batteries instead for the early game because the boiloff is so limiting. I'd really like to know if we could see this configuration for fuel cells in a future update, and if there would be differences in power generation, etc. that we should expect. Thank you so much for your response.

As far as I can tell, fuel cells can only run off of LOX/LH2. However, haven't there been attempts to use HTP with a catalyst as a source of power, oxygen, and water? If I remember correctly, the moon rocket proposed by the British Interplanetary Society used just such a device. I would like to see a configuration for fuel cells that uses this fuel, as its storable nature makes it more practical than the conventional LOX/LH2 mixture offered right now. If there's a reason why fuel cells don't have this configuration, please let me know. I don't know nearly as much about rocketry as the developers of the RO suite, and I'm sure that there are very good reasons why the fuel cells in the game only run on LH2/LOX. Thank you for your response, though.

I'm probably missing something, but for the life of me I cannot find either of the Rutherford engines in my tech tree. I'm using the basic RP-0 tech tree, and all other engines showed up perfectly fine. What node are the Rutherfords supposed to be in? Edit: NVM, fixed after updating RP-0.

If the engines could be made to run on these alternate fuel grades, would there be any noticeable effect on performance? TWR would be better, since you're not carrying around extra water which won't be used in combustion, but would thrust and/or ISP increase? My intuition is to say that they would-a higher amount of ethanol, the fuel actually used for combustion, would be burned every second, and more of the combustion energy would go towards accelerating the exhaust products of the ethanol/oxygen combustion, not heating water. Again, though, I'm not an expert on rocket propellants. I'm just trying to determine whether or not there's any point in creating more engine configs for these alternate fuels.

I noticed that using fuels such as Ethanol90 or just straight Ethanol with an engine that normally requires Ethanol75 do not allow the engine to function. Although I am by no means an expert on early 1940s-1950s rocket engines, I think the reason they used Ethanol75 was just to prevent overheating and that a higher-grade fuel such as Ethanol90 would have worked with the engine, but caused more damage to it. I'm wondering if it's possible to configure engines such as this for use with Realfuels and TestFlight so that they could use these higher-grade fuels with higher thrust/isp, but would suffer reliability issues since they were not designed to run on them. In a similar vein but slightly different, allow certain RD- engines using kerosene to run on syntin, with higher performance but more fuel cost and reliability issues. If I'm getting something completely wrong about how these engines work, let me know. I just thought that these different fuel configurations might be a good idea. I have no idea how to implement them myself, but I'd like to know if they seem like worthwhile ideas, and, if so, we can expect to see them in a future update of Realism Overhaul or Real Fuels.