Headhunter09

Self-contained complexity is pointless, I agree. Nonetheless, the more multi-faceted a system is, the more challenging it is to design within. As an example, let's reduce KSP ad absurdum. You need fuel and an engine. Having power requirements is pointless because people will add solar panels. Having parachutes is pointless because people will just add parachutes. In fact, having any sort of crew module is pointless, as are landing legs (just make them out of girders), and RCS (auxiliary engines and reaction wheels will do the trick). You don't really need control surfaces, as they can just be factored into wings, and there really isn't a point to adding aerodynamic stresses, since it just makes plane design annoying. If Life Support is just "add three parts and forget about it", then yes, it's pointless. That's why it should be designed to be more integral to gameplay.

I know they said that money and science will be interchangeable, but I certainly hope that isn't the case. It would be interesting if science was used to unlock research nodes, and money was used to both develop the individual parts under a node, and pay for a rocket design. When you took a contract, you would get paid a certain amount upfront to defray part unlocking. You would then need to design a rocket that costs less than a certain amount. Once the contract was complete, you would get the remaining pay (with less money the longer you take). That way, taking contracts would both further tech-tree progression, and give a design challenge. Thus, research missions would help pave the way for taking more advanced contracts (open up the nodes), and taking contracts would allow you to do more personal missions without waiting for your annual (and small) budget to refresh.

Looking at this from a game design perspective: what adds the most interesting new elements? -First, consumables (air, water, food) place a time limit on missions, or require the planning of ISRU. However, I don't think they should be clumped together, even though they fill a similar role. Depending on your destination, different resources can be topped up. For instance, Duna has a CO2 atmosphere which can be scooped up and turned into Oxygen. Oxygen can be turned into Water by combining it with LiquidFuel (or Hydrogen equivalent). So if you are going to Duna, it might be beneficial to bring an Air Recycler and a Fuel Cell instead of a bunch more consumables (depending on the weight). This sort of mission planning is one of the core tenets of KSP, so it makes sense to keep those resources separate. I do think that Food should be irreplaceable. Having aeroponic farms and the like sort of break the entire balance. -Second, heat management. I don't know if this should be classified under Life Support, but it is certainly one of the more critical aspects of spaceflight. Vital electronics and crew compartments will need to have heat pumped away, and radiated with panels. Depending on distance to the sun and craft orientation, different areas of the craft would heat up, and this would need to be balanced out. There really isn't any mechanic like this in the current game, except perhaps solar panel orientation. On the other hand, adding coolant tanks and pipes may err on the side of micro-management too much. -Third, crew space. This is often neglected when talking about Life Support, but it is a crucial component of keeping your crew alive and functioning. There should be some system for ensuring that long-duration missions give the crew ample living space. This, really, would be a big design consideration. Sticking two Kerbals in a single pod with a ton of consumables doesn't add much to the game, but having to also give them three Hitchhiker pods if you expect them to make a multi-month journey changes the mission requirements considerably. -Fourth, power requirements. Not having power in space sucks, because you get cold really fast. Also, all of your equipment doesn't work. Right now, manned pods operate fine without power, which should be changed. If solar panels don't get moved down in the tech tree, it would be interesting to see Fuel Cells as an alternative to batteries. Since you are already adding life support to manned missions, sapping a little bit of consumables to cover the extra energy expenditure would work for short missions. Since it wouldn't work for longer missions, this would stop players from stacking up a bunch of consumables (which weigh a lot less than batteries for the same amount of time) and taking off to Eve before getting solar power. At the end of the day, game design is subjective. While one person may think separating consumables into different resources is over-complicating it, another may believe it is the only reasonable solution. Depending on what skill-level you want to appeal to, and what aspect of gameplay you want to enhance, the pros and cons change.

How can you be sure people in the future would know to scan any high-density format (nanoscopic etchings, crystal lattices, etc)? In the past, people have burned scrolls as kindling at archaeological digs because they didn't recognize that they contained information.

That's also not how electrons work. Making the analogy between celestial orbits and quantum mechanics is very misleading.

Kind of reminds me of Starslip. I would probably bury it in an asteroid (provides shielding, structural support, heatsink, raw materials, etc.), and put the asteroid in a highly stable orbit, or near a Lagrange point. I would also keep it fairly nondescript, and leave markers on other celestial bodies or on the Earth that would allow a reasonably advanced civilization to pinpoint the asteroid's location. One big problem with some sort of long-term storage is accounting for the fact that languages and even thought systems will change radically in even a few thousand years. This was addressed partially in the documentary Into Eternity. I guess the best way to reliably store any data would be clay tablets, since that has been the most effective long-term storage to date.

A "private" space program would probably involve mining water and selling it to other people in LEO. There is no direct ROI from doing space exploration, so you have to rely on other people putting a dollar amount to the exploration's intrinsic value.

For anybody interested in this subject, you should read Red Mars. It discusses the subject in depth and is well-researched. In the book, they do a couple of things: -Drill moholes to add heat -Breed extremophile bacteria, lichen, etc. to eat salts in the soil and rock and emit gasses -Spread black powder (or black lichen) on the polar caps -Shift icy asteroids to graze the atmosphere, adding heat and gasses to thicken the atmosphere -Breaking open underground aquifers to add water to the surface

A good idea. I suppose the only roadblock is keeping an updated, extensive list of mods. Unfortunately, it seems like a fairly fundamental issue with the concept, rather than a technical hurdle. I guess the problem lies in getting modders to accept and support whatever sort of central database system is created, which may not be easy.

The difference is that points on the Earth don't move relative to Greenwich (same angular speed)

Look into biomes and vessel.situation (for flying over, landed at, in space above, etc)

Right, sorry. I get snide when I'm tired. Thanks for helping. The code in question is in a PartModule which I've given to every manned pod. It's called every update from each of the three command parts on the vessel, which I can tell from print statements. The rotation of the debugging line works, but the position just stays on the pad. I'm probably overlooking something, but I've been poring over this code for so long that I need fresh eyes. protected Rect windowPos = new Rect(40,40,1,1); // debugging private GameObject obj; private LineRenderer line; private void updateWindowSize() { [INDENT]//print("CTS_Node updating window size in part " + part.partName); // visual debugging Destroy(obj); obj = new GameObject("Line"); obj.transform.position = part.transform.position; //THIS DOESN'T WORK line = obj.AddComponent<LineRenderer>(); line.material = new Material(Shader.Find("Particles/Additive")); line.SetColors(Color.red, Color.yellow); line.SetWidth(0.1f, 0.1f); line.SetVertexCount(2); line.SetPosition(0, Vector3.zero); line.SetPosition(1, part.transform.forward * 2); //THIS WORKS // transform part position to screen space Vector3 screenPos = Camera.current.WorldToScreenPoint(part.transform.position); windowPos = new Rect(screenPos.x, screenPos.z, 40, part.protoModuleCrew.Count * 32 + 8 + 64);[/INDENT] }

I tried that, and it didn't work. That's why I'm asking for help. Both Part.transform.position and part.partTransform.position give the root of a vessel on the launchpad, and then don't move. The rotation of the transform works fine, but the position doesn't. That or I'm using the graphical debugging wrong, but I worked that straight from the examples on the wiki. I'm asking because maybe there is some quirk that I don't know about, and people with experience in the subject can easily identify. That is, of course, the point of having a help forum in first place. It's not so that lazy ignorant people can easy questions, it's so modders who don't know all the little things about the KSP modding environment can draw on the experience of those who have worked with it for longer. But thanks for being condescending.

So I posted a thread about this, but got no answer. How do you get a Part's transform in world space? All the obvious routes seem to given an unmoving point on the launchpad.

Eh, I work on it sometimes. I was running into problems with GameEvents and persistence, but if I get those solved it'll just be polishing left to do.

I was making a mod like this, but its only around 60% done. My only input is that everything should be very simple algorithmically. That is, the user shouldn't have to worry about love triangles, jealously, etc. The user should have to worry about a single number: the Kerbal's sanity. Sanity should be influenced by available space, number of companions, and per-capita space. Things like reaching a new planet, docking with a ship of new Kerbals, and returning to Kerbin should give immediate boosts to sanity, but eventually the effects should falloff. My reasoning here is that the user shouldn't have to worry about micro-managing crew. The main appeal for many people, I think, is that it requires them to create larger ships for longer voyages, and puts a time limit on the mission when using a smaller spacecraft.

No mirror could be made 100% reflective for the entire journey, and thus a combat-grade laser could melt it rather easily. Not to mention it's easily detectable.

Actually, in terms of difficulty KSP is pretty accurate. Parts are much heavier and engines are much less efficient. I remember seeing a guy who did a Realism Overhaul Apollo mission to the moon and said it roughly equaled the difficulty of doing it in stock KSP, except in the real version you had to be much more precise.

I hadn't heard about that, but can you explain what that means in greater detail?

The technical feasibility of a NSWR is questionable. Unlike some other nuclear propulsion systems, nobody is quite sure how to go about constructing a NSWR.

But we don't need a contiguous habitat. Two habitats opposite of each other, connected by longer arcs of structural material would do the trick. Better yet, the whole "use the spent booster stage as a counterweight" idea removes the need to have heavy structural members.

"Outside" is a spatial concept, and since the universe is by definition all of space, there is no such thing as "outside the universe", much like there is no such thing as "before time", because "before" is a temporal concept. On another note, the observable universe is not necessarily smaller than the entire universe. Since there is no boundary to space (it's curved), its quite possible that some of the objects we see very far away are in fact the same objects we are seeing closer, just from a different point in time. How's that for mind-blowing?

As long as we're assembling transit vehicles in orbit, I don't see the problem with constructing a centrifuge. Orbital construction is, after all, one of the things we actually have experience with.

So I want to create a window that appears in the center of a Part's transform and follows it around with camera movements, much like the existing Context menu system. I looked at Camera.WorldToScreenPoint and such things, but I know KSP uses a number of coordinate systems, and I'm not that familiar with Unity's transform system. 1. How do I find the transform of a given part. Is it part.partTransform.position, part.partTransform.localPosition, part.transform.position, part.transform.localPosition, or what? 2. How do I convert that into screen space? Does the function above work, or do I have to do additional operations?

He's talking about a flyby, AKA not entering orbit or stopping to replenish perishables.