nightingale

Goodbye tiki bar, we hardly knew ye! On a similar note, vessel spawning always seems to be the thing that gives me the most grief in updates - hoping that there's some changes in 1.4.1 that'll make this easier (since the mission builder should have the ability to spawn stuff). Still doesn't help with version to version vessel compatibility, of course...

Haha, I doubt I'll be able to get anything done for April 1st this year... but the re-release of this mod... feasible!

I'll take a look. Make sure that you still meet the contract though when you EVA (if you don't have a pilot on board you don't technically meet the objective any more). But it could be there's an issue - since switching vessels should be fine.

Sure - if you use the old version.

@coolguy8445 - I took another look, and I don't think this is one I can fix without significant rework... the 70% already feels too high (although I know in practice it's not). On the other end, the 95% is just enough to give enough room for error.

I agree with most of your other points - but if I recall it was @Arsonide who named them Glimmeroids when he did the callback easter egg to the Magic Boulder. So he gets full naming rights. Semi-related - the gold monoliths (they are supposed to be gold - don't think the color is right though) were always referred to as "randoliths".

@coolguy8445 - That's a long standing occasional bug with how the scanning works. Because it's really performance intensive, the checks for coverage are spread out over time. The way it works out, you can get pretty close to the 70% coverage just from luck (logically you've already got 50% coverage just from the bit that's facing Kerbin). I really should bump the number higher. The nerfing probably has nothing to do with it (which says I do need to fix this up since nerfing the range should've made it harder).

@Ahres - For most contract packs you should be fine in 1.4.x as long as any other dependencies can be satisfied.

All I fixed was to get rid of the error message - the error message wasn't 'causing your issue. And nope, I'm only just getting back into modding, I'm not going to backport anything - it's a huge pain to test/maintain against two versions.

Thanks @DMagic for continuing to provide the mods we didn't know we needed. And because someone always brings up these things as causing grief for my mods... Does it work with planet packs that move Kerbin to a gas giant? Sigma Binary? EDIT: Hmmm... maybe the last one won't cause any issues, since it looks like @Sigma88 has jumped ship.

@steve_v - I wasn't able to reproduce this in 1.4.1, but I did get rid of that message (it was a workaround for an old bug). Once all the applicable mods are updated to 1.4.1, let me know if you still see the issue.

It's unlikely to work on 1.3.1. Even if it does work, it won't be something I will support.

Didn't seem to need too much for KSP 1.4.0 - so here's the new update! Contract Configurator 1.24.0 Recompile for KSP 1.4.0 Added back MODULE checks in simple version of PartValidation (thanks chrisl). Support RemoteTech 1.8.9 (thanks vader111). Read date/time information from dateTimeFormatter (thanks Aelfhe1m).

The custom waypoints file feature is half-baked. You have to use a very specific file (GameData/WaypointManager/PluginData/CustomWaypoints.cfg) and only then will it load it. Works fine if you want to hit export in one save and import in another. Any other use case is a pain. That's my fault. I accidentally released the 1.4.0 version under a 1.3.1 tag. I'll send a PR to CKAN to stop that.

The DLL was for RemoteTech 1.8.9 - as far as I know it should "just work" on the older version.

Someone posted up a dll that can be used for 1.3.1. For 1.4.0 I'll incorporate that (and any other RemoteTech changes required) into the release.

And the "remember how to do this properly release": download here. Waypoint Manager 2.7.2 Re-release properly for CKAN.

Yeah, forgot to update the version file for CKAN. I'll sort it out soon.

@wile1411 - Yeah, the Jool bit really broke me (trying to get it working again just wasn't fun). I plan on re-releasing this for 1.4.0 in some fashion, even if it means cutting the Jool stuff. We'll see how it goes - no promises. And not much the community at large can do - unless there's someone with the skills and willingness to take on figuring out how to fix up the code for the Jool sequence and send me a pull request.

Away, old thread warning! So what's the interest level in my reviving this mod for 1.4.0? In some ways this is my favourite out of all my mods - but also the one that ended up with the smallest userbase/demand.

Okay, let's get this show on the road. I have about a year of unread posts in this thread, and the only way I can constructively move forward with this mod is to just pretend most of them don't exist. So I'll work backwards and answer a few posts, but even the second post is nearing a month old - hard to say who's still actually waiting on an answer. After that, I'll start digging into 1.4.0 compatibility. @Maxsimal - The triggered expressions in behaviours suck. Because they are the only thing that doesn't get parsed at either contract type load or contract instantiation, they have different rules around them. Their limitations are due to the fact that they are the original expression based thing in Contract Configurator, but they were only meant to transfer simple values from one contract to another. It may be possible to make it work with some changes, but that's the must ugly and complex part of the Contract Configurator code, and I'm worried if I look at it now I'll run away for another year. So best bet is to just go with something similar to the existing AltRecord contract and go with a simple increasing index or value. @chrisl - The documentation doesn't match the code, and it looks like a bug. So I've fixed it for the next release. For you though, you'll have to use the extended model of PartValidation. Untested and from a rusty memory, but I think you can do something like this: PARAMETER:NEEDS[SCANsat] { name = LowResScanner type = PartValidation title = Must have a Low Resolution scanner on board FILTER { MODULE { name = SCANsat sensorType = 1 } } minCount = 1 hideChildren = true } @Jim_Panzee - It might be a bug. It uses the internal progress stuff in KSP. I think when KSP added crewed/uncrewed/global progress nodes, it was either buggy or I didn't understand it correctly. So I might be looking at the wrong versions of those nodes in some cases. But it also might work in KSP 1.4.0. So for now I'm not going to touch it - but if you can reconfirm once I have a 1.4.0 compatible version out, then it might be worth a deeper dive. @AlexALX - Multi-lingual support is one of the things that I wanted to look at before i disappeared on my KSP sabbatical. If I know there's someone willing to step up to do a translation (it sounds like you're willing for Russian) and there is a desire in the community (I assume there is or you wouldn't be asking), then it's something that I can consider looking at once the 1.4.0 (and probably 1.4.1) stuff is out of the way. There is going to be a lot of challenges though - right now a contract pack can have text like "Land on @body", so I can't easily convert that to use the localization string system because it already has variable replacement going on. I'm sure it's solvable - but it'll need lots of though. @Bornholio - It was caused by a change in RemoteTech (as it looks like you figured out). The pull request that was sent in to fix has been merged for the next release. @Magnavox - Hopefully you got some help from the contract author - most likely that's where the issue is. @Garlik - You'd need to do something similar to the cooldownDuration in CompleteContractRequirement. Have a look at the code. ... and that's as far back as I'm willing to go. If you have something you want answered, post below and hopefully/maybe I'll be able to help.

Taking baby steps right now, but we'll see what 1.4.0 and Making History bring.

And first mod release from me for this year! Here you go! Waypoint Manager 2.7.1 Recompile for KSP 1.4.0 Fixed NRE when importing custom waypoints before stock waypoint manager is loaded (thanks linuxgurugamer).

KSP.log has actually had the stack trace for a very long time (at least since I started modding in 0.24 or so). It took a very long time for me to understand the hate against KSP.log until NathanKell explained to me that it didn't use to have the stack trace (which I agree would make it near useless). EDIT: Oh right, and the buffering annoyed me too, that's why I added an option not to buffer:

Given this seems to be a one-man dev team (as far as I can tell), it's extremely impressive to get to this point. It absolutely lacks polish, but it looks better than KSP did back in the early days. I agree that (at least right now), it's more of a flight sim (the video implies to me that staging is not yet a thing). But hey - you've got to start somewhere and what I'm seeing on the flight side is mighty nice. I'd say this is one to keep an eye on in the next few years.