rynak

I tend to not create debris that cannot deorbit itself. Even my sats that have been put into proper orbit, always have more than enough fuel to deorbit themselves. If it happens however, i just disable it in the tracking station. And yes, i too use a plugin to get funds for retrieving stages. I almost never plan to detach stages while in orbit - it all happens during ascent and insertion.

Umm, this seems broken in so many ways... where do i even start? I suppose the relevant part vars are minimum_drag, maximum_drag and angular_drag? If yes, those indeed are the same for almost any part. So basically, using larger parts produces less drag, than using smaller ones? If the above is correct, does SDF affect this in any way? If yes, how?

How would a thin atmosphere be relevant for deployment speed? EDIT: I myself did edit the timespan down in the configfile to 3 seconds - but as i said in my prev post, i see no need to adjust it on a per-vessel basis.

Something in-between. The core, supply tanks and solar trusses are planned in advance. However, for the later two, there's not much to plan - it's just a giant fuel tank with some RCS and a small probe after all. Similiar for the solar trusses. Each part i send up, has ports to attach additional ones, so as long as i keep weight and symmetry halfway balanced, i can then extend it as i later see fit. I've seen people send up really giant sections up in a single go, but i prefer keeping the segments at medium weight and single purpose. All of this is for Kerbin of course - for other planets and moons, more planning and tricks are called for, because each flight takes a lot of time. For the kerbin station, the parts usually stay at a weight manageable enough that i can even let a strong spaceplane lift it into orbit.

Proposals about the GUI: Currently, it is rather cluttered, because of all the many options. Unfortunatelly, most of them are probably used by some users. However, at least two mostly are just aesthetic, and probably never have to be changed between vessels, so i propose to remove them from the GUI: - Predeployment speed - Deployment speed In fact, removing those might clear up confusion - some people probably think the above is about the VESSEL SPEED at which chutes deploy - but nope, this is just how fast the chutes deploy once activated. Other minor tweaks to the GUI: - Add an X button to close the window and apply settings. I know you can just click elsewhere, but the intuitive reaction is to look for a close button. - Remove the confirmation dialog about settings having been applied. If i click apply, i expect that it worked, unless i get an error message. It just adds another unneccessary step in the GUI --- A last proposal, unrelated to the gui: In the config files, have a setting to globally scale the model size of parachutes. What it is like now might perhaps be realistic, but in terms of usability, the chutes often obscure my view because of their size.

I'm not sure if your specific example is a reasonable one: AFAIK, in RT antennae can only rip off, if they're deployed. Now, deploying an antenna in the cargohold seems a bit like a cheat, to circumvent the gameplay restrictions of parts, which RT put there on purpose. If i'm right thus far, the RT devs have no reason to address this "issue". But ignoring your example, this is of course a valid issue. The problem for people like starwaster is, if it is even worth the effort to do anything about it now, when the next KSP version may or may not address this aspect automatically.

@CP: Thanks, there are some nice ones among those - though, the tiled surfaces do not really fit stock or B9, and as you can see with "shuttle", which is very similiar to what i came up with today (minus the tiles, and the dark underbody is aligned to fit B9), most texture overestimate the brightness of the grey that stock and B9 use. There are three main aspects, which tend to make most of the available PP textures look out of place for stock and B9: - Tiles and small patterns - Lack of "ends" on the sides. I think this might be a limitation of the plugin - haven't seen any config options to map ends to the side textures. - Too bright At the risk of stepping on someone's toe, my overall impression is that most available PP textures were made by programmers, while the textures made by custom part makers seem to mostly be made by designers. EDIT: This is what i hacked together in 30mins (most of which were spent on reloading KSP over and over). To be used without tiling. It of course isn't on par with the nice B9 textures, but it fits the dark underbody, and the brightness of the upper body and lower body matches B9. Sorry for the size - i tried to make it smaller - this seems really wasteful - but if you size it down further, interpolation artefacts become excessive. Size could probably be lowered, if PP has just the right tiling options, which i couldn't find, so i disabled tiling alltogether - hence the large tex: Now to make up for the above, here's the most simple thing missing from the supplied textures that come with PP - a grey that matches stock, at sane texture size: EDIT2: A remark about the reverted poly reduction. I think there is room for poly reduction - it's just that with the previous version, the reduction went too far. Try something in-between the current and previous version.

So, a compass would be unrealistic scifi? Ahem.

Is there a texturepack that fits nicely with the typical cockpits? None of the supplied ones (incl. "stockalike" which oddly looks out of place with stock parts), or those linked in the OP do. Any other alternatives?

I think having kerbals that are proficient in multiple classes would be annoying to manage. However, after level0 being able to choose their profession, certainly is one way to solve having to rename your custom kerbal over and over, until getting the profession you want to give him. (Or, you know, they could still code this properly by just making profession an attribute - like any sane coder would do)

What's the reason for the MK1 fuselage not showing the option in SPH to edit the fuel types? I looked through the configfiles, but found nothing unusual specified about them. Is this hardcoded into the plugin? EDIT: Nevermind, my mistake. The part wasn't the stock one.

I don't use them, because: - The idea of custom groups is nice, but the UI is too slow to make it anything but a chore - I would use it, if it allowed me to set up parts and categories that should always be ignored, but it doesn't have that feature either. IMO, the advanced menu completely misses the point of what people need. With plenty of mods loaded, or far up the techtree, what you need isn't a whitelist, but a blacklist. The standard part categories mostly are fine - what is needed aren't MORE categories, but a way to globally disable listing of certain parts. For example, it really annoys me, that there is no way to disable display of unavailable parts (those greyed out ones, where it says you need to purchase them). What IMO should be done, is nuking most of what currently is in the advanced menu.... it just adds clutter. Keep the ability to set up custom categories though (and improve the UI to make building them faster). Then, instead of the current whitelists/advanced categories, have buttons to globally disable types of parts.

Exactly. Since this mod adds those, i'm quite sure it has something to do with this mod. The standard KSP markers are easily visible... its just those which this mod adds, that are "dark marker on dark navball"

"Stock Drag Fix". It mainly addresses what's wrong with how stock calculates drag from mass (i.e. different drag for empty and wet tanks). So, wingshape sadly isn't not taken into account.

Early-game light atmospheric plane, to do the various lower tier contracts: It's semi-unstable, but doesn't tailspin unless you try really hard - despite of the quite excessive pitch authority. Turns as if it were nothing, and has enough rocket fuel to go into the stratosphere. Also plenty of jet fuel. It can deal with leightweight cargo (tested up to 5t), but obviously isn't made for heavy lifting. Now on to designing a proper rover - too bad that stock supplies barely any parts, and most of the mods either supply finished vehicles, or highly specialized parts.

I cannot vote, because SDF with spaceplanes is not in the poll. Tried FAR and NEAR, and didn't like the complexity, but also wasn't satisfied with stock. So, i settled for SDF + KIDS... it doesn't take everything into account that i would like accounted for, but the model i'd like currently doesn't exist. I mostly design spaceplanes, but do occassionally also build rockets to lift heavy loads.

Sorry, but i hate the proposal of the OP. I don't want to fight against my own crew - i already have to fight the physics, framerate and whatnot. On the contrary, some of the existing animations already annoy me, because they take overly long - like falling down and standing up. If you want to make the kerbals more "personal", then there are better ways to achieve this.... finalfrontier might have gone completely nuts with the number of achievements, but the basic idea is nice. I also wouldn't mind if the current abilities system were expanded. Then, i'm affraid to mention this, because if SQUAD ever goes to do it, their attitude towards texture memory might ensure that no home computer has enough RAM to load KSP anymore.... but anyways, aesthetics: We're talking about a game, where almost all kerbals look the same, as well as their clothes. Heck, there not even is a variable to say if one of them is male or female, so texture replacer has the player fix everything manually. So yeah, "more personal" sure - "more petlike" no thanks get the hell away from me.

Thank you for the hints! MC2 and KCT add too many features unrelated to this, but i didn't know about SRL, and it pretty much does just what i proposed. The "SIMULATION" label is a bit too big for my taste, but i'm sure i can change that quickly in the source. Again, thanks!

That would be ideal.... i just don't consider it neccessary for upgrades to be tolerable (i've come to set my expectations low with regards to stock ksp). Another issue about having a 4th upgrade level is texture memory. I'm sure you've noticed how much memory usage has increased with the recent version. I wouldn't be surprised, if a significant share of this comes from textures for all the different upgrade levels. Of course, if SQUAD were to efficiently reuse textures between the different upgrades, that would be no issue... but again... low standards.

But then you would lack a curve to scale ISP for designs that need ISP scaling - hence eventually you again would end up with a 3rd curve.

I really don't think an entirely different model is neccessary to make jet and ramjets engines behave more intuitively. Would a diffferent model be neccessary to make it realistic? Yes. Do i care about making something realistic? Pretty low priority to me. Does it bother me when something behaves unintuitively, and doesn't actually do what the description says? Yes it does. To put it simple, all that is missing, is an atmospheric pressure vs thrust curve. There is already a curve for speed vs thrust, and altitude vs ISP. Add the third mentioned curve, and almost everything can be approximated. (I.e. for ramjets, you could reduce the thrust at high atmospheric pressure. Et voila, there you have ramjets that don't work well at low altitude, but good at high alt and speed (the later can already be done via the speed vs thrust curve)). P.S.: The reason i post in this thread so late, is because the topic title is retarded. It alone put me off from even reading the thread for days.

I'm sorry to start off on a bad note, but honestly: What were they thinking? This is just a placeholder, right? Flying without any action groups at all? You mean, i can't even keybind my ENGINES? No staging? Seriously? And what about the vast difference in costs, for the first and second upgrade? I could go into all the details, but quite simply, i think the problem is systematic: Level 1: Unusable Level 2: Basic features. Affordable early game, because L1 is useless Level 3: Everything and the kitchen sink. Affordable late game. There is nothing in-between to bridge the gap. -------------- Instead, rebalance this to be as follows: Level 1: Basic features Level 2: Intermediate features. Affordable midgame. Level 3: Everything and the kitchen sink. Affordable lategame ----------------- So, to take the SPH as an example: L1 = Basic Action groups, L2 = Plus 4 Custom Actiongroups, L3 = All Custom Actiongroups. Or, to take the runway: L1 = current L2 runway but more narrow, L2 = Something in between current L2 and L3 with illuminated runway (though, not as much as L3), L3 = Current L3 runway Similiar pattern for the other facilities, like the launchpad.

I added a proposal for a mod, that deducts a configurable percentage for reverted testflights: http://forum.kerbalspaceprogram.com/threads/107924-Revert-Costs

I too woud like this.

Inspired by this thread: http://forum.kerbalspaceprogram.com/threads/107852-Do-you-fly-test-flights-in-career-mode The poll suggests a 50/50 split between people who revert their test flights at no cost, and those who do pay the full costs. This implies that there might be a middle ground, which currently isn't represented at all in the game. At least, i'm among those who would like a middle ground. Until now, i revert all my test flights at no cost, for the following reasons: - I do not want to land over and over and over again, just to test a minor change - Since the game offers little tools to "simulate" things pre-launch, you have to compensate with more test flights. A deficit of the game should not be the player's burden - hence, i'm unwilling to pay the full vehicle costs. Heck, i could land and recover most of them, but just cannot be bothered to do it over and over again. BUT, i do not expect development to be free. I could fully understand and might even consider it interesting, if a test-flight costs a percentage of the vehicle cost. Hence, my proposal for plugin to do this: Just have a configfile in which you can set a percentage, and the plugin then on revert checks the vessel cost, and deduct the funds that are not covered by the set percentage. No GUI neccessary or other complex stuff neccessary - just automatically deduct on revert, and that's it. If this is technically possible (that is, ability to detect revert, and get the vehicle costs), then this probably would be a <10 minutes coding job.