rynak

This indeed was true back when KSP was started, but now unreal for all practically purposes costs 20$ ONCE, and then NOTHING, while unity will constantly cost revenue. Again, this is the difference between "back then" and "now". At the time KSP dev started, unity indeed was the cheapest option, and other engines like unreal were unaffordable. Now however, the roles have reversed - the competitors are so desperate for marketshare, that they will do everything but stop short of outrightly giving their tools away FOR FREE. Basically, unity started out as financially viable but technically inferior (if you ignore ease of cross-platform releases). Then as the need for a cheap entry dev IDE gained speed (pioneered by unity), the market momentum REVERSED: Unity relatively became more expensive and less fit, while the desperate and panicking competition outdeveloped unity in terms of tech and conditions. The reason unity still is capable of holding its current marketshare is MOMENTUM, not actual meat on the table! To any unity fan, this should be alarming! It means the competion is desperate to level the field (even going as far, as giving game devs *directly debugging access the the engine devs, for 20 bucks a month! Something unity has never ever done... google around for the reports. The competition is giving devs direct chat contact to the engine devs, while unity devs get no more than the equivalent of a run-of-the-mill hotline)... yet, given unity5 press announcements, the vendor behind unity apparently sees no need yet to up the game - instead deciding to milk it's cashcow, instead of investing into future competition. The people behind unity feel save and secure in their market position, even while the competition is practically selling below cost. The only reason for a vendor to ignore such an obvious market situation, is to either sell-off it's "asset", or to consider its own benefits way beyond the competiotion - if the later is the case, i think part of the complains behind KSP, and plenty of other unity-based games, tell you the reality of unity's marklet position: Up til now it rose to it's position by simply being the "least evil" if a low-entry-barrier and multiplatform releases are a requirement. "Least evil" is not a "comfortable" market leader position, unless you have means to via unethical but legal ways simply eliminate opposition (think microsoft, EA, etc).

Wat? @ dev > null.

Seriously, why is even a bugreport or forum post of this required? Stop downscaling anything that is already small. You're punishing developers who allocate reasonable texture sizes for things like icons, by making them larger than neccessary, just because you did not spend 5 minutes to consider, that textures smaller than i.e. 128 do not need further downscaling. (For those unfamiliar with the issue: The texture-quality setting in KSP does not care about the size of textures - it downscales anything it finds, no matter how small it is - if it is already smaller than i suppose 32x32, it will become invisible (i.e. blank icons) because of GPU limits. It also is the reason for the recently reported pixelated icons... see, before 0.90, KSP would not downscale textures in PNG format, so modders thought their textures/icons in PNG format were safe. Starting with i think 0.90, KSP started downscaling PNGs as well, so modder's icons became pixalated/invisible. Still, neither did SQUAD apparently inform modders about this, nor did they finally implement any way to recognize textures that shouldn't be downscaled further - most simply of it being a plain lower texture size limit: <5 mins of coding time refused).

I'm not sure what is the purpose of this poll, and it also fails to mention an important distinction: Initial orbit vs. target orbit. See, once you have established a circular orbit, raising or lowering it is cheap. So, changing the initial orbit is a non-issue. For this reason, really only safety, timing and ressources matter. I could go for scraping the atmosphere, but there is no reason to do so. So, i just target an initial AP of somewhere around 75-85 AP.... more if the vessel will eventually go to hundreds of KM anyways. Which brings me back to my initial question: What was the question again? Need more info.

Your problem - at the very least since 0.90 - is split in two: KSP itself, and mod textures. KSP itself doesn't have the best optimized textures (especially the dozens of kerbals in the assets - who needs those resolutions? And up to this day, what is the megalomaniac MATRIX texture actually doing?). But since 0.90, there is another aspect to it: KSP itself consumes not just hundreds but over a GB of memory, ignoring textures. And there seem to be leaks that result in an inevitable out-of-memory after some time. ATM will neither fix the assets (it doesn't compress those), nor the memleaks. I run a highly optimized install of KSP - more than i suppose 99% of players are capable of achieving. Yet even my playtime is limited by: A) Initial wasteful base mem requirements. Memory leaks. The other aspect is textures of mods. By now, this for fairness has to be split into at least three considerations: 1) No on demand loading and unloading of textures. I suppose argument in favor of this is: If your puter cannot handle loading ALL textures at the same time, then it would eventually crash anyways, as soon as there are enough vessels loaded into "physics range" (a pitiful and laughable 2-something kilometres distance - what is this - the 80ies?). That might be so, but potential of crashing does not justify performance at a given point in time: When i design a puny probe in the VAB, i do not expect ALL textures of ALL parts, plus the entire vicinty of the KSC and kerbin, AND its oceans, to be loaded into memory... yet, that is what is the case. And it does matter, because FPS in the editor matters perhaps more than inflight - after all, you interact much more frequently with your craft in the editor, than in flight. 2) Texture memory: I could write a long story here, but i think by 0.90, there are only two things to mention. First, neither squad nor modders care anymore by now about texture memory (most of them: I honestly apologize, if you're one of the exception - you'll get karma points in a few secs). This might seem like a bold claim, so to debunk any myths, let me tell you this: I have seen plenty of times SINGLE COLOR TEXTURES, of 1024x1024 or more... often 2048x2048.... MILLIONS OF PIXELS OF THE SAME ONE COLOR. DOZENS OF MEGABYTES (multiplied by THREE in VMEM), that can be expressed in THREE BYTES. I'm not kidding - i'm talking about a BLANK SINGLE COLOR IMAGE, wasting dozens of megabytes of VRAM. And that's not a singular case. I've seen it many times, and i see it regularily for two or three color textures. To put it bluntly: Some devs with overly expensive rigs, seem to think that since they have a machine that can abundantly waste memory (probably on linux, without 32bit limits), they seem to think all it's users can afford to not give a ***** about VRAM too. There's a quite devious twist to this: It would appear that at least with regards to icons, some modders have adopted more efficient goals. Unfortunatelly, they now are punished for it - and forced to allocated larger textures than neccessary. This is because before 0.90, KSP used to not rescale textures in PNG format. So, modders started assuming, that if they store their textures in PNG, they will not be rescaled. THIS NO LONGER IS TRUE IN 0.90, and it is the reason for the pixelated or nonexistant icons reported in various threads. In theory, this is actually a feature, since normal part textures now are properly rescaled even if stored in PNG. It however stops being a feature, when apparently SQUAD did not inform the modders at all about this, nor about how to mark icons as non-rescalable. (Squad, you reading this? If you had spent 5 minutes of devtime, to set a lower limit - say, that textures smaller than 128x128 should not be downscaled... you wouldn't even have had to bother informing modders, and would have established forwards compabibility in uncountable cases.) 3) This is a new thing, especially in 0.90. It used to be that KSP requires an excessive amount of RAM, but a rather fixed - and in terms of 32bit VMEM manageable - amount of VMEM. So, even though the "fixed base costs" were significant, they were mostly static. This no longer applies in 0.90, because of memory leaks: No matter how carefully you pick your mods - no matter how much time you spend on handoptimizing textures (or letting ATM do it) - KSP will inevitable run out memory no matter what you do (on 32bit - much later on 64bit if you have enough mem), because of memory leaks. For example, on my setup, KSP will lose half a gigabyte in 20-25mins of playtime... so, no matter what optimizations i apply, i will have to reboot it from time to time.

If you google around a bit, gather infobits and then dig a little bit deeper, what it comes down to is this: Most of what is promised about unity 5 is garbage. Unity is at it's peak, and the vendor is milking it while it still sells well (even if in the process killing the goose that lays the golden eggs). BUT: Unity 5 will bring actually stable 64bit builds, and a physics engine with more or less improved performance. Since KSP has horrible memory optimization and leaks, and no actually optimized physics subsystem (instead relying on unity to do the grunt work), unity5 would allow KSP to continue its memory wasting behavior without running into 32bit VMEM limits. Furthermore, the bad (in terms of performance) physics of KSP could run faster and be distributed over multiple cores. So to put it bluntly: Unity5 will change nothing about KSP's badly optimized and memory-leaking behavior - BUT it would open up more ressources (VMEM, cores), so it would crash/bog down to a lesser extend, until KSP exceeds those extra ressources as well. Unity5 will not fix anything about what is problematic about the implementation of KSP - it simply will enable it to consume more ressources. Since KSP has an overally supportive and "progressive" community, and SQUAD has not yet shown any sign of intention to clean house/optimize and bugfix KSP, people are hoping for unity5 to be the saviour, by "fixing" bad programming with more abundant ressources. Wait, i'm sure there must be more that unity5 is bringing onto the table - that can't be all of it? Well yes, especially for handhelds, it will enable easier integration of adware, fancy shaders that only cost a bit more performance than is already the case, and it will enable more people to scriptkiddie even more stuff without knowing anything about even .NET coding (SLOW!!!). Oh, and for devs there will be better tools to compose music soundtracks - cause that's what everyone wanted. I could go on, but you get the picture: Besides of 64bit VMEM and physics updates, unity5 seems to address nothing of what its critics actually demand. It just ADDS even more, instead FIXING what is wrong with it. Reminds you of SQUAD?

Nah, same age: 2600 entertainment system ("Race the beam!", 32 goddamn BYTES of RAM), then C64 - but when i was young, they limited my computer time, but not lego time

My lego bricks cost less than a puter capable of running KSP, and they attached when they oughta, without part clipping. Then again, after a while they also detached when they weren't supposed to - this they had in common with KSP. EDIT: Also, splosions.

About 35secs 5 Years old machine, but running from an SSD. 50 Mods, but most of them usability and mechanics. Total partcount is probably lower than stock, because my mods do not add many parts, and i replaced various stock parts with procedurals. All textures (stock and mods) handoptimized. In short, overly long loadtimes are usually a texture problem. Half of the RAM problem however isn't - KSP 0.90 itself uses more RAM than before, and there are memory leaks (about half a gigabyte here, over a timespan of 20mins).

That might be considered a feature. After all, physics bugs and performance has been a constant problem all the time. It would have been much better to code a custom physics subsystem for the game - of course, this assumes one is capable of doing so. From what i know - NOW unreal is a better fit in almost every regard except of the instant feedback in the editor. However, things weren't like this back when dev of KSP started. And of course, back then Unity was the only cool kid on the block, with a low entry barrier. Competitors are catching up, while unity gets ever more retarded - i mean, read up on what's coming in unity 5 - complete garbage, except for 64bit support and a better physics subsystem. I suppose by the time Unity 6 is ready, Gamemaker will look like a sane dev environment, relatively speaking.

If i recall correctly, one is supposed to land with the landing gear facing downwards - it's one of those "this end towards space"-like things. Which means that while close to the ground, its a bad idea to rotate the craft too much. What wings have to do with any of this, i'm not sure. Your quote says your replying to me, but i think you must be replying to some imaginary person, because you are the first person in this thread to start talking about wings. Or is this a jab to an entirely unrelated and off-topic thread, where i proposed to put winglets on the ends of the first stage of a ROCKET, and you felt insulted by this? Please stick to the topic, will you?

Well, that is a bit taken out of context. The OP and the replies were about the aspect of *landing*, not about lowing one's orbit. He was talking about even in the landing phase still having too much speed, and someone else remarked the lack of air friction, to slow oneself down during landing. That is what the topic was, and what i was replying to, which i suppose is in the range of 200-400ms. Sure, two micro thrusters would add a bit of mass, but so would any other solution that requires parts. With say 2 micro-thrusters, we're talking less than 0.5t, for a spaceplane which overally probably weights at least 8.0t. It's significant but for a kerbin satellite affordable i think. The bigger downside i imagine to be that retro-thrusters still don't allow oneself to control vertical speed during landing - which would be a useful benefit of a VTOL-like design (even if just mounting the retros on IR-rotatrons).

That is one way, yes - if that's not enough for you, then "RealChute" let's you tweak more parachute parameters than you'll ever need. It even has presets for main, drogue and drag chutes, and at the cost of extra weight, you can design combo-chutes (i.e., drogue plus main chute).

I haven't attempted this yet, but will soon. What confuses me about the suggestions is, why full blown VTOL is proposed, when apparently the problem just is horizontal speed? Wouldn't small surface-mounted retro-thrusters do the trick, of compensating for the lack of air resistance?

I thought what he meant with "GUI panels" were GUI windows, instead of a HUD. And latitude/longitude is relevant to not just spaceplanes, but even planes have it. I regularily use it to estimate my current relative position to KSC, when flying in the atmosphere. Then there is inclination, which definatelly would be relevant to a spaceplane. So, i was talking about actual fundemental "flight data", yet data which perhaps not everyone needs - hence configurability (and it doesn't have to be a GUI - can simply be on/off switches in the configfile). As for "engineering calculations", like TWR - i wasn't even considering those. Thus far, i haven't been using KER. I'll take a look at it's HUD. - - - Updated - - - Okay, i tried KER - where is the HUD? All i can find are dialog windows. Configurable ones, sure - but not what i call HUD. That's not an alternative.

The only thing i like less than navhud, is the way banking is displayed - to me not too intuitive, and more importantly inaccurate. When the entire yellow heading indicator rotates, one can level the wings more accurately. Then again, only when pitching to the horizon. So in a way, with the way this mod does it, wing levelling is less accurate, but at least it's always the same accuracy, no matter the pitch. A solution could be to simply allow configurable scale of the indicator.

If the displayable information became more complete, and were configurable (something the VOID dev has been planning to do for a long time), it might not just be "flight data" for spaceplanes and FAR users, but in general an alternative to the VOID hud. The reason i'm saying this is because people have different needs - i for example would like to be able to see latitude and longitude, but to someone else this might be irrelevant. Displaying all information any user might want would make the HUD so cluttered that it became useless. So IMO, configurability of which information is shown, would be a requirement for any HUD that metaphorically speaking strives to take the crown.

Only show the overlay while placing a pod. This way, clutter won't be a problem - you can even go as far as marking N, S, W, E.

Okay, so you code the game in a way so that the entire world revolves around the navball, and thus orientation cannot be changed inflight. Fine. Can we at least in the editor know that our probe stacks are mounted upside down, instead of only finding out hours into a mission?

Exactly - by now i do think new stock aero will actually feel like something in between current vanilla and NEAR - i feel confident by now that it will have the mechanics right for that task. My only concern is the parameter constants perhaps being skewed, to keep stock parts semi-compatible (but then again, in a way they already backtracked twice on the compatibility promise: First because of the sheer scope of part rebalancing, since it means parts can be biased towards new aero, instead of the other way around. Second, because they just dropped the bomb that some stock craft - while still flyable - might actually lose some of their abilities - like reaching orbit). Other topic: Heatshields. I know many people want them, but i'm not really a fan of this. Extra parts add more complexity to crafts, and there are already too many stock parts in the game - the part catalog needs simplification, i.e. via procedurals. For the stock game, i'd prefer an "unrealistic" reentry-heat system that doesn't require extra parts, but instead simply is about angles and speeds. Okay, a global craft-wide property called "extra thermal shielding" might be an idea - basically trading weight for extra reentry safety. But extra parts.... not really a fan of that in stock. On the upside, this technically will probably just be a variable/module in the partfiles, so i could just go and remove the parts, then add the module to all stockparts with an MM configfile. EDIT: Anyways, things seem to be shaping up well overall. Now if only they would mention the word "optimisation" once.

On a trajectory out of the system.

I too support the idea. The player already has to: - have the skill to bring the sat into a very stable and accurate orbit - do all the maneuvres to give sats the right angles The above is what requires skill and is a challenge. The tiny correction burns over time instead are just boring repetitive micromanagement of the most pointless kind, resulting from: - Inaccuracies in the game - Lack of extremely low powered thrusters (even thrust 1 would already be way too much) Deficiencies of the game shouldn't be the player's burden, and like i said, station keeping is just monotonic boring work, that requires patience and masochism, not skill. Automate it, except for those who like to suffer.

Same here - it is much better in 0.90.... but still happens sometimes. Previously, it used to be that i considered the editor user-hostile without part-clipping, because 50% of the time, it failed to attach parts properly, that do not actually clip. Now it's more like 7%. I do use part clipping for actual clipping sometimes. Though, not to outrightly cheat (like placing stuff inside each other), but usually aesthetic reasons - building structure. Stock really lacks the lego equivalent of bricks - simple general purpose parts to form structure. Luckily, it seems like the upcoming "Mobile Frame System" mod is going to make this much easier, without oneself having to resort to clipping. Besides of clipping, i sometimes use editor extensions to enable surface attachment for parts that normally do not support it. Again, aesthetic reasons - some parts lack nodes at some points for no obvious reason, yet have surface attachment disabled. Sure, clipping and SA override can be abused - but at the same time the game is still in a state, where one has to override the rules in some cases, to make it behave reasonable. It's basically the user hackfixing the game, if used fairly.

Report with the updated DLL: Textures still apparently not unloaded. Replaced assets increase memusage instead of lowering it.

1. How does a single halfway popular game change the consensus of the population about "if space travel is good"? Wishful thinking, hmm? 2. How is a method/tool "good" or "bad" regardless of the context and circumstances? 3. How does something become "good for everyone", because *i* enjoy the topic? A bit egocentric, isn't it? You could instead simply ask how KSP changed one's own view and understanding of space travel. That would be reasonable. Unfortunatelly, it also has been asked countless of times before, and wouldn't allow for a pompous topic title.