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

[alartor]

I guess you could always Alt+F12 those rewards out... Like, subtracting the corresponding amounts of Funds, Science and such... Tedious, I know, but should work...

[IO]

Is it not possible to get CelestialBody's Orbit? Looking into the documentation I only see SemiMajorAxis() which is... not a lot.

[siimav]

v2.7.0.0

What's Changed

• Fix fake failed parameters breaking on tracked VPG vessels. by @siimav in #30
• Fix Duration getting reset when wrapped inside Orbit by @siimav in #29
• Add update frequency attribute to parameters that rely on polling by @siimav
• Don't clobber loading screen tips when RP-1's installed by @NathanKell
• Update build actions to strip excess dlls by @NathanKell

Full Changelog: v2.6.6.0...v2.7.0.0

Edited December 10, 2023 by siimav

[siimav]

v2.8.0.0

What's Changed

• Add more math and orbit related functions by @IO5 in #32

Full Changelog: v2.7.0.0...v2.8.0.0

Edited December 13, 2023 by siimav

[silvermistshadow]

Is it possible to change the configurator settings in an existing save or do I have to start a new game whenever I add a contract pack I want to use?

[Aelfhe1m]

2 hours ago, silvermistshadow said:

Is it possible to change the configurator settings in an existing save or do I have to start a new game whenever I add a contract pack I want to use?

Newly added contract packs should be enabled by default, but yes you can access the customisation screens within a loaded save game.

In a loaded save, bring up the pause menu and click on the settings button. At the top of the settings screen is a button to access the mod configuration settings that were available during your new game setup, including picking which packs contract configurator will use.

[siimav]

v2.9.0.0

What's Changed

• Fix incorrect cc.req.CompleteContract.cooldown in localization by @IO5 in #33
• Fix Rendezvous Parameter check not honoring disableOnStateChange=false by @IO5 in #34
• Fix ArgumentNullException when using Expression and OrbitGenerator Behaviour together by @IO5 in #35
• Make usage of expressions in Contract Requirement possible by @IO5 in #36
• Fix vessel not getting dissassociated on contract completion by @IO5 in #37
• Fix HasCrew crewOnly attribute throwing harmless warnings by @siimav

Full Changelog: v2.8.0.0...v2.9.0.0

 

Edited January 8 by siimav

[dave1904]

For some reason i posted on wrong thread

Edited January 17 by dave1904

[Ooglak Kerman]

Is a MM

AFTER

statement for various contract bits advised if the contracts are part of a mod?  In this case an interstellar mod.

Edited March 5 by Ooglak Kerman

[Aelfhe1m]

8 hours ago, Ooglak Kerman said:

Is a MM

AFTER

statement for various contract bits advised if the contracts are part of a mod?  In this case an interstellar mod.

Most contracts use :NEEDS[modname] where they have a mod dependency but AFTER would work if it's absolutely needed.

If you're writing your own patch to modify an existing contract for use with a mod then using either NEEDS or AFTER in your MM patch should be fine.

[Ooglak Kerman]

5 hours ago, Aelfhe1m said:

Most contracts use :NEEDS[modname] where they have a mod dependency but AFTER would work if it's absolutely needed.

If you're writing your own patch to modify an existing contract for use with a mod then using either NEEDS or AFTER in your MM patch should be fine.

My current plan is to add the contracts into the interstellar mod, so it would be something like GameData/modname/ContractPack/
would this be appropriate?
CONTRACT_TYPE:NEEDS[ContractConfigurator]

Additionally, is there a more up-to-date wiki?  Looking through other ContractPacks, I keep finding stuff that is not in the wiki.

Edited March 5 by Ooglak Kerman

[Aelfhe1m]

10 hours ago, Ooglak Kerman said:

My current plan is to add the contracts into the interstellar mod, so it would be something like GameData/modname/ContractPack/
would this be appropriate?
CONTRACT_TYPE:NEEDS[ContractConfigurator]

Yes, CONTRACT_TYPE:NEEDS[ContractConfigurator] will mark the contract config node as only being added if Contract Configurator is present.

If you are bundling your contracts inside an existing mod then this is all you should need do. If you intend to ship the contract pack separately from the Interstellar mod then I would suggest extending this to NEEDS[modname,ContractConfigurator] so that they are only parsed if both mods are present.

10 hours ago, Ooglak Kerman said:

Additionally, is there a more up-to-date wiki?  Looking through other ContractPacks, I keep finding stuff that is not in the wiki.

The CC wiki is more or less up to date as far as I'm aware. Can you give some examples of the sort of features you are seeing that aren't documented?

[Ooglak Kerman]

44 minutes ago, Aelfhe1m said:

Yes, CONTRACT_TYPE:NEEDS[ContractConfigurator] will mark the contract config node as only being added if Contract Configurator is present.

If you are bundling your contracts inside an existing mod then this is all you should need do. If you intend to ship the contract pack separately from the Interstellar mod then I would suggest extending this to NEEDS[modname,ContractConfigurator] so that they are only parsed if both mods are present.

The CC wiki is more or less up to date as far as I'm aware. Can you give some examples of the sort of features you are seeing that aren't documented?

Thanks for the info.  This is quite the rabbit hole to go down.
There are 2 things I'm super struggling with though - both in regard to pqsCities.
I'd like to create a contract to go to an existing pqsCity on a body and once that has been completed, set the comnetStation property to True.  Any knowledge of if this is possible?

 

[Aelfhe1m]

28 minutes ago, Ooglak Kerman said:

Thanks for the info.  This is quite the rabbit hole to go down.
There are 2 things I'm super struggling with though - both in regard to pqsCities.
I'd like to create a contract to go to an existing pqsCity on a body and once that has been completed, set the comnetStation property to True.  Any knowledge of if this is possible?

 

CC has built in support for creating waypoints based on PQSCities, but the only behaviours associated with them that I'm aware of are through a Kerbal Konstructs extension with a very minimal (and undocumented) feature set.

Looking at the code on the CC GitHub the KK extension seems to offer:

Requirements: BaseClosed, BaseExists, BaseLocked, BaseOpened, BaseUnlocked

Behaviours: CloseBase, LockBase, OpenBase, UnlockBase

As far as I can see each requirement just takes a basename parameter and the behaviours take a basename and one or more Condition blocks.

[Ooglak Kerman]

On 3/5/2024 at 10:22 PM, Aelfhe1m said:

CC has built in support for creating waypoints based on PQSCities, but the only behaviours associated with them that I'm aware of are through a Kerbal Konstructs extension with a very minimal (and undocumented) feature set.

Looking at the code on the CC GitHub the KK extension seems to offer:

Requirements: BaseClosed, BaseExists, BaseLocked, BaseOpened, BaseUnlocked

Behaviours: CloseBase, LockBase, OpenBase, UnlockBase

As far as I can see each requirement just takes a basename parameter and the behaviours take a basename and one or more Condition blocks.

Thanks for looking into this.  I think that what I want would require a change to the City node in Kopernicus.

When using the SpawnPassengers BEHAVIOR, and then subsequently use the ChangeKerbalType BEHAVIOR, how do you reference the individual Kerbals if they are randomly generated?  Index?  Can you point me to an example?

[Aelfhe1m]

8 hours ago, Ooglak Kerman said:

When using the SpawnPassengers BEHAVIOR, and then subsequently use the ChangeKerbalType BEHAVIOR, how do you reference the individual Kerbals if they are randomly generated?  Index?  Can you point me to an example?

Yes, all the examples I know of use indexes. In principle, you could create a variable to hold the name of a specific kerbal if you were going to be referencing them frequently rather than indexing every time but I don't think I've ever seen that done in a contract.

A simple example of changing kerbal types would be the Space Camp contract in the Tourism Plus pack.

Starting on line 38 you'll see a DATA node that creates two lists of kerbals, assigns a number of random new Kerbals as tourists and 3 new kerbals as candidates who will join your space program after the contract is successfully completed.

These lists are then used in SpawnPassenger BEHAVIOUR nodes at line 130 and 138. 

Then at line 158 there is the BEHAVIOUR that simply changes each of those candidate kerbals into a pilot, engineer and scientist respectively. They are also given some experience points in the next BEHAVIOUR node.

8 hours ago, Ooglak Kerman said:

Thanks for looking into this.  I think that what I want would require a change to the City node in Kopernicus.

Unfortunately, I don't think anyone has written a CC extension to interact with Kopernicus or the stock PQSCity system in this way.

Edited March 9 by Aelfhe1m
forgot to add response to other point

[Ooglak Kerman]

On 3/8/2024 at 11:26 PM, Aelfhe1m said:

Yes, all the examples I know of use indexes. In principle, you could create a variable to hold the name of a specific kerbal if you were going to be referencing them frequently rather than indexing every time but I don't think I've ever seen that done in a contract.

A simple example of changing kerbal types would be the Space Camp contract in the Tourism Plus pack.

Starting on line 38 you'll see a DATA node that creates two lists of kerbals, assigns a number of random new Kerbals as tourists and 3 new kerbals as candidates who will join your space program after the contract is successfully completed.

These lists are then used in SpawnPassenger BEHAVIOUR nodes at line 130 and 138. 

Then at line 158 there is the BEHAVIOUR that simply changes each of those candidate kerbals into a pilot, engineer and scientist respectively. They are also given some experience points in the next BEHAVIOUR node.

Unfortunately, I don't think anyone has written a CC extension to interact with Kopernicus or the stock PQSCity system in this way.

I found the Tourism Plus pack and the Space Camp contract is just what I was looking for.

I'm slowly working my way through CC and wow - what a well thought out mod.  Very rich.  Very complex - but I guess that is part of it.

Edited March 10 by Ooglak Kerman

[Ooglak Kerman]

I've run into a behavior that seems counter intuitive.
Given a 1st contract that you accept.  That causes  a 2nd contract to drop that has a Requirement of AcceptContract of the 1st contract.  If the 1st contract is completed before the 2nd, then the 2nd contract will fail.
I see where - since the state of the 1st contract has changed from Accepted to Completed, but shouldn't AcceptContract track on IF a contract has been accepted and not on the state of the contract?

Is there a workaround?

Edited March 11 by Ooglak Kerman

[Aelfhe1m]

2 hours ago, Ooglak Kerman said:

I've run into a behavior that seems counter intuitive.
Given a 1st contract that you accept.  That causes  a 2nd contract to drop that has a Requirement of AcceptContract of the 1st contract.  If the 1st contract is completed before the 2nd, then the 2nd contract will fail.
I see where - since the state of the 1st contract has changed from Accepted to Completed, but shouldn't AcceptContract track on IF a contract has been accepted and not on the state of the contract?

Is there a workaround?

Off the top of my head :-

You could create a variable in a DATA node on your contract group, then have accepting the first contract update the variable using a expression behaviour node in the 1st contract to set that variable to a specific value, then have the 2nd contract depend on an expression based on the state of that variable rather than directly on the 1st contract. You could elaborate this with further logic to test for the 1st contract being failed or cancelled if required.

I've done no testing of this, but a skeleton implementation might be something like:

Spoiler

CONTRACT_GROUP
{
	name = MyContracts
	agent = Integrated Integrals
	
	// the variable that will be used for tracking
	DATA
	{
		type = bool
		GatewayAccepted = false
	}
	
}

// the 1st contract
CONTRACT_TYPE
{
	// contract settings here
		
	// our gateway behaviour
	BEHAVIOUR
    {
        name = GatewayAcceptedBehaviour
        type = Expression

        CONTRACT_ACCEPTED
        {
            @MyContracts:GatewayAccepted = true
        }
    }
}

// the second contract
CONTRACT_TYPE
{
	// contract settings
	
	REQUIREMENT
	{
		name = GatewayAcceptedRequirement
		type = Expression
		title = Gateway contract must have been accepted
		
		expression = @MyContracts:GatewayAccepted
	}
	
}

 

 

[siimav]

@Ooglak Kerman you can add 

Quote

checkOnActiveContract = false

to AcceptContract to prevent it from failing a contract that is already accepted. Unfortunately it's one of those new attributes that aren't documented in the wiki.

[Ooglak Kerman]

4 hours ago, siimav said:

@Ooglak Kerman you can add 

to AcceptContract to prevent it from failing a contract that is already accepted. Unfortunately it's one of those new attributes that aren't documented in the wiki.

Awesome!  Thanks much.  Well thought out.
At what point was that attribute added?  I'll need to make that version the minimum.

 

[siimav]

25 minutes ago, Ooglak Kerman said:

At what point was that attribute added?

2.0.0, I believe

[Ooglak Kerman]

Looks like 2.1.3 actually.  Thanks

[Ooglak Kerman]

@siimav In the Kopernicus City and City2 nodes, there is an option to make the object to be a commnetStation.  Do you think it would be possible for CC to do a BEHAVIOUR to set a persistent MM patch to turn that attribute on?  Or possibly a attribute on the VisitWaypoint PARAMETER?

[Ooglak Kerman]

Can a VesselParameterGroup be nested in another VesselParameterGroup?