I bet this crashes now, for instance: call_out(this_user,0);
You are exactly right.
I suggest putting, in the (base) user class: constant is_user_object=1;
The only problem I have with that, is that the server itself doesn't control anything about the user class or attempt to define anything about it. Plus, the socket class just links the socket to an object and allows for the socket to be relinked to any object on the go.
I'd rather take care of it myself, to keep that extra bit out of anyone's face (like anyone will actually use it, heh)
and a sanity check in the this_user function, like this,
array b=backtrace(); if (sizeof(b)>4 && ...b[4]...->is_user_object) return it; foreach (b;;array v) if (...v...->is_user_object) return it; return 0;
What I went ahead and did was basically what you just wrote here, with the exception that I had it call a function that to checks to see if an object is referring to an interactive (socket-linked) obj.
Martin:
the thing i don't understand is, why use a backtrace to find the user object? is there no simpler way to do this?
Not really after the compat for previous object was removed from Pike. As I said, my server is written with LPC in mind, split server and mudlib. I don't want the two (server + lib) to be conjoined by kludge code, and the only other way, besides previously mentioned, I can see would be passing the pointer of the users current object to each function they call.
How other way would this work and be able to distinguish the user that is calling a function that would be less complex?
Kaylus
/ kaylus
Previous text:
2003-08-29 15:20: Subject: Re: Problems with Backtrace
I suppose you could store something thread-locally, but wouldn't it be about as complicated?
/ Mirar