nightingale

Great, that sounds perfect. If you can do a GitHub pull request, that would be even better - but if not throwing it up on the contract pack's thread will still save me a lot of effort.

0/10 That's a lot of reputation for someone I've never seen before.

Last time I looked at it, it was three. Still, my fault for not checking it more recently than 8 months ago. Okay, I'll most likely change it to 4, and make sure it can be completed with C16s.

I'm open to suggestions for doing it one way or another. Every contract for celestial body coverage other than the Kerbin one just says "get coverage of x", and doesn't tell the player how to get it. For the Kerbin one I wanted it to be somewhat tutotial-like, so I went with what I thought was the most basic/common network. If people think 4 makes more sense, I could change it to for. Or maybe I can leave it as 3 but make the "set it up this way" part optional and make the real contract requirement to just "get coverage" like the other ones....

I'll look into that one.

Sounds potentially like two unrelated issues. This one is the bane of Contract Configurator. There's two major issues with the stock contracts app: If it's hidden it will queue up "updates" from parameters changing. When you open it, for each update it will fully refresh itself. I have a semi-workaround for this in Contract Configurator (it used to be worse). Raised bug #3964 on Squad's bugtracker, which is being completely ignored. If the contract is big, refreshing it even once in the contract app can be expensive. What CPU do you have on your machine? That'll help me determine if your primary problem is #1 or #2. That being said, I can't guarantee any more workarounds - it's Squad's problem and my best suggestion is to go use DMagic's Contracts Window+. What's the first error in the log before this starts happening? There's nothing modded about that error, so it's not directly Contract Configurator - although it's possible Contract Configurator makes some assumption that causes an exception, which puts the game into a bad state, which then causes that error to occur over and over... The "debris" could be a spent stage or piece of your vessel that "fell" off (I'm sure it wasn't an important piece) and then went out of physics range (~2km).

I created a post in the Add-on development section about contract balancing. Although not specific to Contract Configurator, it's (hopefully) a good read for anyone looking to write contracts. Add-On Development: Balancing Contract Rewards

Something I find surprisingly difficult to do is balancing contract rewards. I've laid out my thoughts on some ways to balance the rewards, as well as some of the issues/pitfalls surrounding it. Please, if you disagree with what I've said or have other ideas, post them below and I'll add them to this post! Types of Rewards The first thing to mention is that there are three different types of rewards: Funds, Science and Reputation. Because the gameplay use of these "currencies" is very different, a very different thought process needs to go into balancing them. I'll break down my thoughts below on this. Reward Multipliers The other thing that needs to be mentioned before getting into the details is the reward multipliers. There are multipliers for the contract's celestial body and for the contract prestige. The multipliers are applied regardless of the type of reward (so the same multipliers get applied for funds, science and reputation). The multipliers are (accurate as of 0.90): [TABLE=width: 0] [TR] [TD]Celestial Body Sun 4.0 Moho 7.0 Eve 5.0 Gilly 6.0 Kerbin 1.0 Mun 2.0 Minmus 2.0 Duna 5.0 Ike 5.0 Jool 6.0 Laythe 8.0 Vall 8.0 Bop 8.0 Tylo 8.0 Pol 8.0 Dres 6.0 Eeloo 10.0[/TD] [TD]Prestige Trivial 1.00 Significant 1.25 Exceptional 1.50[/TD] [/TR] [/TABLE] DMagic is the first one that I'm aware of that did digging to pull these values out in this post, so credit to him (although he doesn't have the prestige rewards quite right due to rounding). Note the implication of this. If you set the funds reward to 10,000 for a trivial contract on Kerbin, the reward is 10,000. If you set it 10,000 for an Exceptional Eeloo contract, the actual reward is 150,000 - a LOT more than what you may have intended. Balancing Funds Funds are arguably the easiest to balance, for the following reasons: Contracts are the only source of funds in stock KSP (except for strategies, but more on that later). Meeting a contract typically requires spending funds - which can be used as a basis for determining the reward. Funds required to meet the contract The easiest aspect to look at when balancing funds is the cost of meeting the contract. For many contracts, it's fairly easy to get a good idea of how much it will cost the player to meet the contract by just building the typical vessel(s) required to meet the contract in the VAB/SPH and looking at its cost. Obviously this approach is easier for a contract like "launch a satellite in LKO" vs. "build a massive Eve outpost". Use this number as a guide for the minimum reward that your contract should offer. I find it can be convenient to just apply a multiplier to this number to reach a possible value for the full reward. You can also use this as the contract advance. Player time commitment required Another aspect to look at is - what is the real playing time commitment that is required of your player. It is not appropriate to give a 1,000,000 funds reward to the player for testing a part on the launch pad - as that takes about 5 seconds (and to the point above has a cost of zero funds because they can recover the vessel immediately). Because of this I consider the stock landed part test contract to pretty much be an exploit - there's no good gameplay reason to keep them. More appropriate is giving a large reward for something that takes the player a couple hours of gameplay time to accomplish - like launch a big station. Balancing Science For a lot of contracts, balancing science is easy. Set it to zero, and be done with it. The existing system of gathering science through experiments/crew reports is a much better gameplay mechanic for getting science. Also, as it stands science is reasonably easy to get - dumping a ton more into the players economy via contracts may not be desirable. If it makes sense to have science as part of the contract reward, then read on. R&D Tech Unlocking The only use of science in game is unlocking tech (again, aside from horribly broken strategies, which I'll get to soon). So the best way to determine how much science to give is by looking at the tech tree and the approximate tech level a player using your contract should be at. The early nodes require 5-45 science - so unless you want the player to be able to unlock a lot of nodes from the one contract, keep the early contract science rewards low (20 or lower). The highest nodes in the tech tree cost 550 (or 1000 for the special nodes that aren't used in stock KSP) - so gives an upper limit for how much science should be rewarded - but I would argue that at that point in the game the player can get lots of science in other ways and doesn't need a ton from contracts. As with funds, keep the player time investment in mind. Balancing Reputation Reputation is easily the hardest thing to balance, for the following reasons: Its use in game is limited - better rep really only means more/better contracts get offered. The amount of reputation a player has is not made obvious to the player (the slider goes from -1000 to 1000) The amount of reputation a player receives changes based on how much reputation they currently have. I don't have the formula handy, but if a player has 900 reputation, and you try to give them 100 more, they will end up with a total of 950 (or something like that). Effectively, a player can never reach 1000 (or -1000) reputation. Strategies are broken. So because of all these factors, most players will see reputation as next to useless, and just apply it towards the +Funds or +Science strategies, thus ruining your careful efforts to balance Funds/Science. So my best advice - keep the reputation rewards low. Reputation has minimal gameplay impact and only ends up breaking the system. Failure is not an Option The last thing to talk about is the contract failure values (for funds and reputation). I usually don't even bother. Most players will just quickload or revert, which gives very little purpose in attaching failure values to the contract. In fact, it just gives players more of an incentive to quickload/revert. Yes - there are likely some "ironman" players out there, but I suspect they are the vast minority. One place where I might actually look at the failure values is if it can be part of an interesting gameplay mechanic. For example, a scenario where the player has two optional paths in a contract (perhaps implemented as two contracts where only one can actually be completed). Then the failure becomes tied to a player choice - rather than an excuse to quickload. This could also be used to give reputation a little bit more meaning. The choice could be between getting a bunch of funds by bringing back rare unobtanium, but being forced to sacrifice a Kerbal and lose a large amount of reputation. (Could this be implemented via a negative rep reward in a contract? Not sure....) Another example where the failure values is for a contract where the duration is very long and the player is expected to do other things while waiting for the contract to complete. (eg. stay in orbit with TAC-LS for 1 year, but launch other missions during that time). Then quickloading may not be an option. However, I'd still consider this very carefully - the failure penalty may be viewed by the players as punishing, and may turn them off of the contract completely. The fact is - they've already lost out on the contract reward (and possibly the advance). Taking more funds is just not fun. TL;DR - Strategies are broken from a gameplay/balance perspective.

Nope, should work fine with your existing save. Already active/offered contracts will not be updated with the changes above, whereas any new contracts generated will be up to date.

Also, Contract Configurator supports that today, but there's no mod that is currently using that.

... which aligns very nicely with my own plans around contract packs - since I don't plan to play in the space that's been defined in Yemo's roadmap at all. I'll be doing more contracts packs that add to other mods (like the RemoteTech one did) or ones that provide "interesting" gameplay (like the Anomaly one did). So hopefully in the next few months you guys will have a lot of contracts to choose from in your career playthroughs.

From the top of the page on this thread: We need to petition the CKAN folk to add a deprecated flag into the CKAN spec to remove the user confusion.

Forgot to reply on this one yesterday. Basically, final frontier seems to have some major issue with how it is storing things in the persistence file (you can see lots of people reporting it in that thread). Unfortunately Nereid has real life commitments that have been keeping him away from modding - so he hasn't been able to look into it. TL;DR - I can't take responsibility for what happens to your FF data.

No problem, glad that it got sorted out (I was half worried you'd come back and say that you were on the correct version).

Now with more love for Mac & Linux users! Download it now! Waypoint Manager 2.1.2 License change - now licensed under the MIT license. Use platform independent method for file paths (thanks dak180 & ultrasquid).

In terms of the history, Contract Configurator was started before the Contracts.cfg existed in stock - so at the time there wasn't a way to disable via configuration. They should be compatible. The stock way just prevents the contracts from being eligible to generate. My way is more brute force - it rips the contract right out of the contract system. No to doing the same thing, but equivalents from scratch is possible (depending on the contract). Right, and LGPL is in consideration. I disagree with GNU's depiction in that link of the situation as being a moral battle between two sides.... but I really don't want to turn your thread into a discussion about what is more free.

See GitHub issue #90: ReachState is broken without a situation, will throw a NullPointer The fix for this was released in Contract Configurator 0.5.5, which was released on January 13th - so please, please make sure you're up to date next time you have weird issues (also, KSP-AVC comes highly recommended). Oh, and not to be a pain about this, but if you'd provided the logs the first time around, the version of Contract Configurator is usually one of the first things I check. Anyway, all's well that ends well - I think this confirms that the Initial Contracts package are working as-is on the current version (as both Yemo and I checked it and had no issues).

It is a good point and I did consider it when releasing initially. There are things that are appealing about creative commons as a general license that I won't get into here. In terms of my intent for Contract Configurator: If you create content "for" Contract Configurator (ie. create contracts or other configuration), I do not care what license you use - I do not consider this a derivative work that falls under the ShareAlike clause of CC-BY-NC-SA-4.0 license. But there's enough ambiguity here that I should clarify in Contract Configurator If you link to it (and I mean this in the programming sense), I do not care what license you use. This would seem to be at odds with CC's ShareAlike clause (although as you point out via your link, it's not explicit, since it's not designed for code). I need to fix this to make my intent clear in this regard. If you look at Contract Configurator for examples of how to do something and take a method or two (or even a class or two), I really don't want to force you to use the same license (although I would appreciate a quick attribution). I'll have to give some thought about how I want to lay this out, as I would have issue if someone took the whole thing and changed the license. I'll consider potentially re-licensing under a license that meets my personal requirements, but it definitely won't be GPL (does not meet #2 above). But what confusing me is you already have Contract Configurator as a recommended mod - so if you want to disable any/all of the contract from stock, you just need to provide this in a config file as part of your mod: CONTRACT_CONFIGURATOR { disabledContractType = AltitudeRecord disabledContractType = ARMContract disabledContractType = BaseContract disabledContractType = CollectScience disabledContractType = ExploreBody disabledContractType = FirstLaunch disabledContractType = GrandTour disabledContractType = ISRUContract disabledContractType = OrbitKerbin disabledContractType = PartTest disabledContractType = PlantFlag disabledContractType = ReachSpace disabledContractType = RescueKerbal disabledContractType = SatelliteContract disabledContractType = StationContract disabledContractType = SurveyContract } Or is the concern that doing so turns Contract Configurator from a recommended to a required dependency? Anyway, if you want to do it in your own code, I have no issue with you using the method from Contract Configurator under any license you choose (although this would mean a custom DLL, yes).

Yup, that one was already reported on GitHub - I'll try to get a fix out tonight. It's due to my naïvety - I assumed that the Mono CLR would provide platform independence.

Yup, not something I've been able to reproduce either. All I need is the ksp.log or output_log.txt - that will have the full stack trace and then I can work from there. As discussed above the "input is null" business is a complete red herring. The null reference exception is the issue. There are many, many places where when an exception happens stuff in the squad code just breaks - so things like not being able to enter buildings, quit, etc. are actually fairly "normal". Anyway, provide the log file, then I can investigate. Note that it no longer references the stock one (since that was broken and didn't seem to always fire). But it's still based on the stock "achievement", which still only fires for a manned vessel.

More on this one - I had a look and if you change it to Altitude, you get the following errors: Which is exactly what I would've hoped would happen. The contract is then disabled, which shuts up the 'Input is null' error messages (by removing the contract from existence). Anyway, I did take a closer look, and my best guess is it's the contract system access some field or other from the contract, and then complaining because the value is null. I'll have a look and see if I can make a change to shut it up, although it's never cause any problems that I'm aware of. - - - Updated - - - Aha! It happens whenever you save a null value into a config node. The "problem" is that it comes out on load as an empty string instead of a null one (which I've always just accepted as how it works and dealt with it on load). Anyway, now that I know what the "error" (should be a warning) is about, I can shut it up. That being said, it is nothing that will hurt anything, and can be safely ignored.

As requested, it's now working in sandbox. Download here. Waypoint Manager 2.1.1 Persist "Use stock toolbar" option across restarts (thanks dak180). Now works in sandbox mode (for custom waypoints).

The Error: Input is null is from Contract Configurator, but I have not been able to figure out for the life of me where from (and it has never caused any issues that I'm aware of, other than the log spam). As such, I've been putting off digging into it (if anyone has any clue what it means, let me know). I double checked the code, and it definitely should be minAltitude and not Altitude. In fact I probably should change it so that it validates that there's at least one of the expected parameters (altitude, speed, etc.). If you put Altitude, it should ignore it, and then the parameter would succeed for *any* vessel state. So it seems there's something very weird going on (and I won't have time to look into it until later tonight). Are you able to provide some screen shots of the contract working with that? Also, hit alt-f10 to go into the Contract Configurator debug window - you'll be able to inspect any errors/warnings related to the contract there (if any).

New version out, now with the ability to create waypoints by clicking on the map (toggled from the new waypoint GUI). Download it here! Waypoint Manager 2.1.0 Display waypoint marker while it is being created (in flight and map view). Toggle to automatically set the waypoint to ground level when creating a waypoint. Allow setting the waypoint location by clicking on a celestial body in the map view. Minor bug fixes. Let me look into it - I have a feeling that it won't work outside of career mode, because the underlying core system (the FinePrint waypoints) are completely contracts based. Still, you never know, I may be able to hack it to work.

New release out with some minor changes (mostly as discussed above). Download it now! ContractPack-AnomalySurveyor 1.0.1 Use new parameter save/load exception handling model in Contract Configurator 0.6.2. Clean up titles and descriptions to reduce spoilers. Remove one of the underground monoliths from Kerbin (too boring to visit). Change to only need to visit one of the two Mun monoliths to trigger the Jool mission.