kujuman

Okay, thanks for testing that. I'll add it to the list of things I'll check when I get home.

In GameData\KerbalScienceFoundation\NavInstruments\settings.cfg The line to edit is UseBlizzy78ToolBar = False Change "False" to "True" Save the settings.cfg file and start KSP

Quick update: NavUtilities still works in 1.0.2 but NOT WITH THE STOCK APP BAR. It is reported to work with RPM (so while in IVA) and I believe it'd work with Blizzy's toolbar (you must change one option in the settings configuration file). I'm not at home this week so any update is very unlikely to materialize before then. Once the 1.0.2 patch is up, I'll start work again on the artificial horizon.

Are you thinking about making custom IVA props, or just getting the config for them? I've got a decent amount of experience doing both, but I'm not sure I could commit that much time, at least until I get NavUtils updated for 1.0

Yes, when the NavUtils update drops I'll be sure to add it.

Yes, the attitude indicator is still a WIP; I had been waiting for the new aero to hook into some of the information there. I still haven't explored any of the new functions, but I think I ought to be able to at least tell if there is a stall or some other interesting information that way (maybe AoA? Here's hoping). Probably won't even be able to test any of that for a few days at the earliest. And thanks for the reports testing on 1.0; I'll look into that in the coming days as well.

Yes, check out the link to NavUtilities in my signature.

Only the very end of his stream, he plays and outro song.

Here's a video on how to add custom runways using the built-in editor.

I don't have RSS installed so I don't have a .cfg, but NavUtilities has a built-in runway editor; it's just not super clear how to use it (It can add a runway really fast in-game, all it takes is having your vessel at the location you want to be the touchdown zone). I'll make a tutorial video on how to do that in a bit. Edit: You may have figured out how to add runways, but I still need to make a tutorial video. If you do end up making a .cfg, please post it for other users! Edit 2:

Interesting's not the word I'd have used. Naming a starting Kerbal after a historical figure makes it different to kill her than the other Kerbals. It would be absolutely appropriate to add her name to the easter-egg name list, but the starting 4? Bit of a bludgeon. I assume we'll see some female Kerbals in the VAB and SPH ground crew?

Just an update: Working to see if I can change the SRB nozzles to be derived from the stock ModuleEnginesFX. The intent is to help AdvSRBs better integrate with mods like Kerbal Engineer and stock features like the center of thrust marker in the VAB. I imagine this will be a fairly involved process, but it's one that I've been thinking about for a while now. It may not really be a helpful step, but we'll see where it goes. Of course, KER will probably not like the custom fuel flow system I've written, so ehhh, we'll see

Actually, this is a complication for parallel staged boosters. If we accept that SRBs have a lower Isp than a liquid-fueled core (think STS), then for best dV we'd want to burn the SRBs out entirely before we touch the higher efficiency liquid fuel. Differing thrust on the SRBs will change the net?average Isp of the rocket during their burn duration. For best dV, we want to save as much of the LF for as long as possible; an SRB with increasing thrust over time will be less efficient than an SRB with decreasing thrust over time.

Of course I can go silly too... KSP is an exercise in self-confidence and optimism. Until you get Jeb stuck on the Mun. Then there is no choice but perfection.

The biggest problem I've encountered in setting up custom thrust curves is that it's hard to know exactly how much thrust you need when, particularly for complicated rocket setups (A total vessel TWR/time graph would be amazing...and amazingly annoying to make, I reckon). But a few very simple automatic profiles are really quite comprehensive. Constant thrust for duration; constant excess thrust (aka, how much net thrust is the booster contributing to the stack); and a few others are quite useful. The problem is that visualizing how the rocket will perform is a bit tricky if you're adding together boosters and LFEs etc. Thrust curves on their own might not be so exciting, but a stackable SRB done right needs thrust curves. And thrust curves are invaluable for asymmetric lifters. And yes, of course this wouldn't require that much coding for the engine to work (maybe 2 days to make it work right), but the issues crop up in the GUI design and implementation. There's a lot of information in a thrust curve that the player should like to know, but it's hard to keep it from taking up the entire screen. Hmm, it may be time to see what the licensing on that is... And to see if realfuels has a static thrust curve (.cfg) or editable in the editor...

I'd also add that we need to be clear on definitions, just so we have the same starting point. Here's how I understand these -New Features: Things not announced as being in 1.0; e.g., new SRB mechanics, being able to connect fuel lines between ships on the surface, allowing mods to create new vessel types (so we can designate ComSats, SpacePlanes, etc, a feature I'd really like ) etc. -Bugfixing: Solving problems from occurring inside the game. These can be simple typos, memory leaks (I believe Mike found the causes of the two biggest ones already), or things like the radial decoupler bug, etc. -Optimizations: Doing more with less. E.g., Better RAM management (dynamic loading of parts, load textures in a smaller format), creating a smaller HDD footprint, creating shared textures when possible, etc. -Performance: Reduce clock cycles to perform a task. E.g., rewrite the physics code, update orbital information less often, make contract checking less of a burden, write faster shaders and other GFX improvements, etc. Note the difference between "optimizations" and "performance". Using a gigabyte less of RAM won't allow you to build larger vessels that run at full speed, nor will being able to have a 1000 part ship that runs at 100% necessarily mean that you've reduced the RAM requirements.

If the question is about extending new features for 1.0 (ie more parts, better art, etc) or adding new smaller features we haven't heard about versus improving what's already been developed, I'd much prefer bug-fixing and improving what's already there. A 1.1 patch that has new ISRU scanners and equipment etc feels like a nicer patch than a 1.1 that fixes bugs that have been in the game awhile. New content (above and beyond what's been announced) we can live without; at the very worst, we can continue using mods to add functionality. For example, if the question was between bug-fixing the claw vs adding KAS-like functionality, I'd much rather the claw be fixed in 1.0 if KAS-like connectors did appear in 1.1. Of course, if during debugging the claw it becomes very easy to extend it to KAS-like functionality, by all means do both Optimizations I can live without until the port to Unity 5, since there's no point having to potentially rewrite things. Finally, as I'm sure you're aware, if things are rebalanced much at all say, in 1.1, then people probably won't be happy if the saves they've worked on become no longer useable or if vessels in flight now behave differently. If we did get better SRBs in say 1.1, players who've learned the how the SRBs work in 1.0 would be in for a shock. Just some thoughts.

Sounds most likely to be the known (but the cause is not know) bug of invisible floating buildings. I think it's more commonly referred to as the "Collided with runway" bug, since after the wings and other parts fall off, the F3 screen says the vessel collided with the runway. The bug appears fairly random near the runway, but like I said, no known root cause. More info http://forum.kerbalspaceprogram.com/threads/98232-Colliding-into-building-3km-away

I have this problem too with the Mk3 parts. I think part of it is that the Mk3 parts are so much more massive the pitch surfaces just don't scale up large enough. On smaller planes, the cockpit torque can compensate for bad aerodynamics: mk3 cockpit just doesn't have the same amount or relative torque. My solution has been to do what real airliners do and have an all moving tail for trim (attach the horizontal stabilizaer to the empennage with a IR rototron or the like) and then I can use the rototron to trim for speed/alt and use the elevator for fine control.

Yay, another meta-discussion about the program and not the game ;-) That said, 0.90's been a bit buggier for me (stock) than past versions. Well, more prone to CTDs; I do experience far fewer actual bugs, although part of that is avoiding risky behavior (e.g., the claw). With Mu saying he is working on fixing some of the memory leaks, I expect 1.0 to be a bit more stable than 0.90 (I've come to trust the test team as being pretty good these last few versions). As a final data point, I watch a lot of KSP streams, and CTDs are fairly rare even in moderately modded setups. Known issues with the claw and fuel flow and such still are problems, but knowing the game can help avoid that. Knowing to not trust radial decouplers is an example of that.

http://forum.kerbalspaceprogram.com/threads/108346-A-question-regarding-KSP-and-Unity5%28b%29?p=1698103&viewfull=1#post1698103 Jan 27, 2015 Assumes facts not in evidence. First off, there's no objective way to measure "90% developed with U4 hacks", but by any reasonable interpretation that just isn't so. Otherwise, how could the earlier versions have existed on U3?

I'm too lazy to do it, but for some context of how much work transferring to a major new Unity release y'all might want to find some of the devblogs and such from around 0.18.3 - 0.19, which is about the timeframe I believe they switched from Unity 3 to Unity 4 I think during this time they also switched over to a git for development so some of that discussion might be mixed in as well.

I know it's been posted before, but it was way long ago. When I saw the title of this post I was curious if it was a different Easter egg :-) ...are there any others?

I'll try to get a tutorial video up in a few days. As an aside, NavUtilities ought to have, you know, Utilities. So here's what I've been cooking up: a proper attitude indicator for RPM (it might make its way to stand-alone as well) Please note that this is a work in progress and probably won't represent the final design. So far it features: A modern style flight information display; large artificial horizon Throttle indicator (the green bar on the left) Digital speed and altitude indicators Bar-IVSI I intend to add a speed tape and an altitude tape, indicators for brakes, landing gear, etc; a radar altimeter that automatically displays when below 750m or so, and a pitch offset mode (set up in the cockpit) I have some other plans, but I'd rather not commit myself until I've tested them out.