nightingale

I'll get 0.7.6 out with a fix ASAP. - - - Updated - - - Hot fix up! Download it now! Contract Configurator 0.7.6 Fix a save load issue with the Sequence parameter in 0.7.5 (thanks superm18).

Tons of little bug fixes and new stuff for modders. Download it now! Contract Configurator 0.7.5 Possible fix for duration counters resetting (thanks dorin6565 and many others). Fix for HasCrew with count > 0 (thanks Yemo). Fix for undefined vessels showing up in Tourism contracts (thanks Kaa253). Improvements to tracking across docked vessels. SpawnPassengers now only spawns passengers on Kerbin (closes EPL exploit). Sequence parameter no longer fails if child parameters complete out of order. Added hideChildren attribute to contract parameters to hide children. Added requiredValue attribute to DATA nodes. Added CelestialBody(), Kerbal() and Vessel() functions to expressions. Added resources to expressions. Debug window now highlights items with warnings in yellow. Obsolete EnterOrbit. Obsolete EnterSOI. Obsolete LandOnBody. Obsolete VesselHasVisited. Minor bug fixes.

5thHorseman just put together an absolutely fantastic preview video of Anomaly Surveyor. Click here to go check it out (it's now featured on the first post of this thread). Once you've watched it, there's a few things you can do to show your appreciation: Give him some rep on the linked post! Go to his youtube channel and subscribe! Kneel before him and bask in reflected magnificence!

Wow, this is absolutely amazing! This is going to go straight on to the Anomaly Surveyor first post.

That expression is questionable - it won't know that targetVessel is a vessel, so it'll read as a double and get 0.0. Under the development version, this should work: expression = Vessel(targetVessel).IsOrbiting() Speaking of which, release pushed to tomorrow... just too much pain in getting docking working. I think I've got it right, but it needs a bit more testing.

Should be relatively easy if you're okay with handling it via expressions. Raised [#171] to track (you want this for 0.7.5, I assume?). Taking a wild guess at what your required use case is (refuelling the station?), you could do something like this: DATA { type = Vessel targetVessel = [ LKOStation ].Where(v => v.ResourceQuantity(Karbonite) <= 100).First() } What that would do is if LKOStation has less than 100 Karbonite (or whatever you choose), it'll be the targetVessel, otherwise targetVessel will be null. Since the default is to disallow contracts when any DATA element is null, the effect is the contract only gets offered when in the low Karbonite situation. That work for you? - - - Updated - - - Actually, it was a pretty quick change, so I just went ahead and threw it in. Let me know if it doesn't work as advertised.

The contract shouldn't come up at all if you don't have a valid target (no stations in orbit of Kerbin, or not enough room to accommodate tourists). Also, even if you were to change it from station to base after the contract is offered, it should still work. However, docking does fun things to vessels in KSP (ie gives them new identifiers), so I suspect that may be the real issue here. I'll have to dig into it. Raised [#170] on GitHub to investigate.

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

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

Alright, I've gotten this one on and off for a couple weeks now (across various contract packs), so something's obviously amiss with that timer. Raised [#168] to get to the bottom of this.

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.

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'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. 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 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? 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.

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.

They used to be one mission, but were split into two. It's definitely possible to meet both at once (which is why the rewards for the second one are pretty slim). It's for people who want to set up a Kerbin network that doesn't point to the Mun/Minmus - such as those playing mods with longer progression to get to the Mun.

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

Okay everyone, I'm going to be doing some cleanup in preparation for the Contract Configurator 1.0.0 release. This means that I'm planning on removing parameters from the very first release (where everything was just a wrapper to stock stuff) in favour of other stuff. There should be no loss of functionality - as everything that's being removed is redundant. Here's the plan, please let me know if anyone has concerns over any of this: [TABLE=width: 0] [TR] [TD]Parameter[/TD] [TD]0.7.5[/TD] [TD]1.0.0[/TD] [TD]Notes[/TD] [/TR] [TR] [TD]EnterOrbit[/TD] [TD]Obsolete[/TD] [TD]Removed[/TD] [TD]Use VesselHasVisited, Orbit or ReachState instead.[/TD] [/TR] [TR] [TD]EnterSOI[/TD] [TD]Obsolete[/TD] [TD]Removed[/TD] [TD]Use VesselHasVisited, Orbit or ReachState instead.[/TD] [/TR] [TR] [TD]LandOnBody[/TD] [TD]Obsolete[/TD] [TD]Removed [/TD] [TD]Use VesselHasVisited, Orbit or ReachState instead.[/TD] [/TR] [/TABLE]

Go for it! That page needs some updates, but it's still generally correct. The requirements one shouldn't haven anything wrong. Send me a pull request when you're done and I'll include it in the next release.

Ah, yup, I can see what that wouldn't work. It doesn't know that it's a vessel you're looking for. I'll have to give it some more thought, but I'll fix the more important issue of fixing the definied vessels for docking/undocking/destroying/etc.

Try this, (untested): [COLOR=#333333][I]expression = LKOStation.IsOrbiting()

For tjsnh - The EnterSOI parameter you're using is the problem. It's not a VesselParameter, so it'll get met when any vessel goes in the Mun/Minmus SOIs (even if it's different vessels). tjsnh - I'd suggest moving the ReturnHome parameter into the same VesselParameterGroup as the other things, and giving it the completeInSequence=true flag. You can then remove the define attribute. That should simplify this contract and make it work more reliably.

I've added this to [#158] to track. You, linuxgurugamer and tjsnh are making pretty heavy use of the vessel tracking, especially your station contracts. So I'm going to make the changes under 0.7.5 instead of waiting for 1.0.0. Hopefully this'll mean your fallback logic won't be needed anymore. So one interesting thing about the data node that I think I forgot to document is that if the value is null, it will be like an unmet requirement. It's done that way so you could have something like: DATA { type = Vessel targetVessel = AllVessels().Where(v => v.IsOrbiting() && v.CelestialBody() == @/targetBody).Random() } ... and if no vessels match the criteria, no contract should be offered. So I would've expected the contract to never have its requirements met in your case. So if you could give me the whole contract it'll help me debug this (although I may be able to with just that block).

Oh, that's not so bad - I was thinking it was a thrown exception, not just an error message.

Which looking at his log, he doesn't appear to have installed. Which basically means removing any mod that uses a scenario module will break saved games. Nice... And yeah, I have a scenario called "PersistentDataStore", that I doubt anyone would be able to figure out in a similar situation.

Try this (I haven't tested, but should work): !myVessel.IsOrbiting() ! - reverses the conditional statement myVessel - the name/tag of the vessel IsOrbiting() - Function to check if the given vessel is orbiting, takes no parameters (see wiki)