Black-Talon

Absolutely the best Christmas gift! Thank you! Initial results are exactly as advertised! So much less crashing! I haven't dared to push it further but it has clearly freed up quite a bit of space for me with far less work/configuration/etc! Thanks! Edit: I did get ambitious and increase my texture resolution from half to full (with the same set of parts/mods I have been using mostly successfully but with a crash after a hour of play or so). This worked at first but crashed after 30 minutes or so. This was on DX9. Still such a nice improvement!

I think you're thinking it does this because of the add-on release thread which says that it does: http://forum.kerbalspaceprogram.com/index.php?/topic/88304-background-processing-02-ksp-025/

At first glance I can remove the LF, OX, Xenon, Monoprop, etc properties from the configs that are creating these errors in the configs. Right? I assume it was just for notes (comments) or erroneous that they were left in but I suppose they could be used in a way I didn't see. PartLoader Warning: Variable LF not found in Part PartLoader Warning: Variable OX not found in Part PartLoader Warning: Variable Xenon not found in Part PartLoader Warning: Variable Monoprop not found in Part Edit: Ran out of time to keep looking into this but I think my speculation above is wrong. Just haven't figured out what/how those variables/properties are used and if the errors in the log are because of them or due to a lack of them.

Cool - I'll do the same on my copy then. It must've been in 0.4 since I'm playing 0.3 and still have it in my game. Or I'm just reading it wrong! Congrats on the progress!

Will do. I'm certainly curious and really like the concepts in this contract pack. Speaking of, I'm generally impressed with your usage of tight-ish contract deadlines. But if I'm reading it correctly, I have a day after I accept the "SSI-Start - SSI Aerospace: Join SSI Aerospace!" contract to complete it. Since accepting the contract grants me access to the parts I will need I cannot build a craft until after I've accepted. As a user of Kerbal Construction Time, this creates a problem for me. And I haven't come up with a solution I like. Curious for your thoughts on this. Context of why this is relevant: By using Kerbal Construction Time I feel that time (and things like Contract Deadlines) actually has a purpose. Unfortunately, if the contract deadlines are loosened to support KCT, then they will be less relevant in a normal game. So a config modified by the presence of KCT would be needed. This is certainly possible though a bit of extra work (if I make one for myself I'll share it). I'm slightly more concerned by the variable nature of Construction time. It would be tough to balance situations like this particular contract where time between part unlock and success should be fairly tight. But I suppose it's a rare situation and build time for KCT users would need to be a consideration when designing the vehicle. It's just impossible to know prior to accepting if you'll be able to complete it on time. I'll take a look and see if I can create a ModuleManager config which extends contracts that may be too tight when a vehicle needs to be built first (particularly specialized vehicles). Edit: Added better context

I keep failing the initial contracts but am not sure why. What entails "Landy safely?" Based on my performance I have to guess hitting the runway is a requirement? Interesting. I believe the first time I failed a contract I landed at the island runway (I was in the process of also completing the "Investigative Island Airbase" from Anomaly Surveyor which was a perfect match for "fly your first airplane"). Without looking back at it closely I would either guess that Island Runway was not an allowed landing place OR I broke something when landing and that didn't count as safe. Just now I flew "Fly an aiplane to 2000m" (after originally failing it by not completing in time while awaiting for Kerbal Construction Time to build the aircraft for the mission). After reaching 2000m I was flying around to collect some science and suddenly the mission was noted as failed. No idea on this...crossing 2000m multiple times perhaps? Fortunately I had quick saved and was back in the seat flying it again. No messing around this time, up to 2000m and back to land. Landed just prior to the runway and rolled up onto it without any damage...noticed at that point that the mission was marked failed. Must not touch down unless on the KSC Runway? Loaded the quick save again to narrow this down, hitting the runway and nothing else, completed my Safely Land requirement. Recovery went as expected. Mission success. Phew! Curious if I've identified my issue? Any idea on what would cause the contract to fail while just flying about collecting science? Great stuff so far!

FWIW, I'm interested. Just came to the thread to see if there were any tips on encouraging more realistic bodies for rovers delivery in the early game. Figured I might need to tweak the contracts to stop it from proposing bodies far away when I haven't even flown by the Mun yet. Though, if I understand correctly, if I place a rover on Kerbin, Mun, or anywhere that it will trigger rover missions for my existing rover. That's pretty sweet. Haven't tried it yet.

I guess these issues have just been there awhile. Just to confirm, the Pictozoom 1000 has that lens cover but no animation on it?

All of this still seems to be true? Or at least something that remains is my confusion around the nearly duplicate modules in the parts, the warnings in the output log about the resolution resource be undefined, my confusion around the parts having runnable experiments, additional output log warnings about missing impactTolerance property, the inconsistencies in "Module" and more in the configs, and despite what is in the configs a HullCamera PartModule isn't even defined in the source (another error in the log for this too). HullCam just still needs a lot of code/config cleanup but otherwise works?

Are you already familiar with the Texture load errors in the output_log.txt? I don't have a correlation of them to any particular issue but they seem concerning: Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\Control\ClimatScreen\DATAmonitorr04screenEmissive.dds' Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\Instruments\FuelMonitor\screen.dds' Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\Instruments\IndicatorPanel5x3\screen-emissive.dds' Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\MFDs\ALCORMFD40x20\bg01.dds' Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\MFDs\ALCORMFD40x20\bg02.dds' Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\MFDs\ALCORMFD40x20\screen-emissive.dds' Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\MFDs\ALCORMFD40x20\screen.dds' Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\MFDs\ALCORMFD60x30\BG62x30.dds' Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\MFDs\ALCORMFD60x30\MapMask.dds' Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\MFDs\ALCORMFD60x30\screen-emissive.dds' Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\MFDs\ALCORMFD60x30\screen.dds' Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\MFDs\ALCORPFD\HDG.dds' Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\MFDs\kOSTerminal\bg03.dds' Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\MFDs\kOSTerminal\screen-emissive.dds' Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\MFDs\kOSTerminal\screen.dds' Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\MFDs\ScreenPlates\scalebar.dds' Texture load error in 'D:\KSP\KSP v1.00.5 (Win) - Stock\GameData\ASET\ASET_Props\Misc\PSU\screen-emissive.dds' This is reproducible with a clean install of KSP and only adding ASET Props Pack. v1.3 with the latest version of its dependencies (RasterPropMonitor v0.24.1 and Module Manager v2.6.13). The only lead I have on what could be wrong is this post I found, but I didn't follow up on that or dig into the textures to determine if this was at all related (particularly given the age of that post). http://forum.kerbalspaceprogram.com/index.php?/topic/105600-ksp-cannot-load-dds-textures-without-mipmaps/ For that matter, the only IVA's I'm using that use these props is the "Buffalo: NASA Inspired MSEV." I'm not certain if the IVA's are working properly without those assets or not (perhaps they're unused). And since it has a stock IVA as well this isn't a critical issue regardless of how it turns out.

FYI, I do not think KSP-AVC is setup correctly for Engine Lighting to check for updates. Searching the thread I see this was perhaps already reported: I came to believe this after finding this error in my output_log.txt: MiniAVC -> Version file contains errors: http://forum.kerbalspaceprogram.com/threads/121987 MiniAVC -> D:\KSP\KSP v1.00.5 (Win) - Mods\GameData\EngineLight\EngineLight.version NAME: Engine Lighting URL: http://forum.kerbalspaceprogram.com/threads/121987 DOWNLOAD: https://kerbalstuff.com/mod/817/EngineLighting/download/1.4.1 GITHUB: NULL VERSION: 1.4.1 KSP_VERSION: 1.0.5 KSP_VERSION_MIN: NULL KSP_VERSION_MAX: NULL CompatibleKspVersion: True CompatibleKspVersionMin: True CompatibleKspVersionMax: True CompatibleGitHubVersion: True MiniAVC -> http://forum.kerbalspaceprogram.com/threads/121987 NAME: NULL (required) URL: NULL DOWNLOAD: NULL GITHUB: NULL VERSION: NULL (required) KSP_VERSION: 1.0.5 KSP_VERSION_MIN: NULL KSP_VERSION_MAX: NULL CompatibleKspVersion: True CompatibleKspVersionMin: True CompatibleKspVersionMax: True CompatibleGitHubVersion: True UpdateAvailable: False Since I wasn't familiar with KSP-AVC or MiniAVC and how it used the .version file to even guess why it "contained errors" I did a little research and found this (from a support post in the KSP-AVC thread): This led me to the belief that the EngineLight.version file needs to have the URL parameter set to the remote version file (which will be used to signal/indicate that an update is available). It is possible you already have one setup (with http://ksp-avc.cybutek.net) and you'll want to ask in the KSP-AVC thread (or PM to cybutek) about what the id is. Looking back through this thread I see here where linuxgurugamer kindly helped. Unfortunately his example .version file had this issue with it way back then. In addition, the first version released with AVC had this issue. So MiniAVC has never been telling users about new versions if I understand correctly. In searching the thread I also came across this, perhaps relevant, discussion/suggestion that may warrant additional investigation:

FWIW, I had the exact same question and concern. But I went to the new thread and found this helpful bit, so I'm at least open minded!

Yup, love it. And it works fine with relative paths. And super easy to change with the in game settings. Sorry to have even cluttered the thread, I should've finished trying it before posting.

Unrelated to the JetWing: while looking into a different issue, I found what I believe to be a couple bugs. First small thing, M1A2Grizzly.cfg has a convenient inclusion of WheelSounds via a ModuleManager modification. But for the M1-A2 Grizzly (WBI_M1A2Wheel) it accidentally applies the WheelSounds module to WBI_OmniWheel instead of WBI_M1A2Wheel. And for consideration, did I read correctly the other day that modules themselves can now implement :NEEDS; no idea if it works. The second, any idea what this is and if it is of concern? I didn't see it elsewhere in the thread but stumbled into it in my output_log after loading the game. This isn't the first time I've loaded and I've used the part a little without any obvious issue. PartLoader: Part 'WildBlueIndustries/Buffalo/Parts/Utility/Wagon2u/WBI_Wagon2u' has no database record. Creating. (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) DragCubeSystem: Creating drag cubes for part 'WBI.Wagon2u' (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) NullReferenceException: Object reference not set to an instance of an object at ModuleDeployableSolarPanel.AssumeDragCubePosition (System.String name) [0x00000] in <filename unknown>:0 at DragCubeSystem+ .MoveNext () [0x00000] in <filename unknown>:0 UnityEngine.MonoBehaviour:StartCoroutine_Auto(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) :MoveNext() UnityEngine.MonoBehaviour:StartCoroutine_Auto(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) :MoveNext() UnityEngine.MonoBehaviour:StartCoroutine_Auto(IEnumerator) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) :MoveNext() (Filename: Line: -1) Copied the github release to a clean stock install, same shows up in that install when I load up. [Copy of that output_log for download]

Nice inigma! I was just working on my custom career to get planes into the game a little early and that screenshot in the OP and that you threw into the Contract Configurator screams exactly what I was looking for! Checking it out right away!

As I suspected. Makes sense, uses the right numbers. If my craft is messing up those numbers, perhaps by having the engines crooked, impeded thrust, or perhaps even other bugs that create wasted thrust, my estimate will of course be wrong. If I see it again I'll try to figure out what's going on for real. Thanks!

I think I found a minor bug with the "Dump DB to file" feature. SCANsat comes with a config to create an Agent with the name, "SCAN: Scientific Committee on Advanced Navigation" - and the "Dump DB to file" feature creates config files named with a path down to the Agent name. And the file can't be created since it contains a colon. At least I think that's what's going on... IsolatedStorageException: Could not find a part of the path "D:\KSP\KSP v1.00.5 (Win) - Mods\_MMCfgOutput\SCANsat.Flags.Agents.SCAN: Scientific Committee on Advanced Navigation.cfg". at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] in <filename unknown>:0 at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share) [0x00000] in <filename unknown>:0 at System.IO.StreamWriter..ctor (System.String path, Boolean append, System.Text.Encoding encoding, Int32 bufferSize) [0x00000] in <filename unknown>:0 at System.IO.StreamWriter..ctor (System.String path, Boolean append, System.Text.Encoding encoding) [0x00000] in <filename unknown>:0 at System.IO.File.WriteAllText (System.String path, System.String contents, System.Text.Encoding encoding) [0x00000] in <filename unknown>:0 at System.IO.File.WriteAllText (System.String path, System.String contents) [0x00000] in <filename unknown>:0 at ModuleManager.ModuleManager.OutputAllConfigs () [0x00000] in <filename unknown>:0 at ModuleManager.ModuleManager+<DataBaseReloadWithMM>c__Iterator0.MoveNext () [0x00000] in <filename unknown>:0

Just discovered this mod and I'm going to give it a try. I'm curious about something you might know...I have run into times when the burn actually takes much longer than predicted by the stock estimate that I cannot explain. These are long burns (3 to 4 minutes) with smaller, low thrust, engines (stock engines though, assuming I remember this right). Nothing that's obvious to me is impacting them. I'm locked onto the maneuver node and burn full throttle for 3 minutes only to discover that another 2 minutes of burn is now expected. No stages or other changes are occurring during the burn. It just slowly doesn't perform at the expectations of the estimate. I haven't been able to think up an explanation for this. Given you've spent some time wrapping your mind around the flaws of the stock Burn Time Indicator, I thought you might have an idea that I have over looked? I'll let you know if I experience this with your mod, and under what conditions. Otherwise I'm optimistic that it is a thing of the past! As I think about this previous experience I wonder... does this mod do any correction based on actual performance over the last 5 seconds or so? Or is it strictly calculated from the numbers reported? Perhaps my problem was that for whatever reason, the engine just isn't performing as it's stats would indicate it should. Still wish I knew why.

Ok cool, I was basically doing this but failing to notice what happens when I do. So couple idiot questions: Do you have SAS on or off when you do this? Does it matter? I get "Hover Mode ON" message and my climb rate is displayed in the GUI (+40.2 m/s would be a good example) Do you ... level out first? Or stay vertical? Does it keep you flying horizontally while maintaining an altitude or does it cancel your horizontal motion as well? Or does it do something other than maintain an altitude? After I get "Hover Mode ON" nothing happens. I can then change my Climb Rate and get on screen messages that it is change to 1, 2, 3, 4, 5, 6, etc... but again, I see no change in my flight. I just arc up into the sky and into the hills. Does hover control just RCS? RCS and throttle? Just throttle? Should I see my throttle move? If I turn off SAS should I see my controls move on their own? Thanks!

FWIW, this made me smile today and perhaps put me more in the "Christmas Spirit" more than anything else has this year. Thanks for the smile!

I haven't progressed far but a summary of the fixes/tweaks I've made to my own game are listed here (using \RegularVersion\Full Pack\): (most important) Contract R-2A needs it's Orbit parameter changed to a ReachState parameter (less important) Contract R-2A needs it's CompleteContract requirement changed from V-2N20 to R-1V (optional) Contract Explorer-1 could have its CompleteContract requirement changed from Sputnik-1 to V-2N20 (see my discussion with gerishnakov) (optional) Contract Explorer-6 could have its redundant CompleteContract requirement for Vanguard-1 removed since it also has a CompleteContract requirement for Vanguard-5 (which in turn depends on 4, 3, 2, and 1). edit: I misread this requirement Screenshot of R-2A.cfg diff: http://screencast.com/t/Xwu26FBz8OWy (my version on the right) Screenshot of Explorer-1.cfg diff: http://screencast.com/t/uKmknIgs1pf (my version on the right) Screenshot of Explorer-6.cfg diff: http://screencast.com/t/nt6rMk3O8CU (my version on the right) That's all I had actually changed in my game thus far. But I did also make a couple observations that could be looked at: The R-2A mission has a whole second half to the description in the config that doesn't show up in game in case you didn't already know. Remove line breaks in the config? The R-1V mission confused me regarding the crewed or uncrewed requirement for the mission. This is because the first thing under "Objectives" is (a note): "Launch the first mammal into space and return it safely to Kerbin." Is a Kerbal a mammal? Is it required to have one on board? Reading further, the combination of languard regarding "returning samples" and the requirements saying something like, "Crew: Unmanned: Complete: Unmanned: Incomplete" just looked buggy and I wasn't confident on what was the right thing to do. I would suggest moving the "note" to the historic briefing/description so I don't have to wonder if a Kerbal is a mammal that needs to be included in my R-1V mission. See observation 3 regarding Crew requirements. Any idea why all of the Historic Missions I've seen thus far have two "Unmanned: " labels/requirements? Maybe it's a contract configurator thing but other contracts I have don't show it that way." Perhaps this is because the HasCrew parameter uses both minCrew and maxCrew properties? If possible, a better clarification of the Crewed/Uncrewed requirement would've helped me when I first started. It is easy to get confused about what solar panel is required for meeting the Vanguard-1 requirement because the module name is DeployableSolarPanel, which causes players to assume they need a SolarPanel that has a Deploy option/animation. Perhaps text somewhere in the mission could clarify that any SolarPanel will do, including a Fixed Panel such as OX-STAT Panel? I doubt hiding the Module name is an option but that would be ideal.

Interesting, and I like it. If I understand the intent correctly, you would get to see/feel the options to be the first to orbit a satellite. And your choices impact your kerbal version of the history. For instance, contracts that all become available at basically the same time are Sputnik, Vanguard, and Explorer. Depending on what the game presents you, and what you choose to accept, will impact the historic recreation. You might choose, like the Americans did, to go for a Vanguard mission...and then find yourself lacking a solar panel (as you would with other tech trees, not that I don't like SETI Tech Tree and others of it's type, they're nice and stock is kinda broken imo). If instead the player chooses a Sputnik or Explorer mission to focus on first, it either matches history or changes it for your game. With this mindset the Vanguard contract should indeed be offered to the player before they have the tech required, such that the player can make that choice to focus on a more complex satellite first despite the increased "cost" of solar panels. I still think this means you also want Explorer-1 to have its contract dependency be V-2N20 (instead of Sputnik-1) along with the change you earlier suggested fix of R-2A depending on R-1V (instead of V-2N20). Just my opinion. Thanks again, that I'm even thinking about this is a joy!

It's kinda dumb but I'm mildly (stupidly) annoyed that the config doesn't use a local path because when I diff my various installs it shows a conflict I can't resolve when in reality everything is the same. Like I said, dumb. :-) I'm going to try to change it to a relative path in the config and hope the quoted note from the OP refers to this being something that will work. /fingerscrossed Anyone else tried this?

Kinda feel like an idiot but I can't figure out what the hover mode does or how to work it. I thought perhaps I was missing a dependency but I don't see reference to one. I get the pack strapped on, fueled, etc. Activate the engine. Active hover. Increase climb rate. Nothing. So I throttle up the engine, take off and begin to fly. Activate hover. It has no effect on my climb rate. I've tried this with both mono and liquid fuel. Curious if I'm using it wrong, missed a dependency, or have not realized what it is doing when active?

Those pictures are just amazing! Glad to hear that playing KSP is keeping you distracted from working on this! But can't help but drool over future expeditions using this stuff! For now, is the released version for 1.0.2 worth trying in 1.0.5 or should we wait for all that new awesome stuff?