nightingale

Squad changed some of the stuff around biome maps in 0.90, Bodrick will have to fix that bit to get it working in 0.90 again.

Not right now. Possibly soon. It get what you're trying to do - have 3 contracts for launching the 3 satellites. It may end up that you have to put the 3 together in one contract grouped under 3 VesselParameterGroup nodes, and have a special parameter in each that says the vessel is not the same as the other ones... but I need to dig into it a bit. Anyway, I think that's a better solution as you only occupy one contract slot (which are more valuable with the limits on un-upgraded buildings) *and* you can assign rewards to the parameters to still get the same behaviour.

The idea was to give it a key that doesn't really clash - F12 for stock debug, F11 is module manager, F10 was... some other common mod? Anyway, F9 is one of the worst things I could've chosen. I'll just rebind it in the next release to F11 or F12 and live with the clash. Nice stuff, glad you're getting good use out of it! Short answer - no yet, but probably soon? Long answer - What you're describing I've thought of as the "RemoteTech" problem - how do you define a contract that effectively says "launch a RemoteTech relay satelite constallation"? I'm trying to make Contract Configurator into a very big toolbox, so hopefully there will soon be multiple ways to solve this one: Using an expression for config node attributes. This one actually isn't too hard since I already have the expression parser. It can probably have a lot of applications, so I'll try to get this one in the near term. Specifying a *specific* vessel in any of the parameters. Right now the only support is for "any" vessel. What I hope to do is to extend the VesselParameterGroup so you can specify one vessel or a group of vessels. I'll have to see once I look at this if it could actually be used to solve this problem (not sure if it can, but may serve as the base for other things). Specifying a minDistance to *any* other craft - this is a variation on what you suggested, and I hadn't really thought about it before. It's simple enough to work pretty well. Using the future RemoteTech-specific parameters I plan to build. It may be possible to have a parameter that says "be in continuous contract with Kerbin for 6 hours". If the 3 satellites can survive a day in orbit without the connection dropping... then things are probably good. If you weren't trying to solve a RemoteTech problem, then obviously this answer wouldn't apply. To be honest, not sure which of these ones will make the next release - but I'll have at least one solution to this problem when I introduce RemoteTech support (which is planned for this release).

Version 0.4.0 is out, now supports a good chunk of new KSP 0.90 features. Download it now! Contract Configurator 0.4.0 - Added WaypointGenerator behaviour. Allows creation of waypoints. - Added VisitWaypoint parameter (for use with WaypointGenerator behaviour). - Added OrbitGenerator behaviour. Allows creation of orbits. - Added ReachSpecificOrbit parameter (for use with OrbitGenerator behaviour). - Added HasCrew requirement. Allows filtering on trait, experience level and count. - Updated HasCrew parameter to support trait and experience level filtering. - Added VesselMass parameter. - Added Facility requirement - requires that a player has a facility upgraded to a specified level. - Added SCANsatCoverage parameter and requirement (big thanks @tattagreis on the SCANsat integration). - Added support for turning up log levels through the ContractConfigurator.cfg file (thanks @tattagreis). - Fixed a bug in the HasPart parameter for parts with an underscore in the name (thanks @tattagreis). - HasCrew now errors if minCrew > maxCrew (thanks @tattagreis). - Most requirements are no longer checked on active contracts. Exposed attribute to override default behaviour through config file (thanks @scerion). - Added ability to reload all CONTRACT_TYPE nodes on demand (via Alt-F9). - Various minor bug-fixes. Feature Spotlight: Orbits & Waypoints Orbits and waypoints are both split into two parts - a generator BEHAVIOUR that will generate orbits and waypoints based on either fixed parameters or using randomization, and a PARAMETER for visiting waypoints or achieving orbits. Because they are decoupled, this allows for more flexibility: Generate waypoints/orbits without tying them to a parameter (perhaps the player has to "find" the right one). Create future parameters using orbits/waypoints that behave differently Have multiple parameters that reference the same orbit/waypoint Feature Spotlight: SCANsat I can't thank tattagreis enough for this one - full credit goes to him. I would've *eventually* gotten around to SCANsat integration, but he did the whole thing and threw a pull request my way. Anyway, there's a PARAMETER for having a certain coverage % for a given scan type/planet, as well as a REQUIREMENT for having a minimum/maximum coverage %. So go give all the rep to tattagreis - he made several other contributions along with this one. Feature Spotlight: No more restarting KSP! If you're building Contract Configurator contracts and want to change something, there's no more need to restart KSP! Make your change, open up the debugging menu (Alt-F9 on windows) and press the reload button. May cause problems with active/offered contracts, use only for testing. You've been warned. There's lots more, so have a look at the change log, and as always - happy contracting!

No need to suggest it, that was brought in for version 0.3.0! See this wiki page for the details. I'll have to update the wiki to list the new ones as well in case people want it as a reference.

Getting close to getting these 0.90 features integrated... how 'bout a sneak peek? Waypoints and orbits, oh my!

This question seems to come up enough that I added a section in the wiki: Creating an Agency

Right now I'm working on integrating the orbits parameters that FinePrint introduced in 0.90. If that's too rigid I am considering later adding individual parameters for different orbital values such eccentricity, inclination, etc. I'll probably change it to load at a few set points (main menu, load of game) as well as just giving a hotkey that will force-reload anything. Will make testing a lot easier. In stock, each contract type has hard-coded logic in MeetsRequirement that determine whether it is available to be offered to the player, but it's different for each. Part test contracts start showing after you reach space, the FinePrint satellite contracts need you to have researched a few key bits (probe cores and power). After that it's pretty random, when it wants to generate a contract it'll just cycle through the list trying each one until one generates. I assume that it goes through the list in a random order or something like that so that each contract has a roughly equal chance of coming up. Contract Configurator is slightly different - it is only one contract type, but it will "reskin" it when it's offered to look like many different ones. But it applies the same concepts with the REQUIREMENT node to make it work the same. There is also a weight parameter that can weight the choice more heavily towards or away from a CC contract type - but it only works within the ContractConfigurator contracts (ie. it won't make a Part Test less likely to come up). Yup - the general idea is you can organize them however makes sense to YOU. Correct - agent picking is random (unless you specify an agency in your CONTRACT_TYPE). If you don't want your contract to show up multiple times, look at the maxSimultaneous attribute on CONTRACT_TYPE.

The usual helpful response: it worked for me! The only thing unusual I got was a warning about not finding the Agency (which is normal considering I don't have the customized agency). But perhaps that's where your problem is - try removing the agency in your contract and see if that changes things. Oh, and I probably should've mentioned this when I saw it back when you posted your full configuration - the way you're setting up your agency is wrong - if I'm not mistaken you can just create your own .cfg file in your own directory with the agency details (rather than overwriting the .cfg in the Squad directory).

Version 0.3.4 is out, small fix for the TweakScale issue reported by Kamuchi. Download it now! Contract Configurator 0.3.4 - Fixed incompatibility with Tweakscale.

I'm pretty sure the problem is on TS's end, so I raised it on their GitHub. However, I can think of a way to make it less fragile on my end - so I'll try to get that workaround coded up.

Wow, just wow. From those errors, I wouldn't have believed you when you said it was because of Tweakscale if I hadn't just reproduced it myself. No promises on an ETA on this one... from my quick googling I see a lot of people complaining of this error with Unity. My best guess from that is that it's some issue with an mis-referenced... something... in Tweakscale, which is breaking reflection across the board.

Took me a bit to figure out what E/M/H was all about - they're the buttons in the under the Contracts / Add debug window. These are stock KSP, and I've never used them before. About all I can figure from pressing them is they will attempt to generate a new contract if the conditions are right (but all I could get them to do was generate a message saying "Contract of type <x> was not be generated".) Not sure if you're a programmer or not, so I'll give you both the programmer and non-programmer answers. PROGRAMMER: In the Squad provided ConfigNode class there's a method called GetConfigNodes(string) that will get all nodes of a given type from all config files. NON-PROGRAMMER: Wizardry. Actually, I had I thought - if you were poking around in the debug menus - one of the current limitations on Contract Configurator is that it can only load up the contract configuration when KSP starts. So if you change anything in the cfg file, you need to restart KSP. I'll probably look at making it reload the config every time you drop back to the main menu (or even on load of a save game) to make this a little easier.

More than likely it's that KSCLanding requirement that's causing you trouble. It's one of the stock "ProgressTracking" items that I only did quick testing on - so I can't tell you *exactly* what needs to be done to meet that requirement other than the seemingly obvious "land something at KSC". And just so you're clear on what a requirement means, from the documentation: In other words, you don't need to have any REQUIREMENT nodes - try removing that node to start, and see if that works.

From the first post: Unless your no documentation comment was regarding TextGen. In that case, TextGen is the stock contract text generator, how it is used with Contract Configurator is documented here. The short version of how to create contracts using Contract Configurator is: Create a new .cfg file in any directory you want under GameData. Read through the documentation, starting with the section on the main CONTRACT_TYPE node. If you're still not sure, take a look at some of the test contracts that I use for unit tests here. That should give you an idea of what to do.

Actually the SCANsat support wasn't planned for a little bit.... but Tattagreis was kind enough to code it up for me. Oh, and RemoteTech support will be coming - just not in the next release (likely the one after). I may need to wait until their 0.90 release though - and I don't know when that will be.

This is all cleaned up now: By default, most requirements don't get checked for active requirements If someone wanted to change this behaviour, the attribute checkOnActiveContract is exposed for REQUIREMENT nodes. If it *does* get set up that way, instead of silently failing, now the contract is force-failed (with the notification going to the player), and the contract is removed from the window. EDIT: Oh, and one last note - for the type of contract you're building, consider using the Sequence type to group instead of All. It won't make a difference in this instance, but you may run into cases where you want to the force the player into following the steps in the order given.

I was looking in all the wrong places. The reason it worked for me is I actually changed your contract - I removed the !ReachSpace requirement (so I could load it into my existing save). What happens is that KSP checks the contract requirements *every single frame*. As soon as the requirement is no longer true, the contract becomes invalid. But silently invalid - it removes it from your list, but never updates the contract GUI. Anyway, obviously not what's intended here, and I already have the logic to handle this for another requirements. So I'll do a pass looking for all the requirements that shouldn't be re-checked after the contract is accepted. You'll have a fix in 0.4.0, which will come sometime before Christmas.

Your config looks good at a glance, but I won't be able to look in detail until tomorrow. Are you using hyperedit to test? I had some issues where hyperedit wouldn't fire all the expected events, which would prevent some parameters from firing at the right time. If that's the case and it works from a "manual" launch then we're okay. If that's not the problem then I'll do a bit more digging tomorrow. Oh and nothing to do with your issue, but the way you have your contract set up with disableOnStateChange = true means you'd have to be doing all 4 of those things simultaneously, which is not likely what you want. Try without disableOnStateChange. EDIT: Looking closer, I see you have the anti-hyperedit line in there, so safe to say you didn't use hyperedit. I'll dig into this. EDIT2: I should wait until morning for these things. Your use of disableOnStateChange is fine - since the EnterOrbit parameter you've used (a stock one) would be better named HasEnteredOrbit (ie. having done it at some point in the past would be sufficient). Anyway, the contract you supplied worked perfectly for my quick test. Can you confirm you're on Contract Configurator 0.3.3 and KSP 0.90?

And what about the second one?

Thanks. I would've probably gone crazy trying to figure out how else to do it.

@Arsonide - How do I get the Waypoint class to pick up a custom icon? I'm setting Waypoint.id to the name of the custom icon PNG, but the *only* way that it seems to pick it up is by putting it under Squad/Contracts/Icons, which I'm sure can't be the only way to get it to work.

Version 0.3.3 is out, fixes an issues that potentially breaks contract generation (thanks @tattagreis). Download it now! Contract Configurator 0.3.3 - Persistant data store can now store config nodes. - Fixed an issue with maxCompletions not working correctly (thanks @tattagreis).

Most influential mod of 0.90!

When the time comes here's another example for you from ContractConfigurator - it's a *very* generic data store for saving values within the save game: PersistantDataStore.cs. If you want to use it, please take this post as me officially waiving the ShareAlike clause for this code for Nereid (ie. you can re-release under the BSD2 license).