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

[NathanKell]

I've updated v2.0's changelog to reflect the pre-RO changes.

[Caerfinon]

@NathanKell Would it be possible for you to post an example bit of contract that uses the new Tag feature introduced in 2.1? 

[rmaine]

On 7/28/2022 at 12:52 AM, NathanKell said:

Changelog is also in each release page on github, though most of the changes were in 2.0 (but ignore the "RO only" thing since it was fixed in 2.1).

I built against 1.12.3 but I don't see why it wouldn't work for 1.9?

And most of the thanks go to @siimav(and @Gotmachinefor finding the leaks).

Slightly confused about this "RO only - or maybe not" thing still. Using contract configurator 1.30.5 and I notice CKAN told me an update was available. Ok, did the update. Hey! It now says I'm on an RO only version. Came here and I see this comment about the RO only bit being fixed in 2.1, but the 2.1.2 version still seems to have RO only in the title and directs me to the RO page of this forum. I'm guessing all is probably OK, but this leaves me unsure. I wasn't noticing the 1.30.5 version as being obviously broken for me, so for the moment I think I'll revert to it on the theory of not fixing something that doesn't appear to be broken and replacing it with something whose title implies brokenness, even if the thread here implies otherwise. Oh, and in case that isn't obvious, I'm not using RO.

[NathanKell]

10 hours ago, rmaine said:

Slightly confused about this "RO only - or maybe not" thing still. Using contract configurator 1.30.5 and I notice CKAN told me an update was available. Ok, did the update. Hey! It now says I'm on an RO only version. Came here and I see this comment about the RO only bit being fixed in 2.1, but the 2.1.2 version still seems to have RO only in the title and directs me to the RO page of this forum. I'm guessing all is probably OK, but this leaves me unsure. I wasn't noticing the 1.30.5 version as being obviously broken for me, so for the moment I think I'll revert to it on the theory of not fixing something that doesn't appear to be broken and replacing it with something whose title implies brokenness, even if the thread here implies otherwise. Oh, and in case that isn't obvious, I'm not using RO.

The local metadata was outdated and thus confusing. As the release makes clear, and this thread, this is for everyone. I've now fixed the metadata.

[rmaine]

2 minutes ago, NathanKell said:

The local metadata was outdated and thus confusing. As the release makes clear, and this thread, this is for everyone. I've now fixed the metadata.

Thanks. That was my suspicion, but nice to have it verified.

[NathanKell]

16 hours ago, Caerfinon said:

@NathanKell Would it be possible for you to post an example bit of contract that uses the new Tag feature introduced in 2.1? 

CONTRACT_TYPE
{
	name = contract1
	tag = Group 1 Contracts
	...
	
	REQUIREMENT
	{
		name = AcceptContract
		type = AcceptContract
		invertRequirement = true
		tag = Group 1 Contracts
	}
	
	...
}

CONTRACT_TYPE
{
	name = contract2
	tag = exclusiveGroup
	...
	
	REQUIREMENT
	{
		name = AcceptContract
		type = AcceptContract
		invertRequirement = true
		tag = exclusiveGroup
	}
	
	...
}

Will ensure that you can only have one of the two accepted at any time.  (Note it had a bug for accept, though not complete, which I fixed just now.)
You could also do loc, so instead do "tag = group1" and then somewhere else:

LOCALIZATION
{
	en-us
	{
		#cc.contracttag.OfType.group1 = of type Group 1 Contract
		#cc.contracttag.bare.group1 = Group 1 Contract
	}
}

 

On 7/28/2022 at 10:51 AM, Zelda said:

Hello @NathanKell! Thanks so much to you and the RO community for taking this on. Writing contracts to create my own mission storylines is one of my favorite things in the game, so it's good to see CC get some love!

One thing I noticed after updating to the new version - nearly every celestial body and kerbal referenced in existing contracts appear to be showing a Lingoona gender suffix unless the contract explicitly refers to the the object's '.Name()' property (or for kerbals, '.firstName()' and '.lastName()'). So just having a simple string in a contract like this:

title = Orbit @targetBody

...will show up in-game as "Orbit Jool^N." I updated a few of my personal contracts to use the name properties to test my theory, and it worked to remove the gender suffix, but most older contract packs currently available would need to be updated too. I don't think it causes any problems with the contracts themselves, so likely not a priority, but I'm wondering if you could update CC to default to returning the object name as a string without the gender marker if it's used in a string like that?

Visual example from my game below:

 

https://imgur.com/uhgwmRn

Thanks!

This should now be fixed, the decorators will only be added with .DisplayName() calls for bodies and Kerbals (and  FirstName() / LastName() calls for Kerbals).

[basic.syntax]

Having trouble after editing contract cfg-file parameters? Not making a formal patch? I wanted to share a couple noob mistakes & fixes:

I was making cfg changes and not seeing them take effect after repeated restarts:  it appears that making a backup copy of the original cfg, with a change to the first name but keeping the cfg extension, and leaving that renamed original in the same place as the newly edited cfg could result in the original cfg data being read first.  And the original cfg data might still be found and loaded, after "cleverly" moving the renamed original to a nearby folder.   If you must hack, edit the one file: copy lines to edit and comment out  '//' the original line.

"Why is the contract type I edited, not being offered?"  One possibility: an edited value that starts with a decimal point will throw an exception.  Remember to include a leading zero for decimal numbers, so they can be parsed correctly  

[Caerfinon]

6 hours ago, NathanKell said:

Will ensure that you can only have one of the two accepted at any time

Thank you very much. This will prove useful. 

[Caerfinon]

I have opened an issue in KSP-RO/ContractConfigurator Github  - Exception handling event onPartJointBreak in class VesselNotDestroyed:System.NullReferenceException. 

Contract Configurator is encountering an error  when handling  VesselNotDestroyed parameters. The contracts continue to work correctly if the parameter is successful or failed, however a Null Reference Exception is thrown whenever the parameter is checked during the duration of the contract. 

A link to ksp and player logs is in the issue. 

[thiagobaisch]

Right now using planet packs like GPP, the contracts will display the wrong name of the home planet and star. For example, before, the contract "Orbit Gael" became "Orbit Kerbin", and Ciro also was replaced for the Sun. I didn't test all contracts, but the early ones work fine. All contracts had the name Gael and Ciro replaced for Kerbin and Sun in the last patch.

I reversed to version 1.30 and it is fixed in that version.

Edited August 3, 2022 by thiagobaisch

[NathanKell]

On 8/2/2022 at 5:32 PM, thiagobaisch said:

Right now using planet packs like GPP, the contracts will display the wrong name of the home planet and star. For example, before, the contract "Orbit Gael" became "Orbit Kerbin", and Ciro also was replaced for the Sun. I didn't test all contracts, but the early ones work fine. All contracts had the name Gael and Ciro replaced for Kerbin and Sun in the last patch.

I reversed to version 1.30 and it is fixed in that version.

Fixed. In prior versions, CC had a special hacky way of formatting body names when placed "bare" in a string that took the displayName but stripped the Lingoona decorators off of that value. I've now restored that behavior while still leaving the DisplayName() method which will give the full, decorated displayName.

 

This should fix the behavior you described, which is because GPP changes the display name of Kerbin to be Gael and Sun to be Ciro while leaving their actual underlying names untouched. (RSS also does this, because KSP gets very upset if the homeworld isn't named Kerbin, so we have to just change the display name instead).

 

2.1.4:

- Return to legacy behavior for CelestialBody names when used without a function; Name() will report the actual name and DisplayName() the Lingoona-decorated name as in 2.1.3 however. This should preserve legacy contract behavior while still allowing Lingoona formatting going forward.
- Change last remaining uses of CurrencyModifierQuery that didn't go through RunQuery

[AtomicRocketBooster]

Hello - I think I'm encountering a bug related to this mod where the Mission Control Contract limits don't get applied correctly.

I have a L3 Mission Control, so contracts should be unlimited. However, on my save, which had limits when I was on the L1/L2 mission control, those same L2 limits are still being applied.

When I remove CC, the limits are all removed (however, then I'm stuck with the boring Stock contracts!)

I will try some other debug steps but has anyone experienced this issue before?

Edit: Here are some logs

Edit 2: Looks like CC adds in some limits in addition to the stock ones? If so, this doesn't appear to be documented anywhere.

Edited August 7, 2022 by AtomicRocketBooster

[CowboyChicken]

On 8/7/2022 at 8:19 AM, AtomicRocketBooster said:

Hello - I think I'm encountering a bug related to this mod where the Mission Control Contract limits don't get applied correctly.

I have a L3 Mission Control, so contracts should be unlimited. However, on my save, which had limits when I was on the L1/L2 mission control, those same L2 limits are still being applied.

When I remove CC, the limits are all removed (however, then I'm stuck with the boring Stock contracts!)

I will try some other debug steps but has anyone experienced this issue before?

Edit: Here are some logs

Edit 2: Looks like CC adds in some limits in addition to the stock ones? If so, this doesn't appear to be documented anywhere.

TBH i've always had contract limits (weighted by difficulty) even on L3 with CC installed. I noticed the latest patch did, however, take away the setting to increase the available contracts on the settings menu. I now have a save where I've got 14 Exceptional contracts active with a max of 8.

[adriangm44]

Something is happening...

I met all the requirements for a contract. (I even deleted in the cfg of the contract pack the requirement of having completed a previous contract, which it was met as well, hoping to fix it). But the contract REFUSES to being offered. I can't move on with the progression... 

No one answering in Career Evolution thread. Any help here? I’ll provide logs if needed.

[Caerfinon]

4 hours ago, adriangm44 said:

Any help here? I’ll provide logs if needed.

You should turn on CC debugging  (see the file ContractConfigurator.cfg.default  in Gamedata\ContractConfigurator for instructions). Set all logLevel values to verbose. 

Then provide player.log, ksp.log and GameData\ContractConfigurator\log\CareerEvolution\SSOneYear.log 

[adriangm44]

1 hour ago, Caerfinon said:

You should turn on CC debugging  (see the file ContractConfigurator.cfg.default  in Gamedata\ContractConfigurator for instructions). Set all logLevel values to verbose. 

Then provide player.log, ksp.log and GameData\ContractConfigurator\log\CareerEvolution\SSOneYear.log 

I set all three lines of logLevel to VERBOSE and I'm not getting any logs in ContractConfigurator\log\CareerEvolution\SSOneYear.log. And yes, I renamed the file to ContractConfigurator.cfg

[Caerfinon]

14 minutes ago, adriangm44 said:

I'm not getting any logs

Did you restart the game. changes only take effect on restart. 

[adriangm44]

2 hours ago, Caerfinon said:

Did you restart the game. changes only take effect on restart. 

Yes, of course I did

[Caerfinon]

5 hours ago, adriangm44 said:

Yes

Fair enough. The ksp.log and player.log will still suffice to look into it further.  

[adriangm44]

17 hours ago, Caerfinon said:

Fair enough. The ksp.log and player.log will still suffice to look into it further.  

I managed to make it work. I left the first logLevel as WARNING, changed the other two to VERBOSE. Now it worked.

There you go, and thank you:
https://drive.google.com/drive/folders/1axg1S8inQ2CD9VX7jcbk28mJH_Ous94V?usp=sharing

I deleted the SSSixMonths achievement via in-game cheats hoping it would let me re-do the contract and trigger it again. But it ended up not triggering either, so I went backwards.

[Caerfinon]

2 hours ago, adriangm44 said:

SSSixMonths

In your current ksp.log the you get the following; 

[LOG 22:43:04.925] [VERBOSE] ContractConfigurator.ContractType: Didn't generate contract of type SSSixMonths: 'targetKerbals' had zero count.

The relevant contract config affecting this is the following; 

	DATA
	{
		type = Vessel
		requiredValue = true
		targetVessel1 = AllVessels().Where(v => v.VesselType() == Station && v.IsOrbiting() == true && v.CelestialBody() == @targetBody).SelectUnique()
		uniquenessCheck = CONTRACT_ACTIVE
		title = Get your space station
	}
	DATA
	{
		type = List<Kerbal>
		targetKerbals = @targetVessel1.Crew()
		hidden = true
	}

The  variable  targetKerbals is an empty list because the evaluation that creates  targetVessel1 is either returning a null value, or it does not have any crew in it. If the former, launch a new vessel, If the latter you would need to determine which vessel it is looking at and add crew to it.

Can you post the persistent.sfs of you game save so I can look at the Contracts subsection of it?   

   

 

 

[adriangm44]

18 hours ago, Caerfinon said:

In your current ksp.log the you get the following; 

[LOG 22:43:04.925] [VERBOSE] ContractConfigurator.ContractType: Didn't generate contract of type SSSixMonths: 'targetKerbals' had zero count.

The relevant contract config affecting this is the following; 

	DATA
	{
		type = Vessel
		requiredValue = true
		targetVessel1 = AllVessels().Where(v => v.VesselType() == Station && v.IsOrbiting() == true && v.CelestialBody() == @targetBody).SelectUnique()
		uniquenessCheck = CONTRACT_ACTIVE
		title = Get your space station
	}
	DATA
	{
		type = List<Kerbal>
		targetKerbals = @targetVessel1.Crew()
		hidden = true
	}

The  variable  targetKerbals is an empty list because the evaluation that creates  targetVessel1 is either returning a null value, or it does not have any crew in it. If the former, launch a new vessel, If the latter you would need to determine which vessel it is looking at and add crew to it.

Can you post the persistent.sfs of you game save so I can look at the Contracts subsection of it?   

   

 

 

The targetVessel1 has indeed no crew. Maybe I did wrong bringing them back after accomplishing the contract and should've waited for the next one. The target I'm aiming is Gallileo Station. I've just uploaded the persistent file in the later link.

[Caerfinon]

20 minutes ago, adriangm44 said:

The targetVessel1 has indeed no crew.

What happens when you put crew on it? 

I looked at he persistent.sfs and all trace of the SSSixMonths has been removed. it no longer shows as cancelled. This would occur if you deleted it from the debug menu. 

[DeadJohn]

I'm asking general questions here about Contract Configurator's capabilities before committing to a version of Giving Aircraft a Purpose that works with GPP. Existing GAP derivatives seem to be hardcoded for specific planet packs, and I wonder whether I can feasibly create something that's more flexible to work anywhere.

Can Contract Configurator get coordinates and create a waypoint in the middle of a random KK runway? Maybe the PQSCity object allows that?

My concept is to generate contracts like "Fly from [KSC runway] and land at [a different random runway]. Your one-way flight distance is [calculated distance between runways]. Payment is [based on distance]."

[Caerfinon]

28 minutes ago, DeadJohn said:

Maybe the PQSCity object allows that?

The Contract Configurator WaypointGenerator Behaviour can set a waypoint to a PQSCity object or to a LaunchSite object as defined in KSP. The trick is to be able to identify the runway object you are placing as one of those object types. Otherwise you need to record all the possible coordinates as data in the contract level or contract group level.

This latter design makes porting to other planet packs... daunting.