Ideas & Suggestions

[arul]

Here's a (short) list of things I've been missing in the UOAI so far:

- More event-ish approach in some places (like Targetting - when there's a target available, it would be nice if some callback method would be executed).
- Expose pack handling functions - I mean something like OnPacketSend(PBYTE pBuf, int len) / OnPacketReceive(PBYTE pBuf, int len).

[Artaxerxes]

Here's a (short) list of things I've been missing in the UOAI so far:

- More event-ish approach in some places (like Targetting - when there's a target available, it would be nice if some callback method would be executed).
- Expose pack handling functions - I mean something like OnPacketSend(PBYTE pBuf, int len) / OnPacketReceive(PBYTE pBuf, int len).

Both are already on my todo list, actually.
The most important part needed to implement such events is already present in the current version, it is simply not used yet. A dll injected into each client, already hooks the packetsend and receive functions (at a point where the packets are not encrypted yet or already decrypted) and passes that info to UOAI (IPC is through windows messages).

So I can easily add a onPacketSend and OnPacketReceive event to the UOClient object, but I'm not sure if thats the right way to go.

My first thought was to interpret the packets and sent specific events, such as UOItem_onItemUpdate, UOItem_onDelete, ..., but then again a simple onPacketRcv and onPacketSend event is implemented much faster.

One question remains: should I allow users of my library to modify packets while they before they are sent to the server or client? That would be extremely powerfull, but then again easily abused. Also it would mean the events have to be synchronized with the clients receiving and sending, so if your app hangs in the onReceive or onSend event the whole UO Client will hang too... so whats your opinion on that?

ps. IPC messages are also sent whenever a UOClient's window receives a WM_KEYDOWN or WM_KEYUP, so hotkey handling will be done in a similar by triggering a onHotkey event.

Greetz,
Artaxerxes

[arul]

I wouldn't allow people to change packets through OnPackt*** events. I'd send them a copy of the buffers -or- make the pBuf pointers const(C99 allows that, doesn't it?) -or- simply invoke that event after the packet has been processed, so changing it's contents wouldn't change anything.
I had SpyUO on my mind when I posted that - currently SpyUO works in a way that each time OSI release a new patch someone has to disassemble the client and find the memory locations of UNencrypted send/recv buffers. I wrote a dll that automagiccally(calibration info) found that addresses, but every ~2 months they changed so I had to fetch new calibration info from the client, which eventually bored me to death and abandoned it .

The synchronization problem, no biggie for me, people should face the consequences of what they did

[Artaxerxes]

I wouldn't allow people to change packets through OnPackt*** events. I'd send them a copy of the buffers -or- make the pBuf pointers const(C99 allows that, doesn't it?) -or- simply invoke that event after the packet has been processed, so changing it's contents wouldn't change anything.

Don't need to make it const, in com any read/write access can only be done by accessor functions i expose, so if i don't provide write accessors the buffers will be read-only. (there is no way for a com-user to figure out the memory offsets of the buffers, they just get access to a function in UOAI that accesses the buffers for them)
I think there is no other choice then triggering the events when the packet is already handled, f.e. if an item has moved and you receive that info through a packet, then you probably expect the corresponding UOItem.X, .Y and .Z to be updated, which is only through if I trigger events after the packets were handled.

I had SpyUO on my mind when I posted that - currently SpyUO works in a way that each time OSI release a new patch someone has to disassemble the client and find the memory locations of UNencrypted send/recv buffers. I wrote a dll that automagiccally(calibration info) found that addresses, but every ~2 months they changed so I had to fetch new calibration info from the client, which eventually bored me to death and abandoned it .

UOAI callibrates each client at runtime, when the client is detected. This routine is written in such a way that it has a good chance to still be able to figure out the right memoryoffsets when a new patch arrives. Ofc now and then a new UO-patch will require an update of this callibration-routine, but definitely not every patch.

The synchronization problem, no biggie for me, people should face the consequences of what they did

If only read-only copies of the packet-buffers need to be accessible, I can easily trigger the events asynchronously.

[arul]

Another thingy

Why does the GetDirection function remove the running mask (0x7F)? I can think of a few situations this information may be useful.

[Artaxerxes]

Actually there was a boolean UOMobile.isRunning property too in the first version, so direction just had to return the direction, while isRunning returned the mask info. There were some problems with isRunning, cause it did not consistently return the correct value, so it was removed. I never got to implementing this again. I will take a look at it after I figured out how to fix the crashes... most likely tonight.

[arul]

Actually there was a boolean UOMobile.isRunning property too in the first version, so direction just had to return the direction, while isRunning returned the mask info. There were some problems with isRunning, cause it did not consistently return the correct value, so it was removed. I never got to implementing this again. I will take a look at it after I figured out how to fix the crashes... most likely tonight.

Great, thanks!

Another thing I noticed right now, stats (str, dex, int) are read as shorts while client stores them as unsigned shorts.

[Artaxerxes]

I was running tests from visual basic 6 ... which expects signed integer types.
Maybe I should take another look, to make sure everything is passed correctly though. F.e. also hues are passed as negative numbers, while in fact it should be considered as large unsigned numbers. I think in most cases, such as the X,Y,Z coordinates it is not a problem, since the total scale of the map-axis is always smaller than half the range of the unsigned ints and within that range unsigned and signed values have the same binary representation.

[arul]

On my GM character on my server I have 65.000 (the maximum value the client supports, don't know why) of all stats, the client displays it properly, but in the VB example it's shown as -536.

[Artaxerxes]

Ok, I will fix this. The problem is just that visual basic 6, which I initially used for testing, does not support unsigned types (see f.e. http://msdn.microsoft.com/en-us/library/7f5ztkz3(VS.80).aspx). I'm not sure about vbScript, but there's a good chance that even if I return unsigned types, vbScript will display it as signed ones.