Starwaster
-
Posts
9,282 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Starwaster
-
There are three means by which heat is transferred. Convection - this is reentry heat. Caused by passage through a fluid or the air. Radiation: hot things radiate into space. Conduction: this is what killed your fuel tank probably. Unless it was exposed to convection heat. Basically all that heat the shield soaked has to go somewhere and eventually it spreads to adjacent parts. - - - Updated - - - There are three means by which heat is transferred. Convection - this is reentry heat. Caused by passage through a fluid or the air. Radiation: hot things radiate into space. Conduction: this is what killed your fuel tank probably. Unless it was exposed to convection heat. Basically all that heat the shield soaked has to go somewhere and eventually it spreads to adjacent parts. -
could be stored heat leaking through. Maybe jettison the shield since at 300m/s you don't need it now.
-
Thanks. I've a pretty good idea what's going on here already btw, and basically there are some bad combinations of settings that trigger a bug. Basically there needs to be some sanity checking on temperature gain because it's possible with sufficiently low thermal mass to pick up so much energy that a part radiates more energy away than it had. I'm sure you can appreciate the logical impossibility at work. It's a tricky situation because we have to give a part the opportunity to radiate heat before testing it for destruction, even if it absorbed enough to destroy it outright. The answer is probably that I need to cap heat gain to the lowest of either maxTemp or thermal equilibrium. (temperature can NEVER reach higher than one of those two and if thermal equilibrium temperature is higher than maxTemp then it would be destroyed before reaching equilibrium) Edit: Yeah, here's the problem: mass = 0.7 thermalMassModifier = 0.001 Even if I fix the bug, those are bad numbers I have to mull this over
-
Let me see your current ModuleManager cache.
-
Looks like all the symptoms of excessively low thermal mass and possibly emissiveConstant too high.
-
Go shallower. No steeper than 50. I like to go 40
-
My FPS also dropped by 10 frames due to this (I think). Log file: https://drive.google.com/file/d/0B-Ygs3rUb405UzVuZHVESlFlQlk/view?usp=sharing Does it consistently do that? Even if you restart the game? Is the craft all stock or if not can you still reproduce it with an all stock craft and then send me the craft file please?
-
Here's the full log: https://drive.google.com/file/d/0B-Ygs3rUb405WHozZGRkc0NTYTg/view?usp=sharing CKAN is pulling down an outdated file. Replace ModularFlightIntegrator with this https://ksp.sarbian.com/jenkins/job/ModularFlightIntegrator/ I spoke with Sarbian and he's done CKAN pull request to fix the problem
-
Unlikely that your PC isn't powerful enough. The calculations it does are pretty much the same as what stock KSP does, and those don't even run while DRE is installed. (basically it overrides them) Run the game with DRE installed, and do things that makes your FPS tank. Then quit the game and find your output_log.txt file. If you're not sure where, see next line: These are text files that the game spits out for debugging purposes as it runs; if something broke horribly in-game, there will be something in here about it. You should upload the entire log as a file (i.e. not to pastebin); you can use dropbox or an equivalent host to upload the file. Make sure the entire file gets uploaded; you may have to zip it first, as logs can be very long. Here is where you can find the log: Windows: KSP_win\KSP_Data\output_log.txt (32bit) or KSP_win64\KSP_x64_Data\output_log.txt (64bit) Mac OS X: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log ( Files>~/Library/Logs>Unity>Player.log ) Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log NOTE: These logs are not the same as KSP.log, which lacks valuable data. Do not upload KSP.log; do upload output_log.txt / Player.log Download this file: https://raw.githubusercontent.com/Starwaster/DeadlyReentry/master/DeadlyReentry/DeadlyReentry-KWRocketryFairings.cfg and replace the one in your DeadlyReentry folder.
-
Ok, update 7.0.3 is out https://github.com/Starwaster/DeadlyReentry/releases The main change is that ships won't spontaneously explode on the launch pad. Note that you will still see reentry effects for a brief moment but I'm at a loss at to what I can do about that. Bottom line is that for a single frame when a ship loads in, KrakensBane is using the last frame of data available, which if it happened to be from a ship that was in flight or in orbit, then you could see reentry FX or mach FX. It's a stock problem and the best I can do is to not let it blow up our ships. The other big change is that even less of thermal mass is used for heating. And this part is dynamic, and it's based on the exposed area compared to total area. One interesting effect of this is that flying head on you will notice less incoming flux but your temperature is higher because even though the flux is less, there's also less surface area to take the heat. Fly a lifting reentry and you'll see more incoming flux but also more surface area to take it. Your temperature may go down as a result. Changelog Calculate what pecentage of skin is actually facing the shockwave and use only that percent for thermalMass Add OnDestroy() and null the FlightIntegrator cache Added additional check for part.ShieldedFromAistream Buffed fuel tank maxTemp Fixed typo in DRE heat shields Fixed the Deadly Launch bug (for real this time. NO SERIOUSLY!) Added depletedMaxTemp to heat shields. (if their resource is depleted, their maxTemp changes to this value. Default 1300) skinHeatConductivity works properly now.
-
The DRE shields generally have more resource in them. Consumption isn't linear though so they won't last as long against stock shields as you might think from comparing the numbers. Consumption is something like shield.amount -= shield.amount * loss (where loss is a percentage of loss. So in otherwords it takes off a percentage of the existing shield amount rather than loss representing a flat rate) (that's probably a bad explanation but I'm keeping my explanation simple. The code governing loss is here) https://github.com/Starwaster/DeadlyReentry/blob/master/Source/DeadlyReentry.cs#L854-L871 The stock shields should be left as is as a fallback. You don't want craft with the stock shield parts to break if you remove the mod. If that happens with this mod and you don't happen to be flirting with the sun then I'll probably consider it a bug fix it.
-
Because DRE has always used that as its resource. No. I have no idea, you're in a better position to answer that than I or anyone else participating in this thread. You've had a few weeks now to play with the stock thermal system in place. Are you happy with it? If so then please stick with it. If you're not happy with it then you should try Deadly Reentry. But if you ask me a question like that I can only answer from the perspective of one Kevin Starwaster. And *I* needed Deadly Reentry installed because I was not happy with the stock system. Seriously I would have been thrilled if Squad had left me with one less mod to maintain but their system was lacking and didn't feel very dangerous to me. That doesn't mean they did a bad job of it per se; I happen to know who the code came from and 90% of it is pretty good but it needed a little something extra to let me inflict a huge amount of heat on a vessel without heating up the entire vessel, and that's the way the stock system is right now. It's either all or nothing. If you want to heat up one of a rocket's parts, the entire part is heated up through and through. And that's what Deadly Reentry version 7.0 brings to the table. The concept of a 'skin' or 'hull' (hull is the better term and I wish I'd thought of it a month ago). So part of the rocket can heat up to over 1500K and decide based on that temperature that the craft survived or did not survive. Without heating the whole part. That means a few things It's easier to heat up to lethal levels If it survived then the entire part didn't reach that temperature and that may matter to other mods such as Real Fuels where tank temperature matters because your cryogenic fuels could boil off Life Support mods could in the future make internal temperatures matter to Kerbal survival. But bottom line is this. YOU TELL ME. Do you need this mod or are you happy with the stock system?
-
Hah! Found the cause of the problem. In the very first frame, I'm checking to see if skinTemperature is initialized already. If not it grabs it from vessel.externalTemperature. Somewhere along the way it's grabbing the velocity from KrakensBane.GetFrameVelocity which is probably using data from the previous frame. So, problem will be fixed in update sometime tonight. @almagnus1, make sure you have the latest update. An earlier update had some obsolete engine heat production values
-
Ok, update time on the issue of parts exploding when loading in. This is very obviously not fixed yet in the last update but I am able to reproduce it on a regular basis. Loading a ship on the ground when the current vessel is in orbit reproduces pretty regularly. So if you're going to load in a vessel try to do it from the space center. It is not caused by cached Flight Integrators. (that was disappointing because there's a number of ways that could be fixed) It is not caused by cache PartThermalData objects (also disappointing) So I'm still looking into this. The explosion definitely happens in DRE code when it looks at skin temperature. Which doesn't check the cheat options for ignoring maxTemp. (next update will check that for sure to allow further workaround or troubleshooting)
-
Yes, that will affect Deadly Reentry. Remember that it's tied into the stock thermal system. It uses the same physics globals and those get scaled by difficulty.
-
I added code to try to eliminate that by uncaching the flight integrator when a part / PartModule is destroyed. If the problem is because of data being cached, that should take care of it. Unfortunately I can't know that for sure until enough eyes are on the problem and reporting if it happens again.
-
How do I hate Github. Let me count the ways... ok, take 2.... trying this again.... Edit: Ok, fixed. To be fair, the fault wasn't entirely with GitHub. I had attached the file and it was uploading but I was busy making sure everything was in the release notes that I wanted so I didn't notice GitHub complaining about the file. The solution? I renamed it .... to the EXACT same file name. Exactly the same. For some reason, adding things to zip files through Windows, something happens to them where Github has trouble telling what file it is. Since all I did was remove then add the .zip extension back... well whatever. Fixed now.
- 5,919 replies
-
- 1
-
-
- reentry
- omgitsonfire
- (and 1 more)
-
Update: 7.0.3 Release Candidate 1 (pre-release so it shouldn't show up on CKAN) So, the upshot of this is that things are going to buildup heat much faster so be careful what's pointing into the airstream. That first item right there is why this is marked Pre-Release. There's probably going to be consequences and I'm probably going to have to do an exemption for small parts. Calculate what pecentage of skin is actually facing the shockwave and use only that percent for thermalMass Add OnDestroy() and null the FlightIntegrator cache Added additional check for part.ShieldedFromAistream Buffed fuel tank maxTemp Fixed typo in DRE heat shields https://github.com/Starwaster/DeadlyReentry/releases/tag/v7.0.3.RC1
- 5,919 replies
-
- 1
-
-
- reentry
- omgitsonfire
- (and 1 more)
-
Nope, haven't noticed that. Either the information isn't valid for the build I'm using (which update you'll see soon) or there's something else happening in that situation and I can't comment on it because I don't have sufficient context. What you see might be normal or it might not. There are 3+1 heat models at work every frame and they have to work at a faster rate then real life because Kerbin is so ridiculously tiny. Fuel tanks are getting a +200 buff across the board. Maybe that will be enough to save your fuel tanks but I can't help feeling that maybe people who point six blow torches at their fuel tanks should expect a bad day. Have you tried NOT pointing six blowtorches at your fuel tank? (ok that was a little sarcastic, but remember Challenger... these things are dangerous and you should take care with them)
-
Physics.cfg values are overridden by DRE. Some of those values don't appear in the debugging menu. If you changed something in the file that is overridden then the changes had no real impact. Some relevant values may not be getting overridden and some that are don't appear in the debug menu. (such as densityExponent which is being used to force reentry heating to begin earlier and higher) Thanks, the missing = is obviously a typo. Corrected for the next update. The 1/10th factor is obsolete as of the most recent update. I'm keeping the default of 1000 or shields will deplete too fast and possibly not dissipate enough heat.
-
Re: ModularFlightIntegrator / FAR issues. This was my fault. DRE was being compiled against the ModularFlightIntegrator project files instead of the compiled dll that's distributed from Sarbian's site (this is what CKAN uses) and with FAR. AFAIK that shouldn't have caused issues but did. Next update will correct this. ( Stock KSP issue; nothing I can do about it but AFAIK, next KSP round of fixes will include the the temperature gauge so they should get this as well. KSP measures temperature in Kelvin so 300 K is ~80 F. Which is pretty damned hot especially at night, but you're on the equator so what can you expect. Re: fairings The fairing issue that I'm correcting only takes care of parts not being shielded against convection. Fairings don't actually 'radiate' heat to other object; no KSP parts do. Radiated heat just vanishes into the environment. Parts in the fairing will still pick up temperature increases through conduction, so the entire vehicle will eventually balance its heat out. This is mostly to cover parts cooking in fairings during flight because they were thought to be unshielded.d - - - Updated - - - Re: ModularFlightIntegrator / FAR issues. This was my fault. DRE was being compiled against the ModularFlightIntegrator project files instead of the compiled dll that's distributed from Sarbian's site (this is what CKAN uses) and with FAR. AFAIK that shouldn't have caused issues but did. Next update will correct this. ( Stock KSP issue; nothing I can do about it but AFAIK, next KSP round of fixes will include the the temperature gauge so they should get this as well. (I refer only to the glow persisting after removing the gauges, which is a bug. Parts glowing on the launchpad are because they are half or higher of their maxTemp. I'll do another pass over the temps and make sure everything is above 600 maxTemp which should stop the gauges) KSP measures temperature in Kelvin so 300 K is ~80 F. Which is pretty damned hot especially at night, but you're on the equator so what can you expect. Re: fairings The fairing issue that I'm correcting only takes care of parts not being shielded against convection. Fairings don't actually 'radiate' heat to other object; no KSP parts do. Radiated heat just vanishes into the environment. Parts in the fairing will still pick up temperature increases through conduction, so the entire vehicle will eventually balance its heat out. This is mostly to cover parts cooking in fairings during flight because they were thought to be unshielded.d
-
He's marking it the same way the stock game does so it's good.
-
Well FAR better be marking those parts as shielded in some way that I can see or Jeb better be applying for a volume discount
-
The skin conduction code is applying the skinHeatConductivity * part.heatConductivity which is a bad thing. It's fixed in the next update so that your configuration should work. (I need to do some testing of other parts of the update first because it's going to have a big increase on heating. I think I know what the problem is. I was under the assumption that convection occlusion was checking a part property that cargo bays and fairings set that indicates they are shielded. I'm not sure that's the case anymore so the next update will have an additional shielding check in my code that will prevent convection from occurring if they were marked as shielded. Distance will have an effect, sure. Any physics changes will as well.
-
I did, with default of 40 convection and my peak was 1300+ I didn't set it to 100. So I was very nearly getting at 40 what you got at 100. That's why I needed to see the MM cache file next, to see if anything was making your setup different from mine, and your experience different from mine. (I did learn something new from the experiment; even though 1300 wasn't enough to explicitly destroy the pod, it should have caught fire. The fire setting code failed) Re: Fairings. What kind of fairings? edog's procedurals or the stock ones?
