My favorites | Sign in
Logo
Project hosting will be READ-ONLY Wednesday at 8am PST due to brief network maintenance.
                
New issue | Search
for
| Advanced search | Search tips
Issue 173: InjectedDLL OnGetNextPacket
1 person starred this issue and may be notified of changes. Back to list
Status:  WontFix
Owner:  joebingham07
Closed:  Nov 11
Type-Enhancement
Priority-Low


Sign in to add a comment
 
Reported by joebingham07, Nov 01, 2009
A few "problems" with r758

1) If you hook OnGetNexPacket before login it'll crash the client upon login.
2) If you unhook OnGetNextPacket the client will crash.
3) The addresses for OnGetNextPacket and RecvStream were including in
Core.cpp because I couldn't get it to work by sending the packets through
the pipe. (I believe the problem is with pRecvStream(?)).
4) Before I changed the OnGetNexPacket parser into multiple switch cases
the client would crash upon floor changes. So far I haven't had any
problems, but it seems to lag the client. Maybe this could be fixed by
putting the parser into it's on function on a seperate thread? (I have no
clue how to do that by the way).
5) Without also hooking Recv, Send didn't seem to work so it was commented
out and therefor we can't check outgoing packets. If someone wants to
retest hooking Send for me then I would appreciate it.

I think that's all the problems I can remember. The reason for this commit
was because the parser for Recv wasn't working right and the packets
weren't being parsed correctly resulting in inefficiency of packet events.
I've tested several packet events and they all seem to be working great
with this method. If you have any questions, concerns, etc. please reply.
Comment 1 by joebingham07, Nov 02, 2009
1) I found this is because of the parsing.
2) See #1.
3) My bad, RecvStream is the only address included in Core.cpp. Also I forgot to move
the values and such back to Core.h, not a big deal right now.
4) The "lag" is due to how long it takes to return iCmd because of the parsing. Is
there anyway to go ahead and return iCmd and let the packet parse in a seperate
function? This wouldn't let the end user block/modify the packet, but I don't see any
reason why they would need to anyways.
5) If the Send buffer goes through the same parsing as Recv then it would also be
inefficient, correct? If the Send buffer only holds individual packets I'll test it
again.
Comment 2 by joebingham07, Nov 02, 2009
Fixed #3, and I left the variables in Core.cpp.
Comment 3 by joebingham07, Nov 09, 2009
(No comment was entered for this change.)
Labels: -Type-Defect -Priority-High Type-Enhancement Priority-Low
Comment 4 by joebingham07, Nov 11, 2009
Deprecating hooking OnGetNextPacket and gonna fix the current packet parser.
Status: WontFix
Sign in to add a comment

Hosted by Google Code