Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Starwaster

  1. I have to get Visual Studios back up and running then ensure I can compile it and verify it works okay. It probably will as the source HAS been updated by the Realism Overhaul crew for Real Fuels. Although there were some changes made to a section of the base MFT code that I can't abide... Until then though, you can still download an older version... https://web.archive.org/web/20210126120441/http://taniwha.org/~bill/ModularFuelTanks_v5.13.1.zip
  2. Doesn't seem like @taniwha is coming back to this. He still visits the forum but is not active in the community and hasn't even posted anything in 2 years. You could try using it anyway and ignore incompatibility warnings. AFAIK it'll still work. The incompatibility warning is triggered by a version mismatch. Literally all it does is check what version of KSP the mod has listed as being for and triggers the message. It's not a message from Squad, it's a 3rd party mod that many mods opted into. So, it should be functional but no guarantees. There are other mods that let you edit the content of tanks. Real Fuels is a variant of MFT but with extra features. I think B9Switch lets you alter resources but not sure to what extent. SSTU lets you do it for SSTU parts but again, not sure to what extent. (when used with MFT or RF, those provide the only resource editing function) I'll look into updating and compiling MFT myself. Can't say when that'll happen.
  3. @RunaDacino Most of them are this: NullReferenceException: Object reference not set to an instance of an object FerramAerospaceResearch.FARGUI.FARFlightGUI.PhysicsCalcs.CalculateEngineAndIntakeBasedParameters (System.Double vesselSpeed) (at <8fc38445915649c48b25aabd1db34a9d>:0) FerramAerospaceResearch.FARGUI.FARFlightGUI.PhysicsCalcs.UpdatePhysicsParameters () (at <8fc38445915649c48b25aabd1db34a9d>:0) FerramAerospaceResearch.FARGUI.FARFlightGUI.FlightGUI.FixedUpdate () (at <8fc38445915649c48b25aabd1db34a9d>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) over 20,000 of them
  4. @JadeOfMaar You've definitely got a problem with the docking node transform. I downloaded the beta, put a test craft up there and MJ is trying to dock at a 90 degree angle to where it should be. Edit: Good news is that the control transform seems okay. If I control from it then it's trying to align through the docking port instead of the front of the part. Although, which way should be the top? Right now it's trying to use the back of the part as the top (the direction of the hatch handle) If that's what you intended then it's fine. Edit: 2 That bounding box is messed up... not sure what part is doing that but it shouldn't be so long: Edit #3: Nevermind. It's the fricken Wolfhound that I had mounted on the back for propulsion.... WHY is its bounding box so goddamn huge???
  5. The correct orientation is for the forward (z axis, or blue in unity editor). The up axis is optionally used for orientation around the forward axis. (that is, a port can be configured that the two up axes have to be aligned for docking to succeed) The transform should be named dockingNode OR nodeTransformName should be set in the ModuleDockingNode to whatever you did name the transform. There's also an optional controlTransform (designated in the config by controlTransformName) which if absent defaults to the part's base transform. As to the collision issue, no idea... Edit: Actually, for the controlTransform, you should consider that not so optional for the inline ports. When controlling from the docking port, the controlTransform needs to be the same as if it were a cockpit orientation.
  6. Started happening in the current beta? Do you think it's a problem with the model or the config?
  7. If engines with electrical requirements don't have enough electricity then it kicks in. It's not NF specific though.
  8. Any OPT users who also use Deadly Reentry should re-download this file and copy it into the DeadlyReentry folder. (had a misspelled manufacturer check affecting ~7 parts) https://raw.githubusercontent.com/Starwaster/DeadlyReentry/working/DeadlyReentry/DeadlyReentry-OPT.cfg
  9. It would help if you posted the patch you made, but I would delete the pre-existing waterfall config since you say yours is working great. Something like this: @PART[whatever-part-it-is] { !MODULE[ModuleWaterfallFX]{} !EFFECTS,*{} // I DON'T know that you need to delete EFFECTS, if you're not adding your own then probably don't do this? // Your Waterfall config here after this }
  10. Hopefully just a transient DNS failure. Try again periodically. Pinging @sarbian just in case! (Sarbian, I choose you!)
  11. @Max Que The game is in alpha, at best. Not even in beta. It's still in development.
  12. The concept of skin temperature actually originated in Deadly Reentry with the advent of KSP 1.0 when I was trying to decide if the mod was still needed. It's a lot harder to heat things up to 'deadly' levels when parts have a unitary thermal mass to overcome and no concept of how hot things actually are on the surface. So the new DR got skin temperature which they eventually incorporated into the stock game. Not sure why they decided to reinvent the wheel but it's going to be rough balancing thermals in a way that makes reentry challenging without making things too hot during launches and supersonic/hypersonic flight. Being able to factor in surface temp vs overall part temp helps with that. I do see references though in the PhysicsSettings.json file to skin conductivity. Maybe they're just leftovers from KSP 1.
  13. Tanks should be converted but engines need third party support. If you don't have a scaled up starsystem then this should do it: https://github.com/ValentinBischof/RealFuels-Stock I've recently discovered though that BDB had a lot of changes to part names, which breaks things like saves, craft files, and mod patches. RealFuels-Stock seems like it was updated to account for that but I'm not sure everything was fixed. RO support for BDB seems broken because of the changes. Some things work, others don't.
  14. Not really a valid question. Waterfall just adds plumes (and effects?) to engines. It doesn't require anything from Real Fuels to function.
  15. If it's a bug in the plugin then reinstalling isn't going to do anything. Try the latest dev build which is here: https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/1395/ If it still does it then maybe we need to take a look at your spacecraft design. Maybe your RCS placement isn't balanced. Or maybe you need to describe the problem differently because honestly I don't know what 'stutter' means. Does the RCS light keep going on and off?
  16. It doesn't seem to have helped though. The related code all needs to be gone over to root out the problem. Ooops didn't see that there was a newer dev build that Lamont just worked on for this.
  17. Now I'm confused, I thought your problem was that you had lost/didn't have the ability to switch tanks. Please re-state your problem? And it's probably time to post log and ModuleManager.ConfigCache. Every single patch affecting your parts will be logged and the final result shown in the cache file.
  18. Modular Fuel Tanks is for stock resources. Real Fuels is the one that handles LiquidHydrogen/LiquidOxygen and other assorted realistic propellants.
  19. MJ does not add the MJ module to command pods by itself. That requires a separate patch. If you had it being added before then you had another mod installed that was patching the command pods. It sounds like that mod is no longer present. Think back to mods you recently uninstalled. You could also just patch it yourself. I maintain my own tweak folder for portability that contains MM patches. One of them is this patch: (Note that commented line: the docking guidance module was changed to be available at start. You may want to switch it back. Or not.) MJ_for_all.cfg @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final { MODULE { name = MechJebCore eduMode = true MechJebLocalSettings { MechJebModuleCustomWindowEditor { unlockTechs = flightControl } MechJebModuleSmartASS { unlockTechs = flightControl } MechJebModuleManeuverPlanner { unlockTechs = advFlightControl } MechJebModuleNodeEditor { unlockTechs = advFlightControl } MechJebModuleTranslatron { unlockTechs = advFlightControl } MechJebModuleWarpHelper { unlockTechs = advFlightControl } MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl } MechJebModuleThrustWindow { unlockTechs = advFlightControl } MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl } MechJebModuleRoverWindow { unlockTechs = fieldScience } MechJebModuleAscentGuidance { unlockTechs = advFlightControl } MechJebModuleLandingGuidance { unlockTechs = unmannedTech } MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech } MechJebModuleDockingGuidance { unlockTechs = advUnmanned } MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned } MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned } } } }
  20. What matters for Restock is whether or not they changed to a different model for the decouplers which would affect its exposure and possibly also how it interacts with the thermal shockwave. (shape matters)
  • Create New...