You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As reported by Zal, executing a macro like \ef1*tf1*tf1*tf1*tf1*tf1*t could disconnect the client with "Write error", meaning the buffer has overflowed.
Turns out, it's the *t part, that's being the culprit here.
There are many calls to handle_stuff() from within the targeting routine, that transform scheduled updates into actual (sock)buffer writes. Also, each time player tries to target something, we call adjust_panel() to see if that something is off-screen. Meanwhile, the adjust_panel() function sets p_ptr->redraw |= PR_MAPeach time it's called (because it's buggy).
Net result: whole dungeon map is re-sent on each *t call.
The short-term fix is to fix adust_panel(), long-term, we shall probably remove some of the update flushes from the targeting routine.
The text was updated successfully, but these errors were encountered:
As reported by Zal, executing a macro like
\ef1*tf1*tf1*tf1*tf1*tf1*t
could disconnect the client with "Write error", meaning the buffer has overflowed.Turns out, it's the
*t
part, that's being the culprit here.There are many calls to
handle_stuff()
from within the targeting routine, that transform scheduled updates into actual (sock)buffer writes. Also, each time player tries to target something, we calladjust_panel()
to see if that something is off-screen. Meanwhile, theadjust_panel()
function setsp_ptr->redraw |= PR_MAP
each time it's called (because it's buggy).Net result: whole dungeon map is re-sent on each
*t
call.The short-term fix is to fix
adust_panel()
, long-term, we shall probably remove some of the update flushes from the targeting routine.The text was updated successfully, but these errors were encountered: