Ways to increase framerate

[msyblade]

There is just one thing I wish would happen - once they release 0.21 (and 0.21.x of course), Squad would announce todo list for 0.22 containing just two items - performance and 64bit support. They really need to focus on it and solve the problem. Pushing it out and blaming it on Unity/PhysX/whatever is just unprofessional.

It should be noted that Squad has never blamed anything on anyone. We are honestly a bunch of fans having a detailed discussion trying to find better tips and answers to help alleviate these issues. There is nothing unprofessional about having a fanbase that gets into heated discussions about (usually) nonsensical moot points. This thread however, contains A LOT of helpful tips, and new players would likely benefit by being exposed to it early on. (And it could serve as a caution that nearly any thread can spiral out of control quicker than a launching rocket missing an engine.

[ecat]

There maybe nothing Squad can do about the Unity engine but what about the game bugs that are under their control?

The first thing I'd like to see is a fix for the known editor bugs - symmetry issues, phantom parts appearing that cannot be selected, valid parts that for some reason can no longer be selected, maybe these are all related - and the obvious bug(s) in the save/load routines - landing legs drop off, struts and fuel lines become disconnected, fuel tanks and engines simply drop off. These are the ones I've seen, some I can reproduce, some I have reported and all can happen without a single mod installed.

With those out of the way we can be certain that our creations are consistent and the hours some people spend putting a ship into orbit or building a station or base will not be wiped out by some single, random, unidentifiable event.

If they want people to rage quit and never return they should ignore the above and continue adding towers or clouds or texture pixels.

Unity.

So, it is old? Out of date? I don't know. I do know it is currently been used in some high profile projects, Obsidian Eternity and Red Thread Games Dreamfall come to mind. Perhaps having a higher profile and some real money behind it will spur development?

The game does not exist!

That's right.

There is no KSP game.

There are two games.

One is a sandbox, build it high, build it low, no resource limits so do what you will without restraint game that we all play right now. This game, this framework cannot and should not be ignored, it is the main source of income for the devs (I guess, "a smash-hit success" according to wiki http://en.wikipedia.org/wiki/Kerbal_Space_Program ) and the game most of us here have paid for. Saying the devs did not envision 2000 part monster constructs is neither here nor there, if a good proportion of people are paying good money on impression that such creations are possible then the devs must respond or the money will soon go away.

The second game, limited resources, limited parts, limited part count, is the promised but as yet unavailable Career Mode. While I welcome the day it is available and playable, it is not the game I paid for so no further comment.

But its only Alpha.

And it has been 'only alpha' for 2 years now. Okay, that's fine, no matter how many units may have been sold I'm sure those early days were hard. The game has good reviews, the game is now on Steam, to realise its full potential the game must be seen to be making progress in the areas of stability, responsiveness and features and this progress has to be seen now. Now, while the game is in the spotlight. Now, before some pretender emerges from the darkness and steels the Kerbal Crown Jewels.

tl;dr

Ships that spontaneously deconstruct seriously piss people off. Fixing this should be a priority and no, it is not just a mod thing.

Selling a sandbox game, because that is all the devs have to sell, which cannot fulfil the expectations of the majority of customers is doomed. If the majority expect to be able to dock 4 200 part ships to a 300 part base without significant issues then the game has to allow that or sales will dry up.

You can blame Unity today, you can blame Unity tomorrow, but if you are still blaming Unity in six months time when 'Kopiers Space Project' becomes the best selling game of all time. Well, that would be sad.

[Tiron]

There maybe nothing Squad can do about the Unity engine but what about the game bugs that are under their control?

The first thing I'd like to see is a fix for the known editor bugs - symmetry issues, phantom parts appearing that cannot be selected, valid parts that for some reason can no longer be selected, maybe these are all related - and the obvious bug(s) in the save/load routines - landing legs drop off, struts and fuel lines become disconnected, fuel tanks and engines simply drop off. These are the ones I've seen, some I can reproduce, some I have reported and all can happen without a single mod installed.

With those out of the way we can be certain that our creations are consistent and the hours some people spend putting a ship into orbit or building a station or base will not be wiped out by some single, random, unidentifiable event.

If they want people to rage quit and never return they should ignore the above and continue adding towers or clouds or texture pixels.

Unity.

So, it is old? Out of date? I don't know. I do know it is currently been used in some high profile projects, Obsidian Eternity and Red Thread Games Dreamfall come to mind. Perhaps having a higher profile and some real money behind it will spur development?

The game does not exist!

That's right.

There is no KSP game.

There are two games.

One is a sandbox, build it high, build it low, no resource limits so do what you will without restraint game that we all play right now. This game, this framework cannot and should not be ignored, it is the main source of income for the devs (I guess, "a smash-hit success" according to wiki http://en.wikipedia.org/wiki/Kerbal_Space_Program ) and the game most of us here have paid for. Saying the devs did not envision 2000 part monster constructs is neither here nor there, if a good proportion of people are paying good money on impression that such creations are possible then the devs must respond or the money will soon go away.

The second game, limited resources, limited parts, limited part count, is the promised but as yet unavailable Career Mode. While I welcome the day it is available and playable, it is not the game I paid for so no further comment.

But its only Alpha.

And it has been 'only alpha' for 2 years now. Okay, that's fine, no matter how many units may have been sold I'm sure those early days were hard. The game has good reviews, the game is now on Steam, to realise its full potential the game must be seen to be making progress in the areas of stability, responsiveness and features and this progress has to be seen now. Now, while the game is in the spotlight. Now, before some pretender emerges from the darkness and steels the Kerbal Crown Jewels.

tl;dr

Ships that spontaneously deconstruct seriously piss people off. Fixing this should be a priority and no, it is not just a mod thing.

Selling a sandbox game, because that is all the devs have to sell, which cannot fulfil the expectations of the majority of customers is doomed. If the majority expect to be able to dock 4 200 part ships to a 300 part base without significant issues then the game has to allow that or sales will dry up.

You can blame Unity today, you can blame Unity tomorrow, but if you are still blaming Unity in six months time when 'Kopiers Space Project' becomes the best selling game of all time. Well, that would be sad.

Blaming or not Blaming Unity doesn't change the simple fact that it's the cause of many of the limitations on the game, and that in order to change it they would essentially have to drop Kerbal Space Program and start 'Kopiers' Space Project' themselves. Changing game engines is NOT viable.

Even changing Physics engines is probably pushing it.

What you don't seem to understand is that there are certain things that can't feasibly be changed at this point, because it would take so long and cost so much that it would risk bringing down the project entirely.

And sooner or later someone else WILL do it better. It's inevitable, no matter how good your original product is, it will eventually be exceeded.

As for development, are you asleep? We've had plenty of major additions recently, and are by the sound of it about to get more.

[sushinut]

This thread however, contains A LOT of helpful tips, and new players would likely benefit by being exposed to it early on.

For right now "sushinut" has the best idea. Make it abundantly clear via a forum sticky, both here and on Steam, that there is a "known" performance issue with overly populated design structures. This sticky could even make general recommendations on max part counts (300, 400, 500, whatever). But say something! Just letting new players stumble blindly into this already known pit of frustration is being, IMO, very inconsiderate.

As these folks have agreed, my main point is for Squad to nip this thing in the bud. NOW. They can't fix the problem... so reduce the chances of your customers (alpha testers who pay to play?) complaining by giving them a warning when they first start the game or via a ship-building tutorial. If I saw such a warning, it would have prevented me (and many others here who have complained), from investing 20-30 200 hours of gameplay going down a path that is completely unsatisfying. If I had known this, I would have used more efficient designs... OR would have simply opted to explore other places. Instead, I jumped from orbiting Kerbin to docking and refueling, to landing on Mun, to LET'S BUILD A MUN BASE!!

While I can (barely) tolerate this "you-live-and-you-learn" situation, casual gamers are less likely. And I bring up "casual gamers" because of the game's intro to Steam:

As someone said indeed, the fact that this is just listed as alpha is not enough imo.

If it were FREE alpha, that's one thing. I've never paid a company to help them move out of alpha. Never beta, either. BUT, I'm perfectly OK with paying $23 for something that is as enjoyable as was my first 20 hours of playing it. That was money well spent. I've paid three times as much for a much worse experience from games that were actually released as "production" (I'm sure we all have).

This being said, I discovered KSP via Steam and something I saw on YouTube the same day. For those of you who continue to harp on the idea that "this is alpha... it's going to be buggy..." We get it. But we must also assume that once this hit Steam, the user base has expanded significantly. SOME people simply won't get the alpha idea... but, as I said above, I've never paid to help test a company's software. Since this game went to Steam, there are likely hundreds, if not thousands, of just casual gamers who dropped $23 just to putter around in a space sim. Those people will not know about this inherent problem of the game until they've discovered it themselves. Many will just put the game down there (and then spread their disdain via word of mouth).... most will attempt to check a FAQ, a wiki, a tutorial, or this forum. The people who were drawn to this game prior to Steam will continue to tolerate the idea of alpha/beta play. Many casual gamers will not.

some of the requests we're making of Squad are a bit like asking them to build a house and handing them a mechanic's tool set.

I hope with these many threads, people are now past the idea that it's out of Squad's control to fix it. It is not beyond their control to address it through better customer education. When I got my blueprints to build my home, it was clear how many 2x4s, shingles, and bricks would be necessary. I also had a presumption that if I could afford it and it would pass code, I could add anything I wanted to the house, because that's how building works. I don't want to add a third story to the house and then be told AFTER, that "oh... you won't like the third floor. It'll be too hot all the time." I expect my architect to tell me that before I build. Squad (and this forum, FAQs, wikis, tutorials, etc.) is that architect capable of warning us before we've invested in that unlivable third floor addition.

Edited July 4, 2013 by sushinut

[asmi]

<skipped>

You don't need to tell me that - I'm in this industry for well over decade. The thing is - they picked Unity themselves, nobody forced it upon them. When I make some decisions in software I develop that later turn out to prevent implementing some features that my customer wants, I acknowledge the fact that it's my screw up and do whatever it takes to fix the problem for free (my customers don't have to pay for my screw ups, unless I'm on per-hour contract). That is what professionals shall do and are doing. Complaining to the customer that due to my bad decisions they are not getting some feature they want is UNprofessional and unresponsible, and by NOT fixing the problem Squad acts as such.

I wouldn't be too far off from reality if I go on to say that these two issues top the list of issues that vast majority of community want resolved. It's their fault no matter how you look at it, and therefore their obligation to do whatever it takes to resolve it. That is professional and responsible thing to do if Squad wants to retain a fairly good reputation they have (had?).

Edited July 3, 2013 by asmi

[Tiron]

You don't need to tell me that - I'm in this industry for well over decade. The thing is - they picked Unity themselves, nobody forced it upon them. When I make some decisions in software I develop that later turn out to prevent implementing some features that my customer wants, I acknowledge the fact that it's my screw up and do whatever it takes to fix the problem for free (my customers don't have to pay for my screw ups, unless I'm on per-hour contract). That is what professionals shall do and are doing. Complaining to the customer that due to my bad decisions they are not getting some feature they want is UNprofessional and unresponsible, and by NOT fixing the problem Squad acts as such.

I wouldn't be too far off from reality if I go on to say that these two issues top the list of issues that vast majority of community want resolved. It's their fault no matter how you look at it, and therefore their obligation to do whatever it takes to resolve it. That is professional and responsible thing to do if Squad wants to retain a fairly good reputation they have (had?).

Maybe in the software development industry at large, but when it comes to game engines...well. There's a shining example of what happens when you realize your engine is outdated, so you switch engines. It's called Duke Nukem Forever. Development was first announced in 1997. There were erratic releases of promotional materials, and various release dates were given up until 2001 when they finally declared 'when it's done'. Nothing further was heard until 2007, when a new teaser trailer emerged. In 2009 3D realms, the creator of the character, basically went bankrupt and ceased development, purportedly with the game 'nearly finished'. They were sued by their publisher for failure to deliver, details of what happened are obscure, but 2K announced that Gearbox was finishing it sometime later, and it was released in 2011.

They originally licensed the Quake II engine to make the game in (for a reportedly exorbitant fee), but 14 months later decided to switch the brand-new Unreal engine. A few years later they switched to Unreal 2. The game was eventually released using a heavily modified Unreal 2.5(Apparently almost totally rewritten from scratch), and having gone through at least two physics engines as well.

Edited July 4, 2013 by Tiron

[Coneshot]

I for one am very pleased with the entertainment/dollar ratio I am getting with this game... yes I have had issues with bugs (R.I P: my first ungodly ginormous space station lost due to hitting "End Flight") Have had landers randomly flip or just fall apart in place after a rare perfect landing... If from what I gather is an unfixable problem with the Unity Engine, then I look forward to perhaps "Kerbal Space Program II: The rise of Jebediah!" (or something) with a new and improved engine. By then we might all have better computers as well.. For now, I'll enjoy this version for what it is, a work in progress.

[asmi]

Maybe in the software development industry at large, but when it comes to game engines...well. There's a shining example of what happens when you realize your engine is outdated, so you switch engines. It's called Duke Nukem Forever. Development was first announced in 1997. There were erratic releases of promotional materials, and various release dates were given up until 2001 when they finally declared 'when it's done'. Nothing further was heard until 2007, when a new teaser trailer emerged. In 2009 3D realms, the creator of the character, basically went bankrupt and ceased development, purportedly with the game 'nearly finished'. They were sued by their publisher for failure to deliver, details of what happened are obscure, but 2K announced that Gearbox was finishing it sometime later, and it was released in 2011.

They originally licensed the Quake II engine to make the game in (for a reportedly exorbitant fee), but 14 months later decided to switch the brand-new Unreal engine. A few years later they switched to Unreal 2. The game was eventually released using a heavily modified Unreal 2.5(Apparently almost totally rewritten from scratch), and having gone through at least two physics engines as well.

And how is what you said contradicts what I'm saying? They paid for their screw ups (and apparently failed to learn on their own mistakes by repeating them).

[Mattasmack]

There maybe nothing Squad can do about the Unity engine but what about the game bugs that are under their control?

The first thing I'd like to see is a fix for the known editor bugs - symmetry issues, phantom parts appearing that cannot be selected, valid parts that for some reason can no longer be selected, maybe these are all related - and the obvious bug(s) in the save/load routines - landing legs drop off, struts and fuel lines become disconnected, fuel tanks and engines simply drop off. These are the ones I've seen, some I can reproduce, some I have reported and all can happen without a single mod installed.

With those out of the way we can be certain that our creations are consistent and the hours some people spend putting a ship into orbit or building a station or base will not be wiped out by some single, random, unidentifiable event.

If they want people to rage quit and never return they should ignore the above and continue adding towers or clouds or texture pixels.

...

tl;dr

Ships that spontaneously deconstruct seriously piss people off. Fixing this should be a priority and no, it is not just a mod thing.

...

ecat, that's about the same thing I start thinking when I read these threads on physics engine performance, or improving framerate, or what should be added to the game next, etc. Yes, better performance would be better. Yes, the things that Squad will add in the next version (or that they previously planned to add next, such as resources) would be good additions. But the core of the game, in both game modes, is constructing and then simulating craft. It needs to be solid. Problems with this core can't be overcome by adding other features.

The fact that bugs (from misplaced parts in the VAB to random explosions on load to numerical instability under physics warp) seem to be allowed to persist is what is worries me the most regarding the future of the game. The number of bugs like this usually isn't static. Either they're being tracked down and fixed, or they are multiplying as more things are put on top of the core of the game.

edit: That said, I have a background in numerical simulation and what stands out to me the most are the physics bugs. I don't know PhysX, but I would hope that it's not a complete black box and that it is possible for Squad to do things differently to fix some of the simulation problems. In CFD (computational fluid dynamics), commercial codes often try to be black boxes that 'just work' for everyone and every problem. The result is often completely unrealistic results without the user realizing it or simulations that just won't run for unknown reasons. To really have confidence in a code you need to know exactly what it's doing numerically, which usually means using one that's open source or writing it yourself. I see some parallels to PhysX in KSP. I wonder if anyone at Squad has much experience with numerics.

Edited July 4, 2013 by Mattasmack

[Tiron]

ecat, that's about the same thing I start thinking when I read these threads on physics engine performance, or improving framerate, or what should be added to the game next, etc. Yes, better performance would be better. Yes, the things that Squad will add in the next version (or that they previously planned to add next, such as resources) would be good additions. But the core of the game, in both game modes, is constructing and then simulating craft. It needs to be solid. Problems with this core can't be overcome by adding other features.

The fact that bugs (from misplaced parts in the VAB to random explosions on load to numerical instability under physics warp) seem to be allowed to persist is what is worries me the most regarding the future of the game. The number of bugs like this usually isn't static. Either they're being tracked down and fixed, or they are multiplying as more things are put on top of the core of the game.

edit: That said, I have a background in numerical simulation and what stands out to me the most are the physics bugs. I don't know PhysX, but I would hope that it's not a complete black box and that it is possible for Squad to do things differently to fix some of the simulation problems. In CFD (computational fluid dynamics), commercial codes often try to be black boxes that 'just work' for everyone and every problem. The result is often completely unrealistic results without the user realizing it or simulations that just won't run for unknown reasons. To really have confidence in a code you need to know exactly what it's doing numerically, which usually means using one that's open source or writing it yourself. I see some parallels to PhysX in KSP. I wonder if anyone at Squad has much experience with numerics.

There's some wiggle room, but the version of PhysX built into Unity is very old and very limited. It is theoretically possible to use something different, but right now there's no good, relatively easy way to do so. Someone was allegedly working on porting the Bullet engine as a Unity plugin, but it's stalled or something, because he hasn't posted anything on the subject since December.

They've already put in a few things to work around some of those limitations (The physics instability used to make ships wobble and even tear them apart), but they're pretty limited to what they can do. The main problem is simply how massive the numbers it's being forced to work with are, even with the size compression. It wasn't built to handle numbers anywhere near that large, and rounding errors creep in as a result, which is where the instability comes from. One of the main places, anyway.

At some point it's going to need to be fixed if the game's going to continue to grow, but I gather it's been pushed aside, either as an optimization thing to do later or simply being ignored because they don't think there's really anything they can do about it.

Edited July 4, 2013 by Tiron

[zzz]

Blaming or not Blaming Unity doesn't change the simple fact that it's the cause of many of the limitations on the game

It also cause existence of the game. There no too much better suited for this, non expensive, engines(can you point some?), so if Unity non exist - not sure ksp will be possible, and if Squad, small and not not very experienced(I'm sorry if it sounds insulting), in the begining decide to make own engine - next ten years it will be just pretty pictures sometimes and then abandoned project because lack of money, as it was with many other.

Edited July 4, 2013 by zzz

[ecat]

I'm not trying to criticise anyone here, but I think 10 years is on the high side.

Consider the likes of three/four(?) man Frictional Games who were able to produce a 3D games engine supporting Newtonian Physics running on Windows, Linux and Mac in two years, their first 3 games (well, we can call it 2 1/2 games if you want) in the following 2 years, followed by a 2 year break during which time they rewrote the engine and created Amnesia: The Dark Descent.

http://en.wikipedia.org/wiki/HPL_Engine

I'm sure there are many differences and twiddly details to consider but if we must contemplate engine changes and rewrites shall we say 2 1/2 engines and 3 1/2 games in 7 years is the low side of our estimate?

[Baleur]

I'm so frustrated right now I can barely see straight. I just spent the past 3 days designing, launching, landing, and connecting 3 separate modules meant to establish a base on the Mun, using Extraplanetary Launchpads and Kethane. By the time I got the 3rd module in range of the 2 that were already on the Mun waiting, my framerate dropped so hard, I could barely navigate the terrain with the rover. After finally getting it to its destination, I connected all 3 modules together, and VOILA! I finally have a fully functioning fully self-sustaining Shipyard on the Mun. This is a huge moment of triumph for me.

But now, EVERY single time I try to load this base up from the tracking center, the game lags so hard and the framerates are so low, that it can't properly render the base with the terrain, and after waiting for 20 seconds for the game to finish loading everything, the entire base just randomly explodes and flies everywhere. I've tried everything, cranking every single setting down and up, nothing helps. My base is just gone now, because that quicksave can't be loaded. The same sharp drop in framerate occurs with my Space Station as well, but for now, it has yet to start randomly exploding.

This is so freaking irritating because I have a very solid computer that should be entirely capable of running this game on max settings with 60+ framerates. I can do this no problem with any other modern-day game that is 100 times more taxing than this one. When are the devs going to update the way the software accesses the user's hardware, and what can be done to ease these problems until then? I absolutely love this game, and I'm furious that it can't be played the way I want to play it.

I did the same thing.

Plus a space station that i had to scrap because the game couldnt handle it.

Plus another huge project, thread with pics here --> (OH turns out the forum deleted my entire thread)

It really kills the game at the late stages, when you want to "accomplish" something great, something permanent.

If they can't solve this issue with larger builds, it'll just always remain a "build a little rocket, fly somewhere, done" game.

I mean i love the game to death, but it really kills my spirit everytime i notice i can't do what i wanted to do. Being size-restricted is the worst.

[StainX]

Squad have plenty of problems to solve, bugs to fix and features to add.

So KSP is still in development, and i guess the devs exactly knows how to improve framerate in future updates!

So trust those awesome people... they are always working on things

[nats]

Well the big question has got to be when is Unity going to get multi-threaded surely? Is that likely to happen at all?

[Ming]

... At some point it's going to need to be fixed if the game's going to continue to grow, but I gather it's been pushed aside, either as an optimization thing to do later or simply being ignored because they don't think there's really anything they can do about it.

Squad's silence (positive feedback) on this issue unfortunately makes it more likely that it's the latter portion of Tiron's assertion (they don't think there's really anything they can do about it) that is most accurate.

[_Zee]

Then overclocking would make perfect sense. If you up the frequency you will get noticeable increased peformance with games that even use just one core.

And you can just compare cpus like that. Even though newer high end cpus usually have more cores they are also often faster per core.

As I already stated, overclocking is not an option with my CPU, and its not a hard concept to grasp that I'm not the only one with this limitation. The point is that no modern-day game should REQUIRE you to overclock your modern-day CPU just to try and squeeze more performance out of a single core, and if the engine supported multi-core/multi-threading, increasing clock speed (via OCing or Upgrading, whatever the means) wouldn't even need to be a point of discussion in the first place.

I'm sorry if I'm harping on this same point across multiple threads, but I'm just getting really fed up with all the whining about how horribly this broken game is because it struggles to animate ships that are needlessly and big and overly complex for any useful purpose: ships made simply for the sake of appearances. Yes gentleman, if you senselessly overbuild your ships, both the performance of the game and the ship are going to suffer for it.

First of all, I don't think anyone in this thread has used the word "broken" in reference to this game. I know I didn't. Second, you're making a pretty large assumption that my ships or bases are "needlessly big and complex for the sake of appearances". All of my craft and modules are purpose-built, in the most efficient way I can think to do it. Again, not unrealistic to assume I'm not the only one that builds in this manner and still experiences unreasonable problems. Like I said in my post, my base consisted of THREE modules. It was at the most basic stage it could be at while still performing its function. If the Kraken had attacked while I had it at 10 modules, I might just be irritated. But the fact that said Kraken sees fit to destroy my base at its most rudimentary level before it can even function, makes me furious.

tl;dr

Ships that spontaneously deconstruct seriously piss people off. Fixing this should be a priority and no, it is not just a mod thing.

This.

If <this> were <a> FREE alpha, that's one thing. I've never paid a company to help them move out of alpha.

::snip::

I hope with these many threads, people are now past the idea that it's out of Squad's control to fix it.

This.

Edited July 4, 2013 by _Zee

[AndreyATGB]

My 2600k performs a lot better in KSP at 4.5 compared to 3.7GHz. Must be at least 10 FPS for large ships, they're not even fly able at stock speeds. Put your delta time slider to minimum, it'll make the game move slower, but smoother.

[LexDavis]

if you're in orbit if you look at the stars rather than kerbin your framerate will be a bit better

[Kodiak42]

Unfortunately, there is not much squad can do, they are working with a physics program they do not own, so they can't really optimize it for KSP. They can however, optimize KSP for the physics engine, however, that is a task many times more difficult with a much smaller impact on your frame rate. And just so you know, yes, I too experience a massive performance drop when two craft come within physics range of each other, making docking very, very time consuming. And please, you've told us that you have three modules, but we don't know how complex those are, give us the damn part count if you want us to stop assuming that you have a 2000 part moon-base. If you aren't using some high end gaming computer, you're out of luck unless your knowledge of how these stupid boxes of rocks work rivals that of Bill Gates. At least you can upgrade, I'm playing KSP on a laptop with reviews that all say "Not for gaming", and upgrading my hardware isn't even an option, so I have to patiently set my delta time to the 0.03 while I still completely ignore everyone else's idea of stupidly high part count. This isn't just a bit of bad code, or Squad being unable to fulfill their promises, or even the limitations of Unity, KSP is rocket science after all.

[Tobyz28]

----------

Edited July 31, 2013 by Tobyz28
Violation of Rule 2.3b

[Chail]

I have a serious suggestion for a work-around to these problems that could effectively increase craft sizes many times over:

Allow a craft to be permanently locked into a much lower number of static objects.

So a 1000 part moon-base would be reduced to maybe 20 composite parts.

I would do this generally in the following way:

n = numberOfParts/50.

Find n weakest connections.

Separate at weakest connections to give separate part clusters.

Create single custom parts from each cluster.

Connect custom parts back together.

Ban use of engines.

This approach would drastically reduce physics whilst still allowing objects to have some fragility.

You would have to think about how clustered docking ports etc would still work but that would be worth it.

Any thoughts?

[TheNorthStar]

I think that's a super cool idea, and I hope it gets implemented!

My idea, for a more short term solution, if it's not technically impossible with the engine:

What about some flags to skip some of the physics calculations on various parts (gravity, drag, collision, etc), or maybe just a flag to pass things up to the parent object it is connected to?? That way you could still have all the little frilly parts you want, for looks, without destroying your ability to play?

Maybe this would only be used by non-stock parts, but it seems like a useful thing to have available, and doesn't sound incredibly hard to implement.

[roosterr]

A better CPU will definitely help. But if you just want better performance you have to find ways to create crafts with fewer parts. Extremely complex and interesting stations and bases can be created with under 200 parts. You just have make efficient use of parts.

This is my approach also. I have an i7 3.4 GHz CPU with 3.9 boost, and 1600 MHz FSB. Even so, at about 350 parts or more, I get low frame rates.

The good news is that since the SAS improvements, I use less struts now. Less wobbling at launch = less struts needed. Struts were a huge percentage of my part count in the past. Now they are a fraction of what they used to be.

Edited August 16, 2013 by roosterr

[Deadweasel]

I have a serious suggestion for a work-around to these problems that could effectively increase craft sizes many times over:

Allow a craft to be permanently locked into a much lower number of static objects.

So a 1000 part moon-base would be reduced to maybe 20 composite parts.

I would do this generally in the following way:

n = numberOfParts/50.

Find n weakest connections.

Separate at weakest connections to give separate part clusters.

Create single custom parts from each cluster.

Connect custom parts back together.

Ban use of engines.

This approach would drastically reduce physics whilst still allowing objects to have some fragility.

You would have to think about how clustered docking ports etc would still work but that would be worth it.

Any thoughts?

This could perhaps work, but then again, there's the little matter of the way KSP keeps track of the ships that are built. AFAIK, the only way to "merge" a multi-part vessel or station would be to have a physical single model of the whole thing, which KSP currently can't create on the fly (and probably won't ever really be capable of without adding a LOT of additional load time between scenes).

I had the same idea as well, but currently the closest it's possible to come (from what I've found so far) is a part welder mod that takes some various vanilla components and turns them into their own singular parts. The only problem with that mod's approach is that it relies on being coded for specific combinations of parts (so you can turn a RCS and fuel tank assembly into a single part, but you couldn't turn a wing and a tank into a single part).

Otherwise, I think it's just going to be a matter of waiting until Unity FINALLY releases a proper 64 bit version, for Squad to adopt it, and eventually, for them to optimize the game's code. Only problem with optimization is that it's often pretty one-way; you can't turn around and do much more development to the game's core without then having to turn around and do all the optimization work all over again at each turn.