sjbuggs

The predictions take into account rotation of the planetary body, which definitely does help on airless worlds. Particularly say if you have a base and want to land there.

I've been looking forward to US2 dropping and haven't been disappointed. I mean seriously, pegboard in the Radial Attached KIS module? Beautiful. I do have a couple ideas. First, a wedge version of the Experiment Storage Unit seems like an great fit for the mod. The other idea is more involved, but perhaps a radially attached bay for wedges so they could be attached as clean looking blisters. I did something sort of like that outside of US way back by getting a tweakscaled MK3 Cargo bay radially attached to a ship to hide the science experiment clutter. Regardless, thanks for the amazing mod, and look forward to your next updates.

I'm using the same light actually, but for a different aesthetic there is a station light I remember from the MOLE mod that probably would blend in well since it has a white frame. Not much to look at but it'd offer a minimalist light look.

Actually this reminded me of a thought I had recently (not sure if anyone came up with this first, not claiming credit if so), but putting it out there for the powers that be: Perhaps alter(ed?) Kontainer parts that were treated similar to how MKS handle bays in some Tundra modules and the drills. So a 2.5m Kontainer might have say 4 bays, each of which roughly equivalent to a single 1.25m Kontainer. The idea being you cycle through what's stored in that bay to mix and match what gets stored in it on the fly.

Same as stock actually. KCT is all about what happens before launch.

Regarding this, one thing I noticed the other night was other deployable items worked -- specifically, the inflatable heatshield and the petal fairings from BDB. So taking a look their respective configs. The airbrakes have this setting: dragModelType = none Whereas the other two are: dragModelType = default It makes me wonder how tricky it'd be to hack an alternate airbrake part that didn't have the control surface capability but did act more like a deployable radial heatshield.

Alright, figured that was a possibility but also figured you might know who maintained it and maybe point me in the right direction. Or is it more a matter of whoever steps up to first affair?

Minor issue, but some of the newer parts like the Kane-11-120MM and the Sarnus-BFBM lack any habitation time for USI-LS unlike older parts like the MOL and KANE-11-80MM. Looks like an entry just needs to be added in the usi-ls.cfg compatibility file for those.

The flaw I speak of isn't just the chance of something going wrong. It's the inherit flawed idea of placing a crewed vehicle where: (A) debris lost from lifter could strike the crewed component causing the loss of the crew. (B) in the event of a major accident on liftoff, no way to abort and save the crew. Yeah, both shuttle losses could equally be blamed by go-fever at NASA, but that doesn't change the fact that the concept of the shuttle was a failure from both an economic and safety standpoint.

I think after two loss-of-vehicles incidents and 14 dead astronauts, the design was flawed enough that no longer counts...

Perhaps that's why NASA is looking at using solar power arrays to power VASIMR?

I've been having a very similar problem while setting up a new 1.3.1 install. Aa splashed down pod "floating in the air", no sea, etc. as well as a stream of NodeReferenceExceptions. Uninstalling SVE and using stock Scatterer worked as expected. Installing SVE outside of CKAN seems to have fixed the problem so the conflict looks to be there.

I love the mod but there are times when the parts don't mesh well with parts from other mods as well as the stock parts. Is there a sane way to support both the stock and Vens models at the same time? Or only include a subset of the mod?

Not for stock, but one thing I found to be really profitable with USI MKS was to mine Exotic Minerals and Rare Metals on Minmus and delivery that to Kerbin. One of the 2.5m Kontainers full was worth about 750k funds.

I definitely need to add this to my career game... I'm so done with the mk1-2 (lack of symmetry makes my eye twitch). If you support CTT, using orbital command pod or heavy pod from the Near Future Spacecraft ought to give a good starting point for balance.

Were you able to take a look at this? I'd be happy to test out a modified version if you have one.

Can't exactly agree with the numbers from TheRagingIrishman (but can with with the point about single thread performance). The 3770k = 3.5 GHz w/ 3.9 GHz Turbo (http://ark.intel.com/products/65523/Intel-Core-i7-3770K-Processor-8M-Cache-up-to-3_90-GHz) The 1290 = 3.7 GHz w/ 4.1 GHz Turbo (https://ark.intel.com/products/series/78580/Intel-Xeon-Processor-E3-v2-Family) The IPC of the cores would be the same (the v2 e3's are really Ivy Bridge i7's), so clock wins. If you overclock, get the i7. If you are going to stay stock, your actually better off with the e3.

Relocated from the development thread. Couldn't test for a while I ironed out things on a new system. Running v1.7.0 under KSP 1.2.2. Without airbrakes deployed, point of impact is close, <2 km deviation. When airbrakes are deployed before planning the burn, I didn't catch the exact amount due to night landing and missing pausing before impact. However the deviation exceeded 300 km last I saw. This was using stock airbrakes with the ignore max temperature set to eliminate the ablative brakes mod as a variable. So brakes seem to be ignored completely. The rocket re-enters facing retrograde, and the brakes are mounted with that facing in mind. If you think it'd make a difference, I can throw something up something meant to re-enter prograde.

My old (Ivy Bridge) system melted down, so haven't had a chance to try this until hopefully this weekend with replacement system. Does Trajectories 1.7 work on with KSP 1.2.2?

I see why predicting the future state of the vessel would be a problem, no issue there. However if the airbrakes are deployed during the de-orbit maneuver setup and kept deployed through landing, what's the change that requires prediction? Wouldn't that just add extra drag throughout re-entry? Just curious since that scenario seems different enough from staging changes during re-entry where chutes add drag, staging changing mass and drag, etc.

Love this mod, I have a KOS script that lands a SSTO rocket on the runway, well most of the time (some bugs to iron out still). Still, I know parachutes aren't supported due to staging reasons, but what about airbrakes? I kind of figured if they were turned on before planning the deorbit burn that Trajectories would be able to take that into account but not seeing any difference between the two. Generally, the airbrakes would burn up regardless but wanted to try with the Ablative Airbrakes mod to shorten the time to land. Full disclosure, still running 1.2.2.

Building upon a proven design is a far cry from building a spare.

In general, I'd considering it a losing bet that congress would do anything because it is logical... and don't get me started on the POTUS.

OTOH the more times you launch, presumably the better the data you get on LOM probabilities and more opportunities to iron out problems which ultimately should help prevent future lost vehicles. Consider the chances of an airplane crashing due to mechanical conditions now with say 50 and a 100 years ago. A lot of planes went down in the process of improving safety but things were learned along the way which improved safety going forward.

Love the idea of this, how hard would it be to use a different texture than the stock? Something black to fit in with some of the landing leg and heat shield options in the Kerbal Reusability Expansion would be slick.