nightingale

[1.6.x+] Contract Configurator [v1.27.1] [2018-12-28]

Recommended Posts

23 hours ago, Lisias said:

Problems will be solved when people solve them.

An Official version should merge the fixes (or perhaps solve it in a better way), but until this happens you will need to choose between fixing it yourself (and then, why don't share the fix?), choose an Unofficial fork that solve your problem without creating another (it can happens!), or play KSP without it. 

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.  It happens, no big deal, and I hope whatever things have him busy, they are something good or at least something that turns out well in the end. 

As for forks and fixes: It is on GitHub.  So maybe PM him and ask if he want your fixes as PRs for his main branch.  I'd say, as a courtesy to the original author, any changes you make that fix an issue could be submitted as pull requests on the original repository - Many hands make for lighter work.  I know when I got overwhelmed, pull requests that had been tested were very welcome, they meant my mod had more life, allowed me to focus on other problems, and reduced the time-sink and workload involved in keeping my addon current.

And there goes my excuse for not learning C#/Net/Windows/Unity.  Looks like I have a lot of learning to do, so I can help update a mod like this one eventually (6 months?).  :huh:

EDITORIAL (Feel free to ignore) One last thing: we need to remember that RL is far more important than any game mod.  The authors (and that includes adopters/adopters/rebuilders) do this of their own good will, free of charge, on their own time. Nobody here is demanding anything, which is good, and that makes me proud to be part of this community.  Because "demanding" things is what drove me off being an author in another game (they unfortunately had a toxic community), and I'm sure has or will drive people off if we don't make our intent clear - which can be hard to do in plain old text, so as King Leonidas said, "choose your words wisely" :cool:

Edited by Murdabenne

Share this post


Link to post
Share on other sites
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. :-)

  • Like 1

Share this post


Link to post
Share on other sites

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

Not a good idea

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

  • Like 18

Share this post


Link to post
Share on other sites
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

  • Like 11

Share this post


Link to post
Share on other sites
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! :D

  • Like 11

Share this post


Link to post
Share on other sites

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).
  • Like 30

Share this post


Link to post
Share on other sites
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.

  • Like 3

Share this post


Link to post
Share on other sites
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 :cool:

Edited by Murdabenne
  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

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
}

 

  • Like 1

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites
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).

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Like 3

Share this post


Link to post
Share on other sites

@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
		}
	}

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.
  • Like 7

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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?

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now