To reduce the lag reduce the data transferred

Ranger209

There are only 2 ways to reduce the lag in game. Create a bigger pipeline or reduce what travels thru the current pipeline. Since creating a bigger pipeline probably involves overhauling the engine itself lets look at reducing the data that travels through the pipeline. Below I will list ways to do that, some which may stand alone, and some which may be built upon others. Each idea is singular at its heart and a stand alone independent idea, but could be used with others listed for greater effect.

Dots and Hots is where we start. Right now some Dots and Hots tick every 2 seconds, some tick every second, I think some tick every half second. Make all Hots and Dots tick every 2 seconds period, end of discussion. This alone will reduce the data transferred by any Dots and Hots that tick every half second by a factor of 4 and those that tick every second by a factor of 2. The ticks will need to be 2 times and 4 times stronger so that the dps or hps of these abilities in the end is the same, they just pulse much slower. This includes proctato and cheese.

Make Dots and Hots single target only. This will reduce the data transferred by a factor of however many targets that specific ability can hit, or on average does hit. Hots would be self only heals while Dots would only effect 1 single target. They may need to be increased in strength to accommodate the fact that they are only single target. Certain classes may need access to more or better Hots for self healing.

Give direct damage abilities cool downs. Spamables with a damage rating deemed appropriate for a spamable would get a 1 second cooldown. Heavier hitters could get a 2 second cooldown, or a 1 second cooldown and 1 second cast time. These would do more damage than spamables by a significant margin. Complete blasters that would do even more damage, but get a 3 second or more cool down. These can be single target or AoE but are not channeled nor over time abilities.

Heals, get rid of smart targeting. Make all AoE heals so that if you are within the radius you get the heal, if you are outside the radius you don't. All AoE heals are direct heals, no AoE Hot heals. Self heals can be HoT or a direct self heal. Again the strength of these heals may need to be adjusted and balanced.

All special effects that are part of all types of these Dots, HOts, DD, DH of the CC variety would also obey any of these above mentioned rules that were adopted. No over time CC, only single target CC or AoE off of AoE direct damage that doesn't reapply the CC after the initial hit.

Gonna stop there as I probably am already pissing too many people off, but will follow up later with light attack weaving and the effects of it on server performance. It is time to re-think the amount of data that is getting pushed through the pipeline and come up with creative ways to reduce it, while at the same time maintaining current DPS/HPS numbers by pushing fewer larger numbers through rather than more smaller numbers through.

Draxys

I don’t know the tech side of it, so I can’t dispute that. But I can unequivocally say that zos will 100% not be putting in the effort to rebalance everything that would come along with this kind of change.

idk

Ranger209 wrote: »

There are only 2 ways to reduce the lag in game. Create a bigger pipeline or reduce what travels thru the current pipeline.

It is not that simple. Lag has gotten worse and better over the years. It has also been different. Guessing at the issue and coming up with a solution does not solve the problem and that is essentially what is happening here.

Organization of code greatly affects how programs perform and that is well after an engine or hardware. It makes a great difference in how the live data is handled.

Further, there have been changes to specific skills that have had determinate effects on the game performance in Cyrodiil.

It is great to think of What ifs. I think that is what lead Zos to test if removing CP improved performance. Unfortunately, we saw first hand it did not. But I am with Drazys on this. Zos clearly lacks the technical expertise or financial willingness to solve the issue. Otherwise it would have been solved by now even if it meant contracting some brain power to tackle the issue.

barshemm

I don't think it's a bandwidth issue. I think it's a cpu bottleneck and the lag is a symptom of that. ICMP traffic is low priorityb and thats what is being used to check latency by the client.

Iskiab

CPU bottleneck? I’m not an expert, but is that’s the case wouldn’t changing settings so the GPU handles more have a large in game effect?

idk

Iskiab wrote: »

CPU bottleneck? I’m not an expert, but is that’s the case wouldn’t changing settings so the GPU handles more have a large in game effect?

It is a bottleneck, but not that simple. It could be due to poor organization of the game code. Basically it could be an optimization issue.

However, as stated above, there have been changes made to other areas of the game, like skills, that have caused poor performance as well.

In other words, it is not as simple as some players think it is.

yodased

The best fix to lag especially in cyrodiil is get rid of the peer2peer connections using UDP. Also the ddos protection black hole causes two more hops, and every hop is going to add around 10ms in the best situations.

I think a lot of the problems are mutl-faceted, removing extra sanity checks would definitely allow faster roundtrip data, but when that existed, it was trivial to fool the server.

They have traded accessibility for integrity

SirAndy

Or, just do what everyone in the industry knows works well and implement both client side *and* server side prediction.

That way, you don't have to transfer *any* of the information you mentioned in real time, both the client and server predict what needs to happen next but the server never trusts data from the client (which has been ESO single largest flaw), instead the server makes the final choice and sends that to the client.

99% of the time, the client prediction will match the server choice (or be very close to it) and all is well in game land.

That's how many, many games before ESO have done it successfully. ESO should have been setup that way from the beginning but unfortunately whoever was in charge of the "netcode" had no real world experience building real time client/server systems for games.

And now they are either stuck with continuing to add band-aid patches to a flawed system or bite the bullet and redo it correctly.


PS: None of this is new, myself and others made ZOS aware of the shortcomings of their implementation all the way back in beta, months before PC launch.

heavier

Ranger209 wrote: »

There are only 2 ways to reduce the lag in game.

calling it something else, or by fixing the technologies.

Ranger209 wrote: »

Dots and Hots is where we start. Right now some Dots and Hots tick every 2 seconds, some tick every second, I think some tick every half second. Make all Hots and Dots tick every 2 seconds period, end of discussion.

this would be terrible for PvP. 1 second tick is too high as it is.
why is this even being broadcast round-trip between client and server? just have a packet signaling start sent from client and a packet signaling end from server. both sides can process the hot/dps as it incurs.
they reduce ticks to make it processor friendly and it's bad design otherwise.

Ranger209 wrote: »

Make Dots and Hots single target only. This will reduce the data transferred by a factor of however many targets that specific ability can hit, or on average does hit. Hots would be self only heals while Dots would only effect 1 single target. They may need to be increased in strength to accommodate the fact that they are only single target. Certain classes may need access to more or better Hots for self healing.

you're recommending drastic changes in gameplay to fix this...ground aoe dot needs to be multi target, vigor needs to be multi target...

Ranger209 wrote: »

Give direct damage abilities cool downs. Spamables with a damage rating deemed appropriate for a spamable would get a 1 second cooldown. Heavier hitters could get a 2 second cooldown, or a 1 second cooldown and 1 second cast time. These would do more damage than spamables by a significant margin. Complete blasters that would do even more damage, but get a 3 second or more cool down. These can be single target or AoE but are not channeled nor over time abilities.

ESO didn't forgo CD by accident and I feel it is innovative, even if completely ridiculous. All skills should have an animation time and a point through that animation where damage is dealt. I understand that "instant" cast skills would benefit from the ability to somehow be reset in mid animation. there could be cooldowns that affect how much an ability costs or its effectiveness. the distinction between light and heavy attacks is already a sort of a cooldown, in order to get full damage you need to have a greater windup. some skill that can implement this type of hold and release to get full power would improve pacing and prevent exploits that involve flooding a specific skill that is instant cast so it procs 4x in a second.
some skills could cost more to spam relentlessly, each time it is cast it costs more, similar to the dodge roll.
again there is a kind of biology that ESO upholds where CD is removed and everything you have slotted is always available.

I wanted to see how long I could go without differing to TERA and this has to be a record. In TERA keeping track of cooldowns is a very major part of combat. it really adds something to be able to know the exact moment your enemy will have a CC become available so that you can react accordingly. I PvPed at such a high level I was able to keep track of at least 15 cooldowns of my own and the major CDs of multiple opponents. It makes combat an effort to dictate pace and force the expenditure of an opponent's important ability with a cheap ability of your own. ESO's variety of PvP is primarily a judgement of how an a opponent can attack and defend based on their inert build.

Ranger209 wrote: »

Heals, get rid of smart targeting. Make all AoE heals so that if you are within the radius you get the heal, if you are outside the radius you don't. All AoE heals are direct heals, no AoE Hot heals. Self heals can be HoT or a direct self heal. Again the strength of these heals may need to be adjusted and balanced.

All special effects that are part of all types of these Dots, HOts, DD, DH of the CC variety would also obey any of these above mentioned rules that were adopted. No over time CC, only single target CC or AoE off of AoE direct damage that doesn't reapply the CC after the initial hit.

Gonna stop there as I probably am already pissing too many people off, but will follow up later with light attack weaving and the effects of it on server performance. It is time to re-think the amount of data that is getting pushed through the pipeline and come up with creative ways to reduce it, while at the same time maintaining current DPS/HPS numbers by pushing fewer larger numbers through rather than more smaller numbers through.

I don't know about making healing require aim but ground heals would be cool. Think motes from TERA.
There definitely should be an aim requirement for bowtards tho

The solution to server performance issues is always to throw TDP at the situation and transfer the calculations that may be translated to a computational accelerator.

Maybe even create a network of nodes located across the globe and have a direct pipeline running between them and async comms.

In order to address the issues of hackers and lags, the role of the server needs to be improved upon.

Handling multiplayer requires some parables in order to be idealized. Think of a referee in a soccer/football game.

The players play, the ref is there to make sure things are good.

heavier

yodased wrote: »

The best fix to lag especially in cyrodiil is get rid of the peer2peer connections using UDP. Also the ddos protection black hole causes two more hops, and every hop is going to add around 10ms in the best situations.

I think a lot of the problems are mutl-faceted, removing extra sanity checks would definitely allow faster roundtrip data, but when that existed, it was trivial to fool the server.

They have traded accessibility for integrity

what are the p2p connections doing? client to client? (surely not, but I would be in favor of this)

I've just remembered that my modem is a PoS and I could be getting throttled by it during large battles.
that happened in TERA, smh.

ddos is an ancient technique and there should be a modern solution to it. not sure if one exists but it's such a simple attack I'd imagine a very convoluted solution is needed

barshemm wrote: »

I don't think it's a bandwidth issue. I think it's a cpu bottleneck and the lag is a symptom of that. ICMP traffic is low priorityb and thats what is being used to check latency by the client.

100% cyro lags but I can simply leave and do a dungeon with no lag artifacts. CPU thread is limited by IPC or bandwidth who knows.

my lags are compounding and I'm getting paranoid at the cause of them all DDDD:

barshemm wrote: »

I don't think it's a bandwidth issue. I think it's a cpu bottleneck and the lag is a symptom of that. ICMP traffic is low priorityb and thats what is being used to check latency by the client.

low priority on ISP routing?

Kadoin

SirAndy wrote: »

Or, just do what everyone in the industry knows works well and implement both client side *and* server side prediction.

That way, you don't have to transfer *any* of the information you mentioned in real time, both the client and server predict what needs to happen next but the server never trusts data from the client (which has been ESO single largest flaw), instead the server makes the final choice and sends that to the client.

99% of the time, the client prediction will match the server choice (or be very close to it) and all is well in game land.

That's how many, many games before ESO have done it successfully. ESO should have been setup that way from the beginning but unfortunately whoever was in charge of the "netcode" had no real world experience building real time client/server systems for games.

And now they are either stuck with continuing to add band-aid patches to a flawed system or bite the bullet and redo it correctly.


PS: None of this is new, myself and others made ZOS aware of the shortcomings of their implementation all the way back in beta, months before PC launch.

I'm guessing they don't do this because they do not want jerky or ugly animations to sometimes occur. What's funny is that it already does once you reach a certain lag threshold.

If that's not the reason why, I can't see it unless the server is one that scales on demand and is not hosted at ZOS...Then it would make sense since it would cost more money to have a system like that always running on the server.

SugaComa

Ranger209 wrote: »

There are only 2 ways to reduce the lag in game. Create a bigger pipeline or reduce what travels thru the current pipeline. Since creating a bigger pipeline probably involves overhauling the engine itself lets look at reducing the data that travels through the pipeline. Below I will list ways to do that, some which may stand alone, and some which may be built upon others. Each idea is singular at its heart and a stand alone independent idea, but could be used with others listed for greater effect.

Dots and Hots is where we start. Right now some Dots and Hots tick every 2 seconds, some tick every second, I think some tick every half second. Make all Hots and Dots tick every 2 seconds period, end of discussion. This alone will reduce the data transferred by any Dots and Hots that tick every half second by a factor of 4 and those that tick every second by a factor of 2. The ticks will need to be 2 times and 4 times stronger so that the dps or hps of these abilities in the end is the same, they just pulse much slower. This includes proctato and cheese.

Make Dots and Hots single target only. This will reduce the data transferred by a factor of however many targets that specific ability can hit, or on average does hit. Hots would be self only heals while Dots would only effect 1 single target. They may need to be increased in strength to accommodate the fact that they are only single target. Certain classes may need access to more or better Hots for self healing.

Give direct damage abilities cool downs. Spamables with a damage rating deemed appropriate for a spamable would get a 1 second cooldown. Heavier hitters could get a 2 second cooldown, or a 1 second cooldown and 1 second cast time. These would do more damage than spamables by a significant margin. Complete blasters that would do even more damage, but get a 3 second or more cool down. These can be single target or AoE but are not channeled nor over time abilities.

Heals, get rid of smart targeting. Make all AoE heals so that if you are within the radius you get the heal, if you are outside the radius you don't. All AoE heals are direct heals, no AoE Hot heals. Self heals can be HoT or a direct self heal. Again the strength of these heals may need to be adjusted and balanced.

All special effects that are part of all types of these Dots, HOts, DD, DH of the CC variety would also obey any of these above mentioned rules that were adopted. No over time CC, only single target CC or AoE off of AoE direct damage that doesn't reapply the CC after the initial hit.

Gonna stop there as I probably am already pissing too many people off, but will follow up later with light attack weaving and the effects of it on server performance. It is time to re-think the amount of data that is getting pushed through the pipeline and come up with creative ways to reduce it, while at the same time maintaining current DPS/HPS numbers by pushing fewer larger numbers through rather than more smaller numbers through.

You really don't understand how this works do you

For the layman that sounds great ... Reality ... Probably wouldn't make anything different other than create a boring arse Game that no one wants to play

Simple truth is as numbers drop the number of servers used to create the mega server are also reduced to prevent unneeded overhead costs

This means calculations take longer and are creating lag

Also pings from farther reaching clients take longer to process as the send n return are longer

Influx of people using mobile data instead of fixed line internet is creating lag

All these things need to be addressed first



Merge NA and EU servers so more servers are running

Improve the net code for balancing the send n return times for different regional zones across the globe

Do what bungue did and identify mobile data connections and lock those players from the game (usually kids who's parent turn off the WiFi as punishment so they tether the condone to their phones )

Ranger209

idk wrote: »

Ranger209 wrote: »

There are only 2 ways to reduce the lag in game. Create a bigger pipeline or reduce what travels thru the current pipeline.

It is not that simple. Lag has gotten worse and better over the years. It has also been different. Guessing at the issue and coming up with a solution does not solve the problem and that is essentially what is happening here.

Organization of code greatly affects how programs perform and that is well after an engine or hardware. It makes a great difference in how the live data is handled.

Further, there have been changes to specific skills that have had determinate effects on the game performance in Cyrodiil.

It is great to think of What ifs. I think that is what lead Zos to test if removing CP improved performance. Unfortunately, we saw first hand it did not. But I am with Drazys on this. Zos clearly lacks the technical expertise or financial willingness to solve the issue. Otherwise it would have been solved by now even if it meant contracting some brain power to tackle the issue.

Correct, fixing the pipeline seems beyond them technically or beyond them for budgetary reasons. Fixing this would be a massive undertaking that they are not willing to endure, or they would have done it, or would be in the process doing it. There have been improvements, but they seem to be short lived or have a minor impact.

If you try to force 10 pounds of poo through a 1 pound tube this is what you get. I am conceding at this point that we are stuck with the 1 pound tube. The only logical thing to do in that instance is change the amount of poo. Any one of the above mentioned ideas will reduce that significantly. If the amount of data moving from server to client and client to server can be culled to 25% of what it currently is that is significant, and most likely in their budget as suggested above.

I'm a firm believer that you can fix just about anything if you are willing to throw enough money at it. However, the amount of money required to properly fix this seems to be beyond what they are committed to.

SirAndy

Kadoin wrote: »

SirAndy wrote: »

Or, just do what everyone in the industry knows works well and implement both client side *and* server side prediction.
That way, you don't have to transfer *any* of the information you mentioned in real time, both the client and server predict what needs to happen next but the server never trusts data from the client (which has been ESO single largest flaw), instead the server makes the final choice and sends that to the client.
99% of the time, the client prediction will match the server choice (or be very close to it) and all is well in game land.
That's how many, many games before ESO have done it successfully. ESO should have been setup that way from the beginning but unfortunately whoever was in charge of the "netcode" had no real world experience building real time client/server systems for games.
And now they are either stuck with continuing to add band-aid patches to a flawed system or bite the bullet and redo it correctly.

PS: None of this is new, myself and others made ZOS aware of the shortcomings of their implementation all the way back in beta, months before PC launch.

I'm guessing they don't do this because they do not want jerky or ugly animations to sometimes occur. What's funny is that it already does once you reach a certain lag threshold.
If that's not the reason why, I can't see it unless the server is one that scales on demand and is not hosted at ZOS...Then it would make sense since it would cost more money to have a system like that always running on the server.

Yes, the only drawback of client/server prediction is that if/when both get out of sync the client has to adjust its wrong prediction and display what the server has decided to be the ground truth.
When that happens you get "rubber banding" or really jerky movement animations on the client.

But personally, i'd rather see some other player rubber banding every once in a while if that means i can have lag free game play while hundreds of other players are in my view.

heavier

SirAndy wrote: »

Kadoin wrote: »

SirAndy wrote: »

Or, just do what everyone in the industry knows works well and implement both client side *and* server side prediction.
That way, you don't have to transfer *any* of the information you mentioned in real time, both the client and server predict what needs to happen next but the server never trusts data from the client (which has been ESO single largest flaw), instead the server makes the final choice and sends that to the client.
99% of the time, the client prediction will match the server choice (or be very close to it) and all is well in game land.
That's how many, many games before ESO have done it successfully. ESO should have been setup that way from the beginning but unfortunately whoever was in charge of the "netcode" had no real world experience building real time client/server systems for games.
And now they are either stuck with continuing to add band-aid patches to a flawed system or bite the bullet and redo it correctly.

PS: None of this is new, myself and others made ZOS aware of the shortcomings of their implementation all the way back in beta, months before PC launch.

I'm guessing they don't do this because they do not want jerky or ugly animations to sometimes occur. What's funny is that it already does once you reach a certain lag threshold.
If that's not the reason why, I can't see it unless the server is one that scales on demand and is not hosted at ZOS...Then it would make sense since it would cost more money to have a system like that always running on the server.

Yes, the only drawback of client/server prediction is that if/when both get out of sync the client has to adjust its wrong prediction and display what the server has decided to be the ground truth.
When that happens you get "rubber banding" or really jerky movement animations on the client.

But personally, i'd rather see some other player rubber banding every once in a while if that means i can have lag free game play while hundreds of other players are in my view.

could be good

some stuff should be kept out of the scope of SP perhaps. guessing everything can be harmful.

Ranger209 wrote: »

I'm a firm believer that you can fix just about anything if you are willing to throw enough money at it.

throw money at infrastructure not deleting keystones to the game

Ranger209

heavier wrote: »

SirAndy wrote: »

Kadoin wrote: »

SirAndy wrote: »

Or, just do what everyone in the industry knows works well and implement both client side *and* server side prediction.
That way, you don't have to transfer *any* of the information you mentioned in real time, both the client and server predict what needs to happen next but the server never trusts data from the client (which has been ESO single largest flaw), instead the server makes the final choice and sends that to the client.
99% of the time, the client prediction will match the server choice (or be very close to it) and all is well in game land.
That's how many, many games before ESO have done it successfully. ESO should have been setup that way from the beginning but unfortunately whoever was in charge of the "netcode" had no real world experience building real time client/server systems for games.
And now they are either stuck with continuing to add band-aid patches to a flawed system or bite the bullet and redo it correctly.

PS: None of this is new, myself and others made ZOS aware of the shortcomings of their implementation all the way back in beta, months before PC launch.

I'm guessing they don't do this because they do not want jerky or ugly animations to sometimes occur. What's funny is that it already does once you reach a certain lag threshold.
If that's not the reason why, I can't see it unless the server is one that scales on demand and is not hosted at ZOS...Then it would make sense since it would cost more money to have a system like that always running on the server.

Yes, the only drawback of client/server prediction is that if/when both get out of sync the client has to adjust its wrong prediction and display what the server has decided to be the ground truth.
When that happens you get "rubber banding" or really jerky movement animations on the client.

But personally, i'd rather see some other player rubber banding every once in a while if that means i can have lag free game play while hundreds of other players are in my view.

could be good

some stuff should be kept out of the scope of SP perhaps. guessing everything can be harmful.

Ranger209 wrote: »

I'm a firm believer that you can fix just about anything if you are willing to throw enough money at it.

throw money at infrastructure not deleting keystones to the game

Don't think they want to make that big of an investment.

Ranger209

In the end the way I look at it at this point is that they have tried numerous code fixes. I honestly do not know to what end, but they have made attempts to streamline certain aspects of the code. Which code, where, and how, I do not know. These fixes have had limited, or sometimes temporary success, but after 3 plus years of trying we are still here with the lag and the bugs it induces. It is time to look at other avenues of relieving server stress, and reducing combat calculations by an order of magnitude of 2 to 4 or more has got to make a difference.

barshemm

To be more clear. Based on what I see, the bottle neck is server side, not on your client.

The larger the battle the more calculations necessary to handle a single event.

I think they just have too many forms of damage modification.

Take a sub assault on a group of players.

For each player you have to check the attackers weapon damage and Max stamina to come up with a base damage. That damage then gets boosted by several CP trees, each and additional calculation. Then you have to take the target and calculate their armor vs penetration of the attacker. Modify several more times for their CP. Check for minor and major protections... Oh wait, attack can have minor or major berserk plus the damage modifer from say incap and minor vulnerability. Of yea crit chance, crit damage modifiers...

We have a system where buffs are refreshed at least a couple times a minutes and debuffs are plentiful and then of course that's a single attack. How many dots are happening on the server at a time each requiring all those calculations.

I think if they did a CP overhaul to simplify a lot of those calculations it would be a start.

fred4

barshemm wrote: »

To be more clear. Based on what I see, the bottle neck is server side, not on your client.

I agree. I had ESO on a bandwidth limited 3G connection when my landline was down. I buy 2GB at a time for that connection and the meter hardly moved at all, just a couple of megs for a gaming session. ESO uses hardly any bandwidth. The whole premise of the original post is very likely moot. Client and server have to constantly exchange data to track movement. Whether a DOT ticks every 1/2 second or two seconds seems pretty irrelevant in terms of network usage, as it's going to be an extra few bytes added to a packet that needs to be sent anyway.

For each player you have to check the attackers weapon damage and Max stamina to come up with a base damage. That damage then gets boosted by several CP trees, each and additional calculation. Then you have to take the target and calculate their armor vs penetration of the attacker. Modify several more times for their CP. Check for minor and major protections... Oh wait, attack can have minor or major berserk plus the damage modifer from say incap and minor vulnerability. Of yea crit chance, crit damage modifiers...

This is not really a valid concern. If ZOS programmers have any brains at all, they will precompute mitigation, healing and damage parameters for each character. Their armor sets and CP can easily be rolled up into a precomputed matrix. Yes, there is additional stuff to check, for example the temporary boosts from Incap, armor procs, and so on. Complexity may be an issue, but I don't see that there needs to be a difference between CP and no CP performance. CP and armor sets remain fixed during combat, which means there is no reason why you can't precompute their cumulative effect.

We have a system where buffs are refreshed at least a couple times a minutes and debuffs are plentiful and then of course that's a single attack. How many dots are happening on the server at a time each requiring all those calculations.

Sure, you can check against dynamic buffs whenever an attack takes place. If a character has Major Resolve and gets attacked, the software can check whether the character has Major Resolve for each attack. On the other hand, the software might recompute a characters active stats every time a buff changes. That means they only have a separate computation for Major Resolve every 20 seconds, when that buff is taken or expires. Which method is more efficient and which they actually use, only ZOS can say.

I think if they did a CP overhaul to simplify a lot of those calculations it would be a start.

People have been barking up this tree forever and IMO that is wrong. CP are fixed during combat, which makes them easy to handle. What will have an effect on performance is the additional events generated by CP, such as Critical Leech healing, Unchained, and so on. Funnily enough though, you and everyone else who has made this point keeps talking about the way CP modify a characters stats. Only ZOS know which code is sub-ooptimal. It could be related to CP stat boosts, but there is no intrinsic reason for that.

fred4

I also want to respond to the person who said that client and server, or maybe just the client, commonly predict what the other side will do in MMOs. I believe ESO already does this. When I run around cloaking every 2.9 seconds in heavy lag, this remains remarkably reliable. I remain cloaked and other players are not detecting me. However, if I try to cast other skills, such as Siphoning Attacks, inbetween cloaking, then I really feel the lag. Cloak or the other skill often fail or are not enacted in a timely fashion.

idk

Data has to be transmitted at some point. It is a requirement as I need to learn from the server what damage another player did to me or how much I was healed for.

Further, we used to have a trusted client design in this game. That opens the door to much more exploiting, which we saw in the game. More had to be moved server side to prevent cheat engine use. So even little things like how much ultimate needs to be sent to the server.

barshemm

They did no CP tests in the CP campaign a while back, the lag was basically gone.

Everyone was melting in cold fire too.

fred4

Ranger209 wrote: »

idk wrote: »

Ranger209 wrote: »

There are only 2 ways to reduce the lag in game. Create a bigger pipeline or reduce what travels thru the current pipeline.

It is not that simple. Lag has gotten worse and better over the years. It has also been different. Guessing at the issue and coming up with a solution does not solve the problem and that is essentially what is happening here.

Organization of code greatly affects how programs perform and that is well after an engine or hardware. It makes a great difference in how the live data is handled.

Further, there have been changes to specific skills that have had determinate effects on the game performance in Cyrodiil.

It is great to think of What ifs. I think that is what lead Zos to test if removing CP improved performance. Unfortunately, we saw first hand it did not. But I am with Drazys on this. Zos clearly lacks the technical expertise or financial willingness to solve the issue. Otherwise it would have been solved by now even if it meant contracting some brain power to tackle the issue.

Correct, fixing the pipeline seems beyond them technically or beyond them for budgetary reasons. Fixing this would be a massive undertaking that they are not willing to endure, or they would have done it, or would be in the process doing it. There have been improvements, but they seem to be short lived or have a minor impact.

If you try to force 10 pounds of poo through a 1 pound tube this is what you get. I am conceding at this point that we are stuck with the 1 pound tube. The only logical thing to do in that instance is change the amount of poo. Any one of the above mentioned ideas will reduce that significantly. If the amount of data moving from server to client and client to server can be culled to 25% of what it currently is that is significant, and most likely in their budget as suggested above.

I'm a firm believer that you can fix just about anything if you are willing to throw enough money at it. However, the amount of money required to properly fix this seems to be beyond what they are committed to.

The problem is, you actually know nothing. I do not believe the size of the pipe is an issue at all, see my earlier posts, but then again I am making wild guesses in a vacuum, like you.

I work as a software developer. When there is a technical problem, it is good to have a working theory, but I typically change my mind 10 times during the investigation. It is a bad idea to tell your superiors what you think the cause is, before the investigation is complete, let alone the customer. This is what it's like for the person (me) who is in the best position to make an educated guess. What others think is typically far off base. As such, even though I've made some long-winded posts myself, I have to believe that this thread is worthless. It hardly ever helps me in my job when a customer suggests fixes for a problem. The only thing that does is a complete description of the symptoms. The rest is up to ZOS.

For an extreme example of the insane difficulty some companies have in maintaining their product, consider Oracle. The latest versions (12) of their database client caused memory leaks in our software. Googling it I eventually found another customer with the exact same problem. It had taken Oracle 6 months to diagnose it, and a further year before a fix would make it into their general release. It was something that had previously been working, e.g. a regression issue, and it was a severe problem for the affected customers. I thought the timescales were utterly insane, until I read this blog post from an ex-Oracle developer:

https://news.ycombinator.com/item?id=18442941

Enjoy!

fred4

barshemm wrote: »

They did no CP tests in the CP campaign a while back, the lag was basically gone.

Everyone was melting in cold fire too.

I was there, and it was not (PC EU).

Xvorg

barshemm wrote: »

They did no CP tests in the CP campaign a while back, the lag was basically gone.

Everyone was melting in cold fire too.

That's not true, PC NA still had lag.

Gilvoth

i just know i got bad lagg and ping and something needs fix it!

idk

barshemm wrote: »

They did no CP tests in the CP campaign a while back, the lag was basically gone.

Everyone was melting in cold fire too.

The lag was not eliminated in that test. It was most certainly still there.

Ranger209

Ok maybe the pipeline analogy wasn't the best. The imagery that it inspires isn't probably the best for what I am actually referring to. "Pipeline" as I am using it refers to the pathway, no, pathway is bad too, the processes and calculations that the data must go through among multiple clients via the server from the moment an ability is cast, through the end result of seeing the effect that ability had on the target client for as many clients as need to know that information based on their proximity to the event that has just taken place. I am not just talking client/server exchange of data, but also the manipulation of that data every step of the way. Every calculation being performed with that data server side and client side for all clients in need of knowing that calculation is being performed.

Maybe 600 legged octopus is a better visual whatever that is...a hexactapus? Maybe a train station with 600 incoming tracks works better. The bottom line is this, if there are 10000 calculations being performed per second (picking that number out of a hat), that the server has to deal with, and it could be reduced to 5000 or even 2500 calculations per second without changing dps or hps, without changing the size of fights or number of participants, that would have a large impact on server performance. The one thing I see it affecting that would have to be watched is that I believe health bars would become more volatile as bigger numbers that occurred at a slower rate would be the outcome.

fred4

There are some drawbacks to this. Anything longer than 1 second would make PvP subtly more bursty. There's a reason Viper was changed from a 4 second burst to a 1 per second DOT. Now you're saying 2 seconds is the number to aim for? I'm not sure about this.

Abilities that create more than one event per second have an effect on proc set rates and things like Crit Surge. For example It would affect (stam)sorc healing badly if, say, Arrow Barrage and Hurricane only procced once every 2 seconds. Force Pulse is another example of a (unique) skill that affects proc rates. All I'm saying is that this would have to be done with great care to avoid unintended knock-on effects, of which I think there would be many.

What you are suggesting amounts to a general tidyup and rewrite of the combat code. A lot of work, and something the benefit of which would be hard to quantify in advance. IMO ZOS would be better off using audit logs and performance profiling tools to pinpoint where the bottlenecks actually are, before embarking on major rewrites.

Ranger209

Here's as example using healing springs in an excessive amount for dramatic effect.
Let's say you have 10 players each casting 3 layers of springs. At the most extreme point you will have 30 layers of springs on the ground, pulsing 4 times each one second apart, with the ability to heal 180 players. Each pulse of each layer of springs has to figure out which 6 players it will heal and then heal them accordingly. That's a lot going on.

This could be changed one of two ways according to OP. It could be a self only hot which doesn't have to figure out who to heal pulses every 2 seconds for twice the amount of healing each pulse, healing only the 10 players that cast it. Or it could be changed to an AoE direct heal that heals every target within its radius one time for 4 times the healing power. It does have to figure out who to heal, but it is all inclusive, or all exclusive depending on who is within the radius. Both of these ways of the spell working require orders of magnitude less calculations by the server to perform the heals.

heavier

Ranger209 wrote: »

Here's as example using healing springs in an excessive amount for dramatic effect.
Let's say you have 10 players each casting 3 layers of springs. At the most extreme point you will have 30 layers of springs on the ground, pulsing 4 times each one second apart, with the ability to heal 180 players. Each pulse of each layer of springs has to figure out which 6 players it will heal and then heal them accordingly. That's a lot going on.

This could be changed one of two ways according to OP. It could be a self only hot which doesn't have to figure out who to heal pulses every 2 seconds for twice the amount of healing each pulse, healing only the 10 players that cast it. Or it could be changed to an AoE direct heal that heals every target within its radius one time for 4 times the healing power. It does have to figure out who to heal, but it is all inclusive, or all exclusive depending on who is within the radius. Both of these ways of the spell working require orders of magnitude less calculations by the server to perform the heals.

a simpler solution would be to reduce their radius so you have to really intentionally get healed by it.