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

nightingale · January 9, 2015

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

[B] PARAMETER
{
name = VesselParameterGroup1
type = VesselParameterGroup
vessel = KSA Munar Trainer
[/B]
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
}
}
}
}
CONTRACT_TYPE:NEEDS[!MechJeb2&!HyperEdit]

Tip: Wrap your contract configuration in

 tags to prevent the forum software from mangling it and eating all the whitespace (I added them when I quoted you above).
[/I]
I'll update the How To page with some examples around that - actually updating that page was next on my To-Do list anyway.  A quick explanation for the moment though:

The vessel tracking system currently has 3 components:
[LIST=1]
[*]Defining a vessel to be tracked
[*]Locking a contract parameter to one or more previously tracked vessels
[*]Preventing a contract parameter from being completed by one or more previously tracked vessel.
[/LIST]

[B]Defining a Vessel to be Tracked
[/B]To [I]define[/I] the tracked vessel, use the following within a VesselParameterGroup parameter node:
[code]define = Defined Vessel Name

What this will do is "track" the vessel that ends up completing the parameter under the tag "Defined Vessel Name". This tag is initially displayed to the user when they accept the contract, but once it gets assigned to a specific vessel they will see their vessel's name instead.

Locking a Parameter to a Vessel

To lock a parameter so that it can only be completed by a specific vessel, use the following within a VesselParameterGroup parameter node:

vessel = Defined Vessel Name

The name that is used needs to be one that was previously used in a define attribute. This can be in the same contract, or a different one. The name that is displayed to the user will be their vessel's name - not the one in the contract definition.

To see an example of this in use, take a look at the EverythingSat.cfg from the RemoteTech pack.

Preventing a Parameter from Being Completed by a Specific Vessel

This is done via the IsNotVessel parameter - use it as a child parameter in your VesselGroup to prevent certain previously defined vessels from completing the parameter.

I thought I had an example of this one, but realized that it's redundant in my case - I used VesselConnectivity which won't succeed if the source and destination vessel are the same. Anyway, take a look at KerbinRelay.cfg to see an example of where it could've been used.

Future Plans

VesselGenerator behaviour - I'd hoped to have it in this released, but it just got to the point where I wanted to get it out.
Requirement for a tracked vessel existing. I probably need this - will help keep contracts that cannot be completed from showing up. Or maybe I just make that logic automatic...

Anyway, hope that information helped - if not, let me know more about what you were thinking for your specific use case.

TL;DR - I suspect that you want define instead of vessel, as this looks like the first in a series of contracts.

tjsnh · January 9, 2015

Ok - not sure if I've run into a bug or an error in my configurations.

I have 3 contracts - one to orbit an unmanned probe, and a second to orbit a kerbal.

I completed the contract to orbit a kerbal. Everything works great, and the previous bug with the manned ship also counting as unmanned did not happen.

I went to do a probe, and as soon as the probe hit the launchpad I got the orbit-a-probe contract completed. It seems that the "reach orbit" carried over from the previous manned contract.

The third contract is to send a kerbal to another planet, I used an "any" objective just to put a kerbal into any other planet's SOI and return him home. I get the green checkmark even with a probe for 1 pilot crew, and the list of optional planet objectives doesnt show up on the checklist for the contract (but DOES show up in the contract building). Not sure if this is working as intended or if I need to configure the contract differently for what I'm trying to do.

Screenshot in VAB with probe core vessal (no crew) here http://imgur.com/SJalGDN

and CFG for the three contracts in the spoiler.

CONTRACT_TYPE{
name = FirstOrbitalSatellite
title = Launch the first orbital Satellite
description = Place a satellite into orbit around Kerbin. This will be a significant 'first' in our conquest of outer space!
synopsis = Put a satellite in orbit.
completedMessage = Success! We have placed the first artificial satellite in orbit around Kerbin!
agent = OKB-1
cancellable = false
declinable = false
prestige = Significant
targetBody = Kerbin
maxCompletions = 1
maxSimultaneous = 1
rewardScience = 50
rewardReputation = 20
rewardFunds = 50000
failureReputation = 10
failurefunds = 10000
advanceFunds = 10000
weight = 10.0
PARAMETER
{
name = VesselParameterGroup1
type = VesselParameterGroup
PARAMETER
{
name = HasCrew1
type = HasCrew
maxCrew = 0
minCrew = 0
}
PARAMETER
{
name = EnterOrbit1
type = EnterOrbit
// This can be inherited from the the contract type if necessary
targetBody = Kerbin
}
}
}
CONTRACT_TYPE
{
name = FirstMannedOrbital
title = Launch a Kerbal into orbit.
description = The next step on our race to the stars is to achieve orbit with a manned mission. Place a Kerbal in a stable orbit, we're all counting on you!
synopsis = Put Kerbal in orbit.
completedMessage = Success! We have placed the first Kerbal in orbit around Kerbin!
agent = OKB-1
cancellable = false
declinable = false
prestige = Significant
targetBody = Kerbin
maxCompletions = 1
maxSimultaneous = 1
rewardScience = 50
rewardReputation = 20
rewardFunds = 150000
failureReputation = 10
failurefunds = 10000
advanceFunds = 10000
weight = 10.0
PARAMETER
{
name = VesselParameterGroup2
type = VesselParameterGroup
PARAMETER
{
name = HasCrew2
type = HasCrew
trait = Pilot
minCrew = 1
}
PARAMETER
{
name = EnterOrbit2
type = EnterOrbit
// This can be inherited from the the contract type if necessary
targetBody = Kerbin
}
}
}
CONTRACT_TYPE
{
name = FirstPlanetaryFlyby
title = Launch a Kerbal to another planet.
description = We have reached the point where we are ready to start exploring the rest of the Kerbin system. Send a Kerbal on a return-trip to space near any other planet in the solar system, and bring him back to Kerbin safely.
synopsis = Send a Kerbal to another planet.
completedMessage = Success! We have returned a Kerbal to the ground after visiting space near another planet!
agent = OKB-1
cancellable = false
declinable = false
prestige = Significant
targetBody = Kerbin
maxCompletions = 1
maxSimultaneous = 1
rewardScience = 50
rewardReputation = 20
rewardFunds = 150000
failureReputation = 10
failurefunds = 10000
advanceFunds = 10000
weight = 10.0
PARAMETER
{
name = VesselParameterGroup4
type = VesselParameterGroup
PARAMETER
{
name = HasCrew4
type = HasCrew
trait = Pilot
minCrew = 1
}
PARAMETER
{
name = Any4
type = Any
PARAMETER
{
name = EnterSOI4001
type = EnterSOI
targetBody = Duna
}
PARAMETER
{
name = EnterSOI4002
type = EnterSOI
targetBody = Eve
}
PARAMETER
{
name = EnterSOI4003
type = EnterSOI
targetBody = Dres
}
PARAMETER
{
name = EnterSOI4004
type = EnterSOI
targetBody = Jool
}
PARAMETER
{
name = EnterSOI4005
type = EnterSOI
targetBody = Moho
}
PARAMETER
{
name = EnterSOI4006
type = EnterSOI
targetBody = Eeloo
}
}
PARAMETER
{
name = ReturnHome4
type = ReturnHome
}
}
}

nightingale · January 9, 2015

I went to do a probe, and as soon as the probe hit the launchpad I got the orbit-a-probe contract completed. It seems that the "reach orbit" carried over from the previous manned contract.

I'm going to the have clean up the documentation for EnterOrbit. That one, and the others under "Progression Parameters" are stock parameters, and they are all about progression. So entering orbit for the very first time is what makes it successful (it's what's used in the stock "Reach Orbit" contract). After that, it seems like it's just always successful automatically... so they are really one-time use.

You want to use ReachSituation instead:

PARAMETER
{
    name = ReachSituation
    type = ReachSituation

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

    // Text for the contract parameter.
    // Default = Situation: <situation>
    //title =
}

The third contract is to send a kerbal to another planet, I used an "any" objective just to put a kerbal into any other planet's SOI and return him home. I get the green checkmark even with a probe for 1 pilot crew, and the list of optional planet objectives doesnt show up on the checklist for the contract (but DOES show up in the contract building). Not sure if this is working as intended or if I need to configure the contract differently for what I'm trying to do.

Same issue as above, different type. You are looking for ReachDestination:

PARAMETER
{
    name = ReachDestination
    type = ReachDestination

    // This can be inherited from the the contract type if necessary
    targetBody = Duna

    // Text for the contract parameter.
    // Default = Destination: <targetBody>
    //title =
}

tjsnh · January 9, 2015

Awesome, I'll re-do them using ReachDestination / situation , thanks!

tjsnh · January 9, 2015

Ok, having some trouble getting the reachdestination and reachsituation to work how I wanted. Also, a question about VesselHasVisited

The objective is only "completed" _while_ the vessal is in those conditions. For example, I have a simple contract (in the spoiler) to send a kerbal into space, orbit kerbin, and land safely. It can't be completed, because reachsituation orbiting uncompletes itself after the retroburn, and obviously ReturnHome isn't completed while still in orbit. Is there a better way to do this contract?

Also, I tried using VesselHasVisited to do a mun flyby-and-return-safely mission but I couldn't get the flyby condition to complete. I flew in, and out, of the Mun SOI several times, no luck. Am I misunderstanding what "flyby" means for VesselHasVisited?

(I hope I'm not too annoying with my 50 questions)

CONTRACT_TYPE
{
name = FirstMannedOrbital
title = Launch a Kerbal into orbit.
description = The next step on our race to the stars is to achieve orbit with a manned mission. Place a Kerbal in a stable orbit, and bring him back alive. We're all counting on you!
synopsis = Put Kerbal in orbit.
completedMessage = Success! We have placed the first Kerbal in orbit around Kerbin and returned him to the surface alive!
agent = OKB-1
cancellable = false
declinable = false
prestige = Significant
targetBody = Kerbin
maxCompletions = 1
maxSimultaneous = 1
rewardScience = 50
rewardReputation = 20
rewardFunds = 150000
failureReputation = 10
failurefunds = 10000
advanceFunds = 10000
weight = 10.0
//REQUIREMENT
//{
// name = ReachSpace2
// type = ReachSpace
//}
PARAMETER
{
name = VesselParameterGroup2
type = VesselParameterGroup
PARAMETER
{
name = HasCrew2
type = HasCrew
trait = Pilot
minCrew = 1
}
PARAMETER
{
name = ReachSituation2
type = ReachSituation
situation = ORBITING
}
PARAMETER
{
name = ReachDestination2
type = ReachDestination
targetBody = Kerbin
}
PARAMETER
{
name = ReturnHome1
type = ReturnHome
}
}
}

EDIT: as a troubleshooting step, I tried using disableonstatechange = true , but it hasn't helped.

    PARAMETER
        {
            name = ReachSituation2
            type = ReachSituation
            situation = ORBITING
            disableOnStateChange = true
        }

Still uncompletes after de-orbit burn

Edited January 9, 2015 by tjsnh

scerion · January 9, 2015

Ok, having some trouble getting the reachdestination and reachsituation to work how I wanted. Also, a question about VesselHasVisited
The objective is only "completed" _while_ the vessal is in those conditions. For example, I have a simple contract (in the spoiler) to send a kerbal into space, orbit kerbin, and land safely. It can't be completed, because reachsituation orbiting uncompletes itself after the retroburn, and obviously ReturnHome isn't completed while still in orbit. Is there a better way to do this contract?
Also, I tried using VesselHasVisited to do a mun flyby-and-return-safely mission but I couldn't get the flyby condition to complete. I flew in, and out, of the Mun SOI several times, no luck. Am I misunderstanding what "flyby" means for VesselHasVisited?
(I hope I'm not too annoying with my 50 questions)
CONTRACT_TYPE
{
name = FirstMannedOrbital
title = Launch a Kerbal into orbit.
description = The next step on our race to the stars is to achieve orbit with a manned mission. Place a Kerbal in a stable orbit, and bring him back alive. We're all counting on you!
synopsis = Put Kerbal in orbit.
completedMessage = Success! We have placed the first Kerbal in orbit around Kerbin and returned him to the surface alive!
agent = OKB-1
cancellable = false
declinable = false
prestige = Significant
targetBody = Kerbin
maxCompletions = 1
maxSimultaneous = 1
rewardScience = 50
rewardReputation = 20
rewardFunds = 150000
failureReputation = 10
failurefunds = 10000
advanceFunds = 10000
weight = 10.0
//REQUIREMENT
//{
// name = ReachSpace2
// type = ReachSpace
//}
PARAMETER
{
name = VesselParameterGroup2
type = VesselParameterGroup
PARAMETER
{
name = HasCrew2
type = HasCrew
trait = Pilot
minCrew = 1
}
PARAMETER
{
name = ReachSituation2
type = ReachSituation
situation = ORBITING
}
PARAMETER
{
name = ReachDestination2
type = ReachDestination
targetBody = Kerbin
}
PARAMETER
{
name = ReturnHome1
type = ReturnHome
}
}
}
EDIT: as a troubleshooting step, I tried using disableonstatechange = true , but it hasn't helped.
    PARAMETER
        {
            name = ReachSituation2
            type = ReachSituation
            situation = ORBITING
            disableOnStateChange = true
        } 
Still uncompletes after de-orbit burn

you have disableOnStateChange = true, this needs to be false so that it'll stay checked.

DBT85 · January 9, 2015

you have disableOnStateChange = true, this needs to be false so that it'll stay checked.

Surely the opposite??

disableOnStateChange = true

means that when that parameter has been met disable the checks for that parameter going forward.

I'm tinkering with my SCANSat extension and I'll test this too.

tjsnh · January 9, 2015

you have disableOnStateChange = true, this needs to be false so that it'll stay checked.

Still nothing.

Ive tried disableonstatechange as both true, and false. I've tried defining it in the contract block, and inside the parameter blocks, still nothing. I can't seem to get the ReachSituation Orbiting to stay completed after the de-orbit burn no matter how I define the contract.

nightingale · January 9, 2015

Ok, having some trouble getting the reachdestination and reachsituation to work how I wanted. Also, a question about VesselHasVisited
The objective is only "completed" _while_ the vessal is in those conditions. For example, I have a simple contract (in the spoiler) to send a kerbal into space, orbit kerbin, and land safely. It can't be completed, because reachsituation orbiting uncompletes itself after the retroburn, and obviously ReturnHome isn't completed while still in orbit. Is there a better way to do this contract?
Also, I tried using VesselHasVisited to do a mun flyby-and-return-safely mission but I couldn't get the flyby condition to complete. I flew in, and out, of the Mun SOI several times, no luck. Am I misunderstanding what "flyby" means for VesselHasVisited?
(I hope I'm not too annoying with my 50 questions)
CONTRACT_TYPE
{
name = FirstMannedOrbital
title = Launch a Kerbal into orbit.
description = The next step on our race to the stars is to achieve orbit with a manned mission. Place a Kerbal in a stable orbit, and bring him back alive. We're all counting on you!
synopsis = Put Kerbal in orbit.
completedMessage = Success! We have placed the first Kerbal in orbit around Kerbin and returned him to the surface alive!
agent = OKB-1
cancellable = false
declinable = false
prestige = Significant
targetBody = Kerbin
maxCompletions = 1
maxSimultaneous = 1
rewardScience = 50
rewardReputation = 20
rewardFunds = 150000
failureReputation = 10
failurefunds = 10000
advanceFunds = 10000
weight = 10.0
//REQUIREMENT
//{
// name = ReachSpace2
// type = ReachSpace
//}
PARAMETER
{
name = VesselParameterGroup2
type = VesselParameterGroup
PARAMETER
{
name = HasCrew2
type = HasCrew
trait = Pilot
minCrew = 1
}
PARAMETER
{
name = ReachSituation2
type = ReachSituation
situation = ORBITING
}
PARAMETER
{
name = ReachDestination2
type = ReachDestination
targetBody = Kerbin
}
PARAMETER
{
name = ReturnHome1
type = ReturnHome
}
}
}
EDIT: as a troubleshooting step, I tried using disableonstatechange = true , but it hasn't helped.
    PARAMETER
        {
            name = ReachSituation2
            type = ReachSituation
            situation = ORBITING
            disableOnStateChange = true
        } 
Still uncompletes after de-orbit burn

Hmmm.... the best way to do it without any issues that I can come up with would be using the new vessel tracking feature:

PARAMETER
{
    name = Sequence
    type = Sequence

    title = Reach orbit of Kerbin and come back home

    PARAMETER
    {
        name = VesselParameterGroup2
        type = VesselParameterGroup

        define = Kerbin Orbiter

        PARAMETER
        {
            name = HasCrew2
            type = HasCrew
            trait = Pilot
            minCrew = 1
        }

        PARAMETER
        {
            name = ReachSituation2
            type = ReachSituation
            situation = ORBITING
        }

        PARAMETER
        {
            name = ReachDestination2
            type = ReachDestination
            targetBody = Kerbin
        }
    }

    PARAMETER
    {
        name = VesselParameterGroup3
        type = VesselParameterGroup

        vessel = Kerbin Orbiter

        PARAMETER
        {
            name = ReturnHome1
            type = ReturnHome
         }
    }
}

Every other option I could think of seems to leave some gap or another (ie. reach orbit with vessel x, but "return home" with vessel y).

tjsnh · January 9, 2015

Hmmm.... the best way to do it without any issues that I can come up with would be using the new vessel tracking feature:

Doesn't this mean that the vessel will need to have a pre-defined name?

For example, the rocket/capsule would need to be named Kerbin Orbiter when built in the VAB?

- - - Updated - - -

(For context, I'm working on drafting up a set of alternate "progression" contracts to replace, or supplement, the base squad ones. Trying to add more "space race" type milestones. Once I get it up and working, I'll be posting a download link to share)

nightingale · January 9, 2015

Still nothing.
Ive tried disableonstatechange as both true, and false. I've tried defining it in the contract block, and inside the parameter blocks, still nothing. I can't seem to get the ReachSituation Orbiting to stay completed after the de-orbit burn no matter how I define the contract.

disableOnStateChange = true should work for this, unless I somehow broke it in 0.5.0. A quick review of the code looks good - but I won't be able to test myself this until the evening.

I thought I saw an issue with it - but it was because I thought you'd want it on the destination=Kerbin bit too. But you'd need to come back to return home anyway, so that part doesn't need to be locked down. I'll play with this when I can, see if there's a bug.

- - - Updated - - -

Doesn't this mean that the vessel will need to have a pre-defined name?
For example, the rocket/capsule would need to be named Kerbin Orbiter when built in the VAB?
- - - Updated - - -
(For context, I'm working on drafting up a set of alternate "progression" contracts to replace, or supplement, the base squad ones. Trying to add more "space race" type milestones. Once I get it up and working, I'll be posting a download link to share)

I need to document this part better. The "defined" name and the player-chosen name are independent. define= means "the vessel that meets this parameter shall internally be known under this tag" (I really should've used the term tag). name= mean "This parameter can only be met by the vessel that was previously tagged with this name".

tjsnh · January 9, 2015

The sequenced example you posted worked perfectly. Thanks so much, this is going to serve as the template for tons of other contracts.

The functionality is a lot more object oriented than I had originally thought, the define= makes sense from an OO standpoint - I just wasn't thinking in those terms.

Is it safe to assume that vessel = Whatever should be unique to each contract, assuming the player is intended to only be doing one at a time? It looks like the 'state' will carry through cross-contract otherwise?

vessel = kerbin orbiter

vessel = munar flyby

vessel = minmus lander

so on, and so on?

Edited January 9, 2015 by tjsnh

nightingale · January 9, 2015

The sequenced example you posted worked perfectly. Thanks so much, this is going to serve as the template for tons of other contracts.
The functionality is a lot more object oriented than I had originally thought, the define= makes sense from an OO standpoint - I just wasn't thinking in those terms.
Is it safe to assume that vessel = Whatever should be unique to each contract, assuming the player is intended to only be doing one at a time? It looks like the 'state' will carry through cross-contract otherwise?
vessel = kerbin orbiter
vessel = munar flyby
vessel = minmus lander
so on, and so on?

Correct - it's meant to support vessel tracking *across* contracts (it's just a bonus that it supports it within contracts). So once the vessel is associated with that name, it's associated with it forever.

Now, if you have another contract with "define = Same Name As Before", then it will actually associate a new vessel with that name (there can only be one vessel associated to a name, but a vessel can be associated to many names/tags) - but only once the vessel meets the VesselParameterGroup parameter. So if the old one is still out there, there's a possibility *it* could meet the ReturnHome parameter (or whatever it ends up being). So there's lots of little things to think about, but it could still work with name reuse. But safest is just to use unique names as in your example.

DBT85 · January 9, 2015

Nightingale, does the Orbit Generator Behaviour automatically add a ReachSpecificOrbit parameter to contracts? Only the one I'm playing with has a behaviour to generate the orbit, but I've not added the ReachSpecificOrbit myself, but the contract doe indeed have that once accepted in the game.

Could I not instead use the Orbit Generator Behaviour to generate a pretty line simply as a suggested orbit, and then use a usual set of Parameters in the contract to achieve the correct Ap, Pe, INC and ECC?

nightingale · January 9, 2015

Nightingale, does the Orbit Generator Behaviour automatically add a ReachSpecificOrbit parameter to contracts? Only the one I'm playing with has a behaviour to generate the orbit, but I've not added the ReachSpecificOrbit myself, but the contract doe indeed have that once accepted in the game.
Could I not instead use the Orbit Generator Behaviour to generate a pretty line simply as a suggested orbit, and then use a usual set of Parameters in the contract to achieve the correct Ap, Pe, INC and ECC?

When you say that it does indeed have it once accept in the game - do you mean in the contract window (stock or otherwise, but please specify) or in the persistence file?

Because of the way the orbit system works, the only way to get the orbit lines to render properly is to have a stock ReachSpecificOrbit parameter in the contract. Because I want to separate the behaviour and the parameter, I generate one as part of the behaviour, but wrap it in an special "AlwayTrue" parameter - which is always completed and invisible (at least, supposed to be). If you choose to have a ReachSpecificOrbit parameter in your contract, I actually create a different one under the hood that mirrors the parameter that was added for rendering.

TD;DR: It's complicated under the hood and there could be bugs, but what you want to do is supposed to be supported.

Actually a nice feature would be to do away with ReachSpecificOrbit and add support to "reading" the orbit into a HasOrbit parameter. It's not trivial though, so although I'll put it on the roadmap, there's no promises.

tjsnh · January 9, 2015

Next stupid question - what is the range of the variable "weight = X" for a contract? The examples set weight to 10, but is 10 the max?

(the weight variable that sets the chance for the contract to be available in the first place)

nightingale · January 9, 2015

Next stupid question - what is the range of the variable "weight = X" for a contract? The examples set weight to 10, but is 10 the max?
(the weight variable that sets the chance for the contract to be available in the first place)

double.MaxValue, or in normal person speak, 1.7976931348623157E+308. Actually, it's more like sum(<all loaded contracts's weights>) must be less than double.MaxValue. Either way - pretty big.

The weight is compared against all other ContractConfigurator contracts. So what you're setting is the relative priority. If you have two contracts, one with a weight of 100, another with the default of 1, then it's roughtly a 99% chance that the one with a weight of 100 is chosen when selecting a new contract to be offered. Do something like this if you have a contract that MUST be offered, but you should then do something like set maxSimultaneous or MaxCompletions so it can't show up many times. Similarly, if you want a rare contract that the player should snap up if they ever see it, you can do a weight of 0.1 or 0.01.

Of course I could then come along and give my contract a weight of 10000, which means it'll pretty much always get chosen over yours. The best you can do is assume most contracts have a weight of 1, and then think in terms of how many times more (or less) likely you want it to be for your contract to show up.

tjsnh · January 9, 2015

Perfect, thank you.

Indeed, for some of the "progression"-ish contracts I want them to basically always come up once the player is eligible. I'll default them to 200 for now and see how it goes.

DBT85 · January 9, 2015

When you say that it does indeed have it once accept in the game - do you mean in the contract window (stock or otherwise, but please specify) or in the persistence file?
Because of the way the orbit system works, the only way to get the orbit lines to render properly is to have a stock ReachSpecificOrbit parameter in the contract. Because I want to separate the behaviour and the parameter, I generate one as part of the behaviour, but wrap it in an special "AlwayTrue" parameter - which is always completed and invisible (at least, supposed to be). If you choose to have a ReachSpecificOrbit parameter in your contract, I actually create a different one under the hood that mirrors the parameter that was added for rendering.
TD;DR: It's complicated under the hood and there could be bugs, but what you want to do is supposed to be supported.
Actually a nice feature would be to do away with ReachSpecificOrbit and add support to "reading" the orbit into a HasOrbit parameter. It's not trivial though, so although I'll put it on the roadmap, there's no promises.

// Created by tattagreis and modified by DBT85
// 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
// Thanks you nightingale for creating CC!

name = ScanKerbinLoRes

// Contract text
title = Altimetry Scan of Kerbin
description = Our scientists have suggested that knowing what the rock we're flying around looks like might ge a good idea. Perform an altimetry scan of Kerbin's surface and report back with the answer to the ultimate question, "Where did I put my keys?".
synopsis = Send an unkerbaled vessel into orbit, reach a 490km orbit with an 80 decgree inclination and scan Kerbin's surface with the SCAN Radar Altimetry Sensor. You'll see your suggested orbit in the Tracking Station.
completedMessage = Excellent work, despite the grainy monochrome image we've recovered our experts are very excited to see what they can find.

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

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

// Contract rewards
advanceFunds = 10000.0
rewardScience = 25.0
rewardReputation = 40.0
rewardFunds = 40000.0

// Can only be done once
maxCompletions = 1

// Prestige level 2
prestige = Significant

PARAMETER
{

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

define = Maxwell I
disableOnStateChange = false

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

PARAMETER
{
name = HasPart1
type = HasPart

part = SCANsat_Scanner
minCount = 1
}
}

PARAMETER
{
title = Achieve an orbit with the following parameters
name = Orbit
type = Orbit
targetBody = Kerbin
minApA = 486534
maxApA = 496314
minPeA = 483762
maxPeA = 493486
minEccentricity = 0.0
maxEccentricity = 0.002
minInclination = 79.2
maxInclination = 80.8
disableOnStateChange = false
}

PARAMETER
{
name = Duration
type = Duration

duration = 2d

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

PARAMETER
{
name = SCANsatCoverage1
type = SCANsatCoverage

// Get 50% coverage to complete
coverage = 50.0
scanType = AltimetryLoRes
}

REQUIREMENT
{
name = PartUnlocked1
type = PartUnlocked

// Part name that needs to be unlocked.
part = SCANsat_Scanner
}

REQUIREMENT
{
name = SCANsatCoverage2
type = SCANsatCoverage

targetBody = Kerbin

// Maximum coverage that must be reached before the contract is valid.
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 = Kerbin

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

ORBIT
// Kerbin surface is SMA = 600000
{
SMA = 1090000
ECC = 0.00128
INC = 80
LPE = 270
LAN = 27
MNA = 1.55872660382504
EPH = 31.3999999999994
REF = 1
}
}
}

}
CONTRACT_TYPE:NEEDS[SCANsat]{

And here are the two windows for the contract, before acceptance and after, as well as some snaps from the mission so you can see both the stock and Contracts Window+. It appears that the "Reach the designated Orbit with minimal deviation" is only appearing in Contract Window + and not the stock, though it does appear in the accepted contracts window. It also didn't prevent me completing the mission when I was matching all of the Parameters that I put in the contract myself.

I can also report that disableOnStateChange = false

was working exactly as expected in my contract.

Javascript is disabled. View full album

Edited January 9, 2015 by DBT85

nightingale · January 9, 2015

And here are the two windows for the contract, before acceptance and after, as well as some snaps from the mission so you can see both the stock and Contracts Window+. It appears that the "Reach the designated Orbit with minimal deviation" is only appearing in Contract Window + and not the stock, though it does appear in the accepted contracts window. It also didn't prevent me completing the mission when I was matching all of the Parameters that I put in the contract myself.
I can also report that disableOnStateChange = false
was working exactly as expected in my contract.
http://imgur.com/a/dyGEF
// Created by tattagreis and modified by DBT85
// 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
// Thanks you nightingale for creating CC!

name = ScanKerbinLoRes

// Contract text
title = Altimetry Scan of Kerbin
description = Our scientists have suggested that knowing what the rock we're flying around looks like might ge a good idea. Perform an altimetry scan of Kerbin's surface and report back with the answer to the ultimate question, "Where did I put my keys?".
synopsis = Send an unkerbaled vessel into orbit, reach a 490km orbit with an 80 decgree inclination and scan Kerbin's surface with the SCAN Radar Altimetry Sensor. You'll see your suggested orbit in the Tracking Station.
completedMessage = Excellent work, despite the grainy monochrome image we've recovered our experts are very excited to see what they can find.

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

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

// Contract rewards
advanceFunds = 10000.0
rewardScience = 25.0
rewardReputation = 40.0
rewardFunds = 40000.0

// Can only be done once
maxCompletions = 1

// Prestige level 2
prestige = Significant

PARAMETER
{

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

define = Maxwell I
disableOnStateChange = false

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

PARAMETER
{
name = HasPart1
type = HasPart

part = SCANsat_Scanner
minCount = 1
}
}

PARAMETER
{
title = Achieve an orbit with the following parameters
name = Orbit
type = Orbit
targetBody = Kerbin
minApA = 486534
maxApA = 496314
minPeA = 483762
maxPeA = 493486
minEccentricity = 0.0
maxEccentricity = 0.002
minInclination = 79.2
maxInclination = 80.8
disableOnStateChange = false
}

PARAMETER
{
name = Duration
type = Duration

duration = 2d

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

PARAMETER
{
name = SCANsatCoverage1
type = SCANsatCoverage

// Get 50% coverage to complete
coverage = 50.0
scanType = AltimetryLoRes
}

REQUIREMENT
{
name = PartUnlocked1
type = PartUnlocked

// Part name that needs to be unlocked.
part = SCANsat_Scanner
}

REQUIREMENT
{
name = SCANsatCoverage2
type = SCANsatCoverage

targetBody = Kerbin

// Maximum coverage that must be reached before the contract is valid.
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 = Kerbin

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

ORBIT
// Kerbin surface is SMA = 600000
{
SMA = 1090000
ECC = 0.00128
INC = 80
LPE = 270
LAN = 27
MNA = 1.55872660382504
EPH = 31.3999999999994
REF = 1
}
}
}

}
CONTRACT_TYPE:NEEDS[SCANsat]{

Ah, gotcha. So there's a couple things here:

There's logic to do a search and replace to hide the text in the mission window. It seems to work when the contract is available, but breaks when the contract is active. Bug, should hopefully be easy.
The stock app hides any parameter where the text is empty, as well as hiding all child parameters underneath that. It also hides child parameters when the parent completes (which is another story). The Contracts Window+ window obviously doesn't do these things. My preference is to get the behaviour of Contracts Window+ changed to match stock. I'll throw this up in DMagic's thread and see where it goes.

DBT85 · January 9, 2015

Excellent thanks.

I've also noticed on the Duration display in the contract window, it looks like it's adding a ":" both before and after the duration for the orbit to be maintained. so EG it says, "Hold this orbit for: 2 days: Incomplete"

Does that first one need to be there? or is just included in your string in line 66 of Duration.cs?

I suppose if you use the preceding text of "Time to wait" it looks ok.

nightingale · January 9, 2015

Excellent thanks.
I've also noticed on the Duration display in the contract window, it looks like it's adding a ":" both before and after the duration for the orbit to be maintained. so EG it says, "Hold this orbit for: 2 days: Incomplete"
Does that first one need to be there? or is just included in your string in line 66 of Duration.cs?
I suppose if you use the preceding text of "Time to wait" it looks ok.

The ": Incomplete" part is appended by the contract system, and I have no control over it. The pre-fine print stock contracts had a tendency to follow a <condition>: <value> (example "Alt: 1000m to 2000m"). I've tried to follow that convention in Contract Configurator, but you can override the title completely in 95% of parameters. Recently I've tried to be better in newer parameters (such as Duration) about giving the ability to set the text for different parts, to preserve the "count-down" logic, (which in my opinion in necessary to give the player the right feedback).

Anyway, for the duration one... let me think about it. It may look a little cleaner without the ':', and if someone wants it they can type it into their text.

nightingale · January 10, 2015

Version 0.5.1 is out, with fixes to work with the upcoming RemoteTech 1.6. Download it now!

Contract Configurator 0.5.1

Fixed to work with RemoteTech 1.6
Hide text for fake Parameters related to OrbitGenerator in mission control on active contracts.
Removed ':' from the Duration parameter default text.

DBT85 · January 10, 2015

Excellent work Nightingale!

I'm getting close to finishing my expanded SCANSat pack, hopefully the end of Monday.

In the meantime maybe for the documentation?

The game will multiply your rewards by the following, depending on the target body of the mission.

Kerbin = 1.25

Mun = 2.5

Minmus = 3.125

Eve = 6.25

Not got a chance to look at the others yet.

Setting the same 10k advance for missions to those three will mean a spread of 12,500, 25,000 and 31,250! Important if you want to get your rewards right for the missions.

Edited January 11, 2015 by DBT85

nightingale · January 10, 2015

In the meantime maybe for the documentation?
The game will multiply your rewards by the following, depending on the target body of the mission.
Kerbin = 1.25
Mun = 2.5
Minmus = 3.125
Not got a chance to look at the others yet.
Setting the same 10k advance for missions to those three will mean a spread of 12,500, 25,000 and 31,250! Important if you want to get your rewards right for the missions.

Thanks, I was aware of it, but hadn't formally documented anything. Note that the prestige values are also applying a multiplier, so that a Kerbin trivial contract has a 1.0 multiplier.

Basically, the way I tend to look at it is to just let the multipliers take care of it. In other words if you have two contracts that are effectively the same other than the target body, then just use the same funds/science/rep values. Or at least... use as a starting point. Jool has something like a 9.0 multiplier, which can really mess up your rep numbers.

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation