komodo

This is a tank bug that is fixed in the dev edition; if you open the offending tanks cfg file, you will find that the oxidizer resource is accidentally commented out (it has // at the front of the line.) Take out those slashes and you should be good to go. (Unless something else is amiss, in which case report back and we'll sort it at that point )

Well... Reality Tried. However, Science demanded that we go deeper.

So... We haven't had any decent shots in a while. We haven't had much out of the canon either, or I might just be blind... So, I took a bit off from stress testing and balancing to do a thing... A Horrible Glorious Thing. ... ... Gentlemen! I give you... This Thing! ... I don't know yet if it flies. I hope it will... I haven't done anything entertaining in a while

... Victory? No really, that's pretty awesome.

Could you attach a list of mods and/or a screenshot of one of the affected parts? Now I'm curious as to why this might be occurring. Thanks!

Just a note from my insane brain: the RT antennas that are shipped with RT are a little nuts as far as balance goes. They are either really heavy or really light. I find it hard to judge "just right", especially in Kerbal proportions. Everything tends to be heavy as so much dv is available/low orbital speeds required. But it chafes still to mount a 1 ton dish on a probe. Or, this may be me being ignorant of dish masses; has anyone with more perspective looked at the RT antennas? i will have to try to find the Reddit thread; irrationally I feel vaguely responsible for the RT antennas... >< more importantly, that model looks pretty cool. The polys are ok; my body computer is ready.

That was me. I had to put it on hold a bit due to a (now fixed) bug in the MOLE code. I intend to get back to it soon.

I've looked at making BDB configs for TestFlight twice in the last three weeks and every time I open their documentation, I remember why I closed it the previous time/curl into the fetal position. its extremely robust in what it offers, but the implementation is almost too flexible; there isn't much guidance on how to make new configs. The technical aspects are challenging, but not impossible. I would have to find a decent float curve editor, and perhaps brush up on YAML, but at that point it is a gameplay impasse; if career, how should one engine experience flow into another? Many times, the different lines don't have much to do with each other, for example. This is all just restricted to engines as well, while TestFlight has options for almost any system you'd want... For RSS/RO, it's "easy" to set the numbers up as, well, they just go look them up, but for more "game-y" systems like stock/alike, I have no idea where the "fun" cutoff is, or even what would make for a productive gameplay element. tldr: , possible but challenging. Gameplay balance also (quite) challenging.

Then there is my other model, which I hope doesn't become a trend (as its a bit of a boat anchor) which is a quetzal core with 6 ESM around the rim, offset into one large hexagon. It's a very capable boat anchor, mind you, but it's rather beefy >< ... But soooo symmetrical...

I'll try to post back with some shots of my last probe... I didn't catch any last night due to a "D'OH!" On my part; using Kerbal construction time and juggling several contracts, I sent the guy to the mun only to find out that I sent the probe that should have gone in a high polar orbit accidentally. (F9F9F9!..) It was made of the smaller box (name?...) with a pair of Quetzal service packs strapped on. It was pretty spiffy, if I might say so

I ought to have been more explicit: I wasn't trying to get them going with 6.4x and "stock" parts, I had both @Nerteas cryogenic fuels as well as SMURFF doing fuel fraction rebalancing. I agree that at that scale, the numbers just don't work out. That SIVB I posted a page or two was made of tweakscaled Titan and centaur parts, and worked well for the mission of "get a half fueled CSM to low orbit", before the extra mass boost. The "canonical" S1 config doesn't have a prayer at either mass, fortunately. In contrast, Gemini + Titan works well with a slight stage stretch, so I don't doubt a balanced solution can be found here. I will have to try a 2x w/o extras to compare. @CobaltWolf, it was the S1 with the SIV that got off the ground with the CSM, albeit it partially fueled, but aside from a sluggish surface TWR and a lousy stage 2 TWR, it was able to make orbit and even to a TMI burn (plus insertion, but we've passed ridiculous at that point) I am not trying by any means to go full torches and pitchforks "FIX EET NAOOOO", but just to get some current feedback on where we were vs the goals. I have a decent idea now, so I'll have to have a think on it. To reiterate, I have no doubts that a balanced configuration will be found, and a use for each booster as well.

Having done this on accident before, but in the other direction, I would not recommend it. Even if everything held the same relative position with regards to a surface (altitude), nothing would have remotely enough energy (speed) to stay up. More realistically, I don't even expect that much, with either the existing bodies being thrown into Kerbol orbit/space, and/or spawning deep inside the/a body. But, you can always back up your save and give it a go. As long as a save isn't loaded with a rescale, you can remove said rescale and continue on with the backup save. But do make sure to back it up first!

First, curse le mobile forums. *curses* second, @JsoI have more of my respect on balance; I now see why the CSM were bulked up. I loaded a stock (+FAR; I don't know if that made much of a difference) system and although it barely made it off the ground, the S-I was able to do a Mun mission with ease. I had been using 6.4x + SMURFF and had a lot of trouble, as the dV was (relatively) quite low on the CSM due to the added mass. i know we don't balance around any such modifications, but now I'm not sure about stock. I had been worried that some of my MM patches might be too massive, but now I want to go back and cram more in them. I had just forgotten how (not) much delta V was required for a Mun shot :/ (this post was mostly me musing, I will try to have some more constructive thoughts later on)

Ok, random weird question time: My current install is modded to hell and back and to hell again; What exactly is the intended dV for a standard Kane CSM, chutes, quads, et al combo? I suspect i've gotten myself tied in a knot with some of these rescales, but I wanted to confirm what ballpark it ought to be in. If this is too dumb a question, please pull the "too dumb a question" lever and drop me in the pit

Works very well thus far! I agree that it is unfeasible to expect all mods/parts to be supported. Letting the user define their own stats would be a good feature. Similarly, an over the top 110% stretch goal would be to allow input of custom orbital parameters for RSS and the like; BUT, only after any core functionality is in place. Nice tool, and a very nice interface. That's a difficult trick, I always struggle with them myself

Screenshot time! I was playing around with the toys offered and cooked this up the other day. I dubbed it the S4bkindasortamaybe. ...Assuming I can figure out how to imgur here... O_o We rescaled a centaur rl 10 and a titan 1 short tank. The proportions passed the 'eyeball' test, but I have no idea if they are actually right. A better angle. Whole album here. (Interestingly, my somewhat random naming scheme lead this series of rockets to be dubbed "Volcano 1" for my KSP. This keeps with the offered capsule name, I suppose!)

Sounds about right; i'll adjust the numbers tomorrow night if no one has gotten to them by then. Thanks much.

Tanks are looking good, I like them a lot. I would go check your PR on github though, *COUGHCOUGH* Someone who is running stock should check the balance though; i'm on a 6.4x rescale with SMURFF, so it is difficult to say what is 'fair'. About how capable ought such a engine/tank + (which?) probe be? Either 'real' wise, or gameplay wise? Any thoughts, peanut gallery? EDIT: That is also to say, I completely eyeballed the mass and/or tank volume, although the volume was hinted by the model names. @Jso, what was the ratio you guys came up with/determined for dry tank mass? (Or volume/model scale, for that matter.) It entirely eludes me at the moment

Oh good, it's only reactivity 3. Not so bad. might as well toss an "OX" in the bottom diamond, haha. Looks really cool, though!

Regarding RT: Behind the fold below is a modified MM patch for the 4 dish antennas. The s/m/l fixed antennas I rebalanced by cost, range, and power usage, such that the smallest dish is lowest in range, but should still get to duna. This was a significant buff to the range, actually. Cone massively nerfed from 55 to 3. Energy cost actually boosted to 0.6, in light of a lower tech, but offset by the ease of solar panel usage in the inner system. The medium dish should get to jool, on close approaches for sure, but is heavier and more expensive. Power adjusted down to 0.29, hopefully to run ok with 0.4 ec/s RTG(s), plus whatever else is running. Suggest wise battery usage on transmission to not loose signal. Cone nerfed slightly from 1.5 to 1. Big dish has just under twice the range, and an energy cost of only 0.21, but a cone of only 0.3 (unchanged) and a much higher cost. The cost progression now goes 1000, 2000, 8000. Folding dish I have no idea what to do with, and i've left alone if I recall. Suggestions on balance re: applications versus its fixed brethren? If someone else could give these numbers a go and let me know how they feel/work, that'd be great. As with most of my KSP-ing it seems, its another 1 AM edit job, and we all know how solid those can be Thanks much!

This post was key for me in figuring things out. Nodehelper is also invaluable in sorting nodes. The best resource here though might be this... node_stack_magneto = 0.0, 0.196, -0.04, 0.0, 1.0, -1.7, 0 EDIT: Unrelated, but still noteworthy: The contributed RT patch needs to have some numbers adjusted, unless i'm doing something tragically wrong. The Pioneer and Voyager dishes draw massively more power than their respective RTGs can provide. 0.7 draw vs 0.2 generated for Pioneer. I don't often use RTG, so I was hoping the new coreheat business would help, but no, it just seems there is a numbers mismatch here >< I'm not sure which way the balance should swing, but I wanted to raise the issue in any case,.

The quote is a little wacky... Yes, those numbers seem rational. I think the 'time to drift out of contact', the 38 degrees sounds like the angle at which line of sight is broken by the planet. Depending on what antenna is being used, this may result in loss of contact much sooner. Yes, num 2 seems to get closer to num 1, and sightlyyyyy faster than num 3, so a bit farther away from it as well. It doesn't matter really what 'base' to compare them to. It might be simpler as you say, to push them all towards 1:30.00. Making sure things are circular is a lower priority than the period. These are all nearly circular (at least, they are not very elliptical!), so unless your antenna is at the farthest reach of its range, I would just adjust the orbit at almost any point, although ap or pe are convenient, such that the period(s) match. If the orbits are not perfectly circular, imagine it like this: With the current situation, some are moving closer/farther slowly, but they are still all in range. If the orbits are not perfectly synced in terms of ap/pe, but the periods are the same, they may drift closer and farther as they orbit, but it will cycle back and forth like a pendulum. The effect on communication should be negligible. What I mean to say, is to try to adjust each once, without worrying after circularizing. It will be easier to get the numbers down, and you will go , well, less crazy

Mobile, so difficult to quote... But as far as I know it is only the period that matters ultimately. They may drift closer/farther around the orbit, but it will oscillate periodically. However, those orbital times, while "tight", will be magnified drastically over many orbits, particularly 10 y worth. But how much exactly? Each orbit they will get ~0.008 sec closer/farther. There are 24 h/day, and that is ... 18 orbits at that pace ?( arithmetic is not my strong suit!), so 18 orbits a day, * 7d/w, ... 126 orbit / w, * 52 w/y ... ... 6300 + 252... 6552 orbits /y? And ~1600 m/s orbital speed? So... 1600 m/s * 0.008 sec/orbit * 6552 orbit/y *10 y = meters drift per ten years. ( not doing that in my head, though ! ) so, I don't actually know at that scale. Those are the numbers you'd need to find out, assuming I didn't botch anything in there of course. The point though is that seemingly small values can make a big difference over a long time and at a high speed, e.g., like that in orbit. now I'm curious though, let me know what turns out!

@danfarnsy: there is a dilbert quote which can be paraphrased as "what is work when your job is to think?", which sums up a lot of the sciences nicely... I know for myself, in a different field, that even doing unrelated work, there is some back-burner-ing going on constantly. Additionally, as someone who only vaguely has heard of the Casimer effect, that was a pretty good explanation; I know enough QM to know that the scope of the problem you are working on sounds gross, and you have a major hat tip/salute for being able to plow into it (I will take my non-realitivistic QM, that I have to deal with, and be content tyvm ) oh, TAC; as with all things KSP, and add on authoring in particular: You take care of You first. (I wish they had that in 72 point font at the top of the page sometimes )

All valid points. It boils down to pragmatism, I suppose; if we stick straight to the USI 'stock' conventions, then the only thing really we need to do are the supply capsules and the station parts providing habitation bonuses. The question then becomes, (and i've never figured this one out to be honest) should the grace period be just that, insurance, or should it be a baseline to work off of, and *then* consider capacity? This honestly is the thing that bugs me the most about this system. It is treated as a baseline, but then always referred to as a grace period. Totally agree on fuel vs supplies via a switch. Is that only the gemini/'progress'? The others are just KIS boxes, I think. (I've also never figured out if you can stick containers in a KIS inventory and alt-click transfer them into a different container.) Do we ship anything like B9PartSwitch? FSPartSwitch? These are the sorts of things I don't know the best way to proceed on, but I also know 100% that a lot of balancing/redirection needs to take place. I appreciate the feedback, and i'm also not too proud to back some/half/most/all of the changes out if they don't make sense.