nightingale

Contract Configurator 0.7.0 is finally here! Download it now! New contract pack will follow in 2-3 days or so. I think this is probably going to be the biggest release, feature-wise. The biggest change is the full introduction of expressions. I gave a bit of a description in a previous post: What's so great about the expression is you can use them anywhere in the contract definition. With this, Contract Configurator can theoretically do anything that could be done in the standard (C#) method of creating contracts - but much quicker and much easier. The documentation for expressions can be found in two wiki pages: Expression Syntax - Contains the details of the C-like expression syntax. Function Reference Guide - Contains a listing of all functions and methods available. The next version of Contract Configurator is likely going to be numbered 1.0.0 - meaning that it has all the major features that I wanted when I first envisioned it (I started work on Contract Configurator nearly 4 months ago!). This doesn't mean I'll stop working on it, but the focus will be on integrating to more mods, adding new parameters and improving the old ones, and flushing out the expressions to make more classes/functions/methods available. And I'm hoping that the contract packs that I (and others) produce will become more and more varied and interesting. Changes: Support for expressions in config nodes. All config node attributes can now contain expressions (see wiki for syntax details). Added special expression function/methods for Vessel Added special expression function/methods for CelestialBody Added special expression function/methods for Kerbal (ProtoCrewMember) Added special expression function/methods for Lists Added special expression function/methods for Enumerations [*]New debugging window feature - contract balancing mode. [*]Added HasCrewCapacity parameter. [*]Added VesselDestroyed parameter. [*]Added SpawnPassenger behaviour. [*]Added version check to contract groups. [*]Major changes to CollectScience parameter. [*]WaypointGenerate now supports a PQS offset - allows setting waypoint using a special offset from the PQSCity location. [*]Added minTerrainAltitude and maxTerrainAltitude to ReachState. [*]Fixed HasAntenna to work with omnis without having activeVessel attribute set (thanks Eiktyrner). [*]Clean up "Input is null" warning messages from stock. [*]Lots and lots of minor bug fixes.

FYI, the space that you took out of the folder name means that KSP-AVC isn't detecting the updated version. Only way I know of to handle that is to just keep the old directory around in your source tree with an updated .version file for a while until people upgrade.

Alright, fixes to VesselDestroyed are checked in and tested. Note you'll probably want to set the new mustImpactTerrain attribute to true for your contracts.

The expression options for strings are quite limited, as it's more of a symbol replacement than a true expression. But if you leave the name out, it will generate it using the same code that generates names for the survey contracts. Would that be sufficient? If not, I can try to add better expression handling for strings post-0.7.0. Getting the waypoint name into the title is supposed to work, but because it's in a child config node in this case it doesn't. Can you raise a GitHub issue?

No problem, 0.7.0 should be out very soon anyway.

Yeah, I think that same bug is confounding you (I'll be getting on fixing it after CC 0.7.0 is out). Can you try cancelling the contract, and then re-accepting it? You should be able to leave your ship around Jool, although the Monolith itself will probably be in a different orbit and you'll have to re-do the rendezvous.

Been watching this one for a while now, super excited about what I'm seeing! Have you given any thought into contract integration around this stuff? Once you start hitting phase III stuff I think it'd be very cool to have a series of contracts to help step players through the processing flow. (Obviously I have some interest in the contract area...)

That is a sweet V2 rocket launcher!

Correct, won't take long once I'm able to sit down and look at it tonight.

Good stuff, leaving this here for myself to fix it tonight - looks like they look at a couple different game events than what I picked. Just another thing pushing out 0.7.0 slightly.

Right, that's what I had thought: You could also put parameters around on the speed - since I'd think that would be something that they'd want to control when doing an impact test. You can then tweak it so that it conventiently keeps them into one situation or the other (or just makes it so the situation just doesn't matter.

I'll try to test it out tonight. I have no idea what order stuff happens in - whether you get marked as LANDED and then explode or the other way around (and also if it's even reliable). An interesting alternative would be to use a waypoint and force the player to crash into a specific spot.

Raised [#4] on GitHub, I'll look into it. When I tested them out, the underground one was at the bottom of a deep hole. Not sure if the terrain detail perhaps plays a role? Same thing with the floating one, I remember it being one of the ones that was perfectly placed. Were you able to complete the contract by flying up to it?

And I'm expecting to get 0.7.0 out tonight or tomorrow, so there won't be too long to wait on this.

Good stuff, congrats on the release!

It's the altitude above "sea level" (the same thing the altimeter displays). Raised [#144] on GitHub to add separate attributes for terrain altitude.

Hmmm.... nothing particularly useful in the log. Can you turn on debug? I'd also want you to add this to the logging cfg file: ADD_LOGLEVEL_EXCEPTION { // Type name type = [COLOR=#795DA3][FONT=Consolas]VesselDestroyed[/FONT][/COLOR] // Possible LogLevel: VERBOSE, DEBUG, INFO, WARNING, ERROR logLevel = VERBOSE } Unrelated to your issue, but be careful with that EnterSOI parameter. It's not a Vessel parameter, which means that it will get met when ANY vessel goes to the Mun (not necessarily the one that meets the rest of the parameters). I may need to revisit and deprecate some of those older ones, they don't seem so useful anymore. Anyway, you probably want ReachState instead.

It does indeed.

Nah, the typo wouldn't affect the parameter. The problem is that the Vessel: Minmus (new) and Vessel: Minmus Flyby don't match. Another way you can do this tjsnh, would be to include the ReturnHome parameter in the same VesselParameterGroup and give it (ReturnHome) the completeInSequence=true attribute.

Making it work with multiple targetBody attributes (see below). What you have there expands to: PARAMETER { name = ReachState3001 type = ReachState targetBody = Mun targetBody = Minmus situation = SUB_ORBITAL } Which errors because you're only allowed one targetBody. It would be a lot more work to expand it in the way you're thinking, but would also result in question about how to expand something like this: PARAMETER { name = ReachState3001 type = ReachState targetBody = HomeWorld().GetChildren() situation = [SUB_ORBITAL, ORBITING, LANDED] }

VesselIsType should be working. If it says NEW in the wiki it was introduced in 0.6.x. If it says coming soon it'll be for 0.7.0. Cool! Can't wait to see what you come up with!

Oh I see.... looks like it's assigning the Kerbal far too early! I'll make it so it just switches whenever you EVA, so you can use whoever (which is more what was intended). Raising a GitHub issue...

First, just FYI you're using syntax from 0.7.0 - so that won't work in the release version (0.6.7). But not to worry... release is coming very soon. Anyway, it doesn't quite work like that for the first one - that would be a little too magical. There are a couple parameters where you can specify the same tag multiple times, but that isn't one of them. The main problem being that I don't currently have an easy way to show akward combinations, such as (altitude > 1000 && (targetBody == Minums || targetBody == Mun)). Another option is to have targetBody = HomeWorld().GetChildren().Random(). That will only give you one or the other - but at random (one contract may have Mun, another may have Minmus). - - - Updated - - - Hmm, maybe that wouldn't be such a bad thing. I'm calling it too late for 0.7.0, but I'll raise an issue on GitHub to look at this for the next version.

You're using the wrong version! The release version (0.6.7) doesn't support expressions. The new version (0.7.0) is coming out in the next couple days with support for that. There's a pre-release version (0.6.90) from a couple days you can look at if you want to try it out early.

For that, have a look at the deadline attribute on the CONTRACT_TYPE node. - - - Updated - - - The general philosophy for Contract Configurator has been that each parameter should do only one thing (although in recent versions some of the parameters have becoming quite big, but that's another story). So for what you're looking for, I'd suggest something like this: [COLOR=#3E3E3E]PARAMETER [/COLOR]{ name = VesselParameterGroup type = VesselParameterGroup PARAMETER { name = ReachState type = ReachState targetBody = Mun [COLOR=#333333][FONT=Consolas]situation = SUB_ORBITAL[/FONT][/COLOR] } PARAMETER { name = VesselDestroyed type = VesselDestroyed completeInSequence = true } } Key points: ReachState allows you to set conditions for the speed, altitude, body, biome and/or situation. The completeInSequence attribute means "don't allow this parameter to complete until all the ones above it are complete. Be careful if you use the SUB_ORBITAL situation like I do in this example. If you crash, I have no idea what happens first - the situation changing to LANDED or the vessel being destroyed. Also, if you aim at the ground fast enough, I think you may also be able to get a collision course with the situation of ESCAPING. Things to consider in your design.