Nertea

There is no support for the development version at this time. Do not use it if you need to ask questions about it.

I think I see something that could cause it, but I can't tell until I compile and test.

DBS can only solve problems with modules it "knows" about. I don't know if your mod is subclassed off stock modules like generators and converters (in which case DBS will work) or custom modules. If the latter case DBS won't be able to understand when consumption is happening unfortunately.

Well, can't say when I'll have time to fully investigate this, but: https://github.com/ChrisAdderley/NearFutureElectrical/issues/89

Here's a small bit of progress. Sometimes, those black rings with handles at the end of the parts don't look so great in your station. SSPXr gives you the option to replace them with a few different variants:

So is it resolved if you switch to English localization? If so, I don't know what's going on, but at least have a starting point to look at.

Previous person who had this said it was resolved by reverting translation to English. Are you using a translation at all?

@FreeThinker Based on what you've said here, IMO you should have two different threads with two different mods, or at least clarify your OP. When I used IFS ages ago, it was just a drop-in, better maintained version of FS's fuel switch parts and seems to have grown rather hugely since then. Maybe call it "Interstellar Fuel Management" or something, because it's quite a different scope than the original.

@FreeThinker: Care to explain this thing I found when debugging a user's install containing IFS? @RESOURCE_DEFINITION[Actinides] { @isTweakable = true } @RESOURCE_DEFINITION[DepletedFuel] { @isTweakable = true @density = 0.0117 } @RESOURCE_DEFINITION[LqdCO2] { @flowMode = STACK_PRIORITY_SEARCH } @RESOURCE_DEFINITION[Water] { @flowMode = STACK_PRIORITY_SEARCH } @RESOURCE_DEFINITION[ElectricCharge] { @unitCost = 0.00002 } @RESOURCE_DEFINITION[Megajoules] { @unitCost = 0.02 } @RESOURCE_DEFINITION[Carbon] { @isTweakable = true @isVisible = true @transfer = PUMP @flowMode = ALL_VESSEL } @RESOURCE_DEFINITION[Lithium6] { %displayName = Lithium-6 } Care to explain to me why you're patching common library resources in this also common library mod? Some of these changes will break mods! DepletedFuel density change will break NFT, ElectricCharge cost change will break all batteries' costs. Pinging @RoverDude as this is a CRP issue too...

Perhaps you should try using the engine a bit and you'll already see this. Seems complicated... looking more to make it more intuitive. It's hard to say what you actually need, but you don't need 100% of the cooling spec. I'll try to add some notes, but trial and error is going to be a bit involved.

Yeah which makes little sense considering the scope of the mod. Advanced integrations means the NFE NTR support patch. Problem is probably that most of those files should be gone bleh I'll fix it whenever/in 2 months.

Did you try his solution?

I just had a kid. Don't wait up.

I'm open to better suggestions for how to handle interfacing with the chargeable engines. I recognize this isn't super user friendly.

No, never in this mod.

It would appear you are not using any advanced integrations, so those are just parts... pretty looking parts, but just parts. I'm going to have to chock that up to a mod integration unless you get get reliable reproduction steps. Glad you appreciated the descriptions, thanks!

Much appreciated, I will get to it when I can!

A. Yes, of course, but the timeline is uncertain. It will not break anything. B. No, probably not. Thanks dude, always appreciated! Be quiet.

Thanks, I'll review and merge when I can.

I have no time to work on any projects at the moment.

If you're digging in the dev repo, be aware that I haven't done final QC in anything at all. I don't know what this means.

I think that the obvious solution at this point is to have traceable injection points for new resources. This has happened a few times now and we need a chain of custody for changes. It looks like the way that this happened was because it is too easy to merge dev into master, so to speak. Firstly, it needs to be on all users of the CRP to submit new resources using the public forum, and civilly discuss planned changes and adjustments with all stakeholders. Stakeholders in my mind are everyone who curates any CRP resource and therefore has a stake in using the mod. To my mind this is myself, RD, angel, freethinker. Probably a few more but my kid screamed for 15 hours last night so I'm not all there. We can use different methods to do this, I might suggest making use of GitHub merge request reviews to do this. New resources can be proposed in a PR for that resource, all curating stakeholders can be pinged for input, and other users can be pulled in if stakeholders see another user. Secondly, I've mentioned this before, but there should really be no reason to add a resource to the CRP that is only used by one mod. The reasoning for this seems clear to me, it creates these issues by locking in a resource without a consultation process. Without more than one user it's not a community resource.... These changes will add more overhead to adding resources to the CRP. That's fine. The project is now a large community framework and it needs more stringent controls.

Hey guys, just a note that I'm probably out for a while due to RL stuff. Anyone who steps up to answer questions when I'm gone, it's greatly appreciated.

Ksp doesn't really care what the name is, interestingly, in that form!

Certainly not happening - 85% of the work of these parts are in the textures, so that'd at least double or triple the amount of work I have to do. I noticed that most airlocks have some external toolboxes around them, so I added them in. That's all really.. I expect KAS storage could be a thing.