johnsonwax

While not a suitable general solution, a very cool specialized solution could be to build a KerbinSide harbor, see if it's possible to put a launch pad just under the water (or something like that), and additionally, put an EPL facility at the shipyard so you can construct vessels directly over the water.

This is excellent information. I wonder if we know anything about how it could be adapted to the atmospheres of other bodies? Clearly there's a scaling of altitude and a scaling of sea level pressure, and a different temperature model. Any thoughts on how we could work out a path from here to there? My guess is that if they've adapted the earth atmospheric model, they haven't developed a completely different base model for the other bodies - instead they just put a reasonable set of coefficients and scaling factors on the same model.

No, I still get it. I've tried it both immediately before and after the 'lock THROTTLE to 0' and no change. Tried immediately before 'unlock THROTTLE' and no change.

Having some trouble unlocking throttle. I've got a routine (adapted from tutorial) to execute a maneuver node and then unlock throttle, but no matter what I do it lets out this big 100% throttle belch for what appears to be a single physics tick before shutting down, which completely blows my careful node attempt. I don't know what in here is triggering the 100% throttle. lock THROTTLE to valThrottle. ... until done { SAS on. set manNodeVec to lookdirup(manNode:DELTAV, SHIP:FACING:TOPVECTOR). lock STEERING to manNodeVec. set shipAcc to thrust_avail(engineList)/SHIP:MASS. set manNodeBurn to manNode:DELTAV:MAG/shipAcc. set valThrottle to -cos(min(manNodeBurn, 2)*90)/2.06 + 0.51. if vdot(dvStart, manNode:DELTAV) < 0 { // starting and current vectors are opposing - we've overshot. lock THROTTLE to 0. remove manNode. set done to True. break. } if manNode:DELTAV:MAG < 0.25 { // Burn slowly until our node vector starts to drift significantly from initial vector wait until vdot(dvStart, manNode:DELTAV) < 0.5. lock THROTTLE to 0. remove manNode. set done to True. break. } wait 0.001. } unlock STEERING. unlock THROTTLE. set SHIP:CONTROL:PILOTMAINTHROTTLE to 0. wait 1. Any thoughts on how to avoid that? I have a pretty good launch/circularize script now. My next step is to build up a library of helpers that will allow me to reliably do a direct ascent to synchronous directly above KSC without over/undershoot. If I can work that out, then a set of helpers to move from that orbit to sync above any given longitude. Looking to make a set-it-and-forget-it script for building RT comm networks.

Put the mod in, tell ckan to remove it, then tell it to install it again.

MechJeb has been updated to 2.5.1

With UKS, you can mine water/substrate and make supplies and turn a surplus that way, but there's no way to turn a profit just from mulch->supplies.

This is normal behavior in the stock game. If you look in Squad/Resources/ResourceDefaults.cfg you'll see: RESOURCE_CONFIGURATION { HeatEnabled = True //Thermal effects for generators and drills ECMinScale = 100 //Do not calc scaled EC till this warp OverlayStyle = 1 //(Integer) 1=Line, 2=Dot, 3=Solid } So warp over 100 and it just ignores EC. You can increase that value there and it'll carry across to everything in the game. Not sure if that's changeable via MM, but I wouldn't be surprised. MM is wizardry.

Two requests: 1) An OKS version. 2) Stockalike textures now that UKS has included those. My suggestion on the parts it can produce is to look at the KIS formula and only make parts that are small enough for a kerbal to carry. So, under 1t and under a certain volume. That way the rules are easy for people to understand. Something like that.

Universal Storage has a dedicated NOMS wedge.

Yeah, I think pausing timers makes more sense.

This. Agreed, but Alexustas is not possessed of unlimited time. Given the choice of getting the ALCOR ascent/descent or KONQUEST, I'll bodge something together for ALCOR and take KONQUEST without reservation.

Grand Tours version file reports the following: { "NAME":"Contract Pack: Grand Tour Contracts", "URL":"http://ksp-avc.cybutek.net/version.php?id=138", "DOWNLOAD":"https://kerbalstuff.com/mod/689/ContractPack:%20Grand%20Tours/download/0.1.3", "VERSION": { "MAJOR":0, "MINOR":1, "PATCH":5, "BUILD":0 }, "KSP_VERSION": { "MAJOR":0, "MINOR":90, "PATCH":0 } } That 0.1.3 link looks like a different version than what CKAN is giving me, and it's still saying 0.90 support. Same problem with your shared assets folder.

It's in CKAN. It works in 1.0.2.

Yeah, there's something to be said for that argument. IRL, you have a fairing standard and you often construct your payload to fit that standard. No such thing exists in KSP. There are no 1.1m or 2.2m parts to tuck into a 1.25 or 2.5m inline fairing. Any inline fairing is effectively a 200% (or something just shy of that) fairing with a warehouse of unused space inside. It's a bit annoying, TBH. That's not to say that there isn't a place for inline fairings, but they tend to already exist in game - engine shrouds, and now the service compartments. I too have having a bit of trouble identifying when I'd use a 100% inline fairing, and it's pretty rare. 105%-110% I agree would have a lot more utility, with the 140% boattail for the expected things.

Grand Tours is showing up in CKAN. Unmanned Contracts is not yet.

Well, there is no 64bit Mac version, and linux will be a more straightforward alternative than Windows in this situation.

As well, I was a bit concerned about the direction of the discussion. Unless you're going to go the whole FAR route and model heat dissipation within the VAB, then the parts need to be predictable in how they'll behave just based on the usual description. That could be as simple as requiring 4 R10 radiators or 2 R20 radiators or 1 R40 radiator on an N40 reactor, but if we're trying to stand on a knife-edge on reactor temp between efficiency and self-destruction, and our only mechanism to work that is to repeatedly launch ships and test in space, that's going to become unfun fairly quick. They can be realistic, but tuned in such a way that they can snap together pretty straightforwardly heat-wise. That is, I think you want a modular, discrete set of reactor/radiator combinations rather than an infinite continuum that requires a lot of trial/error to get working properly.

Polar orbit tends to be pretty easy - a 3 or 4 equatorial arrangement will be just fine unless your periapsis is skimming the atmosphere. You'll have 100% coverage.

Boy, that's all the excuse I need to install linux so I can run 64bit.

Well, the CKAN guys seem to say its preferable that the dev support CKAN directly (at least getting the metadata in the right place in their distro). Sure, they'll pull it, but it's not smooth after updates. And ASET parts do have high dependencies/requirements: I don't think they're at all unreasonable - ASETs gear is absolutely first rate, but there's a lot for people to get wrong in all of that as each of those has its own update path. JSI and firespitter are in CKAN, RPM is, SCANsat is, VesselView is, DPAI is, Reflector is, MM is. Of that whole list, the only thing that hasn't been in CKAN is the ASET part itself.

Given the relatively high dependencies and recommendations on this and ALCOR, would you consider adding these to CKAN?

So, this is why I think the mod community should try to work toward a community common dll. We not only have the problem of everyone getting backed up when firespitter wasn't updated for a week (talk about first world problems...) where if we had more contributors who could have pushed out an update, that would have been a bit smoother, but you also have the distribution problem noted here where incompatible versions are getting pushed around. MM is pretty close to a community common dll at this point. Devs are removing it from their distributions because it's so common, and if you are using tools like CKAN it's easy to ensure that the single installation of MM is up to date - something you can't do with multiple installs. I've got kspapiextensions, firespitter, MM, AdaptiveDockingNode, BDAnimationModules, InterstellarFuelSwitch, KSP-AVC (which has a somewhat different approach to this problem), ModuleRCSFX, and RasterPropMonitor. Now, USI has his own tools that I don't think are used by anyone other than USI, which is just fine as is, but all of those others I listed are used by multiple mods on my system. Keeping them all in check is a nuisance. It seems to me the community (including the devs) would be better served if many of those were merged into a handful of common dlls but in a single package, maintained by multiple people (sarbian could still 'own' MM, but if he had to step away for a while, any of the other guys could easily step in and push a maintenance release out), and pushed up out of the individual mods and into a single install. You'd keep MM as a single dll that handles all aspects of patching mods, you'd keep RPM as handling all aspects of IVA, you'd have one that handled all animations, one for all fuel and resource handling, etc. My $0.02, easily offered since I'm not (yet) part of that dev community having to deal with it first hand.

It's pretty early on to have mods updated for 2.0, so give it a little time.

I'm surprised that the venn diagram of people who know how to find this forum vs the people who have module manager installed is anything but a set of concentric circles.