Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Starwaster

  1. Is this an across the board permanent change you want? You can make a patch that sets sunTracking to false in all ModuleDeployableSolarPanel.
  2. Oh god.... that bot.... that's horrible.... He has to stay locked up in that tiny little cabinet? No wonder he looks unhappy. And I bet he's got a pain in all the diodes on his left side that he's asked to have replaced...
  3. 24 hours between launches is much more likely than a week. No point in leaving a tank full of hydrogen up there for an entire week if you don't have to.
  4. @FinetalPies that was pointed out several posts above yours and a patch was provided to correct the problem
  5. Probably? Most of the required component launches fall inside of what SLS can launch though there might be some downsizing required. What you refer to as Copernicus consisted of a number of different proposals which has evolved over time. But yes, it's possible. Here's some documents that might interest you. Some of them are quite detailed http://large.stanford.edu/courses/2014/ph241/wendorff1/docs/aiaa-2009-5308.pdf https://ntrs.nasa.gov/api/citations/20150004421/downloads/20150004421.pdf https://www.nasa.gov/sites/default/files/atoms/files/sls_core_stage_fact_sheet_01072016.pdf
  6. That's used to determine how much heat is removed along with the heatshield material that got ablated away. It's ablated amount * density * specificHeatCapacity * pyrolysisLossFactor
  7. No, that does not happen to me. What other mods are installed? If this is easily reproducible then let a ship explode and then get the logs and upload them somewhere like Dropbox where they can be accessed by others. Post the links here where they can be downloaded
  8. As you've figured out, this is from stock (Squad) code. Specifically it comes from ModuleAblator from which ModuleHeatshield derives. The formula for loss is: lossConst * Math.Exp(lossExp / infoTemp) * ablator maxAmount * ablator density * 1000 where infoTemp is 2000 by default. (you can add this in as a custom temperature to check against in ModuleHeatshield / ModuleAblator) My advice to you is to save yourself some pain and touch none of the fields you referenced above except for lossConst Or if you absolutely must change the others then plug that formula into your spreadsheet.
  9. Make sure your mouse cursor is not over any MJ window when you press that slash key. That means you have to conscienciously clear the warp setting in the MJ menu and then move the cursor out of the window.
  10. The landing GUI and associated code is a separate issue and there is a definite long standing bug in there in that the landing code isn't checking for conditions (that should result in disabling warp) while currently in warp. The main two conditions being whether or not the option is enabled for warp and whether the landing guidance is still in effect. Either of those should cause warp to be cancelled. Furthermore, once warp has been enabled, it is still treated as enabled even if the warp option is disabled IFF landing guidance is still enabled. The end result being that warp must be disabled (in the Landing Guidance window) AND auto landing must be cancelled before manually stopping warp (and you must manually stop warp). Otherwise, the landing guidance will re-enable warp.
  11. It's better to experience painful things. Pain is an excellent teacher. Without pain, learning is impossible. You have now learned that there are things in the game that will cause you pain necessitating a choice between reload or loss of Kerbal or ship.
  12. No, it doesn't really make it much clearer. Different players have different ideas about difficulty. Even with DRE (for stock Kerbin) I have to go up to at least 150% before I even start to feel challenged. To me, DRE is more about introducing consequences for poor design choices. No matter what the reentry scale is at, you should always be capable of designing something that can survive your mission's reentry. And a good design will survive 100% of the time. A bad design will probably almost always fail. As far as the reentry heating slider goes, I think the best suggestion here is for you to run through several reentries and adjust the the slider each time until you find a setting that satisfies your needs.
  13. Interpreting your question literally, 100% as Deadly Reentry no longer touches KSP physics. Those now are deemed adequate to my purposes (and have been for awhile). So quite literally, heating happens at the same rate as before. The main changes from stock are to the thermal tolerances of every part. The max temperature of everything is capped. Ablative heat shield ablation rate is 10x greater for everything except the Mk1 pod which is 16x greater. The other changes are in how parts react to overheating.
  14. Not enough information to say, but AFAIK, RSS doesn't actually change science rates or multipliers. What other mods do you have? Also, what exactly did the message say about the science returned? There might be a clue there as to what was driving your science return so low. Edit: Oops, didn't click the Reddit. Ok, 50m is way too close. You weren't going to get anything for that anyway. I think the real issue is the mass. 1.3 tons is probably just not enough to amount to anything. Distance is also an issue; there's a sweet spot between point blank and the other side of the planet where you get 100% .
  15. Banned for being an anti-canner
  16. They really aren't (different in concept), unless you launch from a different planetary body with a different gravitational constant. So then you have to use a different value when setting up your launch profile. ^^^^^^ THIS ^^^^^^^^^^^^ The UI is already too crowded and there's been way too much feature creep over the past few years. There's already a way to limit by TWR that just requires some simple math and does the same thing If having a TWR limiter is your only reason for using MJ then you should do without MJ. And I apologize for being overly blunt but the statement stands.
  17. It's recomputing the lift force but but not changing where it's applied which is still partTransform + CoLOffset. The actual instruction is part.partTransform.TransformPoint(part.CoLOffset) and returns a vector = to the transform + the offset. Not sure that's even needed as I thought the lift vector was already being modified according to angle..... Edit: Oh ok it's a complete override of ModuleLiftingSurface so it has to do that itself. Too early in the morning to look at code...
  18. No, I mean 'Limit acceleration to' 17.676 which will be the same thing as if you were limiting TWR to 1.8
  19. It's already in there. Enable the box next to 'Limit acceleration to' and in the text entry box next to that, enter a value of 17.676
  20. @EritoKaio The problem there is that the force is being applied to the part transform (partTransform + CoLOffset ), which doesn't move. So you would be correct in saying that force isn't being applied to the correct point on the flap so: no, the center of lift/pressure won't be correct for the flap part but it is changing for the vessel as a whole. Stock KSP doesn't have a debug display for the vessel CoL so you would either need to code one or use MechJeb, which has debugging displays for the vessel CoM/CoL. As for correcting the problem, because you're using the Tundra Exploration mod for flap control, it occurs to me that one could modify the code to adjust CoLOffset and CoPOffset on the fly (and CoMOffset while you're at it if you really want to be a stickler for detail) What you would do is recalculate the offsets based on flap rotation so that it follows the flap. Edit: You wouldn't actually change the offset value, just track where it would be as it traverses around the partTransform and apply the force there.
  • Create New...