[1.10.1+] Contract Configurator [v1.30.5] [2020-10-05]

[nightingale]

I'd love to see parameters for Orbital Period, Eccentricity, Inclination, and other orbital parameters (Arg. of Periapsis, Long. of AN, AP Height, PE Height, or just Semi-Major and Semi-Minor Axes). It'd be really cool if there were some pre-defined orbits as well using the celestial body's parameters (so it'd work with RSS and 6.4x kerbin). "Tundra" orbits, Polar orbits, Keostationary, Keosynchronus, etc etc...

Maybe I'll play with the code and see what I can do...

Having a contract parameter where an orbit is defined is pure Fine Print territory - so this is definitely something where I'd to accomplish through integration, rather than creating my own parameter. Fine Print does this by defining waypoints though. But I think the most user friendly way would be as you've suggested - by letting the modder specify the orbital parameter, and having ContractConfigurer translate that into 3-4 Fine Print waypoints. I also really like the idea of being to use "shortcut" orbits that have fewer parameters to specify.

[DMagic]

Thanks for the help: the dictionary idea is promising. GetHashString() won't work: it keeps on changing when the scene changes. More testing is required, but I think Contract.ContractID is going to work better.

EDIT: Contract.ContractID does seem to be unique, and persistent between reloading the game. Now to figure out where to steal some code for keeping a dictionary persistent for a save game, probably from KAC.

You're looking for the unique contract identifier? Contract.ContractGUID is probably the best. It's what gets stored in the persistent file and isn't based any parameters or values of the contract.

GetHashString is based (I think) on the contract title, and parameter titles and I think some other things.

To make it persistent you would need to use a scenario module and just print out each GUID in a string whenever it saves. Deciding how those GUIDs are sorted and what to do with them is another matter.

Edit: Also, keeping track of orbital parameters for a certain duration is fairly straightforward, it's just the details that get in the way. What happens when you dock or undock? Saving and loading which vessel is being tracked, checking if there are any requirements for the vessel, etc... Orbital Science does this in what I think is a pretty sturdy way.

Edited December 1, 2014 by DMagic

[Starman4308]

You're looking for the unique contract identifier? Contract.ContractGUID is probably the best. It's what gets stored in the persistent file and isn't based any parameters or values of the contract.

GetHashString is based (I think) on the contract title, and parameter titles and I think some other things.

To make it persistent you would need to use a scenario module and just print out each GUID in a string whenever it saves. Deciding how those GUIDs are sorted and what to do with them is another matter.

Huh. The ContractID, from the limited test I ran, was persistent through closing and re-opening KSP, though if ContractGUID works for you, I'll probably just use that. To avoid clogging up other peoples' threads any further, I've established a dedicated thread in the development subforum. I really wanted to have at least a demonstrator finished by then, but the problems are mounting.

[DMagic]

Huh. The ContractID, from the limited test I ran, was persistent through closing and re-opening KSP, though if ContractGUID works for you, I'll probably just use that. To avoid clogging up other peoples' threads any further, I've established a dedicated thread in the development subforum. I really wanted to have at least a demonstrator finished by then, but the problems are mounting.

I had it a little backwards, the ContractID is determined in part by GetHashString(). ContractGUID is just a GUID, a value that has next to 0 chance of ever being repeated, so that's the safest one to use for uniquely identifying a contract.

[nightingale]

Also, keeping track of orbital parameters for a certain duration is fairly straightforward, it's just the details that get in the way. What happens when you dock or undock? Saving and loading which vessel is being tracked, checking if there are any requirements for the vessel, etc... Orbital Science does this in what I think is a pretty sturdy way.

Yup, after looking into it I realized it's more complicated than what the current stock parameters currently support. If you want to do something where the vessel will be active over the entire duration (eg. fly at a certain altitude for a given duration) it works fine. If it's anything where the player is likely to change the active vessel (eg. orbit the Mun for 10 days), the stock parameters will revert to incomplete as soon as we "look away".

Docking is another wrench, but I think I've got a handle on it now that you've shown me how Orbital Science handles it.

In the end, I think I need a way of specifying and tracking the "target object" of the contract, so we can do things like this:

Any vessel:
    10 days:
        Destination: Kerbin
        Situation: Orbit
        Crew Count: At least 1

Jebediah Kerman:
    1 year:
        Destination: Not Kerbin

The first one would require potentially looking at different vessels (like Orbital Science does) and checking off the requirement when the first one hits 10 days. The second could involve Jeb going ship to ship or planet to planet.

As an aside, once I get through this current crop of enhancements I'll also be taking a much closer look at Orbital Science (and Mission Controller 2, also) to see if I can make them into either optional dependencies or if there's any inspiration for new parameters.

[johnsonwax]

I'd like to see a way to add contracts of the following sorts:

* Establish a continuous connection from Jool to KSC for 1 month [RemoteTech]

* Deliver x amount of Kerbonite or Kethane to orbital station y [resource mods]

* Exchange the crew of orbital station y

* Build a self-sustaining orbiting station (keep food, water, oxygen above 90% capacity for 1 month) [OKS/MKS, TAC]

Would these require hooks from the mods themselves to support? Would we need some kind of indicator on an orbital or ground station - e.g. a part that says 'this is a permanent station that should be a target of contracts'?

Looking for some way to shim in logistical simulations now that we can do fairly interesting things. It's cool that we can lasso a class E asteroid and mine it, but in a career game that's largely a volunteer effort, where a resource contract might justify the effort.

[Sandworm]

I'd like to see a way to add contracts of the following sorts:

* Establish a continuous connection from Jool to KSC for 1 month [RemoteTech]

Cannot happen. Under warp RT drops connections readily. You would need a mechanism to accommodate these drops, but then there isn't much point in the continuousness requirement.

* Deliver x amount of Kerbonite or Kethane to orbital station y [resource mods]

Perfectly doable. Was done using contract manager. Whether the resource is stock or mod-added doesn't matter.

* Exchange the crew of orbital station y

Very tricky. The contract would have to keep track of which kerbals are where before, after and during the moves. But you could build something similar using smaller requirements such as "in orbit with 3 kerbal" then "in orbit with 6", which you would have to pick up somewhere. Add specific orbit reqs based on a previous to launch a station and you're done. This too was once possible using missioncontroller.

* Build a self-sustaining orbiting station (keep food, water, oxygen above 90% capacity for 1 month) [OKS/MKS, TAC]

This can be done with basic resource and duration requirements. Launch with <=1000 units, stay a month, and still have >=900 units.

[nightingale]

I'd like to see a way to add contracts of the following sorts:

* Establish a continuous connection from Jool to KSC for 1 month [RemoteTech]

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>
  

* Deliver x amount of Kerbonite or Kethane to orbital station y [resource mods]

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).

* Exchange the crew of orbital station y

Very tricky. The contract would have to keep track of which kerbals are where before, after and during the moves. But you could build something similar using smaller requirements such as "in orbit with 3 kerbal" then "in orbit with 6", which you would have to pick up somewhere. Add specific orbit reqs based on a previous to launch a station and you're done. This too was once possible using missioncontroller.

Agreed. The next release will have something very close to what Sandworm just described...

* Build a self-sustaining orbiting station (keep food, water, oxygen above 90% capacity for 1 month) [OKS/MKS, TAC]

This can be done with basic resource and duration requirements. Launch with <=1000 units, stay a month, and still have >=900 units.

Agree completely - just missing a few Parameters to make this feasible. I expect in the near future this will be fully supported.

Would these require hooks from the mods themselves to support? Would we need some kind of indicator on an orbital or ground station - e.g. a part that says 'this is a permanent station that should be a target of contracts'?

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.

Edited December 4, 2014 by nightingale

[nightingale]

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.

[Apollo13]

...Jeb has just a few days to go to fulfill his contract.

Uh...Jeb ain't comin' home. No engine/tank. No RCS/monoprop. No parachutes. Next contract...Rescue Jeb. LOL

And, great mod here, my friend. You just made contract modders' lives so much easier. Forum Rep point to you times eleventy-eleventy.

Now that Squad is incorporating mods into stock, Felipe needs to contact you and make this stock.

Edited December 4, 2014 by Apollo13

[Sandworm]

Now that Squad is incorporating mods into stock, Felipe needs to contact you and make this stock.

I don't think this mod can mesh with Squad's philosophy regarding missions. The opted not to enable defined or goal-specific missions in favor of procedural generation. Duration requirements also reminds everyone of the absurdity of a space 'simulation' without any mention of life support.

[Borisbee]

I don't think this mod can mesh with Squad's philosophy regarding missions. The opted not to enable defined or goal-specific missions in favor of procedural generation. Duration requirements also reminds everyone of the absurdity of a space 'simulation' without any mention of life support.

And that's why I love where this is heading. I can't wait for some community contract packs to start appearing, especially for mods like RemoteTech or KerbinSide.

[nightingale]

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:

1. The stock parameters only work for the active vessel
   
2. Tracking parameters across non-active vessels is hard!
   
3. 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!

Edited December 8, 2014 by nightingale
added download link

[scerion]

Uh...Jeb ain't comin' home. No engine/tank. No RCS/monoprop. No parachutes. Next contract...Rescue Jeb. LOL

Jeb can totally come home! Just EVA and push!

[scerion]

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:

1. The stock parameters only work for the active vessel
   
2. Tracking parameters across non-active vessels is hard!
   
3. 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!

This is coming along awesomely

Question: Would it be possible to detect a plugin installed? Thinking could use to create a contract for completing certain things but wanted to ensure MechJeb or HyperEdit isn't used.

[DuoDex]

This is coming along awesomely

Question: Would it be possible to detect a plugin installed? Thinking could use to create a contract for completing certain things but wanted to ensure MechJeb or HyperEdit isn't used.

Detecting whether other plugins are installed is a hot topic on the forums I believe. Seems like some folks don't like it for privacy reasons. Just a heads up before we get a flamewar started.

Also, I think that the whole point of HyperEdit/MechJeb is to allow things that are "too hard" to be circumvented, using more or less cheaty ways.

And, @nightingale-do you still want me to keep on looking at support for this?

[scerion]

Detecting whether other plugins are installed is a hot topic on the forums I believe. Seems like some folks don't like it for privacy reasons. Just a heads up before we get a flamewar started.

Also, I think that the whole point of HyperEdit/MechJeb is to allow things that are "too hard" to be circumvented, using more or less cheaty ways.

Hmm I could see that.

And yeah this is a special circumstance kinda thing. Basically setting it up for Kerbal Space Academy. Just was looking for a way to ensure that people didn't use something to circumvent the rules of the event.

[nightingale]

This is coming along awesomely

Question: Would it be possible to detect a plugin installed? Thinking could use to create a contract for completing certain things but wanted to ensure MechJeb or HyperEdit isn't used.

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.

And, @nightingale-do you still want me to keep on looking at support for this?

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.

[nightingale]

Question: Would it be possible to detect a plugin installed? Thinking could use to create a contract for completing certain things but wanted to ensure MechJeb or HyperEdit isn't used.

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!
    }
}

[CaptRobau]

Would it be possible to have the rewards be multiplied by the number of Kerbals. So if you get 1 Kerbal to the Mun, it'll be worth less than if you manage to land 3.

Also noticed that the ModuleManager included is a few version behind the current one.

Edited December 9, 2014 by CaptRobau

[nightingale]

Would it be possible to have the rewards be multiplied by the number of Kerbals. So if you get 1 Kerbal to the Mun, it'll be worth less than if you manage to land 3.

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{

Also noticed that the ModuleManager included is a few version behind the current one.

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.

[AlphaAsh]

@nightingale

I've got contract support slated for Kerbal Konstructs but have been putting it off because I wasn't quite ready to start re-inventing FinePrint. Basically, I'm keen that KK can generate contracts around custom bases, such as 'transport x number of passengers (empty seats) from a to b' and/or 'get from a to b in under x number of minutes' and so on and so forth. KK is not paticularly well exposed for extension so I was wondering, any chance of a PM conversation about what needs to be done with KK and ContractConfigurator to get them talking? Assuming this interest you

[nightingale]

@nightingale

I've got contract support slated for Kerbal Konstructs but have been putting it off because I wasn't quite ready to start re-inventing FinePrint. Basically, I'm keen that KK can generate contracts around custom bases, such as 'transport x number of passengers (empty seats) from a to b' and/or 'get from a to b in under x number of minutes' and so on and so forth. KK is not paticularly well exposed for extension so I was wondering, any chance of a PM conversation about what needs to be done with KK and ContractConfigurator to get them talking? Assuming this interest you

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

[scerion]

Okay, once I took a closer look it's really easy: SNIP

Oh, wow. That's just amazing Thank you so much!

[nightingale]

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