nightingale

I've had that issue when doing searches where it seems to want to get the X oldest posts (for some value of X). Workaround is to date limit your search to last month (or some other appropriate period).

Raised [#40], although it may be a while before I get back to Waypoint Manager.

The define + vessel construct has some limitations, so it should be avoided whenever possible. That's why being able to put the Duration parameter inside the VPG is such a good thing. Some of the problems that can arise in a typical chain of two VPG parameters with the first doing define=someVessel and the second doing vessel=someVessel: If a player gets a vessel defined in the first VPG, and then messes up (lets say they explode the vessel, somehow), then they can't complete the contract. The workaround to this is to set disableOnStateChange=false for the first VPG... but that won't work in this case, as the first VPG would then "uncomplete" when you go out of orbit. I'm not convinced it's always clear to the player what's expected of them. I have the (New) and (TBD) labels that get put in the text to help that along... but I think it's still pretty murky. I think a lot of people also assume that their ship name needs to match the one in the parameter, which is most definitely not true. In fact, the "chaining" ability was really intended for something where a single vessel crosses multiple contracts (example: KSS). I'm not saying don't ever use it this way, as sometimes it really is the way to do something... just use with caution, and prefer other options when they are available. For the specific case of the ReturnHome, the two VPGs has always been the way to do it... I'm hoping to change that with these changes to Duration in the last couple releases, because it'll make more streamlined contracts for a very common use case.

I'll check if I can reproduce it, but logs would help (usually that type of thing means there's some exception spamming in the background). - - - Updated - - - Worked fine on mine - I'll need to see those logs to know what's up on your end.

Yup, that means optional parameters do not work within a VPG. But... I'm gonna say that's working as designed. Because you don't want optional parameters in there - because they can flip on/off based on what ship is selected, the giving the player the opportunity to get the optional reward multiple times. Here's the alternative I would suggest: 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 = ReturnHome type = ReturnHome } } PARAMETER { name = OptionalDuration type = VesselParameterGroup title = (Optional) A longer orbit (1 day) gives extra rewards. rewardFunds = 6250 / @targetBody.Multiplier() rewardScience = 2 / @targetBody.Multiplier() 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 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. } } There's a little bit of duplication, but I don't see a good way to do it otherwise without reverting back to the define/vessel mess.

Yes... but I thought of an exploit/issue that I'll work to fix in 1.7.1. If a player were to get to orbit, wait out the timer, and then fails to return home (let's say he forgets his chute). In that scenario, the Duration parameter would stay checked and the player would be able to launch a follow up mission without having to do the duration portion. Raised [#308] for that. Also - I have no idea if an optional parameter works within a vessel parameter group. Test it and get back to me, and if it doesn't work I'll fix that too.

Heh, I like that I've scared everyone away from doing edits now. Yes for the second one. The first would still require the use of the define and vessel attributes on the two VPGs.

@tjsnh: Have a look at this issue where I discussed a similar contract with NathanKell and made some changes to Contract Configurator in 1.7.0 to make it work *much* more cleanly (without the use of the vessel define).

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]

<Major SNAFU PM'd me a log> I had a look and everything looks okay. What I do see is that one of the contract packs is disabling the stock record contracts (and presumably replacing with its own). From the ones you have loaded I think that it's InitialContracts (from SETI, I think) and Spacetux that *both* do that. Not sure why I don't see any contracts otherwise being offered, although it could simply be that there aren't any available. You can try removing either/both of those two contract packs and see if it changes anything.

The contract is from tjsnh's Advanced Progression Contracts. Are you sure you reverted, versus trying it with another vessel? It looks like you managed to get the contract into an unwinnable state - the vessel it's looking for to meet the second parameter no longer exists, and it won't try to pick a new one because the first parameter is already met. You'll have to cancel the contract and re-accept it. That being said, there's probably a few better ways for this contract to be written that are less error prone. I'd suggest posting on the thread linked above about it (if tjnsh is interested in reworking it I can provide the details to him).

Sorry, I meant "your post has no logs, the logs are what I really need to see." Try Dropbox, Google Drive, or Pastebin (although I believe it has a limit).

No logs... that's all I really need to see.

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.

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.

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).

Actually, Contract Configurator uses Alt-F10, Module Manager uses Alt-F11. Neither of which have a setting to change the hotkey either.

One common cause of a messed up contract system is when the agent loading fails. The most common cause was either agent icons converted to DDS when they shouldn't be, or a bug in Texture Replacer that prevented the agent icons from being properly loaded. It's fixed in the latest version, so if you're using Texture Replacer, update it to the latest. Otherwise, post up a log and I'll take a look.

It's not ideal, but sometimes it's something you have to do when you're revamping stuff. The following will happen: If the player had the contract active, it will immediately fail. If the player had the contract offered, it will silently disappear. 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, 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).

Finally cracked this nut! The fix will be in Contract Configurator 1.7.0, feel free to try out the dev dll in the meantime.

Darn... but the good news is, I've just finally been able to reproduce it (not sure what's different now). I'll play around with it and see if I can get it solved now.

Looking good! I'll be interested to see what the transition from day to night ends up looking like.

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.

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.