Nertea

I wouldn't be worried. Either it's moddable, and everyone is happy, or it's not and people are mad. At this stage in the project development there is no likelihood of changing that no matter what you or I do. I discovered that somehow when I removed the light in the last release of NF solar, the prefab got reset (thanks Unity) and deleted all the colliders. I'll have a fix eventually but I'm massively busy so time in front of my modeling comp is very limited this week.

If you check in my dev thread, you might note that a couple weeks ago I officially paused development due to no motivation to work on it. With the advent of KSP2 news, this is in flux, probably won't happen until I can ensure that what I build could transition to that game in the future.

I highly recommend you not install the optional patch then. It's optional!

Just two notes here - This messes with balance, panels that can't retract are cheaper/lighter in KSP. - This specific patch will not work in NFS > 1.0, you should change the part specifier to nfs-* as all the part names changed.

Why would you ping me twice on an issue discussed 2 posts above yours? I'll look into it when I have time. More posts will not make it faster. I've heard it works.

I can't confirm that but maybe - if the estimator is keying off the 'off' state of the engine i could be reporting infinity or something. I feel like this used to happen in stock and the solution was to turn the engine on for a second.

I guess you are using the NFE integration patch also. Fair warning that this is an advanced patch and may not be to your liking. You should consult the thermal systems panel in the VAB to discover how many radiators you will need to pack if you want to run the reactor without forcing propellant through it, it will be more than 400 kW for sure (8 small TCS). Alternately, set the reactor power to very low (1%) when not running the engine directly, if you can remove that amount of heat with radiators, you do not need to shut it down.

Finally have some time to deploy a few minor updates: Near Future Construction 1.1.3 Updated B9PartSwitch to 2.9.0 Updated some part variants to use new B9PS 2.9.0 features Fixed a bug with the upper cap mesh of the Annular Truss XL Near Future Solar 1.0.4 Fixed rogue lights on Megalador and Halo panels Updated Chinese translations (6DYZBX) Near Future Launch Vehicles 1.2.2 Fixed an engine plume element being sideways

Nobody's talked to me :(. Ya probably not going to need this mod in KSP2! Indeed. I'll finish it sometime, kinda in UI hell now. I'm aware. I think the biggest thing that is happening is that Kerbalism has its own gameplay model. I'm aware of that and some other people are also aware of that, but I think where people get confused is when installing Kerbalism removes the gameplay model provided by other mods. Same problem with KSPI, where people then come here or to one of my other project threads and ask me why feature X is not working. As I am unlikely to migrate my components to Kerbalism's gameplay model, I would say the biggest thing we need to deal with is player awareness - that really boils down to making people aware that if they are using one of my mods with Kerbalism, support has to come from you guys.

Well, your second log looks clean of issues caused by DBS. However, you have a bunch of contract system nullrefs that occur right before the termination error. Might want to investigate those - not sure what is going on there. Your first log shows the KSPI-E error. This was a situation where KSPI-E shipped configurations for CryoTanks which were fundamentally broken and never worked anyways. However, DBS tries to process the configs and dies horribly on them because they aren't what they expect. As mentioned in the ticket, this will be fixed in two ways, one with the upcoming update to CT that refactors some things and adds better error handling around bad configs, and two as KSPI will move to not have broken configs. Its a win win.

Hmm. The exception you posted is pretty clearly a GC alloc/memory thing which are always painful to discover (and usually my things don't reach into the internals enough to touch that). I will trawl your logs later today, but my general suspicion, based on the other issue reported, is that something is messing with some of my modules somewhere, which has the end result of introducing an undiscovered failure mode into DBS, which can cause a stack of exceptions and errors, killing the game. If we can track down the interaction then I can at least investigate.

This looks like it's the same problem that was identified here. It will be fine when KSPI fixes their incorrect use of ModuleCryoTank, which will happen soon. Alternately, release of newer CT and DBS (also soon) should resolve it. I'm at work at the moment and can't load things from most file storage locations, but I would absolutely have seen this while playing recently (as would anyone using a reactor based on that description), so we need to clarify a few things in the last, more reproducible situation so I can run some tests on that case. You're using an MX-0 reactor (vs UX, just need to make sure it's not been touched by some other mod) No other mods are installed besides NFE and and DBS This occurs regardless of whether DBS is installed or not Can you confirm those?

You can read my post a few items above, but in short, no, it does not look good enough. Maybe one or two of the engines are close, but that is not sufficient.

When Kerbalism touches my stuff, the warranty is null and void.

Maybe in 2021. Though I agree conceptually, this adds a nonzero amount of memory use and a fair amount of work to our plates. In order to clarify, there are some mods that create brand new parts, either by cloning existing stock models (eg, an infinite power ion engine as a different part) or by using elements of stock models (say, making a new model and using an old texture). If your mod is not one of these (eg, adding things to existing parts), then you are fine.

I think this still applies - can you point to >= 1 other mod that wants to use such as node?

I'm just going to make parts at this point, so I think the usual will apply - I suspect you will change the functions of them when Kerbalism is installed. Maybe it is, but for the moment development is paused. I have plans to revisit and rework the plugins running the engines somewhat in the future. The.. far future.

I'd argue that what they do is not really what I would want to see with radiation, but sure (see my own WIP radiation project). They don't really break anything though - it's just them abstracting a reactor as a magical Uranium -> Power converter. It works within their system and does what they want it to do. Sure, it doesn't handle thermal behaviour and doesn't model most of what NFE models, but it does technically worked. I offered in the issue to try to work with them on an improved way of integrating mods, and was gently rebuffed. So, unfortunately, the ball's in their court and there's nothing I can do to make them change their minds. Located and addressed for next version! Located and addressed for next version!

Yeah what was said lines up well with how ShotgunNinja originally dev'ed the mod and my conversations with them when it started out, so it hasn't changed. I think it's totally fine - I make a particular set of mods with a set of systems, they are designed to interact in a certain way, and other developers have different systems that they want to work differently. Where I personally get frustrated is with things like SSPX, which provides a centrifuge module with basic functions. Kerbalism replaces this with its own module to hook up its LS, power, etc, but fails to replicate say, for example, the bits of the module that ensure that the IVA spins correctly. Little QoL things I write get lost, and inevitably I get bug reports that my parts are not working right because to the end user, a SSPX centrifuge is an SSPX centrifuge and an NFE reactor is an NFE reactor regardless of whether Kerbalism is installed. Where Kerbalism could do a better job would be in informing the user that these parts are, effectively, Kerbalism's and not mine anymore. This is exactly what @lajoswinkler just ran into.

I would love it if Kerbalism and other mods would work together to create lower effort solutions to solve this problem. As it stands other mod authors can't really work with Kerbalism devs as they don't come to us with suggestions for better interaction - we just discover what they did later and then have to field the support requests. Initial Kerbalism philosophy was that the mod would build its own balance and challenges in its own space - other mods would upset this balance so the original dev would only integrate other mods (and in this case, integrate means write their own implementations of what those mods did) when they knew how they would slot into his gameplay paradigm. If this has changed and development is more collaborative and open to interacting with other mod systems, we have the opportunity to work better together. Thanks for pointing me to this issue, I've added some comments, maybe we can in the long term work something out.

It is indeed intentional and should be the same footprint.

I've confirmed the problem but I have not discovered a solution yet. There seems to be an unpleasant interaction between the window lights and the pod lights - the ModuleLight implementation really sucks.

It might work - I don't support it. Here's why: Kerbalism replaces every single functional component I have made with its own version that hooks into its own systems, which function differently, have different balances and who knows what else. If you install NFE and Kerbalism, you are getting Kerbalism's reactor mechanics. I don't know what those are and don't maintain the code so I can't support them from my end. quick edit - yes, confirmed that Kerbalism replaces NFE reactor modules with a generic KerbalismProcess...

I definitely want to make some remote sensing instruments as part of a mod. Don't know if it'll be this one, but as EO satellites are my day job, it would be really cool. There's some awesome things out there, like... A number of radar altimeters exist, like the one on JASON-3 Wide area optical stuff like Landsat-7, TERRA/AQUA High res optical imagers like Worldview-3 and Deimos-2 Higher frequency SAR panels like Cosmo-SKYMED and RCM Low frequency SAR antennae are really cool, eg BIOMASS/TANDEM-L I looked into this a few weeks ago, even mapped out a part -> gameplay concept map Radar Altimetry 2 models, one primitive, one newer Similar function to the one in ScanSat now, low res terrain mapping Multipectral imaging Needs daylight Wide FOV Biome mapping, resource mapping High resolution imaging Needs daylight 2-3 models One based on the older Coronas, for history's sake One based on the KH-11 because what's cooler than an HST pointed right at the earth One based on a commercial platform, probably something from DG Narrow FOV SAR imaging Doesn't need daylight, but needs more power A few different models Something X-Band (lowest FOV, lowest required power) Something C-Band Something P/L-Band (widest FOV, highest required power) Terrain mapping Potentially an alternate model using C-band that includes resource mapping Locational mapping (BTDT) AIS antenna Would be fun... I'd love to couple this with a contract pack that would make a whole EO program experience viable, something that would create missions that rewarded all the things that we look for when developing these missions, like Place sensor X into a specific orbit Observe target Y with sensor type Y Observe target Z with sensor type K within the next few hours Etc Yknow, things that would encourage understanding of SSO orbits, constellation design, etc.

Ok I'll check it out. I recall the report about NFSolar, I asked for more info but none was ever volunteered. If you see anything please let me know.