Black-Talon

Since burning prograde is the most efficient, isn’t adjusting heading to the changing prograde over the duration of the burn giving you the most bang for the buck? The OP’s issue isn’t necessary making burns “impossible,” as we can see from current game play. But consider moving the node to points prior to Pe, that the burn will begin prograde at the point of the maneuver, right? And prograde being tangent to the orbit means that once the craft has proceeded past Pe the original fixed direction of the burn is significantly far from prograde and inefficient. So, users can adjust the node to be prior to Pe. But the combination of these conditions can’t work for interstellar without detrimental efficiency implications? How would you burn prograde all the way to the halfway point, flip, and burn retrograde all the way to the destination without holding prograde and then retrograde during the duration of those burns all while under time warp with the current system? So two things would be needed? A better maneuver planner surely, one that potentially optimizes the start point of the burn to a location other than where the user clicks to create it. And the ability to hold to heading that moves relative to the continuously changing orbit. Probably some brutal math… Or am I just wrong about continuously adjusting heading to match prograde (such as with lock to prograde sas) throughout a burn being the most efficient? Or is it irrelevant on a hypothetical interstellar burn since we’re spending most of that burn outside spheres of influence and a long ways from the Pe? The implications of interstellar burns are quite daunting and thus OPs “bug” is perhaps reflecting that despite the improvements to the maneuver planning it isn’t the approach interstellar will require. …more work to do as part of the progress towards the interstellar milestone.

Thank you both - using those so I'll count those as the best options.

Thanks for maintaining this@linuxgurugamer, curious for your thoughts on the ease/complexity of adding the ability to snap to "the other" horizontal axis (Mod+H perhaps). This comes up most for me when I'm putting surface mount things on the end of a cylinder, surface mounting multiple parachutes on the top of a crew capsule (landing pod) for instance. In many cases I'd like to center the part I'm placing without using the attach node. Anyway, temped to take a peek at the code and see if I can locate this and see if the same "snap horizontal/vertical" functionality could be applied to the 3rd axis easily but I'm being lazy and asking first. Curious for your thoughts! And thanks again for keeping this working! -Talon

Really wanted to do this so I threw a vehicle together and I guess it made it to the Stage 2/Finish marker for today. I had to use the winch. :-/ Broke a lot of stuff. And oh, my passenger died. Terrible Stage 1 time but it was fun anyway and wanted to post since I at least completed my goal for the day. :-) Screenshots weren't well done...you'll have to trust me that the MET is as good as it'll get for a Stage 1 time. Fun challenge! Oh, my worst accident was caused by a seam. Is it likely a mod caused that? Just curious.

I've been using it with 1.0.5 for a long time without issue. What "trasmit-bug" do you mean? I see these comments from your previous posts ... ... but I don't understand what you're referring to. What "white transmission dialog?" "green line?" I transmit science all the time and don't have an issue. I'm using RemoteTech personally but since you're talking about a dialog I'm unfamiliar with I'm not sure what is going wrong on yours at all. EDIT: Since I made a new page we will inevitably need 1.0.5 compatability and patch instructions on this page ... ScienceAlert is compatable with 1.0.5 after installing this patch:

I so love and hate this at the same time! I want both but don't even want both! So, any thoughts of adding CCC to the fuselage parts? I basically want the textures on them. *sigh* This is a terribke waste of effort on your part and perhaps memory for the player (although I suppose it's all shared with what you already have). I would probably be happiest if I just forgot I discovered this. My sense of 'right' has been torn in two directions. 360 L is basically the same as 400 L in a plane anyway! *puts head in the sand* Thank you for the wonderful mod/parts and maintenance along with the helpful response to my question. This package is really wonderful imo.

@NecroBones The other day I noticed that the Color Coded Cans (with InterestellarFuelSwitch installed which activates Color Coded Cans fuel switch configs) seems to contain what I would consider the incorrect amount of liquid fuel when switched to the LiquidFuel tank setup. Curious if this was intentional or a minor bug that could be fixed in the future? Specifically, the FL-T400 tank should be capable of holding 400 L of fuel. We know this because the stock tank can hold 180 L of LiquidFuel and 220 L Oxidizer. And of course we know that 180 L + 220 L = 400 L of fuel capacity. If we compare the stock FL-T400 to the stock Mk1 Liquid Fuel Fuselage (which certainly seems to be of identical size to the stock TL-400) we see that it also has a capacity of 400 L as it contains 400 L of LiquidFuel by default. Problem(?) - the Color Coded Cans config for making use of Interstellar Fuel Switch result in the FL-T400 having the options of 180 L FL + 220 L OX, 360 L LF, or 440 L OX. This doesn't seem right to me but perhaps it was intentional? I see in the CCC Fuel Switch config that the calculation used does indeed just double the LF volume in order to determine LF Only Fuel Volume and does the same for OX volume. I would have expected it to instead sum the stock LF and OX volumes and not just double them. Thoughts? Were you perhaps trying to maintain ratios of the typical LF to OX mix such that a single OX fuel tank and a LF tank could be stacked (with OX on top of course like the real thing) and fuel a rocket without trying to figure out fuel balance? I agree that's a neat idea. What is tempting me to correct mine locally (to sum the stock LiquidFuel and Oxidizer value, assuming I can do that the way I think I can by adding the MM variables together) is that the stock Mk1 Liquid Fuel Fuselage becomes attractive to use for its additional fuel capacity when ideally I wouldn't use it at all (because it doesn't have texture switching when I use FTP).

Yeah, that gets harder. :-) 64-bit soon though...

Just in case you're missing out on these contracts due to a misunderstanding I thought you might like to know that it doesn't require or install any parts.

1.6.3 - 475 out of 476 Contracts Loaded Known bugs: Apollo-I.cfg has "prestige = triv" and needs to be "prestige = Trivial" (credit to Jimmbal) Surveyor-7.cfg has a minor description issue where "lunar sample Trivially different from" should be "lunar sample significantly different from" (credit to Jimmbal) STS-9, STS-41-G, STS-51-G, STS-51-L, STS-61-A, STS-61-C, STS-95 have a warning of unknown significance with their SpawnPassenger Behaviour: "[Warning] The passengerName and gender attributes are obsolete since Contract Configurator 1.9.0, use kerbal instead." Debug Warning: "Contract group 'FotonMission' contains no contract types of child groups" (but this isn't new) Seems like a good release to me out of the nearly 500 contracts! @Whitecat106I can happily do the type of stuff I'm doing in the thread (diffing the new releases and offering code review, playing at my own rate and digging in deep enough to report the issue effectively) but not much more. I wouldn't call that thorough but if it's any help at all don't hesitate to ping me with a pre-release to review.

There were not a ton of problems created from the quick switch from Significant to Trivial (I did a diff between 1.6.1 and 1.6.2 and went over all the changes). The one I noticed was the Surveyor-7.cfg description that contained the word "trivially" and was mistakenly changed to "significantly" as noted by Jimmbal. But to answer your question about the number of contracts loaded, I show only a few yellow contracts due to Warnings about "SpawnPassengersFactory: The passengerName and gender attributes are obsolete since Contract Configurator 1.9.0." I'm afraid I don't have a perfect count as I have other packs loaded. I'll do a quick bit of debugging while updating to 1.6.3 and report back.

Thanks for the consideration. FWIW, I've been driving around on Kerbin with your new waypoint contracts and it is good fun (and much better than before!). It could be turned into a "test your rover here at home" mission if you wanted. My original issue is likely created by having wheels available early in my custom tech tree...I just wish these contracts weren't suggesting I deploy rovers prior to Mun fly by. Especially when it's taking up valued contract slots! ;-) But my own fault for using a tech tree with a vehicle available prior to mun landing. I still think some progression would help. Thanks for the fun little mission! PS - I saw in the latest update that you added a dummy .dll - I haven't tried it myself but this can be done with a dummy ModuleManager config that uses a :FOR[RoverRedux] or something similar and would be less...dummy.dll? Dunno, just a thought.

@Whitecat106Sorry to hear life has you busy busy. I've continued to really enjoy this pack. I think worth noting, the fixes discussed with @gerishnakov about Contract R-2A needing it's Orbit parameter changed to ReachState along with the dependency on V-2N20 instead of R-1V don't seem to be in the new 1.6.2 version (noted in many places but my consolidation post of issues/experiences is here and I selfishly think it's worth a read ). When either of you can get to these in the next version I think it would be worth it as it was a tough start to an otherwise awesome set of contracts! Stay well gents. Life first! To The Mun second.

Still really appreciating these fixes Claw! I would like to repetition for links to additional fixes (or plus like featurelets) be linked to in this section of your fantastically organized and pinned thread. Specifically coming to mind as supper-duper-awesome-and-helpful to the common player (and should be fixed/added to the game imo): Menu Stabilizer - make any part right-click menu freeze its position on the screen in flight when the mouse is above any part of it FlightDefFreeCam - sets the free camera as the default FlightDefPrecision - sets precise / caps lock controls as the default MapShowNavBall - shows navball on the map by default Thanks for considering this humble suggestion! I do realize that the list gets long quickly, so maybe just pick your favorites if that's the issue. I just hate to see so many good tweaks get overlooked when there is such a perfect place for them to be linked from. They're generally difficult for players to find unless they know it exists and what it is called. They rarely if ever get the spotlight. Heck, I have a hard time finding them again when setting up a new install! It wouldn't hurt to pick your favorite modules from Malah or Magico13 or link to their master listings. They also have some of my favorite gems like QuickSearch, QuickBrake, and Dated QuickSaves.

DTL: ATM:

I'm excited! It's like Christmas again!

Nice, you did go ahead and do this! I've been enjoying the previous version of this mod, and now downloaded your update to switch to immediately! Thanks! One request, I play a slow game (after dozens of missions, such as historic and aircraft, I have only just flown by the mun) and it's a bit strange/annoying to have Rover Missions constantly propose a new Rover Deployment to Eve and other planets when I haven't even had a Mun fly-by yet. Could you enhance this be adding some progression to the Rover Deployment mission? The mission itself is fine but I would prefer that it first request a deployment of a Rover on Kerbin. Next Mun. Next Duna. THEN it could go into a "deploy anywhere random mode" that it does now. Thoughts?

@sarbian Small feature request based on something I find useful in the windows task manager's memory monitor. Can you display the peak memory used (optionally shown in the overlay text as well would be nice)? I find this particularly nice with Kerbal since the big hits to memory happen on scene change. Thus being hard to catch with the memory monitor on screen. By tracking the peak, we get to see just how close we're getting to the limit on scene change and thus why we're too close to the memory limit. I do this by watching Peak Working Set in Task Manager and find it interesting that between two scenes memory use has hardly changed BUT that during the scene change I actually hit an new all time high memory utilization. It would be wonderful to see this in game. PS - Upgraded to Windows 10 and I now have the GPU memory display option! Very nice! Although it shows about 200 MB less than GPU-Z I would still say it is a really nice feature!

I can confirm that I do not see GPU memory use on Windows 7. This isn't a complaint, just confirming your *may require Win 8+* statement. I have to say that the memory monitor is much more useful than expected, I wish I'd tried it sooner! Thanks for making it!

Another curiosity question, the load up of memory into video ram would indicate that things like turning aero off (which uses video memory I believe?) would actually free up memory for parts? Definitely something I didn't know ... planning to try that out.

I have a curiosity question since you're saying this doesn't unload cloud textures, only part textures. Does EVE already unload textures of distant planets? Could it do that using this same technique?

That is a pretty fantastic conclusion to these contracts! Would this require or benefit from one of those mods that adds additional airports across Kerbin? Or is that just too much to leverage additional airfields?

Oh! A super minor nit-pick regarding the OP of this thread. When you release the next version consider making the release .zip more easily/obviously the a download link for your pack. Unless perhaps you're expecting people to download and install it another way(?). I personally find that a quick read looking for the download link often results in me back on the Contract Configurator download, or the source download, etc; eventually I find the release .zip download as the link of the title. Thanks for this silly consideration!

Wow - so quick! But all of that sounds about like what I was suspecting. It seemed as though the "waypoint" completed but then the complete objective no longer could be completed for some reason. Thanks! Excited to give the new version(s) a go soon! I'll need to start over and enjoy the ride!

I have once again had a landing issue. I am doing the "KSC Island Landing" and after Landing (nice perfect landing on the dirt) I do not have "Land at KSC Island" marked off the objectives list. I've finished "Claiming the island for KSC" by "walking to the base of the air tower" and "plant a flag." About to fly back to complete "Land back at KSC runway." FWIW, I took off and landed a second time to try to complete the objective, no dice. I suppose I'll do it all again and see if I notice anything. Anyone else having trouble with landing not completing?