KSP should still be able to run at 60fps even with mods. Discuss.

[kerbiloid]

Maybe not a real welding is required (i.e. joining two parts in one) but a flag "IsWelded" on every part joint?
I.e. on attaching a part in VAB ask: "weld it: yes/no?" or have a special key to flag the joint as "welded".
Then there will be still two parts with their functionalities staying separated, but this joint is not processed as elastic one, but as absolutely rigid, with strength proportional to the welded part strengthes.
And if one part breaks, the welded ones break as well.
Like with PhysicalSignifical.

Edited July 21, 2019 by kerbiloid

[Lisias]

4 hours ago, kerbiloid said:

Maybe not a real welding is required (i.e. joining two parts in one) but a flag "IsWelded" on every part joint?
I.e. on attaching a part in VAB ask: "weld it: yes/no?" or have a special key to flag the joint as "welded".
Then there will be still two parts with their functionalities staying separated, but this joint is not processed as elastic one, but as absolutely rigid, with strength proportional to the welded part strengthes.
And if one part breaks, the welded ones break as well.
Like with PhysicalSignifical.

I'm not an Unity expert, but it's my understading that Joints are the way to keep parts working together. You can set that Joint to be impossibly strong and make things act as one, but the physics engine still handle them as two parts.

You really need something as UbioWelding to create a derivative part with the characteristics of that two at the same time. As far as I know, it's the only way.

That said, it would be very interesting if the game could "compile" the parts marked as "welded" on launch. You would not need to create custom parts and rebuilt the craft with them.

And you could share the craft without sharing the welded parts.

This would be a game changer.

[Motokid600]

On 7/21/2019 at 10:57 AM, Brikoleur said:

Dynamic autowelding to a reasonable physics part count ceiling would do it. Other possible optimisations would be to treat other than the focused vessel as a single part or remove landed/parked vessels from physics altogether, unless/until something collides with them. 

The trade-off would be a stutter when the autowelds are recalculated (e.g. on collision or on un/dock), and somewhat less accurate simulation of things coming apart. 

The garbage collection issue ought to be resolvable -- but it might be buried so deep in Unity that in practice the effort to do so is prohibitive.

A genuine fix to KSP's performance problems would likely be a lot of work and involve a major engine upgrade (or switch to a different one altogether). That would be very expensive; I don't think it could be done without massively expanding the player base or somehow getting us to pay for the game again -- and given the unhappiness about paid DLC I doubt that's on the cards either.

It would be KSP 2 essentially.

 

Edited July 22, 2019 by Motokid600

[Shadowmage]

On 7/21/2019 at 2:41 PM, Lisias said:

I'm not an Unity expert, but it's my understading that Joints are the way to keep parts working together. You can set that Joint to be impossibly strong and make things act as one, but the physics engine still handle them as two parts.

You really need something as UbioWelding to create a derivative part with the characteristics of that two at the same time. As far as I know, it's the only way.

With current KSP code -- yep, that's the only way.

With some (relatively simple) edits to KSP code -- you could easily have parts still as separate entities, but all sharing a single RigidBody for the entire craft.  The only time there would be an explicit need of multiple rigidbodies would be robotics type parts.

The idea behind this is for Parts to still be individual entities (e.g. can explode independently of eachother), but all share a single RigidBody.  No need for joints at all except specific exceptional cases.  Only minor changes in KSP would need to happen for this to work -- most of the groundwork is already in place for the 'PhysicsSignificant' flag on parts (those parts share their parent rigidbody as far as I'm aware, and are not actually connected by joints).

Now... this would also remove 'noodle-rocket' induced RUD entirely;  there would be no joints, so there would be no noodling.  Whether that is good or bad, I'll leave up to personal opinion (I personally think it would be great).  (the limitation is that you can't monitor the forces on the joints between sections, without actually having those joints; no joints = no bending rockets).  Not entirely realistic, so perhaps some analytical method should be developed to still allow for actual, real, physical, stress-induced RUD (as opposed to sloppy-Unity-Joint induced shake-itself-to-death RUD).

 

On 7/21/2019 at 2:41 PM, Lisias said:

This would be a game changer.

Absolutely.

SQUAD, there's a hint for your next DLC.  I would gladly pay for a DLC that introduced dynamic part-welding and reduced/removed the physics bottleneck regarding part-count.  It seems to be much better than it was in the early days, but part-count is still the single most limiting factor of my craft designs.

 

Anyway... I came here to say 'My comp runs KSP at 60fps, even with tons of mods, and it is ~8 years old'.  Stayed for the discussion

[klgraham1013]

1 hour ago, Shadowmage said:

most of the groundwork is already in place for the 'PhysicsSignificant' flag on parts (those parts share their parent rigidbody as far as I'm aware, and are not actually connected by joints).

So...is this something we could play with or would KSP explode?

[Shadowmage]

1 hour ago, klgraham1013 said:

So...is this something we could play with or would KSP explode?

Yes, and also yes.

Last I checked mostly works for most structural parts.  Anything without any MODULE's in the config file should not explode the world.  Even some stuff with simple modules should be fine, like lights.  Anything with a module that messes with physics like engines, rcs, parachutes, wheels/gear/legs, etc. is likely to do strange things (or just NRE endlessly).

Even when it works though, with the current implementation, it can mess with KSPs approximated physics -- mostly drag and thermal.  Also don't have them as a root part, I don't think they can have children parts, they add their mass to the COM of their parent part, and likely a few other gotchas that I've forgotten.

To play around with it, simply patch that line in existing parts to the same value as is used in the stock small science experiments (don't remember exactly the name, or correct value, at the moment).

[Incarnation of Chaos]

2 hours ago, Shadowmage said:

Yes, and also yes.

Last I checked mostly works for most structural parts.  Anything without any MODULE's in the config file should not explode the world.  Even some stuff with simple modules should be fine, like lights.  Anything with a module that messes with physics like engines, rcs, parachutes, wheels/gear/legs, etc. is likely to do strange things (or just NRE endlessly).

Even when it works though, with the current implementation, it can mess with KSPs approximated physics -- mostly drag and thermal.  Also don't have them as a root part, I don't think they can have children parts, they add their mass to the COM of their parent part, and likely a few other gotchas that I've forgotten.

To play around with it, simply patch that line in existing parts to the same value as is used in the stock small science experiments (don't remember exactly the name, or correct value, at the moment).

I just found my next Module Manager patch; i'm guessing i would need to restrict it to Fuel Tanks, Cargo Bays, Wings (not sure?), science experiments and add some logic to prevent it from ever being the root part. But even just fuel tanks would reduce the load immensely, it's exceptionally rare that the bulk of the part count is engines/wheels/gears. 

On 7/19/2019 at 6:09 PM, TimKerbin said:

This is just a rant about KSP's memory and GPU/CPU usage. How good/bad do you think it is?Can it be improved?

KSP isn't, by a long way, the most graphically taxing game out there. Compared to the kinds of graphics demands we see in other modern games - even on their lowest settings - the graphics demands in KSP are minimal by comparison, especially in vanilla. Which makes it so frustrating how this game can grind to a virtual halt just because you wanted to install one or two mods, or because you happened to have been playing for 5 hours straight. Even though my PC is at least 7 years old (2GB video RAM, 16GB of installed RAM,  an i7 multicore processor) it still more than meets the game's current MINIMUM specifications as set by Squad. The fact an old bucket like mine can still run this game fairly well, even with many mods installed, says it all. But do I sound like an entitled little gamer when I say that if I have 7GB of RAM available (as shown in Task Manager) I expect the damn thing to be able to access it, and it can't. Even in 64-bit! Or perhaps  this is still more of a Windows problem than a Unity problem? Or both?

I just get the feeling that KSP could and should be able to run at least 60fps even with many mods installed, and it's frustrating that it doesn't. Depending on the scene I can get maybe 24-30fps (in v 1.6.0), but that depends heavily on how busy the scene is. While docking with a moderately sized station it can drop to 9-12fps (I thought 1.6.0 was suppose to improve multicore rendering for multiple ships, but I really can't see any difference);  in maximum time warp I've seen it drop to 6fps and then shoot back up to 20 then back to 8. Indeed the framerate can be VERY inconsistent with frequent lag, and again I can't tell if it's my PC (toggling V-sync makes little difference, nor does setting a frame limit) , the mods, or the game engine. And please don't tell me to stick to vanilla; mods have defined this game just as they have defined SkyRim. Even Squad members themselves (Nova Silisco for example) contributed mods to this game. KSP just isn't appealing to me any more in vanilla, because I KNOW KSP can do so much better. The forums are always full of players suggesting or requesting new mods, especially visual enhancements, which says to me the community wants this game to be as good as it can be, and we really need to be asking if it is. Even after Unity5 and 64-bit mode were introduced.

I'm not a programmer but I can't help feeling that despite the move to Unity5 and its undoubted improvements, KSP still isn't running at its full potential; and it feels as if it never will as long as it's still using Unity. Programmers, mod-makers feel free to disagree.

My suggestion to Squad-Private Division: stop producing DLC and focus instead on continuing to improve how this game already uses available resources. No point in creating more 'stuff' for the game if in turn the game becomes so bloated and slow no-one can play it. No-one should need a StarCitizen-type setup to play this game satisfactorily, it ain't Star Citizen!

The question isn't "Can it be improved"; given unlimited time and funding you bet they could crank out something resembling a proper fluid-dynamic simulator that would make universities blush. But that's not what you're asking; the question you want to know is "Given the current game; is there low-hanging fruit to be had". Which several posters above have already described fairly interesting fixes that shouldn't take much time to implement (Chasing bugs resulting from them would likely take longer). But as far as how it uses memory overall; programs allocate the memory they "Need" according to what's specified. The reason i say "Need" in quotation marks is because the majority of programs today allocate much more memory than is actually required at the time; this is so the program remains smooth and has time to allocate more memory when more is demanded (This is an EXTREMELY simplifed explaination btw). 

So what does all of this mean in english? If KSP is only asking for 4-5 GB than that's not only all the memory it needs; it's a pretty hefty pile over what it actually would need at that moment. So while i'm sure there's stuff they could do to enhance it's use of memory; that's not really an issue on your system or many others. The physics is a completely different matter; they can optimize it further to make it much smoother than it is currently but without changing how they actually handle physics (Which would likely break quite a few things) it cannot be multithreaded. So they're stuck in a rut; and i don't see how they could get out of it without a hard break.

This in my mind would be the actual purpose of a KSP 2.0; a clean slate to allow that hard break and get a sturdy foundation setup for the future. But for the most part; KSP runs pretty well in my opinion and i frequently launch ships with part counts > 200. 

And to be honest; very few games do what KSP does. No other game i know of gives you a pile of parts, then tells you to wack it into something pointy and see what happens. Everything past the VAB is pretty much handled via physics; which while not entirely accurate still comes damn close to real life. This isn't me saying KSP should be excused for it's flaws; just me saying the scope of what KSP does makes it inherently difficult to account for every potential interaction and situation. Which means i doubt the code could ever be perfectly efficient; as that would limit the possibilities for the player at some point.