Well, One fix might be to make the client to some how, some way, forget those verbs exist when they get removed.
And while your in there, try to fix right click lag, its odd that the webclient can handle 1000 objects on a tile faster than ds can handle 15 objects on a tile. =P
edit: I can confirm that it doesn't seem as bad but still seems to slightly exist pre-1328.
| |
bump.
| |
The issue with the verbs probably deserves its own thread at this point, since the main issue on this thread has been dealt with.
I haven't prioritized the verb fix because to be honest, it's very difficult. The idea I have in mind (it'd be best if the new thread links back here) probably will work, but I think the var access thing takes higher priority. | |
i know mods can merge threads, can they split them? like maybe just move http://www.byond.com/forum/?post=2057211#comment19142543 and down to a new thread?
| |
It can be split, but a lot of the discussion on the subject hasn't been threaded properly and won't go with it.
| |
Every so often, the verb panel refreshes. When it does, it calls a routine called GetPlayerActionList(), which looks for all available verbs that don't have a null category. (Minor possible tweak: It really should check for the null category first before looking to see if anything uses the verb, so I'll make that change for 1334. It doesn't impact your issue.) This in turn calls the function VerbHasSrc() for every known verb.
VerbHasSrc() calls ImplicitSrc() first, which runs a few functions to see if src is easily identified--like for instance if the current client appearance uses it. If those fail, then GetCmpSrcList() is called, and that's where the slowdown is happening.
GetCmpSrcList() is being told in this case to bail out as soon as it finds any possible src, rather than grabbing a list of them. It then goes through all known mobs, all known objs, all turfs in current view (not including OOB turfs), and the area if the player is in an abstract area (e.g., in a MUD), in that order, looking for anything that could be src.
Because these verbs don't belong to anything, GetCmpSrcList() goes through the entire loop trying to find something that has an appearance tied to these verbs. And there's your stutter. It happens every time the statpanel updates, because it's trying to get an accurate verb list. It doesn't happen before you add the verbs because until that point it doesn't know the verbs exist. It doesn't happen when the verbs are in use, because ImplicitSrc() catches those cases early.
Coming up with a solution for this may be difficult. I have one idea, but it may be problematic. The concept would be that every verb would have a value that says whether it may be in use; if that value is 0, GetCmpSrcList() can fail instantly. This value would start at 1 and would be reset whenever an appearance using this verb was assigned to anything on the client end, or when a new appearance was first registered. (The trick: catching all places that happens.) And if GetCmpSrcList() failed to find any matches, it could change the value to 0 to avoid future checks. I doubt this setup would impact performance significantly when appearances changed, especially if the appearances are given a var to indicate the last time their verbs were refreshed.