RealKerbin - a Real Solar System fork

[ialdabaoth]

So, I've decided that I want to make a RSS-style mod, but with a few tweaks. The goal will not to be to replicate Earth's solar system, but to provide an as-accurate-as-possible Kerbol system. This is a game about sending little green men to the stars.

First, I'm going to start with Regex's excellent 6.4x rescaled Kerbol system.

For parts mods, I'm most likely going to include modifications of parts originally from B9 Aerospace, KW Rocketry, KSPX, BahamutoD's EL Drills, and . Since each of these part packs includes a variant of the Creative Commons license or a similarly unrestrictive license, I'm going to be releasing a reduced/modified version of each (including proper attribution in each sub-folder, of course).

For plugins, obviously, FAR, DRE, RealFuels, RemoteTech, and EngineIgnitor are must-haves. Other plugins will most likely be developed by me, with an eye towards maximizing realism. Some of the aforementioned plugins may be forked in order to refine functionality.

Eventual goals:

Realism and Immersion Goals

* Parts will be constrained to those which operate via known and verified science. Their masses, sizes, and performance characteristics will be modified to conform to real world values, at Kerbal scale (1.25m one-man pods and 2.5m three-man pods).

* A "team multiplayer" mode may be implemented utilizing a combination of KMP and FirstPersonEVA, wherein a player can choose to be assigned a specific Kerbal, and only see via that Kerbal's IVA/EVA perspective (no map view or external view). Kerbal-players which are not assigned to a spaceship would instead be limited to the Space Center and Map View screens.

Exploration Goals

* hidden asteroids and comets, which require the use of telescopes to find and track them.

* probe cores are NEVER real-time controllable; you can ONLY control them by uploading new maneuver nodes to them, which they will then execute using something like MechJeb. Uploading new maneuver nodes will require line-of-sight and will follow speed-of-light delays.

* probes can only be accurately tracked via telemetry or telescopes.

* both asteroids and probes which do not have accurate telemetry data will have a "margin of error" applied to their orbital plots in the map view; this margin of error can be decreased by taking more realistic telescope readings.

Resource Management Goals

* accurate real-world resource mining and utilization (including creating parts and building ships out of them)

* accurate life-support needs based on Kerbal physiology (details to be determined)

* due to the Kerbal species' love of simplicity, fuel resources will be limited to the following:

- SolidFuel (Aluminum Perchlorate)

- LiquidFuel (a highly refined Kerosene derivative, much like human's RP-1)

- CryoFuel (Cryogenic Liquid Hydrogen)

- Oxidizer (Nitrogen Tetroxide)

- Peroxide (high-test H2O2)

- LiquidOxygen (Cryogenic Liquid Oxygen)

- IntakeAir (Air with at least 20% Oxygen content)

- MonoPropellant (a hydrazine-UDMH mix)

- Xenon (pressurized Xenon gas)

- ElectriCharge (joules of direct electric current)

- NuclearFuel (Enriched Uranium)

Ultimately, I'm making this "mod pack" for a single user: me. However, I'm sure I'm not the only person with my particular tastes in gaming, so I'm going to be maintaining it as a public mod for others to consume, at least until the "this mod sucks! X is overpowered! Y is too hard to use!" complaints become overwhelming.

In the meantime, I'd love to brainstorm with people about the details, with the understanding that "I'm not sure I agree with you" is an invitation to further discussion, but "That's not how I want to handle that" means you aren't getting your way.

[stupid_chris]

Two things:

First KSPX is not under an unrestrictive license. the license is ARR to Claira, with explicit distribution rights under permission. You're better off to have people download it remotely and use some MM configs for your means.

Second, this might look like some self-promotion (which it kinda is), but if this is reality-oriented, why not RealChute?

[regex]

First, I'm going to start with Regex's excellent 6.4x rescaled Kerbol system.

Daaaawwww, I'm glad someone else liked it.

Your description here has definitely piqued my interest so far. Considering you're not going to be implementing a lot of KSPI, given "Parts will be constrained to those which operate via known and verified science." I'd encourage you to look into Near Future Propulsion. I realized you're not talking about now-viable technology here but rather now-theoretical. Still, I'll pimp NFP because it'w one of my favorite part packs.

Edited April 4, 2014 by regex

[dlrk]

Sounds very cool!

[plausse]

I tried to do this for my own KSP.. With somewhat limited success. This thread might be the single most exciting thing I seen this month.. That means more exciting than the ARM patch.

[NathanKell]

I really like your probe ideas. Before RT2 came out I had a module based on RT1 for "science cores" that allowed right-clicking but not flight control, for uncontrollable (but still science-returning) satellites.

So I guess what I'd suggest is adding that kind of "probe" as well.

[Mulbin]

Really intrigued by your idea for "team" mode.

I've recently started work on the first panels for my enclosed spacecraft simulator (more here info here - http://forum.kerbalspaceprogram.com/threads/66742-Custom-hardware-control-switch-panel-simpit-WIP) which will obviously mean playing KSP in such a way that I won't have any access to the map or exterior view, only the view through my window and the gauges and readouts on my control panels. I had been toying with the idea of running some flights with other KSPers around the world acting as mission control, planning maneuvers etc and feeding me the time and headings.

Will watch with interest!

[White Owl]

Sounds very similar to my current game, with the exception that I'm not planning on using RemoteTech or any of the life support mods. I agree with you that Regex's 6.4 scale Kerbol system is a very good size.

[curiousepic]

This sounds like this would fill a great niche; somewhere between RO and BTSM. A wishlist of additions I hope you'll consider (hooray for scope creep!):

• Tighter electrical system requirements - heavier batteries, higher power draw, power draw for more parts like cryo fuel tanks, heating, etc
  
• Thermal Management - part heating from running equipment, life support, as well as just exposure to the sun, mitigated by radiators (and maybe an ammonia resource that slowly depletes)
  
• Telemetry and tracking requiring parts like star trackers and gyros
  
• Water-focused ISRU (with anything more, like ore refinement requiring very heavy equipment)
  
• Part manufacturing being based on complexity of the part (basic unit can only create structural parts like girders, and maybe simple fuel tanks; engines and the like need to be brought whole from Kerbin)
  
• Integration or balance consideration of these mods:
  
  • KAS - to emphasize desirability of the flexibility of manned missions
    
  • Infernal Robotics - to allow craft to fold up and fit into fairings
    
  • KOS for the craft programming bit, instead of creating your own, along with a list of commonly used programs to get people started
    
  • Kerbal Construction Time - to make the passing of time and launch windows an actual consideration
    
  • One of the part failure mods in development
    
  • Some of the interesting bits from stupid_chris's Stock Rebalance, like the uncovered solar panels being un-retractable
    
  • Orbit Manipulator Series - for orbit degradation and timewarp-burns (with attendant rebalance of ion engines)
    
  • Kessler Chaos - fatal debris clouds that increase with normal debris you leave in orbit
    
  • Custom Biomes and RoverScience - more motivation to explore planet surfaces
    
  • Timewarp Rotation Fix - or the same functionality if this mod is abandoned, since it's currently broken
    
  • KeepFit - if it continues being developed
    

Also, Bob Fitch is doing some coincidentally similar things with

- check it out for some inspiration (requiring individual CPU parts for each comm dish and other pieces of equipment is a really cool idea) Edited April 8, 2014 by curiousepic

[R0cketC0der]

Sounds interesting, but it has one main issue: probes can only be used with maneuver nodes. This makes launching or landing with probes impossible, which is about as far from reality as it can get. After all, even our manned launches are almost 100% computer controlled. Otherwise I really think this has potential, but I will stick to RO.

[magico13]

This could be fun to play with for sure! It sounds like you've got a lot of work ahead of you though, so I wish you luck with that. Curiousepic mentioned my mod, Kerbal Construction Time, which you are more than welcome to take apart and reconfigure for this. It's got it's own issues to deal with, but as of right now it's mostly stable (just a few bugs I need to work out when I get the time). I think it would be well suited for this, as it makes craft take actual time to build instead of being able to launch ships right away.

[ialdabaoth]

This could be fun to play with for sure! It sounds like you've got a lot of work ahead of you though, so I wish you luck with that. Curiousepic mentioned my mod, Kerbal Construction Time, which you are more than welcome to take apart and reconfigure for this. It's got it's own issues to deal with, but as of right now it's mostly stable (just a few bugs I need to work out when I get the time). I think it would be well suited for this, as it makes craft take actual time to build instead of being able to launch ships right away.

Wow, this is almost perfect!

One suggestion for Kerbal Construction Time:

If you can find a way to track subassemblies and saved ships, as well as individual parts, that would go a long way towards realism. That way, when I "recover" a ship, I can recover it as a completed subassembly instead of as a mere collection of individual parts. Also, is it possible to create an "auto-recover" PartModule for SRBs? Some kind of PartModule that checks if the current vessel is a debris, then checks if it's about to leave the physics bubble while in atmosphere, then checks if it has functioning deployed parachutes should do it.

[sirklick]

I started playing around with creating similar stock-alike fuels a while back that almost mirrors what you have outlined here -I lost momentum when creating engine configs (was using your "old" RealEngines as a starting point). From a labeling perspective I suggest using "CryoOxidizer" instead of "LiquidOxygen" -the logic being that "Oxygen" is outside of the chosen labeling schemes specificity.

[NathanKell]

Regarding "autorecovery": You can directly steal the code I wrote for MissionController to do just that, actually. (In my case it was do those checks then give the player the recovery amount of money). Incidentally that will also teach you how to deal with prototypes, snapshots, and other on-rails versions of parts and modules.

[ialdabaoth]

Regarding "autorecovery": You can directly steal the code I wrote for MissionController to do just that, actually. (In my case it was do those checks then give the player the recovery amount of money). Incidentally that will also teach you how to deal with prototypes, snapshots, and other on-rails versions of parts and modules.

That is AWESOME. I will definitely do so.

At the moment, most of my development is in cfg editing and part/resource balancing. Here's what I have so far:

1. All parts have their masses reduced to 40% stock.

2. All resources have been converted to my system. I've ditched Peroxide and added a few LSS resources, so the final resource list is:

- LiquidFuel (RP1)

- Oxidizer (N2O2)

- Monopropellant (UDMH)

- Xenon (Xe)

- IntakeAir (N2+O2)

- ElectricCharge (W)

- CryoFuel (LH2)

- CryoOxy (LOX)

- NuclearFuel (U235)

- NuclearWaste (Kr85 + Pr141 + various Pr141 precursors + a lot of beta radiation)

- Oxygen (duh)

- CarbonDioxide (duh)

- Water (duh)

- BioMass (living plant matter)

- Snacks (duh)

- BioWaste

So, next step might be Life Support. Here's how my LifeSupport mechanics are going to work:

1. Each Kerbal converts Oxygen + ElectricalCharge into CarbonDioxide and Snacks + Water into BioWaste. If a Kerbal can't do this, either due to insufficient input resources OR no room for output resources, there's a random chance they die.

2. Greenhouses / bioreactors convert CarbonDioxide + ElectricCharge + BioWaste into Oxygen + BioMass + Water. When manned, they can also optionally convert BioMass into Snacks.

3. Air Scrubbers convert CarbonDioxide + ElectricCharge into Oxygen.

4. Fuel Cells convert CryoOxy + CryoFuel into ElectricCharge + Water.

[Spuds]

Haven't been a big fan of mods, but this looks like one that I'll use.

You should have the chance of death scale with time. As in, if a Kerbal has gone without food/water for a day, they should be fine, but at 5 days they should have a very high chance of death.

[NathanKell]

Interesting! Makes sense for kerbal resources.

Wow, LF/Ox is going to have a quite terrible Isp, assuming that's Nitrous Oxide--but I thought that was N2O? (And, also, cryogenic, unless you want to deal with gaseous N2O).

A note: you probably don't want UDMH as a monopropellant (I made this mistake too at first). The point of UDMH is that it's much more stable than hydrazine...which is not what you want as a monopropellant. Quite the reverse, really. I've certainly never heard of UDMH used as a monopropellant. If you want a monopropellant that can be combined with something else to be a bipropellant, you're probably better off using HTP...or actually Nitrous Oxide! (Combine it with a hypergolic fuel...)

[ialdabaoth]

Interesting! Makes sense for kerbal resources.

Wow, LF/Ox is going to have a quite terrible Isp, assuming that's Nitrous Oxide--but I thought that was N2O? (And, also, cryogenic, unless you want to deal with gaseous N2O).

Ack, sorry, N2O4, not N2O2.

A note: you probably don't want UDMH as a monopropellant (I made this mistake too at first). The point of UDMH is that it's much more stable than hydrazine...which is not what you want as a monopropellant. Quite the reverse, really. I've certainly never heard of UDMH used as a monopropellant. If you want a monopropellant that can be combined with something else to be a bipropellant, you're probably better off using HTP...or actually Nitrous Oxide! (Combine it with a hypergolic fuel...)

*nod* so, is there a good hypergolic that can be combined with N2O4 to make a hypergolic bi-propellant, or combined with a catalyst to make a hypergolic monopropellant?

EDIT: Found one! NH3OHNO3 is a water-soluble monopropellant and bipropellant that's stable and has 40% higher density than Hydrazine.

Edited April 20, 2014 by ialdabaoth

[ialdabaoth]

Oh, one thing I'd really like to understand better: how do I figure out delta-v requirements for getting from place to place in regex's scaled-up Kerbol system?

[NathanKell]

You can fork alexmun's launch window planner and change the planet/sun data, then let it do it all for you.

http://alexmoon.github.io/ksp/

AbeS forked it for RSS, you can see the changes here:

http://abrhmsanchez.github.io/ksp/

Ah, HAN! Also, IIRC, far less poisonous than HZ/UDMH/AZ50. Although N2O4 is still hella-dangerous.

[White Owl]

Oh, one thing I'd really like to understand better: how do I figure out delta-v requirements for getting from place to place in regex's scaled-up Kerbol system?

I've been working on exactly this same issue. No readily available delta-V maps that I'm aware of!

My solution so far has been to use Mechjeb to find the timing and delta-V for the initial Hohmann transfer, then just keep playing with maneuver nodes to figure out the delta-V for orbit, landing, or whatever else you want to do. I recommend PreciseNode for getting fine control of the whole maneuver node system. Doing it this way has the added benefit of all the calculation happening ingame. (Maybe not as important if you aren't recording videos all the time...)

Edited April 21, 2014 by White Owl

[Garibaldi2257]

you're welcome to use my trusses. they're 65cm square and in 1-5 and 10M measurements. if you want other trusses to go with it, I've pretty much got all the different shapes figured out, and it doesn't take long to put them together.

[regex]

Oh, one thing I'd really like to understand better: how do I figure out delta-v requirements for getting from place to place in regex's scaled-up Kerbol system?

You can fork alexmun's launch window planner and change the planet/sun data, then let it do it all for you.

http://alexmoon.github.io/ksp/

This is exactly what I do. I find it interesting that Moho is actually slightly harder to get to under 6.4:1 Kerbin than getting to Mercury under RSS.

I'm a bit fragmented at the moment, working on engine configs for my own 6.4:1 career mode, recording video of a challenge, dealing with family, but I'm also trying to get the RSS config looking good with the newest PQS information from the RSS thread. I'll probably have a new config out fairly soon with much better looking planets that feel a lot more like the originals (done with Moho, Gilly, Kerbin, Minmus, probably going to tweak Eve and Kerbin a bit more). The landings also seem to be better when tweaking the PQS with the new values, so that's a bonus.

[metaphor]

Oh, one thing I'd really like to understand better: how do I figure out delta-v requirements for getting from place to place in regex's scaled-up Kerbol system?

If it's scaled right, the delta-v requirements for a scaled-up system are exactly the same as the delta-v requirements for the stock system, except multiplied by the square root of the scale factor. So for example if a Kerbin-to-Mun transfer takes 860 m/s in the stock system, it would take 2176 m/s in a 6.4 scale version. This doesn't work for flights through atmospheres since the atmospheres are usually scaled at a very different scale factor. If the atmosphere is kept the same as stock, launch to low Kerbin orbit should be about 7.5-8 km/s of delta-v.

So you can use the KSP delta-v map in my signature and multiply all the numbers by 2.53.

Edited April 21, 2014 by metaphor

[Spartan125]

Another good mod would be NeverUnload: http://forum.kerbalspaceprogram.com/threads/48720-TT-NeverUnload-Vessel-Unloading-Preventer

This means that any object with this module will not unload until it reaches a set distance (300km default) from an object you are currently controlling, allowing for spent stages to land safely back on Kerbin. It hasn't been updated in a while but it appears to not have many problems.