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

[nightingale]

One of the things that I think the stock part test contracts did really well was the way they broke up the parameters. For example (the text is probably wrong, going from memory):

Speed: Between 100 m/s and 1000 m/s: Complete

Altitude: Between 1000 m and 3000 m: Incomplete

Test LV-909: Incomplete

This way the player knows very easily what is missing before they can do their part test. This rule should apply to any parameter that is "composite" in nature. A counter example is the 0.90 waypoint ones - you have to visit a waypoint and do a science report of some kind - but it's all baked in one parameter (plug: In-Flight Waypoints helps here). One of the things that I've tried very hard to do with Contract Configurator is to keep parameters atomic - ie. it should be up to the person writing the contract config to put the pieces together. However, there's a few cases where I've gone away from that for various reasons - one of the main ones is simplicity, I don't want the contract configs to get ridiculously complicated.

So, how to keep simple configuration but give the player the information they need? Introducting... Parameter Delegates. It's a fancy term that you really don't need to know - in a nutshell it's one parameter that automatically splits into parts. I'll use one of the upcoming RemoteTech parameters, as an example, the HasAntenna parameter.

Here we have our beautiful and functional test craft. You can see the "Antenna" parameter in the contract window in the top right corner. The parameters complete from top to bottom, which is important because you could have many Antenna that partially meet the requirement. Let's see what happens when we target Duna.

We now have two check marks! If I was a newbie RemoteTech player, I might have no idea why my antenna isn't connecting... unless of course I look at the big red X staring me in the face! So let's activate the antenna...

And there we go, with the Antenna active we get the rest of our check marks. And because the stock contract app doesn't display the details of child parameters when the parent is completed, I automatically roll up the significant parts of the text.

The best part? You get all this out of just this PARAMETER node in the config file:

    PARAMETER
    {
        name = HasAntenna
        type = HasAntenna

        minCount = 1
        maxCount = 3

        targetBody = Duna

        antennaType = Dish
    }

Right now there's just the one parameter using this system, but I'll be converting at least one more to this system before 0.5.0 is released. I'm excited about this release - there's lots of little polish items like this that are going into it.

[DBT85]

Just downloaded this to try out tattagreis SCANSat contract and am very impressed!

Good work to all involved!

I'm tempted to try and add to his pack but I think it's a bit beyond me right now!

With contracts for that and Remote Tech satellites are much better!

[hakan]

I'm excited about this release - there's lots of little polish items like this that are going into it.

Wow, this is a really cool feature. I could already imagine a contract set teaching people how to properly set up communication networks

[DBT85]

Just thought I'd post this up.

I fiddled a little with the pack from tattagreis to change the orbit and add the nice orbit line, so recorded myself from start to finish accepting the contract and completing the contract!

Real time took about 22 minutes with a bunch of time acceleration (7 in game days). Cut down to just 3:19 for you folks. Sorry for no talking, I have no mic.

[zcaalock]

are you going to implement any ingame ui for making custom contracts ingame?

Edited January 7, 2015 by zcaalock

[DBT85]

If you're talking about the one that appears on the right hand side, that's Contract Window +.

Nighingale and tattagreis I wonder if you can help.

I've used the following to set the orbit for the display and also for contract completion

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


        // Actual orbit details. Note that REF represents the reference
        // body - but will be overriden by the targetBody.
        ORBIT
        {
            SMA = 1090000
            ECC = 0.0012841657
            INC = 80
            LPE = 270
            LAN = 0
            MNA = 1.55872660382504
            EPH = 31.3999999999994
            REF = 1
        }
    }

That's generating an orbit with a PE of 488,600 and AP of 491,400 with the INC, LPE and LAN you can see above.

Is there a way to directly pull the PE, AP, INC, LPE and LAN created from this and put them into the body of the contract?

Currently I've tried using the following which just puts a rather generic "Reach the designated orbit around Kerbin within marginal deviation" as a contract check.

PARAMETER
        {
        name = ReachSpecificOrbit1
        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 = 1.0
        }

Also, I've included screens of the contract at this stage. I've added the checks for altitude and calculated the min and max Ap and Pe that it should trigger at to fill it out a bit more. I do however have an odd extra ": complete" just above the "reach designated orbit" part of the active contract shot.

Javascript is disabled. View full album

Edited January 7, 2015 by DBT85

[nightingale]

Just thought I'd post this up.

I fiddled a little with the pack from tattagreis to change the orbit and add the nice orbit line, so recorded myself from start to finish accepting the contract and completing the contract!

Real time took about 22 minutes with a bunch of time acceleration (7 in game days). Cut down to just 3:19 for you folks. Sorry for no talking, I have no mic.

Wow, nice video - have some rep! That's the problem with those "specific orbit" style contracts... they are so much more restrictive than the way tattagreis did it, but so much prettier.

are you going to implement any ingame ui for making custom contracts ingame?

Definitely not. The idea was that Contract Configurator would be a modder's tool for making contracts more easily. An ingame ui for it would be difficult, and I don't personally see the benefit.

[Exitalterego]

So, I'm going to post this here as I'm not really sure where else to put it.

I've just started a new career game with CC installed alongside the SCANSat mission pack created by tattagreis. Both mod and mission pack were installed via CKAN.

However, I very rapidly ran into a bug that for some reason prevented me from completing any part testing missions, the essence of which was that contract triggers involving value ranges weren't triggering and as such weren't allowing contracts to be completed.

I created a support forum thread about it ([thread=106380]Contract Terms Not Triggering[/thread]) and posted my log file in the thread.

Someone kindly looked through the log and pointed out that CC seemed to be throwing some suspicious things into the log file (details in the support thread).

Initially, this made me think that there was a bug in CC but after some testing, I've narrowed it down to the SCANSat pack (uninstalled both CC and mission pack, contracts completed; reinstalled CC, contracts completed; reinstalled mission pack, problems started).

As I said, I know that nightingale didn't create the mission pack, but equally it doesn't have it's own forum post so.....

I hope this is helpful to someone and if anyone needs me to do more testing to narrow it down, I'll be happy to help.

[nightingale]

So, I'm going to post this here as I'm not really sure where else to put it.

I've just started a new career game with CC installed alongside the SCANSat mission pack created by tattagreis. Both mod and mission pack were installed via CKAN.

However, I very rapidly ran into a bug that for some reason prevented me from completing any part testing missions, the essence of which was that contract triggers involving value ranges weren't triggering and as such weren't allowing contracts to be completed.

I created a support forum thread about it ([thread=106380]Contract Terms Not Triggering[/thread]) and posted my log file in the thread.

Someone kindly looked through the log and pointed out that CC seemed to be throwing some suspicious things into the log file (details in the support thread).

Initially, this made me think that there was a bug in CC but after some testing, I've narrowed it down to the SCANSat pack (uninstalled both CC and mission pack, contracts completed; reinstalled CC, contracts completed; reinstalled mission pack, problems started).

As I said, I know that nightingale didn't create the mission pack, but equally it doesn't have it's own forum post so.....

I hope this is helpful to someone and if anyone needs me to do more testing to narrow it down, I'll be happy to help.

Well, the SCANsat pack just uses the inherent SCANsat integration in Contract Configurator - so CC is still to blame. Anyway, as Arsonide pointed out in your thread, this seems to be the culprit:

[INFO] ContractConfigurator.ContractConfigurator: Disabled 0 ContractTypes.
 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)
[INFO] ContractConfigurator.ContractConfigurator: Finished Adjusting ContractTypes
(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)
MissingMethodException: Method not found: 'SCANsat.SCANUtil.GetCoverage'.
  at ContractConfigurator.ContractRequirement.RequirementsMet (ContractConfigurator.ConfiguredContract contract, System.Collections.Generic.List`1 contractRequirements) [0x00000] in <filename unknown>:0 
  at ContractConfigurator.ContractType.MeetRequirements (ContractConfigurator.ConfiguredContract contract) [0x00000] in <filename unknown>:0 
  at ContractConfigurator.ConfiguredContract.SelectContractType () [0x00000] in <filename unknown>:0 
  at ContractConfigurator.ConfiguredContract.MeetRequirements () [0x00000] in <filename unknown>:0 
  at Contracts.Contract.Generate (System.Type contractType, ContractPrestige difficulty, Int32 seed, State state) [0x00000] in <filename unknown>:0 
  at Contracts.ContractSystem.GenerateContract (Int32 seed, ContractPrestige difficulty, System.Type contractType) [0x00000] in <filename unknown>:0 
  at Contracts.ContractSystem.GenerateContract (System.Int32& seed, ContractPrestige difficulty) [0x00000] in <filename unknown>:0 
  at Contracts.ContractSystem.GenerateContracts (System.Int32& seed, ContractPrestige difficulty, Int32 count) [0x00000] in <filename unknown>:0 
  at Contracts.ContractSystem.RefreshContracts () [0x00000] in <filename unknown>:0 
  at Contracts.ContractSystem+.MoveNext () [0x00000] in <filename unknown>:0

The obvious issue from that message would've been that SCANsat isn't installed, but it does look like it's installed and loading properly (plus the ModuleManager dependency would've prevented the SCANsat contracts from loading at all if SCANsat wasn't installed).

Anway, I need to dig into this one a little bit more.

[hakan]

@Exitalterego , which version of SCANsat do you have installed?

[nightingale]

Oh my, I see the problem - looks like the method that was used only exists in the 9.0 SCANsat pre-release. So there's your workaround at least - upgrade SCANsat to the dev version on their GitHub. In the meantime I'll see if I can get a fix out that works for both SCANsat 8.1 and 9.0.

- - - Updated - - -

Nope, I don't see any way to easily get it working (with reasonable performance) under SCANsat 8.1. I'm *hoping* that SCANsat 9.0 is going to be released reasonably soon, since I know most people who want Regolith (ie. anything USI) support are already on that version.

In the meantime I'll send a pull request on the NetKAN file for the SCANsat contracts to change the required version of SCANsat to 9.0. What this means for users is they will effectively not be able to download the contract pack via CKAN until SCANsat is updated (at which point everything should magically work again).

As a more general item I'm going to see if I can put some exception handling logic (the contract system in its entirety seems to just fall over on any exception) to limit the damage caused by this type of issue. In your case it would mean that the SCANsat contract would be broken, but it wouldn't randomly affect stuff like the part test contracts.

[Exitalterego]

@hakan

8.1. It's the most up-to-date version that CKAN has.

And thanks nightingale for looking at this. At least I know it wasn't anything I did!

I'll wait for SCANSat 9.0 before using the mission pack then

Edited January 7, 2015 by Exitalterego

[DBT85]

@hakan

8.1. It's the most up-to-date version that CKAN has.

And thanks nightingale for looking at this. At least I know it wasn't anything I did!

I'll wait for SCANSat 9.0 before using the mission pack then

Yeah, CKAN wont show you dev builds and stuff which is what the CC mission pack is set to use as hopefully it'll be released soon.

I've been using 9.0 today with no issues to my knowledge.

[hakan]

In the meantime I'll send a pull request on the NetKAN file for the SCANsat contracts to change the required version of SCANsat to 9.0. What this means for users is they will effectively not be able to download the contract pack via CKAN until SCANsat is updated (at which point everything should magically work again).

Just merged your PR. Kudos, Sir, I did not even know we had a "min_version" thingy there

On the other hand, now we really have to wait until SCANsat makes a real 9.x release. Either that or I debug my multi-repo thingy for CKAN so you can reliably install and update pre-release versions.

[nightingale]

Just merged your PR. Kudos, Sir, I did not even know we had a "min_version" thingy there

On the other hand, now we really have to wait until SCANsat makes a real 9.x release. Either that or I debug my multi-repo thingy for CKAN so you can reliably install and update pre-release versions.

I sent a PM to DMagic to see if he'd divulge his timeline to me.

I'm hoping 9.0 would be out pretty quick - considering it's what needed for Regolith support, and there's a LOT of people using the USI mods that are likely also using SCANsat.

[DBT85]

Nightingale, I've noticed a issue with the following code and a variation of it

PARAMETER    {
        name = VesselParameterGroup1
        type = VesselParameterGroup

        duration = 4d

        title = Hold the satellite in position to completely scan the surface.

        PARAMETER
        {
            name = OrbitApoapsis1
            type = OrbitApoapsis


            minApA = 70000
            maxApA = 80000
        }

        PARAMETER
        {
            name = OrbitPeriapsis1
            type = OrbitPeriapsis


            minPeA = 700000
            maxPeA = 800000
        }

        PARAMETER
        {
            name = OrbitInclination1
            type = OrbitInclination


            minInclination = 82.3
            maxInclination = 83.6
        }
    }

It's checking to see that your orbit is inside those parameters. However, I've noticed that once you hit one of those parameters, it gets checked. But if you then move your orbit out of those parameters it doesn't uncheck. It's like its only checking that you've been there at some point, not currently in that orbit.

What it means is that if at any point in my ascent to orbit I manage to get an inclination of between 82.3 and 83.6 degrees, that part of the contract is complete, even if I then move on to another inclination/orbit entirely.

should it not be checking in these instance that you are IN that orbit, not HAVE BEEN in that orbit?

I know in the code above the values for Apoapsis and Periapsis should be the other way around, but that's not my code . In my version its correct and still does the same thing.

Edited January 7, 2015 by DBT85

[nightingale]

Nightingale, I've noticed a issue with the following code and a variation of it

PARAMETER    {
        name = VesselParameterGroup1
        type = VesselParameterGroup

        duration = 4d

        title = Hold the satellite in position to completely scan the surface.

        PARAMETER
        {
            name = OrbitApoapsis1
            type = OrbitApoapsis


            minApA = 70000
            maxApA = 80000
        }

        PARAMETER
        {
            name = OrbitPeriapsis1
            type = OrbitPeriapsis


            minPeA = 700000
            maxPeA = 800000
        }

        PARAMETER
        {
            name = OrbitInclination1
            type = OrbitInclination


            minInclination = 82.3
            maxInclination = 83.6
        }
    }

It's checking to see that your orbit is inside those parameters. However, I've noticed that once you hit one of those parameters, it gets checked. But if you then move your orbit out of those parameters it doesn't uncheck. It's like its only checking that you've been there at some point, not currently in that orbit.

What it means is that if at any point in my ascent to orbit I manage to get an inclination of between 82.3 and 83.6 degrees, that part of the contract is complete, even if I then move on to another inclination/orbit entirely.

should it not be checking in these instance that you are IN that orbit, not HAVE BEEN in that orbit?

I know in the code above the values for Apoapsis and Periapsis should be the other way around, but that's not my code . In my version its correct and still does the same thing.

It's a... "feature". The parameter system has a flag called "disableOnStateChange", which defaults to true. What this means is that the parameter is "disabled" when its state changes to complete - ie. once you hit the target ApA/PeA it'll lock it to complete, which isn't what you want. I've exposed this parameter, so you can just use disableOnStateChange = false in your parameters.

In 0.5.0 I got annoyed with how unintuitive this is - so I've changed the default value on a per parameter basis to be more sensible. In short, when 0.5.0 gets released your contract will work exactly as you expected it to.

[DBT85]

Ah ha. Marvellous!

You are doing sterling work. I look forward to the progress of this mod and your way points!

[tattagreis]

I changed the title to make it more clear that version 9.0 is needed. I already mentioned it in the readme, but who reads it?

[DBT85]

I'm doing a 15 hours shift at work today with very little to do, so I'm going to try and make a few more contracts for the SCANSat pack. I know you said to wait for 0.5 but I can tweak later and I'm bored lol.

[nightingale]

I changed the title to make it more clear that version 9.0 is needed. I already mentioned it in the readme, but who reads it?

Clearly I didn't, although I do remember now you mentioned that it was on the 9.0 release.

I'm doing a 15 hours shift at work today with very little to do, so I'm going to try and make a few more contracts for the SCANSat pack. I know you said to wait for 0.5 but I can tweak later and I'm bored lol.

I'm sure tattagreis would look at a pull request if you want to send them to him.

[nightingale]

Version 0.5.0 is out, and a bonus. Download it now!

And a bonus! The RemoteTech Contract Pack.

Contract Configurator 0.5.0

• RemoteTech integration!
  
  • KSCConnectivity parameter - indicates that a vessel must have connectivity back to mission control.
    
  • HasAntenna parameter - indicates that a vessel must have one or more antenna that meet specific criteria.
    
  • SignalDelay parameter - requires a min/max signal delay for a connection.
    
  • VesselConnectivity parameter - checks for connectivity between two vessels.
    
  • CelestialBodyCoverage parameter - verifies that there is communication coverage of a celestial body.
    
  • ActiveVesselRange requirement - requires that a celestial body has a satellite with a minimum active vessel range (achievable via either an omni antenna or dish targetting active vessel).
    
  • CelestialBodyCoverage requiremnt - requirement for having a dish pointed at the given celestial body.
    

  [*]Vessel tracking!

  • New define attribute of VesselParameterGroup to associate the ship that completes the parameter to the given name.
    
  • New vessel attribute of VesselParameterGroup to require a specific vessel (previously defined using define) to be the one to complete the parameter.
    
  • IsNotVessel parameter for exclusion (eg. to have two VesselParameterGroup parameters in a contract that must be met by different vessels).
    

  [*]Added Duration parameter.

  [*]Added PartValidator parameter and deprecated HasPart and HasPartModule.

  [*]Merged all orbital parameters into Orbit parameter. Thanks ttagreis for contributions on altitude and period.

  [*]Added PartModuleTypeUnlocked requirement.

  [*]Changed default values for disableOnStageChange in parameters to be more logical.

  [*]Added new validation to check for unexpected values in config nodes - helps when developing contract configuration.

  [*]Reloading contract types will also re-run module manager (which means you can now reload contract types that use module manager).

  [*]Minor bug fixes

Feature Spotlight: RemoteTech Integration

This one turned out to be a much bigger job than I expected! Five new parameters and two requirements doesn't sound like much, but there's a lot of stuff built into those parameters and requirements.

Feature Spotlight: RemoteTech Contract Pack

Did I mention, there's a RemoteTech Contract Pack? In the last release tattagreis was good enough to start us off with the SCANsat pack, and now I'm releasing my own. I'm hoping to periodically release these "official" contract packs - perhaps with each minor release of Contract Configurator? Who knows, maybe the next one will be even sooner!

Feature Spotlight: Better Error Messages!

Because of the contract pack, this is the first release where I've really had to use Ccontract Configurator. And not just testing, really using it and putting it through its paces. As such, I've a number of small bugs and cleaned up lots of error messages. The result is that it should be much harder to create an invalid contract without Contract Configurator telling you EXACTLY WHAT'S WRONG.

There's lots more, so have a look at the change log, and as always - happy contracting!

Edited January 8, 2015 by nightingale

[DBT85]

Looking forward to trying them all out and the new bits.

Hopefully other pick up the slack for all the orbital science type mods and stuff!

[scerion]

nightingale thank you as always The update looks awesome.

I'm confused by the documentation on VesselParameterGroups though... could you give a more clarified example?

Like would this work or do I need to change things? can parameters be updated to any newer ones (i.e. orbit?) or is this the simplest/most optimized way? Rather it instead of being "Just working" to it being "properly coded"

(Still the basic munar landing and planting a flag contract with using a specific craft)

CONTRACT_TYPE:NEEDS[!MechJeb2&!HyperEdit]

{

name = KSABKHW150110

title = KSA BootKamp 2015-01-10 Homework

description = Greetings Space Kadets! Here is the first Kerbal Space Academy Homework. Load up the KSA Munar Trainer mkIII in the VAB and go to the Mun! Once at the Mun, land the craft and plant your flag. Be sure to get a screenshot of the plaque with BootKamp 01-10 / YourTwitchUsername / DateComplete

synopsis = Complete the Homework Request below

completedMessage = You have completed the homework for Jan. 10th! Don't forget to screenshot!

agent = Kerbal Space Academy

cancellable = false

declinable = false

prestige = Trivial

maxCompletions = 1

maxSimultaneous = 1

advanceFunds = 35000

rewardScience = 25.0

rewardReputation = 100.0

rewardFunds = 100000.0

failureReputation = 10.0

failureFunds = 35000.0

PARAMETER

{

name = Sequence1

type = Sequence

title = Complete following in order & screenshot with plaque and craft.

PARAMETER

{

name = VesselParameterGroup1

type = VesselParameterGroup

vessel = KSA Munar Trainer

PARAMETER

{

name = EnterOrbit1

type = EnterOrbit

disableOnStateChange = false

targetBody = Kerbin

}

PARAMETER

{

name = EnterOrbit1

type = EnterOrbit

disableOnStateChange = false

targetBody = Mun

}

PARAMETER

{

name = LandOnBody1

type = LandOnBody

disableOnStateChange = false

targetBody = Mun

}

PARAMETER

{

name = PlantFlag1

type = PlantFlag

targetBody = Mun

}

}

}

}

[tjsnh]

WOO! Glad to see the update, I'll be playing around with it tomorrow and will post if I have any more of those issues from earlier in the week. Thanks so much for this mod!