Jump to content

Starwaster

Members
  • Posts

    9,282
  • Joined

  • Last visited

Everything posted by Starwaster

  1. Sigh. BEHOLD. Note the image below. See how there's narrow corridor? Imagine your capsule is flying along that corridor. See one side of the corridor (higher) where it says 'overshoot boundary'? That's shallow! You're not getting enough braking. (drag too low) and depending on circumstance will fly back out of the atmosphere and either off into deep space (if orbit is actually hyperbolic) or have to make another reentry pass. Or, worse case scenario? You burn up because you slowly baked to death in the upper atmosphere. See undershoot boundary? That's steep. You encounter greater drag forces a lot sooner. That can also result in burning up if the shield heats up faster than it can shed heat. That's one possibility but another likely scenario is that your Kerbals can suffer lethal G-forces. ('deceleration too high' as it says) Stock Kerbin is so forgiving that I'm not even sure there is a corridor you need to hit. (it's not a tangible thing in either case). With Deadly Reentry, from LKO or a Mun/Minmus return, your target periapsis is ~20-30 km. The higher you go towards 30, the tougher things are going to be. Above 30 and you're probably going to burn up your shield and not have anything left. The lower you make your periapsis, the more G-forces your Kerbals will suffer. (if you aim right for the ground like it says for 'deceleration too high' and they'll be crushed into a thin green and red paste. It won't be an open casket funeral) edit: 20km isn't 'engraved in stone btw, it's really about the angle you come in at. I'd say the corridor is 10-30 and 20 is right in the middle. But even that could be too shallow if you're returning from a very low altitude. So the point is you want to get to where the sir is thicker and you can get to serious braking.
  2. Oops sorry missed a few posts here: Yeah I think I know why that is. I'll take a look at it. @Benji Ok this is what I'm talking about when I say too shallow. That is WAY too shallow and dramatically increases your total heat loading. You're spending too much time in the upper atmosphere where you're experiencing significant heating and not enough braking. Make your periapsis 20km. That should serve you well in most circumstances over Kerbin. And probably Laythe too. (Eve you'll want higher because the dense atmosphere means earlier and greater braking forces)
  3. By design, the Mk1's integrated shield isn't intended to for anything except LKO. (that said, I've been able to survive a return from the Mun while testing this update and gave up trying to ensure failure... so it is possible, just really hard. And I'm happy with it that way) (And yes, @MAV3RICK, @NathanKell is correct, it's not on CKAN because it's currently in pre-release status. In fact, I'm not happy with fire damage; it happens too fast and needs some reworking. I think once that's done I can take it out of pre-release)
  4. Wow, the very first instruction says 'do not install Layered Animators with KSP 1.0.5. No qualifying statements to go with it, just don't do it. The BB Code is because of forum migration. Here it is properly reformatted. Anyone who has been using LayeredAnimators to fix the centrifuge rotation+inflation issue will need to do the following when updating to KSP 1.0.5 Do NOT install Layered Animators with KSP 1.0.5. (if it is installed, uninstall it) Create a file named CentrifugeFix.cfg anywhere in your GameData folder. (requires ModuleManager) Edit CentrifugeFix.cfg and paste the following into it: If Layered Animators is already installed and you're using KSP 1.0.5, delete it from your KSP 1.0.5 installation. It is no longer necessary // This gets pasted into centrifuge1.cfg @PART[centrifuge1] { @MODULE[ModuleAnimateGeneric],0 { %layer = 0 } @MODULE[ModuleAnimateGeneric],1 { %layer = 1 } }
  5. It's a pressurized gas. If you have a 1000 liter tank and it says it has 10000 liters of Nitrogen in it (or it would be at standard pressure/temperature), then the nitrogen has been compressed to 1/10th its normal volume.
  6. There's a lot of people a lot more knowledgeable on the subject who don't agree and there's a lot of published data on the subject that says it is possible. Bottom line is that peak heating will result temperatures of 400-500C which is within the limits of the materials being studied.
  7. I think you need to talk to the CKAN people. Chris doesn't manage RC's CKAN entry at all, someone else did that.
  8. btw folks, the point of doing this as a prerelease is to test things. Certain things might need rebalancing. A rule of thumb that I've used for skinMaxTemp is that skinMaxTemp / 0.85 = <assumed material melting point> (not flammability since I'm assuming that there won't be much if any flammable material on the outside of anything meant for hypersonic operation, be it planes or reentry vehicles, so in spite of it being 'fire damage' it's probably really melting) Reentry I'm not TOO concerned about. Shields survive just fine, including deployables I've tested. Ballutes work. (see front page for the ballute link). Planes work just fine as long as you keep their reentry shallow and 30-40 degree pitch up. So that leaves ascent. If things routinely catch fire during ascent then I need to know what it was, how fast you were going, altitude and if possible convection / radiation fluxes and skin temperature. Try to rule out user error on your own; if you think maybe you were going too fast then you probably were
  9. Is this a save game from an older version of KSP? If so, try creating a new game and check to see if the error still occurs. (could be related to issues others have posted with parts whose INTERNALs have changed... )
  10. New update for Deadly Reentry. This is 7.3.0 Release Candidate 1 https://github.com/Starwaster/DeadlyReentry/releases/tag/v7.3.0-rc1 7.3.0 RC1 Changelog KSP 1.0.5 compatibility update Code cleanup of extraneous DRE 7.1.0 skin remnants. Fire damage reinstated Repairing of damage now requires an engineer on EVA - the more badly damaged the part, the greater the skill required. Damaged parts have lowered tolerance to further overheating and may break loose easier. (skinMaxTemp, breakingForce and breakingTorque are all reduced) Part configuration patches tweaked. It's still the Melificent Edition. Almost reinstated DRE specific menu options.
  11. @Gaarst my bad I missed where you said you were using 1.0.4 Those control the rate at which heat leaks into the tank. Thickness is in meters. Conduction is in SI units: W/(m·K) (watts per square meter of tank per degree Kelvin) 1 meter thick walls is grotesquely overkill - Where do you see that because no tank thickness in RF are that thick.
  12. Consult the Readme_RF.txt file. Look at the changelog for 10.7.2 You're behind by several updates. https://github.com/NathanKell/ModularFuelSystem/releases/latest Edit: In fact. Holy crap. You're lucky you're not locking up on startup or something. Go update! https://github.com/NathanKell/ModularFuelSystem/releases/latest
  13. At least it didn't go all over the keyboard. Errr it didn't go in the keyboard, right...? (I remember enjoying an excellent morning of SFC 3 on a certain day off that was suddenly cut short by a cup of hot java in the keyboard... had to run down to Best Buy for a replacement real quick)
  14. Sent in a PR for the Mach issues. That'll allow for ballutes or Duna deployments. And very high altitude Kerbin deployments which will still burn up normal chutes if you're going too fast. (or shred them if you're going too fast too low)
  15. That's a Real Fuels message and it's my fault. It'll be fixed the next time an RF update is released :/
  16. Is there any extensibility here? Can we get support back for codes like the quotation and quote codes so that old posts don't look so wretched? One thing we take people to task for around here is not searching the threads for answers to questions that have been asked 69,105 times already. Now there's one more reason why not to search. @kiwi1960 In addition to not 'taking it out on anyone' you especially shouldn't accuse them of being childish in a post sounds.... well you get it.
  17. I do have an update I can send in as a PR that scales just the mach component by (dynamic) pressure in atmospheres. So nothing fancy, just a modification to the current system and so far I think works well for upper/thin atmospheres. I want to test it a bit more first and make sure it's still sufficiently punishing at lower atmospheres.
  18. [quote name='evileye.x']Does not help for me. However what I found - if I turn plate 180, I can easily attach it. Then I can attach something (i.e. engine) to engine node. And after that I can un - attach plate, turn it back 180 and attach it in the right way - already with engine. Awkward, but it works.[/QUOTE] The plate is attachable without such shenanigans. It can be a bit twitchy but it's totally doable. If it snaps but is red then slowly sloooowly drag the mouse pointer back downwards until the plate is green, without actually unsnapping it. Depending on your viewing angle and how far out you are, that may not happen until the part is just about to un-snap. If it un-snaps and didn't turn green or stay green long enough, then you moved the mouse too far off.
  19. [quote name='NathanKell']Yep, gonna be fixed for next KSP, but RC can fix it sooner (woo!). The mach multiplier should fade out with Q, yeah.[/QUOTE] I've been thinking that given the already magnitude of the mach multiplier, wouldn't it be better limit it by static pressure? Unless you're thinking to lerp it and clamp it. Even better though would be to handle chute stress separately as discussed in: [URL="https://solarsystem.nasa.gov/docs/06%20Parachute%20Inflation%20Wolf.pdf"]https://solarsystem.nasa.gov/docs/Parachute Inflation Wolf.pdf[/URL] and [URL="https://solarsystem.nasa.gov/docs/14%20Parachute%20Materials%20and%20Stress%20Analysis%20Wolf.pdf"]https://solarsystem.nasa.gov/docs/Parachute Materials and Stress Analysis Wolf.pdf[/URL] The basic formula is fairly simple: Fmax = Ck*Cd*A*Q Where each chute would be given an FMax rating which if exceeded, the chute fails. (Ck is shock opening factor and ranges from 1-2 depending on mass ratio between atmosphere and chute. The other value's definitions should be obvious) Although it talks about chute opening, the formula is suitable for all other phases of the descent after inflation.
  20. [quote name='hapaxLegomina']The complicated but smart thing to do is edit the .cfg file. Look for the node_stack_ attributes. The first three numbers are the X, Y and Z positions of that node. The fourth, fifth and sixth are orientation. I think at some point during KSP development, they flipped the orientation signs. Orientation didn't change. The problem is that a lot of nodes have always been facing the wrong way. They were always meant to face in the direction that they are snapped from. However, until KSP 1.0 that was not being properly enforced in code due to a bug. When the bug was fixed, it broke a lot of mods that had been doing things the wrong way.
  21. [quote name='stupid_chris']The whole heating code *is* NathanKell's.[/QUOTE] Yeah, I spoke to him and it's a bug that it doesn't take into account low dynamic pressure. It's in stock too.
  22. Wrote up some quick debugging code and stuck your formula in compared to the convective heating a part gets and there's.... a LOT of heat. Note that this is per m² and for RC flux is also before temperature delta, so it's actually a lot higher for RC than this image indicates. Over a gigawatt of heat for that same altitude and reentry profile. Peak was on the order of a [I]terawatt[/I]. [URL="http://[img]http://i.imgur.com/pjIThPE.png[/img]"][IMG]http://i.imgur.com/pjIThPEh.png[/IMG][/URL]
  23. [quote name='stupid_chris']Sorry, the heating is pulled out of actual real life values. Can't help you turn that down.[/QUOTE] I think you should re-examine it. You're using Mach^3 to find heat flux but then you're also throwing in vessel.convectiveCoefficient which also (*I think; obviously take this with a grain of NathanKell) incorporates mach heating. It seems like over kill to do both.
  24. [quote name='Stone Blue']^^ Actually, its a change that was made in KSP (for 1.0, IIRC)...For some reason ALL the nodes were flipped around backwards.... So, probably for any pre-1.0 mod that hasnt had an update since then, more than likely you'll have to do this for every part... :( Or, maybe an MM patch could be made?[/QUOTE] I'll get an official (overdue) update out for them And it's not that all the nodes were flipped backwards. Nodes have vectors associated with them and are supposed to face in the direction that the node can be attached from. A node has never been meant to be attached to from behind. However, that wasn't actually being enforced in the code. Technically, that was a bug and with KSP 1.0 the bug was fixed. However, many modded parts had nodes facing the wrong way. It was especially common for the bottom node of a part to be facing upwards instead of downwards.
×
×
  • Create New...