draqsko

Unfortunately I don't except on a couple old SSDs that I'd have to hook up first to get the info from and I can't remember if I cut and pasted or just copy and pasted stuff. Blew away everything not needed on this box after I had updated to 1.11. Had to build a new computer because my GPU died on my FX build and just started building my Ryzen build since I couldn't find a replacement for the older CPU. No point in using an RX 590 on an FX-8350, the 280X was already bottlenecking at the CPU in some cases. Edit: Oh and the R2D2 thing must've been funny. It does kind of look like it huh? *ponders building a black R2 unit for a Mun colony with robotic parts*

Thanks for the nod @zer0Kerbal even though it really wasn't much that I did. I loved that little thing until KSP updates left it behind and @CobaltWolf made an actual Corona reentry capsule. I should note that unless you changed the buoyancy, it may have issues with floating on water. I know in 2.5x rescale it would sink like a piece of lead. That's something I choose not to fix though because it was more realistic with how Corona was actually built (it had a salt plug that would dissolve in the ocean if airborne recovery failed so the Russians wouldn't be able to get it and see how good our spy birds were).

Shhh, just make the parts, don't worry what we do with them. Besides, it's your fault because of the old MOL airlock and Gemini docking collars: Gotta make it at least somewhat aerodynamic.

Take your pick of bulbous payloads with boosters, what shape do you prefer:

This is the same error that I was seeing before the logs overwrote themselves after I rolled back. You can see in the timestamp it's roughly every 20 ms, same thing I experienced.

May be a compatibility issue with the latest version of KER 1.1.8.4 and KSP 1.11.2, but I didn't test it fully on just a stock plus DLC install only so it could be a mod interaction. After updating to KER 1.1.8.4, all the thermal readouts went kaput. My own little HUD window just showed up like it does for the landing or maneuver when in the editor while on the pad (ie there's no information there so it doesn't really create a window but you can see the top left corner still) and nothing short of rolling back the version to 1.1.8.3 could fix it. Not sure why it did that because I have nothing that would touch Core Heat or Part Heat, even System Heat works alongside it rather than replacing it yet, and it was obvious that temperatures were still increasing because graphically I got the red glow and temp bars in the game but KER had nothing for a readout, nor anything about that in the log file which is the really weird part. The other issue I observed was the Rendezvous window disappearing after selecting a body that I technically didn't have orbital information for but could still select from the list. I have Research Bodies installed and forgot I choose a difficulty option for the test save that leaves Duna undiscovered, although MJ and KER would still be able to read their orbital parameters, previously. Forgot to copy the log file before I fixed my install, but IIRC the error was unable to get relative inclination that was completely breaking the window and making it disappear. It wasn't really disappearing but not being drawn in the first place as there were hundreds of that error being spammed in the log file. Basically every time it would poll to create the window, it would fail and post a log entry. And since you couldn't change the target without a window there, it would be stuck endlessly repeating that until you loaded a different craft, or reverted to a time before you decided to select a target. Not even sure that it's strictly caused by RB since I didn't have any other craft at the time to test if it occurred with selecting another object besides a planet with an "unknown" orbit. If you need any other information that might help with finding the cause, please drop a reply, otherwise I've largely fixed it for myself by reverting back a version and it makes little sense to worry about 1.12 compatibility right now when most of my mods aren't even updated yet so I'm not updating yet. If and when that happens, I'll grab some copies of the logs if I experience the same issue again. Like I said, could be a mod interaction but it's not worth the time and effort right now to tease out.

Quick and dirty way to search for gross errors happening, open the KSP.log file and search for EXC, ERR, or WRN using case sensitivity. Those are all the log codes for exceptions, errors or warnings and something causing an issue is bound to throw out something as long as it has a chance to log it before crashing. Some times even the last entry can give an indication on a crash, as MM loads by alphabetical order which is why some parts of BDB have z's appended to the beginning of the name, to get it to load after everything else has patched but without using the FINAL tag in MM.

That would be the version I'm currently using, for 1.8.1. Was easy enough to change the config and it wouldn't have happened in 1.7.3 since that was the version before that Remote Tech config was added. I can't even begin to describe everything that was broken, SPU showing up, Internal data transmitters were wiped completely even ones added by patch or existing in the part config file, USI tools was completely hosed. Yeah bad things can happen when you load a dll compiled with a different version (and it think it's a different .NET as well). I was already going for broke at that point anyways so I figured what the hell, maybe it's my lucky day. It's never my lucky day.

What can I say, I'm old. Actually was on 1.7.3 for so long because I had a stable setup and BDB hadn't released until winter hit. Didn't catch a break with snow this year, fired up ckan and seen the new release. Everything looked good until I started building Vanguard and realized the issue with SAF. Then I did the crazy thing and tried to use the packaged versions. Then everything went upside down and figured a clean install would be faster than trying to fix anything. Spent most of the week on that given all the install a few mods, boot it up make sure nothing broke, rinse and repeat... for 202 mods. I do find all the ways you can break something though. I had module SPU start showing up on some parts, and I don't even have RT installed.

Question 1: Yes, they are turned 90 degrees on the pitch axis but otherwise functional. And CKAN installed B9PS version 2.11.1 and SAF version 1.5.1 for BDB version 1.7.1 on KSP version 1.7.3. Basically it installed the correct versions of each directly rather than the packaged versions from BDB. Question 2: The packaged release: https://github.com/CobaltWolf/Bluedog-Design-Bureau/releases/tag/v1.7.1, if you download the zip from there, open it and look, you'll see it has B9PS version 2.17.0 and SAF version 1.11.0. Bad things happen with those in 1.7.3 but they work in 1.8.1.

Didn't expect a CKAN update, as I said it'll pull the right DLLs for 1.7.3 so it doesn't break anything else. But the Git release will break updates if they download and install right from GitHub. It's labeled as 1.7.3 there and it is not compatible with 1.7.3 because it will break more than just BDB. Not even sure how it broke things but after trying to use the packaged versions of B9 and SAF in 1.7.3 I noticed all internal data transmitters were missing. So yeah, don't do that.

Yeah I mean the current release though. Am already on 1.8.1 and will probably move to 1.9.1 in a little bit. Need to spend a weekend blowing up some rockets because I spent a couple days figuring out how I broke my install going from 1.7.3 to 1.8.1. Not to mention the packaged DLLs for B9 (2.17) and SAF (1.11) won't work properly in 1.7.3 since they are compiled for 1.8.1. CKAN will install the right versions for 1.7.3 but SAF doesn't work properly, so you can't use the new fairing bases. But if someone tries the package off GitHub, it's going to break a whole lot of stuff because B9 and SAF both don't work properly at all. That's what I was reporting that builds with those two DLLs aren't quite working in 1.7.3, with a little less coffee in me than now. Otherwise I've got it running in 1.8.1 with 202 mods installed, and everything else seems fine.

So I finally got everything working again. @CobaltWolf While the parts as a whole work in 1.7.3, SAF is broken in that version, unless Procedural Fairings is somehow affecting it in that version (only mod I can think of that would have any affect out of those I've installed, but I have the exact same mods in 1.8.1 and it's fine). The fairing bits are rotated 90 degrees, forgot to get a screen grab of it, but basically to tubed halves are turned on the pitch axis, they otherwise work normally. Just trying to update B9 and and SAF up to 1.8 versions would of course break things in other ways; half the fairing was there, half wasn't, in VAB and flight; but that was to be expected. So I'm not sure if you want to restrict the versions to after 1.8.1 for BDB packaged with SAF. But I can say this, it works with almost everything in 1.8.1. Because I really don't stop to think if I shouldn't, only if I can. I did have it up to 73k but it took a long time to load, we're only at 65k-ish now. Edit: Oops, I have more than that actually. I think I need help.

@CobaltWolf Just figured I'd pop in after updating my KSP install recently and just noticed Corona parts. Yay I can finally put to rest that old Sample Return Capsule from 1.2.2 I've kept hobbling along on a wing and prayer since 1.4. Don't let anyone tell you different, you're the best. Love all the new parts even though I gotta rebuild everything.

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

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.

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.

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.

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.

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/

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.

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.

@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.

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.

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