Jump to content

Nertea

KSP Team
  • Posts

    4,638
  • Joined

  • Last visited

Everything posted by Nertea

  1. Sorry I didn't see this before. The rule for CTT is that at least two mods must want a node and must agree on its parameters. This was not enforced in the early days and it's why we have all these garbage nodes used by one mod everywhere. It is not quite easy to add a node with MM so there is not really a need to put this at the top anymore.
  2. A user had this bug on the last page and said it had something to do with TAC.
  3. No. @SPACEDUSTSETTINGS { @GameScale = scaling factor }
  4. This is generally correct below - if you need more go to the MM thread. There is technically syntax to edit FloatCurves but I find it more trouble than it's worth. @PART[name]:AFTER[YourDirectives] { @MODULE[ModuleB9PartSwitch] { @SUBTYPE[theSubtypeName] { @MODULE { @DATA { your stuff} } } } } It's more accurate to say I specifically exclude tweakscale from compatibility work.
  5. They can take any gas that can be ionized, setting all these up is not worth it (new plumes, stat balance, etc) Besides, the stock MM engine module can only handle two modes. Would need to write new code. Already exists: https://github.com/post-kerbin-mining-corporation/SystemHeat/tree/master/Extras/SystemHeatIonEngines They seem to work fine for most people. You'll need to provide more information. Did you make the parts with SystemHeat part modules? It seems like you just made them with stock modules. If you do that, you'll have to edit the SH patches to make ones for your new parts. Intentional. Similar to the stock engines there is a lot of hardware that's 'supposed' to be up front. Tweakscale is unsupported.
  6. Yup. So generally (and I didn't check everything, hence the hedging) MKS modules have one converter or harvester module which is modified by the swap options. So targeting that module should work.
  7. I'm not sure you understand what I'm saying so I'll be more detailed. USI converters and harvesters are both derived from ModuleResourceConverter (and thus BaseConverter). SwapOptions provide different sets of parameters for that converter. When you select an option, those parameters are baked into that converter. The adapter module doesn't replace or touch the USI converter. It communicates with any module derived from BaseConverter, which encompasses the USI converters. It does this in a very primitive fashion: it causes the linked converter to add heat to a loop at a temperature, and causes the converter to be shut down if the max temp is exceeded. Nothing fancy. None of this directly conflicts with the swap system, which just changes out pieces of the converter (resources converted, rates, etc). The link between adapter and converter is unchanged. Like I said though, testing I did here was not a lot. So someone who knows USI needs to validate this.
  8. Oh my bad I was going to add a comment about functional scoops there. Basically it seems you need to build something more plane-like.
  9. It's hard to take these totally seriously without any mention of thermals or other things. Seems like you want more thrust in everything. Probably not happening! KER is going to have to be pseudo-recommended at this point, because stock DV also can't handle the Clarke for some reason....
  10. If things work as expected coding is not needed. ModuleSystemHeatBaseConverterAdapter is specifically designed to NOT require replacing the target module - it just talks to any module derived from BaseConverter to translate heat values. The only unknown is SwapConverter, which this should handle in theory too.
  11. As long as you abide by the terms of the license you are probably fine. You should review: https://creativecommons.org/licenses/by-nc-sa/4.0/ You can generally set a shader param using an out of range value, those are more for the UI.
  12. Thanks I'll check that Thanks for the note, not really an issue with either the way I've set up the repos or the repos themselves.
  13. Not an easy thing to add but I'd accept a PR for it.
  14. Doesn't for me. If you're using MKS there is a material kit requirement, which is not a repair kit.
  15. I am modding about 1 evening a week now (which is tonight). So far I have not got many/any comments about the development version of NFE. I was guessing from that one of two things: (1) there's not much interest and/or (2) it's perfect. So make of that what you will. For that thing I still need at minimum to unwrap/texture the 1.875m reactor.
  16. In my opinion, the best solution is the one that does not require SWFE or WFR to be aware of each other. What you propose requires SWFE to be aware of Restock. The currently implemented solution does not. As to your questions. Yes that was the original effect, all patches were like that. It is common for users to disable restock patches, or more than I would like :shrug: Yes this is generally easier than trying to patch the very complex templates with MM.
  17. I did not make it so I can't say, but you shouldn't need to change any textures or models, the props just need to be repositioned.
  18. Sorry, not from me. That mod runs it's own heat system and generally is not very compatible with my stuff,.so spending effort adding compat stuff is odd.
  19. Why on this green earth would that be intentional? Not authoratively.
×
×
  • Create New...