BudgetHedgehog

Just a little heads up - although this changes the stock IVA navball, RPM navballs remain the same. That is located in GameData\JSI\RasterPropMonitor\Example\ExampleMFD\PFD\NavBall000.png, if that helps. It'd be nice for it to automatically switch but seeing as you can just replace that RPM navball file with any other png, it's no harder than the stock method. But yeah, if you really want to, it might be nice to have RPM support

Would you mind showing pictures of this? Because I successfully escaped a launch with a TWR of over 8 with no ill effects - yes, the pod din't exactly go up, but the sideways force was more than enough to get it out of harms way so there was no problems. A launch TWR of 8 is very extreme and a worst case scenario, but it still managed to escape successfully. Not sure why you think there is a bug, is all.

Ok, so MOARdV has stated that a toolbar-compatible SCANsatRPM dll isn't entirely feasible right now: So my best guess would be for either danmy to come back already, or for someone else to take it over and make SCANsat Continued (with danmy's permission, of course). Users of the "official" SCANsat would need to be notified of the new release either way.. but then, it's no more than they would normally do to check for updates to their mods - check the forum threads. So... where do we go from here? If the people who have successfully recompiled the dll to fix this are willing to share it, do we have an "community hotfix for toolbar integration" of sorts? Or do we wait for danmy to come back and tell us what we can do?

Toadicus of TweakableEverything fame has made it so you can enable/disable sun tracking for solar panels in TE.. If anyone knows where the sun tracking bit of the panels is located, it'll be him I reckon.

Jesus Christ, those are beautiful.. I waaaaaaaant Apart from the Mun though. That looks a bit odd.. I think I'll get rid of that and keep the Distant Object Enhancer view of it.. in the pictures, it looks like it has an atmosphere :/

Well, if my skills at Module Manager config writings are correct, then yes - you'll get the option to do either experiment. FWIW, B9s science packages don't contain either the materials bay or mystery goo - just the various little sensors (barometer, thermometer, atmosphere sensor, seismic sensor) so you'd still need to include the materials bay in your designs somehow. It does cut down on part count though and is a lot easier to use than finding and clicking on all the separate sensors, so it's worth a look in any case.

In the science cfg (or whatever it is now, I have an older version. Which ever contains stuff about FN Seismic Probe Experiments and starts with @PART[sensorAccelerometer]. It'll be a cfg file you can open in a text editor), replace it with the following: @PART[sensorAccelerometer] { MODULE { name = FNSeismicProbe experimentID = FNSeismicProbeExperiment rerunnable = true deployEventName = Collect Impact Data reviewEventName = Review Impact Data resetEventName = Reset Impact Data } } That removes the bit that removes the original seismic scan. You should then get the stock experiment back.

Assuming my install of MJ is up todate, where is that target biome feature/overlay/landing biome info?

I see... Well, I'll see what we can do in the SCANsat thread. Thanks for the reply!

Your design isn't fine. The payload looks way to light to justify such a big rocket under it. Wat's your TWR at launch? I've never had a need for those big SRBs, not even with the heaviest 3m payload. If you're too over powered, no wonder its flipping, despite it being aerodynamic. Edit: ninja'd... Either way, your TWR should never really exceed 2.5 in atmosphere and should be at around 1.3 at launch. Any higher is not needed.

Had MechJeb throw more than a few NRE's just now. I think they may be connected to not being able to quickload or return to space center. Just in LKO preparing for a burn to the Mun, quicksaved and around then, this happened: [ERR 12:00:33.964] MechJeb module MechJebModuleMenu threw an exception in OnDestroy: System.NullReferenceException: Object reference not set to an instance of an object at MuMech.MechJebModuleMenu.OnDestroy () [0x00000] in <filename unknown>:0 at MuMech.MechJebCore.OnDestroy () [0x00000] in <filename unknown>:0

Forgive me for a silly suggestion, but why not ask Squad for help/pointers? They're the ones who changed the attachment rules (apparently, along with help from ferram) and everything - if anyone knows what changes were made and how they'd affect IR, it'd be the devs themselves.. Why not seek help from them? Just a little thought that's been going round my mind for a few days. EDIT: By Squad, I mean the makers and devs of KSP i.e. Harvester et al.

A separate solid fuel tank idea doesn't make much sense.. it's a solid, how can it transfer between tanks? I know this is a game and you can just set the resource flow mode to STACK_PRIORITY_SEARCH and transfer to PUMP, but you'd be making it do things that are impossible in real life. I know that most things in KSP are impossible in real life (and vice versa) but at a basic level, it has some degree of realism. Making a solid fuel transferable from a separate fuel tank is not something that's vaguely realistic. It's exactly the same if the solid fuel was wood - how would you get the wood from tank A into tank B? It just doesn't work.. It's completely possible with some cfg editing though. As I said, make solid fuel transferable and so that it searches the stack (exactly like liquid fuel) or ALL_VESSEL (like electric charge or the old monoprop) or STAGE_PRIORITY_FLOW (like the new monoprop) or whatever you want and make up a few tanks which contain the RESCOURCE - SolidFuel.

This is true, but thinking about it, have you considered TAC Fuel Balancer? It'll automatically help keep the CoM where you want it.

One solution is to balance them around the average CoM so it's neither balanced for full or empty tanks, but is a happy medium between the two.

I'm assuming so, but I've no idea what it means. And I thought it only right that they should be at least made aware of the problem, if only for reference.

*cough*he already included it*coughcough* Yes, it's GPL V3 (included in source code).

Hmm, well, it could be interesting... Couple of things - maybe this'd be better in the Add-On Development section? And why not chuck in a link to this thread in the Spaceport info box so people can find out more? Also, it's probably not a good idea to link directly to MJ #209 (honestly speaking, I wouldn't even link to Jenkins, but rather the forum thread) as it'll quickly be surpassed by newer versions (and indeed, already has been. I think we're up to #218?). If MechJeb is absolutely necessary to the craft (why? Honestly curious), then maybe talk to sarbian if it'd be ok to bundle it or something. But why is MJ needed in the first place? EDIT: Looks like it's just the AR202 box on the top. If you remove that, save the craft, then use that, everyone will be able to use it as it's just stock parts and this mod. So I downloaded this to check it out and immediately noticed the folder structure looks like (I think) what the old system used. Standard practice would be to have two folders in the zip - one Gamedata and one Ships. In the GameData, have a folder called Kerbal Electronics or Rofl47 or whatever, something that makes the folder yours. Then in that, I'd have the Parts and Flags folder you have. In the Ships folder, I'd put another one called VAB and then in that, your craft (might want to think about renaming too ). The way you have it set up makes it difficult if people want to look at/find/uninstall your parts after they've installed it. When people install this mod, it'll just be a simple case of merging the two GameData folders (the one in the KSP install and the one from the mod) so you'll want to be able to let people do that. Talking of the parts, I noticed they're basically stock parts with different parameters. Not sure what the stance is on redistributing Squads textures is, might be useful to know. Anyway, the RTG could be considered by some to be little excessive (1000 output rate and it weighs the same as the stock RTG which outputs 0.75?), the oxidiser tank is good idea (which is why KSPX includes one) but again, it uses the stock large radial tank texture. And the fuel line.. is just a fuel line. Not sure where you're going with that one but the idea of a reversed fuel line sounds intriguing. Please don't think I'm hating or whatever, I think it's great you had the initiative to make this pack and had the guts to upload it and everything, it's certainly not something I could do, so congratulations on your first mod and here's to a great future for Kerbal Electronics! EDIT: Oh, and *Incorporated EDITE THE SECONDE: To put an image into your post, put the link between [IMG] and tags. A nice picture is big, in daylight and where you can clearly see the relevant parts. Sometimes, a VAB shot is used thanks to the nice lighting. EDIT number 3: Also, I believe a license is needed for every mod uploaded here. Even if you don't need one, it's nice to know what we can do with your parts ourselves. From the rules:

http://forum.kerbalspaceprogram.com/threads/55832-PLUGIN-PARTS-0-23-SCANsat-terrain-mapping?p=1086970&viewfull=1#post1086970 DMagic has done a wonderful job with some little updates to the SCANsat mod, chiefly making it compatible with the Toolbar. However, for whatever reason, this breaks the RPM version of SCANsat. Would Mihara or MOARdV (or indeed anyone) like to help out? I figured you guys would be the best people to either help out or come up with a solution amenable to all

Ahh, I see it now... Didn't know about it and for some crafts, it was enabled.. also didn't know you can only set it in the VAB. Is it possible to change it in flight?

Is there away to disable the decoupler in the docking ports? I get that it's useful for LES and such like, but I don't use them and it's making rearranging the staging harder when I have all these decouplers listed. Thanks

Got the latest dev build?

In the target page, once you've selected the vessel you want to dock with, press Enter again and you can choose from the available docking ports there. Your screens might look different, but it's the same actions.

Even taking the plane change into account, it's only a couple hundred more m/s to get there from LKO but orbital insertion and landing both require less than on the Mun.