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

severedsolo · March 29, 2015

I don't think I'm using any of those parameters.

Is targetVessel going? I was getting warnings about that yesterday.

linuxgurugamer · March 29, 2015

Looks like I've got some modifying to do

Me too.

Thanks for the notice, i'll get changes out this evening.

tjsnh · March 29, 2015

[TABLE=class: cms_table, width: 0]
[TR]
[TD]EnterSOI[/TD]
[TD]Obsolete[/TD]
[TD]Removed[/TD]
[TD]Use VesselHasVisited, Orbit or ReachState instead.[/TD]
[/TR]
[/TABLE]

Question : Looking at the ReachState parameter i'm flaking a bit on the best way to replace enterSOI. Would this work :

PARAMETER
{
    name = ReachState999999
    type = ReachState
    targetBody = Mun
    situation = ESCAPING
}

The "escaping" situation would seem to be what most objects are in for "situation" when they first enter the SOI of something. Is this probably the right way to replace EnterSOI or is the VessalHasVisited more appropriate ? Something like:

PARAMETER
{
    name = VesselHasVisited999999
    type = VesselHasVisited
    targetBody = Mun
    situation = Flyby
}

?

I guess my question is, can you give me a little more info about the inner workings of how situation=escaping under VRS and situation=flyby under VHV differ? Or if you have an opinion as to which is more appropriate to use in a simple "send a mission to LocationX" contract and have it complete simply on entering the SOI?

UPDATE:

Just tested using VHV, and it doesnt work. Used the following syntax for sending an unmanned probe to the mun - probe entered, and exited, the mun's SOI with no completion credit. Note that the contract fails to load without the situation=flyby tag, with an error that it's missing the situation argument.

PARAMETER
{
    name = VesselParameterGroup3001
    type = VesselParameterGroup
    define = Mun Probe
    PARAMETER
        {
            name = HasCrew3001
            type = HasCrew
            maxCrew = 0
            minCrew = 0
        }
    PARAMETER
        {
            name = VesselHasVisited3001
            type = VesselHasVisited
            targetBody = Mun
            situation = Flyby
        }
}

Update 2 : Using the same contract, this syntax seems to work as I had hoped with no debug warnings:

PARAMETER
        {
            name = ReachState3001
            type = ReachState
            targetBody = Mun
            situation = ESCAPING
        }

Edited March 29, 2015 by tjsnh

nightingale · March 29, 2015

About the "cleaning up", that got me thinking. For more elaborate contracts using sequence node and vessel parameter groups and so on, the contracts window looks very cluttered now.

For example one of my earlier contracts should only require players to bring a vessel with at least one crew above 18km and then land safely on Kerbin again.

This is the code, and it generates a whole 18! lines of mission objectives in the Mission Control building. Which is kind of overwhelming. Is there a way to introduce at least a "hiding" statements for each parameter?

For example instead of having one line saying "Crew: At least 1 Kerbal: Incomplete" and the next line saying "Count: At least 1: Incomplete", one would be enough.

Same goes for the "Destination: Kerbin" and the "Vessel State", in most contracts, that is obvious from the context, so a flag to hide them would be nice.

PARAMETER
    {
        name = 18kmKerbinSeqNode
        type = SequenceNode

        PARAMETER
        {
            name = 18kmKerbin
            type = VesselParameterGroup

            define = mAltRecord

            PARAMETER
            {
                name = HasCrew
                type = HasCrew

                minCrew = 1
            }

            PARAMETER
            {
                name = ReachState
                type = ReachState

                minAltitude = 18000
            }
        }
    }

    PARAMETER
    {
        name = LandKerbinSeqNode
        type = SequenceNode

        PARAMETER
        {
            name = LandKerbin
            type = VesselParameterGroup

            vessel = mAltRecord

            PARAMETER
            {
                name = HasCrew
                type = HasCrew

                minCrew = 1
            }

            PARAMETER
            {
                name = Any
                type = Any

                PARAMETER
                {
                    name = ReachState
                    type = ReachState

                    targetBody = Kerbin
                    situation = LANDED
                }

                PARAMETER
                {
                    name = ReachState
                    type = ReachState

                    targetBody = Kerbin
                    situation = SPLASHED
                }
            }
        }
    }

Thank you very much for the plugin and your support!

SequenceNode was obsoleted in in 0.6.7 and will be removed in 1.0.0 as well!! You'll want to replace it with the much simpler completeInSequence attribute. Anyway, there is a way to hide parameters, but only if you use the Sequence parameter to wrap everything. In it you can specify a list of parameters in hiddenParameter: those parameters will be hidden until they are available to be completed. I can probably generalize something like this to work for the completeInSequence flag. If this is something you'd be interested in, raise a GitHub issue and I'll take a look.

I don't think I'm using any of those parameters.
Is targetVessel going? I was getting warnings about that yesterday.

Correct! A DATA node should provide the exact same functionality. Using targetVessel was too limiting - it meant I had to add code for new attributes every time there was a new class being handled by expression. It's also very limiting - what if you want to do it for a double or string? Or two vessels, but you don't want to use a list? Anyway, if it's not working *exactly* the same as before, then it may be bugs, so let me know.

Question : Looking at the ReachState parameter i'm flaking a bit on the best way to replace enterSOI. Would this work :
PARAMETER
{
    name = ReachState999999
    type = ReachState
    targetBody = Mun
    situation = ESCAPING
}
The "escaping" situation would seem to be what most objects are in for "situation" when they first enter the SOI of something. Is this probably the right way to replace EnterSOI or is the VessalHasVisited more appropriate ? Something like:
PARAMETER
{
    name = VesselHasVisited999999
    type = VesselHasVisited
    targetBody = Mun
    situation = Flyby
}
?
I guess my question is, can you give me a little more info about the inner workings of how situation=escaping under VRS and situation=flyby under VHV differ? Or if you have an opinion as to which is more appropriate to use in a simple "send a mission to LocationX" contract and have it complete simply on entering the SOI?

ReachState has disableOnStateChange = false by default. Which means if you set up two ReachState parameters (one Mun, one Minmus), you won't be able to complete both unless you specify disableOnStateChange = true. If you do chose ReachState, then the situation is optional, so I'd just leave it off. Escaping is the most logical one, but it'll look unintuitive to the player.

So I'd definitely recommend VesselHasVisited here (pretty much exactly as you wrote it up).

tjsnh · March 29, 2015

So I'd definitely recommend VesselHasVisited here (pretty much exactly as you wrote it up).

Looks like I was editing while you were typing

In testing both, the VesselHasVisited didn't seem to trigger. Using it without the flyby tag caused an error, and with the flyby tag it didn't complete either while the probe was in the mun's SOI (on escape) or after it left.

nightingale · March 29, 2015

Looks like I was editing while you were typing
In testing both, the VesselHasVisited didn't seem to trigger. Using it without the flyby tag caused an error, and with the flyby tag it didn't complete either while the probe was in the mun's SOI (on escape) or after it left.

I'll have to take a look. Can you run a quick test? Get in the desired situation, then save and reload. That might make it trigger and will tell me if the problem is not checking at the right time or something else.

Yemo · March 29, 2015

SequenceNode was obsoleted in in 0.6.7 and will be removed in 1.0.0 as well!! You'll want to replace it with the much simpler completeInSequence attribute. Anyway, there is a way to hide parameters, but only if you use the Sequence parameter to wrap everything. In it you can specify a list of parameters in hiddenParameter: those parameters will be hidden until they are available to be completed. I can probably generalize something like this to work for the completeInSequence flag. If this is something you'd be interested in, raise a GitHub issue and I'll take a look.

Hm, missed that.

I do not like the Sequence Node at all, because of the "fails contract if completed out of sequence".

Eg if I want to define a contract for first landing on the Mun and then returning back to Mun orbit, I can not do that with the Sequence Node.

The vessel will naturally complete the Mun Orbit part before landing on the Mun, which fails the contracts although the player did nothing wrong.

For cleaning up:

It would help a lot if stuff could be shown in the same line.

Eg for this contract parameter:


                PARAMETER
                {
                    name = ReachState
                    type = ReachState

                    targetBody = Kerbin
                    situation = LANDED
                }

It should not show

Vessel State: Incomplete

Destination: Kerbin: Incomplete

Situation: Landed: Incomplete

but rather something like this:

Landed - Kerbin: Incomplete

Actually, besides my time contraints, this is one of the major issues holding me back from making more complex contracts.

Because at the moment this is just too confusing for more complex missions, especially in the in-flight window.

About removing the sequence node, am I correct in assuming that I shoudl rewrite this

    PARAMETER
    {
        name = OrbitKerbinSeqNode
        type = SequenceNode

        PARAMETER
        {
            name = OrbitKerbin
            type = VesselParameterGroup

            define = OrbiterRecovery

            PARAMETER
            {
                name = ReachState
                type = ReachState

                situation = ORBITING
            }
        }
    }

    PARAMETER
    {
        name = LandKerbinSeqNode
        type = SequenceNode

        PARAMETER
        {
            name = LandKerbin
            type = VesselParameterGroup

            vessel = OrbiterRecovery

            PARAMETER
            {
                name = Any
                type = Any

                PARAMETER
                {
                    name = ReachState
                    type = ReachState

                    targetBody = Kerbin
                    situation = LANDED
                }

                PARAMETER
                {
                    name = ReachState
                    type = ReachState

                    targetBody = Kerbin
                    situation = SPLASHED
                }
            }
        }
    }

into that?:

        PARAMETER
        {
            name = OrbitKerbin
            type = VesselParameterGroup

            define = OrbiterRecovery

            PARAMETER
            {
                name = ReachState
                type = ReachState

                situation = ORBITING
            }
        }

        PARAMETER
        {
            name = LandKerbin
            type = VesselParameterGroup

            vessel = OrbiterRecovery

            PARAMETER
            {
                name = Any
                type = Any

                PARAMETER
                {
                    name = ReachState
                    type = ReachState

                    targetBody = Kerbin
                    situation = LANDED
                }

                PARAMETER
                {
                    name = ReachState
                    type = ReachState

                    targetBody = Kerbin
                    situation = SPLASHED
                }
            }

        completeInSequence = true
        }

Edited March 29, 2015 by Yemo

tjsnh · March 29, 2015

Save/Loaded just before, during, and after leaving Mun's SOI. No luck.

PARAMETER
{
    name = VesselParameterGroup3001
    type = VesselParameterGroup
    define = Mun Probe
    PARAMETER
        {
            name = HasCrew3001
            type = HasCrew
            maxCrew = 0
            minCrew = 0
        }
    PARAMETER
        {
            name = VesselHasVisited3001
            type = VesselHasVisited
            targetBody = Mun
            situation = Flyby
        }

}

This however, seems to work fine, so it looks like I'll be using the RS param for now:

PARAMETER
{
    name = VesselParameterGroup3001
    type = VesselParameterGroup
    define = Mun Probe
    PARAMETER
        {
            name = HasCrew3001
            type = HasCrew
            maxCrew = 0
            minCrew = 0
        }

    PARAMETER
        {
            name = ReachState3001
            type = ReachState
            targetBody = Mun
            situation = ESCAPING
            disableOnStateChange = true
        }
}

severedsolo · March 29, 2015

Hm, missed that.
I do not like the Sequence Node at all, because of the "fails contract if completed out of sequence".
Eg if I want to define a contract for first landing on the Mun and then returning back to Mun orbit, I can not do that with the Sequence Node.
The vessel will naturally complete the Mun Orbit part before landing on the Mun, which fails the contracts although the player did nothing wrong.

Try using "hiddenParameter" instead - something like (untested)

PARAMETER
{
    name = Mission1
    type = Sequence
	hiddenParameter = MunOrbit

PARAMETER
{
    name = MunLanding
    type = ReachState

    targetBody = Mun

    situation = Landed

    title = Land on Mun
}

PARAMETER
{
    name = MunOrbit
    type = ReachState

    targetBody = Mun
    situation = Orbiting
}
}

MunOrbit shouldn't appear until after MunLanding has completed - so it can't fail. Thats how I got round this issue for one of my contracts.

Edited March 29, 2015 by severedsolo

Yemo · March 29, 2015

Try using "hiddenParameter" instead - something like (untested)
MunOrbit shouldn't appear until after MunLanding has completed - so it can't fail. Thats how I got round this issue for one of my contracts.

Interesting idea,

but is the parameter also hidden from the in-flight contract description until the previous one is completed?

With complex contracts and especially multiple contract missions, that would lead to a planning/info problem for the player.

severedsolo · March 29, 2015

Interesting idea,
but is the parameter also hidden from the in-flight contract description until the previous one is completed?
With complex contracts and especially multiple contract missions, that would lead to a planning/info problem for the player.

Check out image 2 on the first page of my contract pack: http://forum.kerbalspaceprogram.com/threads/113642-WIP-Contract-Pack-Kerbin-Space-Station

The parameter "Send your Engineer on EVA to fix the panel" is hidden until an engineer is found on KSS, but the player can still see it in the list at the contract screen.

On that subject nightingale - I agree with Yemo, it would be great if all the extra stuff disappeared. If we choose to make use of "title" it probably means we are trying to hide that (and on some parameters it does, on others it doesn't)

So, on my screenshot - all I want to see is "Send an engineer on EVA to fix the panel" the 4 lines underneath (maybe 5? although the timer is probably useful) is irrelevant.

Edited March 29, 2015 by severedsolo

Yemo · March 29, 2015

Nope - the contract in question is actually the 2nd image on the first post from my pack: http://forum.kerbalspaceprogram.com/threads/113642-WIP-Contract-Pack-Kerbin-Space-Station - the EVA repair one. In my case, if an engineer went on EVA before reaching the station, the parameter would fail. So I hid it until I was ready.
"Send your Engineer on EVA to fix the panel" is hidden until an engineer is found on KSS, but the player can still see it in the list at the contract screen.

I m not sure we mean the same thing, if you could confirm?

The parameter is shown in the top right corner in flight mission list?

severedsolo · March 29, 2015

Sorry I misread your post -

All parameters will appear on the mission control screen, but the hidden parameter won't appear on the in-flight contract screen until parameter 1 completes.

Yemo · March 29, 2015

Sorry I misread your post -
All parameters will appear on the mission control screen, but the hidden parameter won't appear on the in-flight contract screen until parameter 1 completes.

Ah, thank you, was just about to try.

@nightingale:

At the moment I do not see an adequate replacement of the SequenceNode.

The completeInSequence hides the fact that the parameter has to be completed in sequence from the player.

The "Sequence" either fails parameters which are completed in the wrong order, or it hides further paramters in flight, which is detrimental to mission planning.

Given those options, I will have to keep the "SequenceNode" in the SETI-Contracts. Anything else would be a functionality devolution.

Because of that, I hope SequenceNode is still supported in 1.0 CC.

nightingale · March 29, 2015

Save/Loaded just before, during, and after leaving Mun's SOI. No luck.
<snip>

I'll look into this one tonight, raised [#165]. For now, let's assume it's broken but will be working as advertised in 0.7.5.

About removing the sequence node, am I correct in assuming that I shoudl rewrite this
{
name = OrbitKerbinSeqNode
type = SequenceNode

PARAMETER
{
name = OrbitKerbin
type = VesselParameterGroup

define = OrbiterRecovery

PARAMETER
{
name = ReachState
type = ReachState

situation = ORBITING
}
}
}

PARAMETER
{
name = LandKerbinSeqNode
type = SequenceNode

PARAMETER
{
name = LandKerbin
type = VesselParameterGroup

vessel = OrbiterRecovery

PARAMETER
{
name = Any
type = Any

PARAMETER
{
name = ReachState
type = ReachState

targetBody = Kerbin
situation = LANDED
}

PARAMETER
{
name = ReachState
type = ReachState

targetBody = Kerbin
situation = SPLASHED
}
}
}
}
    PARAMETER
into that?:
{
name = OrbitKerbin
type = VesselParameterGroup

define = OrbiterRecovery

PARAMETER
{
name = ReachState
type = ReachState

situation = ORBITING
}
}

PARAMETER
{
name = LandKerbin
type = VesselParameterGroup

vessel = OrbiterRecovery

PARAMETER
{
name = Any
type = Any

PARAMETER
{
name = ReachState
type = ReachState

targetBody = Kerbin
situation = LANDED
}

PARAMETER
{
name = ReachState
type = ReachState

targetBody = Kerbin
situation = SPLASHED
}
}

completeInSequence = true
}
        PARAMETER

Yes, but I would take it one step further:

{
name = OrbitKerbin
type = VesselParameterGroup

PARAMETER
{
name = ReachState
type = ReachState

situation = ORBITING
disableOnStateChange = true
}

PARAMETER
{
name = ReturnHome
type = ReturnHome
}
}
        PARAMETER

Using disableOnStateChange allows you to side step all the sequence stuff. ReturnHome is effectively equivalent to the Any (Landed/Splashed) combination you have.

As a general comment, in terms to dealing with these types of issues, the tools I would look at in order are:

The disableOnStateChange flag
Sequencing
Vessel define

Hm, missed that.
I do not like the Sequence Node at all, because of the "fails contract if completed out of sequence".
Eg if I want to define a contract for first landing on the Mun and then returning back to Mun orbit, I can not do that with the Sequence Node.
The vessel will naturally complete the Mun Orbit part before landing on the Mun, which fails the contracts although the player did nothing wrong.

At the moment I do not see an adequate replacement of the SequenceNode.
The completeInSequence hides the fact that the parameter has to be completed in sequence from the player.
The "Sequence" either fails parameters which are completed in the wrong order, or it hides further paramters in flight, which is detrimental to mission planning.
Given those options, I will have to keep the "SequenceNode" in the SETI-Contracts. Anything else would be a functionality devolution.
Because of that, I hope SequenceNode is still supported in 1.0 CC.

If you feel strongly about it, I can keep SequenceNode to allow for more options. The reasoning behind removing it was that it was too verbose, both from the amount of parameters that need to be configured and from a player's perspective.

That being said, looking back failing out of sequence stuff seemed like a good idea at the time, and was borne out of necessity (I didn't have the ability at the time to prevent the child parameter from completing). There isn't anything that I'm aware of that is relying on that behaviour, so I'm going to change the default behaviour NOT to fail for out-of-order completions, but allow it to work that way if some boolean attribute is set to true for the Sequence parameter. Raised [#166] to track. If you get this behaviour, are you okay with SequenceNode getting obsoleted?

For cleaning up:
It would help a lot if stuff could be shown in the same line.
Eg for this contract parameter:
                PARAMETER
                {
                    name = ReachState
                    type = ReachState

                    targetBody = Kerbin
                    situation = LANDED
                }
It should not show
Vessel State: Incomplete
Destination: Kerbin: Incomplete
Situation: Landed: Incomplete
but rather something like this:
Landed - Kerbin: Incomplete
Actually, besides my time contraints, this is one of the major issues holding me back from making more complex contracts.
Because at the moment this is just too confusing for more complex missions, especially in the in-flight window.

On that subject nightingale - I agree with Yemo, it would be great if all the extra stuff disappeared. If we choose to make use of "title" it probably means we are trying to hide that (and on some parameters it does, on others it doesn't)
So, on my screenshot - all I want to see is "Send an engineer on EVA to fix the panel" the 4 lines underneath (maybe 5? although the timer is probably useful) is irrelevant.

So the reasoning behind that is to provide as much player feedback as possible. What I didn't like seeing was stuff in stock like "go to waypoint x and do a science report". Those should be two things, and I'd like to see the player get feedback when they are "halfway" done those types of parameters. Now, with some of these perhaps it can be argued that I've gone overboard. Part of the problem is the teeny tiny stock contracts app - which is the whole reason for Wider Contracts App. Is that alone enough to fix the problem? Should I perhaps start bundling it with Contract Configurator? Let me know what you guys think of that idea...

Otherwise, I'm fine with giving the ability to hide child parameters. It won't be based on title, it'll be it's own flag. [#167] for that one.

Oh and the fact that hidden parameters don't cause the Sequence to fail is unintended. But no matter since I'll be changing it anyway.

Yemo · March 29, 2015

@nightingales revision:

Ah, great, I will change my contract to follow that scheme. It should also cut down on the lines in the contracts description.

@Sequence behaviour:

So the new Sequence would behave like the old SequenceNode in terms of completing parameters in order?

That failing if not in order was the main (only) reason I picked SequenceNode over Sequence, so I could simply run a "replace" through the contract files.

And use what you wrote above under nightingales revision for the less complex ones.

So from my side, there would be no reason to keep Sequence and SequenceNode and I would just convert over.

Though I guess I would need to do that at the same time as the behavious is changed/Contract Configurator is updated?

@flags for hiding:

Flags would be a great addition, so contract makers can decide what people would likely understand from the context.

@WiderContractsApp:

I m generally using ContractsWindow+, but I have to account for people not using that. So integrating WiderContractsApp into ContractsConfigurator would solve that nicely. And it does not seem to take more space than the stock resource panel, while only one of them can be active anyway.

Edited March 29, 2015 by Yemo

nightingale · March 29, 2015

Bleh, the stock flight logger doesn't nearly work as advertised. Doing a flyby is logged as "escaped" (even though you never have to actually escape said body). Doing an actual escape isn't logged. A bunch of other stuff that is supposed to be logged (EVA, Boarding) don't happen either. I may need to scrap it and just look for all those situations myself.

Yemo · March 29, 2015

Bleh, the stock flight logger doesn't nearly work as advertised. Doing a flyby is logged as "escaped" (even though you never have to actually escape said body). Doing an actual escape isn't logged. A bunch of other stuff that is supposed to be logged (EVA, Boarding) don't happen either. I may need to scrap it and just look for all those situations myself.

I know that feeling.

The further you dip into KSP/stock, the more confident you get with squad skipping a proper beta and moving straight to release :confused: .

tjsnh · March 29, 2015

Bleh, the stock flight logger doesn't nearly work as advertised. Doing a flyby is logged as "escaped" (even though you never have to actually escape said body). Doing an actual escape isn't logged. A bunch of other stuff that is supposed to be logged (EVA, Boarding) don't happen either. I may need to scrap it and just look for all those situations myself.

Reminds me of trying to do Civ5 modding. Talk about sloppy APIs ....

nightingale · March 29, 2015

Okay, after thinking about it for a bit, VesselHasVisited is now on the deprecation list. It's not worth my time to rewrite it, as everything in there that currently works overlaps with other stuff (using the disableOnStateChange flag). There's a few that don't work that aren't duplicated, but they either have a way to get something close, or are something I can whip up if someone needs it.

tjsnh - I'd suggest some changes to the parameter you posted earlier:

{
name = VesselParameterGroup3001
type = VesselParameterGroup
PARAMETER
{
name = HasCrew3001
type = HasCrew
maxCrew = 0
minCrew = 0
}

PARAMETER
{
name = ReachState3001
type = ReachState
targetBody = Mun
}
}
PARAMETER

Removed the define - all it really does is pollute the player's savegame.
Removed the ESCAPING situation. What the player has to do is the same - but it's a little less verbose
Removed the disableOnStateChange = as the parent vesselParameterGroup will get met right away, so it won't matter.
If the targetBody on your contract is Mun you can also remove the targetBody (if you like)... keeps things shorter.

tjsnh · March 30, 2015

Okay, after thinking about it for a bit, VesselHasVisited is now on the deprecation list. It's not worth my time to rewrite it, as everything in there that currently works overlaps with other stuff (using the disableOnStateChange flag). There's a few that don't work that aren't duplicated, but they either have a way to get something close, or are something I can whip up if someone needs it.
tjsnh - I'd suggest some changes to the parameter you posted earlier:
Removed the define - all it really does is pollute the player's savegame.
Removed the ESCAPING situation. What the player has to do is the same - but it's a little less verbose
Removed the disableOnStateChange = as the parent vesselParameterGroup will get met right away, so it won't matter.
If the targetBody on your contract is Mun you can also remove the targetBody (if you like)... keeps things shorter.

I'll play around with those tomorrow and see what I can make work, thanks

Yemo · March 30, 2015

I m just rewriting my contracts, when I noticed that the "HasCrew" parameter seems to be bugged.

This is what I used to have a manned 18km altitude contract with return home:


    PARAMETER
    {
        name = OrbitKerbin
        type = VesselParameterGroup

        PARAMETER
        {
            name = HasCrew
            type = HasCrew

            minCrew = 1
        }

        PARAMETER
        {
            name = ReachState
            type = ReachState

            minAltitude = 18000
            disableOnStateChange = true
        }

        PARAMETER
        {
            name = ReturnHome
            type = ReturnHome
        }
    }

While the 18km and returnHome part works, the "HasCrew" is not listed in the right hand side in-flight contract window at launch.

It appears there when the 18km parameter is completed and is instantly checked, even if I m only using a probe to do so.

edit: Hm, has nothing to do with rewriting the contract, the old contract also completes the HasCrew minCrew = 1 for a probe core (maybe using RemoteTech is a problem?).

Edited March 30, 2015 by Yemo

nightingale · March 30, 2015

I m just rewriting my contracts, when I noticed that the "HasCrew" parameter seems to be bugged.
This is what I used to have a manned 18km altitude contract with return home:
    PARAMETER
    {
        name = OrbitKerbin
        type = VesselParameterGroup

        PARAMETER
        {
            name = HasCrew
            type = HasCrew

            minCrew = 1
        }

        PARAMETER
        {
            name = ReachState
            type = ReachState

            minAltitude = 18000
            disableOnStateChange = true
        }

        PARAMETER
        {
            name = ReturnHome
            type = ReturnHome
        }
    }
While the 18km and returnHome part works, the "HasCrew" is not listed in the right hand side in-flight contract window at launch.
It appears there when the 18km parameter is completed and is instantly checked, even if I m only using a probe to do so.
edit: Hm, has nothing to do with rewriting the contract, the old contract also completes the HasCrew minCrew = 1 for a probe core (maybe using RemoteTech is a problem?).

There seems to be something up with this, I'm looking into it.

nightingale · March 30, 2015

This is now fixed, expect to see a new version sometime today.

severedsolo · March 30, 2015

Good job on the module manager support! I love the fact that you can insert parameters/requirements ad-hoc depending on what mods are installed.

Pie in the sky wish - don't suppose there is any way of getting a requirement to only fire if a vessel in orbit has below x resource?

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation