Black-Talon

So perhaps another requirement needs to be added to the contract? Like this(?): REQUIREMENT { name = PartModuleUnlocked type = PartModuleUnlocked // PartModule that needs to be unlocked. // partModule = ModuleDeployableSolarPanel } Also, it might be helpful to know that the first available solar panel in the stock technology tree, the OX-STAT Panel (single fixed panel surface mountable anywhere) uses that *Deployable* Solar Panel module and is unlockable with 90 Science and prior to the expensive R7D upgrade. The *Deployable* language actually/unfortunately seems to indicate you will want/need a panel that can extend/deploy. But that just happens to be the name of all solar panel modules in the game.

Nice, thanks! Shouldn't the R-2A require the R-1V to be complete (not V-2 as you write above). Sputnik-1 requiring R-2A makes sense (correct above and in the Contract Pack). But then Vanguard-1 would require at least Sputnik-1 (not V-2N20 as you write above) and historically Explorer-I as well? But I'm not sure of your intent. Maybe players have the flexibility to change history as we go? If we're rewriting history then would then Explorer-1 shouldn't be dependent on Sputnik-1 (as it is in the Pack's config), Explorer-1 should instead depend on V-2N20, as you've suggested for Vanguard-1, right? Again I'll highlight that it depends on your intent; do you want it restricted to historic order? Or just dependent on that country/agencies progress? Both are sensical options. Having written this all down I think I know what I'm going to do to mine. Give the player the option to change history (thoughts?): R-1V requires V-2 to be complete - no change R-2A requires R-1V to be complete - change needed Sputnik-1 requires R-2A to be complete - no change V-2N20 requires V-2 to be complete - no change Explorer-1 requires V-2N20 to be complete - change needed Vanguard-1 requires V-2N20 to be complete - change needed

Overall I am loving this! I also just ran into this. Combined with a couple of other little bugs I now wish I had been taking notes. Is there an ideal way to submit fixes? Forum? Perhaps github? Also, I'm not an expert at the Contract Configurator, but I see where the proposed (and already added to dev) fix was regarding the ReachState parameter. But in the process of trying to figure out why the contract didn't complete I was looking at the Contract Configurator documentation and finally saw this (particularly noting the "vessel's apoapsis and periapsis must both be above this number"): PARAMETER { name = Orbit type = Orbit // Minimum orbit altitude in meters. The vessel's apoapsis and // periapsis must both be above this number. // minAltitude = 100000 ... And this: PARAMETER { name = Orbit type = Orbit // Minimum apoapsis in meters. // minApA = 100000 ... So out of curiosity, is setting a ReachState better than changing the existing Orbit parameter's minAltitude property to a minApA property? Anyway, I again can't say enough about how excited I am about this. I have been dreaming of such a thing since reading through mendahu's fantastic recreation of notable historical missions in KSP: http://www.ksphistory.com/ I would love to help with any bug fixes along the way if I can so let me know the best way to report those. PS - Recalling the bug I first experienced, the R-1V mission confused me regarding the crewed or uncrewed need for the flight. This is because the first thing said under "Objectives" is (a note): "Launch the first mammal into space and return it safely to Kerbin." And then the combination of returning samples and "Crew: Unmanned: Complete: Unmanned: Incomplete" just looked so buggy that I wasn't confident on what was the right thing to do. I would suggest moving the "note" to the briefing/description so I don't have to wonder if a Kerbal is a mammal that needs to be included in my R-1V. I also thought contracts that are unmanned look a little simpler like this (one less "Unmanned:"): Mission: Incomplete Crew: Incomplete Unmanned: Incomplet Conditions: Incomplete Condition 1: Incomplete Condition 2: Incomplete Any idea why all of the Historic Missions I've seen thus far have two "Unmanned: " labels? Maybe it's a contract configurator thing but other contracts I have don't show it that way. And one last thing, 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.

Still loving this. Thanks for the update and bug fixes! Can anyone confirm if this is still an issue? Reported in 0.5.3 and I haven't tested it myself (probably will) but figured I could ask if others know?

One thing I noticed is that my probes can do science reports now. I haven't double checked but I think that's from this temp/ProbeReport.cfg

Should I at all be concerned about the \GameData\CrowdSourcedScience\temp\ folder? It contains BarometerTweaks.cfg and ProbeReport.cfg and I'm just left uncertain if it was intended to be released with that folder in the .zip and figured I might as well ask for clarification. Thanks! :-)

Pretty happy with this but it seems that without Blizzy's Toolbar installed it's throwing exceptions on startup and occasionally throughout gameplay (like when switching into VAB). I can send logs but it should be easy to reproduce. Is this something you might clean up? I love that it optionally supports Toolbar btw...I just don't like errors in my logs. :-)

Dumb Question: Is it 'bad' for any reason that folders in GameData have spaces in their names? I notice Pilot Assistant has a space but nothing else does. And vaguely recall hearing "spaces are bad" and mods updating to remove spaces from their folder/file names. But I actually don't know that it causes problems.

Thanks! I've been using it and enjoying it as always. Some ideas and feedback: QuickBrake conveniently has a config option to only apply itself when doing runway launches - it makes me wish Improved Chase Camera had this option - I happily configure ICC with: defaultOn = true; disableAuto = true; autoSnap = true; - but every time I launch from the Launch Pad I sure wish I had different options for LaunchPad and Runway (defaultOnLaunchPad = flase or something like that). I might take a stab at this locally when I get motivated enough. I still sometimes get chase or snap behavior that seems crazy and undesired - I'm thinking the most obvious is at the time of a crash. Do you or others find this problematic? Any ideas on improving on those jarring moments? Disable chase for 5 seconds at the moment of part explosion? Temporarily disable or add some slowing/smoothing/damping to the chase camera movements in moments of rapid change? I've long enjoyed your effort on this - thanks!

Thanks for the consideration if nothing else. It's interesting that FASA appears to pull it off. When I use those Atlas tanks it really leaves me this impression of shiny. And yet, when I really look at it closely in screenshots, it isn't all that different from the default grey tanks we have. A bit more of a trick to get the look than I ever realized.

I know I would also enjoy this. I've been tempted to figure out how to set it up myself to get it done. I dream of the part clutter I could save! As long as I'm just dropping in requests, might I also request a new tank skin texture, the polished aluminum (almost chrome), like is seen on the Atlas-Mercury launch vehicles? This look just grabs me and feels missing from the game (unless I use FASA). Thoughts?

I also just experienced this while using 1.0.2d.2 - googled for it and INCORRECTLY found this support thread and made a poor post. :-/ What I can now confirm is that with only StockBugFixModules, StockPlus, and ModuleManager 2.6.3, my roll enabled ailerons respond inverse of expected when placed in front of the CoM. If it helps I'll upload a debug dump but seeing as others are also reporting the issue I'm going to turn off Plus and continue playing. :-) Thanks again for your diligent fixes Claw!

I am also having this problem, specific to roll control, and have to admit that it's problematic. Particularly when roll control should not be impacted at all by aileron position being fore or aft of the center of mass?? The position in front of or behind the CoM would impact their direction for pitch but not roll. Why is roll control inverted? I'm now realizing as I re-read the original bug report that this was a report specific to pitch. I'll write up a new one specific to roll? Perhaps I'm missing something as I haven't had this issue before and it's particularly problematic when you're controls work in reverse. EDIT/UPDATE 1: My post may have been a mistake - after removing mods and restarting the game I was unable to reproduce the issue in stock. I'm going to get more information and post it in the appropriate thread/forum. EDIT/UPDATE 2: I have determined the issue to be specific to Stock Bug Fix Modules (Release v1.0.2d.2) with StockPlus enabled. My mistake for posting here without more testing first!

I have spent too much time thinking about this. Here's the test imo - what would be be allowed to be used in a Stock Challenge? I do believe separating StockPlus, and pointing to it BELOW the stock bug fixes is a good approach. You can note some of the StoxkPlus functionality that doesn't exist in StockBugFix. It is unfortunate that install order matters. I love the idea of it being a gateway. I still in fact think you could and should point out other works you think are StoxkPlus worthy in the StockPlus thread.

Claw, I love it - but I have to admit, I've found new options springing up all weekend as alternatives. I wouldn't mind something in your set of fixes just because I think people trust them and get a lot of value. If nothing else perhaps point in your thread to these wonderful StockFixes and StockPlus options - they just feel too good to not be stock? I realize StockPlus is a slippery slope... Thermal stuff - https://kerbalstuff.com/mod/775/Temperature%20Gauge%20Killer - Just released https://kerbalstuff.com/mod/719/Thermometer - There are others but I like this one at the moment Other fixes - https://kerbalstuff.com/mod/725/Fairing%20With%20Mass - Fairing mass has correct CoM Pretty borderline (fix or plus) - http://forum.kerbalspaceprogram.com/threads/119561-1-0-2-Menu-Stabilizer - I've used it for 15 minutes and am already in love Other StockPlus mods worth pointing out - http://forum.kerbalspaceprogram.com/threads/80683-0-23-5-MapShowNavBall-show-navball-by-default - Pretty sure you're already aware of this one http://forum.kerbalspaceprogram.com/threads/106710-SAS-Reset - Reset SAS to stability once it is off and being turned back on https://kerbalstuff.com/mod/764/QuickBrake - Set brake when starting something on the runway https://kerbalstuff.com/mod/472/QuickSearch - Search parts http://forum.kerbalspaceprogram.com/threads/54303-1-0-Navball-docking-alignment-indicator-v6 - Docking indicator that matches stock navball functionality perfectly, too much for StockPlus? - - - Updated - - - Once you start you can't stop...one more for StockPlus recommendation consideration: http://forum.kerbalspaceprogram.com/threads/102373-1-0-Crowd-Sourced-Science-Biome-Reports-Everywhere%21-%28May-3rd%29

But even when the window is shown, it should hide when you hit F2 to clear the screen of all UI for screenshots or other general basking in the visual glory. Which is what I think the feedback was getting at since the screen is clear of all other windows and UI. Most mods do this so fingers crossed for you that it's easy-peasy.

I'll humbly note that it's not nice to imply that "nobody at Squad actually think of ..." - it is often the case that you cannot do the things you want to do when working on a development project for one reason or another. I'm sure you meant no offense but I want to combat the general idea that "if only they'd thought to x, y, or z!" I'm grateful someone found the time, skill, desire and wherewithal to not only do it but share it and I know you are too.

I originally wrote, "I do also realize that I wish the [BODY RELATIVE ROTATION] UI had wrapped my head around this concept earlier but in hindsight I'm not certain how it would look in order to accomplish that. Maybe some additional SAS mode buttons? Matching their style and hover-text, the top one could say "Match Rotation of Current Body," a second could be, "Match Rotation of Target Body," the 3rd button, when clicked, would allow you to specify which body?" I have liked this idea more and more as I've thought about it (of course I like it more - our own ideas are always the best in our heads!). I do now see that the whole situation is quite complex. Let me walk through it so others can riff on it (or rip it up) in their own minds. First, let me try to explain in hindsight what I thought I wanted and why I was convinced it wasn't there. I'll do this by looking at the existing SAS Modes: [1] Top Row - Stability Assist & Maneuver Not In Time-Warp: Both of these modes lock my vessel's orientation to a direction, a point in space, that does not move. The orientation of my craft, and the direction my craft is pointing in space, stays static. My craft does not rotate, even though the world rotates around me. In Time-Warp: Exactly the same as non-warp. Since stock Time-Warp kills rotation, but no rotation needed to be retained in order to maintain the expected behavior, everything works as expected here regardless of warp. Expected Default Behavior w/ PersistentRotation installed: No change - and no option to persist a rotation while in this mode or it would mess up the function of this SAS mode? Actual Default-Behavior w/ w/ PersistentRotation installed: No change - but there is an option to persist a rotation while in this mode - I can't think of a use case for this but I'm likely missing something. Handle some other way? These SAS modes seems very specific to not rotating. To Persist a Rotation while in these SAS modes breaks their intended purpose. [2] Second Row - Prograde & Retrograde Not In Time-Warp: Both of these modes lock my vessel's orientation to a vector which changes as the position of my craft orbits. Even while in a circular orbit the direction of "Prograde" changes. While not in Time-Warp, the stock game uses a continuous application of reaction wheels to constantly correct my orientation to be the current prograde. In Time-Warp: Since stock Time-Warp kills rotation, and rotation is needed in order to preserve the orientation to Prograde, the desired rotation is not preserved while in warp. Expected Default Behavior w/ PersistentRotation installed: Persist a constant tiny rotation that preserves the crafts orientation with the prograde marker. This is simple in a circular orbit as the direction of the prograde marker changes consistently throughout a single orbit. In an elliptical orbit the rotation isn't constant and would require changes along the orbit in order to match the prograde orientation at any point. I have no idea how PersistentRotation would/should handle this. If there is a way to program it then prograde orientation should be held and some resource utilization could/should technically be used up to account for the corrections along the way. But mostly I'd personally love it to just maintain prograde without regard for resource usage. ...then there are gravitation sphere of influence changes...I haven't thought through those but I suspect that they change the definition of what prograde is and thus create a big problem. What would be expected here? Actual Default-Behavior w/ w/ PersistentRotation installed: Nearly identical to the expected behavior described BUT it requires you to choose your parent body before it'll behave that way. Perhaps because of the drawbacks I described of other usage scenarios. [3] Third Row - Normal & Anti-Normal Stock Behavior !In Time-Warp: Holds direction of Normal or Anti-Normal which does not change. What does change is that my craft's orientation towards the body I am orbiting is changing. But in reality, my craft isn't changing it's position, the world is rotating around it. Stock Behavior In Time-Warp: Same as non-time-warp behavior. Craft is fixed in orientation, thus things rotate around the craft but the craft doesn't persist any rotation. PersistentRotation Expected Default Behavior: This is an interesting one but given that the non-warp behavior doesn't persist any rotation then I have to go with warp isn't supposed to be rotating. But I totally buy that there should be an option to persist a rotation (a roll) in order to maintain a constant orientation to the parent body. ...that means we'd end up with a lot of questions about what to do about non-standard orbits. PersistentRotation Actual Default Behavior: No persistent rotation as desired. Option to persist a rotation as desired. Win! [4] Fourth Row - Radial & Anti-Radial Stock Behavior !In Time-Warp: Holds direction of Radial or Anti-Radial which changes as my craft orbits. Stock Behavior In Time-Warp: Just like other modes that move while I orbit (Prograde/Retrograde), time-warp doesn't persist a rotation to keep up. Nor does a single constant time-warp suffice if I'm in a non-circularized orbit. PersistentRotation Expected Default Behavior: Ideally this would work by persisting a rotation to keep the craft oriented the same way it is during non-warp. PersistentRotation Actual Default Behavior: Requires user to choose to persist a rotation. Doesn't have a mechanism to handle non-circularized orbits. Just like Prograde/Retrograde. [5] Fifth Row - Target & Anti-Target Skipping this one as it may be more complex and either way I've made my primary point already. A solution? Additional SAS Mode Options? You'll see above that my expectation is that with PersistentRotation installed I would expect the default behavior in warp to match the stock behavior in non-warp. This gives us a good guide for default Persistent Rotation behavior imo. Now UI could reflect this behavior somehow - indicating this functionality amongst the stock UI has the added benefit over just unexpected "default behavior" because it communicates to a user that something is happening different from stock. I think it's fair to say that the craft must have SAS engaged in order to persist a rotation that keeps the craft oriented in relation to another body. So making the BODY RELATIVE ROTATION options SAS modes makes some sense. Perhaps there are only two at the bottom of the current options: Perhaps there is a 3rd circle to the right which allows you to open a menu and select any body? Once these options were there, the "maintain orientation with parent body" could be ticked on automatically when the user selected other modes such as Prograde, Retrograde, Radial, and Anti-Radial. By doing so, the default behavior in time-warp would match the stock behavior of non-warp. And other visuals could be done to represent the reality, if the player had Stability selected and turned on Match Parent Body Rotation, it would turn off Stability I would think. It's too bad Stability doesn't function more like a "Kill-Rot" - then it might still make some sense to keep it on while you selected Match Parent Body Rotation. Anyway, this turned into something much longer than expected so I'll let it go at this. Hopefully the idea is spelled out enough to mix and mingle with other ideas.

This mod is great! It also makes me frustrated with all the science that doesn't seem very well thought out or creative. There is a stupid amount as KSC when you consider that other reasonable tests don't exist.

Thank you! I've been using that other plugin to do this but have to admit I was at least slightly concerned that the code was more complex than it needed to be and thus might be leading to other issues.

Sadly, the list is already too long, is there any easy way to prioritize a list like this? Secondly, there should be a list of things that brand new players want/need that has quite a bit of priority over the things us veterans desire for advanced features/customization/etc. Keeping in mind that the better job the game does at ramping up newbies to the game the higher degree of complexity and sophistication the game can have at the more advanced levels. Newbies and veterans alike benefit from games that find a way to teach complex subjects and game dynamics to new players quickly! Some ideas then: 1) New players could use a better introduction to the NavBall. 2) It would be nice if the game explained more about what was wrong - examples: - your parachute burned up or ripped off due to when it was deployed - your probe has run out of electric charge, that's why you don't have control of anything - your rocket has flipped due to their being more drag pulling on the nose than there is pulling on the tail - this is the traditional way of getting the "cart in front of the horse" - the horse slows down more than the cart! Build rockets that force the cart to always be slower than the horse! 3) I've watched a lot of smart people fail at KSP and get very frustrated because it's not working "the way they know it should!" Comitic failure is great entertainment - failure that a new player doesn't even begin to understand (or worse, they believe they understand it better than the game and the game didn't implement it correctly) immediately feels like crappy software to a new player. Career mode (normal difficulty) could/should start off with tutorial content and contracts which demonstrate each component of the game at a time: Rocket Building; Rocket Launch and Piloting (what is the NavBall? how to use it?); Science Gathering and Recovery; Rocket Engineering and Design (from staging and thrust to weight ratio to Rocket Engine Fuels and DeltaV; Electrical systems; Stable Aerodynamic Flight; Control Surfaces; Reaction Wheels; Kerbal Skills; Getting to orbit; Orbital Maneuvers; Gravitational Capture; Engineering Planes & Rovers; Craft Recovery; Landing on Another Body with unknown characteristics such as gravity and atmospheric conditions; Interplanetary transfers; Simultaneous missions; ... where does the learning stop and the game begin?? I've found my learning experience over the last few years to be a fantastic game that I hope never stops - I hope they are both there throughout Kerbal Space Program's lifetime ... there is after all "Moderate" and "Hard" difficulty levels to challenge people on their skills. ...but I do believe the game could help people learn, or re-learn, what they do not know. And ok, and idea for a more veteran player - Joysticks - it's still terrible for these reasons: 1) I plug and un-plug lots of things from my PC depending on what I'm playing (steering wheels, joystick, gamepads, keypads, 3D mouse, throttle, racing pedals, gear-shifter, etc, etc) - KSP gets confused regarding which one is plugged in causing me to go through setup every time I play. Ideally I could plug in controllers AT ANY TIME while I'm playing but as it is I can't even just make sure they're plugged in before I launch the game. 2) Have a mentioned that control setup isn't available in game? I have to revert to the opening menu in order to make adjustments to any of my controller settings. 3) My (quite fancy) controllers have things like, left pedal on Axis 1, right pedal on Axis 2 ... KSP wants to know which axis I'll be using for Roll/Yaw? I require KSP to understand this common issue and either merge the two axises into one or allow me to pick different axises for left and right input. - Note, I use 3rd party software to solve most of these problems - they just are huge inconveniences for all kinds of reasons, many of which result in them never working and thus me never using my joystick(s) like I wish I could. Ok, a simple one, Pods should require electric charge exactly like unmanned vehicals ...and the "Snacks" life support seems like a wonderful way to do life support that doesn't lead to death or game over and fits the feel of the game. Many more that you've already listed. I mostly wanted to chime in about how these more complex desires would be better facilitated by a game that does a great job introducing them to new players (instead of dumbing everything down to keep it fun enough for new players).

Scott Manley shows this happening in his latest Tutorial video at the 6 minute mark: https://youtu.be/cEx7klK7S0g?t=6m My search turned up two threads with this problem - the other is newer and has more activity in it - this one was reported earlier and thus is the original? Anyway - perhaps they need to be merged. http://forum.kerbalspaceprogram.com/threads/118286-Warp-to-is-broken-sometimes?highlight=warp

Scott Manley shows this happening in his latest Tutorial video at the 6 minute mark: https://youtu.be/cEx7klK7S0g?t=6m

Thank you - that's working nicely

Have you considered something that defaults the temperature gauges to disabled in order to prevent people who use your fixes from hitting the memory leak? Perhaps not worth it if a patch is forthcoming. It is a bug that can really get ya. Despite knowing about the leak myself I managed to ruin a mission of mine because my plane's landing gear began to overheat unknowingly to me. When I saw the gauges were on I was shocked I was experiencing heat while flying to a survey location. So I turned them off. Then of course they came back when I landed and reloaded. I turned them off again. Then the game crashed. Then began a cycle where I would load the craft, turn off the gauges as quickly as possible, fly as far as I could, then the game would crash. Other than this one mission I've never had crashing (despite quite a few hours of play). If I understand correctly the following was happening: That craft had developed a lot of memory that it needed to have loaded in order to have that craft loaded - this didn't go away when restarting the game I quite likely was making it worse everything I would re-load that particular craft because the gauges were defaulted to on I never made it back to KSC where I could recover the craft because after every crash I would lose my progress (no auto-save while in flight) Eventually I recovered the plane from where it had landed on the other side of Kerbin - missing out on my other survey points and the part recovery efficiency. Anyway, just an idea if you think it'll be awhile longer before an official fix.