Jump to content

Headhunter09

Members
  • Posts

    74
  • Joined

  • Last visited

Posts posted by Headhunter09

  1. Right. If you are seriously considering ice-mining, you have to be looking at objects beyond the Sol's frost line, which is located about 2.7AU. That excludes moons of Mars, but does include a large portion of the Asteroid Belt. There are plenty of objects there, including some rather large ones, that are bigger than Phobos, at least as easy to get to, and are likely to contain large quantities of water ice. (e.g. 65 Cybele)

    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.

  2. So I recently got into writing KSP plugins and don't have a whole lot of knowledge on the subject but have recently taken over development of a little plugin (that was still in alpha anyway) called Kerbal Construction Time. I want to be able to read and write a custom (well, eventually several) thing(s) to the persistence file instead of a separate file. I already have my code working using a separate file (thanks to Trigger Au's tutorials) but is there an easy way of reading/writing to the persistence.sfs file? The reason I want to do this is because otherwise dealing with time "going backwards" due to reverts and quicksaves will be a big pain later and if I can avoid it that would be awesome.

    I won't get time to work on it until tomorrow night but figured I'd see if you guys have any thoughts.

    Basically, I want to save a List of my object to the persistence.sfs and read it back in when a flight is loaded. Basically (for now at least) I need to save the time that the ship will finish being built along with some other data. I can already save a [Persistent] List<myObject> to a separate file and read it back in without issue.

    Thanks :)

    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.

  3. You're exactly right; putting up a few extra launches worth of fuel is going to be incredibly difficult. Much easier to send a completely autonomous robotic fuel refinery to a place that's currently 0/3 in terms of landing attempts, and where there quite possibly isn't even anything to refine.

    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.

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

  5. KW has multiple-nozzle engines.

    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.

  6. I considered to install KAS and Robotics, but that interstellar waste heat thing is smart! Though I don't like that insterstellar thing.

    I don't have any problems with any gui/hud when I'm playing.

    And that Real engines config makes engines like real engines. That mean that certain engines can't adjust thrust. And when you use a certain fuel type, when fuel percentage reaches under 10%, the engine flameouts. That's because the chamber pressure reduces as fuel goes.

    Also you can't use whatever fuel you like because that's what the real life analogs use. So I haven't modified anything. Also the engineignitor mod makes it so that supported engines only can fire an x amount of times. I know all this is limiting, but it's realistic

    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.

  7. 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?

  8. 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?

  9. 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.

  10. 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.

  11. 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.

×
×
  • Create New...