Conventia

Isn't it possible to only remove the parts from the stock category if CCK is there, using an MM patch?

My preference for DLC's with regard to KSP is for them to be 'content' rather than 'functionality'. I suppose the distinction may be a bit vague, so I'll try to explain a little. For example, in the case of scenarios, I'd prefer that the core code required to enable scenarios be part of the core game while the actual scenarios and perhaps 'plugins' for specific features be part of the DLC. This would allow modders access to the same functionality as the DLC, with regards to how it accesses the game. At that point, the only mods that would need to depend on the DLC are ones which want to rely on the specific functionality of the DLC for whatever reason rather than writing it from scratch. I suppose I have this viewpoint because one of the things I'd really like to see with KSP is the core functionality becoming more flexible and extensible, in much the same way that the new comms system in 1.2 can be extended (in theory) to support functionality like RemoteTech, rather than having to write it from scratch.

What's the modifier for a declined contract? Thanks.

Whether I agree with his opinion or not, you're misunderstanding it. Engines and Lights would be game features that have on/off as a mechanic, inherent to the feature. You cannot turn engines or lights, as features, off. They are always part of the stock game. (I suppose you can choose to ignore them, but that's also not turning the feature off.)

Hmm... the issue seems to start here: [LOG 02:38:24.733] Packing Harrier 1 for orbit [LOG 02:38:41.422] 9/12/2016 2:38:41 AM,KerbalAlarmClock,Reducing Warp-Transition [LOG 02:38:42.523] Unpacking Harrier 1 [ERR 02:38:42.805] Infinity or NaN floating point numbers appear when calculating the transform matrix for a Collider. Scene hierarchy path "HECS2.ProbeCore (Harrier 1)/model/VenStockRevamp/Squad/Parts/Command/ProbeCores/HECS2(Clone)/Hecs2Tops/Collider" My assumption being that there is a bad interaction between KAC stopping warp and PR applying the appropriate 'rotation' to the vessel after warp is over? PR wouldn't have to have an exception for it to be 'at fault'. All the exceptions below this are probably due to the bad unpack here. I appreciate you taking the time to look at it. Thanks.

I just experienced an interesting bug while playing RP-0/RO/RSS. It's reproducible (I've had it happen 3, after reloading to a point before the bug). What happens is that the ship ends up 'somewhere' in the sun. First in the sun's atmosphere and then on a launchpad at the sun. Anyways, I have logs, so hopefully they're helpful and obviously, I can redo it and get more data if you want. Or if you think the bug isn't with PR, I can go poke other people. https://gist.github.com/ahmedcharles/93e87d6c3683183d947b93681d56a6b5/raw/51815d3a31f6b5e5309753c542bbf43eee875010/KSP.log https://gist.github.com/ahmedcharles/93e87d6c3683183d947b93681d56a6b5/raw/51815d3a31f6b5e5309753c542bbf43eee875010/output_log.txt

I don't remember what the original quote was and it's largely irrelevant, since the reasonable concern isn't that the feature is bad because it has a toggle. It is that resources were spent on a feature which is expected to not be used by some subset of the player base, when there are features which could have been implemented instead, that more players would take advantage of. Note, this isn't really my opinion, but it is the 'obvious' tradeoff involved here.

There's a way to view biomes in stock?

When reading the dev notes, my assumption was that the parts would not be released due to a reduction in scope, due to wanting to release sooner rather than later. If that assumption is true, it would make sense to release the finished assets now, since they would require no QA time or resources (modded installs never require resources so limiting them to modded installs implies this). However, this doesn't preclude releasing the parts in a future update, which is what it seems @AlamoVampire is concerned about. Granted, I wouldn't expect a promise of these parts appearing in the future, but it would seem reasonable to expect the obvious clarification, which would be "Just because we're releasing the assets in this release, does not preclude us releasing the assets as parts in the future." That clarification would seem to make everyone happy? Anyways, thanks for all the awesome work and I will miss videos of exploding Kerbals next to wheels/legs and think of you.

There is the occasional mention of range restrictions/requirements for various launch sites. Is there a mod that shows what these are or penalizes you for exceeding them? Or is there a website that has a list of which launch sites have which limits, so you don't end up exploding over some heavily populated area with toxic propellants?

I noticed the same issue with the dV discrepancy. I wouldn't suggest changing the mass of the fairings back to their original, unless that makes them more realistic/accurate. Most of the time I'm still able to execute the same flights just because there's enough excess dV so that it doesn't make a difference. It's also the case that I don't mind as much because I'm advancing in cash faster than the tutorial, due to completing lots (over 30-40) of satellite contracts. As an example, I'm not using a kick engine for the Mercury launch because I completed the tech for the H-1/NK-9V launcher before that time window, so I'm just going to use that instead. It's more expensive, but I don't like solids, so using a completely liquid launcher makes things nicer for me. Anyways, thanks again for the series, I can't wait to get to the moon landings, though I can imagine it might take me a little while since I'm trying to use my VAB efficiently, etc.

I just checked, the new dev dll fixes the issue I was seeing and the contracts get regenerated almost instantly. Thanks

After playing more, I've noticed that entering the tracking station or completing a contract will spawn new contracts but warping or just waiting doesn't cause spawning to happen. Hopefully that helps you narrow it down.

As far as I can tell, it's based on the tag that's created in github: https://github.com/KSP-RO/TacLifeSupport/releases Note: https://github.com/KSP-RO/TacLifeSupport/releases/tag/V0.12.3 vs https://github.com/KSP-RO/TacLifeSupport/releases/tag/v0.12.2 So, it should be as simple as pushing a tag on github with a lowercase v that's pointing at the same commit as the current release. And that's cheap enough to be worth trying since you don't need to create a new release.

It seems to refresh contracts on reload (consistently). Waiting sometimes results in a refresh but not always. I don't see any contract configurator errors, but I'll send the log anyways.