Howdy, Stranger!
Categories
- 6.2K All Categories
- 3.1K Everything Achaea
- 1.5K North of Thera
- 26 Archives of the Terraformer
- 257 The Matsuhama Arena
- 885 The Golden Dais of Creation
- 299 The Scarlattan Theatre
- 149 The Blank Canvas
- 2K Getting Help
- 412 General Questions
- 258 Quick Class Questions
- 1.3K Tech Support
- 313 Client Help
- 486 Curing Systems and Scripts
- 841 Off-Topic
- 255 The Wander Inn
- 586 The Universal Membrane
- 298 Class Discussions
- 298 Individual Class Sections
- 20 Alchemist
- 9 Apostate
- 30 Blademaster
- 9 Depthswalker
- 14 Druid
- 4 Infernal
- 20 Jester
- 19 Magi
- 34 Monk
- 11 Occultist
- 8 Paladin
- 7 Priest
- 29 Runewarden
- 18 Sentinel
- 26 Serpent
- 20 Shaman
- 9 Sylvan
Server-Side Curing: Working As Intended?
There have been issues noted with variability in time of curing different afflictions (standing taking far longer than curing paralysis for example) and curing times up to 250ms for some. This thread is for discussing those perceived issues, and to potentially have some transparency from @Makarios @Tecton.
@Ernam no more derailing combat logs you rascal.
1
Comments
Since I suspect this is a bug, I would assume it will be fixed soonish. However, since now there's a thread, I would like to make my case for lowering the delay considerably. I think 40-50ms would make sense.
My primary justification for this is that this is the latency of a significant portion of the playerbase. (yes, the low end, but that's the point)
1) If the purpose of the delay is to level the playing field, then leveling it to something considerably worse than what a lot of people are getting using client-side curing, then it is failing at its purpose. @Strata still gets markedly better/faster curing than I do, purely because he happens to live closer to IRE's ISP. If the playing field is to be leveled, then the delay should match what people CAN achieve without using server side curing.
2) Using server curing is actually going to hinder anybody whose latency is below the delay, thus making it somewhat silly to use. For example, if I'm getting an average latency of 60ms, even a 125ms delay would be considerably worse than just using SVO, and curing 60ms late, vice 125ms. Currently, it's dumb for anyone with under 250ms latency to use server curing.
3) While this technique is a little situational, people not using server curing can easily send commands early to have them execute in signifantly less time than their latency would normally permit than triggering them off of the balance recovery message. For people with latency >100ms this is a pretty safe and useful method. (which does have its downsides, so has to be used intelligently) This obviously can't be done with serverside, at all.
The other argument to be made here is that 250ms (even 125ms) has some pretty significant combat balance implications. With even a cursory look at some of the standard combat strategies of most classes, it's plain to see that a 250ms delay on every single curing / defense command is going to have a pretty massive impact on combat balance.
Two of the most obvious examples are vivisect and venomlocking. With vivisect, a delay of 250ms adds a half-second to every single limb break, and also adds a half-second to every epteth/epteth DSL. A limb break with epteth/epseth takes a full second longer to cure than it should, because all four salve applications get an extra 250ms delay thrown on the front end. This should make it pretty obvious to anyone familiar with vivisect strategies that the delay does more than impact this combat strategy, but it downright breaks it.
Healing against affliction based classes is also massively impacted, as if you look at the delay as essentially "extending" the balance of each cure, you add a 16% delay to herbs, 20% delay to mending/caloric/epidermal, a 10% delay to focus, and a 250ms delay on otherwise instant abilities like tree tattoo, insomnia, and standing.
You're also 2.1% less tanky (HPS), thanks to delayed sipping/moss. That's slightly more than what you'd get from a sip ring upgrade.
Look at this from an artefact perspective. What would someone pay to have every single balance increased by these figures? Because for someone using serverside curing who has a 30ms ping, you get them for free... by just not using server-side.
Whatever latency server-side curing emulates, its better than my .328 - .500 latency
Well, it's definitely not that high for me, to my experience. I usually get something around 100ms or a bit more, but I haven't really tested that extensively. It's definitely faster than I can cure client-side, in any case.
→My Mudlet Scripts
As for afflicting classes, having guaranteed curing on non-masked afflictions exactly on herb balance would be a significant nerf (probably). Though adding the queuing system didn't seem to make people complain about afflicting classes more (even though it increased their attack rate by their latency) so maybe I am off on that point.
That reminds me, I still forgot to start using the queuing system for my offence.
→My Mudlet Scripts
It was recently changed. It's a fixed 225-250ms on everything now. Applies to every action performed by server curing, to include defense keepup.
Everyone understands why they put the delay in, and I completely agree with you on your point here. However, nobody is saying to get rid of the delay. What I'm saying is to make the delay equal to what people with good internet can expect to see for latency. For the logic behind this, see my previous post.
It's not a fixed 225-250 ms for everything. That's not correct information.
That being said, I do have a lot of evidence to support server-side curing having various buggy aspects that affect the latency times received. I may make a post later explaining more thoroughly but don't really care enough atm. Like I said in the other thread, if you study how it works closely, it's pretty easy to pick out some broken/buggy patterns with it.
Here's a couple of examples:
Standing takes 230 ms to cure for me almost everytime(90% or more of the time). Every 5-10% of the time it'll do it quicker.
Paralysis cures for me in about 15 milliseconds almost everytime(90% or more of the time). Again, there's a very rare outlier here, but it's almost always 15 milliseconds.
Another interesting fact is that all my curing times are always either 15 ms or 230 ms. There's never anything in between.
Good internet where though? I could see it justified for average latency across the US for instance, but I am in Australia on the best internet I can get and I am regularly at 350-400 ms. If they reduced the delay, it is nothing but good for me since I use the server side anyway, but the lower the delay the closer to mandatory it becomes for more people.
Most classes aren't balanced around perfect latency anyway. The closest I can think of is old school sentinel axe stun locking where it was impossible for someone with a highish latency to survive against someone with a super low latency. Other than that, classes are balanced with a reasonable expectation of lag in their offense, otherwise, where is the huge outcry that Class X is impossible to live against unless you have perfect, zero latency curing?
Here's a log displaying the trend that I gave an example of. I just took this log, but I tested it yesterday as well and got the same results.
http://pastebin.com/HLzZ9uRQ
Notice how all the paralysis cures except one take exactly 15 ms. All the stands take 230 ms. This is a small sample size in the log, but I've been testing this for a couple days and have done well over 50 tests of each, only to get the same results.
@Accipiter
Again, I already said all this before, but the vast majority of the playerbase is in the US, and a big chunk of those players get between 50-100ms latency. Many people report averaging 30-40ms latency regularly.
If the playing field is to be leveled, it should be leveled at that amount of real/simulated latency, because that's the delay that combat balancing should consider, since that's the upper limit of what is possible, and since that's what many people's actual delay on curing/defense commands is. If the server-side delay was 30ms, I'd be equal to someone like @Strata, who is relatively close to IRE's ISP. Even if the delay was shortened to 125ms, why should client-side people with a ping of 30ms get to cure 95ms faster than me? That's why I recommended changing the delay to 50ms, among other reasons.
On a completely different note, I want to address something you said earlier. You mentioned that having a delay was a good balance for server-side seeing masked afflictions. Others have also mentioned that it's a good balance for anti-illusion.
1) Masked illusions have all been fixed to not be seen until diagnosed via Diagnose or symptoms.
2) The impact of server-side curing was addressed and balanced out via classleads, resulting in an extensive list of significant upgrades to serpent affliction rate and versatility. The Flay change alone is more valuable to serpent than illusions ever were. (People just may not know this yet).
3) There are still many, many problems with server-side curing, the most obvious and painful of which being that when using it, you have no way of knowing what afflictions you have at any time, without a high specialized client-side system. SVO and Omni both require heavy modification to even come close to tracking afflictions properly (something Vadi has stated he's working on). There are many other severe drawbacks to serverside curing, which I won't get into here, but they more than make up for any strategic gain due to its anti-illlusion side-effect.
4) A server-side delay as a means of balancing out its anti-illusion is silly, since the delay negatively impacts curing against all classes, not just illusion-users. A perfect example of this is its massive impact against apostates and infernals.
I just want known afflictions to be sent via gmcp. Allow players to enable/disable the gmcp data and make it disabled by default. If they do that as well as look into the imposed latency and see if it needs to be cut down to 50ms or so (I think it should be if not), then server-side curing will be in awesome shape. Not having instant access to known afflictions as they occur is a huge drawback because anyone who wants to benefit from server-side curing for higher "tier" fighting has to track all of these things client side (with anti-illusion logic). Folks like @Nemutaur and @Jhui might disagree with this, but seriously... What is the point of server-side curing if I have to maintain over 100 affliction lines client-side solely to be able to manipulate server-side curing priorities and such in real time?
@ernnam The question we really need answered then is this: Is the server curing system meant for new players just getting into the game, or is it meant to be a viable alternative for all levels of combat.
If it is the former, then the latency mimicry doesn't really matter, because new combatants won't be in situations where they would of lived if only they system cured them fractions of a second faster.
If it is the latter, then yes, the mimicry should be tuned down to a point where it isn't a detriment for many players to enable it. Average ping for US players would probably be a good starting point, but if you are right that the majority are in the US anyway, then it should already be closer to that than if players were evenly spread globally.
@strata I have to agree with that, the biggest hurdle that discouraged me from building my own system was always the huge task of finding the affliction lines. Sending them via gmcp means far less OOC work scouring logs, hoping to find someone of a set class that will be nice enough to afflict you with everything they can, entering ffa's you know you have no chance in on the off chance someone will hit you with something new, ect.
The variability is the problem right now.
Speaking from personal experience, anecdotal statistics are actually very accurate.
→My Mudlet Scripts
@Accipiter - you're missing my point. Average latency doesn't matter if you're trying to make the game fair. There are always going to be people above and below average.
With server curing having a fixed delay, it is unwise to use it for everyone that's under the average (50% of the playerbase). If they switch to server curing, they're going to cure / react significantly slower.
Everyone over the average latency is still at a significant disadvantage, even if they use server curing. If the "average" latency that you're referring to is 125ms (pretty realistic), and that's what server curing's artificial delay was set to, then you're still curing slower than half of the game. (who is all below average, and therefore shouldn't use server curing).
tl;dr / summary
Delay needs to be set to the low end of the latency spectrum, not the average or high end. Anything else simply doesn't make sense, for several reasons I've described so far.
Set the delay to 40-50ms and everyone is equal. Client-side and server-side will all have the same curing speed. The only people who would be slower are people with high latency that choose to use client-side curing (which has the ability to pre-send commands based on ping, in many cases). Those people would have the same latency they're used to seeing currently using a system like SVO, and would notice no change.
Dude, your posts have nothing to do with what this topic is about.
Furthermore, the delay is already considerably less than most players pings for some stuff - See my paralysis log of it curing in 10-15 milliseconds the vast majority of the time.
The delay doesn't need to be raised or lowered, it just needs to be fixed to work correctly.
Consistency at a 125ms curing rate.
There are enough significant disadvantages to playing with a medium to high latency connection, without having to deal with slow curing. I see absolutely no problem with leveling the playing field and giving everyone access to the same fixed rate delay on automatic curing, be it from server or client system. To achieve this, it has to be 50ms.
If this is indeed a bug, and the 250ms test results we're seeing are not intended, then fixing that will definitely be a step in the right direction. Either way, when fixed, I hope the game design staff truly consider the reasoning I've put forth on this. I've played a newbie, and I've played a top-tier fighter. I've played super high and super low latency. I don't see any reason whatsoever not to set this delay thing to 50ms and call it a day. If anything all it'll do is get more people using it, which is a good thing for everybody.
Hrm, I couldn't say why you might get different results for different afflictions. If you can ignore it, its handled the same as all other ignorable afflictions, so the one affliction that is handled -slightly- differently is being asleep-you would likely see this being slightly faster (and when I say that, I'd actually be surprised if you could tell) due to it not needing to run curing logic (since you can always wake).
A few things to take into account here, though.
The system isn't meant to completely level the playing field: we can't do that. There will always be someone who can attain a real life ping faster than something we can reasonably have running constantly on the scale of server curing without always having to worry about performance down the line. The closest thing I could really think to say there is its meant to make the gap far less relevant (fighting on a 100 ms ping against someone on a 40 ms ping is far more reallistic than fighting the same person on a 400 ms ping, etc ). Will take a look to see if there's anything that could account for certain afflictions being cured faster, though.
As I've said in another thread, the tick hasn't changed since implementation (and neither has any of the back end really - just convenience additions and symptoms being added).
Finally, and the point that needs to be stated concretely I think. Server curing isn't meant to kill client side systems. Its meant to be a viable alternative for people who don't want to use one. Which it is.
// Have not read above post at the time of posting this, got ninja'd.
The reason it was [supposed] to be set to 125 ms is so that people would still be able to make their own client-side curing if they wished to. If I'm running off 100 ping on my client-side curing, and server-side is working at 50, then I'd feel pressured to change. Server-side curing was developed to be average, not exceptional. It's there to cover the basics, not to be exceptional. If they released server-side curing with super low ping, then they alienate everyone that's currently using client-side curing and doesn't have super low ping. Making the server-side curing simply 'average' was the answer to that.
That subject of conversation still has very little to do with what we're talking about though: IS SERVER-SIDE CURING FUNCTIONING CORRECTLY?
I say: No. And I'm the only one that's posted any logs or evidence whatsoever of any real testing. So how about someone else with a decent connection and some time stamps gets to work. And I may round up some more logs later of various server-side curing stuff.
I'm not sure I understand what you're saying there. There's still many things that need to be handled on the client side (class-specific or artefact-based curing abilities, pipe re-lighting, lock queues, tree scenarios, etc.) and client side scripts will always do this stuff better. Why not help (as in... definitely NOT kill) client side scripts do those things better by adding known afflictions to gmcp? What is the specific reason for not doing something that makes so much sense?
I agree that fighting against 50ms ping with 100ms ping isn't the end of the world, so that'd be more or less fine. However, since we're consistently seeing delays much higher than 100ms, I have to assume something is wrong.
And just in case I came off as pessimistic, let me repeat my earlier comment. I love using serverside curing, and I'm really impressed at the speed and complexity of the fixes and additions to it. Thanks for all the work that has gone into it and the continued tweaks to make it better for everyone, @Makarios, and team.
What, I completely agree with this as I stated when it came out.
Regarding keeping afflictions out of gmcp:
The one argument I can see is that it would give those who already have a great ping an even greater advantage than currently.
As it is, people with a bad ping have an incentive to switch to server-side curing, due to its greater speed and illusion-proofness.
People with a good ping have the choice to make the switch too, except that choosing the server-side option will cost them some speed in favour of being illusion-proof. So all in all, it evens the field somewhat.
With gmcp afflictions however, the fast-ping people would gain the best of both worlds, keeping their extreme speed and adding safety from illusions on top, making their curing distinctively better than previously, and better than anyone else's.
→My Mudlet Scripts
The Primary reason for the implementation of server-side curing was plain - to make it easier for novices to get into combat without needing to find/buy client side curing. With that said, while GMCP is amazing, it isn't exactly simple to work with, for someone without at least a moderate amount of coding experience.
This is why in lieu of (or in addition to) GMCP outputs, a hard-coded output method would be considerably better for making the system easier to use, with or without client-side assistance.
Pipe handling is something that could be easily added, however anything involving "scenarios" is going to be need to be done on the user end. This in all likelihood would be very difficult to code in and use, and would also be pretty taxing on the server (each player running an extensive list of 'if' checks on every single status change would add up).
Thus, I think the best solution is to simply offer an easy output of afflictions that you "know" that you have. This could be accomplished with a second prompt line, or a simple output command (SHOW afflictions known). With this tool on hand, even a beginner could generate scenario-based active curing and priority swapping systems, without having to have extremely complex affliction tracking and anti-illusion to compliment server curing.
Example:
From an output like this, a simple trigger to check for combinations of afflictions could be used to handle scenario-based reactions like tree tattoo, fitness, restore, and so on.
Without this functionality, no matter what server curing can do, it will require a massive client-side system to track afflictions and handle active curing.