Jump to content

Starwaster

Members
  • Posts

    9,282
  • Joined

  • Last visited

Everything posted by Starwaster

  1. Logs are always created unless you somehow disabled them. Here is how to find your logs. http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29
  2. No it's not the cargo bay or anything near it that's responsible. And that's not what Nathan meant. He was replying to part of what I said which was about parts that are attached to each other transferring heat to each other. So his reply is basically saying that it only works if they are less than 4.5 meters apart. For example if you put the shortest fuel tank (FLT100) between the RAPIER and the FLT800, it would absorb more heat than the FLT800 does. But regardless of that, it does look like there's a problem in the DREC config file. (which I posted what it should really look like for the RAPIER. It's from the DeadlyReentry.cfg file) Here's the whole CFG file with RAPIER corrected. Drop this into your DeadlyReentry folder (GameData/DeadlyReentry.cfg) https://www.dropbox.com/s/gagmbk8luzsjj0m/DeadlyReentry.cfg?dl=0
  3. Hellz yeah blow up KSC!!! (uhm strictly in the name of science though...):blush::blush:
  4. Ok, taking a look at it now..... ...and... ...it does look kind of mangled. I'm afraid to ask, but who wrote it? It should be this: @PART[RAPIER] { @maxTemp = 1900 @MODULE[ModuleEnginesFX],0 { @heatProduction = 200 } @MODULE[ModuleEnginesFX],1 { @heatProduction = 325 } }
  5. Ah, sorry I thought it was from the attachment point. Guess it makes more sense they'd do it to the transform
  6. That's because you alt-tabbed away from KSP to go look at your log file while the game was running. That's normal behavior. Might not do it if you're running KSP in Windowed Mode instead of fullscreen. Maybe.
  7. I can't think of anything that would be affecting RAPIERs in particular. Reentry is going to be a little hotter on everything but your problem seems to be just with running them. Do you have anything else that affects them like Real Fuels? Have you tried running just stock + DRE to see how they behave? As a workaround, try putting a small fuel tank between the RAPIER and the long fuel tank. The way heat transference works in KSP, more heat is transferred to shorter parts than longer parts. (literally measured from the attachment node to the part's center)
  8. That's normal. The reason is density of the surrounding atmosphere. Even though the temperature is lower by the time you you hit the mid to lower atmosphere, the air is much denser which means it can transfer more heat. 28km seems to be where heating really starts to pick up because you still have a good amount of heat and more atmosphere to convect it into your ship.
  9. Hi funk! Two things If you link to a log, please use output_log.txt, not ksp.log. (ksp.log lacks important details that are present in output_log.txt) (Mac/Linux users want player.log; there is no output_log.txt for them ) Can you provide the save file where you're having this problem? I have an idea about the problem I want to investigate but need to be able to reproduce it reliably. (and it might let you get your Kerbals home)
  10. As far as other planets go, it's just got to be up to everyone properly plan for the planet they're trying to land on if it's not Kerbin. Kerbin's got to be the default.
  11. That's updated not to cause errors? There is none. It's not updated yet.
  12. You didn't say anything about altitude before, only that a chute couldn't withstand supersonic opening. Anyway, I don't know the precise altitude. The test started at 130,000 feet at which point a rocket was fired to propel the chute part to Mach 1.5. AFAIK it fired straight down. There was some tearing but it was caused by the case, not the shockwave. The canopy AFAIK was nylon, presumably one of the stronger ones. The lines were technora.
  13. Well, the conversations today have me wondering if it might not be a good idea to whip up a MM config file which changes the defaults for known parachute systems. 7km should be do-able too.... 3km is definitely safe as you've demonstrated.
  14. Wow TG626, that was an awesomely written bug report! Kudos! Unfortunately, it's nothing that Chris can do about in RealChute. Looks like a problem in the stock game. There should be some mechanism in place in stock KSP that cleans up contracts which are missing parts that the contract requires for completion. Either that system is not working or never existed in the first place. I shudder to think what would happen if a contract template or entire class went missing because a mod was uninstalled. I strongly suspect you could replicate this in stock if you were to accept a contract to test a stock part and then removed the part that the contract depended on. (as in actually removed it from Squad's Parts folder) Edit: To clarify this a bit, Chris did not code any contract functionality into the plugin. Instead he added a config file that adds RealChute and Wenkel Corporation as Agents. If any part has a manufacturer listed which has the same name as an Agent, then the stock contract system can generate contracts for that part. This is outside Chris's ability to do anything about other than to not add Agents to his mod. This is something that Squad needs to address in a future update or it seriously impedes a modder's ability to use the Contract System.
  15. Thanks Nathan for the correction on chute max temp! However, chutes have been tested at supersonic speeds IRL. Curiosity's chute was tested at Mach 1.5 before it was sent to Mars where it was deployed hypersonic. (And I'm thinking maybe parachute multiplier should be part of the difficulty settings....)
  16. Interesting, it's throwing errors trying to load config nodes from the Parachute class constructor. That's the most likely cause right there of parts of the rocket disappearing. Everything after chute load failure isn't initializing properly. Whether that's linked to the other quickload failure you experienced I don't know. I've seen that happen before but I don't attribute it to any mod in particular. When the game gets in that state it's best to restart it or it could cause other problems.
  17. 700 meters per second is ~700 degrees Kelvin. My guess is you were actually doing closer to 775 m/s. So outside your ship is a plasma shockwave of 775 K. That's like 502 Celsius. That's 25% of the max temp of the chute part. That's what that 0.25 means in the settings. Max temp of the part is 3100. 25% of that is 775 so chute failure occurs at 775. However density of the atmosphere is an issue. I've safely deployed a chute at very high altitudes (15-20km) but they fail when the air is dense enough to conduct a lot of heat. IRL nylon melts at 521 K. Approximately. Assume the chute is nylon and that's a generously high failure temperature.
  18. He wants your ouput_log.txt file if you are on a PC. player.log if Mac or Linux. The support threads elsewhere have detailed instructions on finding them. Those threads are stickied. I can't give you detailed instructions myself at this time as my access is limited to an iPhone. Just typing this is a hassle. edit: regarding Chris on break, anyone who can help you here wants the same thing he wants. Or they can't help. And you can post your logs using Dropbox to host them. That is the easiest solution I've seen both for the one posting the logs and the ones who have to retrieve and read the logs.
  19. He's asking for a window to pop up when you launch that lets you assign crew. Maybe with the crew slots starting unpopulated. I'm not clear on that part.
  20. Suborbital is irrelevant. What was your velocity during deployment? What version number are you using? (Latest version is not a number)
  21. They don't work yet. It was something I was testing and left in accidentally. I usually make a separate branch for testing but I didn't. The main way it will work is by applying presets of the settings you see when you press alt+d+r correct. FYI Apollo deployed drogues at 7km and mains at 2km
  22. If you still have a problem with chutes burning up, first make sure you're updated to latest version of 6.2.1. Chutes are working as intended. Open up the debug menu and edit the chute temp multiplier to suit. Large numbers are safer. Mean people might say large numbers are wimpier. Really mean people might tell you to accept current chute behavior and to suck it up! "Space is a tough place where wimps eat flaming plasma death!"
  23. And yet people STILL manage to screw things up on a regular basis, don't they. The ability for end users to screw up an 'incredibly simple' mod installation rather reminds me of this comic here:
×
×
  • Create New...