draqsko

Members
  • Content Count

    61
  • Joined

  • Last visited

Community Reputation

38 Excellent

About draqsko

  • Rank
    Rocketry Enthusiast

Recent Profile Visitors

341 profile views
  1. Thanks, I'll report anything more I find there. Might not be able to fix it myself (my coding experience is limited to BasicA and vB and even that has been 10 years ago) but I know how to go bug hunting and enjoy poking at things I probably shouldn't. Oh and you should change your profile to include Necromancer in there somewhere, you've resurrected more mods I use from the dead than anyone else I can think of. =D
  2. Not only toxic, but corrosive and potentially explosive when mixed with water ( F2 + H2O > HF + O + O2 + O3, note this isn't a stoichometric ratio only the possible end products, HOF is formed as well but that decomposes fairly quickly into HF and O). Hydrofluoric acid (HF) is nasty, it's what they use to etch glass. It'll also do a nice job of dissolving your flesh. So yeah, extremely toxic. You don't want to be anywhere near a fluorine leak unless you enjoy your lungs melting into a gooey black puddle.
  3. That could be the issue right there. The only time I've observed a shift in LAN so far has been after a high time warp. In the case cited above, I was flying a few pieces of debris from my failed Pioneer P-30 mission (first Munar orbit attempt in this save) that wound up being botched because I lost signal before the burn end. After burning them up in the atmosphere of Kerbin, went back to KSC, then tracking station and seen what I reported above so it had to happen during that flight with timewarp, as I went to the tracking station before that to actually switch to that debris and didn't see any noticeable change in orbits at that time. I didn't check every piece of debris, but every active payload appeared to be fine as I was checking for station keeping working with LFO or something other than MP since the cfg file only had MP listed as a resource but apparently that doesn't matter any more. So the conditions I've observed so far with a shift in LAN involved a high timewarp, change in SOI in a flight scene, burning up a craft in the atmosphere and changing the scene from flight scene to KSC to Tracking Station. I think I'll restore that Mascon file and see if I can get a change in LAN while in a flight scene at high timewarp in my current save, should be fairly obvious when it happens if I stay in map mode as I got a ton of junk in orbit (one of the reasons I installed this, to bring down debris and broken payloads). @linuxgurugamer Did you start a new thread for maintaining this mod? If so I'll carry on this discussion there and let the mods close this one out.
  4. I just happened to have an orbit that was at a LAN of 180 and at close to 90 degree inclination and it flipped the orbit entirely on two parts out of three in the same orbit (or close to the same orbit, the Ap/Pe was a little different but inclination and LAN were the same because it was a payload, separator and kick solid). The thing is, the two parts that wound up at close to zero LAN, actually had different values of LAN on either side of zero, one was slightly positive and one was slightly negative yet both were changed at the same instant as I was watching for that after looking at the issues in the git and in the forum thread. It seemed to me to be throwing the value to zero first and then adjusting it based on mascon given that both objects that changed orbit were about a quarter of the orbit apart and therefore would have had different mascon influences on their orbit. The difference was large enough to not be a rounding error. I was just commenting on what I observed to hopefully help LGG or someone figure out what was going wrong. There were other objects that shifted LAN to close to zero as well but that one was particularly bad given what the original LAN was. Looking at your git link, I think this is wrong: double NewLAN = LAN + RateOfChangeOfLANDeltaTime; return RateOfChangeOfLANDeltaTime; Shouldn't it return NewLAN not RateOfChangeOfLANDeltaTime? The values I'm seeing are what the rate of change should be, not the final value of the LAN, and of course those would be close to zero but on either side of it. Edit: I'm going to have to poke at that file tomorrow with a code viewer, git is ok but it really messes with my eyes and a code viewer makes it much easier to see.
  5. Assuming they'll follow a similar flight plan as with Curiosity, yeah, the MCC was done on a small coast stage as payload separation was only 40 something minutes after launch. It was a kick to a 100 km x 200 km parking orbit for the first burn and then Mars injection on the second burn followed by payload separation soon afterwards.
  6. You both might want to look at that engine config again and realize that it's the RD-180 engine, not the RL-10C used on the Centaur. The RL-10C on the Atlas V-Centaur either used 2 or 3 ignitions depending on its mission and flight profile. TDRS-M used 2 ignitions and AFSPC-11 used 3 for example. https://spaceflight101.com/atlas-v-tdrs-m/flight-profile/ https://spaceflight101.com/afspc-11/launch-profile/
  7. If you are installing this on an old save, you have to load each active craft (and debris) to get the real mass and area for drag calculations, otherwise it uses a hack to estimate the mass and area, which can result in really weird decay calculations (for example a spent kick stage remaining in orbit far longer than the payload it kicked). But rest assured it does actually use the correct mass and area for drag calculations if it is able to access the correct values, which it can only do in a flight scene with a craft in physics range. A new save with this mod won't experience this because every craft launched will have its mass and area recorded. @linuxgurugamer since you are picking this up, I figure I'd let you know about the bugs I am currently seeing using @kalmor's recompile, since they are old bugs that go back to the last versions in @Whitecat106's git and possibly when @Papa_Joesplit off SCS from the main mod (although this might have existed before as well). First is the LAN == 0. If you are seeing LANs getting set to 0 or something very close to zero, look at the Mascon calculations as doing this workaround eliminates that problem, but it basically eliminates mascon calculations by removing the gravity maps and setting alternate = true in the mascondata.cfg file: @Starwaster seemed to think it was the mascon calculations applying too much change to LAN but I don't believe it is that as I watched a probe and either its decoupler or kick stage both get changed from a LAN of ~ 180 to a LAN very close to 0, while most of the other orbital parameters didn't change appreciably enough to be noticed. The third piece, either the kick stage or decoupler, didn't change orbital parameters. If mascons were influencing the orbit that much, I imagine it would have changed the SMA and ECC as well which wasn't observed as other drag factors were negligible and the orbits are close to 90 degree inclination. I think it might be failing to find a craft's LAN and then using 0 as the LAN and then applying mascon deviations to that 0 (which is why it always winds up close to 0 but never exactly that) and then writing that new value. The other major bug I'm seeing is with the Solar Cycle Simulator, the solar cycle is (or was) being reset. After making the mascon workaround I haven't experienced it resetting yet but I don't know if it was because of that or it was just incidental. I do know that currently it has saved a node for the solar cycle now, however I don't know if it was saving one before since I didn't check it before deleting and reinstalling the mod and reverting my persistent file (was more concerned with figuring out the mascon issue). It could have been getting reset because it wasn't saving the node for the current solar cycle, making it create a new solar cycle every time you went to a flight scene. If I see it reset again in my current save, I'll check on the saved node and see if it's creating a new cycle or overwriting one that should still be ongoing. I don't have your current updates as I'm still on 1.7.3 (and the 1.8 compiled dll just won't run at all on 1.7.3) and you might have fixed either of these issues with the updates you've done, but if you do see either of these things happening then it likely isn't a change you've made. I'm just bringing it to your attention before it makes you crazy and they were previously reported bugs that might have gotten buried in the respective threads. Not sure about the scope you intend for this mod, but @Whitecat106seemed to be making it into a Principia-lite with the Nbody stuff but I'm not really sure that's necessary. Mascons would need to be fixed or some sort of hack used to simulate them though as they are the only significant source of orbital decay for orbits above LKO or around airless bodies. My Explorer 1 that is roughly in the same orbit as the real life version is never coming down with the mascon workaround I did above (decay is listed as negligible), but without the work around it does decay above a "negligible" amount. Anyway hope that helps some, as I really want a mod that decays orbits rather than me going into the tracking station and destroying debris and craft according to my ad hoc basis of that should have come down already.
  8. I've only had that problem a few times and it was either because I was attacking the air stream or mounted the decoupler too high or too low. There was a nice little sweet spot where they'd eject clean (although they would still smash well under me). I do like to get aggressive with my ascents so I'm still in the lower part of the atmosphere in that screenshot above. This one is above the atmosphere and you can see the difference in how they eject. And this is somewhere in the last 10 km of atmosphere in my install (because I scaled to 77 km and then stretched it to a nice round number of 80 km in my 2.5x rescale) Technically still burning to apogee here (although TWR is really low for this part of the second stage). Or rather just cut the engine as the screenshot was taken. And yes that's a Centaur masquerading as a DCSS, never posted it because: a) wasn't really happy with the look, b) Cobalt would probably get upset seeing it on reddit, c) shortly after I put the album together he actually made the DCSS. So you guys are the lucky few to get to see my crazy mashup.
  9. @Zorg Delta 1600, 0900, 1900 and 2900 dropped all boosters at once. Air-lit boosters were ignited one second after (or maybe it was one second before that they send the command and they just took time to ignite so the flight profile shows air-lit boosters igniting one second after) ground-lit boosters flamed out. All these Deltas shared the same booster ignition and separation sequence. In the case of Meteosat I they were dropped 70 seconds after the air-lit boosters flamed out, not sure on the other payloads, but I think they basically held them until the rocket was at near zero AoA with the air stream or for range safety. Meteosat launched out of Cape Canaveral so I doubt it was a range safety issue more likely because it had to enter geostationary orbit so had a heck of a dogleg maneuver while ascending. Delta 3900 was a 5+4 arrangement (5 being ground-lit), and it dropped 3 boosters then 2 boosters in the star arrangement, with the 3 being the head and legs of the star and the 2 being the arms of the star. The air-lit boosters were ignited after the ground-lit boosters were dropped. Delta 4900 and 5900 were basically cobbled together from old parts plus the addition of the Castor IVs, they probably had a similar booster ignition and drop sequence that the Delta II 6900 and 7900 had given they were built as a bridge to the Delta II. Delta 6900 and 7900 dropped the ground-lit boosters after the air-lit boosters ignited, sometimes holding onto them slightly longer due to range safety concerns. For example launches out of Vandenberg dropped their ground-lit boosters over 20 seconds after the air-lit boosters ignited while launches out of Cape Canaveral dropped them immediately. It was never an issue that needed addressing, this goes back to 1.3.1: Yes that's a Delta III with GEM 46s. Just gotta watch that AoA.
  10. I think even when it's checking properly you may have an issue. Because when I do a first return from orbit that is manned, the ReturnFromOrbit parameter is now completedManned = <timestamp> instead of completed = <timestamp> if unmanned and that doesn't appear to get overwritten when you do a manned return after an unmanned return.
  11. There's a subsequent manned return that's recorded differently, wish I didn't blow away my old saves when I updated but I'm starting up KSP now to run a test and figure out what the achievement is actually called. ReturnFromOrbit is for manned or unmanned, doing either will complete it but I believe there is another for crew that is FirstCrewToSurvive however I'm not sure because it's been awhile. I'll have an answer in a half hour when KSP finishes loading though. Edit: Ok ran some tests, FirstCrewToSurvive will pick on any crew recovery I believe, certainly does for sub-orbital and orbital flights. Based on the time stamps, I believe it completes when you click Done on vessel recovery. Could work as a condition if combined with a ReturnFromOrbit check, as someone will have at least had to fly an unmanned return and recovered a crew from some sort of flight. Could be cheated but most people will probably be doing suborbital at least to fulfill that condition. @Morphisor
  12. Yeah, it definitely looked like more of a CoM issue than a control surface issue. Engine gimbal should be more than enough in KSP to keep a rocket straight that is even on the edge of stability. I've launched a 5m payload on a 2.5m rocket without a fairing and that thing was unstable as hell but as long as I kept the nose in the prograde marker, the engine gimbal could handle it. I think the only way you can really simulate that in KSP without a custom made engine for it would be to mount an SRB in a boattail that extends way down, and then fiddling with the offset tool to mount the fins in the right spots since you'll probably have to attach them to the SRB or the boattail adapter as the fairing walls don't like stuff mounted on them. Either that or an ore tank for ballast to push the CoM up.
  13. Looks more like the second stage is unflyable for a couple reasons. One the fins don't come down far enough and don't have control surfaces on the back end like the real thing did: But that might not be the real issue, because the sustainer motor had a funky design quirk, it looked like this: The reason for the long throat was to move the CoM of the motor up to match the CoM of the missile so the overall CoM didn't change during flight. It also made the second stage more aerodynamically stable as the CoM of the missile would now be above the CoP rather than below it that a more normal motor design would have. Even real life aerodynamics doesn't like the CoM being below the CoP on a rocket, that tends to flip them. So it's not just Kerbal aero that is at fault here.
  14. You forgot about the Delta 3900 series which had 5 ground lit Castor IVs and 4 air lit Castors. That's the only booster arrangement that's a pain as it requires 4 pairs mounted in mirror symmetry with a single solo. The 4x arrangement flew, but I can't find anything on the 7x arrangement. The Delta 3900 is the only one that used the 5+4 arrangement, the 2900 was 6+3, and the 4900 and 5900 went back to the 6+3 for the Castor IVAs. http://www.spacelaunchreport.com/thorh10.html
  15. My point was they didn't really need cost balancing. You can squeeze more out of the Titan because you can add strap ons while the Delta II is already somewhat maxed in performance. But for comparing builds of the two families with the same throw weight, they come in somewhat equal even if they achieve it in different ways. I think what people tend to favor depends more on their personal piloting preferences and what they are trying to do with it rather than any meaningful advantage of using one rocket over another. I think another thing too that the mods I use tend to make me favor Delta over Titan for those under 4 ton launches to LKO, part failure mod and part unlock costs. Delta is a nice rocket because it's incrementally upgraded, while the Titan is one big chunk of research and credits to make sure nothing explodes. By the time you get to the Delta II, you've worked out all the teething issues working up through Thor-Able, Thor-Delta, Delta, and Delta I. You save the Titan for manned missions because that's the only thing that gives a decent return for that massive upfront investment required to lower the risk of failure. And even after you develop the Titan II, you still use Delta because it's more reliable and really Titan II is just a stepping stone to Titan III and IV. You are really aiming for that 20 ton capacity when you start developing the Titan II. That's where the lack of part failures sort of hurts Delta in the stock game.