Jump to content

Starwaster

Members
 View Profile  See their activity

  • Posts

    9,282

  • Joined

  • Last visited

 Content Type 

Everything posted by Starwaster

  1. Starwaster
    Album demonstrating use of inline ports, surface mounted and rotated. http://imgur.com/a/FZltq It really does not matter. If you had problems with something like this in the past then other factors were at work. The docking AP may not be perfect but it's pretty robust and capable of handling some pretty weird configurations. The only thing I've really seen it have trouble with is where it has other larger parts that expand its bounding box to the point that the target port is deep inside. The reason being that it can get confused as to which side it needs to be on. Increasing the starting point and making sure it's on the right side beforehand can help it handle even those situations.
  2. Starwaster
    That doesn't really matter because the docking AP looks at the part itself, specifically its transforms. The transform dictates where the part's docking axis actually is and which way it points. Because of that, a docking port can be located anywhere on the vessel and it can point any direction. The vessel transform isn't used and the docking transforms (up to two of them: One for control and the docking axis itself) can be different (and usually are) from the part's own transform.
  3. Starwaster
    Lower your engine gimbal authority to 36% If control authority is too low after that then gradually increase it. (36% should do fine)
  4. Starwaster
    I didn't even think of putting them in subassemblies... must be the creeping senilitiez setting in again
  5. Starwaster
    The service module tank type represents a structural component with non-integral dewar type tanks. (non-integral meaning the tank is mounted to the structure rather than FORMING the structure) Because it's basically a vacuum bottle and only receiving heat through a very limited contact area (its mounting points) it has very little heat leakage. In fact, the Apollo's LOX / LH2 tanks actually required heaters IN the tanks to provide enough heat flux on demand to maintain tank pressure within a pre-determined cut-in/cut-off range. The final insulation figures that I settled on were arbitrarily determined by Apollo service module base heat leakage. (i.e. before added heating was applied) The following NASA document was a useful reference: https://history.nasa.gov/afj/aoh/aoh-v1-2-06-eps.pdf (pages 2.6-10 thru 15)
  6. Starwaster
    It's those control surfaces. Lose them. Unless your engines are not gimbaled. If that's the case and you absolutely need control surfaces then reduce their control authority to somewhere between 30-50% If those engines ARE gimbaled then you don't need control surfaces
  7. Starwaster
    It depends on what those tanks actually represent? Are they just service module types wrapped in MLI? That's what it looks like you're trying to model. If so, then those configs are probably ok. The outerInsulationFactor is questionable. It looks like you pulled that from the cryogenic tank def and I'm not sure that was a good value. It's kind of subjective and may need revising. (new KSP version, what sort of tank it really represents has never been firmly established IMO, etc)
  8. Starwaster
    The way he's currently got it set up is about the only other way to make them work properly when mirrored. If you place them in the right location then you can make them orient correctly with two rotations. (I think.... it's actually been awhile since I used them) Seems like node snapping should work but I don't think it interacts with mirrored placement properly. One of these days I was planning to experiment with that and if I could get it working I was going to suggest it to KYeon
  9. Starwaster
    @westamastaflash Updated code base. Made necessary changes for KSP compatibility and fixed heat transfer display. Holding off on class name change until I hear back from RoverDude. Asked him to change his heat pump class name.
  10. Starwaster
    Oh crap I forgot that it used to rely on internal flux... I'll just have to cache the current transfer rate and use that
  11. Starwaster
    Just a suggestion... ignore it or implement it as you will. But instead of those joints, how about flexible / inflatable tubes encased in a folding framework (kind of like the folding framework that connected Skylab and the Apollo telescope mount)
  12. Starwaster
    As it says on the front page, a separate set of engine configs is necessary. You cannot use RF without engine configs. Spoolup is something that has to be configured. Engines are instant on by default.
  13. Starwaster
    Heat Transfer is the amount of heat the heat pumps are pulling out of the part being cooled. If it says 0 then either it's a rounding issue or the part's internal temp isn't hot enough to trigger the pumps. (a temp of 19.9k is cold enough to prevent hydrogen boiloff)
  14. Starwaster
    Sigh. Thanks RoverDude.
  15. Starwaster
    KSP thermal models are abstracted when it comes to conduction and is scaled up. RF boiloff code uses real world thermal modeling by computing the amount of heat incoming based on tank thickness (assuming typical tank thickness which IRL can vary; I averaged it out) and insulation thickness and using real world conductivity values. (assuming aluminum alloy for hydrogen and stainless steel for LOX + polyurethane insulation for conductivity values) for more information on the formula used by RF boiloff code: http://hyperphysics.phy-astr.gsu.edu/hbase/thermo/heatcond.html
  16. Starwaster
    2500 is too much and just means that there's some parts that have been overlooked in balancing and need to either have their max temps adjusted downwards or their masses adjusted upwards commensurate with a material that would justify having such a high heat tolerance.
  17. Starwaster
    If that's your ONLY problem and there's not another issue you haven't reported, then ... that isn't really a problem. Just ignore the warning message. If you WANT a recompiled PP plugin, see below, but, fair warning: I didn't even bother changing the checker version targets so it still reports an incompatibility. Again, ignore it. https://www.dropbox.com/s/8385vooo95i6c5m/ProceduralParts.dll?dl=1
  18. Starwaster
    Technically it's not 'KSP' that's responsible for that error. The mod itself uses a version checker which is widely used by a variety of mods and it only compares KSP (and optionally, Unity) versions to the version it has been configured as being compatible with. Some mods just check major and minor version changes. Others (like PP) include revision as well. Updates that involve revision only are usually safe but YMMV depending both on what specifically was in the update and how heavily the mod depends on KSP classes and functions. I've looked over the code a bit troubleshooting a DRE compatibility issue and it seems safe to use as is though for safety's sake it should at least have a recompile against the current KSP binaries. (that was just a cursory inspection so if I'm wrong, please don't shoot me!)
  19. Starwaster
    Shield those struts with a heat shield or put the the craft in a cargo bay. They're not meant to survive atmospheric reentry. Keep in mind that they are going to be made primarily of aluminum which has a melting point of 663 C. And that's just it's melting point. The point at which it fails as a structural component is going to be considerably lower. That's IRL. In the game, there's no concept of structural failure with heating. The part either survives or it explodes. In the past, DRE has tried to simulate structural failure by reducing the force required for structural failure (breakingTorque and breakingForce) but it never really worked well because the part tended to explode from overheating long before it 'failed'. In general, DRE is actually lenient with its temperature failing points. As an IRL example, the space shuttle's aluminum structure could not go above 175 C. That's 448 Kelvin, which is the unit used by KSP internally. That's considerably lower than the 1073 max temp of those struts and lower even than the 85% threshold where we start damaging those parts. As for the other landing gears with skin max temp of 2706, those are retractable gears with protection on the outside. There is a system in place that detects if they are opened and increases outer-inner thermal conduction to simulate the inrush of the reentry plasma. So, TL;DR, yes they are intended to not survive unshielded reentries, yes you can shield them, bits of metal aren't really heat resistant because they're structural bits that can't get very hot or Bad Things will happen and DRE is actually going pretty easy on you even if it looks like it's punishing you unfairly.
  20. Starwaster
    Still not really sure as the actual error was occurring in Squad's code when it walks over the part's module list when Procedural Parts was checking for the existence of certain modules. Since it only happened when DRE was installed I acted on a hunch that it might have to do with the fallback method that we use to add ModuleAeroReentry. A method which has been safe until now and that I would prefer to keep using because the alternative is to do it in a :FINAL call which I try to avoid doing. (:FINAL should not be used by modders; it's for players to make MM tweaks after all mod patches have been applied)
  21. Starwaster
    Thanks guys. Yeah it's a little rough right now. She'd had little crisises in the past where I thought we would lose her. So while I wasn't entirely surprised I had still thought she might pull out. @Sol Invictus for now leave them enabled. Most don't really conflict. Kerbal G limits only affects 'blackout' and works well with DRE. Part g limits is the only one with potential to conflict but so far my experience is that it is set too high by default to be an issue. Same with pressure limits really. I will be looking out for feedback on all of those however and at some point may introduce configs to tweak some of them as we do for temps
  22. Starwaster
    Pray that they soften us up with cudgels first...
  23. Starwaster
    *Goes into the repository to check the updated file* *Lots of throwing of breakable objects and swearing* Re-download and try again.
  24. Starwaster
    This was Ariel a few years ago
  25. Starwaster
    Hmmm still didn't tell me WHY it happened so I installed PP and was able to duplicate it... I have a vague idea of what's causing it but not why. I'll do another release sometime tonight. You can fix it before then by downloading this file: https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/DeadlyReentry.cfg Replace the one that is already in the DeadlyReentry folder. Can't bring myself to assemble a proper download package right now though. One of our cats, Ariel, just passed away a few minutes ago. She's been in poor health for a long time now but she's always managed to pull out of it, but not this time. We got her as a tiny little orphan kitten. She was found in the middle of the street eating road kill. In fact, we called her that as a nickname. At the time we had an older bottle fed kitten who I was trying to wean. (that's how tenacious she was. When he was still drinking out of a bottle in a house, she was living on the streets eating carrion to survive) Anyway, I'll try to assemble a proper download package later tonight.
×
×
  • Create New...