• Content count

  • Joined

  • Last visited

Community Reputation

3036 Excellent

About NecroBones

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Location MOCR

Recent Profile Visitors

6097 profile views
  1. OK, I'll leave it for now. I still use a lot of BEFORE/AFTER in how I do things anyway, but sometimes it's very circuitous by necessity. Posted: 1.12.1 (2017-04-09) - MFT fix. - Corrected some MM patch issues for ModularFuelTanks.
  2. Good to know, but the old programmer in me doesn't like to trust things that aren't explicitly defined.
  3. Yep, I'm putting it together now. I'll get that out ASAP.
  4. Ah! Excellent. That first one needs to change to a "BEFORE" since it's creating the variable, but otherwise that looks good. I'll add it.
  5. @linuxgurugamer - Another idea I had. It's possible that Modular Fuel Tanks is doing something to the fuels or the tanks before my patch executes. I might need to just move them earlier in the sequence. Is it just MFT that you're installing? I can probably do some testing here too. Just don't have much time at the moment.
  6. For that to be the problem, it would have to be that another mod is removing the Oxidizer from my parts. I would need to see the KSP.log with which parts are erroring out, but the patch should only be modifying tanks that I've given Oxidizer to, and not the monoprop tanks. I could add a check for it, sure, but I don't think it'll solve this for you.
  7. @linuxgurugamer, I'm wondering if MM added an error-check phase that executes on the whole sequence before executing, so it no longer likes declaring a variable and then editing it at the same level. Maybe as an experiment you can try replacing that whole patch rule with the following: @PART[TPtank*|TPcone*|TPdome*]:BEFORE[FuelTanksPlus]:NEEDS[ModularFuelTanks] { origLFO = 0 } @PART[TPtank*|TPcone*|TPdome*]:FOR[FuelTanksPlus]:NEEDS[ModularFuelTanks] { @origLFO += #$RESOURCE[LiquidFuel]/maxAmount$ @origLFO += #$RESOURCE[Oxidizer]/maxAmount$ MODULE { name = ModuleFuelTanks volume = #$../origLFO$ type = Default } } Notice that it initializes the variable to zero in a "BEFORE" rule, and then only modifies it in the "FOR" rule. OK cool. Thanks!
  8. Very strange. That logic should be 100% fine. I do the same calculations in RSB's Stoack-alike patches. I wonder if that would do the same thing. It also makes me wonder if something changed in how MM does these things recently, that I'm not aware of.
  9. I don't know why it would be failing there. The variable is added, and then edited. This logic works pretty much everywhere else. Unfortunately the log isn't much use, since it's pulling cached copies of everything. I would need to see a log generated after deleting MM's ConfigCache file. In fact, stale cache data might be the problem (I've seen things like that before). Do you have anything modifying Oxidizer? Like removing it as a resource? Otherwise, I can't imagine why it would fail on that. The funny thing is that when this was all first getting added to CKAN, they preferred to keep it simple, and list only one prerequisite out of the set. FTP does indeed work with Firespitter and/or IFS, so the netkan can probably be improved. I don't have the time at the moment to dig into that, though. Mostly the CKAN folks handle all of the metadata, but I sometimes helped it along by adding my own.
  10. There's a RealFuels-like component in Realism Overhaul, but not for Real Fuels itself. For the realism mods, I let them handle it on their side. They simply never added support for RSB. Always possible. Heh
  11. Updated. 1.12 (2017-04-07) - Tweaks & Fixes. - Corrected a typo that was preventing the B9PartSwitch patches from applying correctly on the radial tanks. - Slightly increased the performance of the 2m/3m stack decouplers, and increased their propellant maximums. - Changed ModularFuelTanks config to use consolidated wildcard patch. - Removed "cryogenic" tank type assignments from the MFT configs. - Stack decouplers in sizes 1.25m, 2.5m, and 3.75m collider updates, now actually hollow.
  12. Eventually, yep. Everything's kinda been on hold lately, but I don't plan for that to be a permanent situation.
  13. I guess another option would be to create a separate MM patch that disables them, that can be optionally downloaded if desired, and otherwise leave it as-is. Something to think about.