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.

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
set category = "Special Verbs"
set name = "OSay"
set desc = "Make an object say something"
var/message = input(usr, "What do you want the message to be?", "Make Sound") as text | null
M = O
olduniv = M.universal_speak
M.universal_speak = 1
M.universal_speak = olduniv
log_admin("[key_name(usr)] made [O] at [O.x], [O.y], [O.z] say \"[message]\"")
message_admins("<span class='adminnotice'>[key_name_admin(usr)] made [O] at [O.x], [O.y], [O.z]. say \"[message]\"</span>", 1)
feedback_add_details("admin_verb","OT") //If you are copy-pasting this, ensure the 2nd parameter is unique to the new proc!

/proc/possess(obj/O as obj in world)
set name = "Possess Obj"
set category = "Object"

usr << "It is forbidden to possess singularities."

var/turf/T = get_turf(O)

log_admin("[key_name(usr)] has possessed [O] ([O.type]) at ([T.x], [T.y], [T.z])")
message_admins("[key_name(usr)] has possessed [O] ([O.type]) at ([T.x], [T.y], [T.z])", 1)
log_admin("[key_name(usr)] has possessed [O] ([O.type]) at an unknown location")
message_admins("[key_name(usr)] has possessed [O] ([O.type]) at an unknown location", 1)

if(!usr.control_object) //If you're not already possessing something...
usr.name_archive = usr.real_name

usr.loc = O
usr.real_name = =
usr.client.eye = O
usr.control_object = O
feedback_add_details("admin_verb","PO") //If you are copy-pasting this, ensure the 2nd parameter is unique to the new proc!

/proc/release(obj/O as obj in world)
set name = "Release Obj"
set category = "Object"
//usr.loc = get_turf(usr)

if(usr.control_object && usr.name_archive) //if you have a name archived and if you are actually relassing an object
usr.real_name = usr.name_archive = usr.real_name
var/mob/living/carbon/human/H = usr = H.get_visible_name()
// usr.regenerate_icons() //So the name is updated properly

usr.loc = O.loc // Appear where the object you were controlling is -- TLE
usr.client.eye = usr
usr.control_object = null
feedback_add_details("admin_verb","RO") //If you are copy-pasting this, ensure the 2nd parameter is unique to the new proc!
/client/proc/make_sound(var/obj/O in world) // -- TLE
set category = "Special Verbs"
set name = "Make Sound"
set desc = "Display a message to everyone who can hear the target"
var/message = input("What do you want the message to be?", "Make Sound") as text|null
M = O
olduniv = M.universal_speak
M.universal_speak = 1
M.universal_speak = olduniv
log_admin("[key_name(usr)] made [O] at [O.x], [O.y], [O.z]. make a sound")
message_admins("<span class='notice'>[key_name_admin(usr)] made [O] at [O.x], [O.y], [O.z]. make a sound</span>", 1)
feedback_add_details("admin_verb","MS") //If you are copy-pasting this, ensure the 2nd parameter is unique to the new proc!

proc/debug_reagents(datum/D in world)
set category = "Debug"
set name = "Add Reagent"

if(!usr.client || !usr.client.holder)
usr << "<span class='warning'>You need to be an administrator to access this.</span>"

if(!D) return
if(istype(D, /atom))
var/atom/A = D
var/reagentDatum = input(usr,"Reagent","Insert Reagent","") as text|null
var/reagentAmount = input(usr, "Amount", "Insert Amount", "") as num
if(A.reagents.add_reagent(reagentDatum, reagentAmount))
usr << "<span class='warning'>[reagentDatum] doesn't exist.</span>"
log_admin("[key_name(usr)] added [reagentDatum] with [reagentAmount] units to [A] ")
message_admins("[key_name(usr)] added [reagentDatum] with [reagentAmount] units to [A] ")

client/proc/debug_variables(datum/D in world)
set category = "Debug"
set name = "View Variables"
//set src in world

if(!usr.client || !usr.client.holder)
usr << "<span class='warning'>You need to be an administrator to access this.</span>"

var/title = ""
var/body = ""

if(!D) return
if(istype(D, /atom))
var/atom/A = D
title = "[] (\ref[A]) = [A.type]"

if (A.icon)
body += debug_variable("icon", new/icon(A.icon, A.icon_state, A.dir), 0)


var/atom/AT = D
if(AT.icon && AT.icon_state)
sprite = new /icon(AT.icon, AT.icon_state)
usr << browse_rsc(sprite, "view_vars_sprite.png")

/client/proc/cmd_admin_delete(atom/O as obj|mob|turf in world)
set category = "Admin"
set name = "Delete"

if (!holder)
src << "Only administrators may use this command."

if (alert(src, "Are you sure you want to delete:\n[O]\nat ([O.x], [O.y], [O.z])?", "Confirmation", "Yes", "No") == "Yes")
log_admin("[key_name(usr)] deleted [O] at ([O.x],[O.y],[O.z])")
message_admins("[key_name_admin(usr)] deleted [O] at ([O.x],[O.y],[O.z])", 1)
feedback_add_details("admin_verb","DEL") //If you are copy-pasting this, ensure the 2nd parameter is unique to the new proc!
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.
right click lags gon get fixed

Happy day
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.

set name = "Adminverbs - Hide All"
set category = "Admin"

verbs += /client/proc/show_verbs

src << "<span class='interface'>Almost all of your adminverbs have been hidden.</span>"
feedback_add_details("admin_verb","TAVVH") //If you are copy-pasting this, ensure the 2nd parameter is unique to the new proc!

/*Debug verbs added by "show debug verbs"*/
var/list/admin_verbs_default = list(
/datum/admins/proc/show_player_panel, /*shows an interface for individual players, with various links (links require additional flags*/
/client/proc/toggleadminhelpsound, /*toggles whether we hear a sound when adminhelps/PMs are used*/
/client/proc/deadmin_self, /*destroys our own admin datum so we can play as a regular player*/
/client/proc/hide_verbs, /*hides all our adminverbs*/
/client/proc/hide_most_verbs, /*hides all our hideable adminverbs*/
/client/proc/debug_variables, /*allows us to -see- the variables of any instance in the game. +VAREDIT needed to modify*/
/client/proc/check_antagonists, /*shows all antags*/
// /client/proc/deadchat /*toggles deadchat on/off*/
var/list/admin_verbs_admin = list(
/client/proc/player_panel, /*shows an interface for all players, with links to various panels (old style)*/
/client/proc/player_panel_new, /*shows an interface for all players, with links to various panels*/
/client/proc/invisimin, /*allows our mob to go invisible/visible*/
// /datum/admins/proc/show_traitor_panel, /*interface which shows a mob's mind*/ -Removed due to rare practical use. Moved to debug verbs ~Errorage
/datum/admins/proc/toggleenter, /*toggles whether people can join the current game*/
/datum/admins/proc/toggleguests, /*toggles whether guests can join the current game*/
/datum/admins/proc/announce, /*priority announce something to all clients.*/
/client/proc/colorooc, /*allows us to set a custom colour for everythign we say in ooc*/
/client/proc/admin_ghost, /*allows us to ghost/reenter body at will*/
/client/proc/toggle_view_range, /*changes how far we can see*/
/datum/admins/proc/view_txt_log, /*shows the server log (diary) for today*/
/datum/admins/proc/view_atk_log, /*shows the server combat-log, doesn't do anything presently*/
/client/proc/cmd_admin_pm_context, /*right-click adminPM interface*/
/client/proc/cmd_admin_pm_panel, /*admin-pm list*/
/client/proc/cmd_admin_subtle_message, /*send an message to somebody as a 'voice in their head'*/
/client/proc/cmd_admin_delete, /*delete an instance/object/mob/etc*/
/client/proc/cmd_admin_check_contents, /*displays the contents of an instance*/
/datum/admins/proc/access_news_network, /*allows access of newscasters*/
/client/proc/giveruntimelog, /*allows us to give access to runtime logs to somebody*/
/client/proc/getruntimelog, /*allows us to access runtime logs to somebody*/
/client/proc/getserverlog, /*allows us to fetch server logs (diary) for other days*/
/client/proc/jumptocoord, /*we ghost and jump to a coordinate*/
/client/proc/Getmob, /*teleports a mob to our location*/
/client/proc/Getkey, /*teleports a mob with a certain ckey to our location*/
// /client/proc/sendmob, /*sends a mob somewhere*/ -Removed due to it needing two sorting procs to work, which were executed every time an admin right-clicked. ~Errorage
/client/proc/jumptokey, /*allows us to jump to the location of a mob with a certain ckey*/
/client/proc/jumptomob, /*allows us to jump to a specific mob*/
/client/proc/jumptoturf, /*allows us to jump to a specific turf*/
/client/proc/admin_call_shuttle, /*allows us to call the emergency shuttle*/
/client/proc/admin_cancel_shuttle, /*allows us to cancel the emergency shuttle, sending it back to centcomm*/
/client/proc/cmd_admin_direct_narrate, /*send text directly to a player with no padding. Useful for narratives and fluff-text*/
/client/proc/cmd_admin_local_narrate, /*send text locally to all players in view, similar to direct narrate*/
/client/proc/cmd_admin_world_narrate, /*sends text to all players with no padding*/
/client/proc/check_words, /*displays cult-words*/
/client/proc/check_ai_laws, /*shows AI and borg laws*/
/client/proc/admin_memo, /*admin memo system. show/delete/write. +SERVER needed to delete admin memos of others*/
/client/proc/dsay, /*talk in deadchat using our ckey/fakekey*/
/client/proc/toggleprayers, /*toggles prayers on/off*/
// /client/proc/toggle_hear_deadcast, /*toggles whether we hear deadchat*/
/client/proc/toggle_hear_radio, /*toggles whether we hear the radio*/
/client/proc/investigate_show, /*various admintools for investigation. Such as a singulo grief-log*/
/datum/admins/proc/toggleooc, /*toggles ooc on/off for everyone*/
/datum/admins/proc/toggleoocdead, /*toggles ooc on/off for everyone who is dead*/
/client/proc/game_panel, /*game panel, allows to change game-mode etc*/
/client/proc/cmd_admin_say, /*admin-only ooc chat*/
/client/proc/free_slot, /*frees slot for chosen job*/
// /client/proc/man_up,
// /client/proc/global_man_up,
/client/proc/response_team, // Response Teams admin verb
/client/proc/allow_character_respawn /* Allows a ghost to respawn */

var/list/admin_verbs_ban = list(
// /client/proc/DB_ban_panel
var/list/admin_verbs_sounds = list(
var/list/admin_verbs_fun = list(
// FUUUUCKED /client/proc/zombie_event, // ZOMBB-B-BIES
/client/proc/gib_money, // /vg/
var/list/admin_verbs_spawn = list(
/datum/admins/proc/spawn_atom, /*allows us to spawn instances*/
var/list/admin_verbs_server = list(
/client/proc/cmd_admin_delete, /*delete an instance/object/mob/etc*/
var/list/admin_verbs_debug = list(
/client/proc/qdel_toggle, // /vg/
/client/proc/cmd_admin_dump_instances, // /vg/
/client/proc/cmd_admin_dump_machine_type_list, // /vg/
/client/proc/disable_bloodvirii, // /vg
/client/proc/handle_paperwork, //this is completely experimental
var/list/admin_verbs_possess = list(
var/list/admin_verbs_permissions = list(
var/list/admin_verbs_rejuv = list(

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.
Page: 1 2 3