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

[linuxgurugamer]

4 hours ago, nightingale said:

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 

Not yet.  The stuff I've been working on is not yet in github.

contact me if you want a copy of the latest version, only works with the dev version of CC

4 hours ago, Steven Mading said:

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.

Are you sure you don't have a hidden parameter?

If you want, shoot me a copy of the contract and I'll take a look.

What version of CC are you using for this?

[Dunbaratu]

5 hours ago, linuxgurugamer said:

If you want, shoot me a copy of the contract and I'll take a look.

What version of CC are you using for this?

 I'll try to trim the example down to one that has the problem without other things today.  My current version has other dependencies in it like needing a plugin DLL I made for a new contract parameter "hands off controls" for kOS purposes, and it refers to agencies you might not have.  I'll try making a minimalist example that still exhibits the problem and post it here.

[linuxgurugamer]

Just send me what you have so I can look at it.  It might be something obvious (to me) since I've recently been working with it

[smjjames]

After installing the 'Full Pack' option of the Historical Missions, I got this rather long exception just as it transitioned to the menu screen:

Not sure if the Apollo-1 thing is related.... Also, hope I don't have to kill any kerbals for that one......

ContractConfigurator.ContractType: CONTRACT_TYPE 'Apollo-I': Error parsing prestige
 
(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

ArgumentException: The requested value 'triv' was not found.
  at System.Enum.Parse (System.Type enumType, System.String value, Boolean ignoreCase) [0x00000] in <filename unknown>:0 

  at System.Enum.Parse (System.Type enumType, System.String value) [0x00000] in <filename unknown>:0 

  at ContractConfigurator.ExpressionParser.EnumExpressionParser`1[Contracts.Contract+ContractPrestige].ParseIdentifier (ContractConfigurator.ExpressionParser.Token token) [0x00000] in <filename unknown>:0 

  at ContractConfigurator.ExpressionParser.ExpressionParser`1[Contracts.Contract+ContractPrestige].ParseVarOrIdentifier (ContractConfigurator.ExpressionParser.Token token) [0x00000] in <filename unknown>:0 

  at ContractConfigurator.ExpressionParser.ExpressionParser`1[Contracts.Contract+ContractPrestige].ParseSimpleStatement[ContractPrestige] () [0x00000] in <filename unknown>:0 
Rethrow as Exception: Error parsing statement.
Error occurred near '*':
triv
....* <-- HERE
  at ContractConfigurator.ExpressionParser.ExpressionParser`1[Contracts.Contract+ContractPrestige].ParseExpression (System.String key, System.String expression, ContractConfigurator.ExpressionParser.DataNode dataNode) [0x00000] in <filename unknown>:0 

  at ContractConfigurator.ConfigNodeUtil.ParseSingleValue[ContractPrestige] (System.String key, System.String stringValue, Boolean allowExpression) [0x00000] in <filename unknown>:0 

  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&)

  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 

  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0 

  at ContractConfigurator.ConfigNodeUtil.ParseValue[List`1] (.ConfigNode configNode, System.String key, Boolean allowExpression) [0x00000] in <filename unknown>:0 
UnityEngine.Debug:Internal_LogException(Exception, Object)
UnityEngine.Debug:LogException(Exception)
ContractConfigurator.LoggingUtil:LogException(Exception)
ContractConfigurator.ConfigNodeUtil:ParseValue(ConfigNode, String, Action`1, IContractConfiguratorFactory, List`1, Func`2)
ContractConfigurator.ConfigNodeUtil:ParseValue(ConfigNode, String, Action`1, IContractConfiguratorFactory, List`1)
ContractConfigurator.ContractType:Load(ConfigNode)
ContractConfigurator.<LoadContractConfig>d__1e:MoveNext()
ContractConfigurator.ContractConfigurator:Update()

 

[Dunbaratu]

1 hour ago, linuxgurugamer said:

Just send me what you have so I can look at it.  It might be something obvious (to me) since I've recently been working with it

Okay I put it into pastebin:  http://pastebin.com/eUHtTtiT

The eventual goal is to make this require the player keep their hands off the controls, and the contract has to be completed by their kOS script driving the rover to count.  But for now for testing purposes I have that requirement commented out so the contract can be driven manually by hand.  I also commented out the requirement to have a kOS CPU part unlocked in the tech tree, for the same reasons, so this can be tried out on a stock install.

You do, however, need a career that has advanced far enough that you have rover wheels unlocked.

Edited January 7, 2016 by Steven Mading

[nightingale]

5 minutes ago, smjjames said:

After installing the 'Full Pack' option of the Historical Missions, I got this rather long exception just as it transitioned to the menu screen:

Not sure if the Apollo-1 thing is related.... Also, hope I don't have to kill any kerbals for that one......

ContractConfigurator.ContractType: CONTRACT_TYPE 'Apollo-I': Error parsing prestige
 
(Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

ArgumentException: The requested value 'triv' was not found.
  at System.Enum.Parse (System.Type enumType, System.String value, Boolean ignoreCase) [0x00000] in <filename unknown>:0 

  at System.Enum.Parse (System.Type enumType, System.String value) [0x00000] in <filename unknown>:0 

  at ContractConfigurator.ExpressionParser.EnumExpressionParser`1[Contracts.Contract+ContractPrestige].ParseIdentifier (ContractConfigurator.ExpressionParser.Token token) [0x00000] in <filename unknown>:0 

  at ContractConfigurator.ExpressionParser.ExpressionParser`1[Contracts.Contract+ContractPrestige].ParseVarOrIdentifier (ContractConfigurator.ExpressionParser.Token token) [0x00000] in <filename unknown>:0 

  at ContractConfigurator.ExpressionParser.ExpressionParser`1[Contracts.Contract+ContractPrestige].ParseSimpleStatement[ContractPrestige] () [0x00000] in <filename unknown>:0 
Rethrow as Exception: Error parsing statement.
Error occurred near '*':
triv
....* <-- HERE
  at ContractConfigurator.ExpressionParser.ExpressionParser`1[Contracts.Contract+ContractPrestige].ParseExpression (System.String key, System.String expression, ContractConfigurator.ExpressionParser.DataNode dataNode) [0x00000] in <filename unknown>:0 

  at ContractConfigurator.ConfigNodeUtil.ParseSingleValue[ContractPrestige] (System.String key, System.String stringValue, Boolean allowExpression) [0x00000] in <filename unknown>:0 

  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&)

  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 

  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0 

  at ContractConfigurator.ConfigNodeUtil.ParseValue[List`1] (.ConfigNode configNode, System.String key, Boolean allowExpression) [0x00000] in <filename unknown>:0 
UnityEngine.Debug:Internal_LogException(Exception, Object)
UnityEngine.Debug:LogException(Exception)
ContractConfigurator.LoggingUtil:LogException(Exception)
ContractConfigurator.ConfigNodeUtil:ParseValue(ConfigNode, String, Action`1, IContractConfiguratorFactory, List`1, Func`2)
ContractConfigurator.ConfigNodeUtil:ParseValue(ConfigNode, String, Action`1, IContractConfiguratorFactory, List`1)
ContractConfigurator.ContractType:Load(ConfigNode)
ContractConfigurator.<LoadContractConfig>d__1e:MoveNext()
ContractConfigurator.ContractConfigurator:Update()

 

That's a known issue with the current historic missions release (it's currently being discussed on that thread right now).  It's an easy fix once @Whitecat106 is able to get time to fix it (you can manually change triv to Trivial if you want to play the Apollo I mission).

[Dunbaratu]

Does PartUnlocked and PartModuleUnlocked mean merely that you have the tech tree node that allows them ulocked or does it mean you have actually paid the cost of that specific part so it is no longer greyed out in the VAB?  For the purpose of making contracts I think it would be more useful if it meant the node containing the part is unlocked, not necessarily the part itself.  For my rover contract it would be useful if it said "you don't get the contract until you *could* make rover wheels", rather than "you don't get it until you already *have* made rover wheels once."

I think most players never unlock parts themselves in the science center, instead waiting until they're in the VAB or SPH and need the part, and then they unlock it from *there*.  So if I wait for wheels to be unlocked before I give out the contract, that's going to effectively mean it won't show up until someone already built something with their new wheel parts, rather than it showing up in order to incentivize them to make something for the first time with wheel parts once they can.

[nightingale]

19 minutes ago, Steven Mading said:

Does PartUnlocked and PartModuleUnlocked mean merely that you have the tech tree node that allows them ulocked or does it mean you have actually paid the cost of that specific part so it is no longer greyed out in the VAB?  For the purpose of making contracts I think it would be more useful if it meant the node containing the part is unlocked, not necessarily the part itself.  For my rover contract it would be useful if it said "you don't get the contract until you *could* make rover wheels", rather than "you don't get it until you already *have* made rover wheels once."

I think most players never unlock parts themselves in the science center, instead waiting until they're in the VAB or SPH and need the part, and then they unlock it from *there*.  So if I wait for wheels to be unlocked before I give out the contract, that's going to effectively mean it won't show up until someone already built something with their new wheel parts, rather than it showing up in order to incentivize them to make something for the first time with wheel parts once they can.

They need to have the part actually unlocked (paid for).  You can use TechResearched and use the part attribute to select the tech.  If you'd rather do this with a PartModule then raise a GitHub issue, as there isn't anything right now but it's an easy addition.

[linuxgurugamer]

1 hour ago, Steven Mading said:

Okay I put it into pastebin:  http://pastebin.com/eUHtTtiT

The eventual goal is to make this require the player keep their hands off the controls, and the contract has to be completed by their kOS script driving the rover to count.  But for now for testing purposes I have that requirement commented out so the contract can be driven manually by hand.  I also commented out the requirement to have a kOS CPU part unlocked in the tech tree, for the same reasons, so this can be tried out on a stock install.

You do, however, need a career that has advanced far enough that you have rover wheels unlocked.

First, you can remove the lines 

targetBody = Kerbin

I think it would be better to have that as a requirement rather than a target body.  Targetbody will default to the location of the contract, and you already specify that at the top.

If I get sometime this evening, I'll load it up and see what else I can find.  Other than the above comment, I don't see anything wrong.

Are you using the latest dev dll?

Edited January 7, 2016 by linuxgurugamer

[smjjames]

Quick question on the CC options in the KSC screen, which of the stock contract options cover the 'recover kerbal' contracts? I think they might be the 'recover asset' ones, but just asking.

[nightingale]

54 minutes ago, smjjames said:

Quick question on the CC options in the KSC screen, which of the stock contract options cover the 'recover kerbal' contracts? I think they might be the 'recover asset' ones, but just asking.

Correct, it's the recover asset.

54 minutes ago, linuxgurugamer said:

First, you can remove the lines 

targetBody = Kerbin

I think it would be better to have that as a requirement rather than a target body.  Targetbody will default to the location of the contract, and you already specify that at the top.

If I get sometime this evening, I'll load it up and see what else I can find.  Other than the above comment, I don't see anything wrong.

Are you using the latest dev dll?

I'll have a look at it this evening as well and let you know if it's a bug in the Sequence (my suspicion at the moment from the snippet I've seen).

[Dunbaratu]

To answer your earlier question, the version of ContractConfigurator I'm using is 1.9.2.1, which is the most recent one listed in CKAN, but probably not up to date with your develop version.

I had to wait until I was home to access my gaming computer to find this information out.

 

[linuxgurugamer]

Ok.  I just tested this with the latest dll, as of about 8 am this morning.

I see the issue, no idea what the problem is.

I did a little playing around, but no idea.  It's about as simple as you can make it, so I think it is in @nightingale's court now

[severedsolo]

11 hours ago, Steven Mading said:

Okay I put it into pastebin:  http://pastebin.com/eUHtTtiT

The eventual goal is to make this require the player keep their hands off the controls, and the contract has to be completed by their kOS script driving the rover to count.  But for now for testing purposes I have that requirement commented out so the contract can be driven manually by hand.  I also commented out the requirement to have a kOS CPU part unlocked in the tech tree, for the same reasons, so this can be tried out on a stock install.

You do, however, need a career that has advanced far enough that you have rover wheels unlocked.

You have both a description = line and topic/subject/motivation lines. Use only one (description OR topic/subject/motivation).

Your big problem (and the one that I bet is causing your issues) is that you have a redundant VPG wrapped around your sequence node.

    PARAMETER
    {
        name = Run the course
        type = VesselParameterGroup

        PARAMETER
        {
            name = Sequence
            type = Sequence
<lots of other contracty stuff>
  }
  }

The VPG is unnecessary. You have no definitions, no vessel requirements, it's just an empty parameter. I know CC doesn't always like it when you nest a ton of parameters, so I bet that's the problem.

Also: spaces in names ("Run the course") - not a good idea as it makes it difficult to target with ModuleManager - if you meant the player to see "Run the course" in the contract window, you need to add a title = line.

So, it would be:

        PARAMETER
        {
            name = Sequence
            type = Sequence
	title = Run the Course
<lots of other contracty stuff>
  }

Huh, apparently code boxes don't line up new lines, even if they are properly spaced in the editor.

Edited January 8, 2016 by severedsolo

[nightingale]

3 minutes ago, severedsolo said:

You have both a description = line and topic/subject/motivation lines. Use only one (description OR topic/subject/motivation).

Your big problem (and the one that I bet is causing your issues) is that you have a redundant VPG wrapped around your sequence node.

    PARAMETER
    {
        name = Run the course
        type = VesselParameterGroup

        PARAMETER
        {
            name = Sequence
            type = Sequence
<lots of other contracty stuff>
  }
  }

The VPG is unnecessary. You have no definitions, no vessel requirements, it's just an empty parameter. I know CC doesn't always like it when you nest a ton of parameters, so I bet that's the problem.

It was a legit bug - but there's a good chance what you suggested would've fixed it too.  The major benefit his way gives is that it will prevent the exploit of visiting the 4 waypoints with 4 different ships (which might be significant in some instances).

[severedsolo]

On 08/01/2016 at 6:24 AM, nightingale said:

It was a legit bug - but there's a good chance what you suggested would've fixed it too.  The major benefit his way gives is that it will prevent the exploit of visiting the 4 waypoints with 4 different ships (which might be significant in some instances).

Oh, I didn't realise VPGs worked like that. In that case ignore me - as that was clearly your intention, because it's a race course.

Ooh. 666 posts.

Edited January 9, 2016 by severedsolo

[Dunbaratu]

Thanks for the quick bug fix.  I've tried it and the problem is gone now.

 

[Dunbaratu]

I don't know if a thing like this already exists (I couldn't find it in the docs) but if it did it would be useful for what I'm trying to work on:

A Contract Parameter who's state depends on just an arbitrary expression the config file creates out of DATA and/or Expression Behaviour data nodes.  This would allow me to make up my own arbitrary complicated conditions by just tracking them with my own data variables I change when other parameters trigger.

What I'm trying to do is basically this:

I have a Sequence representing the waypoints to hit for the rover drive course.  Once the first parameter in the sequence becomes true (hit waypoint alpha), then I want to apply an additional condition that must remain true or else the driving course needs to start over (the Sequence list goes back to the first one again) the instant it becomes false.  This additional condition is an "AND" (or "All") combination of these two things: altitude AGL < 10 and players keep hands off the manual controls.

I can do each of those things individually,  It's the combination of those terms together that's proving difficult with the tools available (or maybe I just don't understand them).  Prior to starting the waypoint course, I want to allow AGL > 10 and manual controlling.  After the waypoint course begins (the first VisitWaypoint happens), then from that point onward, the conditions AGL < 10 and non-manual-control must continually be true at all times until all the other VisitWaypoints have happened.  If they have failed, then it doesn't fail the contract entirely, it just resets the waypoint list to the start and that attempt didn't count.  You have to start the sequence over.

I've gotten a bunch of attempts that *nearly* do this but not quite.  The hardest part is that each VisitWaypoint is an instant effect, while the other conditions are continual effects.  If I try to connect them to the VisitWaypoint in a boolean combination with Any, then the contract allows "hopping" landers to work, which just land at each waypoint, flown manually, and once the player lets go of the controls for an instant after landing it considers that a success (I don't want it too.  Once the first waypoint is hit, I want it to fail and reset from then on, even when not near a waypoint at the time, whenever the controls are touched or the vehicle rises above 10m.).

I finally worked out that I don't think the built-in conditions can do exactly this, but thought "no problem, I'll track these conditions myself in my own expression Behaviours".... and then ran into the problem that I don't think I see a way to say "this is a parameter which succeeds when my variable foo = 1 and my variable bar = 2" or anything along those lines.  Thus the comment at the top of this message.

 

Edited January 9, 2016 by Steven Mading

[nightingale]

8 hours ago, Steven Mading said:

I don't know if a thing like this already exists (I couldn't find it in the docs) but if it did it would be useful for what I'm trying to work on:

A Contract Parameter who's state depends on just an arbitrary expression the config file creates out of DATA and/or Expression Behaviour data nodes.  This would allow me to make up my own arbitrary complicated conditions by just tracking them with my own data variables I change when other parameters trigger.

What I'm trying to do is basically this:

I have a Sequence representing the waypoints to hit for the rover drive course.  Once the first parameter in the sequence becomes true (hit waypoint alpha), then I want to apply an additional condition that must remain true or else the driving course needs to start over (the Sequence list goes back to the first one again) the instant it becomes false.  This additional condition is an "AND" (or "All") combination of these two things: altitude AGL < 10 and players keep hands off the manual controls.

I can do each of those things individually,  It's the combination of those terms together that's proving difficult with the tools available (or maybe I just don't understand them).  Prior to starting the waypoint course, I want to allow AGL > 10 and manual controlling.  After the waypoint course begins (the first VisitWaypoint happens), then from that point onward, the conditions AGL < 10 and non-manual-control must continually be true at all times until all the other VisitWaypoints have happened.  If they have failed, then it doesn't fail the contract entirely, it just resets the waypoint list to the start and that attempt didn't count.  You have to start the sequence over.

I've gotten a bunch of attempts that *nearly* do this but not quite.  The hardest part is that each VisitWaypoint is an instant effect, while the other conditions are continual effects.  If I try to connect them to the VisitWaypoint in a boolean combination with Any, then the contract allows "hopping" landers to work, which just land at each waypoint, flown manually, and once the player lets go of the controls for an instant after landing it considers that a success (I don't want it too.  Once the first waypoint is hit, I want it to fail and reset from then on, even when not near a waypoint at the time, whenever the controls are touched or the vehicle rises above 10m.).

I finally worked out that I don't think the built-in conditions can do exactly this, but thought "no problem, I'll track these conditions myself in my own expression Behaviours".... and then ran into the problem that I don't think I see a way to say "this is a parameter which succeeds when my variable foo = 1 and my variable bar = 2" or anything along those lines.  Thus the comment at the top of this message.

An expression parameter would be doable, but would definitely have limits (most of the expressions are executed at parse time, so most "@" variables would be unavailable for use within expressions).  You'd have to set some flag with behaviours that trigger off parameters, and then use the expression parameter to check it.  It sounds like that's what you're looking for, so you may be okay.  If it is, raise the enhancement request and I'll look at it (likely for 1.9.4).

In general, resetting parameters is not possible.  The best I can offer with the current parameterset is to fail the contract (although then you might run into #426, which I'm hoping to look at soon).  I could offer a behaviour that resets the state of a parameter (triggered off another parameter completing).

Or I can maybe look at something where the completeInSequence has another mode where a "pre-requisite" in the sequential list gets unchecked, it will reset the parameters below it.  For example:

1. AGL < 10
2. Waypoint 1
3. Waypoint 2
4. etc.

if you had #1 and #2 checked off, but then went above 10m (#1 no longer checked off), it would automatically go through the ones below it and mark those as incomplete (ie. resetting you to zero).  I think this is probably the simplest option, rather than trying to bring expressions into the mix.

[Dunbaratu]

5 hours ago, nightingale said:

Or I can maybe look at something where the completeInSequence has another mode where a "pre-requisite" in the sequential list gets unchecked, it will reset the parameters below it.  For example:

1. AGL < 10
2. Waypoint 1
3. Waypoint 2
4. etc.

if you had #1 and #2 checked off, but then went above 10m (#1 no longer checked off), it would automatically go through the ones below it and mark those as incomplete (ie. resetting you to zero).  I think this is probably the simplest option, rather than trying to bring expressions into the mix.
 

Yes, that would be perfect.  I sort of thought it already worked this way and tried doing it like that at first, but it didn't.  (My reason for thinking it worked this way was how the VisitWaypoints need the disableOnStateChange option or else they go unchecked again when you leave the waypoint, so I figured the same would be true of any other parameter - if it becomes false midway through you have to go back and try again from the top, but that doesn't seem to be the case.)

Edited January 9, 2016 by Steven Mading

[nightingale]

5 hours ago, Steven Mading said:

Yes, that would be perfect.  I sort of thought it already worked this way and tried doing it like that at first, but it didn't.  (My reason for thinking it worked this way was how the VisitWaypoints need the disableOnStateChange option or else they go unchecked again when you leave the waypoint, so I figured the same would be true of any other parameter - if it becomes false midway through you have to go back and try again from the top, but that doesn't seem to be the case.)

Raised [#441].  I'd kind of like it to work the way we've described by default, but I'll have to get very serious though as to whether that can be done without breaking existing contract packs.

[Dunbaratu]

3 hours ago, nightingale said:

Raised [#441].  I'd kind of like it to work the way we've described by default, but I'll have to get very serious though as to whether that can be done without breaking existing contract packs.

Yeah I get the backward compatibility problem.  There's a lot of things kOS does by default that I wish weren't the default, but they'd be impossible to fix without breaking existing scripts.  We often have the sane proper way of doing things ending up being the more verbose uglier way, and the less sane way of doing things being the terse way.  A good example of this is the triggers like WHEN...THEN.  By *default* they only fire once and then erase themselves.  You go out of your way to specify when you want them to NOT go away, which feels really backward but that's what we're stuck with because.. backward compatibility with the way it was first done before we got our hands on it necessitates it be that way.

So yeah I understand if it ends up being not so nice to work with because of backward compatibility.  I deal with that problem a lot.

 

Edited January 10, 2016 by Steven Mading

[inigma]

For https://github.com/inigmatus/GAP/issues/126

Trying to simplify the approach: How can I create a Requirement to check if a player has unlocked an air-breathing engine?

[nightingale]

6 hours ago, inigma said:

For https://github.com/inigmatus/GAP/issues/126

Trying to simplify the approach: How can I create a Requirement to check if a player has unlocked an air-breathing engine?

Difficult to do, as they don't "look" different than any other engine as far as the fields that the requirements can check.  You could try flipping the problem around and look for intakes (use the PartModuleUnlocked requirement with module ModuleResourceIntake).  Technically there can be other intakes than an Air intake, but you'd expect an Air intake to be the first.  Hopefully you wouldn't hit a situation where intakes are unlocked before engines (they're on the same node in stock at least).

[inigma]

2 minutes ago, nightingale said:

Difficult to do, as they don't "look" different than any other engine as far as the fields that the requirements can check.  You could try flipping the problem around and look for intakes (use the PartModuleUnlocked requirement with module ModuleResourceIntake).  Technically there can be other intakes than an Air intake, but you'd expect an Air intake to be the first.  Hopefully you wouldn't hit a situation where intakes are unlocked before engines (they're on the same node in stock at least).

I thought about doing the check based on intakes, however some players will be able to create intake crafts powered by solid rockets or rockets, defeating the check and intent of GAP.   Would it be an easy enhancement to include the same logic for PartModuleUnlocked as you do for PartValidation and its ability to filter?