Salanmander

They need (well, "need"...from the same perspective as they should point up) to point towards the little knob at the top of the post, because that's the receiver. If you want the dish to point upwards, you can mount it on the side of the sat, or you can tilt the whole thing 15 degrees or so in the VAB. Incidentally, what are those landing legs from? They're not part of boxsat, are they?

Sortof. It didn't actually significantly affect my design constraints, it just increased my build time. The way I design, I eliminate torque from thrust if at all possible. The reason I include reaction wheel modules (and I do still use the boxsat reaction wheel module sometimes) is to have an agile craft that is easy to reorient. So what I so when building with boxsat is to simply place other parts on the craft in places to as precisely counteract the mass imbalance as possible. This means that the only real effect of the stack node offset is to add 20 or 30 seconds to the time to place one or two parts on my satellite, and make me re-do that any time I change my satellite design. In other words, it's annoying instead of interesting.

Do the procedural costs and masses depend on how wide the fairings need to go? If not, they really need to. I was doing some tests just now, and got some...nonsensical results. For example, take a Rockomax X200-32 fuel tank (the half-an-orange-tank one), and put a fairing base at the bottom, and a fairing around it. If the fairing base has a diameter of 1.25m, the fairings have a mass of 0.204 and a cost of 1,222. If the fairing base has a diameter of 2.5m, the fairings have a mass of 0.43, and a cost of 2,351. However, if you look at the fairings, the ones from the 1.25m base need to immediately go out to 2.5m to get around the tank, so they should actually be MORE massive than the fairings with the larger base. (Of course, the fairing base mass is completely reasonable, but the fairing mass dwarfs the base mass much of the time anyway.) I dislike this because it means that I can get a cheaper craft by making one that doesn't make sense with real-world logic, and matching real-world logic is a large part of the reason to have procedural fairings in the first place.

Using this with the RCS build-aid, I noticed that the modules seem to have their center of mass out of line with their attachment points, as seen in the picture below: (I used GIMP to shrink the background but not the build aid window, is why the stuff behind the build aid window doesn't line up.) It occurred to me that this might be due to unusual positioning inside the frame. If I put a frame on top of a payload frame, and one of the boxsat engine modules inside the payload frame, the COM and thrust line up for some modules, but not for others. Is this by design, or a bug?

There appears to already be code for normalizing the angles to be between -180 and +180. I wasn't able to understand all the function calls that were going on for checking the mission goals though, because it was referencing classes and functions that I couldn't find the code for.

Am I correct in thinking that there is no way to have vessel construction progress (or mine kethane and ore) unless the workshop (or drill) is in physics range? If so, would it be possible to support checking the time-since-last-load upon loading the vessel, and update work accordingly?

I'm pretty sure cheating by creating custom contracts that are unreasonable is a little like cheating by modifying your save game file directly: sure you can do it, but there isn't really any way to prevent people from doing so, and I'm not sure why you would want to prevent that anyway. The plugin is explicitly voluntary. Heck, you can even disable it for a launch to launch something for free. So if you want to cheat it in weird ways...be my guest. There may be exploits that would need to be addressed, but they would be things that are done within normal gameplay, and may be hard to tell apart. For example, if several different missions can be completed simultaneously, and that's not intended.

I was messing around some more with auto-recycling, and I noticed that it doesn't (or at least, doesn't always) auto-recycle if you're watching the debris fall from the tracking center. I think this is mainly the fault of KSP for throwing out weird numbers for the altitude of the vessel. I watched some debris come down from the tracking station, with the debug window open. I noticed that KSP didn't destroy it at 25 km altitude, it actually waited until the altitude was negative. Then it destroyed it, and I got this debug line from mission controller: [Log]: *MC* Vessel Mantis II Debris (unloaded) destroyed. Alt 1430391.5858285, body Kerbin, sit = SUB_ORBITAL It seems like the altitude mission controller is getting back from KSP is wrong (I assume that's what v.mainBody.GetAltitude(v.CoM) does). And this is preventing MC from recycling it, because it checks for altitude to be less than 25000.

You can enable/disable it in-game (although it will still show GUI elements when disabled). You'll need to switch it every time you switch saves, though. Alternatively, you can just ignore it in some of your saves. Running into the massively negative budget range doesn't actually change the gameplay at all. Edit: Should probably clarify, it DOES track budget independently for multiple saves, so ignoring it in one save won't slaughter your budget for the others.

Looking at the code some more, I definitely agree with Bio that the fuel is not getting recognized. I know you said that not everything gets a debug line, but it looks like it does give out a debug line when it decides to use fuel. Specifically, in this chunk of code: [B]foreach[/B] (Propellant pr [B]in[/B] e.propellants) { [B]if[/B] (rmasses.Keys.Contains(pr.name)) { rmassdry -= rmasses[pr.name]; print([COLOR=#DD1144]"Using propellant "[/COLOR] + pr.name + [COLOR=#DD1144]"(mass: "[/COLOR] + rmasses[pr.name] + [COLOR=#DD1144]")"[/COLOR]); } } Because the mass it's reporting in the line print("DeltaV available: " + dV + "(Mass ratio: " + (mass + rmassdry) + " / " + (mass + rmass) + ", TWR " + TWR + ")"); is the correct dry mass, this implies that the fuel is never getting added, AND never getting taken away. I suspect the culprit is somewhere in the block up above where it's counting up the resources. Specifically: [B]foreach[/B] (ProtoPartResourceSnapshot r [B]in[/B] p.resources) { [COLOR=#445588][B]double[/B][/COLOR] amt = Tools.GetValueDefault(r.resourceValues, [COLOR=#DD1144]"amount"[/COLOR], [COLOR=#009999]0.0[/COLOR]); [COLOR=#999988][I]//print(Tools.NodeToString(r.resourceValues, 0));[/I][/COLOR] [B]if[/B] (!(amt > [COLOR=#009999]0[/COLOR])) [B]continue[/B]; [COLOR=#999988][I]//DBG print("Found resource " + r.resourceName + ", amount " + r.amount + ", cost = " + rCost);[/I][/COLOR] [COLOR=#445588][B]double[/B][/COLOR] dens = r.resourceRef.info.density; [B]if[/B] (resources.ContainsKey(r.resourceName)) { resources[r.resourceName] = resources[r.resourceName] + amt; rmasses[r.resourceName] = rmasses[r.resourceName] + amt * dens; } [B]else[/B] { resources[r.resourceName] = amt; rmasses[r.resourceName] = amt * dens; } rmass += amt * dens; } I can't really say more without being able to run debug tests, and I don't have the knowhow to compile it myself. It looks like it has debug lines commented out, so I'm assuming those got looked at at some point, and that block of code is, in fact, running. However, I do notice that amt is set using "Tools.GetValueDefault(r.resourceValues, "amount", 0.0)", but then in the debug line it's reported as "r.amount". It's possible that r.amount is just outdated, and the commented out debug code didn't get updated, but it looks highly suspect to me. Is it possible that amt is always set to the default of 0.0?

After further testing with the debug window, it looks like I was wrong, and the parachutes actually do recycle. So this does mean it saves you a little bit of money. For the curious, assuming parts that have no price modifiers on them, you save about 11.5% of the original cost of a booster by adding enough parachutes to auto-recycle it. [1] The percentage gets higher the more mass of your booster comes from other categories (like aerodynamic), but generally you want to keep as much mass as possible as rockets on your boosters. My frustration, I think, comes from the fact that I saw "oh, now I can recycle and get 60% of the cost back! I'll need to add some parachutes, but that shouldn't add much to the cost when I'm comparing it to giant boosters", but then it turned out to almost not be a good idea, after I had dumped 300 science on the ability. This is a case where the general information you can easily find dramatically misrepresents the actual gameplay, so in order to make an informed decision you actually have to delve into the game files and crunch the numbers yourself. I suspect what I will actually do is reduce the cost of parachutes in my own instance of the game. I see where the necessary drag comes from, and it makes sense. However, a radial parachute costing as much as an LV-909 engine does not make sense to me. [1] The math, so that other people can check it, and or see where it came from: M is the dry mass of the booster (no parachutes) m is the mass of just the parachutes. So we need (M+m)*70 drag, and the drag we get is m*500. Solving, we find that we need m = M*(70/430). (In practical terms, 1 ton of parachutes per 6 tons dry mass.) The old cost was 0.5*2800*M (assuming all the mass is from the propulsion tab). The new cost is (0.5*2800*M)+(3.7*2800*m) = (0.5+3.7*(70/430))*2800*M. This is 2.2x the old cost. However, by recycling we get (0.63*0.95)*the new cost back, so after recycling, the new cost is (1-0.63*0.95)*(0.5+3.7*(70/430))*2800*M. This is 88.5% of the old cost. Edit: It occurs to me that I'm falling into the trap of negative comments being expressed more frequently than positive ones. I want to be totally clear: this mod is bloody fantastic, and breathes life into the game for me. I very quickly get bored with pure sandbox things, and the fact that this adds clear things for me to strive for is fantastic.

My tanks do have engines, but they're the same cost-per-ton, so the math that I ran works for engines as well as tanks. In order to recycle some amount of money worth of parts from the propulsion tab, you seem to need to add MORE money worth of parachutes. For example (made up numbers, but consistent with pricing as far as I can tell): Cost of engines + dry tanks: $10,000 (to pick a random number) (which would be $10000/($1400/ton) = 7.14 tons, whether it's engines or tanks) Cost of parachutes needed to recycle that much tonnage: $10,400 Amount recouped by recycling: $6,300 Total cost without recycling: $10,000 Total cost with recycling: $14,100 (as well as worse TWR and dV) I'll run some tests with the debug window tomorrow, to make sure my math is correct, and in particular to make sure the parachutes actually aren't recycling. If they are, then the total cost with recycling above would be $7550...so recycling would actually save you some money. Although maybe not enough to be worth the lost dV of carrying a bunch more parachutes.

Has anyone found the auto-recycling to actually be worth it? It seems like the cost of the parachutes is not being included in what gets recycled for me. Is this by design, or did I mess up my install somehow? If it is by design, than it's hard to see how auto-recycling could be cost effective. Needing 70 units of drag per ton of mass means you will need 70/500 tons of parachute per ton of other stuff (at best...that's if the mass of the parachutes isn't counted when figuring out how much drag you need). Let's say I want to recycle 1 ton of tanks and/or engines. That means I'll need 70 drag, or 70/500 tons of parachutes (at best...that's if the weight of parachutes isn't counted when figuring how much drag you need). As I understand it, propulsion parts cost $2800*0.5 per ton, and utility parts cost $2800*3.7 per ton. That means my 1 ton of tanks costs $1400, and my 70/500 tons of parachutes costs $1450. Even if the parachutes also recycle, that only /barely/ saves you money.