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 :-)

ahh! It's been a while since we've had an experimental for a KSP release that felt relaxed and quality driven and not date driven. I'm optimistic that we won't need any hot fixes pushed right after 1.1, but I won't really be upset if we do :-)

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. :-)

*sigh* First off, I'm probably the person who's spent the most time working on getting realistic SRMs in game, so I (1) don't understand why you think that's what I was saying (2) do know that for SRMs to work well w/ stackable segments in game a new fuel flow mode is necessary*. Secondly, adding propellant in an SRM casing means some combination of added thrust or added burn time because one can shape the grain. Without changing the geometry of the burn surface, just adding segments increases surface area -> increases thrust, but one could also shape the grain to maintain surface area with a taller motor -> increasing burn time. "simply" is so literal. The biggest challenge with AdvSRBs was trying to get KER or MJ to understand the custom fuel flow for custom engines, because mod makers don't have all of the fuel flow modes that reasonably exist, and they can't teach the game new ones in a simple way. *Which was the point of the post

It really really is, in any likelihood. Minor hopes: significant performance improvement in resource flow (right now it's...pretty heavy). Big hopes? Stackable SRM style resource flow mode (which is actually pretty simple). Best hope? Make fuel flow no longer enum so that mod developers can more easily create custom fuel flow options.

because some people always make a fuss the other way, I'd like to say I'm glad this info was posted in the forum in its usual place :-) TBH, with devnotes the way they've basically been since 1.0.4 was released, I don't mind waiting the extra day, especially if there's even a bit of news :-) (I'm sure y'all are as ready to be done with getting KSP on U5 as we are) also...tomorrow is only a few hours from now... :-P

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.