nightingale

Yup, everything seems to be alright! Forgot to come back here and post an update. Important notice to CKAN users: Waypoint Manager now shows up in CKAN under the identifier "WaypointManager" instead of "InFlightWaypoints". This means that you will need to uninstall the one that shows up under InFlightWaypoints and install the WaypointManager one.

Holy wall of text batman! I'll try and boil this down to the essentials. For starters, look at VesselParameterGroup. I've been meaning to write some detailed documentation for that as it's a pretty key piece for most contracts, but haven't yet. You'll need it for most of the items below. PartValidation - Validate that a vessel has/does not have specific parts/part modules. VesselParameterGroup - Can be used to "save" a vessel in the first contract, and then be used to work with that vessel in the next contract. (ie. Contract 1 "saves" Mir, Contract 2 says dock new vessel Kvant-1 with the previously saved Mir). No, but planned for 0.7.0. That release will introduce some mechanisms for "selecting" existing ships as the target of a contract. The idea is that you would give it criteria (orbiting Kerbin, has x docking ports) and it if there is a matching ship it would select it for the contract. Yup, like #1, but simpler. You can't be as "random" as the stock ones, although 0.7.0 will make it possible to make something a lot closer. If you want to customize the stock one to use different modules, I believe you can do that by editing/module-manager'ing Squad/Contracts/Contracts.cfg (file name may not be exactly right, don't have KSP on this machine). Same as #3 - somewhat possible now, closer in 0.7.0. As described in #1, use VesselParameterGroup to save it in the first contract, then VesselParameterGroup in the second contract to reference it. HasPassengers - Parameter for specifying passengers on board a vessel (I may change this a bit in 0.7.0 though). Issue #63 - This will introduce a parameter for more detailed science "perform experiment x". Planned for 0.7.0. Don't really have much for tracking crew. You're thinking something similar to the vessel tracking? May need to give that some thought, likely not until post-0.7.0 though. - - - Updated - - - At the moment there is nothing for a "clear" docking port. Throw up a github issue and I can look into it.

TechManager doesn't allow you to put those files in your own folder? If so, that's rather obnoxious of them...

In the command line it shows up as InFlightWaypoints, and in the CKAN GUI it shows up as Waypoint Manager, but after playing with it, there seems to be problems. The idea was to provide proper backwards compatibility/upgradeability, but it doesn't seem to be working right. I'm going to replace it in CKAN with one called WaypointManager... we'll see if that just ends up breaking things further... (apologies in advance to Hakan who will likely be fixing the mess I make in 2 or 3 hours).

Had a closer look and there were some other minor issues with Jool/Sun waypoints that are now fixed. Download the new version here. Waypoint Manager 2.1.4 ​Additional fixes for Jool/Sun waypoints.

This has nothing to do with Kerbal Flight Indicators - but they should work together, as far as I know.

Well, first place to look is the wiki, specifically the How-To page. Then just start configuring! You can look at the contract packs as examples, but the parameters should be fairly well documented (and if you have issues, let me know and I can fix up the documentation). If there's something that you need/want that is missing from the current set, just bring it up on this thread or create a GitHub issue and I'll try to get it into the roadmap for the next version.

Hmmm.... the only reason that could happen is the PQS controller is null. Don't suppose your save has waypoints on the Sun or Jool? That's the only way I'm aware of that can happen. Oh well, I think I can put in a workaround, but would be nice to know why it's happening.... EDIT: Or it could happen if it couldn't find the celestial body by name. Perhaps you had a planet pack installed and then removed it? That seems like a long shot... - - - Updated - - - Not sure if this will fix the issue, but let's give it a go. Spheniscine - make sure to double check the logs as one case may have a warning. Download here. Waypoint Manager 2.1.3 - Fixes for possible NullReferenceException (thanks Spheniscine).

Great post - have some rep! I'm surprised no one has responded yet. At the risk of repeating myself... Contract Configurator supports a lot of these options (not all, and some not fully) - if you're interested in trying to mod these yourself, then you should check it out. Oh and this: Ahem.

And for reference, the requirements on those two contracts are: Island Airfield - Complete First Launch Pyramids - Reach Orbit I had been thinking about having flight/jet tech as a requirement - but I wanted them to be early missions. I also tried to stay away from making one contract dependent on another - as some players may not want to do some of them. The exception being the monolith contracts which has a small bit of a story element to it.

Funny, since Voidheart has been working on a Better Parts Testing contract pack. It doesn't look like there's been much activity on it in the past 3 weeks, but you should give him that feedback of "complaints" about the stock stuff.

Although not completely out of the question a contract "builder" would be a fair bit of work, that would need: Logic for saving parameters/requirements/behaviours to config nodes (right now they can only be read). GUI for each parameter/requirement/behaviour (or some sort of framework). Which may not seem like much, but that's quite a bit. The problem is that it doesn't take away the hardest parts of building contracts, like understanding the parameters and how to best fit them together. It also doesn't give me personally much benefit, as I'd probably still want to do it via files. Anyway, if you do want to get into it the wiki is the first place to start. If you have questions, I'm always happy to help, just post on either the contract pack dev thread or main contract configurator thread.

Usually means an exception occurred. Can you provide log files?

Next version of Contract Configurator is going to support a lot of this - specifically planned are: Being able to randomly select a station/vessel as a contract objective (that meets certain criteria) ... actually, that's it. There's lots more planned, but everything else you mentioned above is already supported, specifically: Using a specific vessel from a previous contract as part of a new contract. Docking a vessel that meets specific criteria to another vessel (ie. a vessel with the new components) Having specific kerbals at a specific spot (on the station/on Kerbin) There's also a contract pack planned that will use many of these features.... look for all this in the next 2-3 weeks.

Does wildcarding on the name and using a tag together work? I have the following configuration: { name = AS_TestA // Indicates a contract where SCANsat multipliers should be applied tag = SCANsat rewardFunds = 1000.0 } CONTRACT_TYPE { name = AS_TestB rewardFunds = 1000.0 } @CONTRACT_TYPE[AS_*,SCANsat]:NEEDS[SCANsat],* { // Increase the rewards of all contracts with extra SCANsat requirements @rewardFunds *= 2.00 } CONTRACT_TYPE With the following result: { name = AS_TestA type = CONTRACT_TYPE parentUrl = ContractPacks/AnomalySurveyor/AS_TEST url = ContractPacks/AnomalySurveyor/AS_TEST/AS_TestA CONTRACT_TYPE { name = AS_TestA tag = SCANsat rewardFunds = 2000 } } UrlConfig { name = AS_TestB type = CONTRACT_TYPE parentUrl = ContractPacks/AnomalySurveyor/AS_TEST url = ContractPacks/AnomalySurveyor/AS_TEST/AS_TestB CONTRACT_TYPE { name = AS_TestB rewardFunds = 2000 } } UrlConfig What I was expecting was that only "AS_TestB" would get the multiplier applied - but it ended up happening for both A and B. Bug, or am I misusing it? EDIT: Note tried this more explicit form, and THAT works as expected (only applying the multiplier to nodes with the SCANsat tag): @CONTRACT_TYPE[AS_*]:HAS[#tag[SCANsat]],NEEDS[SCANsat],*

Hmmm, that's odd - I just tried it and had no problems. Perhaps something crashed and brought down the contract system? Can you provide logs? If you go to the space centre and come back does it work? Same thing if you exit the game and go back?

I see, makes sense. It sounds however like what you really want is the makers of RPM to support waypoints for those items - they'd have far more luck changing that stuff than I would. They are of course, welcome to check out my implementation (if it's helpful to them). Note also that the waypoints on the non-IVA navball is stock (not Waypoint Manager).

Whoops, missed this response. Yup, I'd pretty much come to the conclusion now too that KerbinSide is the problem. The second one being bugged could be working "correctly". Have you escaped the atmosphere with another craft already? If so, it completing immediately would be normal. If my assumption is correct, the best bet would be for Yemo to change the contract to not get offered if the player has already escaped the atmosphere. That would mess up how he handles contract progression, but I think it's probably fixable. Anyway, I'd raise that one in the SETI thread and maybe reference my response above (I know, you've been bounced around all day).

This is probably the biggest problem that I see, and it cascades to at least one of the Contract Configurator problems (which is the fact that the CC persistent data storage scenario isn't loaded). ScenarioUpgradeable is a stock thing - but it certainly *could* be KerbinSide causing that.

Im also getting this. at ScenarioUpgradeableFacilities.getInitialState (.ConfigNode node) [0x00000] in <filename unknown>:0 at ScenarioUpgradeableFacilities.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0 at ScenarioModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0 at ScenarioRunner.AddModule (.ConfigNode node) [0x00000] in <filename unknown>:0 at ProtoScenarioModule.Load (.ScenarioRunner host) [0x00000] in <filename unknown>:0 at ScenarioRunner+ .MoveNext () [0x00000] in <filename unknown>:0 ullReferenceException: Object reference not set to an instance of an object Which im not so sure is relavent, but it comes up a lot. The highlighted part " ScenarioUpgradeableFacilities" is what concerns me. Im running the full package of KerbinSide. That NRE sounds like something relating to that. Ill post in the KS thread about it, but I figure maybe this could also lead to the issues im having with CC contract objectives not completing. A domino effect perhaps.. And it turns out SETI was just updated to 8.0. Ill try it out and unless I have the same issues this troubleshoot is itself an NRE. Those certainly look suspicious. I'll take a look ASAP (which actually won't be until tonight - not much modding gets done on the weekend - kids).

Actually, I've been meaning to look into a way to have it render within the landscape - right now it'll draw on top of the altimeter and such (which is highly annoying).... maybe doing so might make it work with RPM without much other work... I'll have to see what I can do on that front.

No plans, but I can always be convinced. I only have a passing familiarity with RPM. Does it have stock camera views where you'd want to see the waypoints displayed, or were you thinking of something else?

New version up, get it here! ContractPack-AnomalySurveyor 1.0.2 Integrate performance changes from Contract Configurator 0.6.6. Fixed location of Rock Arch #2 on the Mun (thanks Sonny_Jim). Balance pass for contract rewards.

@Steven Madding - There's a new version of Contract Configurator out that will most likely fix your performance issues. If you're able to reproduce the other issue, please provide logs and I'll look into it.

New version out - some performance fixes that will be most noticeable on the RemoteTech contract pack. Download it here. Contract Configurator 0.6.6 Changed to MIT license. Performance fixes for stock contracts app (mainly affects contracts with lots and lots of parameters. Bundled MiniAVC (1.0.3). Minor bug fixes.