Page 3 of 6 FirstFirst 123456 LastLast
Results 41 to 60 of 107
  1. #41
    Community Member
    Join Date
    Sep 2009
    Posts
    2,221

    Default

    Quote Originally Posted by Chai View Post
    Yet games like EQ in older tech eras supported them just fine.

    The idea that this is a problem with no solution other than proposed makes those of us with experience on these issues lol.

    I'd be fine to be proven wrong on this if/when they lower the procs and lag disappears, but we all know what kind of dream that is. We will see the same explanation provided as before: We eliminated one source of lag, but since others remain, there appears to be no change/minimal change in the symptoms.
    EQ had far fewer procs on weapon hits than later games. They had far fewer abilities on the stack from each player also. It really was an auto-attack meta with the occasional proc or ability (like kick, slam or backstab) occurring in a fixed rotation.

    EQ2 had a load of procs and abilities by the time they were 11 years out and they went back and did basically just what SSG is proposing to do now. The effect was an end to crippling raid and group lag and a mile marker on the road to a largely lag free game. Other things had to be fixed also, like the way that effects and animations interacted but the lion's share of the solution was in keeping the combat queues from stacking up to the point of delayed execution and reporting.

  2. #42
    Community Member Chai's Avatar
    Join Date
    Aug 2008
    Location
    Wisconsin, birthplace of D&D
    Posts
    27,794

    Default

    Quote Originally Posted by KoobTheProud View Post
    EQ had far fewer procs on weapon hits than later games.
    No.

    The way the game was set up was based on procs. If you were dual wielding (EQs version of twf) every single main hand swing had a chance to proc an off hand swing based on dual wield skill (0-255 in OG EQ). For one handed and two handed, every swing also had a chance to proc a double attack (what DDO calls double strike) then eventually triple attack.

    This is before we discuss weapon effects procs, procs from AAs (which had several tiers), etc...

    Quote Originally Posted by KoobTheProud View Post
    They had far fewer abilities on the stack from each player also.
    Also no.

    Ever watch a bard refresh buffs in OG EQ? The APM and the PPM of that one class alone would cause DDO forumites to cry tears that would cure cancer.

    There were also buffs which worked on a proc per tick basis. Mana per tick, health per tick, stamina per tick for longer raid fights, damage per tick, etc...and in the first few eras there was no limit to the number of people per raid (not even an interface for it) - You could have 60+ people in one corner of Nagafen's Lair beating on the dragon, while another 30-54 were in the same zone grouped at specific spawn points (Efreeti, Giants, Bugs, Zone Exit, Bats, and Chief were the popular camps)

    The entire back end of that game's combat system was based on procs. I won't tell you that game didn't lag, but it was able to handle alot more than this game does quantitatively considering DDO limits #players/quest to 6 and /raid 12 while you could have over 100 players in an EQ zone (they have since changed this to have multi-instances, but it wasn't like that in OG EQ) - all in an era when bandwidth was far worse (alot more people on dial up) and on old school HW infrastructure compared to what can be had now days (Blades were a NEW thing).
    Last edited by Chai; 04-16-2021 at 06:01 PM.
    Quote Originally Posted by Teh_Troll View Post
    We are no more d000m'd then we were a week ago. Note - This was posted in 10/2013 (when concurrency was ~4x what it is today)

  3. #43
    Community Member
    Join Date
    Sep 2009
    Posts
    2,221

    Default

    Quote Originally Posted by Chai View Post
    No.

    The way the game was set up was based on procs. If you were dual wielding (EQs version of twf) every single main hand swing had a chance to proc an off hand swing. For one handed and two handed, every swing also had a chance to proc a double attack (what DDO calls double strike) then eventually triple attack.

    This is before we discuss weapon effects procs, procs from AAs (which had several tiers), etc...



    Also no.

    Ever watch a bard refresh buffs in OG EQ? The APM and the PPM of that one class alone would cause DDO forumites to cry tears that would cure cancer.

    There were also buffs which worked on a proc per tick basis. Mana per tick, health per tick, stamina per tick for longer raid fights, damage per tick, etc...and in the first few eras there was no limit to the number of people per raid (not even an interface for it) - You could have 60+ people in one corner of Nagafen's Lair beating on the dragon, while another 30-54 were in the same zone grouped at specific spawn points (Efreeti, Giants, Bugs, Zone Exit, Bats, and Chief were the popular camps)

    The entire back end of that game's combat system was based on procs. I won't tell you that game didn't lag, but it was able to handle alot more than this game does quantitatively considering DDO limits #players/quest to 6 and /raid 12 while you could have over 100 players in an EQ zone (they have since changed this to have multi-instances, but it wasn't like that in OG EQ) - all in an era when bandwidth was far worse (alot more people on dial up) and on old school HW infrastructure compared to what can be had now days (Blades were a NEW thing).
    Seriously, you lost me at AA's. AA's did not exist until Luclin came out in 2002. The AA tree did not get large until much later and most of the early AA's were passive non-combat AA's that proc'd nothing but instead increased a baseline stat, resistance or a continuous effect that was not related to any active ability. The procs you're talking about in combat were minimal compared to the number of procs in EQ2 as it evolved.

    If EQ had procs at the level you suggest the combat queue would have just died, as the number of characters contributing was insanely large compared to any modern MMO.

    Another of the differences between EQ and more modern MMO's was the one you touched on about there being no raid interface. Frequently the number of players getting updates on damage in a given encounter was much lower than much smaller raid-based queues. This was because if you were not in range to see a result it did not show up in your combat log. One side of the dragon would generally not see what was happening on the other side because it just didn't matter and the range at which results were shown was fairly low. This made early combat analysis tools like damage meters very inaccurate since the people tracking damage wouldn't be in range of much of what was happening.

    I raided extensively before PoP came out, like 3+ years worth of raiding and I remember the officers intentionally spreading out during a battle so that everything could be caught in one or more people's combat logs and they could manually piece it all together later on from the logs and figure out what DPS really looked like on a character by character basis.

  4. #44
    Community Member redoubt's Avatar
    Join Date
    Mar 2006
    Posts
    6,805

    Default

    I asked on the lama forum, but no dev input yet.

    How are they going to handle assassination? If procs are reduced, does that mean the double assassinate and chance at a triple assassinate are gone?

    What is the future of TWF? Many builds, mine included, work on procs. I don't take damage boost, I take speed boost to up my attack rate and get more procs. What is the future plan for builds like this? Or is the plan that they go away and one more style of play is eliminated?
    Should a reaper see me? I think Death itself should have to make a spot check when I'm rolling up behind him. -- Krimsonrane

  5. #45
    Community Member Artos_Fabril's Avatar
    Join Date
    Jan 2010
    Posts
    1,297

    Default

    Quote Originally Posted by redoubt View Post
    What is the future of TWF? Many builds, mine included, work on procs. I don't take damage boost, I take speed boost to up my attack rate and get more procs. What is the future plan for builds like this? Or is the plan that they go away and one more style of play is eliminated?
    Future plans are for games with a future.

  6. #46
    Community Member
    Join Date
    May 2013
    Posts
    1,879

    Default

    Quote Originally Posted by redoubt View Post
    I asked on the lama forum, but no dev input yet.

    How are they going to handle assassination? If procs are reduced, does that mean the double assassinate and chance at a triple assassinate are gone?

    What is the future of TWF? Many builds, mine included, work on procs. I don't take damage boost, I take speed boost to up my attack rate and get more procs. What is the future plan for builds like this? Or is the plan that they go away and one more style of play is eliminated?
    Just get in the van, Stan, there is no plan.

  7. #47
    Community Member
    Join Date
    May 2013
    Posts
    1,879

    Default

    Quote Originally Posted by KoobTheProud View Post
    This was because if you were not in range to see a result it did not show up in your combat log.
    Just to clarify the concept of a log. Logging, if one will, should have absolutely minimal to zero impact on throughput of a system. There are so many way to handle logging in a fire and forget methodology via messaging that the idea the log and even transmission of the log is what clogs the system brings us back to the first point that the engineering at criticals point in the system is far too single threaded, where it should have been, over the course of 15 years, converted to multi-threaded. The worst things chatty logs do these days is chew up memory on disk somewhere, and even that's hella cheap.

    We would not even be having this discussion if these choke points (which anyone with a sense for system arch could have seen coming on the inside) had been resolved the way arch choke points are supposed to be resolved. Customers most certainly wouldn't be having follow-up discussion about how a bunch of builds are going to be fixed after being forcibly broken not because gameplay balance issues, but because these people who get paid to push bits can't figure out how to logically balance a highly reasonable workload in a world where physical constraints are almost a null factor (it ain't like they are mastercard/visa, or doing crypto mining).

  8. #48
    Community Member grudgebear's Avatar
    Join Date
    May 2013
    Location
    Lithuania
    Posts
    140

    Default

    I get that mitigating proc effects will impact server performance.

    But how proc effects explain lag on HC server? Hardcore server shat itself from lag when it had around ~1k to 1.2k people online.
    First few days it is for sure that players there don't have much double strike and proc effects as on regular ones. Also the notion that Reaper points can cause server lag can be dismissed since people didn't have much of them either (not counting the initial loading lag when entering dungeons).

  9. #49
    Systems Designer
    Lynnabel's Avatar
    Join Date
    Jul 2016
    Posts
    3,250

    Default

    Quote Originally Posted by redoubt View Post
    I asked on the lama forum, but no dev input yet.

    How are they going to handle assassination? If procs are reduced, does that mean the double assassinate and chance at a triple assassinate are gone?
    I've actually answered this but for clarity, here's that post again and a more detailed answer. Assassinate's extra activations are a quirk of its hitbox and have nothing to do with doublestrikes or procs or really anything, it's just how the ability functions. Assassinate's potential for double and triple behavior was therefore unchanged by this. The part of combat that is changing is unrelated.

    Quote Originally Posted by Lynnabel View Post
    The Assassinate ability is completely untouched by this, just tested it out myself to be sure.
    Quote Originally Posted by grudgebear View Post
    I get that mitigating proc effects will impact server performance.

    But how proc effects explain lag on HC server? Hardcore server shat itself from lag when it had around ~1k to 1.2k people online.
    First few days it is for sure that players there don't have much double strike and proc effects as on regular ones. Also the notion that Reaper points can cause server lag can be dismissed since people didn't have much of them either (not counting the initial loading lag when entering dungeons).
    An important thing to remember is that what we're changing with regards to the combat flow is a concerted effort to address one singular type of lag from one singular source. We still have a laundry list of changes to make and lag sources to address. This one just happened to be very prominent from a player's perspective, and therefore we wanted to be sure that players could test it out on our preview server.
    Last edited by Lynnabel; 04-17-2021 at 10:57 AM.
    100% radical, enthusiasm enthusiast.

    "Have you tried preproccing feat directory?"

  10. #50
    Community Member Chai's Avatar
    Join Date
    Aug 2008
    Location
    Wisconsin, birthplace of D&D
    Posts
    27,794

    Default

    Quote Originally Posted by KoobTheProud View Post
    Seriously, you lost me at AA's. AA's did not exist until Luclin came out in 2002. The AA tree did not get large until much later and most of the early AA's were passive non-combat AA's that proc'd nothing but instead increased a baseline stat, resistance or a continuous effect that was not related to any active ability. The procs you're talking about in combat were minimal compared to the number of procs in EQ2 as it evolved.

    If EQ had procs at the level you suggest the combat queue would have just died, as the number of characters contributing was insanely large compared to any modern MMO.
    EQ did have all procs I suggested, and more. 2002 was only 3 years after launch in 1999. DDO is in its 15th year. Yeah we can count Luclin era when comparing.

    Quote Originally Posted by KoobTheProud View Post
    Another of the differences between EQ and more modern MMO's was the one you touched on about there being no raid interface. Frequently the number of players getting updates on damage in a given encounter was much lower than much smaller raid-based queues.
    This is due to actually using physics checks to determine proximity. Something DDO wanted to move away from adding more of.

    Quote Originally Posted by KoobTheProud View Post
    This was because if you were not in range to see a result it did not show up in your combat log. One side of the dragon would generally not see what was happening on the other side because it just didn't matter and the range at which results were shown was fairly low. This made early combat analysis tools like damage meters very inaccurate since the people tracking damage wouldn't be in range of much of what was happening.
    Here you are talking about physics checks and not procs. DDOs original lag pass turned alot of its physics checks into procs. This is why their issue is procs now. They traded one issue for another. Not wanting to do those physics checks to determine proximity as often as before meant having base some hits on the previous physics check, which is a proc.

    Quote Originally Posted by KoobTheProud View Post
    I raided extensively before PoP came out, like 3+ years worth of raiding and I remember the officers intentionally spreading out during a battle so that everything could be caught in one or more people's combat logs and they could manually piece it all together later on from the logs and figure out what DPS really looked like on a character by character basis.
    Again, this is physics checks you are referring to here, not procs. EQ did a physics check/tick/character to determine proximity to determine if you were in range of other players DPS/effects/buff spam.

    This has no relation to DDOs issue as this can be turned off in DDOs interface. If this was the cause of lag telling us to turn it off (or having it off by default) would be the resolution.

    Quote Originally Posted by KoobTheProud View Post
    The procs you're talking about in combat were minimal compared to the number of procs in EQ2 as it evolved.
    Not true. The systems were fairly similar. I do see why you think so though. You are thinking of "procs" as effects only, while this is clearly not what a proc is in terms of how the game is coded.

    Take for example the way TWF in DDO used to work compared to how it works now.
    Then: Used to be a physics check to determine proximity and facing on every main and off hand swing. As physics checks added up, more lag occurred.
    Now: Physics check per main hand swing with the offhand being a proc based on a percentage, which you can increase through taking feats and AP. If you were in range for the main hand swing you are also considered to be in range for the offhand attack that procced off that same main hand swing. Less physics checks = presumably less lag from that specific source of lag. (at leas tthats what we were told in the original lag pass).
    Last edited by Chai; 04-17-2021 at 11:32 AM.
    Quote Originally Posted by Teh_Troll View Post
    We are no more d000m'd then we were a week ago. Note - This was posted in 10/2013 (when concurrency was ~4x what it is today)

  11. #51
    Bounty Hunter slarden's Avatar
    Join Date
    Apr 2011
    Posts
    12,489

    Default

    Quote Originally Posted by Lynnabel View Post
    I've actually answered this but for clarity, here's that post again and a more detailed answer. Assassinate's extra activations are a quirk of its hitbox and have nothing to do with doublestrikes or procs or really anything, it's just how the ability functions. Assassinate's potential for double and triple behavior was therefore unchanged by this. The part of combat that is changing is unrelated.
    How does the triple assassinate work exactly? Prior to the assassin pass several years ago I used to be able to murder as many as 5 enemies with assassinate + twitching, but something with the pass either intentionally or unintentionally removed that and I never saw more than 3 after that - and I am no longer able to increase the # of targets with twitching. I always assumed the 3 assassinates were form main-hand strike, off-hand strike and main-hand double-strike.
    DC Warlock Reaper Build (U48)
    Max DC Illusionist Reaper Build (U48)

  12. #52
    Community Member
    Join Date
    May 2013
    Posts
    1,879

    Default

    Quote Originally Posted by Lynnabel View Post
    An important thing to remember is that what we're changing with regards to the combat flow is a concerted effort to address one singular type of lag from one singular source. We still have a laundry list of changes to make and lag sources to address. This one just happened to be very prominent from a player's perspective, and therefore we wanted to be sure that players could test it out on our preview server.
    What hasn't been answered is why one singular source of lag drained resources from everyone else playing the game? Not why, as in how, why as in what is the point for allowing this except as a poor design choice made eons ago.

    Why were resources pooled so poorly as to not be insulated from being the entire pool being stolen by one particular singular instance? Modern system software design has many methods for enforcing soft and hard limits on users from cannibalizing system resource allocation to prevent the abdication of all common resources by a single actor (or in this case a single raid).

    Wouldn't the first step to solution be to stop the theft of other instances needed resources by over-proc'ng raid groups rather than chopping everyone's proc's off at the knees? This would seemingly (by your own definition of the problem) "address" lag for all of us not in R10 proc-a-palooza raids which wouldn't change our customer experience at all, nor necessitate testing it for you (since you could clearly internal test such limits).

    The natural second step would then be dealing with either the raising throughput or proc limiters on proc'nig within a raid instance itself, would it not?

  13. #53
    Community Member Chai's Avatar
    Join Date
    Aug 2008
    Location
    Wisconsin, birthplace of D&D
    Posts
    27,794

    Default

    Quote Originally Posted by myliftkk_v2 View Post
    What hasn't been answered is why one singular source of lag drained resources from everyone else playing the game? Not why, as in how, why as in what is the point for allowing this except as a poor design choice made eons ago.

    Why were resources pooled so poorly as to not be insulated from being the entire pool being stolen by one particular singular instance? Modern system software design has many methods for enforcing soft and hard limits on users from cannibalizing system resource allocation to prevent the abdication of all common resources by a single actor (or in this case a single raid).

    Wouldn't the first step to solution be to stop the theft of other instances needed resources by over-proc'ng raid groups rather than chopping everyone's proc's off at the knees? This would seemingly (by your own definition of the problem) "address" lag for all of us not in R10 proc-a-palooza raids which wouldn't change our customer experience at all, nor necessitate testing it for you (since you could clearly internal test such limits).

    The natural second step would then be dealing with either the raising throughput or proc limiters on proc'nig within a raid instance itself, would it not?
    I feel similarly. When investigating how to resolve lag issues years ago, they discovered an overload of physics checks were a major issue, so decided to turn some of those into procs. Now procs are the issue. The explanation we were afforded was that procs require less overhead than physics checks do. Did anyone in that era investigate if the solution of increasing the procs was also going to be an issue? Like - how bad would procs need to get in order to cause the same amount of overhead thresholds which were being avoided by tuning down physics checks. The technical debt inherited here could have been avoided if a complete due diligence would have been done on that situation.
    Quote Originally Posted by Teh_Troll View Post
    We are no more d000m'd then we were a week ago. Note - This was posted in 10/2013 (when concurrency was ~4x what it is today)

  14. #54
    Community Member Oxarhamar's Avatar
    Join Date
    Sep 2009
    Posts
    6,523

    Default

    Quote Originally Posted by Chai View Post
    I feel similarly. When investigating how to resolve lag issues years ago, they discovered an overload of physics checks were a major issue, so decided to turn some of those into procs. Now procs are the issue. The explanation we were afforded was that procs require less overhead than physics checks do. Did anyone in that era investigate if the solution of increasing the procs was also going to be an issue? Like - how bad would procs need to get in order to cause the same amount of overhead thresholds which were being avoided by tuning down physics checks. The technical debt inherited here could have been avoided if a complete due diligence would have been done on that situation.
    I think that is not what they have said it was more about the number of calculations than just procs & reduced those by instead doubling damage for a double strike instead of running 2 sets of calculations for 2 attacks reduces the number of calculations.

    Procs are more of less being reduced by proxy of less attacks.

  15. #55
    Community Member
    Join Date
    May 2013
    Posts
    1,879

    Default

    Quote Originally Posted by Chai View Post
    I feel similarly. When investigating how to resolve lag issues years ago, they discovered an overload of physics checks were a major issue, so decided to turn some of those into procs. Now procs are the issue. The explanation we were afforded was that procs require less overhead than physics checks do. Did anyone in that era investigate if the solution of increasing the procs was also going to be an issue? Like - how bad would procs need to get in order to cause the same amount of overhead thresholds which were being avoided by tuning down physics checks. The technical debt inherited here could have been avoided if a complete due diligence would have been done on that situation.
    We know they didn't. Otherwise they could have seen this coming updates ago and planned for the day the pipe got too small to handle the flow.

    Thus, keeping with trend, instead of looking at viable solutions of "paying off" the technical debt, they're opening a new credit card and doing a balance transfer. They'll soon run up the limit on their old card again because they've not yet bothered to change their profligate coding habits.

  16. #56
    Community Member AbyssalMage's Avatar
    Join Date
    May 2011
    Posts
    3,803

    Default

    Quote Originally Posted by KoobTheProud View Post
    EQ had far fewer procs on weapon hits than later games. They had far fewer abilities on the stack from each player also. It really was an auto-attack meta with the occasional proc or ability (like kick, slam or backstab) occurring in a fixed rotation.

    EQ2 had a load of procs and abilities by the time they were 11 years out and they went back and did basically just what SSG is proposing to do now. The effect was an end to crippling raid and group lag and a mile marker on the road to a largely lag free game. Other things had to be fixed also, like the way that effects and animations interacted but the lion's share of the solution was in keeping the combat queues from stacking up to the point of delayed execution and reporting.
    Actually I can attest that EQ had multiple Proc's on hit built into the game. Probably on par to DDO currently has. Rogue and Ranger were the natural two builds for this and level 51+ with AA's was when this build came into its own. Weapons that were inferior statistically in damage/delay (a little D&D 2nd Ed nostalgia) became superior thanks to the proc.

    But in your defense I do remember them scaling back proc's around the time I left because it interfered with Raids which is what the game began full on catering too. Group play was nothing more than background to raids.
    Quote Originally Posted by hp1055cm View Post
    They have been tweaking the game since I started and often I disagree with them. They focus on wrong stuff, over or under compensate and abandon too much stuff. Every once in awhile they get something right, if only temporarily.

  17. #57
    Community Member kanordog's Avatar
    Join Date
    Jan 2013
    Location
    Europe
    Posts
    1,659

    Default

    Quote Originally Posted by redoubt View Post
    I asked on the lama forum, but no dev input yet.

    How are they going to handle assassination? If procs are reduced, does that mean the double assassinate and chance at a triple assassinate are gone?

    What is the future of TWF? Many builds, mine included, work on procs. I don't take damage boost, I take speed boost to up my attack rate and get more procs. What is the future plan for builds like this? Or is the plan that they go away and one more style of play is eliminated?

    The plan is not to have builds they don't like. Some builds are especially hated. Has little to do with lag.

    No, not paladin.
    You nerfed my monks, throwers, dailies and alchemists.
    I hardly play anymore, found a better hobby.
    Thank You!

  18. #58
    Community Member
    Join Date
    May 2013
    Posts
    1,879

    Default

    Quote Originally Posted by Oxarhamar View Post
    I think that is not what they have said it was more about the number of calculations than just procs & reduced those by instead doubling damage for a double strike instead of running 2 sets of calculations for 2 attacks reduces the number of calculations.

    Procs are more of less being reduced by proxy of less attacks.
    Yes, and when "less attacks" eventually fails as a solution with the bloated sacks of hp that necessitated the proc stacking in the first place, we'll just get one swing and either 0 dmg or 1,000,000 dmg, lol.

    There is also two parts to a proc, at a minimum. There is the calculation regarding the proc itself (does it fire, does it not), and then there's the effect of the proc which only has a cost if the effect fires. They haven't clarified which part is the problem. The first part always happens, but the second is obviously a subset of the first.

    Regardless of their answer, there's no justifiable software design reason that my proc's steal your instance's resources, or vice versa. That's just poor resource allocation methodologies which should be re-worked.

  19. #59
    Community Member redoubt's Avatar
    Join Date
    Mar 2006
    Posts
    6,805

    Default

    So is it your intent for builds that use procs to go away?

    For example, a ranged shiradi character might use:
    1. Stay frosty to apply a slow and do some extra damage. You are making the damage work correctly, but losing the extra chance at a slow.
    2. Pin - only one chance to go off instead of two.
    3. Otto's whister - only one chance to go off instead of two.
    4. Nerve venom - chance of the proc now half as well.
    5. Metoric Star ruby for KD proc.

    Another example is a TWF assassin:
    1. Balanced attacks as a twist. How are you accounting for half the chances of this proc'n? This is a light armor low defense type of build that must get very close to function. Some sort of CC is very important.
    2. Improved deception. Less hits, less procs. How are you accounting for this ability?
    3. The vistani tree has rapid slash which boost doublestrike.
    4. The vistani tree also has an alacrity action boost. Its pretty clear that high rate of attack and procs are central to the original design of this. How are you accounting for the loss of this?
    5. With two daggers I'm currently using 2 snow rubies for CC. One instakill ruby and one meteoric star ruby for KD affect. 75% of what I slotted was for CC.

    I am happy you are accounting for the damage, but this is a major debuff to the CC abilities and as a result the survivability of such a builds.

    It really sounds like you just want these things to go away, yet you just introduced a whole bunch of new augments that are proc based. Did you expect people to not use them?

    In the case of something like the snow rubies, they require the mob to roll a 1 for it to work. I would suggest you scale the save DC on these to go with the level of the weapon. Maybe 20+(weapon level *3).
    For proc like the meteoric star ruby, double the chance of it knocking mobs down.

    This is a HUGE AND SWEEPING change you are making. There are a lot of abilities and items that this affects. It has the potential to eliminate and entire playstyle. (Just a month after you killed a different one.)

    Years ago, the company nerfed TWF in the name of lag fix. It did not fix it. Now here we are again. Also, the procs we are talking about have been in the game since before the really bad lag started less than a year ago.
    Should a reaper see me? I think Death itself should have to make a spot check when I'm rolling up behind him. -- Krimsonrane

  20. #60
    Community Member Oxarhamar's Avatar
    Join Date
    Sep 2009
    Posts
    6,523

    Default

    Quote Originally Posted by redoubt View Post
    So is it your intent for builds that use procs to go away?

    For example, a ranged shiradi character might use:
    1. Stay frosty to apply a slow and do some extra damage. You are making the damage work correctly, but losing the extra chance at a slow.
    2. Pin - only one chance to go off instead of two.
    3. Otto's whister - only one chance to go off instead of two.
    4. Nerve venom - chance of the proc now half as well.
    5. Metoric Star ruby for KD proc.

    Another example is a TWF assassin:
    1. Balanced attacks as a twist. How are you accounting for half the chances of this proc'n? This is a light armor low defense type of build that must get very close to function. Some sort of CC is very important.
    2. Improved deception. Less hits, less procs. How are you accounting for this ability?
    3. The vistani tree has rapid slash which boost doublestrike.
    4. The vistani tree also has an alacrity action boost. Its pretty clear that high rate of attack and procs are central to the original design of this. How are you accounting for the loss of this?
    5. With two daggers I'm currently using 2 snow rubies for CC. One instakill ruby and one meteoric star ruby for KD affect. 75% of what I slotted was for CC.

    I am happy you are accounting for the damage, but this is a major debuff to the CC abilities and as a result the survivability of such a builds.

    It really sounds like you just want these things to go away, yet you just introduced a whole bunch of new augments that are proc based. Did you expect people to not use them?

    In the case of something like the snow rubies, they require the mob to roll a 1 for it to work. I would suggest you scale the save DC on these to go with the level of the weapon. Maybe 20+(weapon level *3).
    For proc like the meteoric star ruby, double the chance of it knocking mobs down.

    This is a HUGE AND SWEEPING change you are making. There are a lot of abilities and items that this affects. It has the potential to eliminate and entire playstyle. (Just a month after you killed a different one.)

    Years ago, the company nerfed TWF in the name of lag fix. It did not fix it. Now here we are again. Also, the procs we are talking about have been in the game since before the really bad lag started less than a year ago.
    My thinking is increasing the effectiveness of the procs as many procs have been nerfed or increased chance.

    However if we see a buff to balance the nerf is yet to be seen
    Last edited by Oxarhamar; 04-17-2021 at 05:46 PM.

Page 3 of 6 FirstFirst 123456 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

This form's session has expired. You need to reload the page.

Reload