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

[EldrinFal]

Thanks for the quick fix!  I'm having trouble locating a "maxFunds" ... is that supposed to be in the save file?

 

[renoplane]

@nightingale, is it possible to specify somewhere that an user created agency should not be used to generate stock contracts? It's no big deal, I was just curious because the github wiki does not say anything about it and I've never noticed a stock contract use an agency from a contract pack before. 

Thanks

[NathanKell]

Relatedly, if possible I would like to force a contract to use an agency; other agents are picked despite that agent being the set agent for the contract. Is doing so possible? It's low priority so I've never remembered to ask before....

[nightingale]

4 hours ago, renoplane said:

@nightingale, is it possible to specify somewhere that an user created agency should not be used to generate stock contracts? It's no big deal, I was just curious because the github wiki does not say anything about it and I've never noticed a stock contract use an agency from a contract pack before. 

Huh, that's a bit of an oversight in the wiki.  Added a section for that here.

26 minutes ago, NathanKell said:

Relatedly, if possible I would like to force a contract to use an agency; other agents are picked despite that agent being the set agent for the contract. Is doing so possible? It's low priority so I've never remembered to ask before....

That really is just a question of setting the agent field in the CONTRACT_TYPE.  I've never seen/heard of that not working before though.  If you're able to point me to an example where it doesn't work, I'd love to see it, as that definitely sounds like a bug somewhere.

[NathanKell]

@nightingale Odd. I could have sworn I saw this regularly, but on checking some of our contracts do lack that field. I'll add it where it's missing and report back.

[vardicd]

All my game markers today have changed to Nyan cat. I'm amused. Is there a way to disable this?

Posted in waypoint manager too, as I noticed the behavior from my custom waypoints before I noticed it was coming from all the game markers that seem to be added by contract config.

I'm assuming this is coming from this mod?

[casper88]

hey nightingale, a few of the videos on youtube mention that if stock contracts on 1.1 are declined, those types of mission will appear less frequently... is that correct to your knowledge and will your configuration mod work in the same way?

thanks

[nightingale]

3 minutes ago, casper88 said:

hey nightingale, a few of the videos on youtube mention that if stock contracts on 1.1 are declined, those types of mission will appear less frequently... is that correct to your knowledge and will your configuration mod work in the same way?

That's correct, but only applies to stock Contracts.  Because of the way Contract Configurator is implemented (as a single contract class), it's not really possible for me to make use of the stock functionality.  I'm still waiting to see what the general player feel for the new feature is before deciding if I implement anything to mimic it.  I've also got other plans around contract generation for the future that may make it a moot point though.

[vardicd]

8 minutes ago, nightingale said:

That's correct, but only applies to stock Contracts.  Because of the way Contract Configurator is implemented (as a single contract class), it's not really possible for me to make use of the stock functionality.  I'm still waiting to see what the general player feel for the new feature is before deciding if I implement anything to mimic it.  I've also got other plans around contract generation for the future that may make it a moot point though.

I'm concerned about that new feature, say you get 2 or 3 bad contracts in a row, say with terms you don't think you can handle, right now, but you still want those types later, when you have more tech, but the game looks and say, oh he doesn't want that type of mission. you lose out.

[nightingale]

2 minutes ago, vardicd said:

I'm concerned about that new feature, say you get 2 or 3 bad contracts in a row, say with terms you don't think you can handle, right now, but you still want those types later, when you have more tech, but the game looks and say, oh he doesn't want that type of mission. you lose out.

@Arsonide can obviously speak to the feature better than I can, but I wouldn't be too worried about that.  Here's the relevant settings in Contracts.cfg:

	WeightDefault = 30 // The default weight new contract types start with
	WeightMinimum = 10 // The minimum weight that contracts can have from declining them
	WeightMaximum = 90 // The maximum weight that contracts can have from accepting them
	WeightAcceptDelta = 8 // How much accepting contracts affects their weight
	WeightDeclineDelta = -8 // How much declining contracts affects their weight

First of all, you have to actually decline the contracts to have the weight go down.  If everything's at the default, and you decline two contracts of one type, it'll bring the weight of that contract from 30 to 14.  That'll translate to that contract being *roughly* half as likely to come up than another contract.  If it's a contract you do want and you accept them later, that relative ratio will go back in the contract's favour rather quickly.  Also, since there is that floor of 10, it'll never disappear completely.

[renoplane]

16 hours ago, nightingale said:

Huh, that's a bit of an oversight in the wiki.  Added a section for that here.

That really is just a question of setting the agent field in the CONTRACT_TYPE.  I've never seen/heard of that not working before though.  If you're able to point me to an example where it doesn't work, I'd love to see it, as that definitely sounds like a bug somewhere.

Awesome, I will check that out.

[casper88]

ah so if there is a general liking for the new feature, would you implement it? maybe with each pack with its own class for instance?

[nightingale]

3 hours ago, casper88 said:

ah so if there is a general liking for the new feature, would you implement it? maybe with each pack with its own class for instance?

Exactly.  There's other factors that would come into play like technical feasibility and what other priorities I have.

[inigma]

Quick question, is there a way to reset all VPG parameters of a contract when a specific vessel is recovered prematurely, forcing players to redo the contract parameters again?

[nightingale]

4 hours ago, inigma said:

Quick question, is there a way to reset all VPG parameters of a contract when a specific vessel is recovered prematurely, forcing players to redo the contract parameters again?

There's two cases to look at:

1. VesselParameterGroup.define - the defined vessel goes away.  Nothing happens to the parameter (can't be completed again).
2. VesselParameterGroup.vessel - (note this can be a list).  If the vessel(s) no longer exist the contract may be "unwinnable".  Or it may just be that there's another parameter we don't have visibility to that will define it.

So from the above, there isn't a better general default than what I do now - which is do nothing.  But I have no objection to allow that to be controlled by the contract author.  So that gives us:

1. define - Allow the following options when an already defined vessel goes away
   1. (default) do nothing
   2. fail the contract
   3. reset the state of the parameter to incomplete
2. vessel - Allow the following options when there are no vessels in the vessel list that point to a real vessel
   1. (default) do nothing
   2. fail the contract

I'd have to be very careful above with the disableOnStateChange for the first one, and to prevent failing a contract at the wrong time with the second one.  If this is roughly what you want, can you raise an enhancement and I'll take a look for the next release (I'm slowly ramping back into modding after a brief hiatus)?  Also, if there's additional options/considerations you need.

[inigma]

9 minutes ago, nightingale said:

There's two cases to look at:

1. VesselParameterGroup.define - the defined vessel goes away.  Nothing happens to the parameter (can't be completed again).
2. VesselParameterGroup.vessel - (note this can be a list).  If the vessel(s) no longer exist the contract may be "unwinnable".  Or it may just be that there's another parameter we don't have visibility to that will define it.

So from the above, there isn't a better general default than what I do now - which is do nothing.  But I have no objection to allow that to be controlled by the contract author.  So that gives us:

1. define - Allow the following options when an already defined vessel goes away
   1. (default) do nothing
   2. fail the contract
   3. reset the state of the parameter to incomplete
2. vessel - Allow the following options when there are no vessels in the vessel list that point to a real vessel
   1. (default) do nothing
   2. fail the contract

I'd have to be very careful above with the disableOnStateChange for the first one, and to prevent failing a contract at the wrong time with the second one.  If this is roughly what you want, can you raise an enhancement and I'll take a look for the next release (I'm slowly ramping back into modding after a brief hiatus)?  Also, if there's additional options/considerations you need.

Thanks. I'll raise an enhancement too. Something worthwhile to test for sure. 1.1 isn't out yet, but when it goes gold I'll be jumping into GAP again and I think this would really make GAP behave more like a real challenge - in that if you do something to your craft that makes it no longer in existence, but doesn't fail the contract, for the contract to reset itself (rather than have the player cancel it and refresh contracts).

[severedsolo]

Can I ask a favour? I'm aware it's waaay to much work to go back and retro-actively do this, but going forward, would it be possible for you to just put a line in the docs that says what version of CC a feature was introduced/changed in?

Here's my thinking: When 1.0.5 hit, i released an update for B&S, which implemented some new features. Now, I knew that these features were not supported by the minVersion I was using in CONTRACT_GROUP, but for the life of me couldn't remember what version they were introduced in.

So I just put the latest version of CC... and well, you know that didn't go well, for unrelated reasons. If I know what changes have been introduced when (without having to comb the changelog) - I can update accordingly.

I know we'd rather all users were using latest versions, but that probably won't happen.

[nightingale]

5 hours ago, severedsolo said:

Can I ask a favour? I'm aware it's waaay to much work to go back and retro-actively do this, but going forward, would it be possible for you to just put a line in the docs that says what version of CC a feature was introduced/changed in?

Here's my thinking: When 1.0.5 hit, i released an update for B&S, which implemented some new features. Now, I knew that these features were not supported by the minVersion I was using in CONTRACT_GROUP, but for the life of me couldn't remember what version they were introduced in.

So I just put the latest version of CC... and well, you know that didn't go well, for unrelated reasons. If I know what changes have been introduced when (without having to comb the changelog) - I can update accordingly.

I know we'd rather all users were using latest versions, but that probably won't happen.

It's something I've considered in the past.  I'll do that going forward on 1.11.x

[severedsolo]

It seems that there is something wrong with CC_RemoteTech.dll which is causing contracts to fail validation.

What it is I don't know, because I can't find any helpful error messages in the log.. just "Errors encountered while trying to load CONTRACT_TYPE (whatever) and something else about not being able to read the assembly from CC_RemoteTech properly. It's affecting the Remotetech pack (obviously) and CleverSat

Anomaly Surveyor seems to be busted too, but for different reasons. The Jool monolith mission is failng validation.

"Could not load type 'AnomalySurveyor.MonolithParameter' from assembly 'AnomalySurveyor,"

(1.1 1209 using RemoteTech 1.6.11) - RemoteTech seems to be working (that is, the UI looks ok, and is loaded, I've got the flight computer etc)

The log: https://www.dropbox.com/s/5fpxsmiiu1t0sag/output_log%28CC%20bug%29.txt?dl=0

[nightingale]

1 hour ago, severedsolo said:

It seems that there is something wrong with CC_RemoteTech.dll which is causing contracts to fail validation.

What it is I don't know, because I can't find any helpful error messages in the log.. just "Errors encountered while trying to load CONTRACT_TYPE (whatever) and something else about not being able to read the assembly from CC_RemoteTech properly. It's affecting the Remotetech pack (obviously) and CleverSat

Anomaly Surveyor seems to be busted too, but for different reasons. The Jool monolith mission is failng validation.

"Could not load type 'AnomalySurveyor.MonolithParameter' from assembly 'AnomalySurveyor,"

(1.1 1209 using RemoteTech 1.6.11) - RemoteTech seems to be working (that is, the UI looks ok, and is loaded, I've got the flight computer etc)

The log: https://www.dropbox.com/s/5fpxsmiiu1t0sag/output_log%28CC%20bug%29.txt?dl=0

No RemoteTech support - they only released a couple days ago and I haven't had a chance to recompile yet.  The fact that there is even a CC_RemoteTech.dll in the package is a bug (until the next release).

[nightingale]

RemoteTech support is back.  Otherwise, just a small bugfix release, get it here!

Contract Configurator 1.10.2

• Re-enabled RemoteTech support.
• Fixed exception on requirement load of SCANsatLocationCoverage (thanks wizisi2k).
• Properly fixed contract "flickering" in mission control.

[mtpatane]

Is the SETI Contracts pack still supported?

I know AVC says 1.0.5, but when I load it into the contract packs folder it works just fine.

@nightingale Would you be the one to re-compile that?  Not sure whose realm that falls in to.

 

Thanks!

[Razorfang]

I am having an issue where the RemoteTech contracts will appear in mission control and then shortly disappear. The debug log shows them being created, but there is no entry when they vanish. Running CC 1.10.2, RemoteTech 1.6.11, and RemoteTech Contract Pack 2.0.2.

[linuxgurugamer]

5 minutes ago, mtpatane said:

Is the SETI Contracts pack still supported?

I know AVC says 1.0.5, but when I load it into the contract packs folder it works just fine.

@nightingale Would you be the one to re-compile that?  Not sure whose realm that falls in to.

 

Thanks!

Contract packs aren't version specific, so you should be fine.  No recompile needed

[nightingale]

1 hour ago, Razorfang said:

I am having an issue where the RemoteTech contracts will appear in mission control and then shortly disappear. The debug log shows them being created, but there is no entry when they vanish. Running CC 1.10.2, RemoteTech 1.6.11, and RemoteTech Contract Pack 2.0.2.

Fixed for next release (which will probably be today to get this issue cleared out).