nightingale

Well, first off, this is what the handy new debug window in 0.6.0 (that you do not have, as it is not released) says: So you'll need to fix that - just remove the maxCrew line entirely (the int.MaxValue has an actual value of 2,147,483,647 - but easier to just let Contract Configurator default it for you). I wasn't able to reproduce in 0.6.0, but I think this is what's causing your problem - I remember fixing a bug where it in 0.5.x invalid contracts would still get loaded. So try fixing the maxCrew issue, and if that doesn't make the error go away then pull the full error text from KSP.log for me (it'll include a stack trace - that's what I need to see).

Ah, was an issue with the code for loading, missed testing scenario. New version out. Contract Configurator 0.5.10 Fixed issue loading SCANsatCoverage parameter (thanks whiteout1911).

Oh yeah, that's coming out of SCANsat itself - most likely a problem in the contract pack, but I'll have to take a closer look later - on mobile at the moment.

Also, make sure you're on SCANsat 9rc5 (released today)

Can you send the output_log.txt file?

Contract Configurator 0.5.9 is out, mainly a compatibility update for the new pre-release of SCANsat. Download it now! Changes: Changes for SCANsat 9.0 (rc5) Fix for disableOnStateChange when there is no VesselGroupParameter (thanks voidheart).

0.6.0 sometime next week (probably). I'll add your pack to the main thread then. I'll try to get that behaviour into the release too... don't think it should be a particularly difficult one.

Log a GitHub issue, I'll throw in a behaviour for unlocking experimental parts. For PartTest I'm just wrapping the stock parameter right now - I actually didn't think that the parts unlocked at all (I thought that was the stock contract vs. the stock parameter that had that logic).

This one was a bit of a pain, but I've got it fixed. The problem was that disableOnStateChange wasn't working right if there wasn't a VesselParameterGroup parent. The fix will get released sometime tomorrow under Contract Configurator 0.5.9 - need one more unrelated change before it can go...

To be honest I'm not 100% sure how this all installs with CKAN at the moment (and am not able to test it right now). The SCANsat contract packs on CKAN (both the original one by tattagreis and the new one by DBT85) have their dependency marked as requiring SCANsat 9.0, and the pre-release version is not up on CKAN. So my expectation would've been that the SCANsat pack just wouldn't install or show up in CKAN. Anyway, as soon as SCANsat 9.0 is officially released there will be a new version of Contract Configurator that goes up around roughly the same time. Same thing for RemoteTech 1.6.2. After that things should be in place so that there won't be any required changes in Contract Configurator for SCANsat 9.x or RemoteTech 1.6.x, so there will be no more version woes (until KSP 0.91 comes and breaks everything ) EDIT: Hakan beat me to it on the CKAN front.

Let me look into this tonight and see if I can reproduce.

DMagic is correct. I'll put in a fix so that it fails more gracefully in this scenario, but you will need the dev build of SCANsat to get these contracts working.

The new Contract Configurator debug window is a little bit bigger than the old one...

Cool, I'll add it to the first post.

Hmmm, that screenshot points to the RemoteTech 1.6.1/Contract Configurator 0.5.7 compatibility issue that should be all resolved with CC 0.5.8. @linuxgurugamer - can you provide your ksp.log or output_log.txt?

Not sure what you mean by adding a craft file - do you mean creating the vessel from the craft file and spawning it in game? That is in.

There's a few other contract mods out there with "Ferry Passengers" style contracts, which use a convention that an empty seat = room for a passenger. That's just not as much fun as having real passengers to ferry around. I stumbled on a couple of the pieces that I was missing for this while working on 0.6.0 (how to make it so the passenger doesn't show up in mission control as a selectable Kerbonaut). I don't have any contract pack currently planned that would use this functionality... so if anyone's looking for a fun idea.... First, if there's room on the vessel, we ask the player if they want to load passengers (only happens at KSC). If they say yes, then we load 'em up. And if the passengers are somehow lost before the contract completes... (oh Philry and Alcott, we hardly knew ye).

Ugh, that's horrible.... but now I've done some reading on C# assemblies and have much better sense of them. - - - Updated - - - ... you don't use HyperEdit for testing?

Wow... that would do it, yeah.

It's just a question of finding the points of failure, trapping and logging the error, and failing the contract. The player still loses the contract... but the system doesn't explode. Lesser of two evils. Neat! Which reminds me that I'll need to change RecoverKerbal so that it can "index" Kerbals that were created by SpawnVessel... good thing you mentioned this.

I don't understand what they changed, but a simple recompile fixed it. That's why I never caught it in my development stream - I recompiled at the same time as installing 1.6.1. Anyway, new version out shortly, also with a fix so that next time (let's hope there's no next time), it doesn't take the whole contract system down with it (although you would still lose your RemoteTech contracts.... there's simply no way around that). I really wish this plugin wasn't necessary... but let's throw a plug out there for Nereid's S.A.V.E. - automatic save game backups just for this type of scenario. - - - Updated - - - Contract Configurator 0.5.8 is out, download it now! Changes: Recompile for RemoteTech 1.6.1 Fix so that failing to load a contract is less destructive.

I see! I'll try and reproduce tonight. In the meantime, if anyone has logs it would be appreciated.

The contract system can misbehave badly when things go wrong, but I haven't heard of it killing all the history as well. If you can provide logs I can look into it, but there's no known issues on the latest version that would cause that.

Let's see, a couple items: The way you used it, the SequenceNode doesn't do anything (it only does if there are multiple sequence nodes. You probably want Sequence instead. ReachGoodAlt is the one that should need disableOnStateChange set to true. TestAtTheParachuteAtTheRightTime should also be a sequence - as being in that altitude is a pre-requisite for the PartTest. Not sure if it will do anything or not, but disableOnStateChange shouldn't be false for ParachuteTest I haven't tested this, but here's what I think you want it to look like: // Better Parts Testing parachute contract // For use with Kerbal Space Program (https://kerbalspaceprogram.com/) // And Contract Configurator (http://forum.kerbalspaceprogram.com/threads/101604) // Github https://github.com/bendavieshe3/ksp-cc-better-parts-testing/ CONTRACT_TYPE { name = SimpleParachuteTestingContract title = Test Basic Parachute Operation description = It is no surprise that what goes up frequently comes down. When it does it tends to explode. We believe fitting vessels with a parachute is one excellent way to prevent this. We need someone to test this theory. This, of course, is where you come in. notes = Parachutes are a relatively inexpensive way to decelerate vessels attempting landings on bodies with atmospheres, including Kerbin. Parachutes can be deployed directly or via the staging system. It is generally not a good idea to deploy parachutes too early. synopsis = Launch a vessel to the minimum height and land it safely on Kerbin using a parachute completedMessage = Congratulations! You've learnt basic parachute usage! // Contract min/max expiry in days. // minExpiry = 7.0 // maxExpiry = 30.0 // Contract deadline in days. Default is no deadline. deadline = 30 cancellable = true declinable = true prestige = Trivial targetBody = Kerbin maxCompletions = 1 maxSimultaneous = 1 // Contract rewards // TODO: Find multiplier reference rewardScience = 0.0 rewardReputation = 5.0 rewardFunds = 10000.0 failureReputation = 5.0 failureFunds = 10000.0 advanceFunds = 5000.0 // TODO: Change back to 1.0 after testing weight = 10.0 PARAMETER { name = LaunchAndPullSequence type = Sequence // The title to display // Default: Complete the following in order //title = // Vessel should first reach at least 20K meters PARAMETER { name = ReachGoodAlt type = ReachState minAltitude = 20000 disableOnStateChange = true } PARAMETER { name = TestAtTheParachuteAtTheRightTime type = Sequence title = Test the parachute 2000-6000 meters above sea level // Vessel should be at reasonable altitude and speed PARAMETER { name = ReachGoodAlt type = ReachState minSpeed = 100 maxSpeed = 450 minAltitude = 2000 maxAltitude = 6000 situation = FLYING } // Vessel should have the Parachute tested PARAMETER { name = ParachuteTest type = PartTest // TODO: See if this can be generalised part = parachuteSingle notes = Test the parachute through the staging system } } PARAMETER { name = Touchdown type = LandOnBody } } REQUIREMENT { name = FirstLaunch type = FirstLaunch } } Also, I'll add your contract pack to the first post (let me know if you object).

Contract Configurator 0.5.7 is out, with a few bug fixes. Download it now! Changes: Fix display of year/years and day/days in time based parameters (thanks DBT85). Fix obsolete error messages to display contract type. Fix for NullReference error when decoupling/undocking and the root part is a decoupler (thanks DaveTSG).