Omnipius

Is this a known conflict? I've noticed that it also glitches the most recent version of Kopernicus.

I'm having a very bizarre problem with LR89 engines. When I try to fire them, the fuel gauge comes up, the throttle, thrust, and temperature readouts in the detail menu ramp up, but mass flow and ISP stay at zero. No fire, no actual thrust generated. Meanwhile, the LR105 and LR101s fire up just fine. I thought maybe it was the Atlas booster decoupler, but same issue when directly connected to the tank. I checked and the part is fully researched and owned. I haven't found any errors or exceptions in the log either. Is there something I'm missing or is this broken?

FYI, Persistent Thrust is broken by Kopernicus 67+ (through 68 at time of writing). Null ref spam on the GetRequestedDirection call when trying to save a vessel in flight, causing all attempts to save or exit flight to fail. Log is Here

This is still happening with 68. It appears to be a conflict with PersistentThrust on a get direction call. Log is linked below: KSP_Kopernicus68-PersistentThrust_Conflict.log

Release 67 breaks my 1.10.1 RSS/RO/RP1 build in an interesting way: If I try to quicksave or exit a flight in any way (recover, go the space center, go to tracking, even exit to main menu) all I get a bunch of null ref errors and then nothing happens. I'm just stuck there, game still running, physics still happening, no more null refs, but: YOU! SHALL! NOT! LEAVE! (or do anything that results in a save) I just rolled back to previous release and sure enough everything is fine. I'll have to roll forward again tomorrow to reproduce the error and get a log copy.

For the RO-RSSVE package you need RSS and this version of EVE (and scatterer). Find the RO-RSSVE repo on github and follow the instructions there. My question for the crowd: I have the aforementioned RO-RSSVE package running, along with a lot of customizations. These include major main and Kuiper belt objects, procedurally generated minor main, kuiper, trojan, NE objects, minor outer solar system moons, multiple star systems complete with moons etc, animated auroras, lightning, geysers and more. Believe it or not, at 4k this brings my 500W RTX 3090 down to 35 - 45 fps in flight. (Forget can it run Crysis, can it run Kerbal?) That's perfectly playable, so there's just one thing that annoying the hell out of me: Earth is just too darn cloudy! Short of creating all new custom alpha maps, is there a setting in EVE that would just thin things out a bit? I want about 30-50% of the current cloud cover.

I'm having an issue with Dynamic Battery Storage as a dependency for NFE. This is causing NFE to get kicked out of my RO/RP-1/Kerbalism build now that DBS conflicts with Kerbalism. I've been told that NFE might not technically require DBS. If DBS is not actually required, can the CKAN relationships be changed or overridden?

RP-1 v1.10+ shows as conflicting with Dynamic Battery Storage in CKAN. Is there a reason for this? Might there be a work around for allowing Near Future Electrical and Kerbal Atomics? I'm trying to do a sort of alternate-history career.

[WRN 00:04:28.827] Errors in patch prevents the creation of the cache [LOG 00:04:28.940] ModuleManager: 204742 patches applied, found <color=orange>2 errors</color> 2 errors related to GameData/KerbalismConfig/Support/SXT.cfg Is there a way to override that warning and force cache creation? I'm also trying to sort out what's wrong with SXT's Kerbalism config: [LOG 00:01:27.289] Applying update KerbalismConfig/Support/SXT/@PART[SXTDepolyRTGI,SXTDepolyRTGII]:NEEDS[ProfileRealismOverhaul,SXT]:FOR[RP-0-Kerbalism] to SXT/Parts/StationsBases/Electrical/RTG/part.cfg/PART[SXTDepolyRTGII] [ERR 00:01:27.290] Error - Cannot parse variable search when inserting new key capacity = #$../MODULE[ModuleGenerator]/OUTPUT_RESOURCE[ElectricCharge]/rate$ [LOG 00:01:27.290] Applying update KerbalismConfig/Support/SXT/@PART[SXTDepolyRTGI,SXTDepolyRTGII]:NEEDS[ProfileRealismOverhaul,SXT]:FOR[RP-0-Kerbalism] to SXT/Parts/StationsBases/Electrical/RTG/partBasic.cfg/PART[SXTDepolyRTGI] [ERR 00:01:27.290] Error - Cannot parse variable search when inserting new key capacity = #$../MODULE[ModuleGenerator]/OUTPUT_RESOURCE[ElectricCharge]/rate$

Once upon a time, MM created a cache of it's patch configuration and only re-solved if the patches were altered. Is this still the case? Mine is doing a fresh solve at every load even if I haven't changed anything.

Sounds good! Thanks or the update and all the hard work!

With Kopernicus and RSS both supporting 1.9.1 now, should we be expecting an RO update in the near future? Or is the plan to just wait for them to catch up to 1.10.x?

I realize from your past posts that English is probably not your first language, but you really should review this pinned post at the top of the Addons board: The community does want to help. There's just not enough information in any of your posts to be able to help in a meaningful way. We need a screenshot of the issue in action, a copy of your KSP log file, a copy of your ModuleManager cache file, and a detailed description of how to reproduce your issue. Folks aren't on the forums often enough to ask a bunch of questions to get to the bottom of the problem. Take it from someone that has 4200+ hours of KSP under their belt. For example: Did you do the reinstall that @hypervelocityinstructed you to? Judging from your GameData folder, you really should be using CKAN and nothing else when it comes to installing and updating mods. That includes AVC. Which probe core are you using? A lot of early probe cores only have thrust and staging control, not attitude control. Sputnick was just a metal ball with a battery and a transmitter that said "BEEP". Do you have an active comm connection to a ground station? Probe cores can only do a command if they have an active comm connection to receive it or are executing a kOS script that was commanded when it did. It's also possible to be out of range if your comms aren't good enough, or you could be out of EC, or bunch of other things...

I'm getting a strange issue with AmpYear in KSP 1.7.3, running RO / RP-1 along with TAC-LS and USI-MKS: The KSP loading sequence gets stuck when it tries to compile the USI-MKS Tundra PDU part. KSP doesn't crash or even become unresponsive. The loading screen continues to turn over, but it doesn't progress. No warnings, errors, or exceptions are thrown in the KSP log. Removing AmpYear allows the game to load normally. Thoughts? Suggestions? EDIT: SOLUTION FOUND It turned out to be an issue with the AmpyYear MM config file. The definition for integration with RO is incorrect. Why this causes it to choke on this particular part? I have no idea. However, the fix is simple because you change one line: @RESOURCE should be @RESOURCE[ReservePower] Happy to submit an issue on github or just upload my fixed version if you'd like.

So this is an RO issue? What would need to be changed about the RO patches to correct the issue? I'll happily implement the fix if I can understand how to clear the issue for any one part.

The correct versions as installed by CKAN.

On KSP 1.7.3, running the latest versions of RO/RSS/RP-1, along with latest versions of B9PartSwitch and BDB, I get this set of serious warnings on BDB engines: Any thoughts on what's broken here and how to fix it?

I'm seeing some strange behavior out of my city lights. Namely, the "dark" texture that actually has the lights is rendering during the day when in flight. Any thoughts? I'm running KSP 1.7.3 with RO, RP-1, and RSSVE. All of those have been heavily customized to implement detailed environments across a number of different star systems. I can provide cfg copies if needed.

This is correct. I can add an AvGas tank to the parts, but the KCT fill tanks option doesn't fill them. Possibly because the original parts don't have any fuel capacity? It worked in the previous version of KCT, but that was the only version that it ever worked in. For now, I've worked around the issue by upping my realism by implementing fuel tanks in the wings and ballast in the tail.

Indeed. RO_SXT_Bonanza.cfg changes the parts to have fuel capacity. Maybe it's the late addition that's the issue? Here's the current ModuleManager.ConfigCache

Oh, It's labeled in the SXT files as "Bonny", specifically "625mBonny" as the internal name. I think RO relabels it as a Beechcraft Bonanza since that's what it is.

I'm running into a strange problem with the newest version for 1.7.3: The fill tanks function isn't working for the Bonanza Cabin and Bonanza Tail in RP-1. It works jut fine for procedural parts though. Any thoughts on how to fix?

I'm getting strange behavior from kOS on a simple sounding rocket script for use in RO/RP-1: LOCK THROTTLE TO 1.0. STAGE. WAIT 1.0. STAGE. WAIT 0.7. STAGE. What's weird is that the throttle appears to unlock and drop back to zero every time the rocket stages. So, the rocket stops flying after the first stage. If I comment out the lock and set the throttle manually, everything works out just fine. Any thoughts on what could be causing this and how to fix it? Could it be a bug?

I think I've narrowed my matching issues down to how RealFuels implements multiple tank configurations. So, I want to block ModuleFuelTanks from being stored but still let the part be stored. SY_FORBIDDEN_TEMPLATE blocks the module, but also the entire part. Is there a way to define a module template that shouldn't be stored without preventing the entire part from being stored?