nightingale

It would not behave any differently than if you completed it the normal way. It could hypothetically cause another contract to show up, if the contract pack was configured that way (I don't know of too many that use that functionality though, so you're probably fine).

That would be the preferred way - force completing just fires the contract completion event (just like if you'd completed the parameters yourself). So if the contracts have any special logic for completion it would fire then.

Good idea, wiki has been clarified.

Nope, it's actually a huge pain to do that, because it is a string and can have non-numbers in there. If you want them to be numerical, then give a sufficient prefix, such as "01, 02, 03, 04". Or make it alphabetical: "A, B, C...". The main reason for this limitation is that the sortKey defaults to the title (hence why the default sort is alphabetical).

Yup, new release should come out in the next couple days, was going to mention that bug when you mentioned sortKey.

You can grab the latest dev version from here. In general, I highly recommend doing this if there are pending changes that you're waiting on - that way if there's any issues you can get them fixed quicker.

@hargn - it was a bug in the logic (it was checking for the data in the wrong contract_group node). That should be fixed now. The problem with the inheritance is that Contract Configurator is very strict with the namespacing for the variables. Changing that would have a very big impact to the parser. Right now when you do an @variable notation, it will defer the load if the variable isn't defined. But if the variable can be defined at different levels, and the parser does find it, it won't be able to know if this is the right one, or if the correct one still isn't loaded yet. As long as I define the load order of the groups properly, it may still work, but for the amount of effort I'm not sure what it buys you (the ability to copy + paste the same variable name across different contracts and have a different meaning?).

Anywhere in GameData. The default is GameData/ContractConfigurator/ContractConfigurator.cfg

You shouldn't need to set requiredValue = false, since the value is a constant (and is always there). I tried it out with a basic test, and it worked for me. Can you generate another log with debug turned on? Please add the following verbose logging (you'll need to download the dev dll for verbose logging to show up). CC_DEBUGGING { // Possible LogLevel: VERBOSE, DEBUG, INFO, WARNING, ERROR logLevel = DEBUG ADD_LOGLEVEL_EXCEPTION { // Type name type = ContractPreLoader // Possible LogLevel: VERBOSE, DEBUG, INFO, WARNING, ERROR logLevel = VERBOSE } ADD_LOGLEVEL_EXCEPTION { // Type name type = ContractType // Possible LogLevel: VERBOSE, DEBUG, INFO, WARNING, ERROR logLevel = VERBOSE } }

Here you go: Nothing special I can think of for GAP. You'll want to look at the sort keys for child groups and contracts most likely too.

Took a quick peek - looks like your Kolniya contract is pulling from the wrong variable: targetBody = @STGUnmannedMissions:UnmannedMissionPlanet

You'll have to post that in the unmanned mission thread in that case. That's a nice idea, but not technically possible (KSP doesn't preserve line number information in the config nodes).

Can you show me the screen that says it failed?

Sounds like this is the symptom of a much bigger problem. I can't say anything beyond that without a KSP.log file.

Update unmanned Missions.

Nope. You need to either be close* or have it set as the active waypoint though. *close is hard to define, as it's based on velocity. If you're standing, it's a couple km. If you're at orbital velocity, it's a couple 100km.

On mobile, so won't be full code. You need something like this: @/mediumPlanets.Where(cb => cb.CanHaveKolniyaOrbit()).Random()

@BeafSalad - See my response in the DMOS thread (fixed for next release). As far as the two mods having similar sounding names for experiments... there's nothing I can do about that.

@BeafSalad - Fixed that for the next Contract Configurator release.

@hargn - You managed to find not one, but two bugs/limitations in the resource parser. I've fixed both for the next release (I only added - and _ to the list of value resource characters, so if there's any other ones you can always fall back on to the string method now).

@5thHorseman - There's a bug in that Expression requirement that will cause you grief - the value for $ResearchWings in that example is calculated at contract offer time, but it really needs to be done at each check. I'll need a bit to fix that one. That being said, if you're okay with all contracts being offered, then I think maybe what you really want is child contract groups (so you can have a Wings contract group under your main group, and put all the wing contracts in there). @pap1723 - Interesting approach!

I don't quite understand the idea (probably because I'm tired). But let me make sure we're on the same page, as I'm worried there's a misunderstanding when you say "toggle" contracts. A contract in Mission Control can have the following states: Unavailable (greyed out). A contract can't be generated, for whatever reason Completed (greyed out, green checkmark). Special case of unavailable for maxCompletions = 1 with the contract completed Offered (yellow) Active (green) So when you say toggle - which two states are you looking to toggle between? As I understand the question, I think you need to use expressions and set flags. So in your "enable wing" contract, do this: BEHAVIOUR { type = Expression CONTRACT_ACCEPTED { type = bool ResearchWings = true } } For "disable wing" do this: BEHAVIOUR { type = Expression CONTRACT_ACCEPTED { type = bool ResearchWings = false } } For each of the contracts in the wing "group": REQUIREMENT { type = Expression expression = $ResearchWings } The above should be checked on active contracts by default. So they will fail if you set ResearchWings to false. Not an easy way, but you can do what @inigma does and set a 1 second timer. See here.

@pap1723 - Whoops - I checked that the sortKey was getting properly assigned, but looks like I'd never hooked it up to use the correct value when sorting. That's fixed now.

No, the check is only for active contracts, so after giving it some more thought, I'd be highly surprised if my fix actually fixed your problem (in fact, the change I made should be completely unnecessary). So, a quick primer on the internals of data nodes and expressions is needed for background. This is what happens when a contract generation attempt is made: Basic requirements are checked - this is stuff that should not depend on expressions (maxCompletions, maxSimultaneous). This is done early to eliminate the need to execute expression (expensive!) if we can easily decide the contract should not generate Expressions for non-deterministic values are executed. A non-deterministic value being something where the value can't be determined at game start. HomeWorld().Children() is deterministic - we only need to run that once, and it's always going to be [ Mun, Minmus ] (yes, Kopernicus can change this, but not without restarting KSP, which is what's important). AllVessels() is non-deterministic, because the player creates/destroys vessels all the time. The values are stored in an internal DataNode (similar to the config DATA_NODE) against the ContractType (note - not the Contract). Data with a uniqueness check is stored against the contract. Extended requirements are checked. This is everything that depends on expressions, such as uniqueness checks and REQUIREMENT nodes. Contract initialization is done. This is where the Parameters are generated from ParameterFactories (going from ContractType to Contract). This step is what creates a Contract that is now independent from the ContractType. If it gets through all that, it's stored internally and the periodic Update() calls will re-check requirements (and expiry date, and stuff like that). What's missing is the copy of the requirement data from the ContractType to the Contract in the initialize setp - the refactor of 1.15 inadvertently moved that from contract generation to contract save time. So the RNG value you were rolling could effectively be re-rolled for contracts for the time between contract generation and contract save (eg. doing a quick save). TL;DR - this really was a bug, and I've fixed it for the next release. Docking is messy and nasty in KSP, so it's entirely possible that there's a bug here, and entirely possible that it needs the unique circumstances that you have set up (docking port vs. claw, relative position of root part vs. docking ports, which ship is active on docking). So what you need to look for is a section called ContractVesselTracker in your save. You should have an entry in there that looks something like this: VESSEL { key = Mir id = f6dc8fbc-9c90-4525-93f5-83d5e7a90571 hash = 771082057 } The id can change (if you dock, the vessel with that id should cease to exist), but the hash should stay the same (the hash identifies a connected graph of parts that shouldn't detach under normal circumstances - so the minimum set of parts between docking ports/decouplers/claws). If the Mir section is disappearing, you have a problem. If the hash is changing... you may have a lesser problem. So it sounds like attaching the module is the trigger that is causing that section to get lost. So what I need you to do is confirm that's what's happening in the save, and then provide me the quicksave from right before the docking so I can reproduce with your particular vessel. @HoveringKiller - This was due to a change introduced in Contract Configurator 1.17.0 to prevent invalid Kolniya orbits from being generated. @linuxgurugamer should've already released the update to Unmanned Contracts to prevent that error from occurring.

@SpaceCommanderNemo - We're always looking for Contract Pack authors, and you may find that you are the most motivated to get your vision out! Check out the Contract Configurator wiki if you want to give it a go!