Jump to content

Starwaster

Members
 View Profile  See their activity

  • Posts

    9,282

  • Joined

  • Last visited

 Content Type 

Everything posted by Starwaster

  1. Starwaster
    What we had before (have had for awhile) was fairings that automagically get auto-strutted to their base. And... I think each other? maybe? So you could have fairings that would be stock still and then have the payload come peeking out the side. Unless you strutted the payload to the fairing manually....
  2. Starwaster
    Yeah I don't think fuel lines make joints. I'll stick this in and try it out.
  3. Starwaster
    Eh, no biggy. I can whip up something quick... and your mention of modifying values gives me an idea for some quick hackeriness to make my testing easier. I'll just give the struts a maxTemp of oh maybe 100... 50? yeah 50. This should do it:
  4. Starwaster
    Do you have any mostly stock craft handy for me to test with? I got side tracked with trying to blow up my VAB. errr what? Oh hell... Edit: Ok Date fixed
  5. Starwaster
    Unfortunately, (aside from g force destruction) DRE doesn't destroy anything. We just keep feeding heat into it until KSP says 'enough!' and blows the parts up. I'll run some tests on it but I strongly suspect this is something that needs fixing on Squad's side, just like all the other issues with decoupling strutted parts. (i.e., nullifying decoupler forces or causing parts to swing inward if you strutted them to something other than the part the decoupler was connected to. If you haven't experienced that last one, it's a real riot. SRBs suddenly swinging inwards and smashing your fuel tanks even though you put the strongest KWR SRB separators on them)
  6. Starwaster
    You'll have to add it to the config file yourself for now. Later on it'll go in the settings menu (don't have one YET) and/or debug menu. Though you should at least give the new system a try No, that doesn't work the way you're thinking it does. Yes crewGMin of 31 would stop g force damage from kicking in until 31 g but then you would be assessed 30 g worth of damage. Behold this piece of code! [I]// Behold!!! [/I] if (Math.Max(displayGForce, geeForce) >= crewGMin) // This says if we're getting Gs more than crewGMin then (see below) { gExperienced += Math.Pow(Math.Min(Math.Abs(Math.Max(displayGForce, geeForce)), crewGClamp), crewGPower) * deltaTime; // Take some g force damage no higher than crewGClamp So, if you really just want to kill it outright, you'd do two things. Set crewGKillChance to 0.0 (so crew just can't be killed from g damage) and then if you don't want to see the g force warnings, set crewGMin to something insanely high like 69105
  7. Starwaster
    Payload autostruts sounds like it just might be the end of wobbly payloads. Or at least a reduction of them.
  8. Starwaster
    There is no explicit disable setting for g force damage so what did you change to try to disable it? Sounds like you need a new standard for lifting rockets. Your current standard can't be considered man-rated. (or Kerbal rated) crewGWarn and crewGLimit refer to cumulative G forces. It's like G force damage hit points. If you've been experiencing more than crewGMin then you start accumulating G force 'damage'. Taken from the values below, every frame that your g forces are over 5 you will take cumulative gforce 'damage'. When that accumulated damage (or running total of damage if you prefer) reaches 450,000 then DRE will start displaying a warning for as long as your g force level is over crewGMin. When the accumulated total exceeds 900,000 it starts rolling virtual dice to 'kill' Kerbals. That means it will not add more than 30 at a time. So if the update function runs and your crew actually took 60 worth of damage then it only applies 30 of it. (it's not literally 30g either, the amount of g damage is taken from a formula that uses crewGMin and crewGPower and crewGClamp per update and scaled by delta time so that excessively fast or slow computers don't scale the damage up or down) So, bottom line is your rocket is just too powerful and you need to scale your rocket's thrust back using thrust limits or you need to throttle back when you get warnings about g force damage. (if you use any mods to measure thrust to weight then your rocket should have a TWR of about 1.25 at sea level. There's always been a problem with detecting certain fairings. I believe it to be a problem with their colliders at the forward end. It's always been problematic and if the part lacks colliders in that area then there's nothing DRE can do to detect that part of the fairing. If you have FAR / NEAR installed then DRE will try to use their fairing detection code which is a bit more aggressive in looking for fairings
  9. Starwaster
    @PART[HERP_Pod]:FINAL { !RESOURCE[FOOD]{} !RESOURCE[WATER]{} } It's a reference to the 64bit Windows version of KSP 0.25 which was found during testing to be more unstable than it was for KSP 0.24.x and a group of modders (who are also on the experimentals testing group) feel it shouldn't have been released and some of them disable their mods if it is detected.
  10. Starwaster
    Version 6.2 update. This takes it back to the previous method of calculating densities except that atmospheric density is different from planet to planet. The differences are subtle, you will notice reentry heating rates are different. Probably the most prominent would be Jool. Aerobraking you'll probably find to be a little easier, but you're still coming in at 2-3 times faster than Kerbin reentries so unshielded parts will go up like popcorn. Parachute failures are now logged in the Flight Logger. This is probably the last update for awhile until an expected pull request from Nathan with FAR atmospheric density integration or bug fixes or until I'm ready to finalize toolbar support. v6.2 *Fixed issue with Jool NaN temperature. (capped low end of getExternalTemperature() to -160) *Capped low end of ambientTemperature to absolute zero. *NaN protection for part.temperature *Added density field to debug GUI *Replaced hard coded gas constant with per-planet specificGasConstant. (to-do: move that data to config files) *ReentryPhysics still uses hard coded 287.058 value *Added flight event logging for parachute failures. *Added legacyAero config file option. If present and true then density retrieved from vessel.atmDensity
  11. Starwaster
    It works fine in the latest dev versions of MechJeb 2. (yes, MJ now has porkchop plotting to maneuver nodes)
  12. Starwaster
    With that in mind, I'm not familiar with any changes that BTSM might or might not be affected by. I trust that you'll let me know if something breaks but is there anything about it vis a vis DREC that I should know about?
  13. Starwaster
    Parachutes: What is your speed when deploying? Eve: I've sent quite a few probes to Eve with DRE installed. Both stock Eve and RSS Eve (Venus). I'll send one right now to see how it does. Icons: Well I know tga works. I use that myself. Especially when importing from Unity because it can compress them down fairly well.
  14. Starwaster
    If it weren't noticeable I probably wouldn't have bothered. It affects how fast you pick up heat. And while it's true that this primarily is aimed at stock, it also affects the Stock Drag Fix mod (the third drag mod which is still stock aero, just without the extra drag from resources). So this is of definite value to SDF users, especially if they also play Real Solar System. And given that I created and administer SDF, I definitely don't want it left out in the cold. I don't know if you play Real Solar System at all, but to give a more concrete example, I once tried to duplicate Galileo's atmospheric probe mission. And I quickly found it impossible because a mission to Jool in RSS is like a mission to Jupiter IRL. In stock KSP you're probably only looking at velocities in the upper atmosphere of about 7km/s. Even with the weaker heat shields that 'stock' DRE has, that's still survivable. In RSS you're hitting the atmosphere at about 40 km/s. I wasn't able to pull that off with three stacked heat shields. The reason is that no matter what we did to the atmosphere in RSS, every planet still had the same basic properties as Kerbin. A mission like that is possible if the atmosphere mostly has the density of hydrogen, but not so much if it's like Earth only bigger. The FAR changes coming will benefit users of FAR and NEAR, which not everyone uses. (some people who play RSS may find that notion strange but it is true) So it's realism for the sake of realism. It's realism for the sake of making the difficulty realistic instead of unrealistically difficult. And so that not every planet feels the same going in. So... config setting to override? Maybe... we'll see. I just got this sucker working.
  15. Starwaster
    If you're having to wait that long then you missed an update. That said however, deploying into the plasma outside the ship will burn them no matter if the chute part is shielded or not. The canopy is too far back to be protected. If your naked canopy is flapping in a fiery breeze then it will not be happy. Either you missed an update or you deployed the chutes into the fiery plasma outside the ship. Update to 6.1. (6.2 will have flight event logs telling you that your chutes failed, if they failed) Remember, Apollo didn't deploy drogues until ~7km and mains at... ~3km? ~ish? Also, re: the icons, they're not displaying properly in the game. Do they have actual alpha channels or just png transparency? They need alpha channels. (there is an issue with png and alpha in certain graphics packages. Photoshop for instance needs SuperPNG plugin to properly deal with png alpha) This. Also, hope to put 6.2 out tonight. It will reintroduce the realistic densities that 6.0 had only different planets will have different densities, even without FAR. (Nathan, I'll be pushing the current code for that to Github soon so we can plan around that)
  16. Starwaster
    Moops good point. Edit: Why the hell does Siri think that 'moops' is a word??? DYAC.
  17. Starwaster
    Crap, I didn't push the code changes to GitHub. My bad. Basically I did this: density = (float)FlightGlobals.ActiveVessel.atmDensity; So heating is currently working the way it was previously. and this if (part.temperature < -CTOK || float.IsNaN (part.temperature)) // clamp to Absolute Zero part.temperature = -CTOK; So if anything else EVER writes NaN to .temperature, it'll keep it from being corrupted (because at that point you're reloading that ship. Temperature is broken until you do). If the problem resolves itself then the ship will start experiencing heating again. I'm currently trying to figure why v6.0's density code is messed up. By my reckoning, that code should only cause NaN if temperature were -273.15 (which would result in divide by zero) or if temp were lower than that, causing density to be negative, which to my understanding would also cause Math.Pow to throw NaN... Previously I'd tried this, and unless staticPressure is also doing something screwy in stock, it should have worked. density = (float)((part.vessel.staticPressure * 101325.0) / (287.058 * (Math.Max(-160.0, (double)(part.vessel.flightIntegrator.getExternalTemperature() + CTOK))))); -160 is a bit arbitrary and was chosen on the grounds that it was the lowest temperature that could reasonably be expected in any of the stock planets with atmospheres. (IRL, Titan and I think Mars might go lower but I thought this would do for now)
  18. Starwaster
    Maybe. It's just a short term fix for Flowerchild's bug. I'll probably do another tonight that does update the version # like I said above I didn't update the version but if you redownload, it's temporarily fixed and that's what it does. Just uses vessel.atmDensity
  19. Starwaster
    Wow so that was your christmas present to us all; nightmares to guarantee none of us ever sleep ever AGAIN. Whutta guy! BTW, updated version. No new version, just updated the download file for 6.1. That prevents stuff like the Jool NaN bug. It safeguards the part temperature field so that it can NEVER be set to NaN. Unfortunately that only prevents it from being corrupted, it also stops the part from gaining temperature in that situation instead of correctly calculating the temperature. I just don't get what's happening though. It has to be the density/temperature issue like we were talking about before but I put in so many checks and it still happens. So, back to debugging.
  20. Starwaster
    Status update on the Jool issue. Uhm the problem doesn't seem to be where Nathan and I were thinking it was, at least I don't see how it could be after I put as many sanity checks on it as I have and still get that error. So I'm still rooting around. I'm 90% probably going to push a quick and dirty hack without changing the version name shortly. EDIT: And, holy CRAP Athlonic, if I haven't asked you before, what the HELL is that in your avatar? Is there a full sized version somewhere? Wait have I asked you this before? Oh and thanks for the simulated in-game icon appearance
  21. Starwaster
    I'll probably have to do a of quick fixes until I can take the time to sit down and do it properly and until FAR is actually exposing density. (did I read your second post right; it's not right now?) Until then, I think what I'm going to do is cap it, and quite a bit above absolute zero or it'll really screw over non-FAR and non-RSS users. (you realize this wouldn't be a problem if Flower Child had been over RSS Jool right? Hurray for temperature curves!) You might also have done it if you opened up the DREC debug menu (alt+D) In fact I've got in the habit of always pressing alt+X every time I open that menu up just in case I turned on trim. Eventually the debug menu will also be accessible through the toolbar too. Those are looking good, I still have to get it into the game to see how it actually looks on the toolbar but that code was temporarily disabled for the 6.1 release and I've been too busy looking into the weird issue with extreme negative temperatures.
  22. Starwaster
    It goes below -450C. So it's just a question of whether it's getting to negative density before it hits a divide by zero error. Either one will produce a NaN in a double :/ Probably just grab the density from FlightIntegrator like you said. Or I might just cap the temp It's probably the negative density as above. Nathan had it calculating density using real life formulae that on hindsight depend on temperature NOT dropping below absolute zero. You can thank Squad for throwing a monkey wrench into THAT idea Well only the first 40 lines or so. But whatever, as you surmised I can do without it. (in fact, my own log didn't reveal anything because NaN is not technically an error, so you can't even really trap it) 6.1 won't function in a 64bit KSP environment even if you could get it to work with 24.2 What issue are your referring to??? Only actual heat shields HAVE ablative shielding. Non-heat shields lack it at all and space plane parts have increased heat reflection to compensate for the lack of ablative. Not having ablative in a non-heat shield is a non issue. Press Alt+X. You accidentally turned on trim control which is why your pod is rotating. (DREC itself imparts no force at all to anything)
  23. Starwaster
    i5-4440 3.10 GHz (quad core) 1-2 seconds? I didn't try the limited time one yet. Not sure what that one does. Porkchop is fast though. Oh, and OH my god... the trajectory it let me do... a solar flyby to Jool. I'm having a waking techno wet dream here
  24. Starwaster
    No, the visual effects are all down to density and velocity. The 70km probably is just coincidental..... Let me get a full log from you. output_log.txt (or player.log if you're on a mac/linux)
  25. Starwaster
    I've used png previously for this but I have no image editing capabilities at all right now. I'll probably download the Gimp later but re-learning how to do things is time I don't get to spend coding. Edit: on1 and on2 look good. Have to try them each individually and see how they look. I'm thinking they might look good canted... maybe 45 degrees or so? Maybe less?
×
×
  • Create New...