megamandos wrote:You know, over time I have noticed a few issues caused by the dll "staying inside" of the client and then being "re-injected" upon another application or another instance of the same application being started up. Many times this results in some very odd and almost unexplainable things happening. One of the main issues I have is with the packet filter. If you apply a filter to say the "0xBF" packet (which handles many things) and do some operations and then shut down the program without shutting down the client or removing the filter, then restarting the program and subsequently "re-injecting" the code, the client will still "ignore" the 0xBF packet, and the newly injected code will not recognize that the 0xBF packet is being filtered, and thus will not be able to receive those packets for interpretation, nor will it be able to remove the filter and enable itself to do so.
So, I would suggest that you add code to UOAI for it to be able to unhook/unload itself from the client, either automatically or manually by the parent application upon the parent application closing. I know this may require a lot of work, but it would solve many debugging issues.
The dll is not supposed to be unloaded, since several UOAI instance can be using the same client. Shutting down one UOAI app should not cause another to stop working, right?
That being said, however, the packet-filtering problem you noted shouldn't happen... the packet should remain filtered if your app does not remove the filter, there is no re-injection (at least there shouldn't be)... so the set filters client-side should remain active. However, that should also mean that if you check the filter, after you restarted your app, it should still be set. I'll double-check what's going on there.
