nightingale

It's actually on my list in the very near future (probably next week) to put together some improved/example documentation for the VesselParameterGroup. ViM, but let's not turn this into an editor holy war... Yup, shouldn't be too bad to give something similar to that so that it can all go into one parameter. Raise a GitHub issue.

I think those obsolete error messages are the only ones that don't say what contract/parameter it is. I'll fix it.

Yup, that's classic "something failed and the entire contract system fell over" behaviour. I'll take a look. - - - Updated - - - Looks like StationScience is the problem, not Contract Configurator: [EXC 12:18:15.478] NullReferenceException: Object reference not set to an instance of an object ResearchAndDevelopment.partTechAvailable (.AvailablePart ap) ResearchAndDevelopment.PartTechAvailable (.AvailablePart ap) StationScience.Contracts.StnSciContract.AllUnlocked (System.String list) StationScience.Contracts.StnSciContract.GetUnlockedExperiments () StationScience.Contracts.StnSciContract.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 () You should post this info along with your logs on their thread.

Long term, the goal would be to support contracts like this, but it's not quite there yet. This will probably be one of the last things in your list to get supported, for now you'd have to be somewhat explicit about the vessel (although you can specify one from a previous "launch a station" contract). Supported Random length not yet supported, but definitely planned. Definitely support ability to focus on other ships during that time. Supported. Supported - standard contract funcationality.

I'll make a general thread on the Add-On Development board for Contract Packs and throw the link up here. Module manager is the answer here! I design the structure specifically for this kind of thing. Here's a random made up example: [COLOR=#333333][FONT=Consolas]PARAMETER[/FONT][/COLOR][COLOR=#333333][FONT=Consolas]:NEEDS[KarbPlus][/FONT][/COLOR][COLOR=#333333][FONT=Consolas] [/FONT][/COLOR]{ name = HasResource type = HasResource resource = Karborundum minQuantity = 100.0 [COLOR=#333333][FONT=Consolas]}[/FONT][/COLOR] In this example, it would add the parameter only if the player has Karbonite Plus installed. You can do that on any node, so CONTRACT_TYPE/PARAMETER/REQUIREMENT can all be controlled this way. - - - Updated - - - Here you go, General Contract Pack thread is up, have fun.

This is a thread for discussing contract packs for the Contract Configurator mod. Feel free to discuss ideas for new contract packs, ask for help on a contract pack, offer to help on a contract pack or suggest a new contract pack here. Current Contract Packs For a full list of contract packs, please see the first post of the main Contract Configurator thread. New Contract Packs Under Development The following is a non-comprehensive list of contract packs that are under development. Post a comment in this thread or PM me if you would like your upcoming contract pack added to this listing. [TABLE=class: grid, width: 0] [TR] [TD]Name[/TD] [TD]Description[/TD] [TD]Author[/TD] [TD]Links [/TD] [/TR] [TR] [TD]0.7.0 Release Contract Pack[/TD] [TD]Undecided[/TD] [TD]nightingale[/TD] [TD]none[/TD] [/TR] [TR] [TD]Better Parts Testing[/TD] [TD]Provide sensible parts testing contracts for the purpose of for assisting new players in understanding the 'correct' or expected way to use vessel parts and to encourage players to use parts they might not otherwise use regularly[/TD] [TD]voidheart[/TD] [TD]GitHub[/TD] [/TR] [TR] [TD]Vertical Propulsion Emporium Contracts[/TD] [TD]Contracts for Professor Phineas Kerbenstein's wonderous vertical propulsion emporium.[/TD] [TD]hakan[/TD] [TD]none[/TD] [/TR] [TR] [TD]Contract Configurator Demo Contracts[/TD] [TD]Examples of different Contract Configurator parameters in action.[/TD] [TD]DBT85[/TD] [TD]none[/TD] [/TR] [/TABLE] Contract Pack Ideas These are ideas that nobody is working on that could potentially become a future contract pack. [TABLE=class: grid, width: 0] [TR] [TD]Name[/TD] [TD]Description[/TD] [/TR] [TR] [TD]USI/Karbonite/MKS/OKS[/TD] [TD]There are *tons* of opportunities for contracts in this space.[/TD] [/TR] [TR] [TD]Resupply Contracts [/TD] [TD]Resupply orbital/landed bases with resources/Kerbals. Could also incorporate base building into this?[/TD] [/TR] [/TABLE]

Okay, starting with this. I changed the second post to have a listing of rules and recommendations for contract packs. Not all of it is due to the current situation, but some stuff that I had wanted to get out there for a little while (and this gives me the excuse to go and do it). If the contract pack modifies, enhances or uses another mod, be respectful of the licenses of those mods. If the maintainer of a mod used by a contract pack requests that a contract pack be removed or modified, please work with them to make the Contract Pack comply with their wishes and vision for their mod. Remember that the contract pack wouldn't be possible without the original author's mod. I, nightingale, have the final say on what is listed. I do not generally want to be the one telling people what they can and cannot do, so I will list most contract packs so long as the comply with the above two rules. Recommendations for Contract Packs Have your contract pack install into a subdirectory under GameData/ContractPacks/. Contract Configurator does not require this directory structure, but this keeps it cleaner for the end user. If adding your contract pack on CKAN, a name of the form "Contract Pack: <name of contract pack>" is recommended. This keeps the listings of all contract packs together, and allows the player to easily compare and decide which contract packs they are interested in. Try to be original. If your contract pack has significant overlap with an existing contract pack, consider contacting the author and working with them to enhance the contract pack. Be creative! The possibilities for contract packs are endless. As far as the current situation goes, I will be listing DBT85's pack on the first post, as it complies with the rules above (oh, but make sure you go back and mention the license on your post). However, I would strongly recommend that you and tattagreis talk and figure out a mutual resolution where we end up with one SCANsat contract pack. I don't want to the hard work that either of you have done go to waste, but I'd like to also get it to a point where it's best for the players. If for whatever reason we continue to have the two packs, then can we do something to differentiate them on CKAN? I don't have a specific recommendation, but if we end up going down this route I'm happy to give more thoughts on what can be done. I wouldn't quite say ready to go yet. I've put a proposed change forward for DMagic to review. Hopefully the change works as expected and gets accepted. If it does, then we shouldn't have any more issues in SCANsat 9.0 related to the contract parameters completing unexpectedly. And yes, the disableOnStateChange = false would give you a partial workaround - but only if it's not the last parameter to complete in the contract.

Would you be able to reproduce this again, and then send me your output_log.txt? Basically, the stock contract system has a tendency to go haywire and do stuff like what you've described when there's a failure anywhere in a contract/parameter. I'm slowly finding all the points where I can simply catch and report failures to prevent them from bugging out the contract system. In short, if you can get me log files there'll be two fixes - one to prevent the contract system from getting messed in this scenario and one to fix whatever the root cause is.

I have pretty much no time right now, so I can't address some of the specific points brought up until later - but I wanted to get some general thoughts. First off, congrats on the release, DBT85! I missed your post last night. I believe you need to specify the license on the forum post to satisfy the forum rules (although I see that it is there in the download, so you're 99% of the way there). Second, I have no direct issue with having multiple similar contract packs. However, I would like be able to make them differentiatable to the users. Both in terms of CKAN naming and in terms of a general description it would be nice to be able to have enough information to tells a user what they'll get if they install one, the other or both.

Neat idea. I've just completed the SpawnVessel behaviour (will be released in 0.6.0) which could be used, but I'd suggest sticking with waypoints for a starting point - much lighter weight... 100 one-part vessels might already be getting up there. In fact when you move away from waypoints, I'd be included still keep the same logic as in-flight waypoints - rendering a single image for the coin, rather than a 3d model. Gives it more of a platformer feel. No idea what your c# skill level is, but one of the design goals for Contract Configurator was to be fully extensible. So once you have your proof of concept working and you want to generate "coins" instead of waypoints, you can swap out the GenerateWaypoint behaviour for one that you've written yourself and Contract Configurator will load it and expose it for you. That way you can add something that would never make sense as part of Contract Configurator itself (ie. generating coins). The other thing is, I don't know how well the waypoint stuff works when you start getting to ultra low values for the distance tolerance - you might be okay, but you may find out that it doesn't behave well for small values (but I haven't personally tested).

Depends.... If you want 99 points randomly distributed around another point, then it's quite easy. 100 hand coded coordinates wouldn't be hard, just time consuming. I'll be looking at potential enhancements to the waypoint stuff in 0.6.0 - let me know if there's any behaviour you want implemented. I was thinking I'd look at better handling for navigation (like automatically moving to the next point), as well as giving the option to make a waypoint disappear after completing it.

Very cool, that one shouldn't be a problem for Contract Configurator. Note that I haven't done any testing with mods that add new planets - but I don't see any major reason why it wouldn't work. If you run into any issues, ping me or post on my thread and I'll be happy to make whatever changes that are necessary to get it up and running with OPM.

Try this file. I'll potentially look at including built in RSS files in the next release.

The best way to get it into the SCANsat contract pack is to go to tattagreis's github page for it and submit a pull request. If you don't know how to do that (and don't want to learn), then you should PM him the files - I'm fairly certain he'd be willing to add it. And as far as the "copyright crap", tattagreis licensed it under the WTFPL - which basically says you're free to do what you want, so you've done nothing wrong here. Awesome, can't wait to see it!

Ah, thank you, can't believe I missed that in the documentation post! That hardly seems mod-breaking. I'd argue that if you only want to edit the blue one in your example, then you have enough information about the structure of config you're expecting that you really don't want to be using a deep search, or you can use a HAS[] block to filter out what you don't want. Regarding my initial suggestion, given that ,* is the operator for "apply to all nodes", then I would suggest ,** as the one that "applies to all nodes at any depth": CONTRACT_TYPE [*] { @PARAMETER[Orbit],** { @minPeA *= 6.4 } }

Got a new one for you guys. I have the following MM config: @CONTRACT_TYPE [*] { @PARAMETER [*] { @PARAMETER[Orbit] { @minPeA *= 6.4 } } } Acting on the following config node data, gives the following results: [TABLE=width: 0] [TR] [TD]Before[/TD] [TD]After[/TD] [/TR] [TR] [TD] CONTRACT_TYPE:NEEDS[RemoteTech] { name = MM_TEST PARAMETER { name = CommSat1 PARAMETER { name = Orbit minPeA = [COLOR=#ff0000]600000[/COLOR] } } PARAMETER { name = CommSat2 PARAMETER { name = Orbit minPeA = [COLOR=#ff0000]600000[/COLOR] } } }[/TD] [TD] CONTRACT_TYPE { name = MM_TEST PARAMETER { name = CommSat1 PARAMETER { name = Orbit minPeA = [COLOR=#ff0000]3840000[/COLOR] } } PARAMETER { name = CommSat2 PARAMETER { name = Orbit minPeA = [COLOR=#ff0000]600000[/COLOR] } } }[/TD] [/TR] [/TABLE] I was expecting it to modify both the CommSat1 and CommSat2 nodes, but CommSat2 remained untouched. Is this a bug? If you want to see the full configurations (significantly bigger, I reduced it down to the bare minimum to show the problem): Module Manager Config Config File Also, the Orbit Parameter node could hypothetically be directly under CONTRACT_TYPE, under one PARAMETER parent, under two, etc.... How much effort would be involved in getting some new form of "search" that'll traverse recursively down into children looking for the given node? In other words, instead of the above config, I would've liked to have written something like this: @CONTRACT_TYPE [*] { @PARAMETER[Orbit]:TRAVERSE { @minPeA *= 6.4 } } Which would match CONTRACT_TYPE/PARAMETER[Orbit], CONTRACT_TYPE/PARAMETER/PARAMETER[Orbit], CONTRACT_TYPE/foo/PARAMETER[Orbit]. (I couldn't think of a better name than "TRAVERSE", but you get the idea).

The first mission is a bit of an outlier. It has way more strict parameters than the other ones. The others simply say "provide coverage of X", whereas this one acts almost as a tutorial. I'll see if I can potentially rework it to be a little bit looser while still serving to help guide RemoteTech newbies. Huh, no reason I can think of that it would happen that way, I guess ModuleManager stopped after the first match? I'll have to look into this one.

Interesting, let me know how that goes - if it's an issue in SCANsat I'd like get something out to DMagic sooner rather than later, since I know he's in the midst of getting SCANsat 9.0 ready for prime time. But what you've said so far has been helpful.

This is spot on. As far as them showing up early, it's very surprising, and it's not anything that I've heard of happening before. Let me know if you can reproduce this, and which contract(s) show up. I'll have to take a look. You say you have it on video, can you post that up?

I'll see if I can change it to make it less sensitive to RemoteTech "jitter" from satellite switching.... but it may be that on high time warp you're just going to get issues like this, sadly. Good that it's working for you though!

Nope, I can't explain this, tested and it works perfectly for me. Can you: Confirm you're on the latest Contract Configurator (0.5.5). Try waiting another day to see if the contract completes (it sounds like it's just not displaying the number of days). Tell me if you're using Earth time instead of Kerbin time? I just tested though - and seems fine for both. Confirm it's the same for both the stock contracts app and Contract Window +.

Awesome!! Planning on supporting WiFi? Ie. view cameras on the monitor for any craft within physics range?

Sounds like there was something about some particular waypoint that was causing the plugin to throw an exception( and effectively unload/not work). Although if this was the case I think you would've seen that in the logs as well as the AGX error... but maybe you missed it? Hard to say much more without a save file to work from. Well, if you do end up reproducing, let me know, I couldn't see anything obvious that would cause this type of issue.

You're using the Duration parameter correctly - it should just make that parameter successful when the time elapses. If that made the contract complete, then the implication is that your SCANsat parameter was already completed. There was a bug that tattagreis and I fixed a while back where SCANsat would report 100% scanned while it was still loading up. Our fix/workaround may not be working 100% from the sounds of it. Are you able to reproduce it, and confirm what the state of the SCANsat parameter is at various stages (ie. when does it go from grey to green)? I'll also raise an enhancement to make it look like the RemoteTech coverage parameter - which actually displays the current coverage % in the text.

Nothing that I've heard about. Was it during play that it happened? Did restarting KSP fix it (or even just going to the space center scene and back)? If it happens again, please provide the output_log.txt and I'll take a look.