Contract Packs for Contract Configurator - General Thread

[nightingale]

This is a thread for discussing contract packs for the Contract Configurator mod. Feel free to discuss ideas for new contract packs, ask for help on a contract pack, offer to help on a contract pack or suggest a new contract pack here.

Current Contract Packs

For a full list of contract packs, please see the first post of the main Contract Configurator thread.

New Contract Packs Under Development

The following is a non-comprehensive list of contract packs that are under development. Post a comment in this thread or PM me if you would like your upcoming contract pack added to this listing.

[TABLE=class: grid, width: 0]

[TR]

[TD]Name[/TD]

[TD]Description[/TD]

[TD]Author[/TD]

[TD]Links

[/TD]

[/TR]

[TR]

[TD]0.7.0 Release

Contract Pack[/TD]

[TD]Undecided[/TD]

[TD]nightingale[/TD]

[TD]none[/TD]

[/TR]

[TR]

[TD]Better Parts Testing[/TD]

[TD]Provide sensible parts testing contracts for the purpose of for assisting new players in understanding the 'correct' or expected way to use vessel parts and to encourage players to use parts they might not otherwise use regularly[/TD]

[TD]voidheart[/TD]

[TD]GitHub[/TD]

[/TR]

[TR]

[TD]Vertical Propulsion Emporium Contracts[/TD]

[TD]Contracts for Professor Phineas Kerbenstein's wonderous vertical propulsion emporium.[/TD]

[TD]hakan[/TD]

[TD]none[/TD]

[/TR]

[TR]

[TD]Contract Configurator Demo Contracts[/TD]

[TD]Examples of different Contract Configurator parameters in action.[/TD]

[TD]DBT85[/TD]

[TD]none[/TD]

[/TR]

[/TABLE]

Contract Pack Ideas

These are ideas that nobody is working on that could potentially become a future contract pack.

[TABLE=class: grid, width: 0]

[TR]

[TD]Name[/TD]

[TD]Description[/TD]

[/TR]

[TR]

[TD]USI/Karbonite/MKS/OKS[/TD]

[TD]There are *tons* of opportunities for contracts in this space.[/TD]

[/TR]

[TR]

[TD]Resupply Contracts

[/TD]

[TD]Resupply orbital/landed bases with resources/Kerbals. Could also incorporate base building into this?[/TD]

[/TR]

[/TABLE]

Edited February 11, 2015 by nightingale
added ideas section

[DBT85]

I currently have an expanded SCANSat pack that I'm still working on. It's listed in the m ain thread but it's also still undergoing further testing. Hopefully once I'm happy with it I can start on some other packs.

Happy to help anyone out that wants to get started!

[voidheart]

Happy to help anyone out that wants to get started!

Yes.. there will be questions

[voidheart]

I see some lines like this in the log:

[ERR 11:23:51.003] ContractConfigurator.ContractConfigurator.HasPartFactory: HasPart is obsolete as of ContractConfigurator 0.5.0, please use PartValidation instead.  HasPart will be removed in a future release.

Is there any chance of adding the specific contract name or file to this sort of error? With multiple contracts and multiple contract packs tracking down this sort of error to the contract (which might come from somewhere else) might get a bit old

[DBT85]

That's probably a question for the actual contract configurator thread. This one is for contract pack development.

I'll add it as an issue on the git.

I believe my contract pack that is currently available still uses HasPart, but my dev version has updated to the new format so those errors will go when I release 0.5.0.

Edited January 19, 2015 by DBT85

[nightingale]

I see some lines like this in the log:

[ERR 11:23:51.003] ContractConfigurator.ContractConfigurator.HasPartFactory: HasPart is obsolete as of ContractConfigurator 0.5.0, please use PartValidation instead.  HasPart will be removed in a future release.

Is there any chance of adding the specific contract name or file to this sort of error? With multiple contracts and multiple contract packs tracking down this sort of error to the contract (which might come from somewhere else) might get a bit old

I think those obsolete error messages are the only ones that don't say what contract/parameter it is. I'll fix it.

[voidheart]

I'm building a contract pack called Better Parts Testing

It lives on Github at https://github.com/bendavieshe3/ksp-cc-better-parts-testing

On my very first contract though, I have a bit of problem. It is a parachute contract where the user is expected to launch a vessel, attain a minimum altitude (20,000 m), and then let the vessel descend until a sensible testing point (2000-6000m). Unfortunately the initial altitude requirement is uncompleted when the vessel descends below 20,000 m. I've been trying to use disableOnStateChange in different places and with different values without success.

See the contract below. Any ideas? Thanks for any help

// 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 = SequenceNode


        // 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
        }


        PARAMETER
        {
            name = TestAtTheParachuteAtTheRightTime
            type = All


            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


                disableOnStateChange = true
            }


            // Vessel should have the Parachute tested
            PARAMETER
            {
                name = ParachuteTest
                type = PartTest


                // TODO: See if this can be generalised
                part = parachuteSingle
                disableOnStateChange = false


                notes = Test the parachute through the staging system
            }


        }


        PARAMETER
        {
            name = Touchdown
            type = LandOnBody
        }   


    }


    REQUIREMENT
    {
        name = FirstLaunch
        type = FirstLaunch
    }


}

[nightingale]

I'm building a contract pack called Better Parts Testing

It lives on Github at https://github.com/bendavieshe3/ksp-cc-better-parts-testing

On my very first contract though, I have a bit of problem. It is a parachute contract where the user is expected to launch a vessel, attain a minimum altitude (20,000 m), and then let the vessel descend until a sensible testing point (2000-6000m). Unfortunately the initial altitude requirement is uncompleted when the vessel descends below 20,000 m. I've been trying to use disableOnStateChange in different places and with different values without success.

See the contract below. Any ideas? Thanks for any help

// 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 = SequenceNode


        // 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
        }


        PARAMETER
        {
            name = TestAtTheParachuteAtTheRightTime
            type = All


            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


                disableOnStateChange = true
            }


            // Vessel should have the Parachute tested
            PARAMETER
            {
                name = ParachuteTest
                type = PartTest


                // TODO: See if this can be generalised
                part = parachuteSingle
                disableOnStateChange = false


                notes = Test the parachute through the staging system
            }


        }


        PARAMETER
        {
            name = Touchdown
            type = LandOnBody
        }   


    }


    REQUIREMENT
    {
        name = FirstLaunch
        type = FirstLaunch
    }


}

Let's see, a couple items:

1. 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.
   
2. ReachGoodAlt is the one that should need disableOnStateChange set to true.
   
3. TestAtTheParachuteAtTheRightTime should also be a sequence - as being in that altitude is a pre-requisite for the PartTest.
   
4. 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).

[voidheart]

Let's see, a couple items:

1. 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.
   
2. ReachGoodAlt is the one that should need disableOnStateChange set to true.
   
3. TestAtTheParachuteAtTheRightTime should also be a sequence - as being in that altitude is a pre-requisite for the PartTest.
   
4. 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:

Thanks for the fast and extensive feedback. I'll give it a try when I get I get a chance (need to get some regular KSP hours in right now). I will also review the documentation to see if there are tweaks which would have prevented my confusion. I hope you don't mind but I've already used the edit feature of the pages to make a tweak. If you don't object I'll continue to do that when I notice something.

Also, I'll add your contract pack to the first post (let me know if you object).

Not at all

[DBT85]

Now that my SCANSat pack is out and working I'll work on that demo pack we discussed.

First 3 missions are written and well commented, just need to get back to a KSP machine and test them out with actual parts.

The first 3 missions currently comprise and demonstrate use of the following parameters PartValidation, HasCrew, Duration, Define a Vessel, Recall a Vessel from past contract.

1) Putting an uninhabited first section of a Station into a specific orbit, using some specific parts

2) Putting 3 crew aboard for a minimum of 28 days

3) Adding a new specific module to the existing Station and then boosting the orbit

[nightingale]

Now that my SCANSat pack is out and working I'll work on that demo pack we discussed.

First 3 missions are written and well commented, just need to get back to a KSP machine and test them out with actual parts.

The first 3 missions currently comprise and demonstrate use of the following parameters PartValidation, HasCrew, Duration, Define a Vessel, Recall a Vessel from past contract.

1) Putting an uninhabited first section of a Station into a specific orbit, using some specific parts

2) Putting 3 crew aboard for a minimum of 28 days

3) Adding a new specific module to the existing Station and then boosting the orbit

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

[voidheart]

Let's see, a couple items:

1. 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.
   
2. ReachGoodAlt is the one that should need disableOnStateChange set to true.
   
3. TestAtTheParachuteAtTheRightTime should also be a sequence - as being in that altitude is a pre-requisite for the PartTest.
   
4. Not sure if it will do anything or not, but disableOnStateChange shouldn't be false for ParachuteTest
   

I think I might have found a bug here with the Sequence parameter type. I tried your suggestion and a thousand other things to make sequence respect a disableOnStateChange=true but couldn't do it. The parameter would always complete and then uncomplete when the condition became false.

I switched to SequenceNode and my problems immediately went away.

Here is my demonstration contract. To be clear, the potential bug is that disableOnStateChange behaviours don't work in Sequence parameter types.

(Posted here for someone to spot something silly before I raise a bug)

CONTRACT_TYPE
{
    name = SequenceTest
    title = Test How to make sequence requirements work


    description = test 8

    notes = test


    synopsis = test
    completedMessage = test


    prestige = Trivial


    targetBody = Kerbin


    rewardScience = 0.0
    rewardReputation = 5.0
    rewardFunds = 10000.0
    failureReputation = 5.0
    failureFunds = 10000.0
    advanceFunds = 5000.0


    weight = 10.0




    // Doesn't work. ReachState1 becomes uncomplete after being completed
    PARAMETER
    {
        name = LaunchAndPullSequence
        type = Sequence


        PARAMETER
        {
            name = ReachState1
            type = ReachState


            maxAltitude = 100
            disableOnStateChange = true
        }


        PARAMETER
        {
            name = ReachState2
            type = ReachState


            minAltitude = 500
        }            
    }




//    Works fine (first/ReachState1 stays completed)
// 
//    PARAMETER
//    {
//        name = first
//        type = SequenceNode
//
//        disableOnStateChange = true
//
//        PARAMETER
//        {
//            name = ReachState1
//            type = ReachState
//
//            maxAltitude = 100
//        }
//    }
//
//    PARAMETER
//    {
//        name = second
//        type = SequenceNode
//
//        PARAMETER
//        {
//            name = ReachState2
//            type = ReachState
//
//            minAltitude = 500
//        }            
//    }


}

[nightingale]

I think I might have found a bug here with the Sequence parameter type. I tried your suggestion and a thousand other things to make sequence respect a disableOnStateChange=true but couldn't do it. The parameter would always complete and then uncomplete when the condition became false.

I switched to SequenceNode and my problems immediately went away.

Here is my demonstration contract. To be clear, the potential bug is that disableOnStateChange behaviours don't work in Sequence parameter types.

(Posted here for someone to spot something silly before I raise a bug)

CONTRACT_TYPE
{
    name = SequenceTest
    title = Test How to make sequence requirements work


    description = test 8

    notes = test


    synopsis = test
    completedMessage = test


    prestige = Trivial


    targetBody = Kerbin


    rewardScience = 0.0
    rewardReputation = 5.0
    rewardFunds = 10000.0
    failureReputation = 5.0
    failureFunds = 10000.0
    advanceFunds = 5000.0


    weight = 10.0




    // Doesn't work. ReachState1 becomes uncomplete after being completed
    PARAMETER
    {
        name = LaunchAndPullSequence
        type = Sequence


        PARAMETER
        {
            name = ReachState1
            type = ReachState


            maxAltitude = 100
            disableOnStateChange = true
        }


        PARAMETER
        {
            name = ReachState2
            type = ReachState


            minAltitude = 500
        }            
    }




//    Works fine (first/ReachState1 stays completed)
// 
//    PARAMETER
//    {
//        name = first
//        type = SequenceNode
//
//        disableOnStateChange = true
//
//        PARAMETER
//        {
//            name = ReachState1
//            type = ReachState
//
//            maxAltitude = 100
//        }
//    }
//
//    PARAMETER
//    {
//        name = second
//        type = SequenceNode
//
//        PARAMETER
//        {
//            name = ReachState2
//            type = ReachState
//
//            minAltitude = 500
//        }            
//    }


}

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...

Edited January 23, 2015 by nightingale

[DBT85]

Ok, CC-CP-Demo v0.1 is now on GitHub. A Contract Pack of demo contracts. Short, sharp and pointy.

https://github.com/DBT85/CC-CP-Demo

Anyone please feel free to contribute. Just ensure that any little packs for demo purposes are fairly concise and well commented.

Thus far, just the three missions comprising the SpaceStation collection.

1) Putting an uninhabited first section of a Station into a specific orbit, using some specific parts

2) Putting 3 crew aboard for a minimum of 28 days

3) Adding a new specific module to the existing Station and then boosting the orbit

The parts currently would need to be unlocked to actually do the mission obviously. Hopefully the boss himself can add the new behaviour before too long to unlock specific parts just for a contract!

Same CC-BY-NC-SA-4.0 license as my other pack.

As of Contract Configurator 0.5.8 this pack will not work in the game, the latest dll for Contract configurator will need to be downloaded and placed in the Contract Configurator folder. Hopfully 0.6.0 will be out soon and the new dll will be packaged with it. As a result I have not made a release yet.

I'll update this post when needed.

[nightingale]

Ok, CC-CP-Demo v0.1 is now on GitHub. A Contract Pack of demo contracts. Short, sharp and pointy.

https://github.com/DBT85/CC-CP-Demo

Anyone please feel free to contribute. Just ensure that any little packs for demo purposes are fairly concise and well commented.

Thus far, just the three missions comprising the SpaceStation collection.

1) Putting an uninhabited first section of a Station into a specific orbit, using some specific parts

2) Putting 3 crew aboard for a minimum of 28 days

3) Adding a new specific module to the existing Station and then boosting the orbit

The parts currently would need to be unlocked to actually do the mission obviously. Hopefully the boss himself can add the new behaviour before too long to unlock specific parts just for a contract!

Same CC-BY-NC-SA-4.0 license as my other pack.

As of Contract Configurator 0.5.8 this pack will not work in the game, the latest dll for Contract configurator will need to be downloaded and placed in the Contract Configurator folder. Hopfully 0.6.0 will be out soon and the new dll will be packaged with it. As a result I have not made a release yet.

I'll update this post when needed.

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.

[Yemo]

Hello,

I m trying to replace the stock altitude contracts with different ones.

The idea is, that you first complete the umanned altitude contract and then the manned altitude contract gets offered.

Unfortunately, this does not work, the manned altitude contract does not show up:

I m trying to introduce the variable "unmannedProgression" with the value 2, when the first contract is completed and then check on its value as a requirement for the second contract.

I find this error message in the log:

[Exception]: KeyNotFoundException: The given key was not present in the dictionary.

Thank you for your help!

//---Probe 18km---\\

CONTRACT_TYPE
{
    name = UnmannedAltitude18km

    title = Unmanned altitude record of 18km.
    description = While the lower atmosphere is now widely used for the rapid transportation of kerbals, mail and other goods, the higher levels have only been visited by hot-air balloons. This is your chance to set a new record for rocket-propelled craft.
    synopsis = We want you to launch a probe to an altitude of at least 18,000m.
    completedMessage = You have reached 18km, we congratulate you on this new unmanned altitude record!

    agent = Kerbin World-Firsts Record-Keeping Society

    minExpiry = 100.0
    maxExpiry = 100.0

    cancellable = false
    declinable = false

    prestige = Trivial

    targetBody = Kerbin

    maxCompletions = 1
    maxSimultaneous = 1

    rewardScience = 10.0
    rewardReputation = 18.0
    rewardFunds = 12000.0
    failureFunds = 6000.0
    advanceFunds = 3000.0


    PARAMETER
    {
        name = unmanned
        type = HasCrew

        minCrew = 0
        maxCrew = 0
    }

    PARAMETER
    {
        name = ReachAltitude18km
        type = ReachState

        minAltitude = 18000
    }

    BEHAVIOUR
    {
        name = Progression
        type = Expression

        CONTRACT_COMPLETED_SUCCESS
        {
            unmannedProgression = 2
        }
    }
}

//---Manned 18km---\\

CONTRACT_TYPE
{
    name = MannedAltitude18km

    title = Manned altitude record of 18km.
    description = While the lower atmosphere is now widely used for the rapid transportation of kerbals, mail and other goods, a new official altitude record for manned vessels would be quite an achievement.
    synopsis = We want you to launch a Kerbal to an altitude of at least 18,000m.
    completedMessage = You have reached 18km, we congratulate you on this new manned altitude record!

    agent = Kerbin World-Firsts Record-Keeping Society

    minExpiry = 100.0
    maxExpiry = 100.0

    cancellable = false
    declinable = false

    targetBody = Kerbin

    maxCompletions = 1
    maxSimultaneous = 1

    rewardScience = 15.0
    rewardReputation = 36.0
    rewardFunds = 18000.0
    failureFunds = 12000.0
    advanceFunds = 6000.0


    PARAMETER
    {
        name = manned
        type = HasCrew

        minCrew = 1
        maxCrew = int.MaxValue
    }

    PARAMETER
    {
        name = ReachAltitude18km
        type = ReachState

        minAltitude = 18000
    }

    REQUIREMENT
    {
        name = techResearched
        type = TechResearched

        tech = basicRocketry
    }

    REQUIREMENT
    {
        name = Progression
        type = Expression

        expression = unmannedProgression >= 2
    }

    BEHAVIOUR
    {
        name = Progression
        type = Expression

        CONTRACT_COMPLETED_SUCCESS
        {
        mannedProgression = 2
        }
    }
}

[nightingale]

Hello,

I m trying to replace the stock altitude contracts with different ones.

The idea is, that you first complete the umanned altitude contract and then the manned altitude contract gets offered.

Unfortunately, this does not work, the manned altitude contract does not show up:

I m trying to introduce the variable "unmannedProgression" with the value 2, when the first contract is completed and then check on its value as a requirement for the second contract.

I find this error message in the log:

[Exception]: KeyNotFoundException: The given key was not present in the dictionary.

Thank you for your help!

//---Probe 18km---\\

CONTRACT_TYPE
{
    name = UnmannedAltitude18km

    title = Unmanned altitude record of 18km.
    description = While the lower atmosphere is now widely used for the rapid transportation of kerbals, mail and other goods, the higher levels have only been visited by hot-air balloons. This is your chance to set a new record for rocket-propelled craft.
    synopsis = We want you to launch a probe to an altitude of at least 18,000m.
    completedMessage = You have reached 18km, we congratulate you on this new unmanned altitude record!

    agent = Kerbin World-Firsts Record-Keeping Society

    minExpiry = 100.0
    maxExpiry = 100.0

    cancellable = false
    declinable = false

    prestige = Trivial

    targetBody = Kerbin

    maxCompletions = 1
    maxSimultaneous = 1

    rewardScience = 10.0
    rewardReputation = 18.0
    rewardFunds = 12000.0
    failureFunds = 6000.0
    advanceFunds = 3000.0


    PARAMETER
    {
        name = unmanned
        type = HasCrew

        minCrew = 0
        maxCrew = 0
    }

    PARAMETER
    {
        name = ReachAltitude18km
        type = ReachState

        minAltitude = 18000
    }

    BEHAVIOUR
    {
        name = Progression
        type = Expression

        CONTRACT_COMPLETED_SUCCESS
        {
            unmannedProgression = 2
        }
    }
}

//---Manned 18km---\\

CONTRACT_TYPE
{
    name = MannedAltitude18km

    title = Manned altitude record of 18km.
    description = While the lower atmosphere is now widely used for the rapid transportation of kerbals, mail and other goods, a new official altitude record for manned vessels would be quite an achievement.
    synopsis = We want you to launch a Kerbal to an altitude of at least 18,000m.
    completedMessage = You have reached 18km, we congratulate you on this new manned altitude record!

    agent = Kerbin World-Firsts Record-Keeping Society

    minExpiry = 100.0
    maxExpiry = 100.0

    cancellable = false
    declinable = false

    targetBody = Kerbin

    maxCompletions = 1
    maxSimultaneous = 1

    rewardScience = 15.0
    rewardReputation = 36.0
    rewardFunds = 18000.0
    failureFunds = 12000.0
    advanceFunds = 6000.0


    PARAMETER
    {
        name = manned
        type = HasCrew

        minCrew = 1
        maxCrew = int.MaxValue
    }

    PARAMETER
    {
        name = ReachAltitude18km
        type = ReachState

        minAltitude = 18000
    }

    REQUIREMENT
    {
        name = techResearched
        type = TechResearched

        tech = basicRocketry
    }

    REQUIREMENT
    {
        name = Progression
        type = Expression

        expression = unmannedProgression >= 2
    }

    BEHAVIOUR
    {
        name = Progression
        type = Expression

        CONTRACT_COMPLETED_SUCCESS
        {
        mannedProgression = 2
        }
    }
}

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).

[Yemo]

When I left out the minCrew value for the unmanned contract and launched a probe to complete the contract, it never registered that the vessel was unmanned.

- - - Updated - - -

The error went away and the contract now shows up, but not at once.

When I returned to KSC after the landing/mission (which was some time after I completed the contract on the way up), I did not find the contract in mission control.

Only a little later (after opening debug menu and so on), it showed up.

So the basic issue is resolved, but regular players would probably not check back if they dont find the contract right away.

Thank you for your help, I ll now procede to make contracts!

[nightingale]

When I left out the minCrew value for the unmanned contract and launched a probe to complete the contract, it never registered that the vessel was unmanned.

Yup, since the default for minCrew is 1:

    // (Optional) Minimum and maximum count.  Default values are 1 and
    // int.MaxValue (for min/max).
    minCrew = 1
    maxCrew = 10

I will fix the validation so that it checks max >= min though.

The error went away and the contract now shows up, but not at once.

When I returned to KSC after the landing/mission (which was some time after I completed the contract on the way up), I did not find the contract in mission control.

Only a little later (after opening debug menu and so on), it showed up.

So the basic issue is resolved, but regular players would probably not check back if they dont find the contract right away.

Thank you for your help, I ll now procede to make contracts!

Also normal, that's just how KSP works. If the list is full it won't try to generate new contracts. Either time warp a bit so some of them expire, manually decline them or go to the debug menu for contracts and regenerate the whole list.

[DBT85]

The weight option might help that.

Another option is disabling certain stock contracts, very useful for testing. I have them all off when testing and have disable satellite contracts in my main games.

[nightingale]

So the Anomaly Surveyor contract pack is now out. Next I'll be doing some much needed work on In-Flight Waypoints, after which point I'll get to work on Contract Configurator 0.7.0 and the new release contract pack. I have lots of ideas for contract packs on the back burner, but thought I'd throw it out there on the forum... so, anyone have any ideas they'd like to see in a contract pack?

[suedester]

So the Anomaly Surveyor contract pack is now out. Next I'll be doing some much needed work on In-Flight Waypoints, after which point I'll get to work on Contract Configurator 0.7.0 and the new release contract pack. I have lots of ideas for contract packs on the back burner, but thought I'd throw it out there on the forum... so, anyone have any ideas they'd like to see in a contract pack?

I'd love to see a Karbonite and MKS/OKS packs.

[nightingale]

I'd love to see a Karbonite and MKS/OKS packs.

That's definitely one that I've been toying with. So many decisions though:

1. Make individual contract packs for different bits, or just attempt a massive USI contract pack?
   
2. Wait for 1.0 when the resource system gets shaken up? Or just go ahead now and hope for the best in the future?
   

There's also a couple features that I want to investigate before doing something like this one (the big one being more detailed Regolith support). But it could happen soon, you never know!

[suedester]

That's definitely one that I've been toying with. So many decisions though:

1. Make individual contract packs for different bits, or just attempt a massive USI contract pack?
   
2. Wait for 1.0 when the resource system gets shaken up? Or just go ahead now and hope for the best in the future?
   

There's also a couple features that I want to investigate before doing something like this one (the big one being more detailed Regolith support). But it could happen soon, you never know!

I've discovered via some fine redditor that stock has Karbonite contracts, you just need to enable it by editing the contracts.cfg.

[nightingale]

I've discovered via some fine redditor that stock has Karbonite contracts, you just need to enable it by editing the contracts.cfg.

That's right - almost forgot about those. They are from the original Fine Print and made it into stock (although disabled by default). I think the idea is you can change the resource name to whatever you like (ie. Karbonite, Kethane, etc.) and turn it on.

Anyway, anything I'd try to make sure anything I do in that area would be different enough from the stock ones to be worthwhile.