Ideas & Suggestions

[megamandos]

You should add a way to get the server address and port, not just the name. That way things like my latency ticker can be more easily implemented. Granted i can just get the address by finding out where the client is sending its packets, but that takes a lot more code than i want to execute at the start of my program.

[Artaxerxes]

You should add a way to get the server address and port, not just the name. That way things like my latency ticker can be more easily implemented. Granted i can just get the address by finding out where the client is sending its packets, but that takes a lot more code than i want to execute at the start of my program.

I'll add this to the v0.5 todo list, should not be too hard to implement.

[megamandos]

Please add the ability to send sysmessages of different hues, other than just grey.

[Artaxerxes]

Please add the ability to send sysmessages of different hues, other than just grey.

Should not be a problem, I'll add this to the todolist... i think i should also readd the function that displays messages above a specified character's head.

[megamandos]

Both those ideas would be fantastic. Gives much more functionality. I thought about writing the code in my app but i think i will just wait for you to do it.

[megamandos]

Add a method to get the client's Window Handle so you can tell when it is on top/minimized/maximized/etc. and so you can manipulate it as you wish. That would make an easy way to implement smart always on top like razor has

[Artaxerxes]

Add a method to get the client's Window Handle so you can tell when it is on top/minimized/maximized/etc. and so you can manipulate it as you wish. That would make an easy way to implement smart always on top like razor has

Possible, i get hold of this handle anyway when detecting clients. I'll add this to the todo-list.

[megamandos]

Be sure to include support for the zlib compressed gumps, if you haven't already. If you parse them on the packet level that is...

[Artaxerxes]

Be sure to include support for the zlib compressed gumps, if you haven't already. If you parse them on the packet level that is...

Well, my first attempts to write something like UOAI, before i started disassembling the client or even thought about wrapping it all into a component library, used a proxy based approach: i just connected the client to a local server, which then proxied the connnection to the gameserver. Internally that project was completely packet-based, and also had handling of compressed gumps implemented, so i still have code "lying around" to parse the compressed gump packet.

But in any way most gump handling will not occur at the packet level, but i have figured out the purpose of class member functions on specific gump classes used in the client and use hooks of those class members.

[megamandos]

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.