SpacedInvader

Has anyone here managed to get the RealFuels-Stock engine configs to work with BDB? I'm running into a serious issue where any engine that had multiple configs defined by BDB gets "stuck" when using the RF configs and I can't throttle it at all or adjust its throttle limiter. I've been working on it on my own for a day now and have already asked on the RFS thread, but I'm hoping someone here also uses those configs and has figured out a way to make them work correctly.

I"m running into a fairly serious issue with the Bluedog-DB configs. They do function properly in selecting engine configs through the RF dialog and also in using the fuel types, but I can't throttle many of them and the throttle limiter doesn't work at all for any affected. It appears to be any engine that had multiple configs applied through the B9 part switch by the BDB authors that's affected. I've been trying to tweak the RFS configs to get them to work, but so far they refuse to work correctly and I'm starting to run out of ideas. I'm curious if anyone here has managed to get them to work correctly?

I've got an odd incompatibility that's cropping up with Real Fuels. When I have both mods installed, I get the following message in my log and then the fairings don't work to protect parts within them at all: [LOG 00:12:05.339] RealFuels.Tanks.TankWindow:HideGUI() RealFuels.Tanks.ModuleFuelTanks:OnDestroy() UnityEngine.Object:DestroyImmediate(Object, Boolean) UnityEngine.Object:DestroyImmediate(Object) DragCubeSystem:SetupPartForRender(Part, GameObject) <RenderDragCubesCoroutine>d__31:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) UnityEngine.MonoBehaviour:StartCoroutineManaged2(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <SetupDragCubeCoroutine>d__47:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) UnityEngine.MonoBehaviour:StartCoroutineManaged2(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) SimpleAdjustableFairings.ModuleSimpleAdjustableFairing:RecalculateDragCubes() SimpleAdjustableFairings.ModuleSimpleAdjustableFairing:OnStartFinished(StartState) Part:ModulesOnStartFinished() <Start>d__322:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) Without Real Fuels installed, the fairings work correctly and I don't get these messages. Is this an issue on the Real Fuels side or on the Simple Adjustable Fairings side? The two seem like they shouldn't affect each other at all, but that's just from a layman's perspective... EDIT: To be clear, all other fairing types work (vanilla + procedural), so its definitely something between these two mods

If you'd like to, that'd be great. Like I'd mentioned, there could be issues that need to be ironed out, but if its on the front page, at least it might save some people from having to search for it.

I'm curious what the status of ModuleFlightIntegrator is currently. I've seen on the last couple of pages that there have been some special patches for this that might not make it into the proper branch of MFI, but that discussions with Sarbian were in progress. Since then however, MFI has been updated and I'm curious if I can update to the 1.2.8 version available on CKAN or if I need to keep the version bundled with Koperinus-BE edition?

I've gone ahead and written up a compatibility config for RemoteTech since I plan on using this mod in my next career. Since several people had asked for one, I figured I'd go ahead and share mine here. Some things to note: - I used a decent amount of automation in creating the configs, so if I missed any parts, let me know so I can add them - Most range values have been increased to account for RT's more restrictive range model - I didn't find any special case parts (i.e. probe cores with built-in long range antenna) in my initial run through of the part configs so if I accidentally obliterated something like that, again, just let me know Anyway, just copy all of this into a new cfg and you should have pretty much full RemoteTech support for your parts. EDIT: Updated 02/24/2021 to correct an error in capitalization that invalidated many of the edits

Glad I could help

Couldn't figure out how to do a pull request so I'll just post it here as a zip. What these configs do: - Dynamically configure all antennas to RemoteTech omnis based on their prior vanilla CommNet configurations (those numbers were set for a reason, might as well utilize them) - Buff range of most omnis by 200% to account for RemoteTech's more restrictive standard range model. If you use the root range model, just use the recommended 0.5 worldscale - Nerf range on a few others because huge omni ranges felt unbalanced - Dishes are manually reconfigured from the initial omni state based on their intended mission profile (couldn't figure out a way to automatically configure dishes in a satisfactory way) - Probe cores are automatically configured to have the RemoteTech default 3km always-on antenna for pad control - Probes which are described as communications relays and had been configured already with improved internal antennas have retained those - Going forward, this should automatically configure all new omni antennas and probe cores correctly, with a need to manually patch dishes or special probes / pods (but all would still work as omnis / regular probe cores at least) If anyone spots any balance issues or other issues, I'd be happy to fix them and reupload if needed. The Files

Either way, I'm glad its sorted

I've been planning on using this for a playthrough that I'm getting started which will have RemoteTech and I'm running into an issue in that all of the antenna that have been configured to work with RT seem to be missing. I understand that most of the newer antenna don't have a compatibility patch yet, which is not what this is about, but rather the ones that do don't appear anywhere in the parts list at all. For example, the DP-75 appears to be properly configured, gets all its associated MM patches in the log, but then when I go looking for it in game, it literally doesn't exist and I can't figure out where it disappeared to because there doesn't appear to be any patches that would rename it or delete it. Is there something I'm missing in the configs that's leading to these parts vanishing? Thanks PS: I'm also going to be patching the newer parts to work with RT and I might post it here if I'm happy with the results. EDIT: I'm using v1.7.1 from CKAN on KSP 1.11.1 in case that might be the issue

I've never been very good at deciphering unity errors, but it looks like the game doesn't want any special GUI to be added to the jetpack because its a cargo part. I could be wrong though... Is this an error you're still getting after applying the patch, or something you were seeing before?

You might have a patch somewhere that does a search for all containers that hold resources and then replaces them with service module tanks. Best I can suggest is doing a search through your gamedata folder with a program like notepad++ that lets you search for text in files for something that looks like "@RESOURCE[*]" as that might lead you to the culprit. And yes, I'd remove the service tanks on the jetpacks, but that's been added through a patch somewhere so you've got to figure out whats adding it and disable that. As for rescue contracts, I've got no idea at all as I've got them disabled since I never do them.

So it turns out I wasn't quite paying attention to what I was reading from when I replied to your post, the patch notes are from KSP 1.11.1 actually and after downloading that, I do see the line they were referring to in the configs. After some testing it looks like it doesn't matter what resource you patch into the jetpacks because they don't actually refill from whats on the ship but rather from a magical stockpile. With that said, I think I might know where you went wrong here... did you change both the tank contents and the KerbalEVA module's fuel of choice? Here is the patch I just whipped up to make my jetpacks use Hydrazine instead of EVA Propellant and it works just fine: @PART[kerbalEVA*]:NEEDS[RealFuels] { @MODULE[KerbalEVA] { @propellantResourceName = Hydrazine } } @PART[evaJetpack]:NEEDS[RealFuels] { !RESOURCE[*]{} RESOURCE { name = Hydrazine amount = 5 maxAmount = 5 isTweakable = False } } My thinking is you changed the jetpack's contents, but not the fuel the kerbal's eva module, which is actually a part of the kerbal themselves, wants to see. If I'm still wrong here, my best suggestion is to remove the service tanks from the kerbals and just pick a single fuel for them to use and define it in a fixed way like I did in the patch. EDIT: Considering the fact that the tanks refill magically, it might be better from a realism perspective to use something like nitrogen since hydrazine is just a little too terrible of a chemical to be put into something you might accidentally fire inside the ship...

Can anyone give me some information on how BARIS handles multi-launch orbital construction as well as mods like Konstruction and Global Construction that allow you to build a ship on site without actually launching it from the surface per-se? I've got Extrasolar and Far Future Technologies installed and I'm expecting to launch several missions that will take months or even years to construct in orbit since I also use KCT. I'm fully aware that MTBF will degrade while in orbit, but I'm curious how that MTBF will interact with things like new parts being welded onto the ship sometime after launch.

I'm only just starting to use the mod myself, but if you want no-strings-attached launches of your rockets, this isn't the mod for that. I've been reading through the thread and the wiki for a couple of days now am pretty comfortable in saying that the whole mod is built around testing and patience to get the highest reliability from your craft. That said, yes, if you don't have KCT installed, I'm pretty sure you can skip vehicle integration completely, just expect lots catastrophic failures during your missions.

I'm hoping to get a little help from anyone here who's got experience working with the various US config modules. I'm working on a series of patches to integrate US2 to work with Real Fuels and I've run into somewhat of a minor issue, but its been bothering me for two days nonetheless. While trying to adapt the 1.5m shroud, I've run into an issue where no matter what I try, I can't get the bottom detail to switch between the flat-bottomed structural variant and the toroidal tank variant. This won't work at all for me unless I leave the config in its vanilla state, let alone how I'd like it to work which is have each of the shroud heights cycle through its structural variant and then its tanked variant before stepping up to the next level. Currently, this is what I've got for this part: And with this, I've pretty much got everything else in the config for the part working. The structural and tanked versions do cycle in the way I want, the various fuels are available in the correct quantities based on which model is selected, the colors work just fine, and even the things like nodes and drag cubes appear to work correctly, but literally no matter what I try, the only mesh that will ever show up for the bottom of the part is the tanked variant. As such, I'm really hoping someone who knows a lot more about the inner workings of the USMeshSwitch Module could step up here and give me an idea of where things are going wrong. In the end, its a relatively minor problem because its just a minor visual component of a single part, but I'd still really like to try to work it out. While we're at it, if anyone has any experience in working with ModuleFuelTanks from RF and USModuleSwitch from US2, I could use some help there as well. The reason I've got such a mess of fuel configs for this patch is because I've not found a way to get ModuleFuelTanks to properly update dynamically with the settings fed to it by USModuleSwitch. I've been able to get the tank type to switch correctly, but its volume refuses to budge from whatever I've set it to initially. I'd originally hoped I could get the tanks to work in a similar fashion to their procedural parts function where as the US2 module feeds the RF module with new volumes as the size increases / decreases, the tank reflects the new size / type, but I've not been able to manage the volume change at all and I've tried a bunch of different approaches in MM. Here's where I got to before giving up: If anyone has any ideas on what would need to change to get this to work, that would be amazing as it would be a much better solution than manually editing in every tank content / amount I've got a desire to use for every part. Thanks

On a different note, @Starwaster I wonder if you could help me sort out a config I've been beating my head against for 3 days now. I'm trying to integrate the modular tanks from Real Fuels into the Universal Storage 2 parts using the provisions built into the US2 modules for switching components of modules. Here's what I've got so far: This setup uses US2's built in switch controls to create PAW selectors like this: The second switch does work correctly, swapping the tank type from Default to Cryogenic etc, but the first one which is supposed to increase the volume of the tank to match the increasing size of the model refuses to work. I'd hoped it would work in a similar way to the procedural parts tanks where when the tank changes size and the volume value is increased or decreased, it prompts ModuleFuelTanks to update its volume based on the new volume value I've fed it through the switch. Unfortunately, it refuses to update and stays stuck on 65L no matter what I do to try to get it to update dynamically. I'm really hoping you might have some ideas on how to force ModuleFuelTanks to update dynamically with this changing value in the same way that it does for Procedural Parts as I'm completely out of ideas and about to give up. Thanks PS: Really sorry about the ping, but I felt that you might be one of the only people who might be able to help solve this and it doesn't seem like you pay much attention to this thread anymore. EDIT: Just in case it isn't clear, SwitchID 0 is already part of the part and also controls which version (1 high through 4 high) of the model is shown.

If you're using KSP 1.11 you can't refill EVA tanks from the pod stores anymore (honestly not sure if you ever could) from what I'm reading in the cfgs. You need to put EVA Fuel Cylinders into the pod's inventory and use those. EDIT: So apparently they included the config flag reinitResourcesOnStoreInVessel in 1.11 which would allow you to refill your EVA propellant when placing your jetpack into the inventory of the pod, but I haven't been able to get it to work since there's literally zero documentation about it...

Thanks for clearing that up, at least now I know that it wasn't the new driver per-se, but rather a setting that it decided to impose on its own during install.

I've been testing this in KSP 1.11 and have found that it throws out lots of the following Null Reference Exception whenever you open the PAW on any part of a ship that has at least one kerbal assigned to it: [EXC 04:35:06.513] NullReferenceException: Object reference not set to an instance of an object UniversalStorage2.StockVariants.EditorPartIconListener.PartIconSpawn () (at <da28f16225654a6e9aa3c0ba261544dc>:0) UniversalStorage2.StockVariants.EditorPartIconListener.Start () (at <da28f16225654a6e9aa3c0ba261544dc>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) This happens if there is any kerbal assigned to any part on the ship, but luckily the workaround is just removing all the assigned kerbals while you work on the ship and then reassigning them before launching. I understand that this mod's devs are taking a break for the moment so this might not get fixed anytime soon, but I'll go ahead an leave my logs here in case they have a chance to look at it. Logs One thing to note, it appears that there may be some mod interactions that worsen the problem. In a test install with just US2, there are 20-40 NRE's whenever you open the PAW for a part, but in a heavily modded install like I usually run, it spews out literally tens of thousands without ever stopping. I've saved those logs as well if anyone wants to look at them, but I know mod developers tend to only want to see what their specific mod is doing, so I won't post them unless requested. EDIT: Whoops, I just noticed the post a few above mentioning this same issue. I'm leaving my post up though as I was able to find a temporary workaround for anyone like me who was getting so many NREs in their main install that the VAB was barely functional. Also the added logs can't hurt imo.

For the last two days I've been getting odd behavior during scene changes (i.e. from main menu to KSC, KCS to VAB, etc) where instead of going to a black screen for loading, I get a weird ghosted image of the previous scene like this: At first I thought it had to do with an nVidia driver that I'd just updated, but I've since rolled back and am still getting the same behavior. I don't think its something critical, but I'd like to fix it anyway so I'm wondering if anyone has ever seen anything like this in the past and if so, what can I do to fix it? Also, is it possible that this could be the result of a mod as I run quite a large modlist and more than a few were updated yesterday. Thanks EDIT: I've now tried removing all of the mods that were added / updated since the issue appeared and its still occurring so I don't believe its a mod related issue. EDIT2: Solved with a complete uninstall, cleaning, and reinstall of older drivers. The Game Ready driver v461.40 was apparently the culprit and a rollback to v460.89 corrected the issue.

That appears to be the one... no wonder I got them mixed up with such similarly clever names...

Did this mod at one point have a mechanic where the more you built a specific craft / part, the more reliable it got? I really remember there was a failure mod with that mechanic and I really thought it was Dang It!, but I've read through the documentation and haven't found anything about it. Was that something the mod used to have and has since been removed, or am I thinking of an entirely different mod?

I'm hoping to get some help in sorting out a series of patches I need to to apply. I'm trying to convert a lot of parts from the Near Future mods to work with Real Fuels and its customizable fuel tanks. Normally this wouldn't be an issue at all as swapping in the RF module is a fairly simple process of deleting to old tank contents and patching in the module. Unfortunately, Nertea's approach to part variety was to create a few parts which use B9PartSwitch to change their appearance and contents and I really want to preserve the variety of appearances while replacing the tank contents that come along with each appearance. This is where things have started to go sideways for me as I've found it impossible to affect the individual options through a patch in any way that hasn't also resulted in invalidating them. Anyway, here's what I've tried so far... First, an example of the config I'm trying to edit: This was an attempt to search out the fuel tanks from the mod that I hadn't done a custom edit on (there are a few that I think might need it for various reasons) and delete the tank type and mass adjustment from each subtype, which would then be replaced with its own RF module. I also tried skipping the addition of the RF module and just deleting the tank type references so I could just add a single RF module afterward to the whole part. This is the only one of my attempts that did anything at all and that was generate an error. I'm not really sure where I went wrong with it though. This was my second attempt where I tried to affect the B9 tank definitions instead thinking that if I couldn't affect the part switcher subtypes I'd instead change what those tank types inserted into the part. Unfortunately, this patch didn't work at all and I didn't even get errors. I've tried a few other minor patches, but so far nothing has created the desired result. I've thought about trying to create a new B9 tank type with the RF module already built in, but I'm not sure that the B9 Part Switch module can handle inserting a whole other module like that and even if it can work, I'm still stuck with the problem of not being able to edit the subtypes correctly through a patch. Any help would be greatly appreciated. EDIT: Managed to solve it on my own through lots and lots of trial and error.

Thought I'd post this here in case anyone ran into the same problem. I'd downloaded the mod using CKAN and had run into an infuriating issue where decreasing the thrust limiter would proportionately decrease the maximum throttle available . Example given in the following image where thrust is limited to 60% but even at maximum throttle position it would only go up to 35%. At first I thought it would be RF because it seemed like something RF might have a hand in, but after setting up a test install with just KSP+RF and not getting the same result, I went through my entire gamedata folder looking for the culprit (nearly 200 mods), only to eliminate everything except RF. As it turns out, the version of the plugin that's installed through CKAN is broken somehow while the version from the latest Github release (the one I used for the original test install) is perfectly functional. So, if anyone sees this behavior and has used CKAN to install the mod, I'd recommend the first thing you do is do a fresh install of it from the Git. Also, I'm not sure if this had anything to do with it, but I did the same for RealFuels - Stock engine configs and all of this is on KSP 1.11.