SpacedInvader

I'm curious if this patch ever made it into TweakScale? I'm getting this same behavior (up-scaled solar panels do not produce up-scaled power) in my test install with just TweakScale (2.4.7.1 installed manually from Github along with Recall 0.4.0.1 and UberPaket 2023.3.28.4 just for good measure) and Other Worlds + Kopernicus (installed through CKAN). After looking through the MM config cache, it appears to be the same issue described by Tonas1997 where TS is targeting the vanilla module, but OW/Kopernicus have replaced it with "KopernicusSolarPanel", so TS doesn't actually update the power module. Including logs + MM cache: Logs EDIT: Doing a sanity search for "KopernicusSolarPanel" in CFG files within the test install's GameData folder shows that TweakScale makes no reference to this module, so I'm guessing the answer to my question is "no". This prompts me to ask, would a custom CFG file with this fix this issue? TWEAKSCALEEXPONENTS { name = KopernicusSolarPanel chargeRate = 2 temperatureEfficCurve = 2 } Thanks EDIT2: So I've tried to use the above code both in a custom config file, and by inserting it into 020_ScaleExponents.cfg immediately below the same block targeted at "ModuleDeployableSolarPanel" and neither has had any effect on the issue. I have deleted the MM config cache for good measure on both attempts as I recall seeing that being needed somewhere else in this thread, but apparently has no effect in this case. Something I find interesting is that the up-scaled power production seems to work correctly while the panels are on the surface of Kerbin, but placing them in orbit removes the effect. Going to keep playing around with it in the hopes that I'll figure out how to insert my own patch, but still hoping for some sort of "official" response. EDIT3: Further testing shows that this is specifically related to Other Worlds because it patches "KopernicusSolarPanel" into the solar panels to get the second star to work. With just Kopernicus installed, the behavior of scaled solar panels is correct as well as when Kopernicus and OPM are installed. It's only when Other Worlds is introduced that the scaled behavior fails to work as expected. Still blindly poking around in the configs for myself, but it still looks like the issue is the "KopernicusSolarPanel" module as that is specifically invoked for Kopernicus configs with multiple stars. EDIT4: Playing around with trying to get TweakScale to recognize that I want it to add the same exponents to the "KopernicusSolarPanel" module hasn't produced any results, so I'm back to hoping for a better answer from someone who knows how to make this work correctly.

Curious how System Heat interacts with Real Fuels with regards to boiloff. I have both installed and both have boiloff as a feature, but that has me a little worried that they will end up double dipping and causing me issues. Searching through both threads hasn't returned any sort of relevant results, so I'm wondering if there is any information about whether or not they are compatible or will cause each other issues. Thanks

So I know its been a couple of years since any of the mod creators for this have replied, so I'm not too hopeful for an answer, but I am curious if we're supposed to be using "useRealisticMass=false" or not for this? I've tried multiple combinations and it feels like leaving the settings on "true" leads to fairly small rockets, while setting either of the options to false leads to comically oversized rockets (i.e. just to put a single Kerbal in orbit takes an absurdly large rocket and is nearly impossible with early tech). In searching through the thread I noticed at one point there was some talk about an update to rebalance things and remove the reliance on the setting, but looking at the patch notes there was only one update after that before it development stopped and its unclear if that rebalance happened in that update. So basically, I'm left with the following question: Have the configs been reworked such that we're just supposed to use the default RF settings, or are the current configs not rebalanced and we're supposed to set realistic mass to false and really work hard to engineer workable rockets? Thanks

Nevermind, was thinking of an entirely different mod...

I'm getting back into KSP and as usual I'm busy loading about 100 too many mods onto the pile. That said, I'm curious which of these two part failure mods is better these days? I've played with the old version of DangIt! (pre-continued) a decent amount, but back then OhScrap! was either not a thing yet or had just barely been released so I never had a chance to play around with it. Anyway, normally I'd start with a search on the topic, but apparently all of the relevant results are on the reddit and, well, right now is not a good time to be looking for information that's only on the reddit sadly, so I'm hoping to get a least a few opinions about which people like and why so that I can make an informed decision. Thanks EDIT: So it turns out that I haven't actually played with either of these because the failure mod I used the last time I played was BARIS. That said, I'm still interested in people's opinions on these two as BARIS is no longer supported and its successor doesn't interest me.

It sounds from previous posts that JPLRepo has already solved this and other issues, but the update is still in testing. The only reason I'd asked about its status is that its been nearly a month since the last communication.

I really hate to ask about the status of an update, but I've reached a point in my career playthrough where if I advance time at all, I'm hit with the bug where I go from the initial bodies being visible to all bodies being visible. I've been able to roll back to a backup made prior to the bug kicking in, but I'm basically stopped from playing now because advancing time at all reveals all of the bodies. I'm not trying to pressure for a quick update release, but rather trying to ascertain if said update is coming soon enough to justify setting KSP aside for a little while or if I should just accept that all CB's are now going to be visible and I should just press forward without being able to discover them gradually. Sorry again, but thanks if you reply

No parts had both modules, but oddly enough, somewhere in the intervening time between the posts, the issue worked itself out. Don't know when as I was using PF instead, but when I went back to try to replicate the issue, I couldn't get it to happen anymore, so it might have been a 3-way compatibility issue that was worked out when the third mod updated sometime in there. My best guess was modular flight integrator as that had a couple of updates, but I can't be sure if that would even affect either of the other two mods. Whatever the case, this seems to be a "nevermind" situation. Thanks for the reply though,

Hmm, I'll check it out. Thanks

As I've been progressing through my current career, I've found more than once that I've needed to re-run a mission for a contract because I've gotten my craft all the way to the target location only to find that I'd forgotten to put one experiment on to fulfill the contract objectives. Is there a mod or perhaps a vanilla mechanism to see a list of the experiments that a craft has already on board before committing to launch? I've tried a few times just going through each part and checking to make sure I've got the necessary parts, but several of the mods I'm using place experiments inside of non-science parts (i.e. I use Bluedog and only just today realized that the mod includes a set of solar panels which have RPWS experiments embedded in them...) which can lead to confusing mix-ups. Anyway, any help would be appreciated. Thanks

@Zorg I've done a balance pass on my RT configs now that I've had a chance to play a little with them. Mostly I've improved energy draw since the craft from BDB are designed with the vanilla CommNet in mind which doesn't have running costs for its antennas, but I've also tweaked some of the ranges as well and included configs for the as yet unreleased antennas found in the master branch for when they are released. The one issue I've still got with these configs is that many of the omni antennas feel somewhat overpowered, so I may yet do another balance pass on them, but at the same time, each is expected to fill a certain roll within a limited power budget, so I'm not sure how much wiggle room there really is. With that all said, if anyone other than me is actually using these, I'd really love some feedback for future balancing decisions. The files EDIT: I've also given quite a few of the antennas an unpowered mode to give greater flexibility for on-pad control.

@Bealeso I've found something that might deserve a little attention. As it turns out, a fair percentage of the configs for Tantares have a lower-case 'T' in the author line, while the rest have it capitalized. Its nothing critical of course, but its what caused my patches to fail in some cases since I was identifying parts using the author line and MM needs separate patches for each version of the author. I'm guessing it should be as simple as doing a find / replace in the files in the directory should you decided to fix it as I'm sure I'm not the only one who will ever use the author line to identify the parts in need of patching in the future. With that said, I've gone ahead and updated my configs to handle both versions of the configs and also done a balance pass to draw down the power consumption of the antenna and convert several to allow on-pad control with an unpowered short-range mode. Anyway, here they are:

Just in case anyone was already using my RemoteTech configs and was running into issues, I've updated the config to fix a capitalization error that was invalidating the edits. Here it is to save you from searching for the previous post:

Has anyone tried this in 1.11 yet? I'd actually forgotten about this mod, but remembered it when I realized I couldn't tweak rover wheels in the way I used to. Will probably give it a try, but still worth asking just in casesomeone has tried it and its a no-go... EDIT: Apparently I'd gotten this mod mixed up with Steering Tweaker for wheel tweaks, though for some reason I really feel like an older version of this mod allowed tweaking things like suspension since Steering Tweaker doesn't do that and I specifically remember being able to stiffen my rover's suspension settings... EDIT2: I went ahead and tested the mod and the answer for KSP 1.11 is that is sort of works... There is an error message saying that "TweakableDeployablePanels.dll is not compatible with this version of KSP" and then the game hangs on a full loading screen bar and never makes it to the main menu. Renaming that DLL to .BAK allows the game to load to the main menu, and then the rest of the mod appears to work correctly, but there are many thousands of the following NRE in the log: [EXC 19:51:56.587] NullReferenceException: Object reference not set to an instance of an object TweakableEverything.ModuleTweakableDockingNode.FixedUpdate () (at <a73916ddc84c4aad97c4602d57fff7ce>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) @linuxgurugamer sorry for the ping and I know its not super high on your list, but maybe you could add this to the bottom of your "Needs updated for KSP 1.11" list? Logs

I know... I actually thought I'd popped in here to mention that it seemed to work fine a couple of weeks ago, but I guess I never did.

Ahh, the joys of inheriting a plate of spaghetti

I don't know if this is still being developed at all, but I'd like to make a suggestion that any part that's selected to fail during a staging event should have a secondary failure check against it. I'm finding that my engines tend to fail the most after a staging event even if they are the most reliable part on my whole craft because the staging even only checks against the overall reliability of the whole craft and doesn't care about the individual part reliability. Adding a secondary check would allow for high reliability parts on a lower reliability craft to have more of an impact and would also mean using a reliable engine could save a launch that would otherwise fail. It would also be nice if there was a severity check based on how badly a part failed rather than what appears to be just a random failure. Seeing in the debug that my part missed a reliability check by 2 points and then it fails completely rather than developing a leak or getting something more minor like getting stuck seems off, while adding a severity system would add depth. Just some thoughts.

Makes sense that would lead to bad results... I'm actually kind of surprised that hasn't been in the code for years since checking for a prior config before applying another config seems like a must have component. Either way, thats a nice addition that's likely going to save headaches down the road in addition to the immediate benefits.

Did you work on this all night or something? When you called it last night it seemed like it would be a couple of days before you had something new, but here it is, first thing in the morning... That said, the bug appears to be gone, so that was some quick bugstomping on your part and I appreciate it for sure.

I don't suppose you might have some links to those old discussions? I searched for about an hour before posting my original messages and found basically nothing which is why I posted my initial question in like 4 places in the hopes of finding someone who might be able to help. I'm hoping there might be some information / solutions there that might be helpful in this current situation. You're probably right, but it still seemed like too sudden of a change to have happened without some sort of cause. That said, I have hope that you'll be able to figure something out with the underlying bug eventually and at least you've clued me in on a decent workaround for the time being. Thanks again for the help and putting in the effort to try to sort it out.

I see, though I'm still concerned about the crash that triggered all of this since it was working fine for about two weeks prior to this and then suddenly the bug has manifested everywhere for me. I'm still trying to search for information about whether or not the unity player stores some temporary files anywhere that could have gotten corrupted or "stuck" when the crash occurred, but finding information about that is proving difficult. I'm actually considering trying to join a unity developer forum to ask there in the hopes someone might be willing to help. That said though, I'm very appreciative of the effort you're putting in here and if a solution can be found to a long standing bug as a result of all of this, then I suppose its an overall positive result.

Ahh yes, I suppose I wasn't clear in my original description of the issue... loading the save from the main menu would always place KSC back on the surface. My concern is that there is something deeper going on and I'm hesitant to use this going forward, especially since I use KCT and KRASH together in my main career save which results in lots of short term reloading and I'm not sure what effect that would have on the save file overall. EDIT: The moving terrain with repeated reloads was the result of attempting to load the save from the KSC multiple times

Sounds good, I've got my fingers crossed By escape do you mean accessing the escape menu, or do you mean getting KSC back above ground?

Direct downloads from Squad. I've tried both the installer version and the zip version.

Cleaning the registry and doing a full reinstall of KSP + BG had no affect on the issue