Jump to content

blowfish

Members
  • Content Count

    4,544
  • Joined

  • Last visited

Everything posted by blowfish

  1. Variables don't work in regex replacements. Fortunately you don't really need regex since you're just appending to the end @description = #$description$<br><color="green">It's an example with LiquidFuel $/RESOURCE[LiquidFuel]/maxAmount$</color>
  2. If TweakScale is NREing on GetModuleMass then that would probably be the first place to ask.
  3. It looks like WildBlueIndustries/ClassicStockResources/Templates/Utility/ModExists.cfg is telling ModuleManager that ClassicStock is installed but it is not (and other patches are being inconsistent because of that. @JadeOfMaarcould maybe give a more detailed answer about how these things are supposed to be installed?
  4. yes, I think you're just missing brackets which will cause KSP (and thus MM) to treat is as a node, e.g. !SPACEDUST_RESOURCE:HAS[#body[Duna]]:NEEDS[GPP]:AFTER[SpaceDust] {}
  5. HX could theoretically be split into 4 sizes, I don't know how much value there is there given the smallish number of HX parts that exist
  6. Hmm, I'm not totally clear on what CryoTanksCore is supposed to provide, let me look a little closer. E: yeah, okay so the way CryoTanksCore is installed it makes ModuleManager register CryoTanks as an installed mod. OPT sees this and creates tank types that use it. @JadeOfMaar what's your perspective on this from OPT's side? Theoretically all those patches could also require CRP, but it seems like this might be an uphill battle in general, with many patches across many mods potentially being affected.
  7. @Murdabenne You don't have Community Resource Pack installed. It's a requirement of CryoTanks.
  8. Can you check for a leftover empty FerramAerospaceResearch directory in GameData?
  9. Looks more like config/install issues with OPT, please include KSP's log if you want any actual help.
  10. Thanks for the log, that lead me the problem quickly. It looks like you have a corrupt installation of CommunityResourcePack. Many of the mods you have installed depend on it. Try reinstalling it.
  11. I generally don't bother paying attention to old KSP versions, so as soon as I'm compiling for a new version, that's what the version file will say and that's what CKAN will consider compatible. It may happen to still work with older KSP versions but I don't guarantee anything.
  12. The question you should be asking is does RO support this. I don't know the exact state of everything right now but in general BDB changes fast enough that the RO configs are often out of date.
  13. http://heroicrelics.org/info/titan-i/titan-i-stage-2-engine.html I've generally found Heroic Relics to be a reliable source
  14. Looks like probably node_stack_top/node_stack_bottom, verify the the parts you're targeting actually have a size specified on the nodes Also prefer @RESOURCE[LiquidFuel] { @amount = x @maxAmount = x } over indexing, it's less brittle
  15. @Pappystein Titan I only lit the 2nd stage verniers prior to stage separation, the gas generator was run off of a separate set of pumps to facilitate this (this was removed on later LR-91s as they had exhaust holes in the interstage to support full hotstaging. AFAIK they ended up with separation motors too in the end though.
  16. The error message is somewhat misleading, it's almost always mod misconfiguration (which B9PartSwitch is just noisy about rather than swallowing silently). I can help look through logs and config caches if that would be helpful, usually between those and cross-referencing patches on Github it's possible to figure out which mod is misconfigured.
  17. Actually just to eliminate this, can you try deleting your part database? I've seen a lot of weird caching issues around that and there's no proper invalidation for it.
  18. my guess is that ModulePartVariants is messing with it somehow, would it be acceptable to have drag cubes not affected by B9PartSwitch switching?
  19. Thanks @JadeOfMaararen't these two patches conflicting in the absence of ClassicStock? https://github.com/JPLRepo/Endurance/blob/master/Distribution/GameData/Endurance/Patches/B9PS.cfg#L251 https://github.com/JadeOfMaar/EnduranceReconfig/blob/master/GameData/EnduranceReconfig/B9PS.cfg#L195 This is already working PART { // ... MODULE { name = ModuleB9PartSwitch // ... SUBTYPE { // ... TRANSFORM { name = whatever scaleOffset = 2 // multiplies that object's sca
  20. Okay I figured out what's happening - MM is delaying replacing physics until the space center, which means that when the part loader reads those values it gets the stock ones. If you reload the game database it might get the values from the first load. I can't see any reason why MM shoudln't be able to do the physics thing immediately, so the solution is probably just to do that.
  21. Not really possible in general, I've seen some half baked attempts at this but they all mess up under some circumstances, the fundamental problem is that there may be instances of objects from the old DLL still present, and there's no way to guarantee that they can be converted to new objects. I recommend creating a minimal test install so that the reloads are less time consuming. You might even consider removing some parts of GameData/Squad if you want really fast startup.
  22. need to see the log to know which parts are misconfigured
  23. Ugh, I'll look, if KSP is accessing this before MM has a chance to do its thing then there might not be anything to be done, but maybe it can be set later too. E: hmm, not seeing anything obviously different here, can you provide more info about what about it doesn't seem to be getting picked up?
×
×
  • Create New...