To use Ven's Stock Revamp or Not?

[ZooNamedGames]

I'm in the middle of the road... I don't know if I should download and use Ven's Stock Revamp part retextures or not. I have used them before and they look nice, but are they my style? I don't know...

So I'll leave the decision up to you! Tell me your thoughts  .

[Diche Bach]

I decided not to use for now. I already got way more parts than I already use, and see enough performance decrease at ~55 mods installed.

The one that breaks my heart: I did have 76 installed, including Galileo's visual enhancements and Scatterer. In testing I discovered this one seemed to be the single biggest burden on performance so it has for now been taken out. If I follow Galileo's advice and prune my part's mods to get rid of parts I never even use, I could maybe add EVE, etc. back in. But I'm at heart a gear fondler not a voyeur so, more parts than can ever be used by a single person wins over beautiful visuals, at least for now.

I would be tickled if Squad would explore making changes to the source code to be able to run SVE, EVE, Scatterer type visuals in vanilla for 1.3. Maybe just hire @Galileo

[ZooNamedGames]

14 minutes ago, Diche Bach said:

I decided not to use for now. I already got way more parts than I already use, and see enough performance decrease at ~55 mods installed.

The one that breaks my heart: I did have 76 installed, including Galileo's visual enhancements and Scatterer. In testing I discovered this one seemed to be the single biggest burden on performance so it has for now been taken out. If I follow Galileo's advice and prune my part's mods to get rid of parts I never even use, I could maybe add EVE, etc. back in. But I'm at heart a gear fondler not a voyeur so, more parts than can ever be used by a single person wins over beautiful visuals, at least for now.

I would be tickled if Squad would explore making changes to the source code to be able to run SVE, EVE, Scatterer type visuals in vanilla for 1.3. Maybe just hire @Galileo

Well I'm saving up (very slowly) for an Intel core i7-4790, granted I'll likely need help doing the tech work getting it built in.

[Diche Bach]

In my experience so far, CPU and/or graphics processor speed are not the primary bottlenecks to good performance with highly modded KSP: RAM is the bottleneck.

[Van Disaster]

CPU *is* the major bottleneck still... it's just when you get heavily modded then garbage collection starts hurting a bit.

Ven's stuff was pretty optimised last time I tried it. Some parts changed shape though which wrecked a few aircraft designs.

[ZooNamedGames]

10 minutes ago, Diche Bach said:

In my experience so far, CPU and/or graphics processor speed are not the primary bottlenecks to good performance with highly modded KSP: RAM is the bottleneck.

1.5Ghz, it's mine. You've got 8GB of RAM, how is that not enough?

[Alshain]

I love the feel of the Ven's, but if you are altering stock parts, they should have the same dimensions, and not all of his do.  So craft you build with it, will not necessarily be similar if you remove it.  For me that is a deal breaker.

[Diche Bach]

32 minutes ago, ZooNamedGames said:

1.5Ghz, it's mine. You've got 8GB of RAM, how is that not enough?

That is what I'm asking, but after a while I'm at constant 99% RAM use and probably plenty of VRAM being used too, and eventually fiddling in the VAB just becomes like slow motion.

32 minutes ago, Van Disaster said:

CPU *is* the major bottleneck still... it's just when you get heavily modded then garbage collection starts hurting a bit.

Ven's stuff was pretty optimised last time I tried it. Some parts changed shape though which wrecked a few aircraft designs.

I've only got about a CompSci 101 level of comprehension of Performance diagnostics, but suffice to say: during periods where my heavily modded build starts to crawl. I see:

A. CPU hovering in the 25 to 65% ballpark, and rarely if ever going up into the 90;

B. RAM use constantly above 95% and peaking into 99% often.

ADDIT: I've noticed a few other users here comment that "their heavily modded builds make use of all 12GB of their RAM" and I've also seen a few others comment that RAM use is the primary thing limiting their use of mods . . .

Edited September 10, 2016 by Diche Bach
additional clarification

[ZooNamedGames]

15 minutes ago, Alshain said:

I love the feel of the Ven's, but if you are altering stock parts, they should have the same dimensions, and not all of his do.  So craft you build with it, will not necessarily be similar if you remove it.  For me that is a deal breaker.

And that is now my deal breaker. I need 1:1.

12 minutes ago, Diche Bach said:

That is what I'm asking, but after a while I'm at constant 99% RAM use and probably plenty of VRAM being used too, and eventually fiddling in the VAB just becomes like slow motion.

So how much RAM and processing power do I need for this game?!

[Diche Bach]

To run the vanilla game, check what the sales page (Steam or here or wherever) recommends. I guess a 1.5GHz with 4GB or RAM and even just an onboard GPU is fine.

Vanilla, with my rig, the game is lightning fast. The performance hits I see are all my fault ultimately cause they are a result of stuff I have added to the game.

Still . . . I know that Squad is highly supportive of mods and modding, and at present, it is my unqualified speculation that the game's source code is not as "optimized" for handling heavily modded builds as it could be . . . but not areas where I have much training at all, nor areas I intend to pursue training, so . . . I could be full of it, and I don't want to make too much noise in that case . . .

[Alshain]

10 minutes ago, ZooNamedGames said:

And that is now my deal breaker. I need 1:1.

It's worth noting most of them that matter, do have the same dimensions.  But there are a few that do not and you have to go through and remove them manually.  The one that irritated me most was the Communotron 88-88, which goes from an origami folding antenna to a ISS-style antenna that is a lot like one of the ones coming in 1.2.  I loaded one of my stock craft and it was sticking out of the fairing, and that just drove me nuts.

Edited September 10, 2016 by Alshain

[ZooNamedGames]

7 minutes ago, Alshain said:

It's worth noting most of them that matter, do have the same dimensions.  But there are a few that do not and you have to go through and remove them manually.  The one that irritated me most was the Communotron 88-88, which goes from an origami folding antenna to a ISS-style antenna that is a lot like one of the ones coming in 1.2.  I loaded one of my stock craft and it was sticking out of the fairing, and that just drove me nuts.

Hm... I'll keep that in mind.

[Kerbas_ad_astra]

To be more precise, all of the modified parts have the same node positions, but may have different shapes in between.  Some parts also have new nodes added (for cosmetic tankbutts and such), so while stock craft can usually be brought into VSR without breaking, this is not necessarily true the other way without taking some care.

[sarbian]

On 10/09/2016 at 8:17 PM, Van Disaster said:

CPU *is* the major bottleneck still... it's just when you get heavily modded then garbage collection starts hurting a bit.

Ven's stuff was pretty optimised last time I tried it. Some parts changed shape though which wrecked a few aircraft designs.

Adding parts to your install  changes nothing to the amount of garbage. Garbage is generated by code (dll) 

On 10/09/2016 at 8:49 PM, Diche Bach said:

Still . . . I know that Squad is highly supportive of mods and modding, and at present, it is my unqualified speculation that the game's source code is not as "optimized" for handling heavily modded builds as it could be . . . but not areas where I have much training at all, nor areas I intend to pursue training, so . . . I could be full of it, and I don't want to make too much noise in that case . . .

No no and no. The garbage is generated by each mods code. Sure some of 1.1 code is  not optimized and could lead to more garbage when called by a mod but most of the time it is the mod own code that generates it. 

Edited September 11, 2016 by sarbian

[Diche Bach]

Interesting Sarbian, thanks for clarifying that; I take your word as that of an expert who knows what they are talking about so it is edifying to hear you comment.

So let me get this straight: Squads source code could not make any changes that would make a heavily modded KSP install perform better?

Another way to put that: The lionshare (90 or 95%) of performance degradation that occurs with heavily modded KSP builds is a result of poorly written mod .dlls?

Not questioning because I dispute the points, but simply because I do not have the expertise to know one way or the other, and it would be edifying to hear your view on those points.

This then leads to another question: Are there a set of best practices that a sizeable number of mod makers are failing to adhere to, thus resulting in mods that produce unnecessary performance degradation?

Are these sorts of problems just inevitable to a game written in a language that uses garbage collection instead of manual memory management?

[Van Disaster]

5 hours ago, sarbian said:

Adding parts to your install  changes nothing to the amount of garbage. Garbage is generated by code (dll)

In this case I meant optimized as in not excessive or wasteful asset ( mostly texture ) use, nothing to do with gc.

Diche: modders *might* be professional programmers, but many aren't - and even if they are, Unity or .NET/C# may not be something they're familiar with. You can't really expect pro code without some education and for a lot of us this *is* our education ( even with a degree & years of writing in other langs ).

There is also little documentation beyond the Unity manual about what to or not to do; there's reference to what tools are available but no "please don't do that" other than ad-hoc collected wisdom. It's like we were given a car, we poked about at it with the contents of a generic mechanic's toolbox, wrote down what all the parts did & found out how to make it move, but nobody told us you're meant to use the clutch to change gear or what the rules of the road are.

Edited September 12, 2016 by Van Disaster

[Streetwind]

11 hours ago, Diche Bach said:

So let me get this straight: Squads source code could not make any changes that would make a heavily modded KSP install perform better?

Another way to put that: The lionshare (90 or 95%) of performance degradation that occurs with heavily modded KSP builds is a result of poorly written mod .dlls?

Well, if Squad optimizes the base game to run faster without mods, then it will still run a bit faster after you add mods A part of the work on KSP 1.2 actually focuses on optimizing poorly performing routines, and modders can actually use the same approach to avoid creating more memory garbage than necessary.

Also, "performance degradation" is such an imprecise term. If you give your video card more to do, and therefore you get less FPS, do you count that as a degradation even if it's par for the course? As a rule of the thumb, anything you add that does extra stuff will take away resources from the base game. Parts and assets will take RAM, plugins will take CPU time, visual mods will take GPU time. Even if they are perfectly optimized - there's no such thing as a free lunch.

Edited September 12, 2016 by Streetwind

[Diche Bach]

3 hours ago, Streetwind said:

Also, "performance degradation" is such an imprecise term. If you give your video card more to do, and therefore you get less FPS, do you count that as a degradation even if it's par for the course? As a rule of the thumb, anything you add that does extra stuff will take away resources from the base game. Parts and assets will take RAM, plugins will take CPU time, visual mods will take GPU time. Even if they are perfectly optimized - there's no such thing as a free lunch.

Well . . . of course I do not have access to their source code (plus I have zero proficiency with C# so far!) so I'm in no position to say with certainty . . . however, the performance characteristics I have casually observed in association with heavily modded builds sound rather similar to "memory leaks" and "software aging" both of which are fairly widely regarded as hallmarks of what we might term in the biological sciences "pathological" infrastructure load. Pathos in this instance meaning "a state which evokes pity or sadness" because it is "not the way it should/could be." Yes, all life comes to end eventually, but there is a difference between living to a "ripe old age" and dying of "natural causes" in your sleep, versus making a stupid decision at age 25 to do a U-turn on a busy highway and getting obliterated by a tractor trailer going 120km/h. The latter would be considered "unneccesary" or "avoidable" mortality.

I think the same kind of logic can apply in IT: some changes to performance are inevitable given the specific operating context, i.e., it is virtually impossible to get the thing to work any "better."

Other changes to performance are NOT inevitable and reflect that parts of the whole are not functioning as they "should" to get it to run "optimally."

This is fundamentally what I'm asking: is this as good as it gets? i.e., I load up 75 of the most popular and cool sounding mods and even with a 3.5GHz CPU PLUS a 3GHz GPU (both of which are only a couple years old) and 8 GB of RAM the game progressively slips into a coma?

This does not happen with Skyrim, Fallout4, Stellaris, Jagged Alliance 2.1.13, and a half-dozen other games I play which are modded at least that heavily if not two to three times that heavily. Slower boot times? Yes. The occasional visual glitch, hang, or crash that is pretty clearly associated with modded aspects of the build? Yes. Inevitable progressive software aging and eventual coma on every session? No.

[sarbian]

Ok.

I ll stop replying to those thread since someone always mange to invent a new theory about why is going on even after someone explained what is actually going on...

[Diche Bach]

12 hours ago, Van Disaster said:

In this case I meant optimized as in not excessive or wasteful asset ( mostly texture ) use, nothing to do with gc.

Diche: modders *might* be professional programmers, but many aren't - and even if they are, Unity or .NET/C# may not be something they're familiar with. You can't really expect pro code without some education and for a lot of us this *is* our education ( even with a degree & years of writing in other langs ).

There is also little documentation beyond the Unity manual about what to or not to do; there's reference to what tools are available but no "please don't do that" other than ad-hoc collected wisdom. It's like we were given a car, we poked about at it with the contents of a generic mechanic's toolbox, wrote down what all the parts did & found out how to make it move, but nobody told us you're meant to use the clutch to change gear or what the rules of the road are.

THAT is one of the most clear explanations of the whole kit-and-kaboodle I've read. Thank you!

So basically, this modding community . . . or rather, the Patron-Client relationship between Squad and its Modding community, are probably only about as mature as the analagous relationship between say Bethesda and its modders, around the time Morrowind had become popular.

Up till now, the relationship between Squad and its modders has evolved in an "ad hoc" manner, (just as I would speculate it did for TES games initially, and most games which have active and prolific modding communities [with the possible exception of Minecraft, which seems to have been a geekfest right from the start]) and has yet to progress into a more "managed and directed" mode.

It is an interesting phenomenon from a Business/marketing/consumer psychology perspective, and it is not surprising if even the most innovative of game design studios don't quite get it because even those who DO get it only seemed to have figured it out by trial and error over the years.

[Van Disaster]

OK, this is moving towards politics of modding, and there's been plenty enough of that over the years. Simply - the game is built on an easily extensible platform, and a great many of the people who've worked on it by now have come from the modding community, so it's inherently mod friendly. That doesn't mean it's ever been sold as a modding platform - and even if it *was* and there were formal docs, you would still find mods being written by new programmers which aren't necessarily well optimised anyway.

Source has to be published publically, so if you think there's some bad code then fix it & submit the fix. If you don't know how to fix it and you're not prepared to learn, open an issue somewhere - most mod source is on Github which has plenty of support for peer review, otherwise stick it in the thread - and provide copious useful information. It'd be nice if Squad provided a bunch of "don't do thats" and perhaps some "do it this way" for common practice and I expect eventually we'll get that, but most of the time I doubt things like heavy GC use or excessive CPU time in one assembly is anything to do with them directly; sometimes it's Unity itself, sometimes it's just bad code practice, and it's the job of peer review by modders to correct that unless we want to pay Squad to do it.

I mod for fun, so much that although most of the things I've made are somewhere in public I don't generally make a noise because a) I don't want support issues, and b) usually I don't go the full 100%. Practically everyone else mods for their own benefit too - if they had to go through formal peer review and something like an ISO process just to publish a mod, who is going to bother?

Edited September 12, 2016 by Van Disaster

[CobaltWolf]

Steering us back towards the topic... I like Ven's, but I feel some of the recent updates have moved away from a 'compatible' style. By which I mean, I don't think it meshes as well visually with other mods as it did in the past.

[TheSaint]

I really like Ven's, it is a standard in my mod stable. I do wind up removing some of the models, especially a lot of the pods (stuff that has hatches) because I use a lot of other mods (like Nertea's stuff) that also have hatches and ladders in the stock style, and the visual difference with Ven's is very jarring. But the tanks and engines from Ven's just can't be beat.

[Kerbinchaser]

Ven's gives you some great new parts and some awesome textures. Use it!

Edited September 21, 2016 by Lo Var Lachland

[Dr. Jet]

Pro: Nice re-texturing and re-modeling work.

Con: It ruins some stock parts and saved vehicles by different part geometry and functionality - like solar panels or foldina antenna.

Edited October 6, 2016 by Dr. Jet