Clubbavich

I was able to successfully build the AutomatedScienceSampler from the source code, and it seems to be working just fine, certainly better than it was. I have absolutely no intentions of distributing the built binaries to anyone, simply because I didn't want to interfere with the release process of the rightful owners of the project. I just want to use this awesome addon . The AutomatedScienceSampler project is dependent upon this project: https://github.com/KerboKatz/KerboKatzUtilities I downloaded the latest build of that (from curse, but I should have looked in the releases folder on github first...), and added references to it in Visual Studio. After adding the other appropriate references from KSP listed in the thread below, and following the appropriate instructions (Set project target to dll, set .Net version to 3.5) I had no further issues building it. I never got the source of KerboKatzUtilities to build, but the up-to-date binaries work just fine.

Well, so far things aren't going well... The github source files don't seem to be in a state that's ready to build, entirely unrelated to the bug. The author is probably depending upon some Dev environment configuration files to fix things and doesn't realize it, and those files aren't making it to github. One example is that a mod that this depends on has the tooltip class files duplicated in different areas. I guess I'll just wait until we get that update. Edit: The AutomatedScienceSampler pull request is the only change that's needed. I was trying to build while referencing an older version of the KerboKatzUtilities without realizing it. The latest version of that dll works just fine, even though I can't build that portion myself.

There was a pull request submitted to the github of this project four days ago that fixes this issue, changing literally one line of code. Is anyone familiar with the process of building addons from their source? If I knew what tools I needed I would build the dll's from the source.

@FyunchClick That thread's intro: "Based on an idea born in another thread " The thread @Norcalplanner is referring to in the intro? It's this one! Norcalplanner helpfully posted some experiments in this thread, and then expanded upon it in a separate thread.

Are there any mods out there that track gravity losses and aero losses during ascent? Would be interesting to see so I could refine my designs based upon first-hand experimental results. It would probably make efficient ascents more instinctual as well. Would be nice to see an accumulated total of dV lost to gravity and drag, as well as an "instantaneous" output of how much loss there was in the last second.

Yes, the Offset Gizmo with snapping mode on will let you vertically align components accurately. It does take some time to get it right though. I do still wish for some more advanced symmetry options, but I'd prefer existing bugs to get squashed before new features have significant time spent on them.

I've wanted to go interplanetary in my current game, but Maneuver nodes aren't working properly for me for interplanetary maneuvers. They frequently disappear and delete themselves, or "drift". I've given up on it until those issues are fixed.

Before using any KAS/KIS parts or attachments, my Mun base certainly started sliding around, on a flat plain, with SAS off. I can't specifically recall if it started bouncing randomly before attaching KAS/KIS parts or not, but I'm leaning towards before... Really looking forward to the next round of bug-squishing. This and the problems with the new maneuver nodes/orbit lines are keeping me from playing.

Thanks Morse, I figured it was a stock bug. I tried to create my first maneuver node to just barely get me out of Kerbin's SOI, so I could create a second from Kerbol's SOI, but as soon as I created a node that took place after leaving Kerbin's SOI, I wasn't able to see my trajectory or second maneuver node. It just disappears. Since this is a stock KSP issue, this thread probably isn't the place to discuss it. If I need more advice, I'll go to a different thread for it. Thanks again for the advice.

This seems like a stock KSP problem, but it's an issue with maneuver nodes and I have this addon installed, so I thought I'd check here first... I'm trying to do my first interplanetary transfer, and I have a maneuver burn in about 8 days from a 100km orbit around Kerbin. I have another node in about 100 days for a plane change and final adjustment. But I'm having problems... the required delta-v keeps changing. If I add and remove 1m/s delta-v from either node--net 0 change--my predicted orbits change, and they change every time I make any change. It's really frustrating. Should I be waiting until my second burn to finalize adjustments? Is that a stock bug? Edit: Nevermind. Stock maneuver nodes are still a buggy mess. I'm finding something else to spend my time on.

I'm loving this mod, but I have one major issue with it, and one minor gripe. The major issue is that if I have multiple command modules (in this case, Mk1-2 Command Pod and an Mk2 Lander Can and a Hitchiker's module) then all of the science is getting put into the Mk1-2 pod (Which was the root of this vessel), even if it already has a copy of the experiment. The result is that with ForScience! enabled, I can only have one copy of any given experiment/biome/state on a vessel, the rest are destroyed. I would love for it to correctly use all Science Containers available. Also, when I docked with another vessel, it moved all of my experiments to one vessel. My minor gripe is that even with a scientist on board able to reset one-time experiments, that it doesn't run those as well. I was wrong. It does do that. I was just confused because I had multiple command modules on that vessel... Other than those two things, I'm absolutely loving this mod. Thank you for writing it.

I agree that there are other, more optimal options, but I wasn't intending to critique the OP's ships, I just wanted to point out a bug that very likely caused their problems. They didn't need to completely redesign their lander, they just need to make one small tweak and it would have been probably good enough for their purpose.

I think the problem with the OP's original design is that with 1.1, the landing legs are physically shorter. Shorter than they appear to be. They sink below the surface before they physically "land". The engine doesn't do that though... That craft was sitting on its engine. If it wasn't for that, it would have been fairly stable. To make those legs reach the ground past the poodle, the attachment point of the legs needs to extend past the bottom of the fuel tank if they are to actually work as expected. That was a rather annoying thing I learned first hand.... Easy to test, put just the lander out on the launch pad and see if the engine is touching the pad or not. If it's not, then you're good to go. If it is, the legs need to be lower.

The drills definitely heat up and become less efficient now, so cooling is necessary. On the Mun with about 8.2% ore concentrations, I found that two edge radiators on either side of each drill kept things at the right temp: http://wiki.kerbalspaceprogram.com/wiki/Radiator_Panel_%28edge%29 I made the radiators toggle using the same activation group as the drill toggle, so they both toggle on and off at the same time. Though, it would be nice to have a tool to calculate how much heat you need to handle. I'm not sure how all that stuff is calculated...

Something I would really like to see is a rolling persistent.sfs file, like you see with *nix logs. Current auto-save is persistent.sfs, previous one is persistent1.sfs, one prior to that is persistent2.sfs, etc... and have the file roll over only based upon time intervals, instead of a misc event triggering a new save. That would make things a LOT easier in multiple scenarios. Corrupted saves, forgetting to quicksave (probably most common), and it would possibly be a benefit in other scenarios as well.

I have 32GB, but I'm too newb to vote.

I recall reading somewhere that Fuel Cells don't run until battery power is below 95%, which means you can use them at night and solar panels during the day without needing to micromanage everything. That way, you don't need to bring enough batteries to last through the night, just enough so that there's a bit of a buffer. If the 95% thing is true, (i think it is, but I can't confirm it), then the most efficient setup would be to use both solar panels and fuel cells.