Jump to content

rynak

Members
  • Content Count

    312
  • Joined

  • Last visited

Community Reputation

51 Excellent

About rynak

  • Rank
    Sr. Spacecraft Engineer
  1. 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 inferio
  2. 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 b
  3. 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
  4. 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 r
  5. 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 cont
  6. 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
  7. 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.
  8. 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).
  9. 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, re
  10. 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
  11. 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
  12. 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).
  13. 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?
  14. 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
×
×
  • Create New...