nightingale

Test it and let me know! I actually was thinking about it the other day - the only thing I could think of that would be off is the initial Kerbin Relay contract - it asks to put your 3 satellites above 600km periapsis. I assume for 6.4x Kerbin the appropriate number would be 3840km. But that won't break anything - just give you bad information. Let me know if there's anything else that comes up. For the ApA issue I may be able to easily solve with a ModuleManager patch that I can include. - - - Updated - - - Here you go, give this a try: @CONTRACT_TYPE [*]{ @PARAMETER [*] { @PARAMETER [*]:HAS[#type[Orbit]] { @minApA *= 6.4 @maxApA *= 6.4 @minPeA *= 6.4 @maxPeA *= 6.4 } } } Or download the file from GitHub. I won't include it in the main download, because I can't see a way to differentiate between RSS 10x, 6.4x, etc. If I can figure it out and clean it up a bit I will add it to the release so it gets automatically applied, but this should do for now. - - - Updated - - - And a quick bugfix release. Download it here. ContractPack-RemoteTech 1.0.1 Fixed KerbolSat mission so that it can't be completed by only one KerbolSat.

I'm going to the have clean up the documentation for EnterOrbit. That one, and the others under "Progression Parameters" are stock parameters, and they are all about progression. So entering orbit for the very first time is what makes it successful (it's what's used in the stock "Reach Orbit" contract). After that, it seems like it's just always successful automatically... so they are really one-time use. You want to use ReachSituation instead: PARAMETER { name = ReachSituation type = ReachSituation // The situation. Valid values from Vessel.Situations: // DOCKED // ESCAPING // FLYING // LANDED // ORBITING // PRELAUNCH // SPLASHED // SUB_ORBITAL situation = ORBITING // Text for the contract parameter. // Default = Situation: <situation> //title = } Same issue as above, different type. You are looking for ReachDestination: PARAMETER { name = ReachDestination type = ReachDestination // This can be inherited from the the contract type if necessary targetBody = Duna // Text for the contract parameter. // Default = Destination: <targetBody> //title = }

I have no intention of getting rid of the manual install option - but I do want to try to steer users towards CKAN to avoid having people complain it's not working when the issue is due to a missing dependency. Anyway, I've reworked the main thread to make the options more clear, and the push towards CKAN is... gentler. Hopefully this time it's better for all: - - - Updated - - - Forgot to reply to this comment. That's pretty much what I was thinking. The first contract pack (the SCANsat pack, go download it now) was done by tattagreis, so it's a little different. But don't blame him - I did it my own way just because I can be... particular about some details. Anyway, I can pretty much guarantee that any that I release will follow that structure.

Tip: Wrap your contract configuration in tags to prevent the forum software from mangling it and eating all the whitespace (I added them when I quoted you above). [/I] I'll update the How To page with some examples around that - actually updating that page was next on my To-Do list anyway. A quick explanation for the moment though: The vessel tracking system currently has 3 components: [LIST=1] [*]Defining a vessel to be tracked [*]Locking a contract parameter to one or more previously tracked vessels [*]Preventing a contract parameter from being completed by one or more previously tracked vessel. [/LIST] [B]Defining a Vessel to be Tracked [/B]To [I]define[/I] the tracked vessel, use the following within a VesselParameterGroup parameter node: [code]define = Defined Vessel Name What this will do is "track" the vessel that ends up completing the parameter under the tag "Defined Vessel Name". This tag is initially displayed to the user when they accept the contract, but once it gets assigned to a specific vessel they will see their vessel's name instead. Locking a Parameter to a Vessel To lock a parameter so that it can only be completed by a specific vessel, use the following within a VesselParameterGroup parameter node: vessel = Defined Vessel Name The name that is used needs to be one that was previously used in a define attribute. This can be in the same contract, or a different one. The name that is displayed to the user will be their vessel's name - not the one in the contract definition. To see an example of this in use, take a look at the EverythingSat.cfg from the RemoteTech pack. Preventing a Parameter from Being Completed by a Specific Vessel This is done via the IsNotVessel parameter - use it as a child parameter in your VesselGroup to prevent certain previously defined vessels from completing the parameter. I thought I had an example of this one, but realized that it's redundant in my case - I used VesselConnectivity which won't succeed if the source and destination vessel are the same. Anyway, take a look at KerbinRelay.cfg to see an example of where it could've been used. Future Plans VesselGenerator behaviour - I'd hoped to have it in this released, but it just got to the point where I wanted to get it out. Requirement for a tracked vessel existing. I probably need this - will help keep contracts that cannot be completed from showing up. Or maybe I just make that logic automatic... Anyway, hope that information helped - if not, let me know more about what you were thinking for your specific use case. TL;DR - I suspect that you want define instead of vessel, as this looks like the first in a series of contracts.

I noticed - so I didn't quote it. I wanted to steer people towards CKAN to reduce my future support effort as much as possible, but maybe it was a little over the top.

I reduced the number of spoiler tags that need to be clicked through for the regular download.

Click the "I don't use CKAN" spoiler in the first post.

I remember back in 0.24 building insane super-satellites, looking at the cost in the VAB and saying, "It's going to cost HOW MUCH?!?". Incidentally, that was also the day I learned how to edit funds in the persistance file...

Greetings RemoteTech-ers! I've released a set of contracts for RemoteTech that all of you may enjoy here: RemoteTech Contract Pack. I want to give a big thanks to the Remote Technologies Group - their code was a pleasure to work with, RemoteTech really is top notch (although I'm sure everyone here already knew that). Guess it's time that I test out my stuff in RemoteTech 1.6.... I'll let you know if I run into issues.

Version 0.5.0 is out, and a bonus. Download it now! And a bonus! The RemoteTech Contract Pack. Contract Configurator 0.5.0 RemoteTech integration! KSCConnectivity parameter - indicates that a vessel must have connectivity back to mission control. HasAntenna parameter - indicates that a vessel must have one or more antenna that meet specific criteria. SignalDelay parameter - requires a min/max signal delay for a connection. VesselConnectivity parameter - checks for connectivity between two vessels. CelestialBodyCoverage parameter - verifies that there is communication coverage of a celestial body. ActiveVesselRange requirement - requires that a celestial body has a satellite with a minimum active vessel range (achievable via either an omni antenna or dish targetting active vessel). CelestialBodyCoverage requiremnt - requirement for having a dish pointed at the given celestial body. [*]Vessel tracking! New define attribute of VesselParameterGroup to associate the ship that completes the parameter to the given name. New vessel attribute of VesselParameterGroup to require a specific vessel (previously defined using define) to be the one to complete the parameter. IsNotVessel parameter for exclusion (eg. to have two VesselParameterGroup parameters in a contract that must be met by different vessels). [*]Added Duration parameter. [*]Added PartValidator parameter and deprecated HasPart and HasPartModule. [*]Merged all orbital parameters into Orbit parameter. Thanks ttagreis for contributions on altitude and period. [*]Added PartModuleTypeUnlocked requirement. [*]Changed default values for disableOnStageChange in parameters to be more logical. [*]Added new validation to check for unexpected values in config nodes - helps when developing contract configuration. [*]Reloading contract types will also re-run module manager (which means you can now reload contract types that use module manager). [*]Minor bug fixes Feature Spotlight: RemoteTech Integration This one turned out to be a much bigger job than I expected! Five new parameters and two requirements doesn't sound like much, but there's a lot of stuff built into those parameters and requirements. Feature Spotlight: RemoteTech Contract Pack Did I mention, there's a RemoteTech Contract Pack? In the last release tattagreis was good enough to start us off with the SCANsat pack, and now I'm releasing my own. I'm hoping to periodically release these "official" contract packs - perhaps with each minor release of Contract Configurator? Who knows, maybe the next one will be even sooner! Feature Spotlight: Better Error Messages! Because of the contract pack, this is the first release where I've really had to use Ccontract Configurator. And not just testing, really using it and putting it through its paces. As such, I've a number of small bugs and cleaned up lots of error messages. The result is that it should be much harder to create an invalid contract without Contract Configurator telling you EXACTLY WHAT'S WRONG. There's lots more, so have a look at the change log, and as always - happy contracting!

Contracts for RemoteTech, built using Contract Configurator! Description This is a Contract Pack for the popular RemoteTech mod. Note that I am not affiliated with the Remote Technologies Group, but think the work they do is awesome! There are 14 one-time contracts included in the pack of varying difficulty. Here's a peek at what some of the contracts look like: Download CKAN: In CKAN, Select and download the mod "Contract Pack: RemoteTech" GitHub: For the direct download option, please ensure you have all the dependencies before raising a support request: Contract Configurator is a required dependency and can be downloaded from the Contract Configurator release thread. RemoteTech is a required dependency and can be downloaded from the RemoteTech release thread. ModuleManager is a required dependency and can be downloaded from the ModuleManager release thread. The RemoteTech Contract Pack can be downloaded from GitHub. Source The full source is available on GitHub. Change Log Note for Existing RemoteTech Saves If you are installing this on an existing save with RemoteTech, the contracts will work - but the coverage system will need about two minutes either in flight or in the tracking station to fully initialize. Until then it will assume 0% coverage of all bodies - which means that the contracts offered may not be the ones you expected. New saves are not affected. License The RemoteTech Contract Pack is licensed under CC-BY-NC-SA-4.0 Like what you see? Consider donating to the coffee fund! It will not go directly to supporting this or other mods under my care, but it may keep my motivation up!

Thanks for the plug. Just wait until you see the upcoming RemoteTech contract pack....

Clearly I didn't, although I do remember now you mentioned that it was on the 9.0 release. I'm sure tattagreis would look at a pull request if you want to send them to him.

Actually I did - but the email seemed to get lost somewhere. Anyway, thanks for manually doing that for me!

It's a... "feature". The parameter system has a flag called "disableOnStateChange", which defaults to true. What this means is that the parameter is "disabled" when its state changes to complete - ie. once you hit the target ApA/PeA it'll lock it to complete, which isn't what you want. I've exposed this parameter, so you can just use disableOnStateChange = false in your parameters. In 0.5.0 I got annoyed with how unintuitive this is - so I've changed the default value on a per parameter basis to be more sensible. In short, when 0.5.0 gets released your contract will work exactly as you expected it to.

I sent a PM to DMagic to see if he'd divulge his timeline to me. I'm hoping 9.0 would be out pretty quick - considering it's what needed for Regolith support, and there's a LOT of people using the USI mods that are likely also using SCANsat.

Oh my, I see the problem - looks like the method that was used only exists in the 9.0 SCANsat pre-release. So there's your workaround at least - upgrade SCANsat to the dev version on their GitHub. In the meantime I'll see if I can get a fix out that works for both SCANsat 8.1 and 9.0. - - - Updated - - - Nope, I don't see any way to easily get it working (with reasonable performance) under SCANsat 8.1. I'm *hoping* that SCANsat 9.0 is going to be released reasonably soon, since I know most people who want Regolith (ie. anything USI) support are already on that version. In the meantime I'll send a pull request on the NetKAN file for the SCANsat contracts to change the required version of SCANsat to 9.0. What this means for users is they will effectively not be able to download the contract pack via CKAN until SCANsat is updated (at which point everything should magically work again). As a more general item I'm going to see if I can put some exception handling logic (the contract system in its entirety seems to just fall over on any exception) to limit the damage caused by this type of issue. In your case it would mean that the SCANsat contract would be broken, but it wouldn't randomly affect stuff like the part test contracts.

Well, the SCANsat pack just uses the inherent SCANsat integration in Contract Configurator - so CC is still to blame. Anyway, as Arsonide pointed out in your thread, this seems to be the culprit: [INFO] ContractConfigurator.ContractConfigurator: Disabled 0 ContractTypes. (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [INFO] ContractConfigurator.ContractConfigurator: Finished Adjusting ContractTypes (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) MissingMethodException: Method not found: 'SCANsat.SCANUtil.GetCoverage'. at ContractConfigurator.ContractRequirement.RequirementsMet (ContractConfigurator.ConfiguredContract contract, System.Collections.Generic.List`1 contractRequirements) [0x00000] in <filename unknown>:0 at ContractConfigurator.ContractType.MeetRequirements (ContractConfigurator.ConfiguredContract contract) [0x00000] in <filename unknown>:0 at ContractConfigurator.ConfiguredContract.SelectContractType () [0x00000] in <filename unknown>:0 at ContractConfigurator.ConfiguredContract.MeetRequirements () [0x00000] in <filename unknown>:0 at Contracts.Contract.Generate (System.Type contractType, ContractPrestige difficulty, Int32 seed, State state) [0x00000] in <filename unknown>:0 at Contracts.ContractSystem.GenerateContract (Int32 seed, ContractPrestige difficulty, System.Type contractType) [0x00000] in <filename unknown>:0 at Contracts.ContractSystem.GenerateContract (System.Int32& seed, ContractPrestige difficulty) [0x00000] in <filename unknown>:0 at Contracts.ContractSystem.GenerateContracts (System.Int32& seed, ContractPrestige difficulty, Int32 count) [0x00000] in <filename unknown>:0 at Contracts.ContractSystem.RefreshContracts () [0x00000] in <filename unknown>:0 at Contracts.ContractSystem+.MoveNext () [0x00000] in <filename unknown>:0 The obvious issue from that message would've been that SCANsat isn't installed, but it does look like it's installed and loading properly (plus the ModuleManager dependency would've prevented the SCANsat contracts from loading at all if SCANsat wasn't installed). Anway, I need to dig into this one a little bit more.

I don't like it. Would be better if CKAN just automatically added it as a dependency to every mod. Perhaps a prompt to the user to ask whether they want small or large bananas to give the illusion of choice?

Wow, nice video - have some rep! That's the problem with those "specific orbit" style contracts... they are so much more restrictive than the way tattagreis did it, but so much prettier. Definitely not. The idea was that Contract Configurator would be a modder's tool for making contracts more easily. An ingame ui for it would be difficult, and I don't personally see the benefit.

One of the things that I think the stock part test contracts did really well was the way they broke up the parameters. For example (the text is probably wrong, going from memory): Speed: Between 100 m/s and 1000 m/s: Complete Altitude: Between 1000 m and 3000 m: Incomplete Test LV-909: Incomplete This way the player knows very easily what is missing before they can do their part test. This rule should apply to any parameter that is "composite" in nature. A counter example is the 0.90 waypoint ones - you have to visit a waypoint and do a science report of some kind - but it's all baked in one parameter (plug: In-Flight Waypoints helps here). One of the things that I've tried very hard to do with Contract Configurator is to keep parameters atomic - ie. it should be up to the person writing the contract config to put the pieces together. However, there's a few cases where I've gone away from that for various reasons - one of the main ones is simplicity, I don't want the contract configs to get ridiculously complicated. So, how to keep simple configuration but give the player the information they need? Introducting... Parameter Delegates. It's a fancy term that you really don't need to know - in a nutshell it's one parameter that automatically splits into parts. I'll use one of the upcoming RemoteTech parameters, as an example, the HasAntenna parameter. Here we have our beautiful and functional test craft. You can see the "Antenna" parameter in the contract window in the top right corner. The parameters complete from top to bottom, which is important because you could have many Antenna that partially meet the requirement. Let's see what happens when we target Duna. We now have two check marks! If I was a newbie RemoteTech player, I might have no idea why my antenna isn't connecting... unless of course I look at the big red X staring me in the face! So let's activate the antenna... And there we go, with the Antenna active we get the rest of our check marks. And because the stock contract app doesn't display the details of child parameters when the parent is completed, I automatically roll up the significant parts of the text. The best part? You get all this out of just this PARAMETER node in the config file: PARAMETER { name = HasAntenna type = HasAntenna minCount = 1 maxCount = 3 targetBody = Duna antennaType = Dish } Right now there's just the one parameter using this system, but I'll be converting at least one more to this system before 0.5.0 is released. I'm excited about this release - there's lots of little polish items like this that are going into it.

One of the best things about CKAN for me is a modder is that you guys will tell me when my release is broken. Thanks for all the hard work!

Sorry about all that! I dragged and dropped the wrong file, silly mistake. If you grabbed 0.4.4 from CKAN, you would be up to date anyway - 0.4.5 was a repackage because I messed up the ksp-avc file (overall this wasn't my finest release). Oh and yeah, the CHANGES.txt on github gets updated as I go.... so you get a bit of a look ahead if you check there. 0.5.0 will be soon.... next couple days, most likely.

Not a known issue, but perhaps an unknown one? Can you give me the KSP.log file (or the NullReference exception with the stack trace from that file)? That will help me confirm that ContractConfigurator is indeed the issue, and what part of your contract is causing it.

Yup, confirmed as a bug. If you don't provide trait it'll assume a "blank" trait. Since you have zero Kerbals with a "blank" trait, it considers it unmanned. Fix for both sides of the issue you described will get released in 0.5.0 - you okay waiting a couple days ?