nightingale

Can you provide logs?

That would be more like pulling a Linux (for many years the Linux kernal used odd numbers for development releases and even ones for stable, which is what DMagic's doing here).

Here's one of the things that's been taking me a while to get right in the new Contract Pack... almost there, just a few more Krakens to slay.

Contract Configurator 0.6.0 is out! The contract pack for this release will be a bit late... but what's holding it up isn't stuff that affects Contract Configurator itself, so I figured I'd get that release out now. Download it here! ​Contract Configurator 0.6.0 Added SpawnVessel behaviour. Added ExperimentalPart behaviour. Added Docking parameter. Added TargetDestroyed parameter. Added VesselNotDestroyed parameter. Added VesselIsType parameter. Added SCANsatLocationCoverage requirement. Added Message behaviour. Add situation filter to Orbit parameter. Support for VALIDATION node in PartValidation to allow more terse validation for specific part recipes on a ship. Added CONTRACT_GROUP and extra logic for limiting contracts based on group. SCANsat coverage parameter now displays the current scan percentage. Improvements to HasPassengers (loads real passengers!) Fix to how contract expiry is handled - setting to 0.0 will now give a contract that never expires, similar to the way the deadline works. New debugging window that shows the underlying configurator and allows selectively disabling parts of the contract for testing. Can now add REQUIREMENT nodes as children to PARAMETER nodes. Performance fixes for requirement checks. Remove parameters that have been obsolete since Contract Configurator 0.5.0. Biggest major feature was huge additions to the debugging window (alt-F10): It gives the ability to: view the contract types and the all parameters, behaviours and requirements temporarily disable parts of the contract (useful for disabling requirements for testing) view the underlying ConfigNode details view the error/warning messages related to loading the contract type/parameters/behaviours/requirements I'll need to update the screenshot, as it also shows a summary of how many contracts succeed loading out of the total. There's the ability to view all contracts and the parameters within them, Lots of other little changes, so play around with all the new stuff. Happy contracting!

Yeah, sounds like something went wrong in those contracts, and they buggered up the whole system. Don't think it's a problem specific to 0.5.12, but unfortunately there's not much to go on - the logs you provided weren't much help in this case. Best I can say is to keep an eye out for this type of behaviour and throw the logs my way if you ever see it again.

It'll definitely cause problems with Contract Configurator. The stock app *never* refreshes the titles unless it gets a OnParameterChanged event (or a couple others). However, if those OnParameterChanged events queue up when the app is closed, it'll refresh itself fully (all contracts) for each event once it is opened (which I've seen cause lag anywhere from a couple seconds to 2-3 minutes where the screen is frozen). As such, I limit my use of OnParameterChanged (and can't use it for something like a simple title update). So I wrote code that finds the underlying GUI elements and changes their labels directly when a title changes, which is a horrible and ugly hack. For Contracts Window+, if you provide some sort of hook where I can call in to say a specific parameter has changed its title, I can add a call via reflection to that wherever I do my current hack for the stock app. That won't cover everything (as I rely on the fact that the stock app resets completely if one parameter changes), but it should catch 90% of the stuff in Contract Configurator.

Well, what I did is I included the monolith part (with permission) in the upcoming contract pack. I built a vessel using it, and created it in-game using the SpawnVessel behaviour (new for 0.6.0). For the Vertical Propulsion Emporium you'd ideally want to use module manager to make VPE a dependency on your contracts loading. With that you can just assume it's there and use their parts in PartValidator or in vessels for SpawnVessel with impunity.

That was not expected at all - I assume you went from 0.5.11 to 0.5.12? There really was very little that changed. Is it possible that you started up KSP with 0.5.11 and SCANsat 10 before 0.5.12 was out or before you updated? That I can see causing problems. Not my model - comes courtesy of Nicholander - see this thread. So if you want to change it (or have someone else change it), then he's your man. ReachSituation will still work... for now. It will likely disappear in 0.7.0, so stop using it! Changing to ReachState is easy - just rename the parameter, since ReachState supports all the attributes from the parameters it replaces. - - - Updated - - - Also, for Kedwin Hubble - any chance you can provide logs?

Contract pack for the new version is taking a bit longer than originally anticipated, since there's a little bit more scripting for the end scene. But it'll be worth it, I promise!

Quick release with a fix for the new SCANsat (caused by bad in-built dependency checking in KSP). Download it now! Contract Configurator 0.5.12 Fixed KSPAssemblyDepdency issue indirectly caused by SCANsat (but due to broken dependency checking logic in KSP).

Wow, that's a lot of techs... now if only someone can go and figure out how to get the nice descriptive groupings that you've provided to display in the tech view.

Closest I would suggest is setting weight to zero, and then setting it to 1 (the default value) in your module manager config. Of course, I checked, and I have validation for (weight > 0.0). I've already made the change in dev to make it >= 0.0 instead, that'll be released with 0.6.0. That should be out by.... Sunday (maybe?). In the meantime if you set it to 1.0E-300 it'll be effectively zero. Hmmm, depends on what you're willing to accept. Issue #108 would've probably been the closest bet, and was originally intended for 0.6.0. But I had to change the contract pack that's coming out with the release mid-way and didn't need this parameter (yet), so it got pushed out. In the meantime, if you're willing to live with it, the closest I would suggest is: Use a VesselParameterGroup to set the conditions (including the crew requirements) and define the vessel. Use a second VesselParameterGroup to set the "home" conditions, as well as re-stating the crew requirements. Here's an example (untested, but should work): // Land 3 pilots on the Mun PARAMETER { name = VesselParameterGroup1 type = VesselParameterGroup define = Mun Lander PARAMETER { name = ReachState type = ReachState situation = LANDED targetBody = Mun } PARAMETER { name = HasPilots type = HasCrew // (Optional) The type of trait required. Valid values are: // Pilot // Engineer // Scientist trait = Pilot minCrew = 3 } } // Bring 3 pilots home PARAMETER { name = VesselParameterGroup1 type = VesselParameterGroup vessel = Mun Lander PARAMETER { name = ReachState type = ReachState situation = LANDED targetBody = Kerbin } PARAMETER { name = HasPilots type = HasCrew // (Optional) The type of trait required. Valid values are: // Pilot // Engineer // Scientist trait = Pilot minCrew = 3 } } This requires the player to go to the Mun with 3 pilots, and then bring the ship back to Kerbin, and have 3 pilots. This contract doesn't enforce that they are the same 3 pilots, so hypothetically a player could leave them behind and replace them with a different crew (but that might be harder than doing it the right way). Anyway, if you're willing to live with that loophole, this could be your solution. If not #108 may help a little... but no guarantees (and no timeline either... probably not for at least a month). Always happy to help!

Seemed questionable for a bit, but looking at this GitHub account seems to show that TwistedMexi and Veyda92 are one and the same. Nothing to see here, although maybe TwistedMexi needs to come and update this thread in honour of his Modding Monday....

I'll see what I can figure out... I know it'll be at least a little bit hacking (ie. the waypoints won't work unless there's a contract, and I'm not quite sure yet how I'll dummy that up)....

One of the things I'll look at for 1.3.0 is allowing user-creating waypoints. If there's nothing in the stock code that prevents waypoints from working in sandbox, I'll make sure that my part will work in sandbox.

When I do the refresh for 1.3.0 I will be putting it up on KerbalStuff. In the meantime, you still have lots of options: CKAN KSP-AVC Watch in GitHub (will also notify you for bugs, etc) http://gh-release-watch.com/ (Unlike watching in GitHub, it will only tell you about new releases)

This issue should be fixed in the dev branch now.

Oops, thought that was fixed - I'll have a look.

This one needs more love, great concept!

Alright, multiple part attributes in ExperimentalPart is now supported in the dev version. - - - Updated - - - 0.5.11 is out - recompiled for RemoteTech 1.6.2. Due to changes on their side, this should be the last time I'm forced to do a recompile for new 1.6.x RemoteTech releases. Download here. Contract Configurator 0.5.11 Recompile for RemoteTech 1.6.2

10char

Multiple parts makes sense, that's an easy enough change. As far as the mouse-over and scroll bar, nothing much I can do, that's just the way "tool-tips" work in Unity. I considered having a way to scroll using hotkeys... but didn't implement it. It's meant as a "preview", but it is pretty annoying when you can't see the whole thing... I'll have to think on that to see if anything can be changed.

It's the great circle distance (ie. along the sphere), with altitude difference taken into account. Next version will allow finer control over what gets displayed - ie. it'll let you display lateral distance instead.

In-Flight Waypoints 1.2.8 is out, download it now! Changes: Fixed distance text to take waypoint height properly into account (thanks raath). There's not much in this release, but after Contract Configurator 0.6.0 comes out I'll be switching gears back to In-Flight Waypoints, and it'll get a big​ update... more soon!

Yup, since the default for minCrew is 1: I will fix the validation so that it checks max >= min though. Also normal, that's just how KSP works. If the list is full it won't try to generate new contracts. Either time warp a bit so some of them expire, manually decline them or go to the debug menu for contracts and regenerate the whole list.