Crimson Sunrise

As Frank Zappa would say about this occurence: "This is the equivalent of treating dandruff by cutting you head off."

I'm not asking how he was punished. I'm asking if he was punished or not. Sure his name was mentioned up there, but...You know how it goes, specially if said person is a moderator. But that's just what I think.

If I wrote a specifications document on how the feature I'm suggesting should work, would that be taken into consideration better? Just curious. Think of it like a Python PEP or something like that.

How about telling what those non-descript 'shenanigans' are to being with?

But how you distinguish between mods that don't break the game versus mods that do?

Sorry for asking, but: Was the responsible for starting said flame war punished in some way? If not, your point seems a bit moot in my opinion.

I find myself not playing career mode at all simply because how confusing it is. I maybe be not the brightest of bulbs, but still. It was a confusing experience to me when career mode was first introduced and it's an even bigger confusion nowadays. IMO, it seems a bit sad that most of the basic stuff in KSP that shouldn't need explanation at all has to either be fiddled around or requires a tutorial from someone else outside of the development team that had more patience to tinker with it and figure out how it works than me. The game looks nice enough when you see Scott Manley playing it...Then you try to do the same thing and...the experience is different. Of course, this is about career mode, not stuff said YouTuber is capable of doing naturally because of prior astophysics knowledge or something like that. So, my point when mentioning Scott Manley is not about orbital maneuvers and things like that. Those have a 'recipe' and a series of tasks in order to be executed properly. My point is about hard things that shouldn't be hard at all, like figuring how to play career mode without relying on external sources. A game shouldn't require prior knowledge of itself in order to be played, or else only people that play the game already know how features work, while new players get frustrated trying to figure those out, because it lacks documentation or its documentation is so vague that is the equivalent of not being there.

A clbuttic mistake indeed.

Well.... If you have limiting features on sandbox mode, then it's not really a sandbox mode, is it? Some people just want to fly their vessels without having to worry about limitations, otherwise they would be playing career mode instead, wouldn't they?

Problem is that wings in general lack a thickness setting both for mods and the stock KSP. Notice how the B9 wings fit with the larger models, but are too big and thick for the smaller ones. KSP's stock wings on the other hand, look good on small planes, but are too flimsy and thin on larger planes. The pWings mods has a somewhat fair balance of both, but sometimes, you want large and thin wings, in which pWings fail, since it increases the thickness of larger wings. A 'thickness' setting has been mentioned by DYJ some time in an early version of the mod, but I've never seen it in action or it doesn't work as it should. So, the ideal solution (IMO) would either be variable thickness wings, implement a TweakScale that works on parts other than tanks and engines or implement pWings and work the thickness setings out.

A simple flag check could have solved this quite simply in a simple "algorithm", like: 1- Check which game mode is being played. 2- If the mode is sandbox, remove class limitations. 3- Otherwise, apply class features based on the game mode played (which should provide info of that as well).

Before that's even debatable...What's a 'trillion trillion'?

The problem is that mods affect the game indirectly, even when not used in vessels, especially since the introduction of Module Manager some versions ago. This bug might be caused by incompatible mods. For example. On computers with 3 GB of RAM or less, Active Texture Management fills the entire memory of the pc, making KSP cause 'out of memory' warning messages and sometimes crash before it finishes loading. And KSP doesn't even complain about compatibility when it is running. Also, you said you have Kethane going. As far as I know, Kethane changes A LOT of things in the core game as well (patching by Module Manager).

Did this happen without any mods on? Cause I'm pretty sure the code of 0.90 is different than 0.25. Even if KSP didn't told you which mods aren't compatible, I wouldn't trust that 100%.

I believe the Oberth effect burn has to be executed manually.

Hm...Looks like a variation of the Cthulu...

Well, since I've only played sandbox so far, that's the way SAS is supposed to work in that 'snap' setting: Just hold the current position. A great improvement over 0.25's SAS, that insisted in snapping to the Prograde vector.

That nosecone at that weight will be a major issue for payload SSTOs that use all their fuel to get to orbit. Once you're into Kerbin, your plane suddenly becomes top heavy and you have no control authority over it.

Well, while OpenGL makes the game run faster in my end, it also doesn't render shadows, making landing harder. Not worth the extra speed boost.

Well, maybe because I'm too used to playing the game with FAR...I can't take my planes off the ground since the control surfaces have little to no lifting power over large mass objects like a Mk3 vessel.

Another one would be a better text explanation on how to use the 'root' modifier. It's description is so vague in asking you for steps that I haven't figured out how to use it yet.

A window that displays he readout for science parts when they are on a vessel along with the ability to gather science from them from said window as well. Some of these parts are too small to be found in a vessel, especially in a hurry.

The title says pretty much everything about this suggestion. This would be helpful to deal with attached sub assemblies that don't depend of the main staging to be used, but are attached to decouplers, for example. If you have a big vessel with a lot of stages, it becomes pretty hard to find out where your stage that shouldn't be activated is and increases the risk of you misplacing it on the order. Once you remove them from action groups, they return to the staging column. Another nice thing would be to have command order priority for action groups, much like staging. You can decide in which order things get done by creating groups for different actions. This would give an easier implementation to the prior suggestion, since you could just set the entire staging sequence as an action group of the 'Stage' category, pretty much like landing gear and lights get automatically assigned to their respective groups in the Action Groups tab.

Larger wing parts that for with the new Mk3 parts would be one of the things I expect to see.

Well, while this title may be a little misleading or confusing, it has something to do with the newly released 0.90 update. You see, the new large plane parts are nice, but we don't have wing parts large enough to make usable planes with those parts yet. Sure you could jam a bunch or smaller wing parts and make a big wing, but that would only increase you part count and make your crafts too resource heavy. I know the system is supposed to follow a modular format and all that, but would be too much to ask for some thought before introducing new parts?