Newnard

@ShotgunNinja Thank you very much for the prompt reply!

I was just setting up a mod list for 1.1 and being disappointed that TAC life support isn't updated yet, but this looks fascinating and I would like to try it out! My current mod list includes Kerbal Engineer Redux Better Burn Time Contract Configurator KerbinSpaceStation contract pack KFiles contract pack Remotetech contract pack Tourism contract pack Environmental Visual Enhancements NRAP test weights RemoteTech Waypoint Manager ...and of course ModuleManager and KSP-AVC. Am I correct in understanding that the only incompatible mods on my list are RemoteTech and the associated contract pack? Also: I'm not familiar with the Unlicense; could you provide a link to where I could read it?

Thank you for that information. It makes me sad.

Nope to your nope. Richfiles was absolutely correct, multithreading and 64 bit support are separate features. They both happen to be enhancements in Unity 5, but that doesn't mean they are the same thing.

The desire to make revenue from a product that they have worked so hard on for years is completely understandable. In my humble opinion, that is not sufficient excuse for allowing a third party to implement DRM in an otherwise wonderful software product. See http://www.defectivebydesign.org/ for more information. My cynicism was directed at KerbalEDU, not Squad. So hopefully it was well placed, but I apologize anyway. It's the scenario editor that is fascinating to me, and the reason I wish I could try it out. I imagine all sorts of interesting applications, from the obvious teaching applications that it was designed for, to creation and distribution of puzzles and challenges for people to solve, etc. Alas, while I have been known to occasionally purchase DRM-encumbered software (if the DRM is gently implemented, and the benefit of the software is great) this isn't a situation that I can justify to myself. I do plan to try some similar activities at some point using something like hyperedit to set up scenarios and then just packaging up the .sfs files. But I imagine a bit more engineering than that went into the KerbalEDU stuff, and it's just sad to waste that engineering by contaminating it with DRM. ;-)

The most major difference that I am aware of is that while normal KSP is cheerfully DRM-free, KerbalEDU has horrible oppressive DRM that trusts you no further than it can throw you (hint: it can't throw you). In my more cynical moments I believe that any other additional features in KerbalEDU are just smokescreen to justify the inclusion of the DRM.

No, it hasn't opened YET.

You did read the rest of that statement, right? "An Experimental Testing phase typically lasts around a couple of weeks, though it is highly dependent on the number of issues that arise and how much further development is required to reach a release state." Go play No Man's Sky if you must. I'll be happily playing KSP 1.0.5.

I just raised a github issue [18] because of an odd event that I experienced where a contract completed that shouldn't have completed, the vessel that completed the contract didn't even have a dish capable of doing it. The github issue (and this post) is sparse on details because I'm ignorant about what information could be used to track down the problem, but I'm willing to provide any data/screenshots/logfiles that are requested -- just point me in the right direction.

Thanks AeroGav for the education, and apologies to all for suggesting intake spam.

Thanks FancyMouse! And thanks 5thHorseman! This bit about the fast-forward algorithm was completely unexpected. I note that FancyMouse and 5thHorseman seem to disagree on whether the drill or the ISRU converter is a more likely bottleneck, but that is really a side effect of 5thHorseman factoring in engineer skill I think.

This is an ISRU factory I'm planning on sending to Minmus. It has: 1x Drill-o-matic (the 1.25 ton version, not the Jr.) 1x Convert-o-Tron 125 (the smaller one, because it balances nicely weight-wise with the drill) 8x radial ore tanks (at 75 ore per tank, total capacity 600 ore) 2x Thermal Control System (medium) 4x Radiator Panel (large) about 4.5k electric charge capacity 8x gigantor solar panels. I'm using some mods, but most of them hopefully aren't relevant to this question -- exception might be TAC life support because the kerbals need electric charge to stay alive. The complete list is: Chatterer - 0.9.7.86 Contract Configurator - 1.9.6 Contract Pack: The K Files - 1.1.1 Contract Pack: RemoteTech - 2.0.1 Contract Pack: Tourism Plus - 1.4 Kerbal Attachment System - 0.5.5 Kerbal Engineer Redux - 1.0.19.4 Kerbal Inventory System - 1.2.5 KSP-AVC Plugin - 1.1.5 Final Frontier - 0.9.8.1882 RCS Build Aid - 0.7.7 RemoteTech - 1.6.9 SmartParts - 1.6.6 TAC Life Support - 0.11.2.1 Kerbal Alarm Clock - 3.5 TweakScale - 2.2.6 Waypoint Manager - 2.4.5 So here are the actual questions: If I'm planning on running the drill and the convert-o-tron pretty much continuously until the LFO tanks are full... Which processes ore faster, the drill producing the ore, or the convert-o-tron 125 turning it into fuel? In other words will my ore tanks fill up because the drill is faster, or empty out because the convert-o-tron is faster? If my ore tanks fill up, will the drill shut down? If so will it start back up when some space becomes available? If my ore tanks empty, will the convert-o-tron stop working, or simply wait for more ore to be put in the tanks? I know the answer to question 1 potentially depends on the abundance of ore at the dig site, but I'm looking for a general answer based on people's typical experiences. This is my first attempt at using the stock ISRU system, I don't want to waste funds and time sending a mission that has no chance of working, and for mental health reasons I don't want to start up a separate sandbox to test this out for free first. Thanks in advance for any replies. Hints regarding electric charge and heat dissipation would also be very welcome.

Do your engines actually flame out? Because as you go higher up, your air intakes get less efficient and you might be starving the engines for intake air. Spamming more and bigger air intakes onto your craft wherever they fit sometimes helps with that particular issue.

The availability of those buttons depends on the skill level of your pilot, OR the technology level of your probe core if it is an unmanned flight, OR whichever is best if you have multiple pilots or probe cores or some of each. Note that only pilots get that ability, so if your vessel contains only scientists and engineers (and no probe core) you won't have access to that feature. Beginning level pilots can only activate stability assist, holding the current course but no prograde/radial/normal/target buttons. Then as the pilot levels up, they get access to one additional set of buttons at each experience level -- prograde/retrograde at first. Not sure which order radial/normal arrive in, and then the target buttons are the last ones to be awarded. As for probe cores, you can see which abilities they provide by looking at their entry on the tech tree, on the right hand side where it lists the attributes of the probe core it will say "SAS" followed by a list of which buttons will be activated by that probe core, for example "stability assist", "prograde/retrograde", etc.

Both the hierarchy window and the messages regarding pushing and popping, and the null reference exceptions, are all feedback intended for the developer of the mod that is causing the errors. There is nothing a normal user can do with them aside from report them to the appropriate mod author. If all was working prior to the installation of your most recent mod, then that mod may be the culprit and you should find the development thread for that mod in the forums and report the bug there.

Awesome! Just as trivia, I think a .version file is useful even if it's just in the package and not online anywhere -- not AS useful, granted, but it still allows AVC to register the mod in the list of mods and let you know when you update KSP that you are still using an old version of the mod, etc.

Thanks for the excellent mod! Feature request: Could you add a .version file so that this mod works with KSP-AVC?

Remember to update the .version file -- looks like the version I have is one you updated for 1.0.5, but KSP-AVC still says it's for 1.0.4. Thanks for all your awesome mods!

igor_perusco, thanks for the information! Verios44, see igor's answer just above your question.

Just a minor bug report: I installed this mod, but then decided I didn't want it active for this particular (newly started, zero flights in progress) save game. I clicked to disable it and it gave me the warning about flights in progress, and at the bottom of that window it said I had -1 flights going. Also I think your .version file hasn't been updated properly; AVC is reporting that the mod was designed to work with an earlier version of KSP but you specifically said in your post above that it's set up for 1.0.5

Is this (Smart Parts 1.6.6) likely to work on 1.0.5? I'm willing to be a lab rat and try it out, but if someone else already knows for sure that would be helpful information.

Thanks Snark, that's perfect and exactly what I needed. I also just found this one which is similarly useful: http://forum.kerbalspaceprogram.com/threads/119620-Care-and-Feeding-of-your-MPL-LG-2-Mobile-Processing-Lab-in-1-0-How-to-be-a-science-farmer -- in case anyone wanted to read more.

As Snark says, the Alt key is the complete solution for that problem. But as trivia, I can generally place docking ports snapped to the node without using Alt by simply viewing the stack from the side while placing the port, rather than looking down on the node from the top. Your mileage may vary.

One thing I'm a little confused about is if labs consume or duplicate science. For example, if I'm on minmus with a lab and a mystery goo canister, and I want to study the goo in the lab but also return the data to kerbin, is the sequence basically: 1) Observe goo. 2) Put data in lab. 3) Reset goo and observe again. 4) Take second set of data to kerbin, while lab studies first set. Or is it more like this 1) Observe goo. 2) Load goo data into lab, retaining a copy. 3) Return goo data to kerbin, while lab continues to work on it. To be clear, in my example the lab stays on minmus.

Well, my guess would be that a lot of people are in my boat; I had heard of KSP a few times, but I didn't really learn about it or buy it until it launched on Steam, which was version .19 (well, I think .19.1 but that's not on the poll). Steam launch was March 21, 2013. I bought it the next day. Registered a forum account several days after that. Forum account got wiped in the big snafu less than a month later. Didn't bother re-registering for quite some time.