struct.unpack

Discuss the development of Lua addons for Ashita v3 here.
Post Reply
Yunamahoutsukai
Posts: 36
Joined: Tue Oct 24, 2017 11:28 am

struct.unpack

Post by Yunamahoutsukai » Mon Mar 26, 2018 4:07 pm

It looks like Ashita supports this library but I cant find any docmuentation on it.
Is there any?
Are there other undocumented libraries available besides the ones documented in the Wiki?
User avatar
atom0s
Site Admin
Posts: 455
Joined: Sat May 14, 2016 5:13 pm

Re: struct.unpack

Post by atom0s » Tue Mar 27, 2018 11:26 am

http://ashita.atom0s.com/wiki2/doku.php ... tions:bits

The bits unpacking stuff is listed there. As for struct.unpack, this is just a general lib inclusion to the main Lua library itself.
You can find more info on how to use that here:
http://www.inf.puc-rio.br/~roberto/struct/

As for what other 'hidden' libraries there are, I would really call them hidden just not documented.
- bitop: http://bitop.luajit.org/ - Should be accessible via bit.xxx function calls.
- lpack: https://github.com/LuaDist/lpack - Should be accessible via pack.pack / pack.unpack calls.
- lstruct: http://www.inf.puc-rio.br/~roberto/struct/ - Should be accessible via struct.xxx calls. (pack, unpack, size only.)
- luasocket: http://w3.impa.br/~diego/software/luasocket/ - Should be accessible via its normal means in its docs.

Are the only libraries added to the Lua library in Ashita.
Lead Ashita Developer

Want to donate to say thanks?
https://www.paypal.me/atom0s
Yunamahoutsukai
Posts: 36
Joined: Tue Oct 24, 2017 11:28 am

Re: struct.unpack

Post by Yunamahoutsukai » Tue Mar 27, 2018 3:42 pm

Thank you, that helps alot.
BlackBelt
Posts: 2
Joined: Thu Dec 28, 2017 11:52 am

Re: struct.unpack

Post by BlackBelt » Sat Aug 03, 2019 2:21 pm

Hi,

Apologies for bumping this thread, though it seemed relevant to include here.

I'm trying to wrap my head around the struct.unpack stuff using the above information.

I'm trying to do something simple, like detect if I walking into a moghouse zone and print a message. I mainly want to learn the best approach for going about this. So far I am registering for an "incoming_packet" event and printing out the id in hex.

Code: Select all

ashita.register_event('incoming_packet', function(id, size, packet)
	print(string.format("%x", id));
    return false;
end );
Not sure of a better way, though I found that 0x0A corresponds to zone changes. To find this I had the above code in an addon and entered a zone in game and sifted through the various printouts, "A" seemed to be one of the first ones printed out. From there, I can conditionalize that...

Code: Select all

ashita.register_event('incoming_packet', function(id, size, packet)
	print(string.format("%x", id));
	if(id == 0x0A) then
		print("zone change!");
	end;
    return false;
end );
At that point I am trying to understand how I can leverage the sent in packet. Is there a best practice on printing it? Seemed to be a "=" in the game (i.e., a print call). How do I relate it to the structs defined in Ashita.h with this? Is there a "packets-list" of some sort that I can leverage? I just don't know what to look for in the struct.unpack call. I've read http://www.inf.puc-rio.br/~roberto/struct/#pack numerous times and am just not following. I understand the API signature and it seems that the packet would belong as the second parameter. It's just, there are numerous structs defined and I have no clear way of knowing what the packet corresponds to.

Thanks!
User avatar
atom0s
Site Admin
Posts: 455
Joined: Sat May 14, 2016 5:13 pm

Re: struct.unpack

Post by atom0s » Sat Aug 03, 2019 3:12 pm

For packet information such as offsets and data types, you can take a look at Windower's current packet library:
https://github.com/Windower/Lua/blob/de ... fields.lua

In your situation, 0x0A is the zone update packet sent from the server when you first enter a zone.

For mog house stuff, you're better off going with a different packet to tell if you are using a mog house based on the zone line information. When the client sends '0x5E' to the server, that is used for exiting a zone and requesting the zone line change. You can pull the zone line id from that packet to tell if it is a mog house zone line.

0x0A has some data that can be used to do it as well but it is more annoying to deal with vs. using 0x5E imo.

Keep in mind, regarding Windower's packet information, there is a lot of data that is incorrect in their packet information stuff. They do not spend a lot of time researching packet information thoroughly for lesser-used packets which can land up getting you incorrect information, invalid results, or cause major issues like getting banned if you are sending packets using their information. I do not recommend you ever use their data for sending packets because of this. There are a handful of packets that SE actively has triggers on the server-side to handle flagging cheaters and automating ban related backend stuff. If you send invalid packets consistently enough, you will get banned. Use their information as a reference, but don't assume it to be 100% accurate for all packets.
Lead Ashita Developer

Want to donate to say thanks?
https://www.paypal.me/atom0s
Post Reply