Headhunter09

Good point. Although if NASA does develop asteroid-moving technology within the next 10 years like they're planning, we might be interested in smaller targets in the Belt.

I've been wondering the same thing. As far as I have been able to tell, it may involve using ScenarioModules. Try looking at something like TAC life support, which generates its own section in save files.

Nonetheless, we already have the capabilities to robotically visit and test asteroids for ice content, even if we haven't had a successful mission. ISRU on the Moon would require a whole new regime of development, as the US hasn't landed a robot on the Moon since 1968. Having a self-replenishing fuel dump in Martian orbit opens up a bunch of opportunities that just aren't available when launching your own fuel.

I think the main arguments in this thread are fundamentally flawed. 1. Any plan involving the Moon is worthless. Phobos is closer, in terms of deltaV, than the Moon. The first step would be to test robotic ice mining and refining technologies on either a near-earth asteroid or Phobos. This way, when a mission arrives in Martian orbit, it can top up at Phobos. As for ISRU from the Martian surface or atmosphere: this is a much more difficult option. For one, the Martian atmosphere is very thin and dry. More importantly, the surface is much farther away in terms of deltaV and disallows any abort mode from Mars orbit (if they were planning on refueling). Having a fuel depot in orbit from Phobos means you don't have to move fuel from an asteroid into Martian orbit (another complication), or up from the Martian surface (inefficient). 2. NERVAs, or any other exotic propulsion system, aren't needed. Any plan can be accomplished with straight-up chemical rockets. Honestly, this is the best option because we have the most experience with it. Even ignoring the potential political aspects (which I don't think would be insurmountable), NERVAs would require many years of research, development, and testing. With a small number of heavy launches, we could assembled a habitat and booster capable of reaching a Mars orbit, where it could then refuel. It doesn't even need to carry landing equipment, just a deep-space habitat. Which brings me to... 3. It need not be a single mission. What would most likely happen is that any surface and orbital equipment (like heavy life support equipment, such as aerocultures) would be launched years before hand. That way, if anything fails, it can be replaced before astronauts arrive. So the most realistic profile for a mission is that pieces of equipment are designed and launched steadily for a number of years. Finally, a crew transfer vehicle is assembled and sent on its way. At the other end, the transfer vehicle is parked and the pre-arrived equipment is used for landings, etc. Then the transfer vehicle is refilled by the Phobos ice miner and replenishes its perishable supplies from pre-launched caches, and then returns to Earth. This profile also makes sense politically. If you have four pieces of expensive equipment already in Martian orbit, the program is less likely to be cancelled. It spreads out the cost, and works against cancellation. Also, it can take advantage of new technologies developed in the mean-time (AKA, you only have to develop a few technologies at a time).

Thank you for creating an extremely well-put-together post. It would be so easy to just say "I'm doing N-body stuff, here is a screenshot," and then the thread would immediately fall to pieces. Also this is totally mind-blowing excellence.

Ah yes, good old sarcasm. Witty!

Most part packs do. What I'm suggesting is the ability to create new engines, deciding how many nozzles, whether each nozzle has its own combustion chamber, how to cool the engine, how to pump the fuel into the combustion chamber, and how big/what size to make the nozzle. In this way you could create a new engine design tailored to your needs.

I mean, its pretty much just Realism Overhaul and such. Unless you've done some serious config editing, I don't see the reason to "release" it.

Is there some way to get a callback whenever the activeVessel (or otherwise) enters a new situation and/or biome? I've been looking at GameEvents, but am otherwise pretty clueless about this topic.

I understand that engines are designed with a fuel type in mind, but I want to be able to build realistic missions with realistic engines, not real-world engines, if that makes any sense. I don't want to be restricted to existing engines, I just want my engines to have realistic parameters. Because my engineers would design a new engine if need be. And yeah, the EngineIgnitor mod's ullage simulation is really cool as well.

There are a lot of part packs that provide various sizes and designs of engines. You have vacuum engines, first-stage engines, high-thrust, high-efficiency, dual-nozzle, tall, short, nuclear, fusion, etc. Since there are mods to introduce extra realism elements to the design process (life support, heat management, communication, safe reentry, aerodynamics, etc), why not create a mod for designing engines? On the one hand, it would allow the vast amount of available engines to be relegated to a "Preset" list, freeing up the propulsion tab. It would also allow designers to make engines with just enough thrust, and most efficient at the altitude they are likely to be used at. On the other hand, designing engines is REALLY COMPLEX. How deep do you go? Do you restrict the choices to big things like style and number of turbopumps, cooling cycle design, nozzle vs aerospike, and number of combustion chambers? Do you have a range of values for nozzle angles and sizes; fuel flow rates; valve reliability (tradeoff between failure rate and mass)? Then there's fuel choice, and fuel tank management. Choosing a gas for pressure-fed engines, not to mention arranging the geometry of parts for optimal heat release. Engine design involves fluid dynamics, thermodynamics, mechanical engineering, and material science. Would a mod ever be able to do it justice? Skimming over the nitty gritty details of how such a mod would be implemented in the current game, is this what people are interested in? There are some people who play KSP, others to design. Is this too real? Thoughts?

I run an almost identical lineup, but also use KAS, Infernal Robotics, and KSP Interstellar for its WasteHeat sim. I also went without a number of straight-up "replica" packs like FASA, and use parts like HGR and ASTRA, as well as some other single parts and hand-rolled modified parts. Honestly the biggest issue for me is that some mods conflict and cause fundamental UI bugs. For instance, the "Load" button in the VAB no longer works -- I have to go to the Launch Pad, and revert back to the VAB in order to switch the craft I'm working on. Another annoying thing is that the Realism Overhaul comes with a "Real Engines" config that removes a lot of the versatility from KW engines and the like. It restricts many of the engines to a single RealFuel type, and makes the Min Thrust and Max Thrust the same (so the engine can't be throttled down). Did you keep this, modify it, or use another entirely?

Nice. I took a stab at a Sanity mod about a month ago, but left it 20% done, as you say. Only thing I can suggest is having fitness levels also affect EVA performance. That is, weak Kerbals walk much slower in high gravity environments, and the like (maybe also hook in with KAS and the carrying system?)

That's called pseudocode, and there's a generally accepted way to do that is more readable than what you wrote.

Clearly not everything that could catch you would eat you, judging by the responses of others in this thread.

It'll probably be a value under the "torqueCurve" node. Torque is basically rotational force. Max speed is achieved when the force from friction is equal to the tangential force along the wheel rim from the motor torque. Find the torque value along the axis of rotation, and increase that.

Generally when I'm learning how to work with a new library, language, software package, etc., I work with what I know until I get stuck, and then Google that specific item. That way, I amass knowledge from multiple sources (various tutorials and Stack Overflow questions, mostly), thus reducing the chances of developing misconceptions while also synthesizing the information on my own, providing a deeper understanding. To answer your question, I've never found a good single set of tutorials for any programming language or code library. I've always found it satisfactory to Google something like "what is a method C#" and read around until I feel comfortable doing something with it on my own. Just my two cents.

Check out GameEvents.onCrewBoardVessel, maybe? Never looked into it, but seems like it might be what you're looking for.

I'm working on a plugin that requires you to give your Kerbals ample space for long journeys. I've got most of the technical backend setup, but I'm struggling with creating a realistic/fun algorithm for space requirements. Currently, each Kerbal has a level of "sanity" from 0 to 1. Bad things happen if sanity levels fall too low. How should sanity correlate to mission time and living space? In my mind, a full Hitchhiker pod should degrade sanity slower than a full Mk1 pod; even though the ratio of Kerbals to spots is the same, the Hitchhiker still has more "space". Additionally, if a stupid Kerbal is stuck with a brave Kerbal, I feel like the brave Kerbal's sanity would degrade faster than if he was paired with another brave Kerbal. So far I've been looking at logistic functions as the basic building block (because linear functions are passe), but I'm not sure how to quantify the interplay of the qualities mentioned above. Any opinions would be appreciated.

Hey guys, How can I hook into the save/load process and add a data entry to each CREW tag? In other words: is there a way to get a callback when the game starts writing Kerbal information to the save file? Thanks in advance.

Yes it would be nice to see a list of objectives. A video is nice, but hardly the best medium for conveying information; better for promotion and basic summary.