Question On Packets.

I'm using packetviewer to track dialog options so that I can automate selections from npcs. However, when I build my packet based on the data that I got from packetviewer, it seems that I'm not generating the exact data that the game generates.

For example, using the HP crystal in w.adoulin and canceling out of the crystal dialog generates a packet. In my code, I've attempted to send that same packet via the following code:



When I execute the code and track the packet in packetviewer, I see the following data:



However, this does not cancel out of the HP crystal menu. If I then cancel out of the crystal menu in-game by hitting escape, packetviewer shows the following data:



If you look at the bottom of the packetviewer window, the options are identical. Target, Option Index, _unknown, etc.

However, there is a slight difference in the raw hex data. Particularly in the dark grey section.

Specifically, the packet that my code generates shows a hex value of 5B 0A 00 00, and the packet generated in-game shows a hex value of 5B 0A 3A 04.

Is there a problem in the way I'm generating my packet? Why am I missing the 3A 04 section of the packet? Admitedly, I'm very new to addon programming, and dealing with packets in general. But documentation seems relatively sparse on this issue, and I'm getting the majority of my references from viewing the lua code for other addons.

Thanks in advance.

Edit:

Is there a different way to generate this packet passing the hex values or something? I didn't find anything online, but maybe by passing a string, perhaps?

something like:

local inject = packets.new("5B 0A 3A 04 74 ...etc");

There's usually another follow-up packet that you need to send. For some NPC interactions it's a simple status update packet. For others, it's a similar packet to the one you created, but only after receiving the proper 0x05C(?) I could be mis-remember, but it's late at night.

I'd suggest using packet viewer's logging function to record 'all' related traffic when interacting with NPC's. It should help. You're on the right track.

Edit: The first four parts of your packet aren't as important as you think. I'm going off of memory here and not my actual notes, but I think the first is the packet size, second being the # of packets from the server (your spot in the packet queue as it were)?

For your record, a player update packet is an outgoing 0x016 with your ID as the Target Index. (See the fields.lua) in your windower installation.

So you're thinking it's likely that there's more than 1 packet that needs to be sent for the functionality? I guess I saw the "dialog choice" name and kinda latched on to that as being the packet I needed to send.

I'll play around with it some more, thanks for the reply.

edit: I logged all outgoing packets and the only packets sent were 0x05b (dialog packet) and 0x015 (standard client that send position and orientation of character).

A few seconds after I have canceled out of the hp crystal menu it sends a followup 0x016 packet (update request), but by that point the dialog box has been gone a few seconds, so I'd guess it's not necessary to make the dialog box disappear.

You can't inject any packets while inside a menu. When you press enter on NPC, the game enters a state where it no longer generates status update packets. Packet injection works by appending your injected packets to already outgoing packets. Since you have no outgoing packets, your injected packets aren't appended until you hit escape, at which point they are no longer needed.

When working with menus, you need to work solely in packets. Sending the 0x1A to speak to NPC directly will not lock you out of further injection like pressing enter will. In some cases you will also need to block the menu from appearing to prevent the client having issues.. injecting packets never updates the client side menu correctly, and if another step is requested you may crash or error out.

The 3rd and 4th byte are a synchronization value, windower and ashita handle it internally. It needs to be the same as every other packet in the sequence, so they just match it to the packet they're appending on. It's not your problem.

As a side note, you still aren't sending the same exact data the game sends. The game will always have the 0x5B as the first packet in sequence and won't generate 0x15s while in a NPC interaction. Doing it this way has you feeding 0x15s while mid-interaction and your 0x5B is always the second packet in sequence(or later).

It will still work, but if SE ever decides they don't like it, it would be super easy to catch.

Comeatmebro - thank you that is all very helpful information. I've noticed what you mentioned, while using the packetviewer log that the 0x15 packets stopped abruptly while inside a dialog option with an npc (which makes sense - since 0x15 seems to be the packet that updates the character position data and that normally won't change while in a menu)

After I made my post and shortly before I went to bed, I was mulling over the MAGA plugin, which disables the menu while its doing its work via:


So that kind of got me thinking down the path of what you were saying about "In some cases you will also need to block the menu from appearing to prevent the client having issues". It seems I was on the right track, but was too tired to keep going. I'll play with it some more tonight after work.

I've been able to circumvent this issue to this point by using the windower.send_command to navigate the menus using setkey, but this kinda seemed like a janky solution.

Nice to know this. Just took it for granted.