Starwaster

It should be, but it would take some work to write a patch that brings it in line with SMURFF's mass values. Looking at what the author has said on the subject, it seems like their position is that Real Fuels should be used instead.

It doesn't matter who it's aimed at, the only ones here to catch the brunt of it is the moderators. If you're taking it personally, how do you think they feel? They can only take so much negativity before THEY start taking it personally. So please ease off. All we have left is volunteers.

They all hang out in the Realism Overhaul Discord and I don't go there anymore. And I'm not sure any of them really pay attention to the RF topic anymore. Could try pinging @NathanKell @siimav @blowfish and see who maybe turns up.

It would be a good idea if you created an issue on the Github repository about that. For increased visibility.

What trusses are those? [snip]

Looks like it's only set to cool the part it's attached to, not vessel-wide cooling.

Ooops my bad. I must have missed the memo!

linuxgurugamer is maintaining this mod now:

Your log file contains a lot of exceptions from DynamicBatteryStorage.ModuleCryoTankPowerHandler. If those are happening after a scene change to Flight then those are probably what's killing your performance by causing the log file to be spammed continuously. Exception handling event onEditorShipModified in class EditorVesselDataManager:System.NullReferenceException: Object reference not set to an instance of an object at DynamicBatteryStorage.ModuleCryoTankPowerHandler.GetFuelTypes () [0x00008] in <ce8c094d51db45938ad65ca113e0ce60>:0 at DynamicBatteryStorage.ModuleCryoTankPowerHandler.Initialize (PartModule pm) [0x00009] in <ce8c094d51db45938ad65ca113e0ce60>:0 at DynamicBatteryStorage.VesselElectricalData.SetupDataHandler (PartModule pm) [0x0008f] in <ce8c094d51db45938ad65ca113e0ce60>:0 at DynamicBatteryStorage.VesselData.RefreshData (System.Boolean fromScratch, System.Collections.Generic.List`1[T] vesselParts) [0x001db] in <ce8c094d51db45938ad65ca113e0ce60>:0 at DynamicBatteryStorage.EditorVesselDataManager.InitializeEditorConstruct (ShipConstruct ship, System.Boolean forceReset) [0x00043] in <ce8c094d51db45938ad65ca113e0ce60>:0 at DynamicBatteryStorage.EditorVesselDataManager.onEditorVesselModified (ShipConstruct ship) [0x00024] in <ce8c094d51db45938ad65ca113e0ce60>:0 at EventData`1[T].Fire (T data) [0x000b0] in <4b449f2841f84227adfaad3149c8fdba>:0 (Filename: C:\buildslave\unity\build\Runtime/Export/Debug/Debug.bindings.h Line: 35) That and similar errors appear thousands of times in the log.

FYI, City of Heroes yet lives. For a long while, only as a private server for a select few. Then the server code was leaked and public servers went up. NCSoft apparently okayed it.

Nope, still works. Maybe there was a temporary issue but it is working.

@Zaxxon 10xKerbol is the name of what I'm using. Yes, it's old, but it's just a set of configs for Kopernicus which is updated. This is the thread for it: However, it looks like there's an issue with Spacedock: the link from that thread is broken. Use this link instead: https://spacedock.info/mod/296/10x Kerbol system

Hope you don't mind my saying, but I'm getting some serious pokeball vibes from that part

Every time you open up the in-game Deadly Reentry menu, you'll see one of two random pictures of Barbie. One was from before she arrived here (my sister described her as having 'seen a few things' and another after she'd been here for awhile and had a happy content expression. She was a tiny little cat, kitten sized even though she was a full grown adult cat. I don't think she could possibly have been more than 4 lbs. (less than 2kg if you prefer metric)

There's a mod that rescales Kerbol System by 10x. That brings it up to RSS scale. Kerbin adjusted to have a 130km atmosphere cutoff. I think it's actually called ReScale 10x? If you also want RP1/RO then you'd have to do a custom install without RSS but that probably means installing manually without CKAN because RSS is a requirement of RO. So you'd do something like an installation that has 10x + whatever RO mods that you can't do without. Real Fuels at the very least, maybe FAR for aerodynamic handling. Plus whatever else that I'm not thinking of right now because I'm not in the mood to brain... Be mindful though of grabbing configs directly from RO if you're not actually INSTALLING RO because those configs use a lot of FOR[RealismOverhaul] which signals to Module Manager and every other mod config that RO is installed which means editing a lot of configs by hand. Mostly I'm thinking of parts properly resized/adjusted for a scaled up environment. There are enough stock parts to get you by except in the 8m-10m diameter range + appropriately powered thrusters. SSTU is a big help there and works well with Real Fuels.

You're doing Lagrange points as celestial bodies, right? It looks like the Contract system multiplies contract destination weight by a body's RecoveryValue. Try setting it to 0 for the Lagrange points. In the Properties node Properties { <various properties> ScienceValues { RecoveryValue = 0 } } All fields you can set for a body's ScienceValues. (They default to 1 ) LandedDataValue SplashedDataValue FlyingLowDataValue FlyingHighDataValue InSpaceLowDataValue InSpaceHighDataValue RecoveryValue Not sure what you want to do with these, if anything. flyingAltitudeThreshold spaceAltitudeThreshold CAVEAT: I don't know for a fact that this will stop contracts from showing up. I believe it will. They might show up anyway but immediately fail if accepted. (a lot of things depend on the destination weight, so deadline time, funds, science, it's reasonable to think that if a body has no value then the contract system shouldn't generate contracts for that body. If that assumption is wrong then you get the contracts anyway and they autofail/don't provide value)

Is Persistent Rotation a required mod now for RO? And yes, The Descent AP commands an attitude that if deviated from will cause it to want to correct that and it will come out of warp to do so if necessary. To put it another way, regardless of if autowarp is on or off, the DAP will maintain a set attitude all the way through descent. That's realistic and to be expected. It's not going to allow the vehicle to pitch, yaw, and roll uncontrollably. How do you control your attitude through autowarp normally? Or is that just not a thing with PR? According to ULA: "The optimum thrust to weight ratio at the start of the descent burn is in the 0.35 to 0.5 range (using Earth weight). At touchdown, the thrust to weight ratio should be about 0.15 (thrust slightly less than weight in lunar gravity)." Sadly, this has always been an issue for MJ, especially ignition issues. And especially with limited ignition. I don't use RO anymore but I ended up disabling the limited ignition feature. In fact, that gets patched out of my game by default even without RO. And I think none of the engines I have (added through mods) are unthrottleable. But it should be trivial to add a check that if any engines are unthrotttleable then don't try at all. (if you have a mix of engines though, that probably would be a bad idea). For the second part, yeah, MJ does not handle spooling at all. It needs to add spool time to the suicide countdown. (Did LMDE have a spool time? I think it maintained some level of thrust all the way down, which is also not something MJ does well.)

Sorry, not yet. This is definitely something I want to do but I haven’t had a chance to sit down and work the equation into the config AND then tie the heatshield to that.

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

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.

@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

@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???

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.

Started happening in the current beta? Do you think it's a problem with the model or the config?

Is Deadly Reentry installed?