nightingale

Good stuff, although the one suggestion I would make is to hold off on the call to action for two weeks or so until the KSP 1.1 pre-release comes out - that will hopefully reduce the amount of re-work required from 1.1 changes (I don't imagine the changes between 1.1 pre-release and 1.1 full will be so significant to warrant waiting another two weeks on top of it).

Awesome, really glad to hear that Strategia is helping to remove the grind! Oh, and if you decide it's not what you wanted, you can always cancel the Duna Program... just make sure to read the fine print if you do.

I haven't been able to reproduce this one - can you provide some more info? Which biomes/Celestial Bodies, and which experiments are you running? If I could see a KSP.log and a save file I might be able to tell what's going on here.

Just FYI, the download link in your KSP-AVC version file is pointing to the ModularFlightIntegrator thread instead of this one.

I think the biggest problem is that KSP doesn't really have a true public API. Instead, we as modders have access to invoke pretty much anything in their code via the same internal API that Squad uses (ie. public class members, for those involved in the programming craft). This gives us enormous flexibility in modding, but it means that trying to document that would be an absolutely massive undertaking. I couldn't see a way in Visual Studio to count the number of classes that KSP has in 1.0.5, but by visual estimation its in the high hundreds, if not in the thousands. Each class will have anywhere between three or four functions to over a hundred. So documenting the whole thing (even if it wasn't a moving target) would easily mean looking at tens of thousands of different functions. Obviously, that's not a viable approach. So we probably need to narrow it down to the important ones. But who decides what's important? What's important to me (contract stuff, career stuff) doesn't intersect with what might be important to Thomas P. (Kopernicus dev). This overwhelming effort could be why the previous API documentation failed (although I don't really know, and @The_Duck hasn't been seen on the forums in close to a year, so it's possible they simply lost interest in KSP). Although the idea of a wiki sounds appealing, I'd be inclined to say the approach should be to fork that (warning: there's no license specified anywhere on the documentation project). The fork should be owned by an "organization" with multiple member in GitHub (so that it's not on one single person to deal with pull requests). Then we have to get people to contribute (I know I'd be more willing to contribute if I know that pull requests would be accepted more than once a year)! This is the case for C# as well for public/protected members. The problem is that the GameEvents.* accept a callback function, so the parameters don't actually get names. I know a little about this one because the addition of the ProtoVessel was in 1.0, and the addition of the bool was in 1.0.1 (both broke Contract Configurator). The hint as to what it is is from the 1.0.1 release notes: Science contracts and science World Firsts can no longer be triggered with science gained by reverse engineering recovered vessels. You have to transmit or recover an actual experiment. So the bool will be true if a vessel is being "reverse engineered", which it took me a long bit of experimenting to figure out is when KSP generates the list of experiments on the vessel for the vessel recovery dialog box. The ProtoVessel parameter is the vessel the science is coming from and I assume was added in 1.0 to support those world firsts contracts in some way (not 100% sure how). So yeah, you picked the perfect example to show the reason why getting this API documentation done as a community is both very difficult and very necessary. EDIT: I'm al lot less sure of my answer after @DMagic's ninja - I think I'll have to do some verification as it may mean I have a bug or two in the handling of science labs. EDIT2: Unstrikethrough.

@AdamMil - it's actually more difficult than you'd expect, which is one reason that type of functionality is not widely implemented. As severedsolo said, Contract Configurator gives all the contract modders the tools to implement contract failures. Associating a contract to a vessel is not trivial, but I know it's something that @inigma has been implementing in his GAP contract pack in the last couple releases (and there's at least one enhancement that is expected to make it into the next CC release that will help make that more vessel-specific). There's some things you could do that are fairly brute force with module manager: @CONTRACT_TYPE { PARAMETER { type = KerbalDeaths } } That will fail any/all CC contracts if you let a Kerbal die. Problem is that it doesn't distinguish in any way. The other problem is that KSP has no iron-man mode, and I believe that most players are pretty quick to revert/reload when things go wrong. So having contract failures becomes fairly meaningless to a big chunk of the player-base.

<== Does not understand CKAN sometimes.

No so much unclear, as I think you had a typo and said 1.0.4 when you meant 1.0.5: @severedsolo - he is indeed right, the CKAN meta-file is saying max KSP version is 1.0.4, even though the NetKan is setup to read your KSP-AVC file and your KSP-AVC file correctly says 1.0.5. Best take this up with the CKAN folk as I don't see where the problem is.

Can you post a save file for me to take a look at?

Didn't directly test, but took a look at the code and TS doesn't seem to change ISP, just thrust, so should be okay.

Okay, I'm starting to get more confident that the change I made fixed it. Anyway, in case you still want to know: Just let me know if you hit it again, there's lots of time still before I get the rest of the issues resolved for the next release.

Contract Configurator has to change for pretty much every new KSP release. When Contract Configurator introduces new features that mods like this one start to make use of, that automatically makes them incompatible with older KSP versions because the required Contract Configurator version won't work on that old version. In short - @severedsolo knows what he's talking about, and when he says that the current version of his mod doesn't support older versions of KSP, then he is absolutely correct.

I suspect the change I made might've fixed things up (or if there's multiple issues it fixed one of them). Kerbal experience should not come into play at all - only the trait.

Yup, sometime after @KaiserSoze put his contract pack together I changed my original one to support planets dynamically (eg. OPM etc.)

Any chance you were switching between Engineer Focus III and Pilot Focus III during the session where you had crazy high ISP values? I found one place where info from one strategy could leak to the other. I've fixed that in the dev dll - give that a go in case that's affecting it too.

@smjjames, that's bizarre - the 4150 is the right number though (4048 * 1.025 = 4149.2). So that makes me think it's something in your other save that is the problem that is either throwing the ISP amounts out of alignment. I can't even being to guess what it is (nothing we've looked at seems a likely culprit). Are you able to easily post a full mod list? EDIT: What's most interesting is that you are not getting the same value in the VAB as the launchpad with a non-pilot or probe core. The non-pilot amount (4179) is equal to the pilot amount (4284) times the 1.025 multiplier. So that part actually does seems to be working... but where's the extra bit coming from??

Everything looks normal there - does this mean you're not seeing the issue anymore?

Nope, it's by design - I wanted the strategies to be more powerful individually, but more limited (so one strategy slot per building level). Unfortunately, I need an extra slot always open for the upgrade logic to work. When KSP 1.1 rolls around I'll fix up all the UI and text stuff to make it look like there's the correct amount of slots open. Awesome, thanks in advance! Hard to tell from just that screenshot, but those seem reasonable. TWR should be unchanged - vacuum ISP should be <old ISP> * 1.025. I was thinking that this could be a problem with FloatCurve tangents (because I don't touch them), but that doesn't seem to be the case. Lightbulb worked as expected for me. It may still be dependent on specific engines, but need *something* else to trigger it... either a specific sequence of operations, a specific ship build or some other mod to trigger it off.

There's some special stuff in Contract Configurator used by Field Research that eliminates some invalid combinations (in the case of Station Science, doing Plant Growth on Kerbin's surface). Otherwise they should all be eligible, but it'll depend on the implementation of the contract pack.

Actually, I'm more interested in any mods that would affect vessel/engines - I could do the same thing I'm doing without a strategy or pilot and I'd expect the same results. I'll see what your analysis in the morning tells us... hopefully that'll give me a hint in which direction to investigate.

@smjjames - I've been looking at the Pilot Focus ISP issue, and haven't been able to reproduce as of yet with either stock or Atomic Age engines. I did add a quick change to force set the realISP field, but as far as I could tell that shouldn't be necessary. Do you mind trying the dev dll and letting me know if you still have the issue? The other obvious issue is that you're using MechJeb to report the ISP and I'm using KER. Can you confirm that the vastly increased delta-v is actually what you are getting (ie. if you burn it all, do you actually get way less)? If you right click an engine that's giving you messed up delta-v, what ISP does it report with/without a pilot? Are there any other mods you have that you can think of that might change this somehow? I skimmed the code of Better Burn Time, and didn't see anything there that should affect this.

Raised #28 to look into it.

If you want to attempt, you'd best make a backup of your save. First use the alt-f12 debug to clear all contracts (this will clear what's been completed). You *should* be able to get the contract offered again that way.

The waypoint is off by like 100 meters - I don't think a workaround like that would be sufficient here. Actually if you're able to cancel the contract and re-accept it, can you let me know if that fixes the issue (curious to see if it's always generating wrong for you or not).

Nothing jumped out in there, so not sure what's going on. Raised #487 to dig a bit further in the next week or two. Was hoping it was something simple like you didn't realize you had Kopernicus (it's happened before, since it's a dependency for Kerbal Renaissance. Yup, may consider doing a workaround for the Kopernicus issue above (if it's an easy one).