Jump to content

Starwaster

Members
  • Posts

    9,282
  • Joined

  • Last visited

Everything posted by Starwaster

  1. Look in the RealFuels folder for RealSettings.cfg. Edit that file and look for a line that says 'limitedIgnitions = true' Change it to 'limitedIgnitions = false'
  2. Then configure the chute (in the VAB / SPH editor action group editor) to land at a lower speed. You can totally edit RC chutes to your specific custom needs. Not that hard to do either.
  3. Not to mention embarassing.
  4. The avionics ring / service modules do not stage by design and must be decoupled manually through context menu or action group. Fairings exploding: Sounds like an outdated version of SDHI. The colliders had to be completely reworked when concave colliders support was removed from KSP. Terrier: As far as usage, no, there's no point in using it over the stock version. I imagine (hope) that the part stays in the game for backwards save game compatibility. Though maybe it could be removed from the editor listing by changing its category to something non-existent? @sumghai Re: Chute. Sounds like you also need to update Real Chute. There was a staging issue with it but I think that's resolved now?
  5. I think I know what's wrong. It's not going to be possible for you to override until I fix something that I broke I can't say exactly when but I am planning to do a final 1.0.5 update before KSP 1.1 is released. (fixing, among other things, the missing menus)
  6. Might be this: https://github.com/Nils277/KerbalPlanetaryBaseSystems/blob/master/Sources/PlanetarySurfaceStructures/DependentLight.cs#L180 If you're restoring animation state from persistant data, don't play the animation, just set the normalizedTime
  7. Not ratio, what you want is atmosphereCurve. First digit of each key is atmospheric pressure, in atms. Second digit is Isp for that atm pressure. That's the one that you want. (there may only be one key for some jet engines. Not sure if OPT is done that way)
  8. NP! Also, if you open up the file DefaultSettings.cfg you will see those exact same settings but with comments explaining what each one does.
  9. Better would be to create a new file with extension cfg like DeadlyReentryOverrides.cfg and then paste the text I gave you into that file. It will override DRE's settings. Except that I just noticed a problem with what I gave you so I'm going to go fix it right now.... Corrected cfg (replaced most @ with % - Why that matters is because @ means to replace an existing cfg node, and most of those won't be valid until AFTER DRE has completely loaded) // Physics Overrides & Settings @REENTRY_EFFECTS[Default]:Final { %crewGClamp = 30 %crewGPower = 4 %crewGMin = 0 %crewGWarn = 450 %crewGLimit = 900 %crewGKillChance = 0.01 %ridiculousMaxTemp = 1523.15 %maxTempScale = 0.5 }
  10. Then don't use it. Stick to stock. Or file a specific bug report with repro steps and logs. Use the Github issues page to create a new issue: https://github.com/StupidChris/RealChute/issues Do you know how to find your logs? If not, read the following.
  11. Chris never claimed it didn't do any of those things. Never claimed a level of compatibility that you (apparently?) think was claimed. All talk of compatibility has been aimed at things such as meshes, parts and transforms. KSP version compatibility. Third party chute part compatibility. It was never ever claimed that stock code would be able to identify Real Chute parts as having parachutes. And it is up to third party plugins as to whether they will or will not update their code to recognize RC parts as being parachutes. Take for example Deadly Reentry, back in the day when DRE had special chute handling code. Did Stupid Chris ever make representations that RC would be compatible with DRE's chute handling? Whose responsibility was it to implement such compatibility? Chris or the modders responsible for DRE? Nathan and I had to do that and make sure it stayed up to date with any of RC's code changes. If there is a third party plugin that you think RC is not properly compatible with then it's up to the modders in charge of those mods as to whether or not to do that.
  12. Using key combo to open the menu was removed well over a year ago. The menu itself isn't functional at this time but you can create a Module Manager patch that does the same thing. Below is a sample config that you can use. These are the only DRE specific settings you can access. All thermodynamic specific changes must be made using the stock interface. (i.e. PhysicsGlobals, etc) // Physics Overrides & Settings @REENTRY_EFFECTS[Default]:Final { %crewGClamp = 30 %crewGPower = 4 %crewGMin = 0 %crewGWarn = 450 %crewGLimit = 900 %crewGKillChance = 0.01 %ridiculousMaxTemp = 1523.15 %maxTempScale = 0.5 }
  13. Your problem is probably unrelated. The message is triggered by Firespitter itself after a simple version check. If you run a lot of mods then low memory is the most likely culprit. then again: this thread isn't the place to go for firespitter or general support...
  14. Actually it's 114 watts of electricity per watt of heat (using RF/RO, EC would be kw, so rate would be set to 114 kwe / kwt. I kind of screwed that up there) And that's regardless of environment. 114 watts period. That's the cost to move the heat to the radiators.
  15. More precisely, it needs a PROPELLANT that has mass/density. Part of the formula for determining thrust relies on propellant mass flow and ElectricCharge has no mass flow
  16. Maybe if people knew what the 50 errors were, someone could help...
  17. The context menu is an accurate indicator of thrust and it says that engines in reverse put out the exact same thrust as when forwards. There's no change. So what are you basing your statement on? The only link in your signature that seems relevant... I'm not sure what to make of it; what there is a direct comparison of thrust?
  18. By default, heat pump parts only target the parent part to which they are attached. To make them target a specific node attached part you need to specify the attach node as follows In the following example, any parts attached to node_stack_bottom and node_stack_latch would receive cooling. Note Heat Pump doesn't limit cooling to the heatTransfer value. In addition to that, it also will provide enough cooling to neutralize however much heat penetrated into the tank interior. (so, skin <-> part influx + heatTransfer = amount of cooling applied * (parent part + attach node targets)) The rate specified for ElectricCharge is ok for stock but Realism Overhaul environments should use a value of 114 ec / watt of heat removed MODULE { name = ModuleHeatPump heatTransfer = 0.078 heatConductivity = 0.0039 RESOURCE { name = ElectricCharge rate = 1 } HEATPUMP_NODE { name = latch } HEATPUMP_NODE { name = bottom } }
  19. Have you checked out RoverDude's submersible pack? It has ballast parts and ballast tanks...
  20. Nuh uh! Nowai!!! Whut sorcery is this??? Ooooooo how does it interact with the god rays? Someone needs to get a shot of an eclipse on the horizon (as in during sunrise). That would look awesome
×
×
  • Create New...