• 8
SessoSaidSo

It's been 6 months since I asked about the stutter

Question

Hi.

So back in July I was pretty upset about the stutter or micro freezing as it may be known. Now it's been pretty much concluded it is due to the GC of Unity 4.x, and I have been playing 1.0.5 and see it is worse than ever.

For reference I play off a custom rig running:

Windows 10 Home

i7-5820k

GTX 980 Ti

16 GB DDR4

I generally use a resolution of 2160p or 1440p

I have run the game from the following 3 drives:

SM951 256 m.2 SSD

850 Pro 256 SATA SSD

840 EVO 512 SATA SSD

I go back and forth playing the game with DirectX and OpenGL. Problem persists either way, so I generally stick to OpenGL for performance reasons(RAM savings are significant).

No. I do not spend all my money on computer parts. I work for a large IT vendor. 

I believe back in July I came off as a Kerb-Hole, for which I apologize. I am interested in understanding if the GC issue is a currently acknowledged issue from Squad and if the team is aware of its presence (or lack thereof) in Unity 5.x. 

 

TL;DR...too bad. Go Back up and read it.

Share this post


Link to post
Share on other sites

Recommended Posts

  • 4

@sal_vager While there is an element of truth about the slowness of the GC in your post, the conclusions you come to are way off the mark

Firstly, yes, the garbage collection does run automatically but describing it as periodic makes it sound like it happens at a fixed interval and this is not the case.  Mono has a heap of a certain size and when the amount of free space in the heap drops below a threshold it runs the garbage collector to free up any objects in the heap that are no longer being used.  Only if it can't free up some space does it increase the size of the heap.  So, the fact that the memory used by KSP doesn't fluctuate much doesn't say anything about how many objects are being allocated and released.

Secondly,

56 minutes ago, sal_vager said:

So any attempts to reduce garbage by Squad would have no effect on the stutter.

This is so patently untrue that you really should withdraw this statement or you risk looking like a complete idiot.  The GCMonitor tool (or just thinking about it for a minute) clearly shows that if some code allocates 1000 objects and discards them immediately and does the same on every frame then the heap will fill up with released but not collected objects much faster and the GC will run much more frequently.

Thirdly,

56 minutes ago, sal_vager said:

As for Unity5, there are benchmarks from other software available to make comparisons, and the inclusion of a newer PhysX should mean that  physics can continue on another core while the GC is collecting, preventing it from blocking the simulation (ie the stutter)

This is a rather optimistic conclusion given that, while the GC is running, other threads are not able to allocate any memory on the heap.  The PhysX threads may be able to run while the GC does but this won't affect the stutter as that is a pause in the calls to Update that Unity makes each frame because it is unable to allocate memory.  That it why you get a stutter, nothing to do with the PhysX calculations.

Edited by Padishar

Share this post


Link to post
Share on other sites
  • 3
57 minutes ago, sal_vager said:

The 3rd point is optimistic because I'm being optimistic over Unity5's performance, I'd rather do that than be pessimistic, I'm hoping for the best.

Well, you will almost certainly be disappointed (or would be if this issue affected you).  I'd rather be pessimistic so at least there's a small chance of being pleasantly surprised.

57 minutes ago, sal_vager said:

As to the second point, please show me where KSP is allocating and removing 1000 objects on every frame as I find that unlikely, you make it sound like KSP is making and removing 1000 Kerbals or 1000 GUI's, which would have a much larger impact than we actually see.

Now that you're Squad staff, ask one of the devs to show you the source of the ResourceConverter and ResourceBroker classes.  For a vessel with a reasonable number of parts that hold EC, it only takes a couple of fuel cells to end up with well over 1000 objects (any instance of a C# class allocated with new and also things like adding an item to a full List<T>) being created and deleted each physics frame.  This isn't the only example, there are many other bits of code that create pointless garbage.

Do you accept that the more garbage the game creates, the more often the GC will run?  Logically, it follows that reducing the amount of garbage created will lessen the frequency and, if tackled seriously so that almost no garbage is created during scenes, the GC would almost never need to run and forcing it to run when the user wouldn't notice a small glitch (e.g. when saving or loading, when bringing up the pause menu, switching to/from map view etc.) could probably eliminate the noticeable stutters completely.

57 minutes ago, sal_vager said:

As for the first, the stutter is pretty regular, thats periodic enough for me.

Yes, periodic it is, but that says nothing about the frequency.  If less garbage is created it will run less often.  One call per hour would also be periodic but no-one would complain about it.

Edited by Padishar

Share this post


Link to post
Share on other sites
  • 2

Every time the code needs to know how much resource of a particular type is available (or how much space is available) it creates a new List object (which also allocates its internal array usually with the default initial capacity of 4) and scans through the whole vessel adding each Part's sub-objects that represent that resource in the part to the list.  This should only be adding the references to the list but the PartResourceList.GetAll function (called from Part.GetConnectedResources) itself creates a new List object and adds all of its resource storage sub-objects that are the correct resource type to it before returning the new List.  GetConnectedResources then copies the items from that list that have flow turned on into the one it is building and discards the list returned from GetAll.  Also, when a List object becomes full it allocates a new underlying array with twice the capacity, copies the contents across and discards the original array.  Once the list is built, it is scanned to calculate the total or space or to add or remove resource from the parts.  Then the list object is discarded. So, as well as the main list (which is at least 2 "objects" in the heap), there is also another list for every part that has storage for the resource.

Edit: Actually it is much worse than this.  The PartResourceList.GetAll function is called on every part and always creates a new list even if the part doesn't have any resources at all.  This means that every call to GetConnectedResources actually creates at least 2n + 2 bits of garbage where n is the part count of the vessel.

On every physics frame the ResourceConverter code for a fuel cell first checks to see if the source resources are available (it does the above for each source resource). Then it checks if there is enough space for the output resource (another of the above).  Then it actually removes the resource from the source parts but runs the above code again rather than reusing the lists from before (two more runs of the above code) and then it adds the resource to the output parts (another call of the above).  That's six calls every frame to a function that creates quite a lot of pointless garbage.

KSP does create a lot of garbage.  The slope of the GCMonitor graph is a direct display of how much.  Strictly speaking, the slope is the rate of memory allocation but, since the graph drops down again when the GC runs the memory must have been "released".

Edit: For a 50 part vessel with two active fuel cells there will be at least 2 * 6 * 102 = 1224 bits of garbage created just by the fuel cells on every physics frame.  The example in the bug report of a 75 part vessel with 72 fuel cells creates 72 * 6 * 152 = 65664 bits of garbage on every frame.

Reducing garbage creation is the only thing that can possibly stop (or significantly reduce the frequency of) GC stutters.  Ideally, the GCMonitor graph would generally be a horizontal line during scenes with steps up when things need to allocate memory from time to time (e.g. when another vessel comes into range, you change SOI or such like), but they certainly shouldn't be allocating any memory and throwing it away again on each frame (or multiple times per frame).

Edited by Padishar

Share this post


Link to post
Share on other sites
  • 2

I actually thought you'd locked this thread or I would have replied sooner.

On 1/10/2016 at 9:02 PM, sal_vager said:

Sorry but I have to stop you there, Squad doesn't have to acknowledge this issue, just as they don't have to post official statements for any other issue in KSP.

Yes, this is true.  However, they also don't have to hide behind inaccurate replies posted by their staff.

On 1/10/2016 at 9:02 PM, sal_vager said:

But Squad has posted in the devnotes about performance increases, HarvesteR has posted about optimization on many subjects from PQS to orbit calculations, you're welcome to use the forums search box to locate these (it's fixed).

Again, yes, there have been various optimisations to various parts of the game.  However, the generally accepted consensus is that the overall performance of the game is getting worse with each update, not better, so there is still plenty of room for improvement (and for constructive criticism).

On 1/10/2016 at 9:02 PM, sal_vager said:

All indications are that it is caused by the garbage collector, this is not Squad code and Squad cannot change the GC.

Yes, it is caused by the garbage collector.  However, I thought I had explained that changing the GC is not the only way to improve matters, reducing the amount of garbage created will reduce the frequency of the stutters regardless of what GC code Mono/Unity uses.

It is true that not all of the garbage that is created is done so by KSP code (rather than Unity) and, some aspects of how C# works makes it virtually impossible to eliminate all garbage (most notably that string objects are immutable, code that modifies a string always creates a new object) but some of the code in KSP is so bad in this respect that fixing it must reduce the frequency of the stutters and improve the performance of the game in general.

I also edited my post above to say this but I'll say it again here.  Each fuel cell creates over 12n bits of garbage on every physics frame where n is the total part count of the vessel.  For a 50 part vessel with two fuel cells that is over 1200 per frame, over 30000 per second.  For a 250 part vessel with 20 fuel cells the number would be over 60000 per frame, over 1.5 million per second (if your computer could keep up with 25 physics updates per second with that amount of garbage thrash happening).

This particular bit of code could be vastly improved by some simple refactoring (mostly passing the list to be filled in to the PartResourceList.GetAll function).  This would eliminate the list that is created for each part removing almost all of the garbage creation.  This would make a significant difference even without the other optimisations that the ResourceConverter code is crying out for.

On 1/10/2016 at 9:02 PM, sal_vager said:

Squad can only fix their stuff, which they are doing and will continue to do, but to expect an acknowledgement is unrealistic, they should not be held accountable for code they cannot control.

Well, Squad certainly are accountable for the fuel cell code.  Giving an acknowledgement that this code (and numerous other areas) produces excessive garbage (or uses a highly inefficient algorithm etc) and is contributing to the stutter (or general poor performance) would not harm Squad's image and would probably improve it in a lot of peoples' eyes.

Share this post


Link to post
Share on other sites
  • 2
13 minutes ago, KasperVld said:

I think your point about the fuel cell code has been adequatly made.

So why is a Squad staff member still claiming that KSP doesn't produce much garbage?

12 minutes ago, KasperVld said:

and come to an overall more meaningful improvement of the player experience

In whose opinion?  Calling it "microstutter" makes it sound like a minor issue but the people that suffer badly with this issue find the game virtually (or even actually) unplayable. Would you play the game if it paused for half a second every 2 seconds?  I certainly wouldn't.  I imagine they would much rather this was fixed (or at least improved) than any new feature being developed.

16 minutes ago, KasperVld said:

Coming back to the fuel cell issue in particular, I can see that the issue (this isn't even necessarily a bug) exists, but why would anyone activate 20 to 80 fuel cells on board a spacecraft? The actual impact of this issue is next to zero in the vast majority of use cases.

I have seen numerous vessels posted in this forum that are close to or exceed the 250 parts with 20 cells example I gave above.  Even a single fuel cell on a large vessel will cause a lot of (totally pointless) garbage to be created.  In any case, you are missing the real point in all this.  If there is one bit of code that is this rampant with garbage creation (and general inefficiency) then there are almost certainly many others.

19 minutes ago, KasperVld said:

I think we should also be careful to proclaim ones vision as that of the majority of players ("general concensus" and "a lot of people's eyes") given that even on these forums which are the biggest community website for KSP we'll find only a relatively small group of the people who own the game. And a small group within this relatively small group have the technical knowledge requiredd to identify, discuss and underline these issue, I would say you're definitely within this small group, but that does not mean you're speaking for a majority of the players as a whole.

I was careful.  The "generally accepted consensus" part was talking about performance and I have absolutely no doubt that the game runs measurably slower using the same (fairly large) vessel (as same as it can possibly be given the changes in the game) in 1.0.5 than it did in earlier versions and I have seen far more people posting this observation than the opposite.  I have a vessel (somewhere, I'll try to dig it out) that gets just over 10 fps in 0.25 but can barely manage 3 fps in 1.0.5 (and, yes, all the game settings are set to be as similar as possible and even if 1.0.5 is given a boost by tweaking the settings it never gets over 4 fps).  Yes, it is quite an extreme vessel but I didn't deliberately design it to show up this performance difference, it just does.

As for, "in a lot of people's eyes", again, I think I'm on pretty solid ground here.  I wasn't speaking for everybody, if I was then I wouldn't have said "probably" and would have said "all" instead of "a lot".  I reckon I could probably find (at least) a couple of hundred members of this forum that would think better of Squad if they did this and, while this isn't a lot compared to the total user base, I believe it can still be described as "a lot".  Admitting your faults is a much nicer trait than pretending they don't exist and, where paying customers are concerned, it makes a much better impression to acknowledge faults even if you also say you can't work on them yet rather than your staff trying to brush it under the carpet with misleading (or just plain wrong) statements.

Also, you make the point that the forum is only a small proportion of the user base (which is true) but if this acknowledgement were made in the forum then only the forum users would see it.  I didn't use the word majority but, given the general maturity level of this community I would be surprised if the majority of the forum users don't agree with me...

Share this post


Link to post
Share on other sites
  • 2

@Padishar I find myself agreeing wholeheartedly with everything you have said so far, and you do so far more articulately than I could.

48 minutes ago, Speadge said:

So my highest respect for @padishar.

Likewise :D

While I have relatively little experience with C#, I am not entirely unfamiliar with programming in other languages. What solid data we have points squarely at Padishars explanation being the correct one. In absence of any competing theories I can only conclude that the staff response is either uninformed or deliberately evasive.

I am trying to keep my cool here, I really am. But concrete statements like this:

On 10/01/2016 at 2:17 AM, sal_vager said:

So it's not a case of too much garbage

From a position of some authority, shortly followed an admission that you don't actually know:

On 10/01/2016 at 4:17 AM, sal_vager said:

Fact is I don't know what is going on inside KSP

Are not improving this situation.

Don't get me wrong, this is not a personal attack, and I don't know exactly how the code works either. But I'm getting the distinct impression that someone is trying to brush this under the rug. Something like: "I don't know what the issue is, but I'm sure it will be fixed some day, problem solved"
Please, tell me I am wrong about this.

 

4 hours ago, KasperVld said:

The situation comes down to the fact that there is a limited amount of development time available, even to fix bugs. We have to make choices, and although the microstutter is annoying it's not breaking the game in any meaningful way.

Indeed, time is a limited resource. However, I for one would not describe this particular issue as "annoying". It's infuriating, and it seriously impacts the playability of the game. A 1/4 to 1/2 second stall is not "microstutter", it's "I can't enjoy playing because the game keeps freezing."
While there's no need for it to go straight to the top of the list, at present it doesn't appear to be getting any attention at all. Can you point me at any recent information to the contrary?

4 hours ago, KasperVld said:

...there are plenty of other bugs, pieces of feedback and new features that we can spend that time on, and come to an overall more meaningful improvement of the player experience.

To be quite honest, I'm not looking for a "meaningful improvement of the player experience", what I'm after is a playable experience, period.

 

I will of course wait and see if this is improved in the upcoming release, however the responses gathered in this thread leave me with precious little optimism.

At this point, count me in to the "this and other performance issues are the only thing I care about being done to the game" camp.

 

14 hours ago, Padishar said:

I actually thought you'd locked this thread or I would have replied sooner.

He did. I left in disgust at that point.

 

----

Now, would anybody in the know like to explain this issue and what is being done about it?

Edited by steve_v

Share this post


Link to post
Share on other sites
  • 1
49 minutes ago, swjr-swis said:

Post a survey with the question, and you'll know.

Hehe, yeah, I did consider it, but forum surveys aren't exactly the most statistically sound source of information to be drawing firm conclusions from (as is pointed out in a lot of survey threads).

Share this post


Link to post
Share on other sites
  • 1
14 minutes ago, swjr-swis said:

Not the most perfect method, agreed. But I'd think it's statistically a little more sound than 'probably' 'I'm pretty sure' or 'it would surprise me if'...

By all means make a poll if you think that.  I'll vote but otherwise keep out of it because I can't be bothered with the validity argument that will probably ensue followed by locking of the thread...

Share this post


Link to post
Share on other sites
  • 1

I have a dream. Open-source KSP with protective licensing and semi-community semi-SQUAD controlled voting to apply merges. A man can dream, I guess...

Share this post


Link to post
Share on other sites
  • 1

Also,

8 hours ago, KasperVld said:

There's a confirmed bug on the bugtracker about it as well.

Yes, I'm fully aware of that, I was the one who confirmed it (and take a look at the linked issues too).  However, a bug being confirmed on the tracker says absolutely nothing about whether Squad are even thinking about doing anything about it.

9 hours ago, KasperVld said:

Coming back to the fuel cell issue in particular...

The issue I have described with the GetConnectedResources function is not specific to fuel cells, they just provide a particularly good example because they call it 6 times every physics update.  Every running engine and thrusting RCS block also calls it on every frame (though rocket engines use a flow mode for which it should run much quicker).  The resource window also calls it for every resource.  The RCS blocks can cause issues when docking large vessels as, while you are pressing an RCS key (or SAS is pressing it for you) each RCS block that fires calls it every frame.  This can be a considerable number on large vessels, easily enough to significantly affect the frame rate (and greatly increase the frequency of GC), which you really don't want when trying to make accurate control inputs for docking.

6 hours ago, swjr-swis said:

I wasn't actually arguing for a survey. It was brought up to illustrate a point. I will leave it at that.

Could you explain what point you think it illustrates?  I may be being dense, but I really don't get what you mean...

 

Share this post


Link to post
Share on other sites
  • 1

There is another issue with the Part.GetConnectedResources function.  It calls the PartResourceList.GetAll function presumably so it can handle parts that contain multiple "tanks" of the same resource correctly.  However, the Part.RequestResource functions (and various other code that does things with resources) simply uses PartResourceList.Get which only returns the first "tank" of the correct type.  This will mean that if someone creates such a part then the resource will show up as available in the main resource dialog (and the engine fuel gauges on the staging icons) but the contents of the extra "tanks" will not actually be available (except to resource converters because they use GetConnectedResources).

I've no idea if anyone has ever tried to make such a part, presumably someone at Squad has or, at least, they wanted to allow the possibility, or the GetAll function would never have been written in the first place.

Obviously, this shouldn't be fixed by changing RequestResource to call GetAll in its current form as that would give the GC a heart attack...

Edit: The Unity documentation goes into some detail about how the memory allocation works, common pitfalls to avoid and ways of working around them.  This page should be made compulsory reading for anyone writing code for Unity...

http://docs.unity3d.com/Manual/UnderstandingAutomaticMemoryManagement.html

Edited by Padishar

Share this post


Link to post
Share on other sites
  • 1
On 7.3.2017 at 8:30 AM, sal_vager said:

Yes, it's old, Microsoft have actually bought Xamarin and have released Mono under the MIT license, so Unity are free to upgrade to the latest version and I hear this is happening.

So there is still hope in this? I have not benn playing since 0.23 that much really anymore. And it is becuse of this. I have over 400 hrs on record with this amazing game, but the micro freezes deter me from playing the game at all :(

Is there any time line on this appening by any chance?

Share this post


Link to post
Share on other sites
  • 0

I've played KSP on 4 different computers from low end to high end over the years and I've never had this problem even on my 10 year old laptop with an integrated card I used to use. Even when playing on lowest settings at barely 30 frames it never micro stuttered or hung up. (And yes I know what that looks like, I've had the same problem your describing with other games.)

Must be specific to certain comps/gfx cards/drivers/etc..., hopefully someone else who has experienced this can help you out. The next major update will see KSP move to the newest version of Unity so possibly that will solve your problem?

Welcome back and best of luck!

Share this post


Link to post
Share on other sites
  • 0
8 hours ago, SessoSaidSo said:

Hi.

So back in July I was pretty upset about the stutter or micro freezing as it may be known. Now it's been pretty much concluded it is due to the GC of Unity 4.x, and I have been playing 1.0.5 and see it is worse than ever.

Little addition for those who are not common with "GC":
"Garbage-Collection" is a feature in the engine running every x ticks to cleanup data that is not needed anymore.

About your problem at all: I whink most of us need to understand first if you are having a problem with KSP compared to other users (i.e. extra-freezing) or are you just expecting way to much frames than many others are.There is a mod called "GC-Monitor" which may help to visualize what you are experiencing. Also a Screen of the "Performance"-Window in flightmode (moderate craft, 0.04 physics delta) would be nice to understand whats going on.

Can you also compare it to a complete vanilla installation? (You are posting in unmodded, but since you want to save memory in OGL-mode, i dont believe you are running vanilla @ all ;) )

 

I think with those information we might bring up some better suggestions than "wait for u5" like some ppl do now...
 

Share this post


Link to post
Share on other sites
  • 0

One thing I've noticed caused some noticeable stutter, at least in the VAB/SPH, is the ground crew Kerbals. It removes a little bit of graphics bling, but there's a setting to disable those, and it would at least help while building.

Scatter is also something that seems to cause fps drops and stutter for some. This is also something you can either turn down or disable entirely in the settings.

In the flight scene.. there's been a recent thread (here) where some people complained about the animated portraits of Kerbals on a craft (lower right of the screen) causing fps drops for them, which could seem like stutter. A workaround is to remove the INTERNALs of crewed parts, so the portraits don't show, and it's been reported to give a slight increase in fps. Again, at the cost of some bling, but if you find fluid graphics more important, it might be an option to consider.

 

Other than the above: I haven't seen any specific mention in release notes of a fix for graphics stutter, no. There's a bug tracker though where people report problems and SQUAD keeps track of issues - if you consider this to be a real issue and can provide a reproducible use case, you would likely get more attention to this if you post it there. This thread explains how to best put an issue to the attention of SQUAD, including a link to the bug tracker to check if your isue is already known or even already worked on.

Share this post


Link to post
Share on other sites
  • 0
9 hours ago, SessoSaidSo said:

Hi.

So back in July I was pretty upset about the stutter or micro freezing as it may be known. Now it's been pretty much concluded it is due to the GC of Unity 4.x, and I have been playing 1.0.5 and see it is worse than ever.

For reference I play off a custom rig running:

Windows 10 Home

i7-5820k

GTX 980 Ti

16 GB DDR4

I generally use a resolution of 2160p or 1440p

I have run the game from the following 3 drives:

SM951 256 m.2 SSD

850 Pro 256 SATA SSD

840 EVO 512 SATA SSD

I go back and forth playing the game with DirectX and OpenGL. Problem persists either way, so I generally stick to OpenGL for performance reasons(RAM savings are significant).

No. I do not spend all my money on computer parts. I work for a large IT vendor. 

I believe back in July I came off as a Kerb-Hole, for which I apologize. I am interested in understanding if the GC issue is a currently acknowledged issue from Squad and if the team is aware of its presence (or lack thereof) in Unity 5.x. 

 

TL;DR...too bad. Go Back up and read it.

Hi SessiSaidSo!

This bug just old like KSP,here is the cure: At the <Nvidia Controll Panel> , set the <Maximum pre-rendered frames> to 1.

Share this post


Link to post
Share on other sites
  • 0
15 minutes ago, anarkhon said:

This bug just old like KSP,here is the cure: At the <Nvidia Controll Panel> , set the <Maximum pre-rendered frames> to 1.

please dont quote _whole_ posts that are so long..

To your comment: is there any source where u learned that? Im running fine with <4> on this setting.

Edited by Speadge

Share this post


Link to post
Share on other sites
  • 0
5 hours ago, swjr-swis said:

One thing I've noticed caused some noticeable stutter, at least in the VAB/SPH, is the ground crew Kerbals. It removes a little bit of graphics bling, but there's a setting to disable those, and it would at least help while building.

Scatter is also something that seems to cause fps drops and stutter for some. This is also something you can either turn down or disable entirely in the settings.

In the flight scene.. there's been a recent thread (here) where some people complained about the animated portraits of Kerbals on a craft (lower right of the screen) causing fps drops for them, which could seem like stutter. A workaround is to remove the INTERNALs of crewed parts, so the portraits don't show, and it's been reported to give a slight increase in fps. Again, at the cost of some bling, but if you find fluid graphics more important, it might be an option to consider.

 

Other than the above: I haven't seen any specific mention in release notes of a fix for graphics stutter, no. There's a bug tracker though where people report problems and SQUAD keeps track of issues - if you consider this to be a real issue and can provide a reproducible use case, you would likely get more attention to this if you post it there. This thread explains how to best put an issue to the attention of SQUAD, including a link to the bug tracker to check if your isue is already known or even already worked on.

I have actually created two prior threads regarding this issue and many have come forward acknowledging they have this same problem. It may very well be that only certain people actually notice this issue as it appears to be fairly good mix of hardware that can reproduce this. 

Please see this video I posted on Youtube in July: https://www.youtube.com/watch?v=fI0Rx6dwJEc&feature=gp-n-y&google_comment_id=z12wt1ehdmvftt33522bijkb0kbgzz3p504

Again, this is not an FPS issue, this is a literal freezing of the game that occurs in intervals of 2 to 10 seconds. It's actually incredibly easy to recognize using mechjeb; if you pay attention to your dV stat and watch the numbers change during a burn, you will see the numbers stop for a moment and then resume. DO NOT take this to mean it is a mechjeb issue, I say this to only give an idea of how to spot this issue. 

In the past 2 threads created, Squad has never given a response and in fact many posts have tried to flat out deny this problem exists usually blaming my hardware. I upgrade my hardware every 3 or 4 months and I have had this issue for years. Played this game on Win 7, 8 and 10. 

Share this post


Link to post
Share on other sites
  • 0
6 hours ago, Speadge said:

 

Can you also compare it to a complete vanilla installation? (You are posting in unmodded, but since you want to save memory in OGL-mode, i dont believe you are running vanilla @ all ;) )
 

Also note that I said I experience the issue in both DirectX and OpenGL so I primarily just use OpenGL for Ram performance. 

As I said before, I believe everyone experiences this, I can see it in so many KSP videos, however, I believe only certain people actually notice it. 

Share this post


Link to post
Share on other sites
  • 0

Are there specific repeatable times when these lags occur? The only lag I get is when coming back to Kerbin from a different body, around 160,000m up which I believe is when the higher res textures are loading. Other than that, off the top of my head when rotating the view I will get choppiness on occasion. One of my concerns is the number of graphics options to choose from, and the arcane descriptions of what they do.

Share this post


Link to post
Share on other sites
  • 0
1 hour ago, Waxing_Kibbous said:

Are there specific repeatable times when these lags occur? The only lag I get is when coming back to Kerbin from a different body, around 160,000m up which I believe is when the higher res textures are loading. Other than that, off the top of my head when rotating the view I will get choppiness on occasion. One of my concerns is the number of graphics options to choose from, and the arcane descriptions of what they do.

Did you go look at the video I posted? No? Again, and this is the frustrating part; this is not an FPS issue, this is not a loading issue. I do not understand why these types of questions are asked. This is a well described phenomenon of which I have included a video. 

I am not looking for community support. I am not looking for someone to say, "oh, ya, the solution is...".

My question was simple and direct. Is the issue persisting within the KSP versions compiled in Unity 5.x 

This is a massive bug which I have never seen Squad make mention of and I would like them to work on. I am not a community tester. I do not get paid to fix issues.

Share this post


Link to post
Share on other sites
  • 0

hi,

checked the video and seen, that it is on the 18/19th  second most noticeable, not before, not after... Are you sure its the GCs fault? did u try the monitor i suggested?

P.S.: As u dont want help - im not here to help you, just to understand for myself why i dont have this issue :P)
Edit: ok, tried the VAB-scene. seems to be default that the truck is "hanging" somehow... never bothered me before :D

Edited by Speadge

Share this post


Link to post
Share on other sites
  • 0
4 hours ago, SessoSaidSo said:

Did you go look at the video I posted? No? Again, and this is the frustrating part; this is not an FPS issue, this is not a loading issue. I do not understand why these types of questions are asked. This is a well described phenomenon of which I have included a video. 

I am not looking for community support. I am not looking for someone to say, "oh, ya, the solution is...".

 

So, your issue is that the truck stops, then goes again? Seriously? You are right, the issue is neither an FPS issue nor a loading issue.

I think the well described phenomenon you are referring to is called "animation."

Share this post


Link to post
Share on other sites
  • 0
1 hour ago, Waxing_Kibbous said:

So, your issue is that the truck stops, then goes again? Seriously? You are right, the issue is neither an FPS issue nor a loading issue.

I think the well described phenomenon you are referring to is called "animation."

Do me a favor. Do not post on my thread if you are not going to be contributing productive dialogue. 

Watch the video i posted, then you have my permission to return.

Share this post


Link to post
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.