Jump to content

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

nightingale

By nightingale
in KSP1 Mod Releases

 Share

Recommended Posts

Tonas1997

Tonas1997

Posted
Posted (edited)

I've just launched my RealAgencies mod and someone brought to my attention a possible problem with the agent parser in CC version 1.28.2 (1.28.1 seems to work fine):

Here are two logs for the same contract but on different versions of Contract Configurator. I took the liberty of highlighting the relevant lines:

1.28.1 (works fine)

  Reveal hidden contents

1.28.2 (not working):

  Reveal hidden contents

As you can see, the "agent" line on the data nodes for the secong log file appears as null.

P.S. the problem with the incoherent HasResource nodes I mentioned on the previous page keeps happening; the configs I posted there should help with diagnosing the bug. The contract itself has these two lines: 

minQuantity = Round((Pow(Random(0.5,1.5) * (0.3 + UnlockedTech().Count() / 100),2)*2500)/2,100) * 8
title = Have a ComSatPayload of at least @minQuantity units on the craft

In what situation could minQuantity present different values on these two lines? Now that I think of it, I only ever saw this happening on contracts with more than one simultaneous instance...

Edited by Tonas1997
Removed line break
Link to comment
Share on other sites
GlitchHound

GlitchHound

Posted
Posted (edited)
  On 7/7/2020 at 9:25 PM, Tonas1997 said:

P.S. the problem with the incoherent HasResource nodes I mentioned on the previous page keeps happening; the configs I posted there should help with diagnosing the bug. The contract itself has these two lines: 

minQuantity = Round((Pow(Random(0.5,1.5) * (0.3 + UnlockedTech().Count() / 100),2)*2500)/2,100) * 8
title = Have a ComSatPayload of at least @minQuantity units on the craft

In what situation could minQuantity present different values on these two lines? Now that I think of it, I only ever saw this happening on contracts with more than one simultaneous instance...

Expand  

I can't speak for whether or not it's intended/expected behavior, but I'd wager that minQuantity having a call to Random in it is your issue - probably the title is re-evaluating the expression (including generating another random number) whenever you reference minQuantity, rather than calculating a single value for the contract.

You could test this by NOT specifying the title (the wiki says a requirement will typically get a default value) and seeing if there's still an issue. That may not resolve the problem in a satisfactory way, but it would at least narrow it down.

Edit: Well, actually that doesn't really test it, but it works around it. TESTING it would be perhaps by using @minQuantity more than once in the title, or using it in yet another field, and seeing if that makes it pick 3 distinct values.

Edited by GlitchHound
correction
Link to comment
Share on other sites
HawkEngineer

HawkEngineer

Posted
Posted

Is there a way to generate a list of Biomes for a given body?  I have using the code below but the variable "biomelist" is always null.  Any help would be very appreciated.

    DATA
    {
        type = List<CelestialBody>
        biomelist = @/targetBody.Biomes()
        title = Find Planet's Biomes
    }

Link to comment
Share on other sites
Morphisor

Morphisor

Posted
Posted
  On 7/12/2020 at 1:44 PM, HawkEngineer said:

Is there a way to generate a list of Biomes for a given body?  I have using the code below but the variable "biomelist" is always null.  Any help would be very appreciated.

    DATA
    {
        type = List<CelestialBody>
        biomelist = @/targetBody.Biomes()
        title = Find Planet's Biomes
    }

Expand  

I'm pretty sure your node type should be list<biome> instead of celestialbody.

Link to comment
Share on other sites
HawkEngineer

HawkEngineer

Posted
Posted

One more request for help which I have been trying to figure out for the last several hours.  In the contract example below, I am able to select the biome randomly but when I use the @/targetBiome in the reach state parameter and collect science parameter, I keep getting a parsing error.  Any help or thoughts would be appreciated.

      //===========================================================================================================================

DATA
    {
        type = List<Biome>
        targetBiome = @/targetBody.Biomes().Random()
        title = Find Planet's Biomes and select target biome
    }
    
    PARAMETER
    {
        name = ProbeLander
        type = VesselParameterGroup
        title = Probe Lander
        define = ProbeLander
    
        PARAMETER 
        {
            name = Crewmembers
            type = HasCrew
            minCrew = 0
            maxCrew = 0
            title = Uncrewed
            hideChildren = true
        }
        PARAMETER
        {
            name = LandOnPlanet
            type = ReachState
            situation = LANDED
            situation = SPLASHED
            title = Land on @/targetBody
            targetBody = @/targetBody
            biome = @/tbiome
 
            PARAMETER
            {
                name = CollectScience
                type = CollectScience
                targetBody = @/targetBody
                biome = @/targetBiome
                situation = SrfLanded
                situation = SrfSplashed
                recoveryMethod = Transmit
                title = Gather Science from the surface and transmit home
            } 
        }
    
    }    

Link to comment
Share on other sites
Morphisor

Morphisor

Posted
Posted

@HawkEngineer Without the CC debug info it's hard to tell what exactly is being the problem; a complete overview of the contract would also help, since now we can only assume there's a proper targetbody definition in there, for instance.

That said, it seems this part may be in error:

  Quote

biome = @/tbiome

Expand  

 My guess is that it should be the same as the biome reference in the collectscience parameter?
 

Link to comment
Share on other sites
TranceaddicT

TranceaddicT

Posted
Posted (edited)
  On 7/12/2020 at 5:16 PM, HawkEngineer said:

        PARAMETER

        {
            name = LandOnPlanet
            type = ReachState
            situation = LANDED
            situation = SPLASHED
            title = Land on @/targetBody
            targetBody = @/targetBody
            biome = @/tbiome
         }

Expand  

Also, this should be

biome = @/targetBiome

 

Edited by TranceaddicT
@Morphisor beat me to it
Link to comment
Share on other sites
nightingale

nightingale

Posted
  • Author
Posted (edited)
  On 7/7/2020 at 9:25 PM, Tonas1997 said:

I've just launched my RealAgencies mod and someone brought to my attention a possible problem with the agent parser in CC version 1.28.2 (1.28.1 seems to work fine):

Expand  

Yeah, I was way overzealous in fixing the previous agency parsing bug and allowed a bunch of special characters (including commas).  I've made a fix to disallow commas in agency names.  There should be no reason for that to be needed in the name since it's not used in stock agencies and the name is just an identifier (the title can have anything you want in it still).  Can you test out this quick patch and let me know if it works for you?  Just replace the ContractConfigurator.dll with the linked one.

  Quote

P.S. the problem with the incoherent HasResource nodes I mentioned on the previous page keeps happening; the configs I posted there should help with diagnosing the bug. The contract itself has these two lines: 

minQuantity = Round((Pow(Random(0.5,1.5) * (0.3 + UnlockedTech().Count() / 100),2)*2500)/2,100) * 8
title = Have a ComSatPayload of at least @minQuantity units on the craft

In what situation could minQuantity present different values on these two lines? Now that I think of it, I only ever saw this happening on contracts with more than one simultaneous instance...

Expand  

I'll have a look, it could be a number of things.  It could be that it's somehow not treating the title as non-deterministic (ie. keeping the same value forever).  It could be a scoping issue (picking up the minQuantity from another parameter).  None of these things *should* happen though, the way you've done it is supposed to work.  Just curious - if you put minQuantity as a variable in a DATA node instead, does that still misbehave?

  On 7/12/2020 at 5:16 PM, HawkEngineer said:

One more request for help which I have been trying to figure out for the last several hours.  In the contract example below, I am able to select the biome randomly but when I use the @/targetBiome in the reach state parameter and collect science parameter, I keep getting a parsing error.  Any help or thoughts would be appreciated.

Expand  

I think your problem is that targetBiome is a List<Biome>.  So you have a list of one biome, but the parameter needs one single Biome.  So change the type to just Biome, and I think it will work (and @TranceaddicT makes a good point about the variable name - you need to fix that too).

For everyone else, just want to say that I'm still around and working towards a KSP 1.9 release.  I just need to figure out the vessel spawning stuff, which has always been one of the most annoying things in to get right in KSP.

Edited by nightingale
Link to comment
Share on other sites
HawkEngineer

HawkEngineer

Posted
Posted
  On 7/12/2020 at 6:56 PM, nightingale said:

Yeah, I was way overzealous in fixing the previous agency parsing bug and allowed a bunch of special characters (including commas).  I've made a fix to disallow commas in agency names.  There should be no reason for that to be needed in the name since it's not used in stock agencies and the name is just an identifier (the title can have anything you want in it still).  Can you test out this quick patch and let me know if it works for you?  Just replace the ContractConfigurator.dll with the linked one.

I'll have a look, it could be a number of things.  It could be that it's somehow not treating the title as non-deterministic (ie. keeping the same value forever).  It could be a scoping issue (picking up the minQuantity from another parameter).  None of these things *should* happen though, the way you've done it is supposed to work.  Just curious - if you put minQuantity as a variable in a DATA node instead, does that still misbehave?

I think your problem is that targetBiome is a List<Biome>.  So you have a list of one biome, but the parameter needs one single Biome.  So change the type to just Biome, and I think it will work (and @TranceaddicT makes a good point about the variable name - you need to fix that too).

For everyone else, just want to say that I'm still around and working towards a KSP 1.9 release.  I just need to figure out the vessel spawning stuff, which has always been one of the most annoying things in to get right in KSP.

Expand  

Thanks for everyone's one, changing the type  from list to just Biome fixed the error as well as fixing the variable reference.

Link to comment
Share on other sites
  • 2 weeks later...
oniontrain

oniontrain

Posted
Posted

One of the older contract packs, I can't remember which, had contracts for you to visit shipwrecks it would place underwater, and to deploy weather buoys in the ocean. It might have been two different ones? Does anybody remember which packs these were, and if they've been maintained by anyone since?

Link to comment
Share on other sites
pap1723

pap1723

Posted
Posted

Hello all! I am looking for a solution to the following situation. I want to pay an amount of funds based on how much of a resource was delivered to a specific orbit. This isn't something that can be set in the contract beforehand, it all depends on what the player does.

Basically it works as a BONUS payout. So there will be the regular reward in the contract, and then based on how much resources there are, it is paid out in addition. I am almost positive I have made contracts with bonus payouts before, but cannot remember the syntax on it.

Thanks!

Link to comment
Share on other sites
nightingale

nightingale

Posted
  • Author
Posted
  On 7/29/2020 at 2:50 PM, pap1723 said:

Hello all! I am looking for a solution to the following situation. I want to pay an amount of funds based on how much of a resource was delivered to a specific orbit. This isn't something that can be set in the contract beforehand, it all depends on what the player does.

Basically it works as a BONUS payout. So there will be the regular reward in the contract, and then based on how much resources there are, it is paid out in addition. I am almost positive I have made contracts with bonus payouts before, but cannot remember the syntax on it.

Thanks!

Expand  

Right now the only way to do any kind of sliding scale is using a tier system with optional parameters (set optional=true on a parameter).  Each tier would be a separate parameter: 

PARAMETER
{
    type=HasResource

    resource = LiquidFuel
    minQuantity = 100.0
    rewardFunds = 1000.0

    optional=true
}

PARAMETER
{
    type=HasResource

    resource = LiquidFuel
    minQuantity = 200.0
    rewardFunds = 2000.0

    optional=true
}

... etc

You may also want a "hold for 5 seconds" type parameter as well - otherwise I'm not sure what order KSP will look at the parameters in and it may not register all the tier parameters.

Link to comment
Share on other sites
severedsolo

severedsolo

Posted
Posted (edited)

@nightingale  - welcome back!

Seeing an issue where a DATA node using CelestialBody (and possibly also due to it using SelectUnique()) is not "locking" the contracts on a successful roll and is reevaluating and withdrawing the contract instead if another body in the list of candidates can't satisfy the REQUIREMENT.

Contract that reproduces the issue (used PasteBin as I'm about to hide the issue in E+ by adding another parameter to the list)

https://pastebin.com/JWyyKWLH

Test Case:

Mun has been orbited and a return from orbit has been completed, Minmus has been orbited but not returned from.

Expected Behaviour:

A "return from Minmus" contract should be offered and not withdrawn.

Actual Behaviour:

Although a "return from Minmus" contract is offered, it's withdrawn when the DATA node is re-evaluated. My suspicion is this is because the DATA node contains two candidates, Mun and Minmus - but only one of them satisfies the requirement node: You can see the Body is being switched to Mun in Mission Control as the requirement test changes to "Must not have returned from orbit of Mun" 

OrbitedBodies().Where(b => !b.IsHomeWorld()).SelectUnique()
    REQUIREMENT
    {
        name = ReturnFromOrbit
        type = ReturnFromOrbit
		targetBody = @/targetBody1
		invertRequirement = true
    }

What I believe should happen, is once a contract has successfully generated, it should be left alone (ie CC should consider offering a new contract if Mun also meets the requirements, rather than re-evaluating the Minmus one)

Suspected Root Cause:

The List<CelestialBody> contains two valid candidates, but only one of them satisfies the REQUIREMENT node. Presumably this will get worse as the player reaches more and more bodies, as the ratio of "good" candidates vs "bad" candidates will get slimmer and slimmer.

Workarounds:

Make it so the List<> can only have candidates that satisfy the requirements. Ideally of course, I'd like a "HaveReturnedFromOrbit" method for CelestialBody() but this will hide the issue, rather than fixing it.

Log: https://www.dropbox.com/s/kx7gh1e88mhggmj/KSP.log?dl=0

 

Edited by severedsolo
Link to comment
Share on other sites
TranceaddicT

TranceaddicT

Posted
Posted (edited)

@severedsolo

In the initial CONTRACT_TYPE definition you set

CONTRACT_TYPE
{
name = ExplorationPlus-Gemini
...
targetBody = @/targetBody1
...
}

Once it's set, should you not use targetBody in the remaining PARAMETER nodes to lock in that value?

Why does this not work?

  1. PARAMETER
  2. {
  3. name = ReturnerDefine
  4. ...
  5.     PARAMETER
  6.     {
  7.     ...
  8.     title = Orbit @targetBody
  9.     }

Isn't that why when the contract is reevaluated everything goes wonky! Because you continue referencing a procedurally generated variable, @/targettBody1 instead of the initialized variable targetBody . 

Edited by TranceaddicT
Link to comment
Share on other sites
severedsolo

severedsolo

Posted
Posted

 

  On 8/2/2020 at 6:25 PM, TranceaddicT said:

Once it's set, should you not use targetBody in the remaining PARAMETER nodes to lock in that value?

Expand  

Appreciate the attempt to help - in theory doing this is exactly the same as referencing @/targetBody1 (just tested and got same behaviour, in case it was a workaround).

The DATA node shouldn't really be re-evaluated at all if it scores a "hit" - usual behaviour would be for CC to evaluate the DATA node to see if it can generate a *new* contract, rather than re-evaluating an already generated one.

Link to comment
Share on other sites
Morphisor

Morphisor

Posted
Posted

@nightingale In case you want to further investigate the issue presented by @severedsolo, I have witnessed similar behaviour within your own Field Research contracts: contracts suddenly generating, then being retracted almost as quickly. This isn't a new thing either.

The main thing in common is target selection using data nodes and selection from a larger pool of possible targets; both contract sets use select.unique to do so, though I'm unsure if the problem is within that syntax or with data nodes as whole.

Link to comment
Share on other sites
nightingale

nightingale

Posted
  • Author
Posted

@severedsolo - Yeah, that's an old bug, but your post gave me enough hints that I think I finally know what's going on.  The requirement nodes get "soft-copied" from the contract type to the contract instance when the contract is created.  So in a sense the contract and contract type are "sharing" the requirement node, and when there is a new check for a generating a different contract of the same type, the value in the requirement gets change,d invalidating the original contract.

I think this used to work because the contract generator used to create a copy of the contract and I changed how that worked when redoing the mission control screen.

I should be able to fix this, but I'll need to do some tests.

Link to comment
Share on other sites
nightingale

nightingale

Posted
  • Author
Posted

Okay, hopefully this is the last release against KSP 1.8, and should be stable.  Next up I'm going to try to solve all the vessel spawning issues against KSP 1.9, then move on to KSP 1.10.

Contract Configurator 1.28.3

  • More changes to AgentParser, now commas are disallowed as part of agent names (thanks Tonas1997).
  • Fixed requirements being regenerated incorrectly on some contracts, resolves issues with "flickering" of contracts in mission control (thanks severedsolo).
Link to comment
Share on other sites
nightingale

nightingale

Posted
  • Author
Posted

I've fixed the vessel spawning issues, and this release is looking good on KSP 1.9.  I've smoke tested against KSP 1.10 and it seems okay there too.  However, I'm going to do a formal release against KSP 1.10 soon too (but in the meantime let me know if this one has issues).

Contract Configurator 1.29.0

  • Recompile against KSP 1.9.1.
  • Fixed various vessel spawning issues.
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...