It actually applies to both PC and non-PC matches and this is just my theory from what I've experienced personally from the behavior I had in game.

It's the sound!

It's something to do with the sounds that every deployed object makes. I know in EVE for a very long time, in order to reduce lag in large fleet fights everyone would always disable the sound to prevent the client from crashing. Apparently you have somehow recreated the same problem in DUST. Only we don't get the option to disable the sound.

I'll use drop uplinks for my example. If you put down one drop uplink, it makes that nice soothing "woom woom" noise if you are withing a certain proximity to it. Well if you put down another one, it also wants to make that same woom woom noise only now it's competing with the original uplink and they are BOTH making the noise and sometime they don't mesh together well. No multiply this by like 2 dozen separate instances of "woom woom" all within proximity of you. If you step outside the area where they make the noise, no lag... Renter the area, suddenly all kinds of lag! Kinda like how in beta when you went from outside a building to inside the building and the game would glitch as it loaded the stuff it needed for the inside of the building.

So if it is indeed the sound processing choking the hell out of everything because it's trying to make 2 dozen instances of all the noises simultaneously while still running everything else, then I have a possible idea on a solution. So instead of trying to make 2 dozen noises, just make ONE. Whenever you check for proximity to any equipment to make the "noise" instead of continuing to check for others and wasting processing to do it, just set a flag to only check when not within proximity of the original object making the noise and make only the one noise not 2 dozen. Then when you leave prox of first one or if it is destroyed, then go back to original check for proximity to equipment and if true make the ONE noise again. If none, then stop.

Seriously, I don't need to hear a cacophony of 2 dozen uplinks to know that they are there. Just make one woom woom noise and good to go.

Anyways, just a thought and hopefully it gives you guys something more to go on as to the possible cause of all the lag.

Hello guys.

We are deploying memory optimization fix tonight during downtime for this specific issue. Please reply to this thread with your experience/videos/findings once you've tested it for a while.

Thank you for all the feedback so far!

It actually applies to both PC and non-PC matches and this is just my theory from what I've experienced personally from the behavior I had in game.

It's the sound!

It's something to do with the sounds that every deployed object makes. I know in EVE for a very long time, in order to reduce lag in large fleet fights everyone would always disable the sound to prevent the client from crashing. Apparently you have somehow recreated the same problem in DUST. Only we don't get the option to disable the sound.

I'll use drop uplinks for my example. If you put down one drop uplink, it makes that nice soothing "woom woom" noise if you are withing a certain proximity to it. Well if you put down another one, it also wants to make that same woom woom noise only now it's competing with the original uplink and they are BOTH making the noise and sometime they don't mesh together well. No multiply this by like 2 dozen separate instances of "woom woom" all within proximity of you. If you step outside the area where they make the noise, no lag... Renter the area, suddenly all kinds of lag! Kinda like how in beta when you went from outside a building to inside the building and the game would glitch as it loaded the stuff it needed for the inside of the building.

So if it is indeed the sound processing choking the hell out of everything because it's trying to make 2 dozen instances of all the noises simultaneously while still running everything else, then I have a possible idea on a solution. So instead of trying to make 2 dozen noises, just make ONE. Whenever you check for proximity to any equipment to make the "noise" instead of continuing to check for others and wasting processing to do it, just set a flag to only check when not within proximity of the original object making the noise and make only the one noise not 2 dozen. Then when you leave prox of first one or if it is destroyed, then go back to original check for proximity to equipment and if true make the ONE noise again. If none, then stop.

Seriously, I don't need to hear a cacophony of 2 dozen uplinks to know that they are there. Just make one woom woom noise and good to go.

Anyways, just a thought and hopefully it gives you guys something more to go on as to the possible cause of all the lag.

I saw the hotfix come down last night and was wondering what it was about....

We have a bunch of PCs this afternoon, and I'll let you all know how it goes.

We are deploying memory optimization fix tonight during downtime for this specific issue. Please reply to this thread with your experience/videos/findings once you've tested it for a while.

It actually applies to both PC and non-PC matches and this is just my theory from what I've experienced personally from the behavior I had in game.

It's the sound!

It's something to do with the sounds that every deployed object makes. I know in EVE for a very long time, in order to reduce lag in large fleet fights everyone would always disable the sound to prevent the client from crashing. Apparently you have somehow recreated the same problem in DUST. Only we don't get the option to disable the sound.

I'll use drop uplinks for my example. If you put down one drop uplink, it makes that nice soothing "woom woom" noise if you are withing a certain proximity to it. Well if you put down another one, it also wants to make that same woom woom noise only now it's competing with the original uplink and they are BOTH making the noise and sometime they don't mesh together well. No multiply this by like 2 dozen separate instances of "woom woom" all within proximity of you. If you step outside the area where they make the noise, no lag... Renter the area, suddenly all kinds of lag! Kinda like how in beta when you went from outside a building to inside the building and the game would glitch as it loaded the stuff it needed for the inside of the building.

So if it is indeed the sound processing choking the hell out of everything because it's trying to make 2 dozen instances of all the noises simultaneously while still running everything else, then I have a possible idea on a solution. So instead of trying to make 2 dozen noises, just make ONE. Whenever you check for proximity to any equipment to make the "noise" instead of continuing to check for others and wasting processing to do it, just set a flag to only check when not within proximity of the original object making the noise and make only the one noise not 2 dozen. Then when you leave prox of first one or if it is destroyed, then go back to original check for proximity to equipment and if true make the ONE noise again. If none, then stop.

Seriously, I don't need to hear a cacophony of 2 dozen uplinks to know that they are there. Just make one woom woom noise and good to go.

Anyways, just a thought and hopefully it gives you guys something more to go on as to the possible cause of all the lag.

Hello guys.

We are deploying memory optimization fix tonight during downtime for this specific issue. Please reply to this thread with your experience/videos/findings once you've tested it for a while.

Thank you for all the feedback so far!

want to write so much right now but I am not. It is difficult for it to be the sound itself.

Typically, LAG is attributted to taxing resources to a point of creating a bottleneck at the NIC, CPU, Memory, etc on either or both the server and client. We would need WAY more information to make determination that sound is the issue IMO and IME.

I would argue that you could be on the right path in that something that should be locally kept and processed is being shot over the internet and taking up valuable resources on the server which chokes up the game. Or that the "code"/"db" "stuff" is over taxing the PS3 and creating local lag. It could also be a combination.

In conclusion, if it is the sound then it would be the processing of sound and that would be what causes the lag. This would also mean the lag would be local to the PS3 since the bottleneck would be there to begin with.

It just doesn't make sense from a programming or network perspective for it to be sound because sound is sound. It would have to be a bottleneck at the server or the PS3.

EDIT: An easy fix from CCP would be to limit the amount of "total" sound sources. Typically this causes some issues (some sounds will be heard while others won't) but it is for testing purposes only. Just limit the number of simultaneous sounds allowed locally on the PS3. If the lag doesn't go away then it isn't sound. It should be a very easy test. Unreal Engine has some good stuff for sound as a whole.

EDIT: And lag in games like this can, sometimes, not affect frame rate but will affect other "calculations" elsewhere. An example is the sudden invincibility people have on occasion. Doesn't seem like lag from the traditional sense but it is.

That is EXACTLY what I was saying with the OP. It's all "local lag" created by 'bottlenecks' in processing due to how they programmed the sound without any limitations. It happened that way in EVE too back in the day. Only on a PS3 you cannot disable ALL of the sounds and so it cannot be worked around. Additionally, the devs cannot reliably repeat it because it's local to each PS3 and sometimes it happens and sometimes it won't. That's why you may be experiencing lag in the game and your team mate thinks you are just making it up. It's also why CCP devs believe a lot of the lag complaints to be due to local internet issues outside of their control and always ask anyone reporting this issue to first check their local networks for anything that may be causing problems.

In the end it's a combination of the sounds without limitations combined with the current voice comms in game that make the PS3 want to kill itself. And by the way, sooooo many people are raging in FW matches right now because they cannot reliably use the Team Chat Voice Channel without incurring the voice comms bug. This also nullifies any benefit we might have gotten from OS supporting EVE pilots as they can only talk to us through Team chat in FW matches.

Oh and one more thing. The bug from beta where someone drops from a height and uses the inertial dampener, but the LOUD AS HELL sound effect of the inertial dampener being active doesn't STOP. So I can hear nothing but the guy next to me with that sound going on! This tells me that if that is the case, then you probably have the same issues on smaller (quieter) levels throughout the game where you open resources for sounds and do not properly close them out when they are done. Thus causing the slow-over-time leak of memory and resources due to sound that I pointed out in the OP. Obviously not intentionally, but by the use of some simple library to create sounds, you have introduced a "sloppy" piece of code that is doing this.

In the end, I still say it's the sound!

You CAN disable sound in DUST client. There is such an option in system setings for dust client. Separately for SFX and background music.

Then you can test if this will disable sound events handling routines in DUST clients and reduce lag.

Since i play mostly at night i have my TV sound turned down to 0. You can play DUST without soundz. But it's awkward...
For communications during PC matches you can use thirdparty livecomm programs running on another computer.

Now i plug headphones into my TV and mic into PS3 OEM SingStar dongle Dirt cheap solution below $20.

disabling the sound in the options doesn't help, you just don't hear it, but the data is still being fed to your console

Hello guys.

We are deploying memory optimization fix tonight during downtime for this specific issue. Please reply to this thread with your experience/videos/findings once you've tested it for a while.

Thank you for all the feedback so far!

Ok, done a few PCs now after the fix, I'd say performance has probably improved (based on a very limited sample) BUT FRAMERATE LAG NOT FIXED. Gallente research facility still has framerate issues, but at least in the one match I did it didn't devolve down to slide show. So framerates dropped noticeably inside the outpost with equipment present (also persisting after destruction of equipment) but I would call the performance maybe "gooey" or shaky as opposed to the more familiar jerky slideshow feeling of that map. Some spikes also on the cargo hub map, but nothing major. The few matches have all been playable for me, but not anywhere near perfect, particularly the research facility is really only playable in comparison to what it would have been last week.

CCP Delamorui Eddy,

No I cannot easily replicate this as arranging for the right map with the right people and somehow hoping that the enemy will cooperate too is not within my power to do. These are things that you should be able to do on your end by creating a "special match" for your own testing purposes and populating it with your fellow devs. To produce the dozens of uplinks and hives you would only have to just input instances of them using creation commands.

As for trying to "demonstrate" a difference between sound and no sound, that is also NOT within our power as there is no option within the PS3 to completely DISABLE the sound card. It is mismanagement with sound effects and the memory that it is gobbling up that is causing this issue (I believe) and possibly combining this with the clipping of the fancy graphical effects of the "shimmer" deployables all loading at once. So simply turning off the sound on the TV won't show this difference as the PS3 will still be trying to generate the sounds even if the TV never makes them.

Turning off some of the sound options within the game client like music and voice will possibly free up more memory for this issue, but won't definitively prove it. So unless you are willing to create "test matches" under the "other contracts" portion of the game, we have no way to help you definitely test this issue.

That's why I reported it to you and described it as I did. The ball is out of our hands now and you need to make the next step in this investigation.