Jump to content

Starwaster

Members
 View Profile  See their activity

  • Posts

    9,282

  • Joined

  • Last visited

 Content Type 

Everything posted by Starwaster

  1. Starwaster
    Let me also get your ModuleManager.ConfigCache too please. Try doing that reentry with those parts again only make sure you have thermal debugging enabled. (alt-F12->Physics->Thermal) and right click the part that's exploding. It will show you where the heat is coming from. Convection should be 0 if you have a heat shield (or ANYTHING) between you and the shockwave.
  2. Starwaster
    The A10 has a maxTemp of 1000.... I'll see about bumping that up in the next version. About that bay, is US properly updated for KSP 1.0? It should be using ModuleCargoBay. Otherwise there's no guarantee that it will shield anything. Also, the stock heat gauge can't tell that your parts are overheating if it's the outer skin heating up. It's not DRE-aware. I'll look at the log file to see what errors you're getting. Make sure you're updated to DRE 7.0.2 which I posted last night. Are you sure you did a proper install of 7.0.2? Delete then reinstall? Pretty sure you should be exploding that pod with no shields. Did you post any logs earlier? If not, do so now. output_log.txt (player.log if Linux/Mac) Is it the same thing as what I posted though? Procedural Fairings? Did you try reverting to launch or saving then restoring?
  3. Starwaster
    That doesn't sound good. I'll look into it when I'm more fully awake. Thanks for letting me no.
  4. Starwaster
    Removed legacy engine configurations which were adding pre-KSP 1.0 levels of heat production. (FIRE BAD!) Fixed duplicate toolbar button issue Tweaked convection heating to start EARLIER. Tweaked stock shields to (more or less) their original ablation/pyrolysis levels. For your protection. Put in checks and guards against null ref errors in UpdateConvection() Known issue: You may get logged error spam on craft with procedural fairings, namely the base. If this happens just revert to launch, or quicksave then quickload
  5. Starwaster
    It's like this: If you have a pretty good TWR then you should start turning earlier. You can afford to and early turns are better because you start building up that horizontal movement early and only have to spend a few hundred DV to circularize instead of a few thousand. You start your turn high up if you just don't have the TWR to pull off an early turn. A starting TWR of 1.6 (ASL) is good. If possible I start my turns no later than 250m and most of my designs have the TWR to be doing 100m/s by then, or close to it.
  6. Starwaster
    That's essentially how it is ArcFurnace. I've been thinking that 10% is actually maybe too much but wonky things start happening if the thermalMass gets too low. Even wonkier things happen when the heat transfer rate or amount are increased too much. For instance, I've been trying for the past day to make the stock heat shields explode faster when they are depleted. A logical step there was to decrease the thermal mass, but when I did that their temperature pinned to 4k and their radiative energy skyrocketed. Turns out that their temperature went up so high (probably high enough to destroy them outright) but then radiative flux kicked in and because radiation is temperature^4 they dumped all of the heat they had picked up. So, it's actually better if the heat transfer rate isn't sped up too much (although it was unrealistic, a scaled down version of that is how space shuttle tiles worked. The tiles really can't hold very much heat at all, so when they reach thermal equilibrium they're dumping most of what they have in them so it never gets to conduct very much into the shuttle) Another thing is conduction. It's been claimed a few places on this forum that the low conduction factor of the stock heat shields is bad because they leak enough to the parts they're attached to. Well, that's true, but too much conduction and they don't get to build it up to the point where they should explode either so the heat shields are vexing me a bit right now.
  7. Starwaster
    ok do it again but this time revert to launch and see if that clears it up. Edit: I'm not seeing anything in that log to tell me why you're having trouble. Was that ksp.log? It seemed sparse. output_log.txt would be better, maybe there's something in that I can use but as is right now, I'm just not seeing where the problem is.
  8. Starwaster
    well just smack someone else over the head and take their rep
  9. Starwaster
    Ok, EVERYONE replace your DeadlyReentry.cfg file (in the DeadlyReentry folder) with this version. (naturally this will be in the next update but grab it now if you want to plane) https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/DeadlyReentry.cfg In fact just grab it now
  10. Starwaster
    Ok, there is an error that occurs when the vessel loads in. The error is in one of FAR's methods but I'm not pointing the finger at FAR... could be an issue with the ModularFlightIntegrator which we both use to override physics. I'll look into that some more. If heatproduction were changed, it would be because maxTemp was lowered. If that happens, heatproduction has to be lowered a proportional amount. So if it's 350 now and DRE did it, that means it was should have been higher before. Edit: Oh crap, ok I see it now....
  11. Starwaster
    Correct, that patch only targets RF, where engines were having their heat production reset to high levels after DRE had cut both max temp AND heat production. (ModuleEngineConfigs was doing that) Since RF is not currently out yet, nobody has it so that config isn't the source of the problem
  12. Starwaster
    Check your log, I'm guessing you have errors spamming the log. Also, I'm thinking there's an issue with Procedural Fairings. If you experienced the FPS drop on a ship that had those, either revert to launch, or quicksave then quickload and it should stop
  13. Starwaster
    The attach nodes (probably the ones the engines need to connect to rather than the engine's nodes) need to be reversed. if you want to try doing it yourself, edit the part that you're connecting to You'll see something like this: See the red numbers? It needs reversing node_stack_bottom = 0.0, -1.930788, 0.0, 0.0, 1.0, 0.0, 2 you want that to say node_stack_bottom = 0.0, -1.930788, 0.0, 0.0, -1.0, 0.0, 2 (it wont be exactly like that; I don't have the KSO installed. I grabbed that from the Mainsail)
  14. Starwaster
    Ah crap, that's right, it's supposed to be Deadly REENTRY, not Deadly LAUNCHES.... BTW, log files are better than pictures. And not that cheap watered down ksp.log; I want the nice output_log.txt or player.log
  15. Starwaster
    Ok, looks like Ioncross' EVA module is breaking the FlightIntegrator. (that's where the error spam is originating) Is that the only time it's acting up?
  16. Starwaster
    I suggested that but they don't even want to try that. (just a value of 1 would be sufficient)
  17. Starwaster
    You didn't close it with a pair of {} @PART [*]:HAS[@MODULE[ModuleGenericRadiator]]:FINAL { !MODULE[ModuleAeroReentry]{} } It's on you guys now to make sure that can still burn up
  18. Starwaster
    I don't know. It's stock behavior. There's a part.explosionPotential, maybe that controls size.
  19. Starwaster
    I'm also seeing the error Failed to call function OnVesselUnpack of class KzFairingBaseShielding Calling function OnVesselUnpack with no parameters but the function requires 1. I suspect also that it's interfering with some of Deadly Reentry's functionality as I get a null ref error trying to access the PartThermalData of anything that has KzFairingBaseShielding in it. (reverting to launch helps and I don't get errors with the part after that) I tried removing DRE and its dependencies to see if there was a conflict between the two mods but I still get that error. In fact I removed all plugin related mods but still got that error
  20. Starwaster
    Regarding Deadly Reentry: That's going to be problematic in the next update because the modules will be added programatically. If I'm understanding the problem correctly you're getting unwanted heat buildup? One suggestion would be to set skinHeatConductivity in the ModuleAeroReentry to 1 - that will allow an unimpeded flow to the surface. Another possibility is that we figure out some method of exemption. If the radiator has a module that's unique to it, I could use that to exempt it from having anything added to it by DRE
  21. Starwaster
    Use dropbox. If the file is more than a few MB then zip it up Anyone who has to edit their files does NOT have the most recent version of the mod. If they say they do have the most recent one and STILL cannot attach shields/decouplers then they do NOT have the latest version installed. Completely delete your existing installation and delete all older Deadly Reentry archives and then reinstall. I have just personally downloaded the latest version myself and gone through every file and just as I thought, all bottom nodes are fixed. I'm sorry, I must have missed it. If anyone wants to contribute to the mod, feel free to do a pull request and I'll take it under consideration. If you want to hack on the code and more than a bug fix then you should run your specific proposal by me first. (i.e. if it adds or makes changes to existing functionality) That's ominous, looks like I'll have to install nuFAR again because you should be experiencing something a little more perilous than what you're describing.
  22. Starwaster
    I can't see your pictures at all but you're saying you have to turn them upside down? Re-download the mod. Sounds like you don't have the latest version. I see those thermallink errors in pure stock. I don't think they're related to your issue. I need to see an entire log file, output_log.txt or player.log (if Mac or Linux)
  23. Starwaster
    If you have a mod that displays heatshield remaining, they should first be checking the heat shield module to see what it's been configured to use instead of hard coding it to only look for one. Same for KOS, reflect into the class and grab the ablativeResource value. It's a public readable field If you think these things are problems now, what happens if someone decides to make a custom heat shield resource? People need to code more flexibly to allow for those contingencies. insufficient information. Are you saying you're running a reentry with both shields attached? It should certainly be protected from convective heating. Did you install that set of configs that someone put out to fix stock reentry before DRE came out? Or any other mod that alters conductivity? If so, then heat could conduct into the Mk1 pod and the shield doesn't care where the heat came from. If you get it up hot enough it will ablate. Enable thermal debugging (Alt-F12->Physics->Thermal then enable Display Thermal Data in Action Menus) Then right click the Mk1 pod. Every positive flux value is heat coming in. Every negative value is heat going out. l Once you have established the source of the heat: The Mk1 pod is configured to deplete faster.
  24. Starwaster
    Best case scenario is that this is a solution looking for a problem Worst case scenario, is that it causes problems. Fair warning: I won't give support to anyone using this if it looks like the problem stemmed from this until they return to a supported configuration.
  25. Starwaster
    No surprise whatsoever. You had a higher than usual peak heating rate but it was short lived. Not enough time to burn anything. Physics are safe.
×
×
  • Create New...