0.23 should focus on performance

[TimMartland]

I have a massively powerful gaming PC, but KSP gets jittery at 200-300 parts and above that its pretty much unplayable. Some optimisation wouldn't hurt, but on the other hand it is a hard job for the devs. Plus, do any of Squad seriously consider any of these ideas, even the really good ones? I can't remember a user suggestion going into the game (at lease for a long time)

[DaRocketCat]

I will keep saying this until some dev reply.

All the things in your list can be solved if we remplace most parts for procedural parts that will snap between standard sizes.

Also we would have a lot of extra parts and sizes to use, our crafts will look more real and any upgrade on the physsics models would be easier to update.

And I will keep saying these two words in response: damage simulation.

[AngelLestat]

AngelLestat although I do agree with you that having stock procedural parts would be nice, there are mods that provide this and making it stock would not change much. However increasing base game performance (mostly physics engine) would mean a whole other level of awesomeness, as the ships having few parts are dull in terms of their looks and how they "disassemble" when there is a structural failure, not to mention it takes that LEGO feeling out of the game.

And I will keep saying these two words in response: damage simulation.

I have to accept that the "LEGO feeling" and the damage simulation are the only 2 moderate critics that this can have.

About the Lego feeling... Are you sure if that is the real factor that makes the game fun? The game is about design any kind of craft and fly it. Is not about puzzle rockets, attempts to simule a space program. And even if it is. With procedural parts you are only reducing the amount of parts that you stack. So is not something that it will change the gameplay dramatically. Plus more parts is equal to less limit to your imagination.

The damage, right now is not very accurate, in the case of 3 tanks stack, you really think that the wobble between the parts looks real?

Meanwhile in the real world are all made in one part and they do not bend or break with ease in the middle.

In the case of wings, or any other part, it has to be a max size snapping between standard scale dimensions, so you also need to stack parts.

And the game engine also allows other solutions, you can have premade damage parts in the case of the wings with certain cfg values.

That part would remplace the original in a crash.

You also had different assets for unity that can be download for free or paying a low cost that can solve those problem.

Parts can be cut or bend. If you have 1 part, the game can cut one and make 2 parts of it.

You can search damage assets in unity and you would see. There are many demos.

I am not against muti core, threadding or 64b structure or anything that can help in the performance. But that feature does not depend on SQUAD.

On the other hand procedural parts is something that SQUAD can manage well. They can ask for help to the community, something like "project procedural", with details and parameters made by squad meanwhile they may focus in the game content.

With only this, the game performance is increased by a lot.

Edited October 29, 2013 by AngelLestat

[boomerdog2000]

I will keep saying this until some dev reply.

All the things in your list can be solved if we remplace most parts for procedural parts that will snap between standard sizes.

Also we would have a lot of extra parts and sizes to use, our crafts will look more real and any upgrade on the physsics models would be easier to update.

Wouldn't only about two of those be fixed by procedural parts anyways? Some RAM usage and maybe some loading times. The rest generally have to do with terrain, or buildings and such.

[Nuke]

i dont think anyone is against x64 or multithreading. its just a thing squad and unity are not going to be able resolve overnight. in the future perhaps, but not now.

i dont think procedural stuff will help. one thing about them is you cant instance them, so every procedural part of a same type has to be handled individually, instead of all parts of one type being handled in one pass. this not only affects rendering performance but also collision detection and physics performance (which is where all the bottlenecks are). i cant help but see that is a way to shoehorn a feature request into a bugfix. ive seen this happen a lot on various open source projects (i even committed this atrocity myself a few times), and almost always it ends in misery. you end up with a half ass bugfix and a feature that doesnt work right.

[Tsuki]

Also on the note about procedural parts, what parts would you make procedural?

Lets say fuel tanks, struts, beams, wings, etc.. so yeah mostly structural stuff. But when you look at an average ship, they have all those tiny parts, like rcs, ladders, landing struts, docking ports, science stuff etc that can't be really "procedural" unless you have complete blocks in 1 part that has it all. (but that would utterly destroy the creativity in this game), or another option is parts welding which I suggested long time ago, and there is a mod for that, as it only simplifies the damage simulation, but not creativity. Also as it is now, the game allows decent performance for simple space ships that are able to go land and return to any planet/moon in game without lag. But when you get into space stations, or bases, and when you make or 3rd or 4th dock the game gets unplayable, so again not something that procedural parts will help alot with. Also since there are 3 great procedural MODs already why bothers the DEVs to make it into stock, since not much change there. I would very much prefer they would focus on actual performance boost, than porting mods into stock.

TLDR: procedural parts would not improve much as it would only help you reduce part count (depending what are you building) for 10-5%.

Edited October 29, 2013 by Tsuki

[SaturnV]

Optimaize too early is evil

[Superfluous J]

Of course it needs optimizing. It's in Alpha.

The problem is, you're putting the cart before the horse. You don't put the tires on the car while you're welding the chassis on. You don't hang the drapes while they're pouring the foundation. You don't pull your chute in the launch stage. You don't edit your novel in the first draft.

And you don't optimize code while you're adding features. It's a waste of time and it's counterproductive.

[Tsuki]

Wrong...

5thHorseman, your anecdotes makes sense only if you mean optimization before all the frills. Perfectly it would be optimize engine first before starting to add features, but sadly these days in development is features before everything else. And IMO KSP at the moment already has all the main features it needs (and what it does not have is, and can be covered with mods), but at this point what it really lacks is better performance. Its getting to a point where new features are becoming useless because of bad performance. We got docking, but we cant make space stations without major lags, there is talk about stock planetary resource system (you can use kethane mod at the moment) but you cannot make a decent planetary base without lags. In any direction KSP wants to expand (with features) it will hit the wall of max 300parts without lags. As it is for now, KSP only works well for building simple go to (and maybe return) ships. One exception is science and career mode(with parts cost eventually), as it actually forces you to minimize and gives additional meaning to "go-to ships". Also the more features you add the harder it becomes to replace/optimize the underlying engine.

[Tuareg]

Multicore support can only happen if unity developers do it, otherwise it would have been implemented a long time ago. The issue is mostly with the PhysX implementation that unity uses, it is simply very old and squad can't do much about it on their end.

However a major code overhaul is coming soon, as the optimization was supposed to be featured in 0.22 but got delayed since it still needs to work out some issues. It is supposed to be a significant performance boost.

could u explain it why? others can implement safe multithreading in unity. it doesnt need unity devs.

you now, its a shame that my PC can run skyrim on ultrahigh settings without any lag, my cooling doesnt even spin up under crysis 3 test and it cries for a break whenever I start KSP and docking a 50 parts craft to a 400 one on low orbit is just impossible

Edited October 29, 2013 by Tuareg

[Tsuki]

Tuareg speaking of skyrim:

http://www.youtube.com/watch?v=O4wFtwtL6dc

those 4000 cabbages lags less than 1000parts in KSP, and skyrim was not meant for rigid body spam, while for KSP is essential and can't handle 1/2 the amount.

Or this:

it has more than 1k and runs perfectly smooth(compared to ksp @ 400parts), despite most of them being in contact, and being pushed around with fusrodah Edited October 29, 2013 by Tsuki

[Superfluous J]

Wrong...

5thHorseman, your anecdotes makes sense only if you mean optimization before all the frills. Perfectly it would be optimize engine first before starting to add features, but sadly these days in development is features before everything else. And IMO KSP at the moment already has all the main features it needs (and what it does not have is, and can be covered with mods), but at this point what it really lacks is better performance. Its getting to a point where new features are becoming useless because of bad performance. We got docking, but we cant make space stations without major lags, there is talk about stock planetary resource system (you can use kethane mod at the moment) but you cannot make a decent planetary base without lags. In any direction KSP wants to expand (with features) it will hit the wall of max 300parts without lags. As it is for now, KSP only works well for building simple go to (and maybe return) ships. One exception is science and career mode(with parts cost eventually), as it actually forces you to minimize and gives additional meaning to "go-to ships". Also the more features you add the harder it becomes to replace/optimize the underlying engine.

I disagree with you (obviously, else I wouldn't have made those anecdotes you don't agree with). You cannot optimize until all features are in, or you'll find - again and again - that you optimized something that needs to be changed to account for that new feature. You'll end up throwing some or all of your optimized code away, or worse yet waste hours or days trying to optimize it on the fly or keep it even though it won't work as-is. In the end, you've at LEAST wasted the time you spent optimizing the code, and probably wasted more time trying to get all the stuff working together.

If KSP had all the basics, it wouldn't be in Alpha. As it's in Alpha, the devs don't think it has all the basics. Once it's not in Alpha they'll start working on optimization in earnest. Your opinion about how complete the game (and mine on the same subject) is completely immaterial.

Don't think I think the game is "good enough" and "they shouldn't do anything to fix it." They should. But they should do it at the correct time so this game can be released in 2014* instead of 2027**.

*I don't know when the game will be released, or when they hope to release it.

**I don't know how much of a setback doing things out of the correct order would cause. I suspect my guess is a gross overestimate, done as a cheap way to make a point.

[Nuke]

Wrong...

5thHorseman, your anecdotes makes sense only if you mean optimization before all the frills. Perfectly it would be optimize engine first before starting to add features, but sadly these days in development is features before everything else. And IMO KSP at the moment already has all the main features it needs (and what it does not have is, and can be covered with mods), but at this point what it really lacks is better performance. Its getting to a point where new features are becoming useless because of bad performance. We got docking, but we cant make space stations without major lags, there is talk about stock planetary resource system (you can use kethane mod at the moment) but you cannot make a decent planetary base without lags. In any direction KSP wants to expand (with features) it will hit the wall of max 300parts without lags. As it is for now, KSP only works well for building simple go to (and maybe return) ships. One exception is science and career mode(with parts cost eventually), as it actually forces you to minimize and gives additional meaning to "go-to ships". Also the more features you add the harder it becomes to replace/optimize the underlying engine.

its somewhere in the middle i think. things like threading are good to get in early because it vastly effects the code structure. you could end up having to rewrite huge sections of code over again because it doesnt like your division of labor.

x64 on the other hand is something that can and should be done in beta, before you start doing low level optimizations on your maths. when you implement this you all of the sudden have 2 architectures with different instruction extensions, each needing their own set of optimizations and bug fixes so that they behave the same.

the compressed texture formats that i talk about in every single 'make the game faster' thread is a do it now kinda thing. why: x64 is a huge thing to implement(unless you linux), multithreading is a huge thing to implement. texture compression is a relatively tiny thing to implement (my game engine has that and its written in friggin lua! took me an afternoon) and self contained. it also will improve memory consumption enough where people wont be demanding x64 as much. later on, when you have x64, then you can double the resolution of ALL THE TEXTURES, and it will still use less ram than the current textures (and then double it again because you can address ram in droves).

that doesnt really solve your physics bottleneck though. threading (or using the gpu) is how you fix that one. thats a big problem that is hard to solve. i expect that dev cycle to be no less than 4 months. it will be worth it when we get it though.

[Pulstar]

could u explain it why? others can implement safe multithreading in unity. it doesnt need unity devs.

The issue isn't just multi-threading, unity does that to a degree but not in the area that is the performance bottleneck for KSP. The problem is specifically with physics being ran in a single thread on the CPU, using a very old version of physx from an ancient era before it used Nvidia GPUs for physics acceleration (I am wondering if one of the 10 people that still own a Ageia Physx PPU card experiences better performance with it in KSP). Skyrim works the way it works because it uses a much newer physics engine, a fairly recent version of havok which makes uses of all the recent technological advancements in PC hardware. The old version of physx KSP uses does not, hence the performance difference.

Overall the only way to get around KSP's physics bottleneck problem would be to license a new physics engine and integrate it into the game (or write a new physics engine from scratch but that's too much for a small developer team such as squad). That is doable and one developer using Unity did do this for their game, I don't remember that game's title or the developer team's but they switched to Bullet physics, it was mentioned on the forums a few times. The issue is whether or not Squad has the resources to do that at this stage of development (or ever in the future), it may be that they rather wait for Unity to make the smart choice and upgrade the physics engine it uses, if Unity would do that it would save Squad money and probably time. I would like to see a better and newer physics engine in KSP just like probably everyone would like to see it, but I figure that if such a choice has not been made by Squad so far there must be significant technical and business issues standing in the way.

That's the gist of it in my understanding of the issue, after seeing "beating the dead horse" of the KSP performance topic for over the nearly year I spent on this forum.

Edited October 29, 2013 by Pulstar

[John FX]

I`d be happy for a single thread to work across all my cores. If Unity would make that change it would go a long way.

Myself I have seen huge improvements in performance between 0.21.1 and 0.22 but then my machine is very capable and has the legs to allow the improvements full reign. A lot of the game seems restricted by hard drive speed. I have a lower spec machine that has a faster hard drive and KSP runs better on that one as far as loading times and general playability/flow etc goes.

Best KSP i play is on the SSD RAID machine that gets 900MB/sec

[Tsuki]

Overall the only way to get around KSP's physics bottleneck problem would be to license a new physics engine and integrate it into the game (or write a new physics engine from scratch but that's too much for a small developer team such as squad). That is doable and one developer using Unity did do this for their game, I don't remember that game's title or the developer team's but they switched to Bullet physics, it was mentioned on the forums a few times. The issue is whether or not Squad has the resources to do that at this stage of development (or ever in the future), it may be that they rather wait for Unity to make the smart choice and upgrade the physics engine it uses, if Unity would do that it would save Squad money and probably time. I would like to see a better and newer physics engine in KSP just like probably everyone would like to see it, but I figure that if such a choice has not been made by Squad so far there must be significant technical and business issues standing in the way.

I mentioned it was Rawbots (a really small team) that switched to bullet in Unity. As for "waiting for unity to get better physics" it was said multiple times by unity devs, that they are conservative in this type of change as the main selling point of unity is its cross platforming(think mobiles) and backwards compatibility. And is most unlikely that there will be any big change in Unity any time soon. And KSP's needs are quite specific and a bit different than the kind of games Unity aims to support. So there is probably only 2 possible options... Squad does major a physics overhaul by themselves (yes a 4-6month cycle...) and get away from the hellish physX from unity, or does nothing but small optimizations (yes those are done in Beta). Sadly they will probably opt for the later, and KSP will never be epic as it could be..

Edited October 29, 2013 by Tsuki

[John FX]

I mentioned it was Rawbots (a really small team) that switched to bullet in Unity. As for "waiting for unity to get better physics" it was said multiple times by unity devs, that they are conservative in this type of change as the main selling point of unity is its cross platforming(think mobiles) and backwards compatibility. And is most unlikely that there will be any big change in Unity any time soon. And KSP's needs are quite specific and a bit different than the kind of games Unity aims to support. So there is probably only 2 possible options... Squad does major a physics overhaul by themselves (yes a 4-6month cycle...) and get away from the hellish physX from unity, or does nothing but small optimizations (yes those are done in Beta). Sadly they will probably opt for the later, and KSP will never be epic as it could be..

The only way for SQUAD to be able to devote that much time to changing the engine would be if the community relaxed to the point where threads anticipating 0.23 didn`t start before 0.22 was out...

That or they got a huge injection of cash and could afford parallel development on two platforms and switch over that way.

I`m not sure which is less likely.

[AngelLestat]

Wouldn't only about two of those be fixed by procedural parts anyways? Some RAM usage and maybe some loading times. The rest generally have to do with terrain, or buildings and such.

You know very well that the problem comes with hundreds of parts all with its physsics. Also the memory usage for each part texture.

How much you optimize the game it would depends if you compare against vanilla or with mods.

My estimations against vanilla it would be:

-25% less loading time and memory usage. (this also means scene transitions times, etc.)

-from 10% to 300% increase in FPS depending the amount of parts that your craft have. (of course you need cpu performance when your craft is big)

(and you get a lot of extra parts for the same price XD)

Using some mods parts:

-300% less loading time and memory usage.

-from 20% to 300% increase in FPS (this does not change much, becouse even if you have less memory avariable, to have extra part sizes like novapunch reduce the amount of parts that you need to launch big payloads)

(you do not lose so much time searching the right part that you need in the part menu)

So this mean that if you had a 600 parts craft (5 FPS) then becomes in 250 parts (15 FPS).

i dont think procedural stuff will help. one thing about them is you cant instance them, so every procedural part of a same type has to be handled individually, instead of all parts of one type being handled in one pass. this not only affects rendering performance but also collision detection and physics performance (which is where all the bottlenecks are). i cant help but see that is a way to shoehorn a feature request into a bugfix. ive seen this happen a lot on various open source projects (i even committed this atrocity myself a few times), and almost always it ends in misery. you end up with a half ass bugfix and a feature that doesnt work right.

I dont follow you.. "you cant instance them"?

With procedural you reduce the amount of files that the game needs to open and close like the cfg files.

The amount of textures you load to the memory.

IF you are not convince how much this can help, make the test. Is easy, strechy tanks (alone) vs all vanilla plus novapunch tanks (only tanks), open the game, make a craft and fly it. You will surprice of the advantages.

And strechy tanks mod is not a good example becouse it does not use standard sizes.

And with procedural tanks you can use different fuels, so you do not need extra tanks for each fuel type.

The bottlenecks is in the amount of parts that your craft has and the amount of extra parts that you add to the game.

Procedural fix the 2 problems.

Also on the note about procedural parts, what parts would you make procedural?

Lets say fuel tanks, struts, beams, wings, etc.. so yeah mostly structural stuff. But when you look at an average ship, they have all those tiny parts, like rcs, ladders, landing struts, docking ports, science stuff etc that can't be really "procedural" unless you have complete blocks in 1 part that has it all. (but that would utterly destroy the creativity in this game), or another option is parts welding which I suggested long time ago, and there is a mod for that, as it only simplifies the damage simulation, but not creativity. Also as it is now, the game allows decent performance for simple space ships that are able to go land and return to any planet/moon in game without lag. But when you get into space stations, or bases, and when you make or 3rd or 4th dock the game gets unplayable, so again not something that procedural parts will help alot with. Also since there are 3 great procedural MODs already why bothers the DEVs to make it into stock, since not much change there. I would very much prefer they would focus on actual performance boost, than porting mods into stock.

And you said it yourself, if SQUAD can not do much about multicore or 64 bits support, then what they need to do? nothing?

TLDR: procedural parts would not improve much as it would only help you reduce part count (depending what are you building) for 10-5%.

How parts you made procedural? Is more easy to mentions what parts you dont, like engines, pods or some science stuff.

You mention landing struts, docking ports, ladders, etc. All those can be procedural. Ladders for example is one of the most part request by the comunity (not me) to become procedural.

You can also add decouplers, sas, asas, panels, etc. Is amazing how much you can reduce the part menu.

Of course the parts needs to use the same 3d model. Procedural what it does is change its cfg parameters like strenght, joint nodes, scale depending on the size you choose. You can have different textures for the same part too.

And you don't optimize code while you're adding features. It's a waste of time and it's counterproductive.

I am agree, I work with codes more oriented to webpages, and the optimization always is the last that you need to do.

[boomerdog2000]

You know very well that the problem comes with hundreds of parts all with its physsics. Also the memory usage for each part texture.

No I don't. Many of the problems mentioned above relate to terrain, (ocean lag, lag on timewarp changes in orbit around a body with the new terrain system, low FPS when looking at the horizon, long scene transition times between space center buildings).

Procedural docking ports wouldn't really work because each one would be a different size and none of them would dock together. Landing struts don't really make sense either, since those of us that build planetary bases would lose our height standard. I could see procedural ladders rather than the individual bits we have no cut down on part count but we already have the retractable ones that function quite well, so that seems unnecessary.

[AngelLestat]

oh sorry, maybe you dint read the 10 times that I mention "SNAPING BETWEEN STANDARD SIZES"

[boomerdog2000]

oh sorry, maybe you dint read the 10 times that I mention "SNAPING BETWEEN STANDARD SIZES"

Which is the same as having standard size parts.

[Nuke]

You know very well that the problem comes with hundreds of parts all with its physsics. Also the memory usage for each part texture.

I dont follow you.. "you cant instance them"?

With procedural you reduce the amount of files that the game needs to open and close like the cfg files.

The amount of textures you load to the memory.

IF you are not convince how much this can help, make the test. Is easy, strechy tanks (alone) vs all vanilla plus novapunch tanks (only tanks), open the game, make a craft and fly it. You will surprice of the advantages.

And strechy tanks mod is not a good example becouse it does not use standard sizes.

And with procedural tanks you can use different fuels, so you do not need extra tanks for each fuel type.

The bottlenecks is in the amount of parts that your craft has and the amount of extra parts that you add to the game.

Procedural fix the 2 problems.

learn how things work in a game engine. instancing is where you load a model and texture data into the state machine, draw 50 of them in one pass just by feeding in transform data. its one of those ways you lower the command rate to the graphics apis to increase performance. with procedurals you cant do this. you load your generated model and texture, draw one, and then you need to reset the state machine for the next thing, so the commands/object is higher. maybe you can do something with a geometry shader to speed things up, but those are fairly new and probibly not supported on a wide array of video hardware at this time.

i get it, you want procedurals to be stock, its a cool feature. but its not a way to fix the problem. it might net you some performance gain using certain rocket builds (especially megaboosters). but its a bandaid at best and wont give you the wide sweeping performance increase you want.

[AngelLestat]

Which is the same as having standard size parts.

...

really??

learn how things work in a game engine. instancing is where you load a model and texture data into the state machine, draw 50 of them in one pass just by feeding in transform data. its one of those ways you lower the command rate to the graphics apis to increase performance.

OK, so for instancing you are meaning that. Perfect, but is your next paragraph the one that seems illogical.

with procedurals you cant do this. you load your generated model and texture, draw one, and then you need to reset the state machine for the next thing, so the commands/object is higher. maybe you can do something with a geometry shader to speed things up, but those are fairly new and probibly not supported on a wide array of video hardware at this time.

i get it, you want procedurals to be stock, its a cool feature. but its not a way to fix the problem. it might net you some performance gain using certain rocket builds (especially megaboosters). but its a bandaid at best and wont give you the wide sweeping performance increase you want.

I dont understand you, maybe we have different meanings of procedural parts or we are talking of different things.

English is not my first language and I guess is not yours either. If you know spanish, PM me and this will be a lot easier to understand.

Why is different? You are not generating the texture... the cfg parameters that you set dynamically is the same that you send with a normal part.

Even more, the engine has NO IDEA that is a procedural part.

For example, if you had a craft with 4 small tanks (pair stack), 1 middle tank and 2 big tanks stack. (3 cfg files, 3 models and 3 textures) 7 parts

Now lets said that you can make the same craft using procedural (1 part menu) with only: 2 small tanks, 1 middle and 1 big. (1 cfg file, 1 model, 1 texture) 4 parts.

Using that example, tell me how is different from the engine perspective.

[Tsuki]

Angel you are avoiding the main argument how procedural parts is only a band-aid that at best can only improve performance on specific ships, mainly when trying to stack up fuel tanks or wings. And for both of this 2 problems there are existing mods that help you with that (procedural wings, stretchy tanks, modular fuels, and KW rocketry for bigger parts) not to mention you can have smarter lifter designs. However no procedural parts will help you with reducing parts count for space stations or planetary bases, because on such structures you usually need many docking ports, lights, rcs solar panels, landing struts and other small parts that you cannot simply replace with one procedural part. There are mods that try to cover this by making multifunctional parts but this takes away the creativity. And if you are building a station or a base you usually want to visit it with other crafts, like SSTOs for refueling, or similar, and those crafts needs their own set of parts which just adds to the part count when being close enough. So no procedural parts won't solve the main issue, that KSP as it is for now is only good for making a ship, sending it somewhere, and come back (or having fun horribly killing kerbals....). As soon as you try to go into station building or planetary bases, you will hit the wall of bad physics performance.

Also, about RAM usage, i do not really mind, as RAM is cheap now-days, so really not of much importance (except that current x86 builds have a limit of only 4GB). But no (reasonable)computer upgrade will fix the physics performance....

EDIT: Angel just now i saw your signature, you've build a nice station, now tell me how many parts could procedural parts reduce.... Not to mention that your station is kindof minimalistic, but you still get yellow counter

Edited October 30, 2013 by Tsuki

[John FX]

Also on the note about procedural parts, what parts would you make procedural?

Lets say fuel tanks, struts, beams, wings, etc.. so yeah mostly structural stuff. But when you look at an average ship, they have all those tiny parts, like rcs, ladders, landing struts, docking ports, science stuff etc that can't be really "procedural" unless you have complete blocks in 1 part that has it all. (but that would utterly destroy the creativity in this game), or another option is parts welding which I suggested long time ago, and there is a mod for that, as it only simplifies the damage simulation, but not creativity. Also as it is now, the game allows decent performance for simple space ships that are able to go land and return to any planet/moon in game without lag. But when you get into space stations, or bases, and when you make or 3rd or 4th dock the game gets unplayable, so again not something that procedural parts will help alot with. Also since there are 3 great procedural MODs already why bothers the DEVs to make it into stock, since not much change there. I would very much prefer they would focus on actual performance boost, than porting mods into stock.

TLDR: procedural parts would not improve much as it would only help you reduce part count (depending what are you building) for 10-5%.

One reason to make these features of the standard game is because of how much of a reaction you get if you use a mod...

Lets look at the real world. I have made the same craft in stock and using procedural tanks and fairings only. The stock craft weighs about 200T more and is over 300 parts extra and requires many many struts. The craft with procedural fairings is 330 parts (so about 50% not 5%) and flies a whole lot better *because* it is more realistic. This contradicts your statement directly as procedural parts would help greatly with part count induced lag on stations. The procedural parts are all staged by the time the payload is in orbit pretty much. The payload is the same in both cases, which do you prefer?

Edited October 30, 2013 by John FX