kujuman

I really like these ideas! Allowing LKO operations to be end-game is pretty nice--I don't like having to fly to Jool to get the science/funds I need to do a crewed Duna mission ;-) Yay space-stations!

One of these things is not like the other... It's just unwise to compare F9 or NS to the STS, in practically any capacity. F9 is designed to be an economically competitive choice. STS was designed to get support from Congress. Re-using F9 stages is an opportunity to reduce costs. If it doesn't work out economically/practically, SpaceX doesn't continue the reuse avenue, and just flies expendable F9s. When the STS wasn't easy to turn around, well, what are you going to do? Tell Congress you need to design a new vehicle? Build new orbiters for each launch? For a really quick and dirty breakdown of labor costs at SpaceX by type (manufacturing, engineering, overhead), just look at the careers page at SpaceX's site--the vast majority of positions are for manufacturing, so one should not just say, oh, SpaceX overhead isn't reduced, therefore reusability is DOA economically; okay, so what? (Yes, there are differences in wages and costs other than wages per position, and turnover probably doesn't occur at the same rate, but as a first level approximation, it ain't bad). Sure, maybe 20% of departments at SpaceX don't need to see increased labor costs w/ increased flight rate, but that 20% might have 50% of the labor. 20-30% in cost/price reduction w/ reusing first stages doesn't seem like a wildly inaccurate claim. It won't happen for several years, and the launch rate might need to reach some minimum first before it approaches that territory, but it's probably a reasonable guess. Unless we know Musk's assumptions (we don't) we can't judge very accurately the validity of the choice. Betting the company to save 20% might not make sense for established players, but betting the company for 20% if the company is a start-up has a better expected value. Reduced prices by 20% on top of 50% compared to competitors might sway customers who are on the fence already. But all of this without data is just faffing about. :-) Nibb is absolutely right: SpaceX is taking a gamble--if it pays off, others will soon follow suit, if it doesn't maybe SpaceX will vanish or be bought-out. We get to see how things go too; but until then, let's just be glad there are amazing efforts to do things a little better :-)

There's a pre-release for 1.1 here If you don't have 1.1, or want to keep testing in KSP 1.0.5, if you copy NavUtilRPM.dll from 0.6.0 to use with the rest of 0.5 RC3, it might* work okay. :-) If that also won't work, I'll build a .dll for your testing use when I get to my development computer. * Looking at your logs, the NavUtilRPM.dll from 0.6.0 loaded in fine into 1.0.5, and it contains the relevant code. NavUtilToolbar.dll didn't load because it requires Blizzy's toolbar to be installed (so that's expected), and NavUtilLib.dll didn't load because it's only for 1.1, so I think it'll work.

0.6.0 is only for 1.1 and later, as I had to make some big changes to get it working that are not backwards compatible. Since you're in 1.0.5 right now, let me try something that might work, I'll report back when it's ready.

My F-16 has no problems in stock :-) It's almost like I designed something based upon the conditions in which it'd operate. Needs better FBW though. @regex your F-16 is one nice looking bird :-) TL;DR Use the tools presented to you the way they are meant to be used. For FAR, think in voxels. For stock, think in parts. It seems like you're claiming stock KSP is wrong because something you made to work with FAR isn't compatible...should one complain to Ferram that planes designed for stock don't work in FAR?

@DeputyLOL I've added a part module for making the flight data public, and it'll be in the next build. I've not tested it in RPM, but I think it should be ready to go (I don't really know the RPM config side of things, unfortunately. If you get a config that should work, but doesn't, send it my way so I can give it some more testing.) If you end up wanting more information, that's super easy to add (as long as it's being calculated already, which most stuff is), so just let me know. Module Name: ModuleNavUtilsInfo Method: NavInfo Variables: SELECTEDGLIDESLOPE glideslope in degrees BEARING runway bearing DME meters distance to the runway (glideslope, not localizer) ELEVATIONANGLE elevation in degrees above projected horizon LOCALIZERDEVIATION difference in degrees between bearing and runway heading GLIDESLOPEDEVIATION difference in degrees between elevation angle and selected glideslope RUNWAYHEADING compass heading of runway in degrees SELECTEDRUNWAYALT selected runway altitude (meters) SELECTEDRUNWAYIDENT selected runway name (the long name) SELECTEDRUNWAYLAT selected runway latitude (in decimal degrees) SELECTEDRUNWAYLON selected runway longitude (in decimal degrees) Version 0.6.0 (for KSP 1.1 experimentals) is available to download from GitHub https://github.com/kujuman/NavInstruments/files/201068/NavUtilities.0.6.0.zip . It should work for the 1.1 experimentals, and is pre-release itself. Please report any bugs you might find in it.

That should be easy enough to do if I just need to make things public. I'll take a look at RPM and see what I need to do there. (kujuman, here's the bookmark https://github.com/Mihara/RasterPropMonitor/wiki/Variable-handlers )

Dunno if a change in functionality, but I'd previously (in 1.0.5) used if (Event.current.button == 1) { //stuff } to check for right-clicks. http://docs.unity3d.com/ScriptReference/Event-button.html. In 1.1, I changed it to if (Event.current.alt) { //stuff } and now fires when the user holds down the Mod key and clicks on the AppButton. See if either of those work for you.

I think for the most part the code will work: both versions use the same renderer and current runway data. The override on the runway name to be the marker won't function (I *think*) but that'd be super easy to fix once I have RPM to test on. I've implemented the fix suggested by Ser. It won't be in a version for 1.0.5, but that problem should be resolved in the 1.1 version. In general news, the update is coming along nicely--I don't think there's a lot more for me to work on, at least until I have RPM etc to test on. One side effect of the update (as you might see in the pic I posted a bit ago) is that the washed out color that appeared in 1.0.5 is also happily solved :-) One thing I'm toying with is adding a KSPedia page (or several) for NavUtilities, but only if there's useful content to add, so if you have ideas, please suggest them. Also, mini-changelog, in case I forget later :-P Marker Beacon audio volume was moved from Voices to UI To bring up the settings window, Mod+Click (Alt+Click in Windows, Option+Click in OSX) the AppBar icon, no longer right-click NavUtilities windows should now auto hide and restore when the player presses F2

I think that's in the regular RPM package. I can try converting them to .dds, sure. The images used for the digital HSI and AI are in fact hard coded at the moment. Oh! And I suppose I should update this for 1.1... In addition to fixing compatibility, I've pulled a fork by @Ser a while back, so the HSI will work with Waypoints for stock contracts. I've not be able to test it yet, but it looks like it'll be pretty useful. I should point out that only very basic functionality works right now, and the settings menu isn't yet functional. I've been unable to test it for RPM for 1.1, but once RPM gets updated, I imagine integration into that will work fairly straightforward. When I get closer to a more full functional 1.1 release, I'll start putting together a build + uploading it.

One small thing I finally figured out in working to get my RenderTextures to show. I had been using KSP/Alpha/Unlit Transparent for materials I'd been writing to the RT. Shader.Find("KSP/Alpha/Unlit Transparent") doesn't throw an exception, but nothing will show up on the RT. I substituted Sprites/Default and that solved the problem.

Hi all, So this is a simple-ish idea: models of plaques/memorials for general use, but perhaps specifically for fallen Kerbals. I've seen a lot of people planting flags at the KSC to memorialize their fallen Kerbals, and thought it might be nice if there was a fancier option available. Memorials could be simple markers, more tradiational gravestones, memorial trees/flowerbeds/bushes, etc. In practical terms, they'd likely work as either KIS/KAS place-able parts (similar to the ground pylons), although they *might* be able to use the default FlagSite partmodule (used on the stock flags), so that players can still write their text on the memorial site. If there is interest in this idea, I'll try to prototype the functional aspects of such a memorial, but I doubt I'd be able to make a very nice model :-)

my thoughts on this IVA on external views are (1) some IVAs are STUNNING, especially mod ones. But IVA is hard to do anything in: I could see turning this on while doing a burn or something just for kicks :-) (2) it seems like something that is a dev step towards transparent windows--a way to test that IVA orientations are correct and such. Easy to just make a dev thing in the public release (like the aero debug lines :-) ... Just no thermal men leak please :-P ) (3) if textures are revisited for the new shader possibilities in U5, that seems like a reasonable time to mod the textures to have actual windows--only have to touch the texture once then (4) clouds, aero visuals, emissives, flags on certain parts, water being blue, the kerbal eye gap bug, the new (at the time) VAB and SPH internals, the kerbal workers in the VAB and so forth are all just visual enhancements that could be or are in the game. Some are more resource intense than the others, but they all contribute to the game (and who knows, maybe the IVA pics sell KSP to more people to enjoy :-) ) point is, Kerbal Telemetry Simulator could have the same physics as KSP, but it sure would feel different :-)

As I understand it (and I might be completely off-base), it's official as in "Approved by" or "Developed with Assistance of" ULA, but it might not at all be "SQUAD official", if that makes sense.

the pic was presented by Das and on stream you could see it had the 1.1 style UI before it got cropped. Also was RT by KSP twitter, so legit 1.1. but yeah, another case of a mod proof of concept becoming stock? Neat

In case anyone wants the link for the VOD of just the interview you can nab it here. http://www.twitch.tv/dasvaldez/v/53283711 Well worth the time--hear about how Mr. Bruno first started getting into rocketry (a few of his rockets made it into flight before exploding!), and how Das offered one neat trick to improve fuel transfer between vehicles that ULA might have to look into :-P But seriously, a very fun, a very informative, and very real interview--absolutely worth checking out at least once :-) ULA mod preview (not ready yet) (not 100% sure who's involved, but at least ej_sa, and ULA has been assisting as I understand it, but I don't know in what capacity)

also, with another target, if you do manage to stick the landing, the rest of the logistics become complicated. Might as well use what you think should work (I also imagine the barges get incremental upgrades as they collect data from landing attempts)

I think that's just his having played a lot of KSP, so he knows what works and what doesn't, and what's not intuitive, and what's just plain broken. (His background in software development also gives him a more critical eye) KSP is a lot more accessible with only a handful of tweaks (KER and some bug fixing), and he's just saying even as great fun as it is now, it could be even better :-) I think this stream is going to be a real showcase of amazing :-) also, I think it's more showing what ULA has in in the works via KSP than trying to sell ULA on using KSP :-)

I disagree that this is something that should be a forced change in the stock science mechanics, for several reasons. First, in response the the first rational for the change given (that maxing the tree in Kerbin's SoI isn't fun)--well, that's how other players enjoy the game, and it's unreasonable to limit what others can do to have the stock game better fit one's own play style. Second, in response to the comment that just a quick mission to Minmus to grab a bit extra science, that's not inherently a bad thing gameplay wise. Sure, it can help unlock a node we want/need for something (say, getting better engines for an SSTO that *almost* works), but that seems like a good thing--one doesn't have to launch a massive Jool mission to make play in LKO more interesting. Third, as weird as the science system is (finding out the temperature of a valley on Dres helps my engineering team build a bigger battery? Umm, sure...) finding out the environment from different parts of a body tells you about *the body*, and not just about the rock you landed near. If I land on an animal and it has fur on its back, I would later want to do a fly-by of its belly to see if it has four legs, and land another probe on its feet to see if it has claws or hooves, and then rove to the mouth to inspect the teeth, and the exploration of the parts tells a story about the whole. And for players who don't use biome maps or lists, maxing a body is a puzzle in itself--hmm, there's a farside crater I landed in, maybe the other craters are interesting as well! Oh, Duna should have loads of science! But there aren't distinct features...hmm...where should I try? I think a mod like this though could be very popular (for the reasons stated), just as the mods that reward one for really in depth exploration and development of a single body are. But I think the stock game does a reasonable job of giving the player a choice of where to direct his energies, and enforcing a particular playstyle isn't what makes KSP. :-)

In general, there's nothing too taxing with using cloth simulation real-time for the bag (not sure how the cloth engines would like zero g and a vacuum though). And once you can encapsulate the target body, the (1) point can be abstracted away and depending upon what you're mining, using a laser to vaporize material and then using a magnetic collector may work (you still have the "can't anchor to the target" problem though

Yes, it's very possible, even using stock SolidFuel in NO_FLOW, but then you need a custom engine fuel flow mode (which is actually pretty easy, but since the stock fuel flow types are enums and I don't think one can be added via mod, it's slightly more tricky) (that is, the fuel flow has to be programmed into the engine, rather than in the fuel config) http://forum.kerbalspaceprogram.com/index.php?/topic/35551-part-advanced-srb-wip-v07-by-kerbal-science-foundation/&page=1 Considering how often better SRBs have been requested, and how relatively straightforward it is to make them better, I really don't know why other modders/Squad hasn't spent any time on doing them properly. The biggest hurdle for me was that it was difficult to figure out how to interface the new engine types with MechJeb/KER to get accurate dV counts, but I think that's even pretty simple, just I didn't know how to do it at the time. And actually, even a NO_FLOW resource in one part can be used by another part, but it requires a slightly more involved resource request mechanism than just blindly requesting fuel and having the default fuel flow logic work out where to take it from.

video of landing from barge https://www.instagram.com/p/BAqirNbwEc0/?taken-by=elonmusk

I think worrying about the Vector as good for exactly one role is both (1) short-sighted and (2) really focused on one part rather than the philosophy behind it. (1) Saying the Vector is only good as a shuttle engine discounts both the idea that good shuttles/spaceplanes can be vastly different in form and function from the STS (so yeah, even if the Vector only makes sense in career for recoverable spacecraft, that doesn't mean it's only good as an STS clone) and that there are other realistic applications for the engine. Permanent space use makes a lot of sense for the Vector--as a landing engine, it has good gimbal for control and a relatively low profile (plus a generous crash tolerance), so it can better fit under the landing legs we have. Stick it on a fuel ship from a moon surface where you're mining to an orbital fuel depot, why not. (I also use them sparingly on space stations because of the gimbal meaning that I can do burns more easily if there are ships attached.) (2) Even if one thinks the Vector is only good for an STS clone, most of the other parts in the game could also be viewed as having only one purpose/ill-suited for balance reasons; the Cupola is ridiculously massive and really has the traits that it has a cool IVA and overall look; the Mk2 Lander can is also massive/kerbal; the Stayputnik has an odd form-factor and no SAS nor reaction wheels (it's a decent back-up for normally crewed ships, and sufficient for rover use); the Mk3 engine mount is pretty single-use; the NERVA is pretty single-use; the batteries all have the same eC/mass, but the costs are not equal per eC--why*?; the ladders aren't at all balanced for length/cost/mass; the whole line of Big-S aero surfaces are just good for STS clones; oh, I'll just stop there. Why gang up on only the Vector when there are plenty of other balance tweaks a lot of people would see as useful? My point is, the Vector, along with most parts in the game, has a job it does well that isn't easy to capture just based on TWR or Isp or cost/Thrust or form factor. The Vector isn't always the right choice, but it's not always the wrong choice, so that means it's not terribly unbalanced. Part of the reason I like the Vector on my rockets in career is just that it looks pretty cool to me, and since my Funds can only be spent on my rockets, I'll spend some for aesthetic reasons. *some of it is heat tolerance, but it's mostly paying more to reduce part count/get a different form factor

heh, I've not seen the T3 tracking station in career in a LOOOONG time--I never really bother upgrading to it :-P I think the T2 station looks fine as is.

One thing to clarify: if you stack attach anything* to the "docking" node in the VAB/SPH, you will be able to use the docking port as a decoupler as well. The reason you don't see the "Undock" option is because the game logic only recognizes docking when docking ports get connected in the flight scene. So because you never docked your craft together (they came preassembled), you don't have the Undock option. Once decoupled though, the docking ports will work normally, so next time you redock, you'll see the "Undock" option :-) * so no just another docking port