zeel

This thread makes me sad. We seem to be stuck in this rut of thinking that anyone making money is evil, and only indie devs who are barely scraping by are worth our notice. Not to mention that we assume the worst possible outcome when someone mentions the term "DLC". Lets get something straight: DLC is not inherently evil - in fact, it's actually pretty awesome. The problem is that some developers have used it as a way to cheat their customers. I don't believe for a second that SQUAD would do such a thing. In recent times a number of companies have committed some serious breaches of trust against the gaming community. Microtransactions for pointless fluff content, pay-to-win, and on-disk "DLC". Those things are bad, dishonest, and generally distasteful. But "DLC" is not necessarily bad because companies do that. Good DLC has and still does happen. When you have a full complete game (KSP is scope complete, upon 1.0 we will have what we paid for), and the developers then produce even more content for that game, it is reasonable for them to expect further compensation. Developer time is not free, nor is it cheap. SQUAD could call it quits at 1.0 and be perfectly within their rights, because they finished the game. The idea that we somehow deserve anything else they produce is absurd! What if they made a new completely unrelated game? Would we be entitled to that as well? Of course not. So why do we expect to get all future KSP content for free as well? That's insane. I for one fully support DLC (so long as it's not microtransactions). And to get back on topic. . . I would like to see interstellar content; airships and ocean going vessels would be cool; multiple competing space programs (AI run, as well as multiplayer) and multiple launch sites; and more content for rovers and stations. There are so many suggestions in this forum that are really cool, but tend to go beyond the scope of what the game is about - but they would be perfect as DLC. I want to see those things become a reality.

So back to the original question of Orange suits, and the idea of adding the females as Blue. . . I get why the Orange suits exist, and while it's a fun throwback it has no value as far as gameplay is concerned - it's actually a bit confusing, why are those three orange? Most players will never know or care. Even before there were different types of Kerbal (Pilot, Engineer, Scientist) I thought there should be, and that suit color would designate the kerbals type. Orange for pilot, Blue for science, White for engineer. I say get rid of the old Orange suit club - maybe replace it with a colorful patch on their arm or something.

The essential problem I see is that the player already has all the knowledge they need. Enough planning allows any mission to succeed unless you make a piloting mistake, by restricting that knowledge the player has to either take a big risk, or send a preliminary mission to find out the information they need. This would enrich gameplay significantly, in theory. The fundamental problem with the concept is that the Kerbol system is immutable (accept asteroids), and therefore anyone who has played it before, or just checks the wiki, will no longer need to research everything before a mission. You can't reliably aerobrake over Jool if you don't know the thickness of the atmosphere - but once you know that number it won't matter if the game is aware that you know it. Since nothing changes subsequent playthroughs lose challenge, and many players would just cheat and check the wiki. The solution would be for some variables to be introduced - mass, atmosphere, etc - that are randomized for each game. Thus you actually need to investigate your version of the Kerbol system. Unfortunately topography would be an issue, doing that procedurally would probably be insane, so each surface would probably be identical.

Consider a square made of four I-beams. One of them has a probe core an an engine attached, so that it kinda looks like The Enterprise with only one engine (the square is the saucer). When you fire that engine it pushes the first I-beam, which pushes the one attached at a right angle on its right side, which pushes the beam at the very front of the ship, which pulls on the beam on the left side. In the current system that is all, as the left hand beam is not technically attached to the first one - it only touches it. This causes a bit of a bug though, since heavy acceleration can cause the entire structure to bend, and the ends will move apart and rub around. In the proposed system, the left hand beam would now pull on the first one, which would in turn push the right hand beam, etc. This causes an infinite loop of parts mutually pushing and pulling each other. And it gets worse, because when that initial thrust happened, and pushed beam one, it not only would have pushed the right hand beam but the left as well! So now there are two physics loops one running clockwise and the other counter. Can this situation be resolved? Yes, but it's much more costly to calculate and keep track of than the current system. Remember that in a computer, nothing is simultaneous - you have to deal with each part one at a time, so keeping track of which parts a given force has or has not already effected becomes a huge concern. You can't just run down the tree passing the force along, you also have to keep track of whether or not a force has been applied yet. There are further complexities (which compound as the design become more interesting, and forces come from multiple vectors) that I'm not even going to attempt to describe. This is probably one reason why the Kraken exists - even the current system can cause physics propagation loops, producing phantom forces. The only real option is the "welding" method. Here collections of parts that are connected permanently are predetermined, and become single logical parts. Thus my square of beams is treated like a single object, and forces no longer propagate from one beam to the next at all. This solves the bending problem, as well as the physics loop problem. However now how do you handle breaking one part of the square? The whole thing would be destroyed! And what about a very large ring, that would (logically) bend and flex to some degree - or break apart under enough stress. Welded, it would be not be affected by realistic forces. There really is not good way to do this that will satisfy everyone, because each system has a critical problem. So what do the devs do? Nothing! There isn't a solution that is actually better for everyone than what they have now, so it's better to leave it as is than waste time on something that won't actually be an improvement across the board.

The only way that the current ports make sense, given the way they react physically, is to assume that the clamping ring is not attached to the node by metal - instead the conical part is some thick but flexible plastic that allows the attachment point to flex without breaking. Given that assumption, new ports could use this as a feature, along with a certain breaking point at which the force will decouple the port - as it is a strong enough force will destroy the vessel, instead of simply breaking away at the port. Some ports would be extremely rigid and strong, acting like you built the ship that way in the VAB - others would break apart if you spin too fast.

What if different ports had more or less strength or flexibility? Currently bigger ports keep the vessel more rigid simply because they are bigger, and small ones let the whole thing twist and sway like crazy. Perhaps the more complex ports (resource transferring ports) would not be as strong, and they may become uncoupled under enough stress, while the mechanical clamps that transfer nothing would hold firm as if it was one ship. There could also be different shapes - such as square, or hexagonal ports, that would be more effective structurally, and transfer resources/crew, but would be more difficult to dock (though the forced alignment could be an advantage). Furthermore, port magnetism could vary, so that some ports are much easier to dock than others, due to a greater or lesser pull when they come neer. There could also be a (very expensive) "universal" port, that would attach to multiple other ports, but would be much larger, heavier, and thicker than standard ports - mainly used for stations.

The problem with a more realistic engine design is that real aircraft can have their engines and fuselage designed from the ground up to work properly and be aerodynamic. In KSP we have to build with predefined parts - if the jet engine part was a big long tube like it should be, it would severely limit the designs that are possible. Instead we have a bunch of smaller bits that we fit together in ways that may or may not resemble a jet engine. As players we have to simply assume (as with RCS and EC routing) that the Kerbal engineers know how to build the inside parts of our plane so that it will actually work, and that all the important internal workings of the engine are in there somewhere. Willing suspension of disbelief is an important factor.

I doubt it would work when you don't have the vessel loaded, since they will go on rails. Unless they added some calculation for that, time warp or not piloting usually cancels any rotation - I would assume this would effect the pilot as well.

This will definitely help with slightly off balance vessels that require constant correction (like larger asteroids). Not to mention taking some of the stress out of extremely long burns. The only other thing we need is the ability to set an arbitrary navball target (say, by clicking on it - referably you could even drag the pointer around, while the pilot follows it) - which the kerbals could then be instructed to point at. Sure maneuver nodes work, but there are times when you don't need to go into map view and set up a node to know the right direction to go, but that would be required if you want a Kerbal to hold that course. This way you could just toss a pointer at 45°, and the pilot will take care of it. This would allow for not-quite-autopilot launches, where you can give more focus to throttle and staging, and less to turning, or can get a smoother turn by sliding the pointer with your mouse instead of using the keyboard. I imagine that clicking the ball would place the target at the location of the click, right clicking the pointer would remove it. Right clicking and dragging the ball would rotate it (some visual effect would come up to show that the ball is no longer showing you your heading, but is in edit mode), right clicking the edit-mode ball would cause it to snap back to normal mode. Clicking and dragging the pointer would allow it to be moved, and the pilot would follow the position. Clicking while a pointer is in place would either allow another pointer, or pop up a button to "move pointer here". In the case of multiple pointers, clicking the pointer (and really any of the basic ones) should produce a context menu with the option (if your pilot is capable) to have them target it.

Anything I can manage without enabling the clipping cheat is fine, using the cheat to put previously working designs back together is fine. Using the cheat in the pursuit of creativity is fine. Starting a game and saying "I will part clip on this one" is like giving yourself super maxed out funds and such on the difficulty screen. It's only an issue if you are playing with the intent to beat the designated difficulty level, or have not predetermined that it's okay for that particular game.

Both constant acceleration and spinning ships should be walkable. Kerbals should be smarter than they are now.

I think this would remove too much gameplay from the system. On one hand this would be great, there isn't much fun in performing five identical launches - but on the other hand allowing automation is probably not a good direction to go. Yes, yes, and yes. The science system lacks depth, there is no relation between science you earn and the benefits you receive. Kerbals have an inexplicably high level of knowledge about the Kerbal system, yet they have not yet been to space at the start of the campaign. All that data should be (at least on harder difficulties) recorded by player activity. How high is the gravity around Jool? You don't know till you go measure it. We actually have most of the science parts we would need to measure that data, but instead they just generate generic "science points". Quite true, that would certainly be a good use for the station. I would recomend some new modules designed for training, like a dummy science lab that boosts Kerbal experience faster but gathers no science. My thought on the whole "shipyard" thing is that some designs that could easily fly in space are either too heavy or would have too high a part count to launch from kerbin. It is possible to "construct" a ship in space using docking, but aside from the difficulty of performing multi-point docking, this method isn't very sturdy, and has significant design limitations. I'm imagining a SLS size module called "Orbital construction bay" or some such, that would be placed in orbit. Then another part, or set of different sized parts, called "cargo container" or something would deliver ships in a "packed" form. Basically all the parts of a ship would be added to this cargo container by selecting that ship in the tweak menu, the container would then weigh as much as that ship + some percent extra; different container sizes would have different maximum weights. Once a ship with a cargo container is docked to a ship/station all the parts it contains would become available to the shipyard. Right click the shipyard, select the ship you desire, and it will be "unpacked" from the container. The shipyard would have access to all VAB/SPH blueprints, but it can only build those for which parts are available. You can split the parts into multiple containers (docking them each to the station), or even construct a craft from from the parts of another - as long as all the right parts are present. All resource containing parts would be unpacked empty, fuel and electricity would need transferred from the station. Possibly one could even choose to cannibalize an existing ship, packing it into an empty container. Doing so would allow that ship to be rebuilt at any time, if it was missing parts due to damage, and those parts were available in another container, it could be reconstructed whole. The parts could alternately be reused for another ship. Doing this though should have some extra cost, similar to how recovery of a craft works perhaps. The important thing would be that all the parts of a ship need to get to orbit manually, the shipyard simply allows you to put those parts together like you do in the VAB instead of gluing it together with docking ports.

Rover ramps would be great, could have a part that angles up at the back and the underside opens down as a ramp. The top end would narrow to MkII shape.

Pretty simple, I have at times wished for a Mk II - I adaptor that is much shorter than currently available, the one we have is a full fuselage, but sometime I just want something like the flat adaptors for rockets. Along with that a bi coupler version would also be great. In both instances one may not need or want the weight and length of the current parts, but it looks terrible to attach smaller parts to the ends of MK II parts directly.

Which is the whole point of adding experience to them. If your crew means something as far as gameplay is concerned you will care more about them.

Now here is a thought: Instead of the accuracy of the burn being affected, make it the efficiency. What I mean is that your kerbal would always stay right on the maneuver marker, as long as the ship is stable enough, but by telling a kerbal to do it instead of yourself you would lose fuel efficiency - the maneuver would be perfect, but you would pay for it in dV. Highly experienced Kerbals may even increase efficiency.\ As for the abilities, I would say that the first tier of piloting should be the minor performance boost the devs are already considering; the second tier would allow the kerbal to point the ship at a node/prograde/target/normal (we also need a way to create a marker at an arbitrary point, perhaps by clicking a point on the navbal) on command; the third tier would allow them to also control a burn, which would be split at a user defined point. They should never be able to land, set up maneuvers, or dock on their own. As to the courage/stupidity, I don't think that stupidity should have any direct effect, it should just affect the rate at which a kerbal gains experience. I have no idea how courage would come into play, it probably shouldn't really do anything as far as piloting goes.

Which is why doing it in an expansion makes sense, its actually a pretty big addition if you want it done right, so doing a (probably paid) expansion that people can simply choose to not buy makes sense. To do airships justice we need a new hanger (cause there is no way that tiny space plane building houses a zeppelin) with a new launch site; we need a whole crap load of new and enormous parts; we need functionality to allow buoyant craft to float in place/at constant altitude, loaded or not; we need a new resource; we need new contracts and science nodes. . . To do it up right it need to big a pretty substantial feature and content set.

This, along with boats and submarines, would probably make excellent post-launch expansions. You're talking about lots of new parts and concepts that would be awesome, but don't really fit into the core of the game. Having an airship expansion post-launch would make more sense.

Is Kerbal equipment (chutes and such) ever coming? Along with adding a part, the ability to give a kerbal a camera to use would be great. Probably less "quality" images, but easier to aim at things.

Don't forget that if you take the contract for a part you don't have you can use it in any craft you want. In some situations it may be convenient to take one just for the temporary part.

It looks like the perfect place to store a K-Drive to me. Or perhaps a whole rocket. Take of in space plane, and do a mid air launch. Also, I might EVA a bunch of Kerbals inside of it and see what happens.

Yep, the hard part is the part that isn't even simulated in KSP.

After KSP I just can't stand starfighter combat. Any movie that has little fighters flying around at full burn, banking into turns, and generally pretending that their swimming in an atmosphere bugs the hell out of me. It's especially annoying when one ship is chasing another - the lead ship could spin around and fire back at them in reality, but in the movies they just keep running. Not to mention people forgetting about the third dimension, or flying into a hanger head first with their engines still burning - how are they slowing down?

The most useful thing about multiple launch pads would be non equatorial launches. Getting various angles is easier if you start from a different latitude, so both launchpads and airstrips at other locations on kerbin would be great.

Seems like the simplest thing to do is for quick saves to not overwrite each other, and for the quickload button to ask for confirmation when and only when the save it is trying to load is older than some set amount (or older than the current session). Furthermore backloading should not delete/overwrite the more recent saves, allowing you to load them if needed. That means that you don't accidentally overwrite a quicksave, you won't accidentally load one that's days old, and if you do you can load an autosave that's more up to date. The load list should tell you the real time timestamp, game time, science amount, and number of flights for every save in the list. Also you don't have to make a "hold to save" feature very long. 500ms is more than enough to prevent accidents, but still more than short enough to avoid being annoying.