nightingale

Version 0.3.2 is out, with basic support for KSP 0.90. Download it now! Contract Configurator 0.3.2 - (0.90) Support for KSP 0.90 - (0.90) Fixed VesselHasVisited (note the valid values for situation changed) - Fixed a bug in the handling of VesselParameterGroup that would cause the countdown timer to reset when switching vessels. Time to play with 0.90 for a bit and get some of the new features integrated!

Hmmm.... still getting a ton of log spam errors using the new version in 0.90: [LOG 20:01:14.460] KerbalEngineer -> FlightEngineerCore->UpdateModules // Object reference not set to an instance of an object [LOG 20:01:14.461] KerbalEngineer -> at KerbalEngineer.Flight.Readouts.Orbital.ManoeuvreNode.ManoeuvreProcessor.Update () [0x00000] in <filename unknown>:0 at KerbalEngineer.Flight.FlightEngineerCore.UpdateModules () [0x00000] in <filename unknown>:0 [LOG 20:01:14.475] KerbalEngineer -> FlightEngineerCore->UpdateModules // Object reference not set to an instance of an object [LOG 20:01:14.476] KerbalEngineer -> at KerbalEngineer.Flight.Readouts.Orbital.ManoeuvreNode.ManoeuvreProcessor.Update () [0x00000] in <filename unknown>:0 at KerbalEngineer.Flight.FlightEngineerCore.UpdateModules () [0x00000] in <filename unknown>:0 ... etc.

THANK YOU!!! This is going to make my life so much easier in Contract Configurator!

Heh, for some reason I expected 0.90 to drop on a Tuesday. Contract Configurator failed the smoke test - there's issues that need to be fixed to make it run under 0.90, but most things seem good at a glance. Should have the 0.90 compatible version out soon enough (tonight, perhaps).

From the wiki page for the CONTRACT_TYPE node: I'm going to be doing some wiki cleanup today, I think maybe I'll add some more around this, as what's there is woefully inadequate for anyone not familiar with the different values that can be passed in.

Version 0.3.0 is out, with still more new features! Download it now! Contract Configurator 0.3.0 - Support for ContractBehaviour - extensible behaviours at the contract level. - Support for a persistent data store. - Support for disabling other contract types - Support for contract level notes. - Support for using TextGen generated descriptions. - Added Timer parameter. - Added Expression requirement. - Added SpawnKerbal behaviour. - Added Expression behaviour. - Added cooldownDuration to CompleteContract requirement. - Added weight to CONTRACT_TYPE to support genering some contract types with higher/lower probability. - Increase the odds of a ContractConfigurator contract being generated (versus a stock or traditionally defined contract) based on the number of configured contracts. - VesselParameterGroup now works with deeply nested children (previously would only work with direct children). - Various minor bug-fixes. Some focus on a few of the more interesting features: Disabling Stock Contracts You asked for it, you got it! You can now have full contractual control. Contract Behaviours Contract behaviours are the new system (the others being parameters and requirements). A behaviour is a contract-level hook that can be used to introduce logic on the contract. This can be used for things that aren't appropriate for a parameter (as a parameter forces the player to meet it) or is common across multiple parameters. Right now there is out of the box behaviours for spawning Kerbals, and another special one (that I'll get to in a moment). Persistent Data Store The persistent data store is of interest to anyone who is extending Contract Configurator. This gives an easy way to store data in the player's save file. Use this to track data across different contracts. Expression Behaviours and Requirements There is now an expression parser that uses the persistent data store. The behaviour side of the house gives the ability to store data (based on an expression) on certain contract events (accepted, failed, succeeded). The requirement side is used to make a contract only show up if the expression is true. For example, if I wanted to use it to keep track of something we'll call... "Anomaly Research" (@Space_Nomad, I hope you're listening ) we would have the following behaviour: BEHAVIOUR { name = AnomalyResearch type = Expression CONTRACT_COMPLETED_SUCCESS { AnomalyResearch = AnomalyResearch + 1 } } ... which could be matched with a requirement like this on another contract: REQUIREMENT { name = AnomalyResearch type = Expression expression = (AnomalyResearch >= 10) } There will be plenty more to come in the next release. The only question is... will it be 0.25 or 0.90? In the meantime, happy contracting!

Thanks! That's the exact kind of contract I want to see created from this! Are you willing to do a little coding? What you'd need is a ContractBehaviour (new thing, more on this when 0.3.0 drops in a few days) that increments the Anomaly Research points. You'd also need a ContractRequirement that makes a contract require a certain minimum/maximum of AR points. What I'd provide for sure is some functions/classes for a generic persistant data store - ie. pass a config node and I'll store it in the save file. It *may* get to the point where I've got enough generic stuff so you could do all this without coding anything yourself. However, I think you'd want a way to display to the players how much AR they've accumulated, and *that* would definitely be outside the scope of Contract Configurator. That's cool, I think I can add something for this. Right now you can require another contract to be complete (see the CompleteContract requirement), but there's nothing for the date piece. GitHub issue created. Very similar to above, I think once I get that one working you'd be able to do this as well.

A little preview of the next release. Did someone order some Kerbals rescued?

I have no idea how I missed that. Thank you!

Okay, I feel like this one should be easier than I'm making it, so going to the forums for some hopefully quick help. I'm trying to load/create an Orbit object from an ORBIT config node such as this one: ORBIT{ SMA = 1449999.99996286 ECC = 1.07570816555399E-05 INC = 0 LPE = 270.690311604893 LAN = 1.93635924563296 MNA = 1.55872660382504 EPH = 31.3999999999994 REF = 1 } This is the code that I've tried: public static Orbit ParseOrbit(ConfigNode configNode, CelestialBody body) { double inc = Convert.ToDouble(configNode.GetValue("INC")); double e = Convert.ToDouble(configNode.GetValue("ECC")); double sma = Convert.ToDouble(configNode.GetValue("SMA")); double lan = Convert.ToDouble(configNode.GetValue("LAN")); double w = Convert.ToDouble(configNode.GetValue("MNA")); double mEp = Convert.ToDouble(configNode.GetValue("LPE")); double t = Convert.ToDouble(configNode.GetValue("EPH")); return new Orbit(inc, e, sma, lan, w, mEp, t, body); } Now, the first 4 parameters are obvious (or at least, I think they are). Based purely on the parameter counts, I'm working on the wild guess that the last 3 just need to be in the right order (vs. representing different things and needing some conversion to get into the right form). Anyway, the code isn't working - when I instantiate a vessel with this orbit I get the "orbit is NaN" error in the logs (and just FYI, the orbit is an 850KM circular equatorial orbit). Anyway, my questions: Am I just getting the mapping/ordering on the last 3 parameters wrong? If not, how do I convert MNA/LPE/EPH to w/mEp/t. And what are w/mEp/t? I figured out the others from this page on the wiki. Is there a super obvious public class/method in the squad code base that I'm missing. I looked really hard for Orbit.Load() or something that would've made my life easy. Thanks for the help!

@MenuOption I sent you a PM about some possible ideas for Kerbal Adventure going forward... let me know what you think!

I obviously can't speak for Marclev, but these are both in the roadmap for ContractConfigurator. Which of course only give the ability for a modder to add orbiting/surface kerbals/vessels. So to see it in game you'll have to wait for me to make a player mod using ContractConfigurator (or for someone like Marclev to do it using ContractConfigurator).

Definitely interested, that's the type of thing I was hoping to see for ContractConfigurator. I sent you a PM.

A straight up multiplier is not currently possible. When I get a chance I'll consider looking at variable rewards/penalties based on a number of factors - but I'd like to have a fairly generic system for that. I do have a solution for you - but it's not as clean as you might like. Have an Any wrapping 3 parameters each with different rewards and different numbers of Kerbals. Something like this: name = Any1 type = Any PARAMETER { name = Mun1Kerbal type = VesselParameterGroup title = Land on the Mun with 1 Kerbal rewardScience = 100.0 PARAMETER { name = ReachSituation1 type = ReachSituation disableOnStateChange = false situation = LANDED } PARAMETER { name = ReachDestination1 type = ReachDestination disableOnStateChange = false targetBody = Mun } PARAMETER { name = HasCrew1 type = HasCrew minCrew = 1 maxCrew = 1 disableOnStateChange = false } } PARAMETER { name = Mun2Kerbal type = VesselParameterGroup title = Land on the Mun with 2 Kerbals rewardScience = 200.0 PARAMETER { name = ReachSituation1 type = ReachSituation disableOnStateChange = false situation = LANDED } PARAMETER { name = ReachDestination1 type = ReachDestination disableOnStateChange = false targetBody = Mun } PARAMETER { name = HasCrew1 type = HasCrew minCrew = 2 maxCrew = 2 disableOnStateChange = false } } PARAMETER { name = Mun3Kerbal type = VesselParameterGroup title = Land on the Mun with 3 or more Kerbals rewardScience = 300.0 PARAMETER { name = ReachSituation1 type = ReachSituation disableOnStateChange = false situation = LANDED } PARAMETER { name = ReachDestination1 type = ReachDestination disableOnStateChange = false targetBody = Mun } PARAMETER { name = HasCrew1 type = HasCrew minCrew = 3 disableOnStateChange = false } } }PARAMETER{ I include no version of ModuleManager! You had me worried for a second, so I had to double check the .zip, and there was definitely no ModuleManager in there.

Okay, finally had a look at this, and the pre-release ContractConfigurator now supports TextGen. Once I update the first post in my release I'll add a list of recommended mods, because wow this is so much better than stock. Now that I understand Coherent Contracts a bit better, I really don't have much in the way of requested updates. Once I or others start building mods using ContractConfigurator, that's when I'll know where things need to be added. If I ever get to that point, I'll likely start throwing strings your way.

Okay, once I took a closer look it's really easy: Instead of: CONTRACT_TYPE { ... } Do this: CONTRACT_TYPE:NEEDS[!MechJeb2&!HyperEdit] { ... } And you're all set. Now, this will silently remove the contract. If you'd prefer to inform users, you can use separate ModuleManager patch node to add an impossible parameter: @CONTRACT_TYPE[SimpleTestContract]:Needs[HyperEdit|MechJeb2] { PARAMETER { name = MillionKerbals type = HasCrew minCrew = 1000000 title = Kerbal Space Academy is a contest, please do not use HyperEdit or MechJeb! } }

Depends. Because everything is in a config file, you should just be able to use ModuleManager syntax. I did a quick test, and wasn't able to get it it to delete a CONTRACT_TYPE node using a NEEDS[] block. But I could've been just using it wrong. I'll play around with this and let you know. If it isn't possible using ModuleManager syntax, I'll add an enabled flag on the config node, because then you'll be able to use ModuleManager to disable the CONTRACT_TYPE. Yup! Although there isn't anything specific I need at the moment - one of the next things I'll be looking at is the description generation stuff - that's when I'll know if there's anything I need/want in CoherentContracts. I'll let you know soon - but even then it'll probably be stuff than can wait until 0.90.

Alright everyone, version 0.2.0 is out, with a ton of new features: - Added VesselParameterGroup parameter (supports grouping Vessel parameters, tracking duration, tracking non-active vessels, works across docking/undocking/decoupling).- Created new versions of all the stock parameters dealing with Vessels to add support for tracking non-active vessels. - Added HasCrew parameter. - Added HasResource parameter - Added HasPart parameter. - Added HasPartModule parameter. - Added PartModuleUnlocked requirement. - Added VesselHasVisited parameter. - Added ReturnHome parameter. - Added Sequence and SequenceNode parameters. - Various minor bug-fixes Oh, and one bonus feature... for a mod that is intended for use other modders, documentation is key! So I've dumped the second post of spoiler-tagged silliness and replaced it with a much more user friendly GitHub wiki. Enjoy! A few of the new features could use some additional explanations, here's some details on a few of the more interesting ones: VesselParameterGroup This one is special, so it needs a little explanation. On my first attempt to implement a duration parameter, I realized a few things that the other big contract modders were already aware of: The stock parameters only work for the active vessel Tracking parameters across non-active vessels is hard! Docking/undocking/decoupling makes it worse!! The VesselParameterGroup parameter was my solution to these problems. It provides tracking across different vessels, tracking of vessels across docking actions as well as containing the duration piece that started it. The state of the child parameters will display the state for the active vessel, *unless* the parameters are all complete for a non-active vessel. In that case, the notes field will display the name of the vessel that is meeting the conditions, as well as a countdown timer with how much longer to go before that vessel meets the duration portion of the requirement. Docking is another one I wanted to spend some time on to get right for some different scenarios. For example, let's say the contract you are providing is "Land on Eve and return home". Let's say the player builds a ship composed of a command module and a lander. He lands on Eve with the lander, returns to orbit and docks with the command module, then abandons the lander and goes home to Kerbin. Has he met the contract? I would say yes - but technically speaking the ship that landed on Eve never returned home. I deal with this technicality by allowing a docking craft to automatically "transfer" its parameter state to a craft it is docking to. Note that this transfer can only happen between a craft that accomplished the parameter (ie. landed on Eve) and another craft. In our example, if the command module docks with a brand new craft, the new craft is not treated as having met the parameter. HasResource HasResource supports... resources. Kethane! Karbonite!! Karborundum!!! Make your players go and get them! Or give them resource limitations - launch a vessel with a maximum fuel quantity. HasPart and HasPartModule HasPart and HasPartModule introduces the most basic level of support for building contracts for other mods. Require that a ship has ModuleRTAntenna for a basic RemoteTech contract. Require that an OKS base has all the various parts required for a functioning base. Note that lots of features that have been requested in this thread didn't make it into this release - but they haven't been forgotten! See the GitHub tracker if you want to know what's coming up!

It's funny, because I always saw it as the other way around - for ContractConfigurator I'll be looking at mods like Mission Controller 2 for inspiration for new parameters (or integrate directly with those mods if it makes sense). One day in the future you should be able to hypothetically make something with the scope of Mission Controller 2 using ContractConfigurator - but that wont' be the case until I hit the breadth of parameters that I'm looking for.

Took a quick peek, and it seems like there's potential, I see that there's been a lot of work put into this (you just need to sell it to us!). However, you're currently in violation of SQUAD's policies (see sticked thread), specifically: You'll need to provide the source for KerbalAdventure.dll ASAP - the mods take that requirement pretty seriously. (Or take down the thread, but I don't think anyone wants to see that.)

Or perhaps filtering/filtering-out by contract type - ContractConfigurator gives the ability to create all kinds of contracts where the modder will have likely tuned the science results to something they feel is appropriate.

Oh, and a sneak preview of what's upcoming for the next release. Jeb has just a few days to go to fulfil his contract.

As Sandworm mentioned, this specific parameter isn't feasible. However, I do plan on adding parameters to supports Remote Tech in the near future. I haven't looked closely yet to say exactly what they will be, but some example contracts/parameters that I would like to eventually support would be things like: Create a Kerbal relay network with a minimum range of 'x' Provide connection between KSC and <place> Also planned. Right now Fine Print has a least the starting point for this, which is basically "have amount X of resource on ship". So I'm tentatively waiting to see what that looks like in 0.90 stock before I make the decision on how to handle it (write my own parameter, use stock, somewhere in between). Agreed. The next release will have something very close to what Sandworm just described... Agree completely - just missing a few Parameters to make this feasible. I expect in the near future this will be fully supported. Yes and no. For the RemoteTech example, I would have a separate .dll that is dependent on RemoteTech which has all the parameters that use RemoteTech logic. For someone not using RemoteTech, those parameters would simply be unavailable. It would be up to the mod introducing the ContractConfigurator contracts to specify that RemoteTech is a required dependency (or possibly use ModuleManager syntax on the ContractConfigurator .cfg file(s) to only make the RemoteTech contracts only appear if RemoteTech is installed). For something like Karbonite/Kethane there's probably no hooks required - it'll just look at resources. For OKS/MKS... maybe? Most likely it'll just be something that can require a station/vessel with parts that have certain part modules, which is a soft-dependency.

No specific requests until I do some more digging and playing around. But even so, there's a LOT there right so don't forsee needing anything more unless I start exposing the ability to specify some of the parameters used (right now the only thing that can be specified in ContractConfigurator that would affect these is the agency). It'll probably be a while before I can do a real deep dive into this stuff (it's not as high on the priority list), so I may not have anything until the new year. In the short term though, I will make the description optional to allow using the auto-generated stuff, at which point I'll put Coherent Contracts as a recommend mod on ContractConfigurator.

Thanks for the offer. Let me take a look at what you've done first - it may be sufficient to just have Coherent Contracts as is as a suggested companion mod for ContractConfigurator.