Jul 17 2013, 7:54 am
|
|
More experimenting: About same ping-pong time as same server I tried this on, same round, same pile of crap, last time it ran in about 2 seconds, now my client froze for about 10 seconds
|
The fact of the lag being a factor could be indicative of the need for some verbs to verify things with the server. For the most part verb availability is client-based, but there are some exceptions. This could end up being pretty difficult to test without a known reliable sluggish case though.
|
The whole thing is really weird, like if it was based on time connected or something, it can be extremely sluggish at times, but there appears to be many factors involved
Though, it can be related to round-trip time, since that time is very spastic I could have gotten the same time by chance Wouldent it make sense for the server to simply filter all the verbs that need data that the client doesnt currently have, and then send it off to the client for further filtering? |
On another note, the only verbs that are in the case I'm testing use oview() for the availibility check
|
Additionally, if you're moving fast and right click a tile with lots of objects when its far away from you, you sometimes only get a partial list
|
Most verbs should already have all the info they need at the client end. The main times you need to contact the server are when the verb has an "arg in userdefinedproc()" format or something similar. view() and oview() are already things the client should be able to handle because it calculates those as part of the map display.
|
Going to bump a lot of old SS13 issues that are getting really annoying
This seems to be an SS13 thing, running a simple environment I get basicaly no issues, in SS13 a pile of 10 items can kill your client for a good second, those time someone manages to abuse something to make a pile of 1000 items it will pretty much murder your client for a few minutes |
I've done a little investigation in the past. I've noticed that verbs on objects are a LOT slower than verbs on the user. See the attached project for an example. Toggle the macro at the top of the DM file for each case.
http://www.mediafire.com/download/5rrs3b58c7r7vr7/ VerbTest_src.zip It creates 25,000 objects on the map with random offsets. In the first test, all objects have a verb with set src in world , and there's a noticeable delay after right clicking on the map. In the second test, there is a client verb with an obj/o in world parameter. The context menu populates almost instantly in this case.I've managed to convert a few object verbs in SS13 to client verbs, (I.E. pull, examine) but all the nonconvertible verbs made the difference only noticeable in ridiculously huge piles. |
The problem seems to only become really bad mid or late round in SS13 (read: when pretty much half the engine has leaked something or miserably broken itself and is dying limping along)
|
Lummox JR, is it possible that view() and oview() are already calculated for mobs/clients but not for objects?
At the moment every object in SS13 has examine(), pull(), and point() verbs. |
Lummox I have some more information on this if you would be willing to take a second look.
It seems the length of time it takes for the right click menu to initialize is directly proportional to the number client procs (that would normally be on the object) that are HIDDEN from the client. I've noticed this from just gathering lots of experience on my local server as well as on our primary codebases' server. So I tested this experimentally: With a stack of 100 objects the right click times were accurate to within about .5 seconds I found on SS13 at least with varying number of 'admin flags' (and thus client procs accessible to me): With maximum flags, and 10 right click verbs shown per object - 5 second display time Moderate flags, 6 right click verbs shown - 10 second display time No flags, 3 right click verbs shown - 18 seconds display time It seems clear there is some inefficiency with the way client procs and regular procs added to some clients on the object that the client does not have in the verbs list is causing this insane clientside latency. But the fact that additional verbs on the object do not seem to affect it is what I found most interesting. So it seems, to me at least, that object verbs have no trouble at all since they are immediately accessible, but client procs or regular procs (which work using obj/turf/whatever in world) individually verify they cannot be activated by this client (or something). |
What sorts of hidden verbs tend to trigger this? What are the args of those verbs, if any? And how are the verbs shown/hidden? That info could be really helpful to finally uncovering the problem.
|
I will post several of them for you, but truncated versions for the extremely long ones.
...In a bit of course |
/client/proc/object_talk(var/obj/O in world) // -- TLE /proc/possess(obj/O as obj in world) /proc/release(obj/O as obj in world) |
/client/proc/make_sound(var/obj/O in world) // -- TLE client client/proc/debug_variables(datum/D in world) /client/proc/cmd_admin_delete(atom/O as obj|mob|turf in world) |
Above are all the procs that are hidden from normal users which are activated and are available to admins with some/all flags. There could be more procs like this in SS13 that aren't added even under the maximum number of flags and therefore admins currently could never get truly instantaneous speeds without them.
The final 3 for that object were base level object procs which I dont think are relevant to this discussion. The above procs are added to the admins' client verb list when they receive the datum admins are assigned. Admins can hide/show some or all of these verbs which is the method I used to quantify the latency of right clicking earlier. |
Fascinating. I think the fact of the argument being "obj in world" is the key thing for me to zoom in on. Obviously 508.1287 is proceeding without this, but hopefully I can find and fix this for part of the 508 series.
|
I've started looking into this, but I'm having a lot of trouble with a simple test project. I'm really not sure I'm doing this the same way. In my tests, any client/proc that has not been added to the client already is ignored completely and doesn't seem like it could possibly contribute to this issue.
Can you show me the code responsible for adding these verbs, and tell if the verbs have ever been added? |
Hmm... recently I've been looking at this more in depth as well and I'm not sure anymore that it's an explicit problem with hiding verbs on the right click menu. I recently conducted a test by removing any verb that may show up in the right click menu, however from my measurements performance wasn't significantly impacted.
So taking it back to the basics of what I tested and the results I found, there are 3 standard verbs to show or hide verbs for admins (which is the precise method I used to test it). Here is the most extreme case is the Hide All admin-verbs command, which gave the most extreme difference between the two states. /client/proc/hide_verbs() The problem here is that I cant see any explicit problem with any of these. The right click latency for the client has little to nothing to do with the quantity of right click options that show up. The confusing thing that really muddles my thinking is that having all these verbs added to your client.verbs increases performance, whereas one would expect the precise opposite. Due to the number of variable factors here I simply don't know precisely what conclusions to draw overall. I suppose I must attempt further permutations of this test, such as one limiting the scope of the changed verbs to client/procs only. |