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

[nightingale]

Ok I look more closely at the CC code and added some Debug-Logs to look inside the data structures. I think I have an idea why this happens:

In file Science.cs, function AvailableExperiments() I can see this line:

[FONT=Consolas] [COLOR=#333333]experiments[/COLOR][COLOR=#333333]=[/COLOR][COLOR=#333333]experiments[/COLOR][COLOR=#333333].[/COLOR][COLOR=#333333]Where[/COLOR][COLOR=#333333]([/COLOR][COLOR=#333333]exp[/COLOR][COLOR=#333333]=[/COLOR][COLOR=#333333]>[/COLOR][COLOR=#333333] ![/COLOR][COLOR=#333333]experimentParts[/COLOR][COLOR=#333333].[/COLOR][COLOR=#333333]ContainsKey[/COLOR][COLOR=#333333]([/COLOR][COLOR=#333333]exp[/COLOR][COLOR=#333333].[/COLOR][COLOR=#333333]id[/COLOR][COLOR=#333333])[/COLOR][COLOR=#333333] || [/COLOR][COLOR=#333333]experimentParts[/COLOR][COLOR=#333333][[/COLOR][COLOR=#333333]exp[/COLOR][COLOR=#333333].[/COLOR][COLOR=#333333]id[/COLOR][COLOR=#333333]][/COLOR][COLOR=#333333].[/COLOR][COLOR=#333333]Any[/COLOR][COLOR=#333333]([/COLOR][COLOR=#3364a4]ResearchAndDevelopment[/COLOR][COLOR=#333333].[/COLOR][COLOR=#333333]PartTechAvailable[/COLOR][COLOR=#333333]))[/COLOR][COLOR=#333333];[/COLOR][/FONT]

The intention of this line is to filter only those experiments where the parts are available for the player. In the lines above the code tries to get a list of all available parts and their experiments.

However something looks strange here: According to the expression it allows an experiment either when there is not part that can do this experiment or when this part (when there is a part) is available for the player.

I wonder: Why do you allow experiments, where is no part defined to do those experiments?

Is there a special reason or is this only a "hidden" check, if a part is in the list before you try to access this list (to prevent exceptions)?

Anyway the ChemCam is for some reasons not in the list. But the part is available in the TechTree, so I guess there in another error with the Part-Definition of the ChemCam that triggers the first test-stastement of this expression and this leads to the situation that such an experiment is chosen by the "Field Resource" contracts.

I simply need to find out, why the part is not found even when it exists.

There's two types of experiments, the "partless" ones (crew report, EVA report, surface sample) and the "parted" ones (mystery goo, materials bay, etc.). So if a part for the experiment is not found, I have to assume it's a partless experiement.

If a mod has an experiment that requires parts and uses the stock ScienceExperiment module, then its auto-detected, and there's nothing else to be done. If a mod adds experiments and adds its own PartModule, then things get more murky. Because KSP hasn't provided a lot of depth in the science subsystem, every mod tends to determine the experiment availability their own way. But I have a system for handling this - I just need to create a science config file for Tarsier. I'll get that out in the next release.

Raised [#253] to track.

[GrafZahl]

Hi Nightingale

Thanks for explaining this, it makes sense

In the meanwhile I had the idea to define the experiment inside the part with a Stock Experiment ID and suddenly it worked. This perfectly fits to your description.

I guess with config file you mean the files in the "science" directory of your mod like this:

CC_EXPERIMENT_DEFINITIONS
{
    name = Transier

    EXPERIMENT
    {
        name = TarsierSpaceTech.ChemCam
        ignored = true
    }    
}

I tried to bind the part with "partModule" to that experiment, but this did not work for some reasons.

Maybe also the other Transier experiments needs to be listed here.

Are you going to ignore them or do you want to apply the correct attributes to them (in spcae, landed, part-mapping)?

Thank you very much for your very fast response

Best regards,

GrafZahl

[nightingale]

Hi Nightingale

Thanks for explaining this, it makes sense

In the meanwhile I had the idea to define the experiment inside the part with a Stock Experiment ID and suddenly it worked. This perfectly fits to your description.

I guess with config file you mean the files in the "science" directory of your mod like this:

CC_EXPERIMENT_DEFINITIONS
{
    name = Transier

    EXPERIMENT
    {
        name = TarsierSpaceTech.ChemCam
        ignored = true
    }    
}

I tried to bind the part with "partModule" to that experiment, but this did not work for some reasons.

Maybe also the other Transier experiments needs to be listed here.

Are you going to ignore them or do you want to apply the correct attributes to them (in spcae, landed, part-mapping)?

Thank you very much for your very fast response

Best regards,

GrafZahl

Here's the file that will be used for the next release: [TarsierSpaceTechnology.cfg]. The ChemCam will be integrated in, but the telescope is set to be ignored (it's special and would require extra coding to integrate). Feel free to give it a try and let me know if you have issues.

[GrafZahl]

Cool, thank you so much!

I will try it today. The Technology for ChemCam is far away, but at least I can give you feedback if the ChemCam experiment is available without part or not

Thanks a lot!

[nightingale]

A little bit late, but congratulations to maculator and CosmoBro on the release of their new contract packs, KerbalAircraftBuilders and Base Construction!

I've updated the listing of contract packs on the first page (and moved it to the second post).

[Cireon]

Since yesterday my save file seems to be corrupt in some way. When activating the launch clamps through the staging process, the clamps don't detach despite showing the particles. The engines start running though. I also can't use the right-click context menu to detach. The same issue applies to any type of decoupler. I also seem to have a problem with my ScanSAT contracts, since their percentages are not showing up. My v1.0.2 backup save game still works though.

This is the error that appears in Player.log when I activate the launch clamps in the staging process: http://pastebin.com/SkZPgM07

I have put a full version of the log and the save files (both the corrupt one and the backup one) in a zip file on Dropbox: https://www.dropbox.com/s/eejvfda1b0zdp2w/ksp-info.zip?dl=0

A "highlight" in the save file is the line "update = -1000" in the corrupt save file in the ContractSystem SCENARIO (I tried replacing the value with the value from my backup file, but it reverted back to -1000 immediately on load).

For completeness sake, here's the full list of mods currently installed:

[GrafZahl]

Hi Nightingale,

sorry for the bad news, but after switching to your config file, I will get new ChemCam contracts. Just put in the "ignore = true" statement helps (however this is not a ideal solution).

Is there something I can help? Maybe I can add some Debug-prints into the code an run it on my local setup again?

Best regards,

GrafZahl

[nightingale]

Hi Nightingale,

sorry for the bad news, but after switching to your config file, I will get new ChemCam contracts. Just put in the "ignore = true" statement helps (however this is not a ideal solution).

Is there something I can help? Maybe I can add some Debug-prints into the code an run it on my local setup again?

Best regards,

GrafZahl

I'll take a look tonight.

[nightingale]

Actually, thinking about it a bit more - can you try it again? I suspect that what may have happened is that there was a ChemCam contract "cached" that showed up.

[AlphaAsh]

Just a very generic report of some issues nightingale. I'm working to narrow down the issue and my suspicion is the new Asteroid contract might be responsible somehow.

- Random waypoint generation is now resulting in kerbals being spawned beyond configured ranges.

- Stock base contracts no longer work at all.

Might also be corruption in the save file but I'm still thinking Arsonide gone b0rked up the Asteroid mission dll.

Get back to you when I know more.

[GrafZahl]

Actually, thinking about it a bit more - can you try it again? I suspect that what may have happened is that there was a ChemCam contract "cached" that showed up.

Hi,

of course I can try it again. I will do it today... so maybe I can give you feedback in some hours.

However I cancelled several times this contract it it comes up all the time again with chemcam.

As soon as I have tried it again, I will give you more feedback.

[nightingale]

Just a very generic report of some issues nightingale. I'm working to narrow down the issue and my suspicion is the new Asteroid contract might be responsible somehow.

- Random waypoint generation is now resulting in kerbals being spawned beyond configured ranges.

- Stock base contracts no longer work at all.

Might also be corruption in the save file but I'm still thinking Arsonide gone b0rked up the Asteroid mission dll.

Get back to you when I know more.

Hmm.... that's very interesting. I haven't had a chance to play with the Asteroid Day mod yet, but I took a quick peek and there didn't seem to be anything that jumped out at me. Let me know what you find.

[nightingale]

Hi,

of course I can try it again. I will do it today... so maybe I can give you feedback in some hours.

However I cancelled several times this contract it it comes up all the time again with chemcam.

As soon as I have tried it again, I will give you more feedback.

Ah, turns out it was a bug. It'll be fixed in 1.5.1

[nightingale]

New release is out! Download it now!

Contract Configurator 1.5.1

• Added new ChangeVesselOwnership contract behaviour.
  
• Added new NewVessel parameter.
  
• Added support for Tarsier Space Technology in science subsystem - ChemCam only (thanks GrafZahl).
  
• Added validation for CelestialBody name in WaypointGenerator (thanks Arctic Sesquipedalian).
  
• Additional performance fixes for CollectScience (Field Research).
  
• Fixed issue where activeUniqueValue and uniqueValue flags were not checked (thanks severedsolo).
  
• Fixed asteroid science subject from being offered unless asteroid tracking is unlocked.
  
• Fixed issue with "ghosting" vessels in SpawnVessel.
  
• Fixed parameters that weren't being hidden by the hideChildren attribute (thanks CosmoBro).
  
• Minor bug fixes.
  

[Arsonide]

Just a very generic report of some issues nightingale. I'm working to narrow down the issue and my suspicion is the new Asteroid contract might be responsible somehow.

- Random waypoint generation is now resulting in kerbals being spawned beyond configured ranges.

- Stock base contracts no longer work at all.

Might also be corruption in the save file but I'm still thinking Arsonide gone b0rked up the Asteroid mission dll.

Get back to you when I know more.

The Asteroid Day mod just adds a new contract definition, so I doubt this is causing your issues. I'd be interested in seeing your full mod list, and a log would also be helpful. Even a log where the issue is not occurring would show a few things. I've seen a few people with this issue recently, but I can't track down the source without more information.

From what I can tell so far, the underlying issue is disappearing ConfigNodes, and so far the only common mod I've found amongst sufferers is KAC, but everybody uses KAC.

Edited July 6, 2015 by Arsonide

[AlphaAsh]

The Asteroid Day mod just adds a new contract definition, so I doubt this is causing your issues. I'd be interested in seeing your full mod list, and a log would also be helpful. Even a log where the issue is not occurring would show a few things. I've seen a few people with this issue recently, but I can't track down the source without more information.

From what I can tell so far, the underlying issue is disappearing ConfigNodes, and so far the only common mod I've found amongst sufferers is KAC, but everybody uses KAC.

I've been able to reproduce the issue consistently in the old career game it first occured in so it's probably save corruption, specifically disappearing ConfigNodes as you suggest. I've started a new career game and want to try to reproduce the issue in that before I'm happy to say "not a one off".

Which mod is KAC, remind me? Is that the alarm clock? I have used that before but I'm not using it atm.

Current mod list:

AsteroidDay

AtomicAge

BoulderCo

ContractConfigurator

ContractPacks: AnomalySurveyor, FieldResearch, KerbinSideJobs, KerbinSpaceStation, Tourism

EngineLight

EnvironmentalVisualEnhancements

Firespitter

KashCorp: Rovers & Roadsters, KAP

KAX

KerbinSide

MechJeb2

medsouz: Kerbal Konstructs

PortraitStats

SeriousBusiness

StageRecovery

WaypointManager

I'll reproduce the issues in the old save and drop some logs here when I've done that.

Edited July 6, 2015 by AlphaAsh

[AlphaAsh]

The Asteroid Day mod just adds a new contract definition, so I doubt this is causing your issues. I'd be interested in seeing your full mod list, and a log would also be helpful. Even a log where the issue is not occurring would show a few things. I've seen a few people with this issue recently, but I can't track down the source without more information.

From what I can tell so far, the underlying issue is disappearing ConfigNodes, and so far the only common mod I've found amongst sufferers is KAC, but everybody uses KAC.

Whelp, I'll get a ksp.log posted once I've removed near 7 mb worth of this:

[EXC 18:51:38.841] NullReferenceException: Object reference not set to an instance of an object

ModuleParachute.SetConvectiveStats ()

ModuleParachute.FixedUpdate ()

Unrelated but annoying.

E: Here we go: http://www.kashcorp.co.uk/ksp.log

Accepted contract for minmus base. Two launches with the base spec met. First was aborted. Second achieved a landing on minmus. Not a single parameter of the base contract got met.

@nightingale This jumped out but I don't think it's related in this case. Thought I should highlight it for you though:

[EXC 19:22:03.292] NullReferenceException: Object reference not set to an instance of an object
	ContractConfigurator.Parameters.VisitWaypoint.VesselMeetsCondition (.Vessel vessel)
	ContractConfigurator.Parameters.VesselParameter.CheckVesselMeetsCondition (.Vessel vessel)
	ContractConfigurator.Parameters.VesselParameterGroup.UpdateState (.Vessel vessel)
	ContractConfigurator.Parameters.VesselParameter.CheckVessel (.Vessel vessel, Boolean forceStateChange)
	ContractConfigurator.Parameters.HasResource.OnUpdate ()
	Contracts.ContractParameter.Update ()
	Contracts.ContractParameter.Update ()
	Contracts.Contract.Update ()
	Contracts.ContractSystem.UpdateContracts ()
	Contracts.ContractSystem+
	.MoveNext ()

Edited July 6, 2015 by AlphaAsh

[Kowgan]

Thank you for the update, nightingale!

[Arsonide]

E: Here we go: http://www.kashcorp.co.uk/ksp.log

This is throwing red flags:

[LOG 18:50:13.465] [INFO] ContractConfigurator.ContractConfigurator: Disabled 3 ContractTypes.
[LOG 18:50:13.466] [INFO] ContractConfigurator.ContractConfigurator: Finished Adjusting ContractTypes
[ERR 18:50:13.528] ContractList: Contract type 'CollectScience' not found

[ERR 18:50:13.529] ContractList: Contract type 'CollectScience' not found

[ERR 18:50:13.578] ContractList: Contract type 'StationContract' not found

[ERR 18:50:13.579] ContractList: Contract 0 is invalid

[ERR 18:50:13.579] ContractList: Contract type 'CollectScience' not found

[ERR 18:50:13.580] ContractList: Contract 6 is invalid

[ERR 18:50:13.580] ContractList: Contract type 'CollectScience' not found

[ERR 18:50:13.581] ContractList: Contract 7 is invalid

[ERR 18:50:13.595] ContractList: Contract type 'StationContract' not found

[ERR 18:50:13.596] ContractList: Contract 29 is invalid

This seems to be normal for Configurator, to disable certain types of contracts, but invalidating existing generated contracts seems suspect, if Configurator had already been installed, these would not be in the save to begin with. Seeing as we're in this thread, and you have several packs installed (some quite old), I doubt you just installed these, which begs the question: how did the invalidated contracts get into the save?

Granted, I'm not entirely familiar with Configurator, so this might be normal. It is possible that in the milliseconds between when the contract system loaded, and Configurator loaded, the system generated these contracts to be immediately invalidated by Configurator. If this is the case, and it is normal, it might be a good idea to wipe the board of these contracts prior to disabling contract types, so that these invalidations do not occur.

Edited July 7, 2015 by Arsonide

[GrafZahl]

@Nightingale

I can confirm that the ChemCam bug is fixed with the latest release. Thanks for doing it so quickly

[AlphaAsh]

This seems to be normal for Configurator, to disable certain types of contracts, but invalidating existing generated contracts seems suspect, if Configurator had already been installed, these would not be in the save to begin with. Seeing as we're in this thread, and you have several packs installed (some quite old), I doubt you just installed these, which begs the question: how did the invalidated contracts get into the save?

Granted, I'm not entirely familiar with Configurator, so this might be normal. It is possible that in the milliseconds between when the contract system loaded, and Configurator loaded, the system generated these contracts to be immediately invalidated by Configurator. If this is the case, and it is normal, it might be a good idea to wipe the board of these contracts prior to disabling contract types, so that these invalidations do not occur.

Light-bulb over head.

I briefly had that new contract pack for bases installed but removed it. So it's disabling of stock base contracts remained after it was removed. @nightingale - user-error or something that should be catered for by CC?

[CosmoBro]

Light-bulb over head.

I briefly had that new contract pack for bases installed but removed it. So it's disabling of stock base contracts remained after it was removed. @nightingale - user-error or something that should be catered for by CC?

Well I had this issue yesterday I use a cfg file to disable all stock contracts then I remove that and no contract appear I'll try to reproduce it later. Because I had to start a new save game to fix this.

Edited July 7, 2015 by CosmoBro

[nightingale]

This is throwing red flags:

[LOG 18:50:13.465] [INFO] ContractConfigurator.ContractConfigurator: Disabled 3 ContractTypes.
[LOG 18:50:13.466] [INFO] ContractConfigurator.ContractConfigurator: Finished Adjusting ContractTypes
[ERR 18:50:13.528] ContractList: Contract type 'CollectScience' not found
[ERR 18:50:13.529] ContractList: Contract type 'CollectScience' not found
[ERR 18:50:13.578] ContractList: Contract type 'StationContract' not found
[ERR 18:50:13.579] ContractList: Contract 0 is invalid
[ERR 18:50:13.579] ContractList: Contract type 'CollectScience' not found
[ERR 18:50:13.580] ContractList: Contract 6 is invalid
[ERR 18:50:13.580] ContractList: Contract type 'CollectScience' not found
[ERR 18:50:13.581] ContractList: Contract 7 is invalid
[ERR 18:50:13.595] ContractList: Contract type 'StationContract' not found
[ERR 18:50:13.596] ContractList: Contract 29 is invalid

This seems to be normal for Configurator, to disable certain types of contracts, but invalidating existing generated contracts seems suspect, if Configurator had already been installed, these would not be in the save to begin with. Seeing as we're in this thread, and you have several packs installed (some quite old), I doubt you just installed these, which begs the question: how did the invalidated contracts get into the save?

Granted, I'm not entirely familiar with Configurator, so this might be normal. It is possible that in the milliseconds between when the contract system loaded, and Configurator loaded, the system generated these contracts to be immediately invalidated by Configurator. If this is the case, and it is normal, it might be a good idea to wipe the board of these contracts prior to disabling contract types, so that these invalidations do not occur.

This is pretty normal and is an unfortunate side effect of how Contract Configurator disables contract types (by removing them from the list in ContractSystem). What happens is a user installs a contract pack that disables a certain stock contract type (or types) mid-save, which then invalidates the instantiated versions of those in the users save. Unless something has changed though, what happens is that the contract system loader throws that error and does not load them (but continues to successfully load everything else).

Because it's only failing to load some, I'm not too concerned. It also appears to be a different issue than the one in this thread, as that user didn't have Contract Configurator and was getting the slightly different error:

[COLOR=#333333][ERR 14:37:07.771] ContractList: Contract config is invalid[/COLOR]

@nightingale This jumped out but I don't think it's related in this case. Thought I should highlight it for you though:

[EXC 19:22:03.292] NullReferenceException: Object reference not set to an instance of an object
    ContractConfigurator.Parameters.VisitWaypoint.VesselMeetsCondition (.Vessel vessel)
    ContractConfigurator.Parameters.VesselParameter.CheckVesselMeetsCondition (.Vessel vessel)
    ContractConfigurator.Parameters.VesselParameterGroup.UpdateState (.Vessel vessel)
    ContractConfigurator.Parameters.VesselParameter.CheckVessel (.Vessel vessel, Boolean forceStateChange)
    ContractConfigurator.Parameters.HasResource.OnUpdate ()
    Contracts.ContractParameter.Update ()
    Contracts.ContractParameter.Update ()
    Contracts.Contract.Update ()
    Contracts.ContractSystem.UpdateContracts ()
    Contracts.ContractSystem+
    .MoveNext ()

Actually that is 100% the problem in your case. That exception rolls all the way back up to the ContractSystem instance, which means that the MonoBehaviour gets killed, and no more contract system until the next scene change when the ScenarioModules get recreated. So I think we've got a completely different bug than what Arsonide's been looking for, which I'll get a fix out for.

Aside for Arsonide - any chance you can put some try/catch blocks around some of the calls to mod-supplied hooks for 1.1 (OnUpdate, OnLoad, OnSave for Contract/ContractParameter)? It's not as bad as it used to be in Contract Configurator, as I've got my own exception handling logic scattered throughout, but there's still the occasional spot were an exception in one contract (stock or mod-provided) ends up bringing the whole system down with it.

Well I had this issue yesterday I use a cfg file to disable all stock contracts then I remove that and no contract appear I'll try to reproduce it later. Because I had to start a new save game to fix this.

I suspect this is a completely separate issue (the one in this thread) - but I'm still interesting in seeing a log (and I'm sure Arsonide is too).

- - - Updated - - -

AlphaAsh - yours is one of those "I don't know how/why that should happen" type of errors... so just in case there's something else odd about the particular contract that's causing this, do you mind giving this fixed dll a quick try?

[AlphaAsh]

AlphaAsh - yours is one of those "I don't know how/why that should happen" type of errors... so just in case there's something else odd about the particular contract that's causing this, do you mind giving this fixed dll a quick try?

Will do. Always happy to help.

E: Nice. Went back to the borked save, took control of that base on Minmus and ten seconds later the contract completed.

Edited July 7, 2015 by AlphaAsh

[CosmoBro]

I suspect this is a completely separate issue (the one in this thread) - but I'm still interesting in seeing a log (and I'm sure Arsonide is too)

My problem is not that because it was without asteroid day it was on a test game with no mods other than CC and my contract pack. To test only my contracts I disable every type of stock contract so after that I enable all of them and none appear.

Also I'll try to reproduce it later because now I'm not available to play ksp. After that a log

Edited July 7, 2015 by CosmoBro