Part Count Optimization Issues

[14thTry]

First off sorry if this has been posted a million times and/or is impossible/stupid . I did quickly look through the things not to post section...

LOVE YOUR GAME.

Business time:

my play style: Normal, No MODS, gather some tips/strats from friends, and Das then mission FUN TIMES! That's how I will play not really looking for anythiing more to this complex beauty, I won't download a mods there is plenty.

Something that bothers me from a system/design prespective is the minimum part count becoming unlimited at highest upgrade teir. It is used as a gating mechanism in early stages of the game, but would seem is also a way to limit builds becoming too much for most computers to handle. Yet when the VAB is upgraded to max the part limit goes away, and next thing I know my computer is showing me it is in desperate need of an upgrade.

A 300+ part ship for me is no fun on max settings, and a mun base (450+) ... yikes. And while I plan to upgrade to enjoy this game I love a little more I am wondering why you decided to uncap the part count at all?

All it really does is allow me to essentially break the game/my immersion. I get that this is what players want (freedom), so I get that's why it was made possible, but having played lots of editors in many games, I have found the part count is actually one of the most interesting ways to make an editor a game. It becomes a balancing act which thing is more important, is this the absolute best thing we can do here. In fact I truly believe you can't make anything right until you define your limitations (sorry ranting). I had more fun building ships with the 255 limit than once I had to remove it to get done what I wanted. So yes I get it, but its bad

So that's my issue. It is "necessary" sure. but how could it be done for a better running experinece for more people/me

THE IDEA:

Welding.

Construction teir unlock (300 - 550 sci req)

Two parts can be made into one part for more money and weight, these parts now carry both functionalities, and are considered by the part count (physics calculations?) to be one part. destruction applies to both welded parts, and the new crash tolerance could be set to the lower of the two parts (possible balance) or something like that.

What would actually need to happen processor wise might be less optimal than I assume, but if there less parts each physics calculation then that calculation could be made much simpler/faster (?). I know that Unity does slow down a lot just with enough draw calls, and I wouldn't think that could be reduced in this case easily, since the mesh count would have to remain the same. but if the major lag spikes are all physics then I think this could work really well.

example

one command module, one fuel tank, one rocket engine.

weld A to B, new A to C, and you have a one part rocket that weighs and costs more than a 3 part version of the same design. If the welded ship collides with something faster than its crash tolerance, bye bye ship and its pilot. in this simple example you can already see why welding as I speced would balance itself nicely. any OP uses could be restricted, similar to fuel transfer restrictions already in the game.

Am I off base here? would this actually save processing power?

Way less interesting if this didn't make more optimal ship building possible, but if it did work...

If so, you could set an actual part count for all VAB, SPH upgrade levels, and it could be even less than 255. Welding should also be unlocked in the science tree (rant on this coming, but I am sure this one has been said a million times). At a high enough science req it would essentially be the unlimited parts teir

[CaptainTurbomuffin]

Currently, not only the game's part loading system, but the whole loading system i quite unefficient. I am sure that something will be done about this. Currently, Squad is working on Unity5 implementation, wich will make things better.

Two parts can be made into one part for more money and weight, these parts now carry both functionalities, and are considered by the part count (physics calculations?) to be one part. destruction applies to both welded parts, and the new crash tolerance could be set to the lower of the two parts (possible balance) or something like that.

I think that's the right way. Here's my idea:

No part welding.

Every rocket, every vehicle should be simulateed as one. There may be areas in this one part, where heat is spread slower/quicker, there are points in it, where heat is produced (engines), there are weaker points in it, where it's likely to break, there are more flexible points in it... This is also better when it comes to damage. If you hit it somewhere, instead of blowing up a part from it, the rocket could be separated, in a much more appropriate way. Rockets wouldn't be simulated as piles of parts, but like unique vehicles, like in most simulators. Of course, this would requie to convert each desgin in the VAB/SPH into a vehicle format, before launching. Also, it would save phys-warping!!

Let me bring up the example of the Portal2 editor. There, after you desgined your puzzle in the editor, you had to convert it into an actual map. Converting took ages, but both the editor and the game was efficient, and you could run them with high settings, while it wasn't eating up your computer.

[steve_v]

Or, ya know, a real multi threaded GPU accelerated (OpenCL/CUDA) physics engine. Which is what the game has needed since day 1. Doing complex rigid-body physics in a 32bit, single threaded, CPU only engine is ridiculous - the processing requirements increase pretty much exponentially with body(part) count. Get a faster CPU? Nope, they don't exist in consumer grade hardware.

Welding would be nice, but it removes one of the key features of the game - the part interactions. Heat transfer, impact destruction, joint failure etc. would all have to go.

I get that it's a Unity issue, but it's crippling the game. Something. Must. Be. Done.

There's no point in an "unlimited part count" unlockable if the physics engine can't handle it. As it is, the game becomes unplayable at part counts that are effectively encouraged by the progression system.

- - - Updated - - -

And don't get me started on the excessive memory consumption and brain-dead "put everything in RAM at startup" asset loader...

[14thTry]

Or, ya know, a real multi threaded GPU accelerated (OpenCL/CUDA) physics engine. Which is what the game has needed since day 1. Doing complex rigid-body physics in a 32bit, single threaded, CPU only engine is ridiculous - the processing requirements increase pretty much exponentially with body(part) count. Get a faster CPU? Nope, they don't exist in consumer grade hardware.

Yes, but this is incredibly hard to do at this point which means it either isn't coming or is too far off for me to care.

Welding would be nice, but it removes one of the key features of the game - the part interactions. Heat transfer, impact destruction, joint failure etc. would all have to go.

I kinda of detailed this in my OP, but it was long winded, It wouldn't affect these unless you welded, so getting rid of them wasn't my intent, Heat transfer (could be balanced by making heat transfer be instant across welded parts), impact destruction would destroy the entire welded thing, Joint failure on the other hand would be a big bonus, and it would be impossible to break apart with gforces unless the whole thing disintegrates. These things actually seem to me to make interesting design choices for many builds, Do weld the command module to the rocket or not?

Also the physics engine is fine handling the physics for most reasonable thing but as with all physics engines they have an upper limit. It is why there should always be systems that limit your options.

[14thTry]

I think that's the right way. Here's my idea:

No part welding.

Every rocket, every vehicle should be simulateed as one. There may be areas in this one part, where heat is spread slower/quicker, there are points in it, where heat is produced (engines), there are weaker points in it, where it's likely to break, there are more flexible points in it... This is also better when it comes to damage. If you hit it somewhere, instead of blowing up a part from it, the rocket could be separated, in a much more appropriate way. Rockets wouldn't be simulated as piles of parts, but like unique vehicles, like in most simulators. Of course, this would requie to convert each desgin in the VAB/SPH into a vehicle format, before launching. Also, it would save phys-warping!!

Let me bring up the example of the Portal2 editor. There, after you desgined your puzzle in the editor, you had to convert it into an actual map. Converting took ages, but both the editor and the game was efficient, and you could run them with high settings, while it wasn't eating up your computer.

I don't know if this is actually easier harder or technically impossible for Squad to pul loff but would be great. They definitely would need to keep some limiters so you can't build it out of the hanger. But I would find it a little less desirable for testing purposes. I often launch a rocket 6 or 7 times before I get the Pad and orbit Dv balanced enough, that means in your system my waiting between launches and tweaks would become terrible fast. Plus why not add more build options and potential designs. Kerbal is a puzzle game, build a ship that can complete a mission (or more) and then see if it works.