nightingale

Funny thing is, based on that log you should be able to reproduce without Contract Configurator at all: [EXC 14:28:25.966] InvalidOperationException: Operation is not valid due to the current state of the object System.Linq.Enumerable.First[RDTech] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback) System.Linq.Enumerable.First[RDTech] (IEnumerable`1 source, System.Func`2 predicate) Contracts.Templates.PartTest.Generate () Contracts.Contract.Generate (System.Type contractType, ContractPrestige difficulty, Int32 seed, State state) Contracts.ContractSystem.GenerateContract (Int32 seed, ContractPrestige difficulty, System.Type contractType) Contracts.ContractSystem.GenerateContract (System.Int32& seed, ContractPrestige difficulty) Contracts.ContractSystem.GenerateContracts (System.Int32& seed, ContractPrestige difficulty, Int32 count) Contracts.ContractSystem.RefreshContracts () Contracts.ContractSystem+.MoveNext () What's happening is that the stock Part Test contract is failing, and bringing the whole contract system down with it. From what little I know of the tech tree stuff, what appears to happen is: The contract chooses a random part to test that has the ModuleTestSubject part module and is either researched in the next set of nodes that can be researched. It looks for it in the tech tree (pretty sure that's what it's doing when it fails). That's all I can gather - your best bet is to head over to TechManager to continue the discussion there. You may have some luck identifying the specific part causing the trouble by looking at the parts in the node(s) that are opened after you research the node that causes problems - best guess is that it's something about the tech assignment of one of those parts that is causing the problem. Good luck.

0/10 I think we hang out in different circles.

Very strange, don't see why the two would be related, but KSP tends to do weird things when stuff goes wrong. If you post logs I'll have a look in case there's anything Contract Configurator related that jumps out. Exactly - adding to that list requires creating a new contract sub-class (ie. C# code), which is the antithesis of the whole idea behind Contract Configurator. I may at some point in the future add a similar function to my own debug window - but it's a fairly low priority. For my own testing I usually just spam the regenerate button until the one I want shows up. The more the merrier. This has been a busy couple days for new contract packs (3 and counting, 4 when I release mine...) Not that I'm aware of. Is this a "I want to know so I can work on it and not do the same thing someone else is doing?" or "I want this in my game?" question? If it's the latter, you may get more visibility posting a new thread on the General Add-On Affairs sub-forum.

Thanks! Hope you like the new one... should be out by the weekend! Excellent, thanks for helping me squash some bugs along the way.

You can check out the file for Anomaly Surveyor as an example. I use GitHub for the "online" portion of the file, Cybutek also provides a server that you can use (but I've never played with it myself): http://ksp-avc.cybutek.net/ See the KSP-AVC thread for more.

No, it's a completely separate group. From a file perspective it doesn't matter, it can go in its own file or share a file with other stuff. So an example would be: [COLOR=#333333][FONT=Consolas]CONTRACT_GROUP [/FONT][/COLOR]{ // Name of the contract group name = MyContractGroup // Use this to specify the minimum version of Contract Configurator // That is required to run contracts in this group. minVersion = 0.7.0 // The maximum number of times that contracts within this contract // group can be completed (0 being unlimited). // Default = 0 maxCompletions = 3 // The maximum instances of this contract within this contract group // that can be active at one time (0 being unlimited). // Default = 0 maxSimultaneous = 1 } CONTRACT_TYPE { name = MyContract1 group = MyContractGroup ... } CONTRACT_TYPE { name = MyContract2 group = MyContractGroup ... }

That's my own validation preventing it. I'll remove the validation and see what happens... if stock KSP allows it then fine, otherwise I'd need to do something special to get that working. Raised [#149] on GitHub.

Nice update, lots of new contracts, I see! Could I ask a favour though? Could you reduce the weight=99 on all your contracts (or even remove it entirely)? Your contracts always take precedence against other contract packs. You now have enough contracts that it means it can cause complete starvation of the other contract packs. I'll probably look at the weight system soon to change it so that it only applies within a contract group (if one is specified). That way it can't be used by one contract pack to starve out another (intentional or not). I'd also suggest everyone start putting their contracts in a CONTRACT_GROUP - aside from the above reason, I've added a minVersion field to lock the contract pack to a minimum version of Contract Configurator, after it cause me some grief in the Anomaly Surveyor code pack when some users didn't upgrade when I started using new features. You can also use it to specify a maxSimultaneous across your contract pack that way, which is another way of "playing nice". I will caution you on that though, as KSP allocates the 1star, 2star and 3star contracts in order... so you could easily put yourself in a position of never offering the 3star contracts to the players if you set it up poorly. Sigh... I need to document all this in the wiki.... most of this subtle stuff isn't obvious.

It's certainly possible. I double checked the way tjsnh set them up, and they basically have top priority over other Contract Configurator contracts (meaning if there's a free slot, there's about a 99% chance the advanced progression pack will fill it over any other Contract Configurator contract. If that is what's causing you problems, then I may need to bring it up with tjsnh to tone those values down a bit.

One last teaser for the new contract pack: Note that I realized I missed a small but important piece of functionality for the contract pack, so it will be released alongside 0.7.1. I'll also take the time to fix a couple other smalls bugs and enhancement requests that have cropped up.

Pretty early - should be unlocked once you have a power source (solar panels) and an antenna. Obvious things to check would be: You have Contract Configurator installed. Go to the alt-F10 debug menu. See any red? If yes, send me logs, if no, everything is good. Try "recycling" contracts by cancelling the 2-start contracts that have been offered... see if the RemoteTech ones show up.

Hmmm, I think I need this narrowed down a little bit more. Can you provide a screenshot of a specific instance of this happening? Have you noticed this when making your own contracts, or is this just with the various contract packs out there? Is this something that you've just started seeing since 0.7.0?

Unrelated to Volatar's issue, but I sent a pull request to the CKAN folk to add a dependency on ContractConfigurator, since the current setup of the NetKAN file doesn't install the bundled one (which is the desired behaviour for CKAN). This should make the CKAN version align better with your manual install.

More than welcome! Once the new contract pack is out in a couple days I'll fix up some other the other nagging bugs in Anomaly Surveyor (and then finally give the RemoteTech contract pack some much needed love).

Congratulations on the release, the first post has been updated with a link to your post and kerbalstuff (sorry I didn't get to it earlier, was an otherwise busy day). Oh, and normally I'd rep you, but the forums says I need to spread the love to others first... so everyone go have a look at linuxgurugamer's stuff and send some rep his way if you like what you see!

Recompiled to work properly with Contract Configurator 0.7.0. Download it here!

Ah, the date stuff... short answer is, expressions aren't supported there. Raise an issue on GitHub and I'll take a look for the next version.

Hmmm, that was unexpected, I'll get an emergency patch out for this one tonight. Consider the Jool monolith contract broken under 0.7.0 until I get that out. - - - Updated - - - Shouldn't have been my update, it must've been detail settings... I'll have to look into that and make a decision on how to handle it in the contract.

The name needs to be "RTGigaDish1", or else Contract Configurator won't find it. Unless of course, you meant that you changed the title from "Reflectron GX-128" to something else (which Contract Configurator shouldn't care about). So if it really is the name that you changed, then you'll need to change it back or also change the contract .cfg files to match. The impact is that the RT_EelooRelay contract (and probably several others) isn't loading and won't be available in your game until you fix the underlying issue.

Cross-replying into the correct thread, as requested. I think I'd misunderstood what a test flight was meant to entail - I got it mixed up with Kerbal Construction Time which has the concept of a flight simulation. In that case it's supposed to be a true simulation and contracts, etc. can't be met. But meeting contracts in Test Flight makes perfect sense.

Good bye and good luck. We'll keep a place set at the table until you return!

This. I've raised bugs on the bug tracker that have shown no evidence of being looked at (and if someone actually is looking at it, then it would be nice if it at least got a comment, status change or something showing that there's a point to me raising issues there...). Sal, you must have a different profile than me on the bugtracker... I don't have any option for up/downvoting (or even seeing a score/votes on issues....).

CONTRACT_TYPE - needs to be globally unique. PARAMETER/REQUIREMENT/BEHAVIOUR - no uniqueness requirements. The name fields are used for: Logging/debug window Easy identifier for module manager patches Identifier when using special identifiers in expressions (eg. someField = @/SomeParam/SomeChildParam/someOtherField) Typically I just duplicate the type as the name unless it's something where that type is used a lot and I'd like to differentiate (eg. the VesselParameterGroup).

Ouch, that is a tough one - I only run Windows at the moment, so there's no real way I can reproduce it. Let's start with the output_log.txt and KSP.log from the crash directory... I'll see if anything interesting is in there. During development I *have* had some crashes from mono when using pretty heavy expressions.... mono didn't seem to like the amount of try/catch/finally blocks I was using (but I couldn't correlate with any other mono bug reports on the internet, or make it happen with any reliability). Another test - if it's reliably reproducible, can you do a module manager reload (alt-f11)? Part of the contract configurator reload is to do the module manager load, so it'd be nice to rule that out.

What, like this one? By the way, been meaning to ask - do I need to do anything special to work well with TestFlight (ie. prevent contracts from progressing while in a test flight)? I'm hoping that you just handle it generically for all contracts (and if you don't, I have ideas on how it could be done...)