[sldev] Technical question

Soft soft at lindenlab.com
Wed May 6 14:46:28 PDT 2009


On Wed, May 6, 2009 at 1:04 PM, Carlo Wood <carlo at alinoe.com> wrote:
> I wish to debug something that happens as a result
> of a server message - but I have no idea where to
> start (where to put the breakpoint).
>
> I can trigger this by editting a prim. For
> example-- I create a box, and then I change
> a value in the Object TAB (ie, position or
> rotation etc) and hit enter. This will send a
> message to the server.
>
> I am assuming that some feedback message will
> be returned by the server to tell my client that
> the prim changed.
>
> What would be ideal is if I could set a break-
> point somewhere where I can check WHICH object
> was changed (so that I'm sure that if the breakpoint
> is hit, it is what I need *), as opposed to for
> example set a break point in a function that is
> hit *every* message from the server. The latter
> obviously won't help much cause there are too
> many incoming messages.
>
> Can someone shine a light on this for me?
> What would be a good point to intercept this?

The message handling functions (with very few exceptions) start with
the name "process_"For server responses, it's always going to be one
of these that you would want to hook first. In this case,
process_object_update is the guy you're after, and that goes on to
call LViewerObjectList::processObjectUpdate. The "fullid" unpacked
from that message is a unique object ID, which you could check for in
a conditional breakpoint.

To learn the object ID, you could add an llinfos print to something
like LLToolGrab::startGrab so it prints the ID of any object you click
on.

For discovering which messages you want, put a break on any process_
message and look up the call stack to see how messages are dispatched.
You can add a little in the dispatcher that prints the name of every
single message that arrives, and then start adding conditions to omit
the most common messages. Keeping this in place and periodically
filtering out messages you understand is a really great way to learn
the client-server protocol.


More information about the SLDev mailing list