• Content Count

  • Joined

  • Last visited

Everything posted by Fraktal

  1. Same here, although my FPS isn't quite that bad (I'm running KSP on a 13 months old laptop with a quad-core CPU and a decently good GPU) and remains playable for 4-5 hours before chugging down so badly it takes the game 15 minutes to exit and the clock is constantly running in the yellow even in vacuum at no movement and no warp, even if I have literally nothing running in the background. I do not use any parts mods and only use PlanetShine and a low-spec config for EVE in terms of visuals, but it's bad enough that I'm actually reluctant to look for support when I'm having problems with mods because I'm fully expecting the modder to tell me off for wasting their time with such a low-spec config that shouldn't even be trying to run KSP in the first place.
  2. I moved the thermometer and barometer to the sides of the exp. storage bay and offset the goo canister as far into the exp. storage bay as I could. Torque is now minimal, though still non-zero. Also, I decided to disregard the rolling and go aggressive with the gravity turn, flying nearly horizontally by the time my apoapse is beyond the atmosphere. That did the trick, so the problem was definitely with the ascent profile. Still, I decided to go back to the side-tank configuration for the transfer stage but with four FL-T200s instead of three. This nets me nearly 300 m/s surplus dV in the transfer stage by the time circularization at the Mun is complete at 50 km altitude. Now I just need to figure out why in the world is the Mk1 lander can so damn draggy. According to the UI, it's got nearly 11 drag while the Mk1 command pod directly in front of it has less than 1 and during reentry from a munar flyby, the lander can heated to 79% despite being behind a heatshield with ablator. Do I need to use a 2.5m heatshield here, or is the heatshield dumping heat into the lander can due to the heatshield being attached directly to the lander can with no parts between?
  3. I go vertical until 100 m/s, then start turning. I never turn at the same rate between two takeoffs because I'm not quite that good at paying attention to three things at once, so I just shrug and eyeball it as best as I can. SAS locking is what I usually go with, yes, but not with this particular rocket (the OKTO can't do prograde, the command stage has only one seat and I'm sending a scientist). I went through the booster tinkering with each part. If I just attach parts on the tricoupler's triplet attachment nodes, there's torque, but if I select them with an offset tool and click on any of the arrows (not drag, just click), the torque in this stage goes to zero. So KSP isn't placing them properly. The booster stage and the transfer stage are torque-free: rotating them with the rotation tool changes neither the strength nor the direction of the torque. If I rotate the service bay with the science payload, however, it rotates the torque's direction too. Rotating anything underneath that service bay doesn't change anything. So the torque is definitely at that bay. The interior of the bay has a thermometer on one wall (placed on the outside, then rotated and offset to be inside), a barometer on the opposite wall, an exp. storage bay in the center and a goo canister hanging off the side of the storage bay, towards one of the doors. That last one might point at the goo canister as the reason for the torque... except not only RCS Build Aid's torque indicator points in the barometer's direction, if I take off the goo canister, the torque is still there and it's still pointing at the barometer, even though it has the exact same weight as the thermometer and is in the exact same position, so the weight distribution should be symmetrical. Oh, and the torque direction RCS Build Aid shows is linear, not rotational. One more thing. I've read somewhere yesterday that clipping parts into each other causes phantom forces. I have a reaction wheel clipped between the top of the booster stage's tricoupler and the decoupler connecting the booster stage to the transfer stage, as the command stage's reaction wheels don't have enough torque to meaningfully steer the booster stage in the upper atmosphere. Could that be causing rotational torque?
  4. So. I have a Mun rocket I've already successfully ran several missions with - but when I fired up KSP today, I ended up spending six hours without a single mission actually reaching Kerbin orbit because it just doesn't seem to want to work the way I used it before. Maybe I'm messing up the ascent, but I'm not sure. Anyway, the rocket in question (couldn't make screenshots because KSP ran like excrement after six hours and took fifteen minutes to exit): Booster stage Three Reliants on a tricoupler with four FL-T400 tanks each, plus three Thumpers and three winglets. Struts applied where necessary. Originally the Thumpers were mounted on the side of the LF tanks, similar to how an S-shaped asparagus staging is set up, but I dropped that design because I wasn't sure the drag/flex wouldn't cause rotational torque. So instead I hung a number of girders off the tricoupler's exact center (offset tool until RCS Build Aid showed zero engine torque), onto which I attached three extended radial decouplers that clip through the LF tanks to the outside. This stage is capable of outputting a max-throttle TWR of 1.7 up until 81.88 tons. My payload is lighter (60-something, below 70), so I throttled back all engines in the VAB for 1.7 TWR at both takeoff and SRB separation. In this configuration, the stage has just short of 3000 m/s of dV. Transfer stage Single Terrier with fuel equivalent to two FL-T400 and one FL-T200 tanks. Originally made up of a single FL-T400 and three radially-mounted FL-T200s, with nosecones on both ends of the radial tanks, to shorten the rocket's height for less flexing. Changed to two FL-T400s and a single FL-T200, all centrally mounted, to test if this configuration is more drag-friendly, but noted no difference aside from gaining over 100 m/s of dV from losing the nosecones' weight. Packs just over 1900 m/s. Lander stage Single Terrier throttled back to 60%, with an FL-T400 and an FL-T100, plus four landing legs and four searchlights. Packs over 2100 m/s to have enough spare fuel for a non-equatorial landing (about 20° away from the equator max before cutting it dangerously close, even if I zero out my horizontal speed a few dozen kilometers above the target area and land with a suicide burn). Payload stage Command pod with three Communotrons (the extendible, not the radial) and three solar panels on top. One materials bay. Two service bays. One with a science payload (1 exp. storage, one thermometer, one barometer, one goo canister), one with a guidance payload (OKTO and 200 power). Heat shield with 80 ablator. So then. My problems with this are twofold. First, if I deviate more than about 3-4° away from prograde, the rocket starts rolling. Not flipping due to lack of stability, rolling around its lengthwise axis in a clockwise direction, turning the pitch into yaw, which introduces an inclination change, which causes SAS to start yawing in the opposite direction, which makes the roll even worse until it eventually stabilizes. If I turn off SAS, it keeps rolling for about ten more seconds before stabilizing. I've noticed this on other rockets before, but they all started rolling at far bigger AoA, never this soon. Because of this, I'm having a hard time doing a proper gravity turn, only managing to turn 20° before hitting the target apoapse. I've spent hours trying to figure out why this is so. The rocket is stable (barely) with the winglets it has and adding more winglets doesn't help. Launching without the SRBs doesn't help either. RCS Build Aid indicated a ~5-6 kN torque which I fixed by nudging around the LF tanks on the booster (they weren't centered properly, for some reason). Now I still have a torque of 0.6 in the science payload, but that's not it. Which leads me to my second issue. Even once I dropped the transfer stage's radial tanks to reduce drag, I'm still losing so much dV during takeoff that it costs me about 4000 m/s to circularize at my usual parking orbit of 120 km. While the transfer stage still has more than enough dV left for a munar encounter, it doesn't have enough left afterwards for me to deorbit it into the Mun like I've done with my previous launches of this design. Yet when I tried reducing my apoapse to 80 km as per the dV map, I hit apoapse so quickly that I ended up 30 seconds late at starting the circularization burn. I'm losing a colossal amount of dV somewhere, I just don't know where. So then, what are my options? The booster stage still has a few tons of weight capacity left, should I use that to give the booster stage more fuel? That solves the dV budget issue, but what about the rolling? Oh, and ever since I switched the SRB mounting from a regular decoupler to an extended one, the SRBs are pitching inwards after separation and hit the LF tanks if the rocket isn't aiming perfectly prograde, despite me having mounted them literally at the bottom of the decoupler to center the decoupler force on the CoM. I even offset the SRBs one notch lower, no difference. When I was using the regular decoupler, mounting the SRB on the very bottom caused it to separate without pitching, why isn't this the case with the extended decoupler?
  5. I tried it, about an hour ago. I put everything on the bottom of the bay, did the offset-into-bottom-of-command-pod thing. Reenters fine with a heat shield, flips without a heat shield (and I was coming in at a very shallow angle). So I'm keeping the shield on. It's a highly inefficient suborbital rocket, so it's not like dropping one small fuel tank to not go over 30 parts is a critical shortcoming because it doesn't have the dV to stay in orbit either way (and if I bring the fuel tank instead, I have to lose some fuel to stay within 18 tons anyway).
  6. As far as I can tell, it primarily seems to be a drag issue: the service bay has very high drag, which is what's causing the craft to flip by creating torque the moment the drag vector is not going exactly through the CoM (ie. the moment you are not pointed perfectly retrograde, assuming a perfectly symmetrical weight distribution in your craft). The higher the AoA becomes (ie. the further away from perfectly retrograde you are pointing), the further away the vector is pointing from the CoM, which means the greater the torque. The moment this happens, the low-drag front and the high-drag back are now both pointed into the airstream but since the drag distribution is asymmetric (one side has more drag than the other), the high-drag back (ie. the service bay) creates more torque than the low-drag front (ie. the command pod), resulting in the craft orienting itself to point the high-drag side backwards and the low-drag side forwards (ie. prograde) to reach dynamic equilibrium (ie. where any deviation in heading causes the service bay's drag to counteract and force the craft back to pointing perfectly forward), unless something like SAS or aerodynamic stability via fins/winglets is actively holding against it. Someone likened the relevant physics to a badminton ball: no matter what orientation you throw it in, it will immediately reorient itself into pointy end forward and finned end backwards because that's when drag is the lowest. Attaching a heat shield helps because the heat shield has lower drag than the service bay, but it's not a perfect solution, it merely decreases the torque to the point where SAS can handle it at low AoA, but it will still flip without SAS actively holding against it because even at 69 km altitude and even if your deviation from prograde is less than 1°, the torque is still non-zero. Attaching more weight to the bottom helps by moving the CoM downwards and further away from the CoL, with the resulting aerodynamic stabilization partially or entirely counteracting the drag torque. Of course, this makes the top stage heavier, which in turn reduces dV at launch. A different solution would be to deliberately create drag at the top of the command pod to stabilize it. Of course, this runs into the issues of 1) those parts burning off and 2) the front of the rocket having higher drag means the drag will now want to flip your rocket at takeoff instead, unless you have enough fins. I ran into this second problem while building a munar lander: by mounting four FL-T100 tanks (with nosecones on both ends) to the transfer stage radially instead of centered in order to reduce the rocket's height for less flexing when steering, those tanks create enough drag that flying more than 10° off prograde causes the rocket to flip as soon as the SRBs are dropped, despite being aerodynamically stable (ie. CoM in front of CoL). Doesn't appear to be related at first, but is actually the exact same problem: aerodynamic drag creating too much torque for SAS to compensate for.
  7. Today I finally put my shiny new fairing to use by deploying relay satellites to the Mun (and had to build a new launcher for them as well, since even the weakest one I had was overpowered for something as light as a satellite). I had to strap on a second fuel tank to give the sats enough dV to reach their target orbit without a transfer stage or leaving junk in orbit, but in the end, I was kinda-sorta successful. Two sats were properly deployed into semi-synchronous orbit, but the third required some tedium because it arrived to the Mun too close to the orbital position of the second sat, which would've left too big of a gap between the third and the first. So I put the third on a 1797 km x 300 km orbit to get into position down the line, then jumped back to the KSC to launch Bob's next landing mission in the Explorer-2, which also served as a range test for the new sats. I did some calculations which said that two HG-5 antennas had the combined range to reach a Communotron on the munar surface from semi-synchronous orbit, which I proved true. Well, sorta: at 40 km altitude, the Communotron had an 8% signal strength which, considering the relay was over 1800 km away at its current orbital position, was pretty nice. Of course, it's worth mentioning that the Explorer-2 has three Communotrons, the combined strength of which versus the combined strength of the relay's twin HG-5s resulted in a signal strength in the low fifties. I targeted the northwest crater as a landing site this time and although I landed safely on the first try, I lost too much dV with a slow descent and ended up stuck in low munar orbit about 140 m/s short of getting back to Kerbin. I tried getting out and pushing with Bob, but I realized I simply didn't have the patience. Then I remembered that I popped a quicksave before the deorbit burn, so I reloaded that and went with a different descent profile: above the target area, I killed my horizontal velocity completely, then turned downwards and descended with a series of T-5 second suicide burns, only switching to a continuous slow descent about 400 meters up. That did the trick and even with me only circularizing at 11 km altitude, I only got back to Kerbin with about 50-something m/s left, which is far too close for comfort. Also, the 43 km periapse reentry turned out to be too shallow, as I burned off all my ablator and bounced back out to an apoapse of 300 km before reentering for real. Luckily, the heatshield was up for the job even without ablator. That being said, reentry was still a bit unnerving because without the OKTO core being able to hold retrograde, Bob had to constantly keep fighting against the heatshield's drag wanting to flip the craft to maintain low AoA to keep the materials bay in the middle of the craft from overheating and tearing out not just the entire science payload, but the OKTO as well. Still, I got about 40 science out of this trip and seeing as I'm at 49 right now, the next trip should unlock me another science node. I think I'll probably take the lander can next so that Jeb can help out with reentry stabilization. At this rate, I'll unlock the entirety of tech tier 5 on the Mun which, coupled with the science I'll get from Minmus, will open up options for me to start planning a probe launch to Duna. Note to self: add more ablator to the Explorer-2. 60 isn't enough, 80 should do the trick, possibly 100 if we factor in a Minmus mission in the future.
  8. Tried out my new heavy booster for a crewed munar landing. I staged it so that the SRBs and the Reliant fire together, the Swivels fire when I drop the SRBs. It leaves the ground very laboriously (1.3 TWR) because the SRBs and the Reliant simply can't lift any more but once it's in the air, it burns for about two minutes straight at full throttle, imparting a nice 3100+ m/s to the lander and the transfer stage. I'm still struggling with the ascent profile because most of my takeoffs with it resulted in me flying practically horizontally at 35k altitude, about 20-25° off prograde, getting a excrementston of drag to the point that overheat bars started showing up on the antennas at the top of the lander. But if I turn any slower, I overshoot my target altitude. Anyway, Jeb tested the prototype personally to visually survey the monolith anomaly that was found several weeks beforehand by a lucky probe and it was quite the comedy of errors: The lander's engine was throttled back far too much (13.5%) and he had to manually bump it up quite a lot (60%) to be able to kill his horizontal velocity before hitting the ground. He only noticed in the middle of the pre-takeoff checklist on the munar surface that the engineers who assembled the lander forgot to put any ablator on the heatshield. For this reason, he used a quite shallow (45 km periapse) reentry that was slow, but safe enough that the heatshield never went beyond 71% capacity. He was literally seconds away from reentering Kerbin's atmosphere when he realized the engineers also forgot to set the flight computer to auto-hibernate and the command pod's batteries to reserve mode, causing the lander to deplete all power by the time it reached Kerbin due to the solar panels being mounted on the top of the command pod to shield them from reentry but the pod facing away from Kerbol during its entire journey back to Kerbin after finishing its return burn at the Mun. I actually had to cheat for this one, as the lander was already inside Kerbin's atmosphere by the time I noticed the problem, so I didn't have time to get out and push to turn the solar panels towards the sun. Once the irresponsible engineers were smacked about a bit and the problems corrected, Bob took the next flight to the Mun and, thanks to crafty use of available storage space for experiment data (one copy transmitted, second copy stored in the pod, third copy stored in the experiment storage module and a fourth copy left in the instrument, where applicable) returned with about 30 science (which, since I'm running a 10% science game, is actually equivalent to 300 in a stock game) which, due to Jeb's earlier trip, yielded just enough data to develop fairings for launching the planned munar satellite relay network so that missions can be expanded to the far side of the Mun as well. ...and when I brought up the satellite subassembly to slap on a second HG-5 so that it can reach the munar surface from a decent range, I tossed the fairing aside to gain access, tried to move one of three symmetry-mounted solar panels... not only the game didn't remove the other two, I couldn't drop the one I was holding either, nor could I exit the VAB, while the game was rapid-firing nullpointer errors in the console. NullReferenceException: Object reference not set to an instance of an object at ModuleProceduralFairing.onInterstageDetach () [0x00000] in <filename unknown>:0 at (wrapper delegate-invoke) Callback:invoke_void__this__ () at (wrapper delegate-invoke) Callback:invoke_void__this__ () at Part.onDetach (Boolean first) [0x00000] in <filename unknown>:0 at EditorLogic.detachPart (.Part part) [0x00000] in <filename unknown>:0 at EditorLogic.deleteSymmetryParts () [0x00000] in <filename unknown>:0 at EditorLogic.<SetupFSM>m__D () [0x00000] in <filename unknown>:0 at (wrapper delegate-invoke) Callback:invoke_void__this__ () at (wrapper delegate-invoke) Callback:invoke_void__this__ () at (wrapper delegate-invoke) Callback:invoke_void__this__ () at KerbalFSM.UpdateFSM () [0x00000] in <filename unknown>:0 at EditorLogic.Update () [0x00000] in <filename unknown>:0 So much for putting that sucker inside a fairing. I had to Alt-Tab out and kill the executable manually.
  9. Unfortunately, it got overwritten when I did another session yesterday after posting this. That being said, I didn't encounter it again after having uninstalled BetterCrewAssignment and Configurable Containers, so one of those could've been the culprit. Especially since CKAN says Configurable Containers wasn't even updated since KSP 1.4.5. ...and indeed, someone already reported the exact same thing in CC's thread. So I guess we've got the culprit. I'll be taking this issue to that thread.
  10. @allista, I've encountered the same bug @siderr reported back in October. Here's some additional information (sadly, my output_log.txt got overwritten in the meantime). Exiting and reentering the VAB didn't fix it. Hope this helps in splatting this bug down the line. Uninstalling the addon fixed it and since @siderr reported the exact same issue and I didn't have any other addons installed that mess with part resources, I'm guessing Configurable Containers is the culprit.
  11. In the past few days, I noticed the following issues: occasionally when trying to radially attach a part in the VAB, it simply stops working beyond 2x symmetry. That is, no symmetry, mirror and 2x radial work properly but at 3x radial and above, the ghosted preview of the parts does not appear, no parts get placed when clicking and the framerate chugs down. It happens both when the part itself is being radially attached and when the part is being attached via node to a radially attached part. About half an hour ago, it happened again, but only to fuel tanks. Landing legs worked fine even at 12x radial, but whenever I picked up a fuel tank and hovered it near another part for radial attachment, no ghost, no placement and framerate tanked. Alt-clicking to copy a placed part also stopped working. Yet if I mount said fuel tank on a radial decoupler, grab the decoupler and increase symmetry level, it works just fine! Console window showed ArgumentOutOfRangeException spam sandwiched between rapid-fire "ship changed, auto-updating my stuff" log entries from ShipSections and BetterCrewAssignment, which also appears in output_log.txt with the following stack trace: Exiting and reentering the VAB didn't fix it. I don't think it's ShipSections or BetterCrewAssignment acting up since as far as I know, neither of those mods touch part resources. The only mods I have that do are Kerbal Engineer and Configurable Containers. But just to be safe, I'm dumping BetterCrewAssignment and Configurable Containers since I'm not using them anyway.
  12. Hey, I'd be happy if the modders would just stop putting MiniAVC into the CKAN releases of their stuff. Putting it in the standalone release is fine and makes sense, but CKAN already does the version checking and won't even let you install an incompatible release in the first place unless you go out of your way to allow it, so not only is MiniAVC redundant in the CKAN release, but 99% of the time a pointless annoyance as well due to the mod working just fine despite the constant demands to downgrade my KSP version.
  13. Funny thing is, when I unlocked the science node, I originally intended to use the Spark instead and keep the Ant for satellites only due to not liking its looks, but I changed my mind when I realized that the Spark is still overpowered for a probe lander.
  14. Used the Ant engine for the first time today for a munar lander probe (OKTO, Oscar-B tank, engine, three landing legs, three Communotrons, three solar panels and science gear). Definitely liking it so far, especially due to the fact that although my previous probe design used a Terrier set to 15% output, I still had to dial the thrust down almost completely all the time to not decelerate too fast. So something as anemic as the Ant is definitely more my speed here. In fact, I dumped a few hundred m/s from the transfer stage because the probe was so much lighter with the new engine that it would be halfway through the descent from munar orbit by the time the transfer stage ran out of fuel. I do need to send a few relay sats up to the Mun, though, so that I can probe the far side. For that, I'm planning a quite unusual design for an OKTO-controlled hauler using Thuds instead of a Terrier so that I can mount the cargo to the bottom of the hauler. So the hauler is on top, the payload is in the middle and the booster is on the bottom. Launch profile is takeoff, use booster to go suborbital and get as close to orbital as possible, then use the hauler to get the payload to its intended orbit, decouple the payload, then turn around and go home. Thing is, Thuds are nowhere near efficient enough for that role, with the biggest tank I have only giving them 1k dV without the payload. At the end of my session, I figured I have some time to experiment and decided what the hell, might as well screw around a bit with building a Space Shuttle-style glider radially attached to a booster comprised of a Reliant and two Swivels, all on the same stage, followed by the glider's own Terrier as second stage. It... didn't quite go well. Aside from the fact that the whole thing rolls onto its back on the launchpad (which only needs Launch Stabilizers fix), it's extremely hard to maintain pitch while going slow and once it's going fast - as in, Mach 3 fast -, attempting to pitch up caused it to spin at something like 100 RPM due to the excessive control surface authority needed to take off without nosediving into the ground after a few hundred meters. Not to mention that it has neither the reaction wheel torque nor the battery capacity to maintain a nose-up position during reentry so as to not burn the Mk1 Cockpit up. But hey, even with it spinning like a top at the time of stage separation, it still made suborbital!
  15. I ran into this issue after the 1.5 update, whose changelog says they tweaked the geometry of some parts. I don't know what they did, but both the Illuminator Mk1 and the Mk2 have huge rightclick-detection boxes in the direction they are facing. Like, the game detects mouseover in a 45° angle reaching about 10 meters from the light. I built a probe with an FL-T100 tank, three lights on the top pointing downwards and a Terrier on the bottom, mounted on a transfer stage with an FL-T400 and another Terrier. The lights have rightclick-detection as far as the bottom of the transfer stage: Cursor is not visible due to Windows, but it's right next to the checkered-texture on that FL-T400 in the middle, nowhere near the light in question, yet you can see the light clearly highlighted for mouseover. I literally have to clip the camera inside the fuel tank to rightclick it rather than the light.
  16. Question, (probably) not bug-related. The check for a probe battery with EC flow disabled does not check the probe core's battery. That is, if I set an external battery to disabled, it satisfies the check but if I set the probe's own battery to disabled (since it's too little to be used as anything other than backup and is enough to turn the probe with reaction wheels to point fixed panels towards the sun), it still says there's no backup. Why?
  17. It's not the choice that's the problem here. I made the choice specifically because I didn't like how easy it is to get literally hundreds of points of science with minimal effort. I wanted the game to be long, where progress is a matter of effort, not choice. I do not regret 10% science whatsoever because the game feels meaningless if there is no effort behind it. The problem I'm having is that I've "fallen into a gap", so to speak, where I'm able to do what I want, just not how I want. I don't need an OKTO or an inline cockpit to land on the Mun, hell, I've pulled off Munar landings with even less tech before (a 100+ part monster of a rocket built entirely out of tech 3 or lower parts as an experiment at getting to the Mun without Terriers). I just want to do it that way but I can't because I ran out of science to collect halfway to the node I need. The problem isn't with the mission, it's with the mission profile: Kerbin Explorer 1/A: manned orbiter, no landing. Kerbin Explorer 1/B: manned orbiter, unmanned one-way lander. Kerbin Explorer 2/A: manned lander with no orbiter component. Kerbin Explorer 2/B: manned lander, unmanned orbiter with relay antenna. Phase 1 is complete, phase 2 is where I'm stumped at. I can do phase 3 with the tech I have right now and phase 1 has enough range to reach Minmus and gather science there for phase 2, but I'd like to do phase 2 at the Mun first if at all possible.
  18. Forgot to mention this in my above rant. Why are the big, high-payoff experiments given to the player before the low-payoff ones? It reduces the incentive of even bothering with the latter. It should be the other way around: simple stuff like thermometer, barometer and seismometer coming first, then the goo canister and materials bay later on so that the player's science payoffs increase alongside the costs of later nodes. Small cost, small reward; bigger cost, bigger reward.
  19. Two FAT wings, one 1.25 tank and two 0.75 tanks caused landing gear bouncing from overstress before 1.5. If you want to decrease weight by ditching the 1.25 tank for a Structural Fuselage and putting the fuel in multiple 0.75 tanks, you have to research another node which means another several hours of grinding in a low-Science game and would cost you enough points to put you halfway towards a node on the next tier. It's simply not worth it.
  20. Agreed on that part. I'm currently running a 10% Science game and got stumped where I got literally all science I could out of Kerbin, including the KSC mini-biomes (which alone took hours due to the extremely glitchy biome detection), as well as Mun orbit, and I'm currently stuck not being able to build a lander I want. That is, I don't want to include instruments that require a reset without bringing a scientist along, but I'm 41.5 points short of getting inline lander cockpits or the OKTO. I could go to Minmus and get the science from there, but I want to do everything in order and it feels sequence-breaking to go to Minmus orbit before Mun orbit. Another option I'm considering is using a manned pod to haul a Stayputnik to munar orbit, decouple (since I don't have docking rings or stack separators yet, the probe's engine will have to blast the decoupler away) and attempt a highly inefficient manual landing (the last time I tried a fully unmanned Stayputnik launch to the Mun, I ran out of fuel before even completing the transfer burn despite having packed nearly 6000 dV). The KSC mini-biomes are the only reason I even got this far. Because if I hadn't gone grinding, I'd be two or three nodes short of where I am right now and would've had to choose between developing aircraft and sweating getting to the Mun, or developing Mun travel and trying to hit Kerbin biomes with suborbital launches. In any case, what I think would definitely help in reducing the grinding of the early game of a low-Science game is zeroing out the KSC mini-biomes but increasing Kerbin's multiplier so that Kerbin as a whole still gives the same amount of science. Yes. This. What we need is not a longer tech tree with more nodes per branch, but a wider tech tree with more branches. Some things are not very intuitive: fuel and rocket engines get their own nodes, but science instruments, solar panels and probe cores are all jammed together? What does a barometer have to do with safe landings? Why is the Stayputnik only unlocked at a point where the player no longer has any use for it? A related problem is nodes that unlock too many parts, including stuff the player is never going to use. A good example of this are the FAT airplane wing parts, which are unlocked alongside regular wings but nobody uses them due to their incompatibility with elevons and being too heavy for the landing gears that get unlocked alongside them. By the time you have gears that can actually hold their weight for more than short hops, you have better wing parts. When a part is only practical at the point where you no longer need it, there's something wrong there. I mean, I could put the Stayputnik to the Start node, but it won't do any good without a reaction wheel and a battery, now would it? I agree with this as well. Been thinking about something in this regard a while ago: simple experiments (temperature, barometer, crew report, EVA report) should transmit for 100%, the rest should remain lossy BUT the loss rate should decrease as the Tracking Station and the R&D Facility get upgraded (due to increased reception gain and better data encoding/compression, respectively). Additionally, for repeatable experiments (ie. those that must be run multiple times per biome to get all science out of it) except surface samples, I'd make it so that even if you return the data instead of transmitting it, you only get the full result if the instrument comes back as well. That is, if you run a goo experiment, take the data out of the goo canister, put it in a command pod or experiment storage unit and only return the data, you don't get all the science from it. You don't lose as much as if you had transmitted it, but you still lose something. But if you bring the goo canister back to Kerbin and recover it, you get full science from it, no deduction. This way the player is encouraged to try and bring those expensive instruments back home, which becomes tricky with materials bays due to their reentry characteristics. Again, this does not apply to surface samples which of course have no instruments to bring home. And this loss rate too would decrease as the R&D Facility gets upgraded.
  21. Bug. The button doesn't seem to properly deregister when exiting the VAB/SPH or something. linuxgurugamer has known about it for months (because I've been bothering him about it) but seeing that he's got a helluva lot of mods to update for 1.5, I don't think this'll be high-priority for him for a while. It's specific to the stock toolbar; if you switch to Blizzy, it only appears when it should be appearing.
  22. Did so, problem didn't go away. Start game without EER, enter main menu, no button. Load any savegame, button is now present in every single screen with the stock toolbar and clicking it anywhere other than the VAB/SPH throws a nullref in the console. If I switch the button from the stock toolbar to Blizzy, the button is now properly displayed only in the VAB/SPH and nowhere else, so the problem is specific to the stock toolbar. I'd post the entire output_log here but the forum threw up an internal error when I tried.
  23. Redacted. problem is back. When I start the game, the button is not yet in the main menu - but after I load up a savegame and subsequently exit back to the main menu, it's now there and clicking it throws a nullref exception. Found this in KSP.log: [ERR 01:24:08.250] ToolbarControl: WARNING: RegisterMod, LoadedScene: MAINMENU, called too late for: RCSBuildAid_NS, RCS Build Aid, button may not be registered properly And the nullref caused by clicking on the button in the main menu: [EXC 02:54:05.696] NullReferenceException RCSBuildAid.RCSBuildAid.SetActive (Boolean value) RCSBuildAid.AppLauncher.onFalse () ToolbarControl_NS.ToolbarControl.SetButtonInactive () ToolbarControl_NS.ToolbarControl.doOnFalse () KSP.UI.Screens.ApplicationLauncherButton.OnFalse (UnityEngine.EventSystems.PointerEventData data, CallType callType) UnityEngine.Events.InvokableCall`2[UnityEngine.EventSystems.PointerEventData,KSP.UI.UIRadioButton+CallType].Invoke (UnityEngine.EventSystems.PointerEventData args0, CallType args1) UnityEngine.Events.UnityEvent`2[UnityEngine.EventSystems.PointerEventData,KSP.UI.UIRadioButton+CallType].Invoke (UnityEngine.EventSystems.PointerEventData arg0, CallType arg1) KSP.UI.UIRadioButton.SetState (State state, CallType callType, UnityEngine.EventSystems.PointerEventData data, Boolean popButtonsInGroup) KSP.UI.UIRadioButton.ToggleState (CallType callType, UnityEngine.EventSystems.PointerEventData data) KSP.UI.UIRadioButton.UnityEngine.EventSystems.IPointerClickHandler.OnPointerClick (UnityEngine.EventSystems.PointerEventData eventData) UnityEngine.EventSystems.ExecuteEvents.Execute (IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData eventData) UnityEngine.EventSystems.ExecuteEvents.Execute[IPointerClickHandler] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.EventFunction`1 functor) UnityEngine.EventSystems.EventSystem:Update() However. The problem might actually be caused by Ship Sections, as I found this at every single scene change: [ERR 02:46:53.309] Exception handling event onGUIApplicationLauncherReady in class SectionNameUI:System.NullReferenceException: at (wrapper managed-to-native) UnityEngine.Component:get_gameObject () at JKorTech.ShipSections.SectionNameUI.OnAppLauncherReady () [0x00000] in <filename unknown>:0 at EventVoid.Fire () [0x00000] in <filename unknown>:0 [EXC 02:46:53.310] NullReferenceException JKorTech.ShipSections.SectionNameUI.OnAppLauncherReady () EventVoid.Fire () UnityEngine.Debug:LogException(Exception) EventVoid:Fire() KSP.UI.Screens.ApplicationLauncher:StartupSequence() KSP.UI.Screens.ApplicationLauncher:OnSceneLoadedGUIReady(GameScenes) EventData`1:Fire(GameScenes) <FireLoadedEventGUIReady>c__Iterator2:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) [ERR 02:46:53.310] Exception handling event onGUIApplicationLauncherReady in class SectionNameUI:System.NullReferenceException: at (wrapper managed-to-native) UnityEngine.Component:get_gameObject () at JKorTech.ShipSections.SectionNameUI.OnAppLauncherReady () [0x00000] in <filename unknown>:0 at EventVoid.Fire () [0x00000] in <filename unknown>:0 [EXC 02:46:53.311] NullReferenceException JKorTech.ShipSections.SectionNameUI.OnAppLauncherReady () EventVoid.Fire () UnityEngine.Debug:LogException(Exception) EventVoid:Fire() KSP.UI.Screens.ApplicationLauncher:StartupSequence() KSP.UI.Screens.ApplicationLauncher:OnSceneLoadedGUIReady(GameScenes) EventData`1:Fire(GameScenes) <FireLoadedEventGUIReady>c__Iterator2:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) [ERR 02:46:53.311] Exception handling event onGUIApplicationLauncherReady in class SectionNameUI:System.NullReferenceException: at (wrapper managed-to-native) UnityEngine.Component:get_gameObject () at JKorTech.ShipSections.SectionNameUI.OnAppLauncherReady () [0x00000] in <filename unknown>:0 at EventVoid.Fire () [0x00000] in <filename unknown>:0 [EXC 02:46:53.312] NullReferenceException JKorTech.ShipSections.SectionNameUI.OnAppLauncherReady () EventVoid.Fire () UnityEngine.Debug:LogException(Exception) EventVoid:Fire() KSP.UI.Screens.ApplicationLauncher:StartupSequence() KSP.UI.Screens.ApplicationLauncher:OnSceneLoadedGUIReady(GameScenes) EventData`1:Fire(GameScenes) <FireLoadedEventGUIReady>c__Iterator2:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) My guess is that whatever UI function handles toolbar button registering/deregistering calls Ship Sections before RCS Build Aid, Ship Sections throws an exception that isn't caught and goes up the stack, which breaks out of the UI function before RCS Build Aid gets its turn, causing RCS Build Aid's button to not be properly deregistered/disposed. Mind you, I don't know how Unity works internally, I'm just guessing here as a fellow software dev who works with C# on a daily basis.
  24. If you mean the two dark rectangles on top, those are actually radial chutes offseted into the main body. I don't know if this reduces drag or not, but I'm doing it anyway on the off chance that it does and because it looks more aesthetically pleasing. 5 parts are inside the bay: one thermo, one baro, three goos. I'm forced to use the swept wing for lift and the tail fins for pitch/roll because I don't have the part count for elevons.
  25. This plane is designed to be able to reach both the poles and the badlands from the KSC; haven't yet visited the badlands, but the edge of the polar icecaps, it can reach in about an hour with about 30% fuel left, by which point it can parachute down safely (I'm at low-transsonic speed and 4x warp for nearly the entire flight but drop back to 1x whenever I'm nearing 10° pitch from SAS not following Kerbin's curvature so that I can nose down manually to maintain speed and go back to 4x warp once my altitude has stabilized to get to my destination in a timely manner because Junos are indeed kinda anemic at 10k altitude). So no, I don't need that much fuel. I just didn't want to waste fuel tank capacity and can't mount the Junos and their intakes elsewhere. Dropping the Mk1 tank for several Mk0 tanks is an idea, but I'm deliberately trying to stay within 30 parts and have already hit the limit.