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

[Nori]

You'll want to be careful with putting that type of stuff under the contract group - you may want to consider using requiredValue = false:

[TABLE=width: 640]

[TR=bgcolor: #F8F8F8]

[TD=align: left]requiredValue[/TD]

[TD=align: left](Optional, default = true) If true, the expression needs to return a valid (non-null) value for the contract to be offered. If false, the contract will be offered even if the expression returns null[/TD]

[/TR]

[/TABLE]

What that doesn't say is it'll also fail if a list of values is empty. So because that node is in the group, it applies to all contracts within that group.

Ok, thanks. I will look at that some more..

To give you some color on why I'm doing that crazy stuff.. I think I mentioned that I'm working on a planet pack agnostic progression pack. Since it relies on logical progression I wanted to require certain contracts to be completed before you progress. That isn't a issue for many contracts, but I have several that could never show up if added to a existing game because of some planet checking that I do.

For instance:

    DATA
    {
        type = CelestialBody
		activeUniqueValue = true
        validTarget = AllBodies().Where(cb => cb.SemiMajorAxis() < @/smamax && cb.SemiMajorAxis() > @/smamin && cb.IsPlanet() && cb.HaveReached() == false && cb.IsHomeWorld() == false).Random()
    }

That beauty will not fire if they have reached those planets (in stock this would apply to Duna/Eve) before they install the pack. This contract is supposed to be used as a stepping stone for other planets via the required contract.

I suppose ideally I could say it needs to be installed in a new save.... But you know how people are...

Any ideas on what I can do here? Maybe I could use your new dialog boxes to fire after a contract and ask the user if they have visited xyz.. :/

Not sure. But I have spent way too much time on this specific issue.. You know the whole 10% take 90% of your time...

~Ninja Edit:

Tried the duration but it appears that the in sequence isn't working right:

	PARAMETER
	{
		name = Orbit
		type = VesselParameterGroup
		define = Orbiter
		title = Orbit @targetBody
		completeInSequence = true
		duration = 60m

		PARAMETER
		{
			name = NewVessel
			type = NewVessel
		}

		PARAMETER
		{
			name = HasCrew
			type = HasCrew
			minCrew = 1
		}

		PARAMETER
		{
			name = Orbit
			type = Orbit
			minPeA = @targetBody.AtmosphereAltitude() * 1.1
		}


	}

	PARAMETER
	{
		name = Home
		type = VesselParameterGroup
		vessel = Orbiter
		title = Optionally orbit for 1d, or just return home.
		completeInSequence = true

		PARAMETER
		{
			name = Orbit
			type = Orbit

			minPeA = @targetBody.AtmosphereAltitude() * 1.1
		}

		PARAMETER
		{
			name = Duration
			type = Duration
			duration = 1d
			optional = true
			notes = (Optional) A longer orbit (1 day) gives extra rewards.

			preWaitText = Orbiting for a additional day will provide us with some valuable data.
			waitingText = One more day should do.
			completionText = Excellent, this will be very helpful.
			rewardFunds = 6250 / @targetBody.Multiplier()
			rewardScience = 2 / @targetBody.Multiplier()
		}


		PARAMETER
		{
			name = ReturnHome
			type = ReturnHome
		}
	}

The first VesselParameterGroup is supposed to be completed before the second one can be started.

Edited August 25, 2015 by Nori

[nightingale]

That beauty will not fire if they have reached those planets (in stock this would apply to Duna/Eve) before they install the pack. This contract is supposed to be used as a stepping stone for other planets via the required contract.

That's a tough one. Your only choices that I can really see are the "don't use on existing save" or to change the later contracts to not be based on contract progression, but on other attributes (ie. make them available if the player has done a flyby of the planet but not a landing).

Any ideas on what I can do here? Maybe I could use your new dialog boxes to fire after a contract and ask the user if they have visited xyz..

Right now the dialog boxes are pretty one-way. Eventually the player will be able to answer "multiple choice" questions (and have the answer stored somewhere), but that probably won't be in 1.7.0.

Tried the duration but it appears that the in sequence isn't working right

I'll test this out and get back to you.

[Nori]

That's a tough one. Your only choices that I can really see are the "don't use on existing save" or to change the later contracts to not be based on contract progression, but on other attributes (ie. make them available if the player has done a flyby of the planet but not a landing).

Right now the dialog boxes are pretty one-way. Eventually the player will be able to answer "multiple choice" questions (and have the answer stored somewhere), but that probably won't be in 1.7.0.

Hmm, well the crux of the expression is that it acts as a sort of requirement which I'm really liking.

I can't think of a simple way to check if they have done say a flyby without duplicating the DATA nodes across contracts.

Below is the DATA nodes I'm using for a set of contracts. These contracts are supposed to be completed before the next set.

Haven't thought of anyway to easily check if the planets this applies to have been reached, but the contract hasn't been completed. Might just be easier to say use on new saves..

	DATA
    {
        type = bool
        homeIsPlanet = HomeWorld().Parent() == Sun
    }

    DATA
    {
        type = double
        sma = @homeIsPlanet ? HomeWorld().SemiMajorAxis() : HomeWorld().Parent().SemiMajorAxis()
		smamin = @/sma * 0.5
		smamax = @/sma * 1.6
    }

    DATA
    {
        type = CelestialBody
		activeUniqueValue = true
        validTarget = AllBodies().Where(cb => cb.SemiMajorAxis() < @/smamax && cb.SemiMajorAxis() > @/smamin && cb.IsPlanet() && cb.HaveReached() == false && cb.IsHomeWorld() == false).Random()
    }

[nightingale]

Okay, I see what you mean with the duration stuff. That's a bit of a tricky one since the vessel checks happen on VesselParameterGroup, and aren't done until all the child parameters are met. So about the only suggestion I can think of here is to just make your 1 day check into 1 day + 1 hour to make the numbers right.

- - - Updated - - -

Hmm, well the crux of the expression is that it acts as a sort of requirement which I'm really liking.

I can't think of a simple way to check if they have done say a flyby without duplicating the DATA nodes across contracts.

Below is the DATA nodes I'm using for a set of contracts. These contracts are supposed to be completed before the next set.

Haven't thought of anyway to easily check if the planets this applies to have been reached, but the contract hasn't been completed. Might just be easier to say use on new saves..

Yeah, there isn't a way that I can think of, because CompletedContract just looks at count, you can't say "Completed this contract for Duna". You probably need the changes in [#296], which would allow you to use an expression BEHAVIOUR to store the planet the contract was for or something... even then I'm not sure if that actually solves your issue here.

If it's going to be that complex, I vote for "new save". It's pretty hard to do a contract pack that is centered around progression, but then allow the player to start halfway through.

[Nori]

Okay, I see what you mean with the duration stuff. That's a bit of a tricky one since the vessel checks happen on VesselParameterGroup, and aren't done until all the child parameters are met. So about the only suggestion I can think of here is to just make your 1 day check into 1 day + 1 hour to make the numbers right.

- - - Updated - - -

Yeah, there isn't a way that I can think of, because CompletedContract just looks at count, you can't say "Completed this contract for Duna". You probably need the changes in [#296], which would allow you to use an expression BEHAVIOUR to store the planet the contract was for or something... even then I'm not sure if that actually solves your issue here.

If it's going to be that complex, I vote for "new save". It's pretty hard to do a contract pack that is centered around progression, but then allow the player to start halfway through.

So duration doesn't respect the complete in sequence option? Huh, ok I'll just add extra time.

Thanks for looking into it.

Yeah, you've sold me. New or early saves it is. Technically it won't start breaking till you've at least orbited both the Mun Minmus. So that gives a bit of a window.

[nightingale]

So duration doesn't respect the complete in sequence option? Huh, ok I'll just add extra time.

Thanks for looking into it.

Pretty much, yeah. Complete in sequence is a bit of a hack - it just generically prevents a parameter from getting a checkmark. I've had other issues with it where the parameter wouldn't get its checkmark after the other prerequisites were met (I think that's fixed now though). I could possibly make Duration aware of it, but it still wouldn't help you as it would need to look at the PARENT parameter...

Maybe there is a way. I've got a bit of a cold and it's late here, so my head is cloudy - raised [#302] and I'll think more clearly through the implications tomorrow.

[nightingale]

Nori, a heads up for you - I did the change that I raised above, but I actually did another one under [#304] that may be more suitable for what you're doing (have a look at the example contract in the issue - that should be very similar to what you're trying to do).

[Nori]

Yah! All my wishes are coming true! Take that duration, you will no longer be autonomous (well sometimes)!

Edit: FYI, this is pretty much the best thing that has happened all day. Since the rest of the day has been extremely frustrating (I hate Office 365 deployment tool...).

Edited August 25, 2015 by Nori

[Nori]

Is it bad to remove a contract that was already in a save?

[nightingale]

Is it bad to remove a contract that was already in a save?

It's not ideal, but sometimes it's something you have to do when you're revamping stuff. The following will happen:

1. If the player had the contract active, it will immediately fail.
   
2. If the player had the contract offered, it will silently disappear.
   
3. If the player had the contract completed, it'll still be in the completed list, but CC will throw a warning in the log saying "I don't really know what this is".
   

[Nori]

Cool. More or less what I thought, but wanted to be sure it wasn't too bad.

[nightingale]

New release out, download now! Note that this is a pretty big release, and I'm not sure how much time I'll be able to devote to bug-fixing over the next day or two, so I'm putting this one up as a pre-release. If there isn't any major issues reported over the next couple days I'll turn this into a full release.

Some pretty cool additions in this one, but there's two I want to highlight:

Dialog Boxes

I'm pretty stoked about this feature, as it'll be a prominent part of my next contract pack. Actually, severedsolo is also making a contract pack that I believe will be using this one a lot... so it'll be a race to see who gets something out with these first. The dialog boxes support animated Kerbal heads, text, and images.

Better Persistent Data Store Logic

Way before there was support for expression within contracts, I had introduced the notion of the Persistent Data Store. The idea was that it was a generic place to store data within the save game. However, I never really gave much in the way of the ability to interact with it (the only way to get stuff in was with the Expression Behaviour, which only worked for the double data type).

Well, now the Expression Behaviour supports all data types (you can specify the data type in the config), and the value can be retrieved anywhere in the contract with the $ symbol. For example:

[COLOR=#333333][FONT=Consolas]// Values can be stored in one contract
[/FONT][/COLOR]CONTRACT_TYPE
{
    BEHAVIOUR
    {
        type = Expression

        CONTRACT_COMPLETED_SUCCESS
        {
            type = CelestialBody
            theBody = Duna
        }
    }
}

// ... and referenced in another contract
CONTRACT_TYPE
{
    targetBody = $theBody
}

This will probably get extended further in a future release to add multiple choice selections (see [#297]) to the aforementioned dialog boxes. This would allow you to prompt the player to make some choice, and then change a future contract based on that choice.

Contract Configurator 1.7.0

• New DialogBox behaviour for creating rich text dialog boxes with images.
  
• New CopyCraftFile behaviour to reward a player with a craft file.
  
• New DestroyVessel behaviour to destroy a vessel.
  
• New RecoverVessel parameter.
  
• Support in WaypointGenerator for underwater waypoints.
  
• Duration parameter can now be used as a child of some parameters.
  
• Duration parameter now respects the vessel filter in VesselParameterGroup.
  
• Expression behaviour can now store data for types other than double.
  
• Data can now be retrived from the persistent data store in expressions using the $ symbol.
  
• Improved casting between string and VesselIdentifier (thanks Nori).
  
• Made ChageVesselOwnership onState values consistent with other behaviours.
  
• Added Crawlerway into list of KSC biomes for contracts (thanks Rokanov).
  
• Fixed issue with grandparent contract groups not being recognized properly for expressions (thanks Rokanov).
  
• Fixed issues spawning vessels with the deferredVesselCreation flag (thanks Enceos).
  
• Fixed exception in HasCrew when referencing a Kerbal that hasn't yet been spawned (thanks severedsolo).
  

Edited August 26, 2015 by nightingale

[Superfluous J]

Oh man this is big for my pack. I was not happy about not giving the player some control of where in the system you can find the parts to scavenge. Now I can use variables to store where the player has been and then use those to generate new contracts.

[nightingale]

Oh man this is big for my pack. I was not happy about not giving the player some control of where in the system you can find the parts to scavenge. Now I can use variables to store where the player has been and then use those to generate new contracts.

Depending on exactly what you were looking to do that's possible even in 1.6.x. You could do something like:

targetBody = AllBodies().Where(cb => cb.HaveLandedOn()).Random()

Which would set the target to a random body that the player has landed on.

Of course, if you meant something more like "bodies that the player has already scavenged on", then you'd probably need the new data store variable system.

[Superfluous J]

Of course, if you meant something more like "bodies that the player has already scavenged on", then you'd probably need the new data store variable system.

What I want is but a bit more involved I've ordered all locations in the game by dV and certain parts will only be found in a small subset of those places. The highest-tier parts will require the most dV, for instance. However, I only want to offer them up in places that the player has shown interest in (by going there). That way, you won't be offered to pick up (many) things landed on Eeloo when you've sent your scavengers to orbit Laythe.

[severedsolo]

As much as I'd love to have the honour of releasing the first story based contact pack, I don't think I'll beat you. I'm not sure where it's going yet, and I still need to do the artwork!

Knowing my art skills, you'll probably end up with stick kerbals

Also, dialogue boxes are awesome, and everybody should check them out. My favourite use so far, is giving the player clearance to take off (plane missions etc)

Edited August 26, 2015 by severedsolo

[nightingale]

As much as I'd love to have the honour of releasing the first story based contact pack, I don't think I'll beat you. I'm not sure where it's going yet, and I still need to do the artwork!

Knowing my art skills, you'll probably end up with stick kerbals

Also, dialogue boxes are awesome, and everybody should check them out. My favourite use so far, is giving the player clearance to take off (plane missions etc)

Heh, too bad - it could've been another space race. But you never know - I've got a lot of code stuff I need to play around with before I get deep into the contract pack, so it may be a while yet.

[Ald]

Doing as asked:

Question is - should I be worried? D:

I was messing around in VAB on 1.6.6 version. Misplaced one part and had a huge flow of errors in my debug menu connected with Kerbal Construction Time. So I switched scenes to Tracking station via QuckGoTo and back to VAB. Then I had this message for the first time. So I closed my game, reverted to a backup save and updated the Contract Configurator to latest version shown in KSP-AVC. I know it is a pre-release, so bugs may happen. I'm just informing as stated in the error info

I'll check if going back to 1.6.6 and old save will solve the problem.

Edited August 26, 2015 by Ald

[nightingale]

Doing as asked:

http://i.imgur.com/eL8CJLJ.png

Question is - should I be worried? D:

I was messing around in VAB on 1.6.6 version. Misplaced one part and had a huge flow of errors in my debug menu. So I switched scenes to Tracking station via QuckGoTo and back to VAB. Then I had this message for the first time. So I closed my game, reverted to a backup save and updated the Contract Configurator to latest version shown in KSP-AVC. I know it is a pre-release, so bugs may happen. I'm just informing as stated in the error info

I'll check if going back to 1.6.6 and old save will solve the problem.

This is related to a change in 1.7.0 and is definitely a bug. This is why I did it as a pre-release.

Raised [#307]

[Ald]

I did mess up my description. Of course I had this message AFTER upgrading to 1.7.0. That other issue was around KCT so don't mind it.

After rolling back to 1.6.6 and an old save copy everything is fine. Anyway I'm happy I could help

[magico13]

That other issue was around KCT so don't mind it.

I'm curious as to what that was, btw, so feel free to post logs in the KCT thread if you want any help with that

[Ald]

Sadly I didn't copy that log when it happened. Long story short: After purging the list of stored parts and doing some modifications in VAB on a previously edited craft a error struck (Don't remember the details, but it scared the hell out of me about save corruption). If I'll manage to replicate that situation, I'll post it in KCT topic for sure.

Edited August 26, 2015 by Ald

[magico13]

After purging the list of stored parts and doing some modifications in VAB on a previously edited craft a error struck

Are you using any Procedural Parts mods? I think there might be an issue with them and clearing the part inventory (but it should have been fixed/averted in 1.2.1). If you do see it again, please let me know as I haven't seen any reports like that before. Thanks

And now I'll let the conversation switch back to your regularly scheduled Contract Configurator.

[severedsolo]

Heh, too bad - it could've been another space race. But you never know - I've got a lot of code stuff I need to play around with before I get deep into the contract pack, so it may be a while yet.

Speaking of, I have a working (but unfinished) prototype if anyone is interested in jumping into the thread with suggestions. The images are just placeholders at the moment, but the contracts basically work.

Edited August 26, 2015 by severedsolo

[Nori]

Now that I have polluted the other thread with duration stuff.. Figured I should drop this here.

Based on what I read, I'm changing from this:

	PARAMETER
	{
		name = Orbit
		type = VesselParameterGroup
		define = Orbiter
		title = Orbit @targetBody
		completeInSequence = true
		duration = 60m

		PARAMETER
		{
			name = NewVessel
			type = NewVessel
		}

		PARAMETER
		{
			name = HasCrew
			type = HasCrew
			minCrew = 1
		}

		PARAMETER
		{
			name = Orbit
			type = Orbit
			minPeA = @targetBody.AtmosphereAltitude() * 1.1
		}


	}

	PARAMETER
	{
		name = Home
		type = VesselParameterGroup
		vessel = Orbiter
		title = Optionally orbit for 1d, or just return home.
		completeInSequence = true

		PARAMETER
		{
			name = Orbit
			type = Orbit
			minPeA = @targetBody.AtmosphereAltitude() * 1.1
		}

		PARAMETER
		{
			name = Duration
			type = Duration
			duration = 1d
			optional = true
			notes = (Optional) A longer orbit (1 day) gives extra rewards.

			preWaitText = Orbiting for a additional day will provide us with some valuable data.
			waitingText = One more day should do.
			completionText = Excellent, this will be very helpful.
			rewardFunds = 6250 / @targetBody.Multiplier()
			rewardScience = 2 / @targetBody.Multiplier()
		}

		PARAMETER
		{
			name = ReturnHome
			type = ReturnHome
		}
	}

To this:

PARAMETER
	{
		name = Orbit
		type = VesselParameterGroup
		title = Orbit @targetBody

		PARAMETER
		{
			name = NewVessel
			type = NewVessel
		}

		PARAMETER
		{
			name = HasCrew
			type = HasCrew
			minCrew = 1
		}

		PARAMETER
		{
			name = Orbit
			type = Orbit
			minPeA = @targetBody.AtmosphereAltitude() * 1.1
		}

		PARAMETER
		{
			name = Duration
			type = Duration
			duration = 1d
			optional = true
			notes = (Optional) A longer orbit (1 day) gives extra rewards.

			preWaitText = Orbiting for a additional day will provide us with some valuable data.
			waitingText = One more day should do.
			completionText = Excellent, this will be very helpful.
			rewardFunds = 6250 / @targetBody.Multiplier()
			rewardScience = 2 / @targetBody.Multiplier()
		}

		PARAMETER
		{
			name = ReturnHome
			type = ReturnHome
		}
	}

Seem good?