Jump to content

Starwaster

Members
  • Posts

    9,282
  • Joined

  • Last visited

Everything posted by Starwaster

  1. Just the custom probe core; the bit I am just now noticing is you tagged it with skynet
  2. @Shadowmage Uhm, can't believe I am only just now seeing this... Custom Probe Core? Tags? SKYNET?
  3. I once took a stab at converting Nertea's station parts to use the stock version and I will tell you it was a major PITA and I gave up on it because I just didn't have that kind of time. The process was easy but incredibly time consuming because the stock ModulePartVariants assumes all model parts to be active unless explicitly turned off. The B9 part switcher is the exact opposite and requires models to be explicitly turned on. That made for a lot of work and very bloaty configs and I gave up in frustration.
  4. Not to be snarky but 'the latest version' aint no version number I ever heard of! You need to give accurate information or else how do you expect to get accurate help? The latest version number (for the branch of Bon Voyage maintained by Maja) is 0.5.2 and doesn't say anything about path not found. That's the kind of thing the older version by the original author would have said. Maybe you want this: https://github.com/jarosm/KSP-BonVoyage/releases/latest And, whatever you have installed right now, COMPLETELY delete it. Shift-delete so it doesn't even go to the recycle bin. Then install the file you download from the link above.
  5. what batteries are you using? Maybe there's no flow to the repulsors? I forget, do they have a resource flow button in the PAW? (to show the path that resources will feed to). If so, click that and see if power is getting held up somewhere. Maybe there's a part that has crossfeed disabled
  6. That... is a good question. I do not know. I don't think I've ever paid attention to the situation of a vessel that actually made it intact to the bottom of the crushing depth of Davy Kerman's Locker...
  7. Yeah, situation should be changed to SPLASHED when the biome is a water type. Though it may still be possible to complete that contract as is if you try it on the shore depending on how accurate the biome map is. If the sea biomes as mapped protrude onto land anywhere it would work. (not suggesting that as the correct solution; just as a work around)
  8. Is 2.5x really that much harder? I would think that the stock 3.75m and 5m parts are up to the challenge. But then I either play stock sized or 10x size with nothing in between, so... just asking out of curiosity what 2.5x is like....
  9. That's kind of how I feel about Deadly Reentry. People have (ever since KSP 1.0) speculated on DR's inevitable demise since we now have atmospheric reentry heating. And yet of course DR is still around. First by implementing its own thermal system override on top of 1.0's thermal and then when Squad adopted that system there was still the need to rebalance max temps of parts that had all the thermal survivability of tungsten. So it will be interesting to see how KSP 2 handles thermal.
  10. @Mephisto81 you don’t need to set ROC_VISUAL_SPEED so low. For JNSQ somewhere between 25-125 is low enough. Unless you're trying to stop them showing up at all?
  11. @draqsko yes, all underscores are turned into and stored as dots. That is an internal change i.e. at runtime. It’s not a problem, generally, unless someone tries to refer to the part in code specifically by name, with a hard coded value that does not use the correct name string.
  12. @Gremillion replace GameData/RealismOverhaul/RO_SuggestedMods/SSTU/SSTU_Tanks.cfg with https://raw.githubusercontent.com/KSP-RO/RealismOverhaul/master/GameData/RealismOverhaul/RO_SuggestedMods/SSTU/SSTU_Tanks.cfg
  13. yeah I hope so too but that might be asking too much given the frustration he's experienced with KSP1....
  14. I found at least part of the problem is that they’re cloning SSTU tanks before SSTU’s compatibility check so I’m going to go do a PR to fix that today.
  15. @RobK I’m not surprised that it didn’t fix any issues with parts losing resources. I don’t know what I might have said to make anyone think it would...
  16. No it has to run last or at least after all that cloning. (that's why I put :FINAL in there so it runs last no matter what) Well crap then I have no idea. All I know is the SSTU RF compatibility patch runs in :FOR[SSTU] and the cloning of those parts happens in :FOR[RealismOverhaul] so the cloning takes precedence over the patching. SSTU ends up patching only its own parts. I'll see about getting someone to fix the timing of the RO patch or to do the patching oureselves
  17. @Gremillion put the patch back in that I posted a few posts back: The problem is: that tank is a clone of the MFT-A and it's being cloned BEFORE SSTU patches any of the MFT parts
  18. What about the normal MFT-A tank? Lander tank?
  19. @Gremillion no, this is what you want: https://github.com/shadowmage45/SSTULabs/releases/tag/0.11.49.161
  20. @Gremillion scoured the logs and the cache and don't see why it's happening but things aren't being patched that need to be. (sound familiar?) @PART[*]:HAS[@MODULE[ModuleFuelTanks],@MODULE[SSTUModularPart]]:FINAL { @MODULE[SSTUModularPart] { %subtractMass = false %subtractCost = false } } The above patch should render the mass = 0 patch unnecessary. You should be able to safely remove or disable it. If the above patch does NOT fix the issue then you don't have the right version of SSTU installed. What that does is basically tell SSTUModularPart to opt out of all mass and cost manipulations so that ModuleFuelTanks can take over responsibility for it.
  21. What is being Ok, not understanding what's being inquired of me... Though I do see some serious glaring error in @Buflak 's config snippet there. Whatever patched that config needs to be taken behind the woodshed and executed with a gunshot to the head regardless of whether it worked or not, SOMETHING did not patch that in correctly and it needs looking at. Yes it worked because the first name, type and defaultScale are all that got used but the fact that it's in that condition says it was written badly.
  22. You did that and still had the negative mass issue? Can you upload a copy of your log files (either KSP.log or preferably output_log.txt if it exists) and from your GameData folder ModuleManager.ConfigCache file? Preferably to DropBox or to some other upload site. (DropBox is best because you get lots of free storage and it doesn't try to serve up ads to people needing to download from it)
  23. I inquired about that in the SSTU thread because as far as I was aware all you need i the SSTU update and that's all I have myself and it's fixed for me. But did you install that as a complete reinstall to remove the possibility of older files sticking around? Because the update (I think) also depends on a few things being turned off in the patch... maybe try completely deleting all trace of SSTU before installing the latest one.
  24. @Shadowmage re the mass issue, I thought the most recent SSTU already patched itself appropriately? Isn't that what these lines do? (the one for mass and the other for cost?) https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/ModIntegration/RealFuels/RF.cfg#L8-L9 I'm didn't do anything other than install the latest SSTU (complete reinstall) and it was working fine so I didn't think anything particular had to be done on RO's side. Or is that not so?
×
×
  • Create New...