A bunch of mixed suggestions

[Troberg]

Some humble suggestions, all based on my own, personal, opinion:

* The main focus of development at the moment needs to be performance. I have a decent computer, and as soon as I try to make something a little bit more complicated (say, 500-1000 parts), the performance drops to levels where I use MechJeb, simply because a launch to orbit can take an hour or more. Suggestions for improved performance:

** Don't treat all parts as structural. For example, I want to add lights, antennas, navlights and other mostly aesthetic stuff, but, as they increase the part count, perfomance drops to a slow slideshow. So, my suggestion is to treat those "decorative" parts as just decorations, and not include them in the physics calculations for structural failure et cetera. That would reduce the number of performance sucking components a lot.

** Add something like Procedural Fairings, but, when the payload is hidden under the fairings, it's replaced by a "dead mass", with the same center of gravity, angular momentum and so on, but it's one single part. That way, even a complex payload (like my current 600 part permanent Eve base) would run smooth as grease. It would also encourage the use of fairings, which means nicer looking, more realistic rockets, instead of the usual bird's nests.

** Allow some parts to make a permanent bond, in effect making them a single part for the physics engine. Example: Tanks. If you use a stack of two orange tanks or four half size grey tanks shouldn't matter. Either way, they should, for the physics engine, become one big tank, totally rigid. Less parts, better performance. Would also reduce the wobble problem a lot, as well as making "realism sense" (for a real rocket, they would make one tank as large as needed, not stack a bunch of small tanks). Other positive side effects are less need for struts (once again, fewer parts) and less different parts needed (why need several lengths of tanks if you can just stack smaller tanks).

* Larger VAB and SPH. I frequently build craft that don't fit well in them, especially the height of the VAB is a problem.

* Landing pad. Precision landings are fun, but the launch pad is usually cluttered by launch supports, and has some nasty slopes. So, just a circular concrete pad with some markings to land on would be nice.

* Autoexec action group. I'd like to be able to set up an "autoexec action group", where I could add actions that should be performed automatically even before the craft is put on the launch pad. Typical examples: lower gear (for testing landers and stuff, it's often useful to start in the "landed" position), disabling gimbaling, disable fuel cross-feed, activate lights/nav lights and so on. Basically, a way to put the vessel on the launchpad, ready for start without fiddling around.

* View controls in the SPH. For larger craft, they quickly become very awkward and pressing the correct key almost becomes guesswork. I'd like some more intuitive, first-person-shooter-like controls. Move with the arrows, look with the mouse.

* Trusses. I often put stuff on other places than the ends of the trusses, and it's fiddly, very fiddly. I'd like some more attachment points, such as on each side, half a truss width from the end (for nice 90 degrees joints) and halfway along the length on each side.

* Realism. I know there are a lot of people who wants hardcore realism, but I'd want a mode left that's something like what we have today. Frankly, I have no interest in the next to impossible logistics of realistic manned interplanetary flight. Too much realism would also create a too high threshold for new players.

* VAB and SPH, aligning parts. A common situation is that I've, finally, after fiddling around with pixel precision mouse movements, manage to get the part where I want it. Problem is, it's not pointing perfectly in the direction I prefer. So, I'll have to click the part and try to align it properly without it popping lose and me having to start over.

My suggestion is some modifier key, say, Ctrl, which, when pressed when clicking a part, leaves the part connected in its current position, but still allows me to rotate it.

* Building "rings". As far as I can see, with the exception of struts, no components can be connected so that a loop is formed. or, in other words, they will only connect on one node when you place them. Example: Take four four-way connectors and four habitat modules (or tanks). Try to make a square using those parts. When you try to put the last part in, it will only connect to one node, making the construction wobbly. Sure, I can use some mod, such as quantum struts, to stiffen it, but then I get more parts and require a mod.

I suspect this is a biggie to fix, as it probably would require changing the internal data structure as well as the VAB/SPH logic, but it would be very nice if it could be fixed, as it would allow some very sturdy constructions.

* Stronger parts. Seriously, vessels over a certain weight is next to impossible, as tanks start to collapse simply because of the weight of the stuff stacked on top of them.

* Clearer part descriptions. The main thing I miss is clear information about if a part is 1.25m, 2.5m et cetera. Shouldn't be too complicated.

* Mod compatibility. I know it's under development, and one can't do a lot of work to not break mods. That said, try to avoid unnecessary changes that will break mods, and try to announce in advance what mod makers will need to do to keep their stuff working, to minimize their downtime.

Face it, KSP is, for many players, a very mod driven game, and breaking mods slows adaptation of new versions and causes unnecessary annoyance. I'm not saying that you should go out of your way to preserve mod compatibility in all cases, but keep it on the agenda.

* Modders. Seriously, there are some really, really good modders and mods out there. I know you've hired one modder. If economy permits, consider hiring more, or negotiate with some of the modders to give some mods an "official" status as part of the base game.

Now, it may look like I'm just whining, but the truth is that I really love this game (I wouldn't do a two hour slide-show speed launch with choppy sound if I didn't really, really love the game). That's why I bothered to write this long post with suggestions about some details that bothers me. I hope some of them will be found useful. Either way, excellent work, keep it up!

[stupid_chris]

Alright, that's a whole lot of suggestions, I'll try to go point by point:

Performance: The performance upgrades are limited for now. By what? Mainly by Unity, the game's engine. Changing engines at this stage is completely out of question, and since Unity does not support 64bit and multithreading, what you can do with it is very, very limited. Hopefully, support for both of those things will be added soon. Now for the specific points:

1) That's already being done. Parts whose's mass is low enough are being treated as completely massless and are ignored by the physic engine at some extent. I.E. struts, cubic octagonal struts, etc.

2) Read your stickies! Fairings are on the do not suggest list! Also, your idea of removing the structures below, as good as it is, would mean loading all the objects upon fairing separation, which could be extremely demanding to the game depending how much stuff is under. Try to think about your big crafts loading on the launchpad.

3) That is also on the do not suggest list. There's a mod for it in the meanwhile.

Larger VAB/SPH: The lasted updated sort of nerfed this in my opinion. There was a mod who made the VAB/SPH larger, but they removed that feature now because the new ones are much larger.

Landing pad: Could be useful. I see this further down the development road though.

Auto action groups: Most definitely will be useful, I agree.

Controls in SPH: I have no idea what you mean there. Really, controls are the same at all time and don't change from a craft to another, so I don't really understand what you mean here.

Truss attachment nodes: A few more attachment nodes would be useful, but it wouldn't be really adaptable to any situation, and it could cause some attachment node clustering which could be hard to manage in the editor.

Realism: An insane amount of realism is not planned, and it's even being rejected by the devs. They want this to stay a cartoonish and fun simulator game, not a realistic simulator. This is partly why they left the game moddable though, so everyone could have it the way they like.

Aligning parts: I agree on this one too, would be useful.

Rings: This would be insanely complicated for the editor to recognize two simultaneous attachments on a part. That would likely require a complete rehandling of the parts in the VAB and SPH, and if it is to happen, it's probably far on the development priorities.

Stronger parts: That comes from the way the parts are handled together and from how they are attached to each other. Currently, the game considers a single attahcement point between parts, and that causes a lot of weird things. Stabilizing the parts will most probably come sometime relatively Soonâ„¢.

Clearer information: Usually it's given, and after the first time you test it out you'll realize what size it is.

Mod compatibility: I'm forced to completely disagree here. You have to understand that the product here is in an early development stage, and when you accepted to buy it, you should be clearly aware that everything is subject to change and break between versions. Mod compatibility can't be guaranteed just as your saves or craft file's compatibility will be guaranteed. The devs can't announce beforehand what mod will break and how to fix them, that's utterly unpredictable. Some of the most random mods can break for no reasons. The best they can do is announce beforehand what is planned for the next update, and they already do it. This way you can get an overview of what might break. CrewManifest, for example, broke and it was predictable, because they completely changed how crew was being handled.

Hiring modders: Squad is a small marketing company. Really, they do what they can, and you can't really tell them "hire more modders". Yes they hired some, and they said they would hire those that show some extraordinary assets that would be needed in the team, if they have the resources to.

[Troberg]

2) Read your stickies! Fairings are on the do not suggest list! Also, your idea of removing the structures below, as good as it is, would mean loading all the objects upon fairing separation, which could be extremely demanding to the game depending how much stuff is under. Try to think about your big crafts loading on the launchpad.

Well, my suggestion was not so much about fairings as it was about a way to increase performance by replacing many parts with a single part. Fairings were just a way to hide the switch.

Yes, it would probably freeze the game for a while while the parts loaded, but, frankly, I prefer a 20 second freeze to a 60 minute slide show...

3) That is also on the do not suggest list. There's a mod for it in the meanwhile.

Sorry, I didn't see that in the list, must have missed it. What's the mod, and does it increase performance as I suspect it will?

Controls in SPH: I have no idea what you mean there. Really, controls are the same at all time and don't change from a craft to another, so I don't really understand what you mean here.

A practical example: I was working on a largish base today. I was zooming/translating around all over the place using shift and arrows. Then, when I started trying to just rotate with the left and right arrows, it got strange, probably because I had moved past the point it used to rotate around.

The problem is there with all crafts, but with small, uncomplicated crafts, you'll probably not notice it.

Rings: This would be insanely complicated for the editor to recognize two simultaneous attachments on a part. That would likely require a complete rehandling of the parts in the VAB and SPH, and if it is to happen, it's probably far on the development priorities.

Yep, I know. That's why I said it was probably a biggie. I just wanted to throw it out there, and maybe, somewhere down the line, in some future version, it'll happen. Maybe just some workaround (hmm, perhaps it can be done using docking ports...).

Clearer information: Usually it's given, and after the first time you test it out you'll realize what size it is.

Yep. I know. I just see it as an unnecessary newbie hurdle that could be easily fixed.

Mod compatibility: I'm forced to completely disagree here. You have to understand that the product here is in an early development stage, and when you accepted to buy it, you should be clearly aware that everything is subject to change and break between versions. Mod compatibility can't be guaranteed just as your saves or craft file's compatibility will be guaranteed. The devs can't announce beforehand what mod will break and how to fix them, that's utterly unpredictable. Some of the most random mods can break for no reasons. The best they can do is announce beforehand what is planned for the next update, and they already do it. This way you can get an overview of what might break. CrewManifest, for example, broke and it was predictable, because they completely changed how crew was being handled.

I'm not saying that the devs should do the work of the modders, just that they should "let the information flow". For example, the new directory structure in 0.20 could have been announced a week or two in advance.

Likewise, I'm not saying that ani modding interfaces should be etched in stone, just that one should weigh in "will this change break mods and is it worth it at this point" as one factor in the decision process.

I'm a developer, and I know how frustrating it can be to develop for a "moving target". I've done that, a lot. It helps a lot if one gets some insight into the thought process of the devs who make the target, as well as some information like "this bit is pretty much done as it is, it's not likely to change for a good while", "we are rewriting this bit, be prepared that you will have to handle data like this instead" and "this is mostly just a test stub, don't rely on anything to be stable or unchanged".

Hiring modders: Squad is a small marketing company. Really, they do what they can, and you can't really tell them "hire more modders". Yes they hired some, and they said they would hire those that show some extraordinary assets that would be needed in the team, if they have the resources to.

I'm not telling them, I'm just suggesting. There is talent out there, and they got an excellent opportunity to see the quality of their work. Hiring is hard, and any indication of the competence of a candidate is worth a lot of good money. Then again, a company, especially a software developing company, needs to grow organically and at a pace where new developers can be assimilated into the team in a good way, so one should not hire so much that one dilutes the core competence. I've worked at a small company for a long time, and have seen both how it should be done and how it shouldn't be done.

Either way, my suggestion was more about pointing out a possible resource than a command to hire.

[Troberg]

Oh, another thing:

* When you move a vehicle from the SPH to the VAB (I often build payloads in the SPH, then move them to the VAB and add a lifter), symmetry gets messed up. Say, for example that I set it to 6x symmetry and place an RCS block on the side of the tank, instead of getting six RCS blocks placed evenly around the tank, I get a circle of six RCS blocks on the side of the tank that's facing me. This is probably just a minor oversight, missing to adjust the orientation of something in the transition.

[MR4Y]

3) That is also on the do not suggest list. There's a mod for it in the meanwhile.

Considering that any support is now denied if you use mods, I don't think recommending mods would be recommended.