kujuman

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.

If achievement integration into PC was just a "Hall of Milestones" with a list of the World's Firsts (or whatever is tracked in the end), (sort of like the science archives) I'd be pretty happy. The little beeping in the corner when a World's First contract is completed is a nice way to do it I think--it's not at all intrusive, but you can still check the status of it in flight. I think keeping some sort of record of who was first in orbit, or first kerbal on each body would be welcome generally. I don't want: a master list of achievements (aka it lists unfulfilled things), a notification in flight that would ruin immersion. I'd also add that for certain achievements (such as landing on the mun), it'd be nice if it were made more robust. If I bounce my first landing, I don't want to achieve both "landing" and "take-off" from the mun--likewise, if I land and then tip over/break an engine/etc, I don't want my sudden terror of messing up to be spoiled by "Congratulations! You've landed on the Mun!"

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

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.