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

[Lisias]

1 hour ago, Murdabenne said:

I think the author ( @nightingale ?) is still around although it is apparently he does not have the time right now to deal with updating and reworking this mod.  

Real-life is an issue for everybody, including me. Every hour one expend fixing something, it's an hour we doesn't expend playing with something else.

Fixes can bork - usually we mess up one or two times until we got it. If the maintainer hasn't the time to fix the problem, would he has the time to fix the fix?

This way we are doing know, when he find the time to update, he will gain the fixes implementated and validaded on the field. Ideally, more than one fix so he can even choose the one he likes more. 

Pull requests works both ways. He can merge back the code from anyone that had forked his own, he doesn't have even to ask - it's the Open Source way.

And with us tacking down problems openly here, he don't have to search by himself neither: all the needed info is already consolidated to be analysed. :-)

[linuxgurugamer]

Unfortunately, thus is now creating confusion and incompatible versions of the same mod.

Not a good idea

[Murdabenne]

version locking is not usually a good solution, although it may be a sufficient solution for a corner case. 

[nightingale]

All - I'm going to work on a quick update for 1.5.1 over the next few days.  It's not going to be much - grabbing and reviewing a few pull requests, recompiling to 1.5.1, doing some quick testing and seeing if there are any "easy" outstanding issues that I can do a quick fix for in the GitHub list.

Sorry that I haven't been updating this recently...  other things have been a higher priority than KSP of late, so it's fallen down in priority.  If there is anyone who is capable and interested in taking over, do send me a PM.

[Drew Kerman]

8 hours ago, nightingale said:

Sorry that I haven't been updating this recently...

Sorry that you feel you have to say sorry! Nothing wrong with keeping your priorities straight IMO

[nightingale]

13 hours ago, Drew Kerman said:

Sorry that you feel you have to say sorry! Nothing wrong with keeping your priorities straight IMO

Am Canadian - sorry, but it's in our DNA! 

[nightingale]

A wild release appeared!  @nightingale used GitHub....  it's super effective!

Contract Configurator 1.26.0

• Recompile for KSP 1.5.1
• Updated to work with RemoteTech 1.8.13+ (thanks PiezPiedPy).
• Added trig functions to expression language (thanks VaPal).
• Invalid Celestial Bodies constants no longer throw an error on parsing (improves overall support for planet packs that remove/rename planets).
• Fixed a bug that prevented casting from string to ExperienceTrait.
• Fixed an issue affecting CollectScience and biomes with spaces (thanks mpharoah).

[Superfluous J]

58 minutes ago, nightingale said:

A wild release appeared!

I just Liked somewhere near 5 of your posts. And I don't feel bad. I may go through your history and find 20 more.

[Murdabenne]

On 12/5/2018 at 12:27 AM, nightingale said:

All - I'm going to work on a quick update for 1.5.1 over the next few days.  It's not going to be much - grabbing and reviewing a few pull requests, recompiling to 1.5.1, doing some quick testing and seeing if there are any "easy" outstanding issues that I can do a quick fix for in the GitHub list.

Sorry that I haven't been updating this recently...  other things have been a higher priority than KSP of late, so it's fallen down in priority.  If there is anyone who is capable and interested in taking over, do send me a PM. 

RL happens!  I hope RL is treating you well, and please don't feel pressured to do anything here.  Family, health, and hearth are all far higher priority than anything we want for our little green gherkins people. kerbals

Edited December 6, 2018 by Murdabenne

[ssd21345]

Wow nightingale updates so fast

[ondert]

Can you please update the second post for contract packs supporting 1.5.1? I've seen G.A.P supports the latest version of ksp but not sure about the others. Thanks in advance.

[nightingale]

On 12/8/2018 at 4:54 AM, ondert said:

Can you please update the second post for contract packs supporting 1.5.1? I've seen G.A.P supports the latest version of ksp but not sure about the others. Thanks in advance.

Sure, I'll have to take a look at that.

[Dr. TarB]

Hi, fellows! I have one question which I posted it the Galileo's OPM thread but didn't get any answer... So maybe here someone could tell me if celestial bodies from addon planets packs can have contract reward modifiers? I tried to find it by myself almost everywhere (this thread, CC docs, Kopernicus thread and docs...), but nothing. I need it for my custom contract packs which I want to properly interact with OPM and if it's a hardcoded feature of KSP I have to implement it myself in contracts code...

[Immashift]

On 12/6/2018 at 12:00 AM, nightingale said:

A wild release appeared!  @nightingale used GitHub....  it's super effective!

<3 Thank you!

[nightingale]

On 12/10/2018 at 5:12 AM, Dr. TarB said:

Hi, fellows! I have one question which I posted it the Galileo's OPM thread but didn't get any answer... So maybe here someone could tell me if celestial bodies from addon planets packs can have contract reward modifiers? I tried to find it by myself almost everywhere (this thread, CC docs, Kopernicus thread and docs...), but nothing. I need it for my custom contract packs which I want to properly interact with OPM and if it's a hardcoded feature of KSP I have to implement it myself in contracts code...

Should be based on the RecoveryValue (CelestialBody.scienceValues.RecoveryValue in code, I think it's in Properties/ScienceValues in Kopernicus).  If you want to interact with it in CC contracts it's body.Multiplier() (for historical reasons).

[Boamere]

Hey I've been looking into why the anomaly scanning pack isn't working with SCANsat like it should. Does anything about this cfg file stand out? (as it is causing errors)

Spoiler

@CONTRACT_TYPE[AS_*]:HAS[#tag[SCANsat]],NEEDS[SCANsat],*
{
    // Increase the rewards of all contracts with extra SCANsat requirements
    @rewardFunds *= 1.30
    @rewardReputation *= 1.10
}

 

[pap1723]

Hello CC team and users!

I have made quite a few contract packs and feel like I have a good understanding about how it all works, but some of you do some amazing stuff on here! There are two issues that players continually report to us and I am hoping that you might have some clever tips or tricks to get around these (stock I am assuming issues).

First Issue:
Most of the missions we have require a NewVessel to be launched. However, when one is launched after accepting the contract, the green check mark will show, but then it will go away if you switch off the craft.

Second Issue:
We have quite a few Duration requirements that work correctly as long as the vessel is in focus, but if you switch away from the vessel, it will stop tracking the duration and reset it.

 

Question / Idea
It would be great if in the VAB, or after a launch, we could set a craft as the ONLY craft that can complete a mission. That way it should fix some of the issues with tracking of vessels. The only vessel that a contract would need to track would be the one that is set as the "Mission Vessel". The biggest drawback I would see is how to handle if the craft fails for some reason. Then there would have to be logic to disassociate one vessel and associate another, but that shouldn't be too hard.

 

Anyway, looking forward to some help from you all!

[nightingale]

14 hours ago, Boamere said:

Hey I've been looking into why the anomaly scanning pack isn't working with SCANsat like it should. Does anything about this cfg file stand out? (as it is causing errors)

  Reveal hidden contents

@CONTRACT_TYPE[AS_*]:HAS[#tag[SCANsat]],NEEDS[SCANsat],*
{
    // Increase the rewards of all contracts with extra SCANsat requirements
    @rewardFunds *= 1.30
    @rewardReputation *= 1.10
}

 

I see your PR about this issue, so I'll merge that and get a release out soon-ish.

5 hours ago, pap1723 said:

Hello CC team and users!

I have made quite a few contract packs and feel like I have a good understanding about how it all works, but some of you do some amazing stuff on here! There are two issues that players continually report to us and I am hoping that you might have some clever tips or tricks to get around these (stock I am assuming issues).

First Issue:
Most of the missions we have require a NewVessel to be launched. However, when one is launched after accepting the contract, the green check mark will show, but then it will go away if you switch off the craft.

Are you using a VesselParameterGroup?  It will always display the contract from the perspective of the currently selected vessel (but potentially track it for any/all vessels in the background).  In this case, giving focus back to the "contract" vessel should show the parameter as checked again.

If not, the same will apply, but it won't track on a per-vessel basis (so other parameters that might depend on the NewVessel will potentially get reset.

5 hours ago, pap1723 said:

Second Issue:
We have quite a few Duration requirements that work correctly as long as the vessel is in focus, but if you switch away from the vessel, it will stop tracking the duration and reset it.

There's a lot of exceptions around the Duration and a lot of different ways to use it, so it's hard to say for sure.  If you're using a VesselParameterGroup, the duration on the parameter itself is often a better/simpler choice.  If you're not using a VesselParameterGroup - then I would expect it to reset when switching focus.

5 hours ago, pap1723 said:

Question / Idea
It would be great if in the VAB, or after a launch, we could set a craft as the ONLY craft that can complete a mission. That way it should fix some of the issues with tracking of vessels. The only vessel that a contract would need to track would be the one that is set as the "Mission Vessel". The biggest drawback I would see is how to handle if the craft fails for some reason. Then there would have to be logic to disassociate one vessel and associate another, but that shouldn't be too hard.

This is sort of supported.  I think @inigma did stuff like this in his GAP contracts .  It would say that the next vessel you launch is the "contract vessel" (done via VesselParameter group + define).  Then the other parameters would use another VesselParameterGroup with "vessel" set to lock it to the contract vessel defined in the previous step.  Finally, the VesselNotDestroyed parameter is used to force the contract to fail if the vessel gets destroyed.  If you want the contract not to fail - then it's really just the normal case of using a VesselParameterGroup (potentially with the NewVessel parameter).

[nightingale]

Recompiled against KSP 1.6 without any errors, so probably no issues with it.  Will do a bit more testing and a new release tonight.

[pap1723]

@nightingale This is the typical structure of the contracts we have. Is this setup correctly?

	// ************ PARAMETERS ************

	PARAMETER
	{
		name = VesselGroup
		type = VesselParameterGroup
		title = Flyby Venus
		define = FlybyVenus
	
		PARAMETER
		{
			name = NewVessel
			type = NewVessel
			title = Launch a New Vessel
			hideChildren = true
		}
		PARAMETER
		{
			name = Crewmembers
			type = HasCrew
			minCrew = 0
			maxCrew = 0
			title = Uncrewed
			hideChildren = true
		}
		PARAMETER
		{
			name = FlybyPlanet
			type = ReachState
			maxAltitude = 20000000
			disableOnStateChange = true
			title = Flyby Venus within 20,000 km
			hideChildren = true
		}
		PARAMETER
		{
			name = CollectSpaceScience
			type = CollectScience
			recoveryMethod = Transmit
			title = Transmit Science Data from Space near @targetBody
			hideChildren = true
		}
	}

 

[nightingale]

5 hours ago, pap1723 said:

@nightingale This is the typical structure of the contracts we have. Is this setup correctly?

<snip>

Looks fine.  Could be there's a bug with certain situations or something - would be good to get either a save that reproduces or repro steps.

[nightingale]

New KSP, new release.  Now with more delta-vee!  Download here.

Contract Configurator 1.27.0

• Recompile for KSP 1.6.0
• Added actual and vacuum delta-vee to ReachState.
• Added Expansion requirement.
• Added LAUNCH_SITE sub-node to WaypointGenerator behaviour.
• Added support for LaunchSite class in expressions.
• Added OtherKerbinBiomes() function to return biomes like Baikerbanur.
• Fixed Biome functions to correctly distinguish between KSC biomes and other collider based biomes.
• Fixed issue with sub-parameters sometimes showing as met when they shouldn't.
• Clarified error message when SpawnPassengers is omitted from a contract that requires it.

[theJesuit]

4 minutes ago, nightingale said:

New KSP, new release.  Now with more delta-vee!  Download here.

Contract Configurator 1.27.0

• Recompile for KSP 1.6.0
• Added actual and vacuum delta-vee to ReachState.
• Added Expansion requirement.
• Added LAUNCH_SITE sub-node to WaypointGenerator behaviour.
• Added support for LaunchSite class in expressions.
• Added OtherKerbinBiomes() function to return biomes like Baikerbanur.
• Fixed Biome functions to correctly distinguish between KSC biomes and other collider based biomes.
• Fixed issue with sub-parameters sometimes showing as met when they shouldn't.
• Clarified error message when SpawnPassengers is omitted from a contract that requires it.

You're amaze balls.  Thank you!

Peace.

[Krakatoa]

4 minutes ago, nightingale said:

New KSP, new release.  Now with more delta-vee!  Download here.

Contract Configurator 1.27.0

• Recompile for KSP 1.6.0
• Added actual and vacuum delta-vee to ReachState.
• Added Expansion requirement.
• Added LAUNCH_SITE sub-node to WaypointGenerator behaviour.
• Added support for LaunchSite class in expressions.
• Added OtherKerbinBiomes() function to return biomes like Baikerbanur.
• Fixed Biome functions to correctly distinguish between KSC biomes and other collider based biomes.
• Fixed issue with sub-parameters sometimes showing as met when they shouldn't.
• Clarified error message when SpawnPassengers is omitted from a contract that requires it.

Sorry for being a little dense, when you say "Added Expansion requirement", does that mean being able to set up contracts that require MH, or that it's now required for CC?

[nightingale]

9 minutes ago, Krakatoa said:

Sorry for being a little dense, when you say "Added Expansion requirement", does that mean being able to set up contracts that require MH, or that it's now required for CC?

The former.  It was always possible with Module Manager, but this gives another option for contract authors.  With module manager the contract just wouldn't exist without MH, with this method it would still show up as a contract, it would just be disabled with a requirement stating that contract requires MH.