[1.10.1+] Contract Configurator [v1.30.5] [2020-10-05]

[scerion]

zcaalock, Where you have the prelaunch parameter add this and it won't mark the parameter failed after launch: disableOnStateChange = true

Like this:

		PARAMETER
		{
			name = ReachState
			type = ReachState

			situation = PRELAUNCH

                        [COLOR="#FF0000"]disableOnStateChange = true[/COLOR]
		}

For cleanup I'd remove the minCount=1 on your detectionarray, it should just detect then if it has one or more without the added text.

As for the Destination Mun that might be a bug? But I think the workaround is to remove the target=Mun from the main contract parameter and put it in the SCANsatCoverage parameter.

Edited January 14, 2015 by scerion

[nightingale]

i posted in wrong thread before..

how to make prelaunch to hold result? After launch parameter is going back to x

PARAMETER
        {
            name = ReachState
            type = ReachState

            situation = PRELAUNCH
        }

http://i61.tinypic.com/2nvs5r6.jpg

and after launch:

http://i58.tinypic.com/290vrqs.jpg

from where "destination" is comming from?

here is whole code:

CONTRACT_TYPE:NEEDS[SCANsat]
{
    name = ScanMun

    // Contract text
    title = Karbonite Scan Mun
    description = We need answers! And snacks!!! You are required to create an Altimetry scan of Mun's surface.\n This will greatly enhance our knowledge about our moons, snacks and everything.
    synopsis = Reach a fitting orbit and scan Mun's surface.
    completedMessage = HQ will be statisfied!

    // Controls for whether a contract can be declined or cancelled, default is true for both
    cancellable = true
    declinable = true

    // Target Celestial body - controls where the contract must be completed, has some automated
    // effects on numeric parameters (increasing science, etc.)
    targetBody = Mun

    // Contract rewards
    rewardScience = 25.0
    rewardReputation = 40.0
    rewardFunds = 20000.0

    // Can only be done once
    maxCompletions = 1
    maxSimultaneous = 1

    prestige = Significant



    PARAMETER
    {
        name = VesselParameterGroup1
        type = VesselParameterGroup

        PARAMETER
        {
            name = HasCrew1
            type = HasCrew
            maxCrew = 0
            minCrew = 0
        }

        PARAMETER
        {
            name = PartValidation1
            type = PartValidation

            part = KA_DetectionArray_01
            minCount = 1
        }

        PARAMETER
        {
            name = ReachState
            type = ReachState

            situation = PRELAUNCH
        }

    }

    PARAMETER
    {

    name = ReachSpecificOrbit
        type = ReachSpecificOrbit

    // The index (0-based) in the OrbitGenerator behaviour of the orbit we
        // wish to reference.
        // Default = 0
        index = 0

       // The deviation window for how close we must match the given orbit.
       // wish to reference.  Higher values give more room for error.  Note: More
       // testing is required to better document the realistic range of values.
       // Default = 3.0
       deviationWindow = 5.0
    }

    BEHAVIOUR
    {
        name = OrbitGenerator
        type = OrbitGenerator

           // Use this to generate an orbit with specific parameters
           FIXED_ORBIT
           {
              // Body for the orbit - defaulted from the contract if not supplied
            targetBody = Mun

            // Actual orbit details. Note that REF represents the reference
            // body - but will be overriden by the targetBody.

               ORBIT
               {
                SMA = 500001.234556523
                   ECC = 1.07570816555399E-05
                INC = 82
                LPE = 270.690311604893
                LAN = 1.93635924563296
                MNA = 1.55872660382504
                EPH = 31.3999999999994
                REF = 1
            }
           }    
    }

    PARAMETER
    {
        name = SCANsatCoverage1
        type = SCANsatCoverage

        // More than 90% coverage
        coverage = 90.0
        // See https://github.com/jrossignol/ContractConfigurator/wiki/Parameters#scansatcoverage to get the full list of SanTypes
        scanType = Karbonite
    }

        PARAMETER
    {
        name = Duration
           type = Duration

        // The duration the timer is set to. Can specify values in years (y),
        // days (d), hours (h), minutes (m), seconds (s) or any combination of
        // those.
        duration = 30m 10s

        // The preWaitText overrides the text that is displayed when waiting
        // for the other parameters to complete.
        // Default = Waiting time required
        preWaitText = Hold the satellite in position for 30m 10s to scan the surface.

        // The waitingText overrides the text that is displayed when waiting
        // for the timer to expire.
        // Default = Time to completion
        waitingText = Scanning surface

        // The completionText is displayed when the timer completes.
        // Default = Wait time over
        completionText = Scane done
    }


    REQUIREMENT
    {
        name = TechResearched
        type = TechResearched

        // The technology that needs to have been researched.  Take special note that
        // this does not get validated - if you make a typo, the requirement will
        // always return false.
        tech = fuelSystems
    }

}

See the Parameters page of the wiki for more details.

If you want a VesselParameter to be "sticky" (ie. not reset its state), then you need to provide disableOnStateChange = true. The destination in the ReachState parameter gets defaulted from the targetBody of the contract. In this case, it's not the behaviour that you want, so you would have to provide targetBody = Kerbin as part of your reachState parameter.

Note that if you make that change, you won't have to explicitly use the disableOnStateChange anywhere, as the VesselParameterGroup at the top will get completed, and it has a default of true for disableOnStateChange.

Also note that the way you have it currently set up, the player can meet the launch pre-requisite requirement and the ReachSpecificOrbit with different vessels, which I'm sure isn't what you intended.

[scerion]

ahh I was close on my advice. But I misunderstood the beginning parameter, I should've caught that's how CC was interpreting it. I gotta pay closer attention at reading these

[nightingale]

zcaalock, Where you have the prelaunch parameter add this and it won't mark the parameter failed after launch: disableOnStateChange = true

Like this:

        PARAMETER
        {
            name = ReachState
            type = ReachState

            situation = PRELAUNCH

                        [COLOR=#FF0000]disableOnStateChange = true[/COLOR]
        }

For cleanup I'd remove the minCount=1 on your detectionarray, it should just detect then if it has one or more without the added text.

As for the Destination Mun that might be a bug? But I think the workaround is to remove the target=Mun from the main contract parameter and put it in the SCANsatCoverage parameter.

Ninja'd!

The target=Mun defaulting is working as intended - it's just not necessarily intuitive. The Part=KA_DetectionArray_01 is a bit restrictive, as there's the possibility for someone to create new and different scanners that could scan Karbonite - and you'd want those to work in the contract. I don't have a better suggestion at this point, aside from straight up removing it.

[DBT85]

So I've finally got my CC-CP-SCANSat pack ready for an initial rollout, got AVC compatible and working fine, even got the netkan working when not including the AVC part. Can I get it to work with the AVC part? No. Bad version file. Grrrr.

[nightingale]

So I've finally got my CC-CP-SCANSat pack ready for an initial rollout, got AVC compatible and working fine, even got the netkan working when not including the AVC part. Can I get it to work with the AVC part? No. Bad version file. Grrrr.

Run it through a JSON validator on the web. KSP-AVC is very loose about JSON compliance in the version file, NetKAN/CKAN is not.

[hakan]

So I've finally got my CC-CP-SCANSat pack ready for an initial rollout, got AVC compatible and working fine, even got the netkan working when not including the AVC part. Can I get it to work with the AVC part? No. Bad version file. Grrrr.

Also, make sure that your version information is three separate numbers instead of one string. We have an enhancement request running to read the shortened version too, but no one picked it up yet.

  "VERSION":{
         "MAJOR":1,
         "MINOR":6,
         "PATCH":0
     },

instead of

"VERSION": "1.6.0",

[nightingale]

Thanks for the update!

Testing on 0.5.5 (not sure if it was existing in 0.5.4)

In my ReachState parameters if I set a minAltitude but no maxAltitude, there seems to be a default maxAltitude set (at Double.MaxValue? the wiki entry for ReachState isn't specific).

This results in Mission Control Line:

I guess I was expecting 'Altitude: Greater than 70,000 m' or something.

Am I doing something wrong? Should I raise an enhancement issue?:

    PARAMETER    {
        // TODO: Wait for a way to detect docking is created
        // See https://github.com/jrossignol/ContractConfigurator/issues/86
        name = ReachStateDocked
        type = ReachState


        // Minimum and maximum altitudes.
        minAltitude = 70000


        // The situation.  Valid values from Vessel.Situations:
        //    ESCAPING
        //    FLYING
        //    LANDED
        //    ORBITING
        //    PRELAUNCH
        //    SPLASHED
        //    SUB_ORBITAL
        situation = ORBITING


        // Text to use for the parameter
        // Default Vessel State: <state details>
        title = Vessel is orbiting Kerbin
    }

Thanks!

Was sure I responded to this one earlier, but guess I never hit submit. This is most certainly a bug - it should be displaying "Greater than 70,000 m", as you expected. I've raised issue #96 on github to track this.

EDIT: At a quick glance, everything looks right for this one. Can you confirm that this is a new contract since you updated to 0.5.5? In other words, use the debug option on the contracts tab to regenerate all the contracts, and accept your contract again.

Edited January 14, 2015 by nightingale

[DBT85]

Run it through a JSON validator on the web. KSP-AVC is very loose about JSON compliance in the version file, NetKAN/CKAN is not.

Also, make sure that your version information is three separate numbers instead of one string. We have an enhancement request running to read the shortened version too, but no one picked it up yet.

  "VERSION":{
         "MAJOR":1,
         "MINOR":6,
         "PATCH":0
     },

instead of

"VERSION": "1.6.0",

Thanks guys, will look at it in the morning. Tearing my hair out this afternoon with it!

I did have it as three separate numbers, I practically copied one from another mod and made the appropriate changes, rather than starting new.

[voidheart]

Was sure I responded to this one earlier, but guess I never hit submit. This is most certainly a bug - it should be displaying "Greater than 70,000 m", as you expected. I've raised issue #96 on github to track this.

EDIT: At a quick glance, everything looks right for this one. Can you confirm that this is a new contract since you updated to 0.5.5? In other words, use the debug option on the contracts tab to regenerate all the contracts, and accept your contract again.

Sorry, looks like this is fixed now. It reads 'Above 70,000 m'. Thanks for the reply!

[nightingale]

Sorry, looks like this is fixed now. It reads 'Above 70,000 m'. Thanks for the reply!

No problem, appreciate the bug report.

[DBT85]

Sorted my version file woes out. An extra comma bunging up the works.

Then tried to add my netkan to the repo and got told it didn't match JSON (another comma), despite Netkan.exe having no problem with it.

Never mind, just waiting to be added now.

My pack, CC-CP-SCANSat (Contract Configurator-Contract Pack-SCANSat) is currently riddled with 10 exciting missions covering every body cept Jool (and moons), with fun optional parts for covering other moons and deorbiting old equipment.

Currently all are unlocked so can be got at any time and the rewards are all out of whack as I've just set everything to be identical and let the games multiplier go crazy. Both will of course be changed soon along with more missions. Full details and links soon!

[hakan]

Full details and links soon!

ckan install ContractConfigurator-ContractPack-SCANsat

is your friend now

[DBT85]

Thanks for the help Hakan, sent you a PM about it remaining up to date.

Nightingale, I've noticed something and am not sure if its a bug with SCANSat or the contract system.

I just tested my first 3 missions in full (get lo res altimetry of Kerbin, Mun & Minmus), all locked using their requirements with real values for things.

Each has a duration timer on the orbit to ensure a stable one, I've set it to be about the same duration as it takes to get roughly 50% of the scan done.

For Kerbin and Mun, the timer elapsed slightly after 50% of the scan parameter was met, so the contract ended as soon as it did as you would hope.

For me Minmus mission however, the timer was set about 2 hours short (testing). When the timer expired, the contract completed, despite still having to get another 15% or so of the data from the scan to complete the SCANsatCoverage Parameter in my contract. It even showed "get 50% lo res data from Minmus" as green, even though I was at about 35%!

No maps for Minmus had been previously completed, so I'm wondering if SCANSat is reporting numbers weirdly, or if there is a problem with the contract somewhere.

Maybe I'm using the Duration Parameter wrong and its just designed to end the contract as soon as it completes?

// Any suggestions or corrections? Send me a note on http://forum.kerbalspaceprogram.com/members/118151-DBT85
// This contract only work with Contract Configurator and SCANsat 9.0



name = ScanMinmus


// Contract text
title = Altimetry Scan of Minmus
description = Heads up, Director. There is more work to be done. With the Kerbin scans coming along nicely and Mun scans underway, the team feel it's time we got some data about Minmus. We think it's very flat in places, but we'll know more once you've got us this data.
synopsis = Send an unkerbaled vessel into a Minmus orbit, reach a 74km orbit with an 79.5 degree inclination and scan Minmus's surface with the SCAN Radar Altimetry Sensor. \n\nYou'll see a suggested orbit in the Tracking Station, but feel free to just hit the targets below.
completedMessage = Excellent work. As expected Kerbins second celestial satellite is very flat in places, with some bumpy bits. The guys are already preparing a party in the mess. Free Ice Cream!


// Target Celestial body - controls where the contract must be completed, has some automated
// effects on numeric parameters (increasing science, etc.)
targetBody = Minmus

// Always offered by the R&D department
agent = Research & Development Department


// Contract rewards, Minmus multiplies by 3.125 in Normal mode.
advanceFunds = 8960
rewardScience = 13
rewardReputation = 18
rewardFunds = 19200

// Can only be done once and offered once at a time
maxCompletions = 1
maxSimultaneous = 1

// Prestige level 2
prestige = Significant

// very likely to be chosen
//weight = 10.0


PARAMETER
{
// Named for the Scottish physicist who predicted the existence of electromagnetic waves.
name = Maxwell3
type = VesselParameterGroup


define = Maxwell III
disableOnStateChange = false

PARAMETER
{
name = HasCrew1
type = HasCrew
maxCrew = 0
minCrew = 0
}

PARAMETER
{
name = HasPart1
type = HasPart

part = SCANsat_Scanner
minCount = 1
}


PARAMETER
{
name = Orbit
type = Orbit
targetBody = Minmus
title = Achieve an orbit with the following parameters
minApA = 71210
maxApA = 77305
minPeA = 71103
maxPeA = 77219
maxEccentricity = 0.00217
minInclination = 79.0
maxInclination = 80
disableOnStateChange = false
}

// Once all of the above are complete, start the countdown.
PARAMETER
{
name = Duration
type = Duration


duration = 3h 30m


preWaitText = We need a stable orbit for at least
waitingText = Orbit acquired, monitoring.
completionText = Stable orbit confirmed!
}
}

PARAMETER
{
name = SCANsatCoverage1
type = SCANsatCoverage
targetBody = Minmus

// Requires 50% SCAN coverage to complete
coverage = 50.0
scanType = AltimetryLoRes
}

REQUIREMENT
{
name = All1
type = All

REQUIREMENT
{
name = SCANsatCoverage2
type = SCANsatCoverage


targetBody = Kerbin


// Contract will not be activated until 65% of Kerbin has LoRes data
maxCoverage = 100.0
minCoverage = 65.0


// The type of scan to perform. Valid values are from SCANdata.SCANtype.
scanType = AltimetryLoRes
}

REQUIREMENT
{
name = SCANsatCoverage3
type = SCANsatCoverage


targetBody = Mun


// Contract will not be activated until 15% of Mun has LoRes data
maxCoverage = 100.0
minCoverage = 15.0


// The type of scan to perform. Valid values are from SCANdata.SCANtype.
scanType = AltimetryLoRes
}

REQUIREMENT
{
name = SCANsatCoverage4
type = SCANsatCoverage


targetBody = Minmus


// The contract will not be activated if Minmus has 50% LoRes data
maxCoverage = 49.9
minCoverage = 0.0


// The type of scan to perform. Valid values are from SCANdata.SCANtype.
scanType = AltimetryLoRes
}
}



BEHAVIOUR
{
name = OrbitGenerator1
type = OrbitGenerator

// Use this to generate an orbit with specific parameters
FIXED_ORBIT
{
// Body for the orbit - defaulted from the contract if not supplied
targetBody = Minmus

// Actual orbit details. Note that REF represents the reference
// body - but will be overriden by the targetBody.

ORBIT
// Minmus surface is SMA = 60000
{
SMA = 133986
ECC = 0.0001
INC = 79.5
LPE = 90
LAN = 203
REF = 1
}
}
}
}

CONTRACT_TYPE:NEEDS[SCANsat]{

[zcaalock]

thanks for help. BTW is anyone working on some kind of campagin or custom chain contracts?

[nightingale]

Thanks for the help Hakan, sent you a PM about it remaining up to date.

Nightingale, I've noticed something and am not sure if its a bug with SCANSat or the contract system.

I just tested my first 3 missions in full (get lo res altimetry of Kerbin, Mun & Minmus), all locked using their requirements with real values for things.

Each has a duration timer on the orbit to ensure a stable one, I've set it to be about the same duration as it takes to get roughly 50% of the scan done.

For Kerbin and Mun, the timer elapsed slightly after 50% of the scan parameter was met, so the contract ended as soon as it did as you would hope.

For me Minmus mission however, the timer was set about 2 hours short (testing). When the timer expired, the contract completed, despite still having to get another 15% or so of the data from the scan to complete the SCANsatCoverage Parameter in my contract. It even showed "get 50% lo res data from Minmus" as green, even though I was at about 35%!

No maps for Minmus had been previously completed, so I'm wondering if SCANSat is reporting numbers weirdly, or if there is a problem with the contract somewhere.

Maybe I'm using the Duration Parameter wrong and its just designed to end the contract as soon as it completes?

// Any suggestions or corrections? Send me a note on http://forum.kerbalspaceprogram.com/members/118151-DBT85
// This contract only work with Contract Configurator and SCANsat 9.0



name = ScanMinmus


// Contract text
title = Altimetry Scan of Minmus
description = Heads up, Director. There is more work to be done. With the Kerbin scans coming along nicely and Mun scans underway, the team feel it's time we got some data about Minmus. We think it's very flat in places, but we'll know more once you've got us this data.
synopsis = Send an unkerbaled vessel into a Minmus orbit, reach a 74km orbit with an 79.5 degree inclination and scan Minmus's surface with the SCAN Radar Altimetry Sensor. \n\nYou'll see a suggested orbit in the Tracking Station, but feel free to just hit the targets below.
completedMessage = Excellent work. As expected Kerbins second celestial satellite is very flat in places, with some bumpy bits. The guys are already preparing a party in the mess. Free Ice Cream!


// Target Celestial body - controls where the contract must be completed, has some automated
// effects on numeric parameters (increasing science, etc.)
targetBody = Minmus

// Always offered by the R&D department
agent = Research & Development Department


// Contract rewards, Minmus multiplies by 3.125 in Normal mode.
advanceFunds = 8960
rewardScience = 13
rewardReputation = 18
rewardFunds = 19200

// Can only be done once and offered once at a time
maxCompletions = 1
maxSimultaneous = 1

// Prestige level 2
prestige = Significant

// very likely to be chosen
//weight = 10.0


PARAMETER
{
// Named for the Scottish physicist who predicted the existence of electromagnetic waves.
name = Maxwell3
type = VesselParameterGroup


define = Maxwell III
disableOnStateChange = false

PARAMETER
{
name = HasCrew1
type = HasCrew
maxCrew = 0
minCrew = 0
}

PARAMETER
{
name = HasPart1
type = HasPart

part = SCANsat_Scanner
minCount = 1
}


PARAMETER
{
name = Orbit
type = Orbit
targetBody = Minmus
title = Achieve an orbit with the following parameters
minApA = 71210
maxApA = 77305
minPeA = 71103
maxPeA = 77219
maxEccentricity = 0.00217
minInclination = 79.0
maxInclination = 80
disableOnStateChange = false
}

// Once all of the above are complete, start the countdown.
PARAMETER
{
name = Duration
type = Duration


duration = 3h 30m


preWaitText = We need a stable orbit for at least
waitingText = Orbit acquired, monitoring.
completionText = Stable orbit confirmed!
}
}

PARAMETER
{
name = SCANsatCoverage1
type = SCANsatCoverage
targetBody = Minmus

// Requires 50% SCAN coverage to complete
coverage = 50.0
scanType = AltimetryLoRes
}

REQUIREMENT
{
name = All1
type = All

REQUIREMENT
{
name = SCANsatCoverage2
type = SCANsatCoverage


targetBody = Kerbin


// Contract will not be activated until 65% of Kerbin has LoRes data
maxCoverage = 100.0
minCoverage = 65.0


// The type of scan to perform. Valid values are from SCANdata.SCANtype.
scanType = AltimetryLoRes
}

REQUIREMENT
{
name = SCANsatCoverage3
type = SCANsatCoverage


targetBody = Mun


// Contract will not be activated until 15% of Mun has LoRes data
maxCoverage = 100.0
minCoverage = 15.0


// The type of scan to perform. Valid values are from SCANdata.SCANtype.
scanType = AltimetryLoRes
}

REQUIREMENT
{
name = SCANsatCoverage4
type = SCANsatCoverage


targetBody = Minmus


// The contract will not be activated if Minmus has 50% LoRes data
maxCoverage = 49.9
minCoverage = 0.0


// The type of scan to perform. Valid values are from SCANdata.SCANtype.
scanType = AltimetryLoRes
}
}



BEHAVIOUR
{
name = OrbitGenerator1
type = OrbitGenerator

// Use this to generate an orbit with specific parameters
FIXED_ORBIT
{
// Body for the orbit - defaulted from the contract if not supplied
targetBody = Minmus

// Actual orbit details. Note that REF represents the reference
// body - but will be overriden by the targetBody.

ORBIT
// Minmus surface is SMA = 60000
{
SMA = 133986
ECC = 0.0001
INC = 79.5
LPE = 90
LAN = 203
REF = 1
}
}
}
}

CONTRACT_TYPE:NEEDS[SCANsat]{

You're using the Duration parameter correctly - it should just make that parameter successful when the time elapses. If that made the contract complete, then the implication is that your SCANsat parameter was already completed.

There was a bug that tattagreis and I fixed a while back where SCANsat would report 100% scanned while it was still loading up. Our fix/workaround may not be working 100% from the sounds of it. Are you able to reproduce it, and confirm what the state of the SCANsat parameter is at various stages (ie. when does it go from grey to green)?

I'll also raise an enhancement to make it look like the RemoteTech coverage parameter - which actually displays the current coverage % in the text.

[notsorightstuph]

This Is awesome. I actually was scared off by the short description of this mod. The word syntax frightened me. But after reading on the remote tech pack and then finding the sacansat pack its a gotta have mod. I see from reading your all working on duration contracts. Cant wait for tac life support pack. Wink wink!

Also an idea, you can make contracts that include stock station parts. So it requires you to build a station using certain parts at a certain altitude for a certain duration making building stock stations an actual paying thing instead of waste of money for something everyone wants. I use station science but I really rather not. I try to stay away from parts packs for ram. Plus getting science is easy it funds that I struggle with.

Great work nightingale! KEEP THE PACKS COMING PLEASE!

[DBT85]

You're using the Duration parameter correctly - it should just make that parameter successful when the time elapses. If that made the contract complete, then the implication is that your SCANsat parameter was already completed.

There was a bug that tattagreis and I fixed a while back where SCANsat would report 100% scanned while it was still loading up. Our fix/workaround may not be working 100% from the sounds of it. Are you able to reproduce it, and confirm what the state of the SCANsat parameter is at various stages (ie. when does it go from grey to green)?

I'll also raise an enhancement to make it look like the RemoteTech coverage parameter - which actually displays the current coverage % in the text.

Ahh ok.

I'll attempt to make it happen again.

I'll also run some tests with short durations and several scansat parameters to see them getting checked off.

[Jim DiGriz]

Nightingale, can you make a patch to allow specifying the longitude of the periapsis or apoapsis of an orbit or something similar in a contract? It seems like the stock contracts will do something like that, but I don't see the options in your wiki or the code.

EDIT: hmmmm... nm, I just found the BEHAVIOURS section and the OrbitGenerator...

Edited January 16, 2015 by Jim DiGriz

[DanBMan]

Should I be putting the contract packs in the contract configurator folder? Or have it separate in game data. They are no longer appearing, made a new carreer to test with enough science buff so I could unlock scanning and communication parts. Tried doing the first few stock contracts to see if they would appear but no luck. The previous version I used they all showed up, albiet somewhat oddly (gave me the option for a cover the entire solar system contract on day 1, 2 million advance). Did I do something wrong?

[DBT85]

If downloading and doing it manually, then they should be going into GameData/ContrackPacks/RemoteTech for the remote tech one. If CKAN is doing your downloads then it'll do it itself.

Not that it should matter IIRC.

Nightingale, I've managed to produce another version of my bug with the scan percentage, caught it on video.

In this instance the Mun jumped from "need 50% Lo Res Altimetry yo!" to "Done it dawg!" as soon as I entered the Muns SOI. Hadn't even turned on the scanner or got into orbit yet, Mun map was still reading 0.0% complete.

On my first try I couldn't get it to happen. I exited KSP, reloaded and started a new default career (exactly the same procedure as before), and then started the missions again. Kerbin was fine, Mun jumped as described above. Not yet redone Minmus to see if it does the same.

I can't see where SCANSat stores its data in relation to individual saves so I'm wondering if maybe it's not purging correctly when the game it trying to remove/overwrite an old save.

[nightingale]

Should I be putting the contract packs in the contract configurator folder? Or have it separate in game data. They are no longer appearing, made a new carreer to test with enough science buff so I could unlock scanning and communication parts. Tried doing the first few stock contracts to see if they would appear but no luck. The previous version I used they all showed up, albiet somewhat oddly (gave me the option for a cover the entire solar system contract on day 1, 2 million advance). Did I do something wrong?

If downloading and doing it manually, then they should be going into GameData/ContrackPacks/RemoteTech for the remote tech one. If CKAN is doing your downloads then it'll do it itself.

Not that it should matter IIRC.

This is spot on.

As far as them showing up early, it's very surprising, and it's not anything that I've heard of happening before. Let me know if you can reproduce this, and which contract(s) show up.

Nightingale, I've managed to produce another version of my bug with the scan percentage, caught it on video.

In this instance the Mun jumped from "need 50% Lo Res Altimetry yo!" to "Done it dawg!" as soon as I entered the Muns SOI. Hadn't even turned on the scanner or got into orbit yet, Mun map was still reading 0.0% complete.

On my first try I couldn't get it to happen. I exited KSP, reloaded and started a new default career (exactly the same procedure as before), and then started the missions again. Kerbin was fine, Mun jumped as described above. Not yet redone Minmus to see if it does the same.

I can't see where SCANSat stores its data in relation to individual saves so I'm wondering if maybe it's not purging correctly when the game it trying to remove/overwrite an old save.

I'll have to take a look. You say you have it on video, can you post that up?

[DanBMan]

Just updated remote tech and removed the extended contract window which seems to help, also did a reinstall of CC + the packs for good measure. Now the beginner contracts are showing up. I have not seen that particular bug again but I will keep an eye out for it if it does reoccur I will let you know, after all 2 million advance on day 1 is kind of cheap haha Although if it helps I was using version 0.5.1 before I updated and that is when I was offered the weird contract. Was likely due to me fudging something on the install though or not having the latest version of remote tech (released yesterday) installed.

[DBT85]

I'll have to take a look. You say you have it on video, can you post that up?

I do, its just a huge jump though as I was just outside SOI when I set a timer for Mun Pe and then hit time acceleration. When slowed down you can just about see it triggering at SOI change.

Just completed the Minmus mission and it didn't do it this time.

Will repeat the process again, I'm careful now to avoid time acceleration when crossing SOI and when near the duration expiring.

[nightingale]

I do, its just a huge jump though as I was just outside SOI when I set a timer for Mun Pe and then hit time acceleration. When slowed down you can just about see it triggering at SOI change.

Just completed the Minmus mission and it didn't do it this time.

Will repeat the process again, I'm careful now to avoid time acceleration when crossing SOI and when near the duration expiring.

Interesting, let me know how that goes - if it's an issue in SCANsat I'd like get something out to DMagic sooner rather than later, since I know he's in the midst of getting SCANsat 9.0 ready for prime time. But what you've said so far has been helpful.