kujuman

For me, KSP offers a little bit of everything I like. I've always enjoyed logistics-type games (Railroad Tycoon, Cities in Motion, etc) and piloting games (flight and train sims) and physics games (when I can find some...mostly bridge designers), and KSP has all of those things. But my favorite thing to do in the game is to build space stations around Kerbin, especially now with KIS/KAS and the ability to have gendered docking ports. Being able to build a space station in parts and rearranging pieces during construction to get the final format I want is really a soothing process...sort of like a really laid back puzzle game, and it brings some aspect of building out of the VAB and into orbit. But even when I'm not playing the game for a few months at a time, making mods for it has always been fun--a chore--but fun. Learning to program is difficult unless there's a real application for your application, and making things for KSP really helps me to focus on getting something working.

While I don't think there are mods that fix that bug, it's an (relatively) avoidable one. The state=acquired gets stuck in that state when the game saves when the docking ports are magnetized and the game is then resumed from that save state. So as long as you don't save mid-docking or switch scenes mid-docking you should be pretty safe. And just in case you don't know, you can switch between nearby craft using the "[" and "]" keys by default, so you don't need to go to the tracking station. But yeah, it's one of those annoyances that should get fixed.

I looked into this several months back, and from what I recall it looked pretty difficult/impossible to mod in the way it's designed. But (1) I'm not the most knowledgeable programmer (2) it's worth taking a look again anyway, because custom categories would be super amazing.

Yes, at first it was just in the flight scene when right clicking a command pod/probe. But I loaded up .22 just now, and I can't change the name of a vessel in the tracking station, but I can in .23.5 (I can't find my .23 install atm).

So...I loaded up my .23.5 game...apparently it was a thing back then...time to see how far this goes...

If you're willing to install and use mods, the go-to mod is Kerbal Attachment System, which will allow you to attach two vessels together using a variety of parts. There are a few other mods that just do fuel transfer over short distances, but I am unfamiliar with them. http://forum.kerbalspaceprogram.com/threads/92514-1-0-4-Kerbal-Attachment-System-%28KAS%29-0-5-4 In a stock KSP install, one option is to use the Advanced Grabbing Unit (the claw)...it will also make two vessels into one, but there are some bugs with it still that may destroy your vessels.

For staging, it might be worthwhile to explore using the acceleration of the rocket. You don't want to look for 0gs (particularly if you're still in atmo) but perhaps a reduction in G by some amount (maybe average the prior frames 15-10 against 5-current frame to help avoid physics issues). You might also want to couple this to another metric (if you have no exposed solar panels or rtgs and your engines in a stage have alternators, maybe look for a drain in electric charge to signal when the engines cut off) as a backup.

I think this is a really good idea to at least try out. I think the one addition I'd want is some visual indicator on the orbit of which direction the different node handles are pointing (since the moved node gizmo would be fixed in rotation it seems). Maybe when you hover over a handle on the gizmo, a line or set of lines are drawn on the location of the node indicating the current direction (this would be more useful for changing inclination/radial in/out burns than simple prograde/retrograde maneuvers. The seperate node selection could also give us dVs for each node in real time as we're dragging (actually that'd make a cool app--a simple list of node # and dV, and then a total sum. For extra coolness, maybe nodes could also have a user naming function ("Duna capture" instead of "node 3")

I think one false assumption touching all aspects of the OP is assuming that a rocket has a set cost to design/build/operate, no matter which company is doing it. That's just not the case--corporate structure can have a huge impact on costs. For SpaceX, part of this means younger engineers (less salary, more hours/year, lower non-salary compensation) and building strong enthusiasm in the workforce. Even if SpaceX were to design 100% from scratch vs using 100% COTS, that's not enough to prove that a custom design's costs are necessarily higher. A fully custom design means one might have to design a part, but one doesn't need to design *around* a part (assuming they can change it). If they can save a few hundred kgs per stage this way, they've designed a higher performance rocket than they otherwise could have, without needing to design a new engine or add more of them. Even if a SpaceX rocket costs more to design than it otherwise *could*, it may still very well be cheaper to design than another company building to the same specs. The key to mass production isn't volume, it's maximizing the use of machinery and specialized workers. Let's say that a special machine is needed for 50 hours per F9--to maximize use of that machine, you'd want to build ~50 F9s per year (allowing for maintenance, not assuming continuous production, contingency time, etc.) A traditional mass production scheme would see 50 F9s built so as to not leave the machine just idle and costing the company; it's possible to instead design the vehicle so that you need that machine for 100 hours per F9 (and presumably *not* needing a second type of special machine). In this second way, full mass production only requires 25 F9s to be built per year to not let the machine be idle. This is obviously an oversimplification, but if you can think about it in terms of mass producing *parts* on the F9 and not mass producing the *whole* F9, it should be more clear (one of the reasons there are 10 Merlin engines on a F9 and not, say, an F1 and a Merlin). The factory is designed to be most efficient at building some number of F9s/year; you can build more or fewer, but the vehicle costs will go up. While it's probably true that SpaceX could lower costs somewhat by just focusing on lowest possible cost disposable rockets, their listed launch prices are already pretty low compared against competitors. SpaceX probably figures they can't keep as large a cost advantage forever (the workforce will age, it won't be *as* glamorous to work there, meaning higher compensation costs), so getting into the reusability game ​first will help them maintain some lead in the medium term.

Quit air-hogging the lighted stage, this is all just a lot of hot air--did you really think there's be a mass reaction to a thread of puns? (I like puns :-) )

I actually know why the flag points the direction it does (even during launches...)--KSC wants the flags to fly the "right" direction during launches, and so have installed an intricate system of fans to blow the flag majestically, for all to admire! :-)

Yeah, I do wish I could pawn off AdvSRBs to someone else to maintain. A thrust curve GUI is actually really easy to have work in game*, and stackable boosters are really awesome (though procedural SRBs make stackable ones a little less important). * Even if one doesn't want total control, it's pretty easy to write a small function to automatically configure SRB burn profiles to suit one's needs; constant excess thrust, start/end thrust, duration, etc. I guess one of the issues with SRBs in KSP is that setting up burn profiles (if we could do it the "right" way) is a little bit of a chore, and that's fine for players who use common lifter rockets, but it can be a little annoying for those who always build custom rockets for each payload.

When using subassemblies, you can only attach them by the root part in the subassembly (either a node or surface attach). For example, consider a simple ship consisting of a (in order, top to bottom) docking port, Probe core, fuel tank, and an engine. If the first part you placed was the probe core, if you try to make it a subassembly, you can only attach it to the new ship by the probe core--but since both the top and bottom nodes are already occupied, you can't actually connect it. There are two ways to get around this: the first is to make the first part the docking port, and then build down from it; the second method (and is generally easier) is to, after you build the ship but BEFORE dragging it over the subassembly area ("Drop Subassembly Here" I think), use the re-root tool (press 4 on your keyboard while in the editor to start using the tool) to make the docking port the root part. Hopefully that makes some sense when you're actually doing it in game.

Ooh, I actually have a video of how to do this with KAS and without needing any Kerbals, I'll go grab the link. Using a kerbal and the KAS pipes is easier, but this is just another idea.Update : Editing posts on the phone is hard :-(

Yes, but I'm wondering if there are spares. IE if they planned to install 2, then building a 3rd would mean there is one spare. And the same goes for the science experiments and replacement parts for the station...does anyone know if they are typically one-offs or are spares typically made.

This failure in particular brings up a question: how likely is it that backup/spare docking adaptors were manufactured? It seems like the sort of thing that you might as well build spares when you're building them rather than try to restart production if you need more.

Okay, I'll take these things under advisement (thanks for the comments!). When you refer to the "attitude indicator", do you mean adding a black outline around the yellow wings or around the white ladder with the pitch up information? (the roll and pitch digits in the upper corner are intended as a debugging tool btw)

Let me know how the artificial horizon/primary flight display works, I want it to be functional. Are the numbers in a helpful place/large enough?

Looks interesting, I may have to test AdvSRBs using this--particularly if it'll make it easier to work with the info mods.

Hi everyone Sorry for not being responsive lately, real life got in the way. I'm working on getting everything working in 1.0.2: I think I have the stock toolbar stuff figured out, but I need to update for Blizzy78's toolbar and check to see if everything works in RPM. So lots of testing ahead, but I figure I can get a patch out relatively soon. RE: posting hotfixes. That's exactly what I'd hoped would happen in case I took an unexpected absence, and so I'm glad some effort was taken in patching it. I'd advocate users continue with the unofficial fix until I have a version published. Thanks Ser for keeping it going! Update: Is there any interest from users of kOS to have access to the ILS information via a context menu on a special part? (IE an antenna) It might be possible to write a landing program then, but that's beyond what I could do in kOS: but it'd be pretty easy to expose the information if there's desire.

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.