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
Where #189 is about tracking telnet options negotiation, this ticket is about making it easier to debug things like MXP lines. If you're wondering something like "Why did this output work in Mudlet but not in Zmud" then it can be helpful to see a human-readable sequence of exact characters that went over the wire, right before sending the actual line. For example, if this option is on, the connected admin may see something like:
SENDING: Here is our inventory:\r\n
Here is our inventory:
SENDING: ESC[1z * <send href="buy bread">bread</send> \r\n
* _b_r_e_a_d_
SENDING: ESC[1z * <send href="buy water">water</send> \r\n
* _w_a_t_e_r_
with, perhaps, special named parts like ESC colorized specially. An alternative to sending this to the character connection could be to output this to the console output of the app. There are trade-offs to consider.
(In this example, it is cases of output like <send href="buy bread">bread</send> that Mudlet aggressively treats as MXP output even if the "secure line" type sequence is missing. Such behavior may lure developers into thinking their output is good even though it is actually malformed and would only work on that one target client. This would also help catch why things like "my emotes don't show up" if the emote output format happened to be something like <*Dude waves!> and they happened to be testing through Mudlet.)
The text was updated successfully, but these errors were encountered:
Added DebugConnectionsOutgoingData and DebugConnectionsIncomingData bool flags which echo nicely color-coded data to the console log window, while enabled. This should be sufficient for now as something a dev turns on to investigate specific issues. We can think again during later polish whether we need to be able to route such debugging data elsewhere (not just the console log as an admin may not have that in all run contexts), whether we need it for active live MUDs against specific target connections (at the exclusion of others), etc.
Where #189 is about tracking telnet options negotiation, this ticket is about making it easier to debug things like MXP lines. If you're wondering something like "Why did this output work in Mudlet but not in Zmud" then it can be helpful to see a human-readable sequence of exact characters that went over the wire, right before sending the actual line. For example, if this option is on, the connected admin may see something like:
with, perhaps, special named parts like
ESC
colorized specially. An alternative to sending this to the character connection could be to output this to the console output of the app. There are trade-offs to consider.(In this example, it is cases of output like
<send href="buy bread">bread</send>
that Mudlet aggressively treats as MXP output even if the "secure line" type sequence is missing. Such behavior may lure developers into thinking their output is good even though it is actually malformed and would only work on that one target client. This would also help catch why things like "my emotes don't show up" if the emote output format happened to be something like<*Dude waves!>
and they happened to be testing through Mudlet.)The text was updated successfully, but these errors were encountered: