SVO + SPAM = death, frozen mudlet, mudlet dies

Rangor

Hi,

Like before. I'm still struggling with SVO in spammy environments. I've tried a number of things to solve it. Disabling all NDB scripts/aliases/triggers, mudlet settings like compression. Reinstalling. Deleting the backups of the profile.. but it still dies in massive spam.

I am experiencing this when using mind sapience on people who use wundersys, or serverside curing. The amount of spam generated by their priority swapping is massive.

The symptoms are - Client lagging, cmd bat freezing so that I cannot even type in characters until the spam stops, then whatever I typed gets sent through, in worst cases mudlet client dies and I have to end the process to restart it.

What I've done to identify the source:
Test with everything installed - Mudlet freezes (can't type) and lags, recovers when spam stops.
Test with clean mudlet - Flawless execution.
Test with SVO uninstalled - Minor lag, commands go through fine, can still type and react to the situation.
Test with SVO reinstalled - Mudlet freezes (can't type) and lags, recovers when spam stops.

Log oof the testing when it freezes.
https://ada-young.appspot.com/pastebin/90c23e89

Ideas? Anyone experiencing the same problems?

@vadimuses

Nemutaur

That is a Wunder feature baby.  Granted I could just revert all affs that have shifted from Default, but this is safer since you never know exactly who shifted their aff prios in what way that might not be picked up by my Triggers. To be fair I have the same Problem, but only if I spam GOTO whatever and try to type something while a new path is being calculated, I cant wait for mudlet 3.0 since it felt so much smoother.

edit: do you have a personal Trigger that is processing the mind sapience --> stuff ? Tried disabling that and seeing what happens on Diagnose spam while sapiencing?

Valaria

I'm using Mudlet 3.0 Gamma right now, I have no problem with it since i installed it..(unlike beta version that contains a scary hunger and searching eater!)

edit: pss, pss. How to kill rangor? spam your priority switching.

there is one way to cut down the spam is to gag them. but only show it to you if it is relevant to you.

Atalkez

Mine lags and goes to Not Responding whenever there are lots of people in the room and/or fighting so I usually die in raids before j ever get to see a single thing, if I do ql or leave the room and come back. Highly annoying

Nemutaur

Oh forgot to ask. Do you guys have Compression forced off in settings?

Atalkez

Definitely Edit: my situation is a bit different. I only run wundersys, nothing to do with SVO. I have alot of triggers and alias groups but that's about it

Rangor

@nemutaur tried with it on and off, no noticeable difference.

Rangor

Maybe mudlet 3.0 will help. Will seee

Vadimuses

Time to dig out the stopwatches and see which of your triggers are taking so long... either try the debug window, but that'll be super spammy, or disable folders until you pin down which ones are making it slow. Putting in triggers echoing the stopwatch time throughout your stuff will help.

Rangor

So like I'm not going to debug SVO and see why it lags for most everyone who does pvp that I talk to. The common impression I get from people is also that when you uninstall SVO, switch to wundersys the lagging stops.

I started experiencing this at the reckoning event, hadn't had lag issues before that as far as I can remember. Anyone know what svo updates/changes were done around that time?

I dig SVO's functionality though, so gonna keep at it for a big longer before QQing for 100% wundersys.

Also...
when is mudlet 3.0 out of beta, and will that help with the problems?
Will SVO get a version that uses 100% serverside and strips out all the needless parts?

Rangor

@vadimuses

When reinstalling everything to mudlet 3 I tracked the lag problems to this:

Lag disappears when I remove both @numb and @tarprone from the customprompt.

vconfig customprompt @numb@tarprone^1H: @health ^W(^1@%health%^W), ^2M: @mana ^W(^2@%mana%^W) ^4@willpowerw, ^5@endurancee ^6K: @kai @eqbal|@defs- @timestamp

on event "svo system loaded"

function targetnumb()

svo.adddefinition("^xmagenta", "'<magenta>'")

svo.adddefinition("@numb", "targetnumb()")

  if tarnumb then return "<magenta>(N)" ..numb_counter.. " " else return("") end

end

function Pronetrack()

svo.adddefinition("^xskyblue", "'<sky_blue>'")

svo.adddefinition("@tarprone", "Pronetrack()")

  if TargetAfflicts.prone == 1 then return "<sky_blue>(P)" else return("") end

end

Antonius

@Rangor: Those functions are re-creating the svo custom prompt tag binding when they're called, and they're called on every prompt; that's probably why you're having issues with lag when there's a lot of spam because you'll be seeing a lot of prompts.

You need two functions:

One that is your event handler and does the binding for the prompt tag (a single time during each loading of Mudlet):

svo.adddefinition("^xmagenta", "'<magenta>'")

svo.adddefinition("@numb", "targetnumb()")

and then your targetnumb() function that just does the return:

if tarnumb then return "<magenta>(N)" ..numb_counter.. " " else return("") end

Rangor

yep.

changed it so this is called on svo loaded. and moved the targetnumb() and the other function to a different script. Was fairly sure I ruled this out during reckoning though. Maybe reckoning was causing other kinds of lag at the same time. Anyways. resolved now. Thanks!

function addcustomdefinitions()

svo.adddefinition("^xmagenta", "'<magenta>'")

svo.adddefinition("@numb", "targetnumb()")

svo.adddefinition("^xskyblue", "'<sky_blue>'")

svo.adddefinition("@tarprone", "Pronetrack()")

end

Aelios

Okay, I have the same problem but i'm not going to lie - that all looks greek to me.

Rangor

Try without a custom prompt. Just normal achaea health, mana, endurance and wp.