Fighting in lag

For those of us that live overseas from the servers, I was wondering if anyone had some tips or tricks as to fighting, or attempting to fight in lag.

So far, I've found several things system related. Mainly, my temptimers never caught diagnose or def, and I could not figure out why. Turns out my lag was too bad for the length of the trigger, so I had to go through and extend all my temp timers in anything trigger related.

I've also found that keeping things outrifted help a lot, and cut down a lot of time. For fighting I just learned how to put a "stand" or other mostly useless option in front of multiple inputs, as it makes the last set of multiple inputs group together rather than act seperately.

Also, is the sendall command in mudlet more useful than doing multiple send commands?

Anything that might help cut down a bit of time when it comes to fighting in bad lag would be appriciated.
Replies the scorpion: "It's my nature..."

Comments

  • MishgulMishgul Trondheim, Norway
    when you get used to it, you can pretend you are psychic and hit things before they happen and watch your lag compensate and you do things at a good time, and then stroke your ego like the bamf you are.

    I fight very defensively though, eg i'll illusion shields/rebounding to force razes, daegger hunts because everyone shields on daegger hunt  when i know something is about to happen that I can't handle on my super slow ping, and passive curing helps a lot too.

    -

    One of the symptoms of an approaching nervous breakdown is the belief that one's work is terribly important

    As drawn by Shayde
    hic locus est ubi mors gaudet succurrere vitae
  • Temp triggers are a pain. It helps to make their times variable for lag. Instead of 2 seconds, make it 2 seconds + variable.

    Then set variable to 0 in no lag, 0.5 seconds in light lag etc.

    Really helps with that. Other than that chase balance when you can. Helps in some cases.

  • Aepas said:
    Also, is the sendall command in mudlet more useful than doing multiple send commands?
    No, the results are identical. Use whatever you prefer visually.
    Arador said:
    Temp triggers are a pain. It helps to make their times variable for lag. Instead of 2 seconds, make it 2 seconds + variable. Then set variable to 0 in no lag, 0.5 seconds in light lag etc. Really helps with that. Other than that chase balance when you can. Helps in some cases.
    Remember that you can even get your current latency in Mudlet with getNetworkLatency(). You could use that for this variable.

    There isn't really overly much you can do against lag, except doing what Carmain said and staying relatively defensive. Chances are you won't be winning fight by pure speed and reflexes, so you need to compensate by thinking more strategically.
  • Idea server side 200ms lag for everyone - the latency individually.

    Hides in a corner.
  • Perma retardation in every room!
  • Things I found to be useful for me:
    Increase the timers.
    Not sending useless command.
    Not spamming commands.
    and what Mishgul said.
  • hm, I had no idea that was a real thing. How often does it update? My lag recently has been around .6-.7, and very random at that. Does it update with every new action?
    Replies the scorpion: "It's my nature..."
  • It contains the time between the last thing you sent to Achaea and the next line you received from Achaea after that.
  • That can mess you up if, for example, you just hit ENTER (for a blank prompt), which is faster than other commands and it sets your tempTimer time really short. On every prompt, I do something like the below to track my average latency:

    latency = ( (latency * i) + getNetworkLatency() ) / (i+1)
    i = i+1

    ...where "latency" and "i" are variables initialized at 0 when you log in. And then use the latency value in your tempTimer, preferably with some multiplication factor (I use 1.5*latency).
  • Even hitting enter for a blank prompt will never get you a faster time than your current ping though. But yeah, I recommend smoothing out the values by averaging them a bit too. Personally, I just write the current latency into a table at every prompt which contains the last 5 latencies. Then I just take the average between the five.

    That doesn't give as smooth values as Tirac's, but it will react a bit better to changes in your latency during your session. Which you prefer may depend on what you use it for, as well as how stable your ping is.

  • Daeir said:
    Iocun said:
    Even hitting enter for a blank prompt will never get you a faster time than your current ping though. But yeah, I recommend smoothing out the values by averaging them a bit too. Personally, I just write the current latency into a table at every prompt which contains the last 5 latencies. Then I just take the average between the five.

    That doesn't give as smooth values as Tirac's, but it will react a bit better to changes in your latency during your session. Which you prefer may depend on what you use it for, as well as how stable your ping is.
    I would up that to 10-15 samples and you'd probably have the best sort of compromise for this kinda thing. Small samples are more prone to Type I errors statistically (aka an inordinately large effect on the average due to 1 packet spike which would happen fairly often on a normal connection), so a sample of 5 pulls from your recent latencies is going to be potentially be 15-20% out of margin if you only get 1 bad pull. What Tirac has is best, in all honesty, since a larger sample size is better and Type II errors aren't really applicable for something so binary.
    Depends on how you're using it, though. If you're using the latency in a way that there's some small chance of, say, consuming a curative before you get balance back, you might want to err on the side of weighting spikes more heavily.
  • Well, I actually don't use the average value all that much. I have some applications where I use the minimum of the five last values, for some balance chasing and such, and it works well for that purpose. I don't usually modify my timers according to my latency at all.
  • You should be really careful about relying on getNetworkLatency() for things like this. It merely provides a representation of the latency when the -last- command was sent and as such will not be in line with current latency.

    Daeir's suggestion is not a bad one.
    Innovate or Die.
  • Caeya said:
    You should be really careful about relying on getNetworkLatency() for things like this. It merely provides a representation of the latency when the -last- command was sent and as such will not be in line with current latency.

    Daeir's suggestion is not a bad one.
    That shouldn't be too much of a problem unless your latency is quite unstable as well as large, though, right?

    Not sure I really get @Daeir's suggestion. Maybe it depends on what the timer is doing, but if you're adjusting the time to wait before sending a command to account for latency, wouldn't you want to be subtracting the latency (or half of it, maybe) rather than adding it? Adding it seems like simulating extra latency.
  • edited December 2012
    Well, yeah, but there is simply no way of getting the current latency, because the moment you can measure it, it's already a past latency. In a combat situation you'll be sending so many commands in a short timespan however that a somewhat smoothed recording of getNetworkLatency() tends to get reasonably close to reality.

    The major problem with taking -all- samples into account (as in Tirac's example) is that if you don't just have a stable ping with some random spikes, but actual long-term changes in your ping, it can take a very long time to adapt. Depending on how you connect to the internet and whether you sometimes make changes to this connection mid-game, this may or may not be relevant. This is why I believe it's almost impossible to give a method here that will be suitable for all players equally.
  • Yeah, the best you are going to get is really to just take the average from x number of prompts and set your time to that.

    Here, I got bored: Clicky.
    Innovate or Die.
Sign In or Register to comment.