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

[nightingale]

18 minutes ago, linuxgurugamer said:

That sounds like it's what I would need.  Would that be difficult?

Also, does it get a list of all the CONTRACT_GROUP nodes before it starts processing the contracts?

 

But if I'm the only one who has ever asked for this, then I suppose I can do a dummy dll, and let MM do the work for me.  Might make it easier for  you.

Yeah, definitely something that is better handled through ModuleManager

[linuxgurugamer]

2 minutes ago, nightingale said:

Yeah, definitely something that is better handled through ModuleManager

Ok, then let's go that route.

 

LGG

[linuxgurugamer]

I'm now able to tell if the UnmannedContracts has been loaded by using a dummy dll, and have MM working properly with it.

Now, I'm trying to determine if a specific contract has been fulfilled.

I can't find (yet) any way to reference a contract in a different contract pack.  So i was wondering if it was possible to reference a persistent data item which was stored by a different contract pack.  I'm not sure yet which way would be better for me, still working on the logic here.

Thanks

[nightingale]

19 minutes ago, linuxgurugamer said:

I'm now able to tell if the UnmannedContracts has been loaded by using a dummy dll, and have MM working properly with it.

Now, I'm trying to determine if a specific contract has been fulfilled.

I can't find (yet) any way to reference a contract in a different contract pack.  So i was wondering if it was possible to reference a persistent data item which was stored by a different contract pack.  I'm not sure yet which way would be better for me, still working on the logic here.

Thanks

Either should work regardless of the contract pack "boundary" - so you can just reference the contract by name in a CompleteContract requirement that is protected by a module manager NEEDS statement. 

[linuxgurugamer]

7 hours ago, nightingale said:

Either should work regardless of the contract pack "boundary" - so you can just reference the contract by name in a CompleteContract requirement that is protected by a module manager NEEDS statement. 

OK, thanks for confirming the CompleteContract is global and that the persistantdata is also global.  You may want to mention that in the Wiki

[Dunbaratu]

I've dug through the documentation and a few examples from existing contract packs but I'm still lost on this question:

How do I make a contract whose waypoints are indexed sub-points from a root point?  In the contracts API that means it looks like this:"myname alpha" is *actually* called just "myname" but with waypoint index = 0, and the one called "mayname beta" is *actually* called just "myname" but with waypoint index = 1, and so on.

But I don't quite get how ContractConfigurator wants me to express that.  Do I call the waypoints by the name "myname alpha", "myname beta" and so on, and ContractConfigurator will strip off the words "alpha", "beta" and so on when communicating them to the KSP API?  Or do I name them "myname" and give them an index number and the KSP API will add the terms "alpha", "beta", and so on itself (which is what it seems to do with the stock contracts.  The actual name of the waypoint is stored without the greek letter names, and it generates the greek letter names for display purposes only.

I'm trying to make some contracts for kOS contract packs.  The difference between these two approaches is important because in when a script asks kOS for the waypoint called "mypoint gamma", kOS assumes in order to find that waypoint from the API, it needs to strip off the word "gamma" and instead look for a waypoint called "mypoint" with index == 2, because that's how the stock contract waypoints work.

 

Edited January 6, 2016 by Steven Mading

[nightingale]

38 minutes ago, Steven Mading said:

I've dug through the documentation and a few examples from existing contract packs but I'm still lost on this question:

How do I make a contract whose waypoints are indexed sub-points from a root point?  In the contracts API that means it looks like this:"myname alpha" is *actually* called just "myname" but with waypoint index = 0, and the one called "mayname beta" is *actually* called just "myname" but with waypoint index = 1, and so on.

But I don't quite get how ContractConfigurator wants me to express that.  Do I call the waypoints by the name "myname alpha", "myname beta" and so on, and ContractConfigurator will strip off the words "alpha", "beta" and so on when communicating them to the KSP API?  Or do I name them "myname" and give them an index number and the KSP API will add the terms "alpha", "beta", and so on itself (which is what it seems to do with the stock contracts.  The actual name of the waypoint is stored without the greek letter names, and it generates the greek letter names for display purposes only.

I'm trying to make some contracts for kOS contract packs.  The difference between these two approaches is important because in when a script asks kOS for the waypoint called "mypoint gamma", kOS assumes in order to find that waypoint from the API, it needs to strip off the word "gamma" and instead look for a waypoint called "mypoint" with index == 2, because that's how the stock contract waypoints work.

I only did some basic testing (it's just enabling a flag in the stock system), but you should be able to do this by setting clustered=true.  That will cause the Alpha/Beta/Gamma stuff to get automatically appended.

[theonegalen]

@nightingale, is it possible to use CC to modify the stock "rescue a kerbal" contracts to make them spawn in a derelict vessel or restrict where they spawn to where one already has resources in the area? For example, lets say I have an active base on Laythe or an exploration vehicle transiting Jool en route to Eeloo, therefore the rescue contract could trigger anywhere in Jool orbit or among the Joolian moons, with a Kerbal stuck after her engines blew up but she has plenty of life support to await rescue, etc?

[nightingale]

20 minutes ago, theonegalen said:

@nightingale, is it possible to use CC to modify the stock "rescue a kerbal" contracts to make them spawn in a derelict vessel or restrict where they spawn to where one already has resources in the area? For example, lets say I have an active base on Laythe or an exploration vehicle transiting Jool en route to Eeloo, therefore the rescue contract could trigger anywhere in Jool orbit or among the Joolian moons, with a Kerbal stuck after her engines blew up but she has plenty of life support to await rescue, etc?

Not possible to modify the stock contracts.  But it would be possible to write a Contract Configurator equivalent that does what you're describing.

Actually, the rescue contracts are probably the stock contract that people have talked about creating contract packs to replace the most, but it has never happened (projects just never made it to completion).

[linuxgurugamer]

Is there any place I can see what the stock contracts do?  ie:  see what they do for the "rescue a kerbal" so that it can be replicated?  Almost sounds too easy, at least in the beginning

[nightingale]

9 minutes ago, linuxgurugamer said:

Is there any place I can see what the stock contracts do?  ie:  see what they do for the "rescue a kerbal" so that it can be replicated?  Almost sounds too easy, at least in the beginning

Observe them in the game.

Basically no - it's all C# code controlling the stock contracts.  You can also look at what's saved for them in the persistence file, that will give some hints.

[linuxgurugamer]

sounds like fun :-(

[Dunbaratu]

3 hours ago, nightingale said:

I only did some basic testing (it's just enabling a flag in the stock system), but you should be able to do this by setting clustered=true.  That will cause the Alpha/Beta/Gamma stuff to get automatically appended.

That's not enough to answer the question.  First of all, "clustered" is only given in the docs as an option for the basic kind of waypoint, not for WAYPOINT_NEAR or RANDOM_WAYPOINT_NEAR, secondly if I made a bunch of vanilla waypoints and then gave each of them a clustered=true, how do I pick which is alpha, which is beta, etc?  How do I make a cluster of RANDOM_WAYPOINT_NEAR's be in the same group as the first WAYPOINT they are assigned to be near to?  Is there a group name field to put them in?

Are the other sorts of waypoints, like RANDOM_WAYPOINT_NEAR meant to be derived classes of the basic WAYPOINT, such that all the fields of WAYPOINT are also available for RANDOM_WAYPOINT_NEAR?  If so then I'd know they have the ability to do clustered = true for them too.  If so, that wasn't something I noticed in the docs.

[nightingale]

12 minutes ago, Steven Mading said:

That's not enough to answer the question.  First of all, "clustered" is only given in the docs as an option for the basic kind of waypoint, not for WAYPOINT_NEAR or RANDOM_WAYPOINT_NEAR [...]

That's a documentation mistake - it should be valid for all of them.

12 minutes ago, Steven Mading said:

[...] secondly if I made a bunch of vanilla waypoints and then gave each of them a clustered=true, how do I pick which is alpha, which is beta, etc?  How do I make a cluster of RANDOM_WAYPOINT_NEAR's be in the same group as the first WAYPOINT they are assigned to be near to?  Is there a group name field to put them in?

Right now it's pretty simplistic - it starts counting from the first waypoint you generate in the behaviour .  If you want to create a second cluster group, you would need a second behaviour.

13 minutes ago, Steven Mading said:

Are the other sorts of waypoints, like RANDOM_WAYPOINT_NEAR meant to be derived classes of the basic WAYPOINT, such that all the fields of WAYPOINT are also available for RANDOM_WAYPOINT_NEAR?  If so then I'd know they have the ability to do clustered = true for them too.  If so, that wasn't something I noticed in the docs.

That's conceptually how it works, yup.  One of these days I'll go back and rework the documentation so there's no duplication and it's clear which attributes are common, and which are specific to the various "types".

[Dunbaratu]

Thanks for the fast reply.  So do all the waypoints within the same BEHAVIOUR section attempt to collect together if I give them the same name and call them all clustered = true, and set their count = fields?

[nightingale]

They should cluster even if they have different names (which is probably undesirable...) If you want to change that functionality it should be simple enough - raise a GitHub issue and I'll look at it. 

[Cdr_Zeta]

Greetings,

This is looking kool ! This is just what is needed; basically contracts on the fly (I hope !); meaning and I know contracts can get messed up if not careful and thus one must save gamesave 'folders', not just gamesaves, and the cfg files in the gamedata dir to keep things in order should a problem arise; and it will !

So say I get to a moon, and certain contracts are not available, I as the director can add appropriate contracts to complete sub-missions necessary to complete a main mission (say supply generation for a certain length of time and get rewards for it; at least REP or anything that is needed to keep the game afoot !

Cmdr Zeta

[nightingale]

29 minutes ago, Cdr_Zeta said:

Greetings,

This is looking kool ! This is just what is needed; basically contracts on the fly (I hope !); meaning and I know contracts can get messed up if not careful and thus one must save gamesave 'folders', not just gamesaves, and the cfg files in the gamedata dir to keep things in order should a problem arise; and it will !

So say I get to a moon, and certain contracts are not available, I as the director can add appropriate contracts to complete sub-missions necessary to complete a main mission (say supply generation for a certain length of time and get rewards for it; at least REP or anything that is needed to keep the game afoot !

Cmdr Zeta

Nah, it's really not contracts on the fly.  It's a tool for modders to make contracts very easily (as compared to doing it without Contract Configurator which is requires lots and lots of C# coding).

That being said, if you go back through about a years worth of those GameData directories, I remember you did toy around with Contract Configurator for a little bit in early 2015.

[Dunbaratu]

Am I correct in understanding that for the "agent = ....." setting, the two choices are either "specify nothing" or "specify exactly one"?  I have a collection of contracts for kOS I'm making and I'm trying to make about 3 or 4 new agencies to generate them, but with some randomness where it will pick one of the ones I specify, but I don't specify the exact one - just a set to pick from.

Maybe if it allowed an array here and it means it's a set to choose from randomly that would be neat, like so:

    agent = Turing Machinations
    agent = Lovelace Labs
    agent = Von Neumann Architects

Meaning "pick from one of these 3 choices to be the contract provider".

(edit: Hey, it actually DOES work like this already, it turns out, but it wasn't documented that way.)

Edited January 7, 2016 by Steven Mading
Found out it works

[nightingale]

12 minutes ago, Steven Mading said:

Am I correct in understanding that for the "agent = ....." setting, the two choices are either "specify nothing" or "specify exactly one"?  I have a collection of contracts for kOS I'm making and I'm trying to make about 3 or 4 new agencies to generate them, but with some randomness where it will pick one of the ones I specify, but I don't specify the exact one - just a set to pick from.

Maybe if it allowed an array here and it means it's a set to choose from randomly that would be neat, like so:

    agent = Turing Machinations
    agent = Lovelace Labs
    agent = Von Neumann Architects

Meaning "pick from one of these 3 choices to be the contract provider".

(edit: Hey, it actually DOES work like this already, it turns out, but it wasn't documented that way.)

Actually, it doesn't work that way - you may have had a pre-generated contract from a previous test run waiting in the queue, perhaps.

Anyway, it would be a relatively simple change, so raise the GitHub request and I'll take a look.

[Cdr_Zeta]

38 minutes ago, nightingale said:

39 minutes ago, nightingale said:

Greetings,

This is looking kool ! This is just what is needed; basically contracts on the fly (I hope !); meaning and I know contracts can get messed up if not careful and thus one must save gamesave 'folders', not just gamesaves, and the cfg files in the gamedata dir to keep things in order should a problem arise; and it will !

So say I get to a moon, and certain contracts are not available, I as the director can add appropriate contracts to complete sub-missions necessary to complete a main mission (say supply generation for a certain length of time and get rewards for it; at least REP or anything that is needed to keep the game afoot !

Cmdr Zeta

Nah, it's really not contracts on the fly.  It's a tool for modders to make contracts very easily (as compared to doing it without Contract Configurator which is requires lots and lots of C# coding).

That being said, if you go back through about a years worth of those GameData directories, I remember you did toy around with Contract Configurator for a little bit in early 2015.

I sort of understand...I figure contract manipulation with stock should be somewhat comparable but either way it will be a challenge to work with them and see how I can make them work as well !

I would be some work to have them pre-made but then I wouldnt have to worry in-game; just wondering when they can appear; I dont want a Duna mission to show up when I am at Mun say.

Cmdr Zeta

 

[Dunbaratu]

42 minutes ago, nightingale said:

Actually, it doesn't work that way - you may have had a pre-generated contract from a previous test run waiting in the queue, perhaps.

Anyway, it would be a relatively simple change, so raise the GitHub request and I'll take a look.

Ah I see what happened.  It gives me the alphabetical first one every time when I make a list like that.  I was getting "Lovelace Labs" all the time.  It worked without complaint, but wasn't what I was looking for.

[nightingale]

51 minutes ago, Cdr_Zeta said:

I sort of understand...I figure contract manipulation with stock should be somewhat comparable but either way it will be a challenge to work with them and see how I can make them work as well !

I would be some work to have them pre-made but then I wouldnt have to worry in-game; just wondering when they can appear; I dont want a Duna mission to show up when I am at Mun say.

The requirement for a contract to show up (or not show up) can be almost anything you want.

11 minutes ago, Steven Mading said:

Ah I see what happened.  It gives me the alphabetical first one every time when I make a list like that.  I was getting "Lovelace Labs" all the time.  It worked without complaint, but wasn't what I was looking for.

I have an error for missing mandatory attributes, a warning for extra attributes, but I never thought to put a warning for extra attributes with a duplicate name.

[Dunbaratu]

Sorry if I'm being difficult but I'm really struggling with understanding this.  How do I make Parameter sequence work?  I'm trying to visit waypoints, but force it to visit them in the proper order.  You have to hit the 'alpha' waypoint before the 'beta' waypoint, and so on.   The goal is to make them an effective "driving course" for a rover test contract.

 

So I tried doing it something like this:

    PARAMETER
    {
        name = Run the course
        type = VesselParameterGroup
        PARAMETER
        {
            name = Sequence
            type = Sequence
            PARAMETER
            {
                name = ReachWaypoint1
                type = VisitWaypoint

                // order of the waypoint in the WaypointGenerator list, even though
                // WaypointGenerator disallows the index field, it's got an implied
                // one based on the order it appears in the list in the file:
                index = 0

                title = Reach KSC Rover Point Alpha
                notes = Must be within 10 meters of Alpha.
                distance = 10.0
                showMessages = true
                targetBody = Kerbin

                rewardScience = 2.0
                rewardReputation = 1.0
                rewardFunds = 6000.0

                disableOnStateChange = true // If I don't do this, the checkmark goes away when I leave the waypoint.
            }
            PARAMETER
            {
                name = ReachWaypoint2
                type = VisitWaypoint

                // order of the waypoint in the WaypointGenerator list, even though
                // WaypointGenerator disallows the index field, it's got an implied
                // one based on the order it appears in the list in the file:
                index = 1

                title = Reach KSC Rover Point Beta
                notes = Must be within 10 meters of Beta.
                distance = 10.0
                showMessages = true
                targetBody = Kerbin

                rewardScience = 2.0
                rewardReputation = 1.0
                rewardFunds = 6000.0

                disableOnStateChange = true // If I don't do this, the checkmark goes away when I leave the waypoint.
            }
            PARAMETER
            {
                name = ReachWaypoint3
                type = VisitWaypoint

                // order of the waypoint in the WaypointGenerator list, even though
                // WaypointGenerator disallows the index field, it's got an implied
                // one based on the order it appears in the list in the file:
                index = 2

                title = Reach KSC Rover Point Gamma
                notes = Must be within 10 meters of Gamma.
                distance = 10.0
                showMessages = true
                targetBody = Kerbin

                rewardScience = 2.0
                rewardReputation = 1.0
                rewardFunds = 6000.0

                disableOnStateChange = true // If I don't do this, the checkmark goes away when I leave the waypoint.
            }
            PARAMETER
            {
                name = ReachWaypoint4
                type = VisitWaypoint

                // order of the waypoint in the WaypointGenerator list, even though
                // WaypointGenerator disallows the index field, it's got an implied
                // one based on the order it appears in the list in the file:
                index = 3

                title = Reach KSC Rover Point Delta
                notes = Must be within 10 meters of Delta.
                distance = 10.0
                showMessages = true
                targetBody = Kerbin

                rewardScience = 2.0
                rewardReputation = 1.0
                rewardFunds = 6000.0

                disableOnStateChange = true // If I don't do this, the checkmark goes away when I leave the waypoint.
            }
        }
        PARAMETER
        {
            name = nearGround
            type = ReachState
            title = Keep altitude below 10m AGL
            maxTerrainAltitude = 10.0
        }
}

And the problem is that even when I hit the waypoints in the proper order, and it DOES give them all green checkmarks in the contract display, it sill doesn't consider the sequence itself done for some reason I don't understand.  It still shows as un-checked, even with all four VisitWaypoint's contained inside it checkmarked, and the "nearGround" parameter at the bottom checkmarked too.  With all 5 things showing as green, it still doesn't get marked as completed.

If you want I can post the whole contract file, not just that snippet, but I'm just not understanding why the contract parameter won't close out even when all its component parts have closed out as green checks.

Edited January 7, 2016 by Steven Mading

[nightingale]

That's odd, seems like it could be a bug in the sequence parameter - I'll take a closer look tomorrow.  If you save and reload, does that cause it to complete? 

The other think you can do is use completeInSequence (attribute in the parameters). I don't have an example handy, but I know @linuxgurugamer has been doing something extremely close to what you're doing right now,you may be able to find a good example in the rover contracts GitHub