#opcode should reload all opcodes
|
Well, I tried #opcode and it doesn't seem to reload any saved changes to my .conf files for opcodes. I still get an Unknown message about opcodes that I have assigned in the config file and saved.
|
yeah my mistake it's #opcode reload it should give you a client message about reloading all opcode patches.
|
Thanks, I actually just found that out while experimenting a little after posting that lol. Was just about to come and post the correction.
After figuring that out, I was about to get /zone to work for GMs instead of only #zone working. Here are the changes to get /zone working. Still working on figuring out more. Code:
#GM/guide opcodes |
That's awesome Trev. I hope that I can get some free time soon - I'd LOVE to come help with OpCodes, it was the last one thing for which I had been trying to make time.
Keep rocking it out, THESE are the things that have been holding back this project from becoming polished. Muchos Kudos! Dax |
Took forever to figure out the correct byte order to get everything to work but finally got the CRC working on live packets and if I can CRC them I can decode them... eventually.
Code:
Request session reply(0x0002) found, stream between You and |
Ooh, nice! Sounds like a very nice start. What are you using to get the packets from live? Wireshark?
Then, you are running a script to decode the packets? Whatever it is, it sounds like a very handy tool when it is complete :D If I had your knowledge, I could do some real damage :P For now, I will just keep fumbling around and researching. I imagine that getting the friends list and maybe even titles working wouldn't be way too hard. I think I have all of the needed opcodes, so it would be a matter of pulling out the names that are sent for the friends list and doing a who query on them for the client. And for Titles, I imagine we would need a new table that includes the Title name and multiple fields for requirements to meet (like total AAs, etc). I know friends list and titles seem small, but every little thing adds up IMO. I know that one of the main ones everyone wants to see working are LDoN Adventures, including the points and merchant systems. This would probably be considerably more complex to get working. I think bazaar would be a really cool one as well. And, I don't even think bazaar would be all that hard to get working. Mainly, everything that /becomenpc does is what turning /trader mode on needs to do. Then, just have a table for items for sale, and maybe gather a couple more missing opcodes for purchases and stuff. Still, getting any of these system working is over my head. Eventually I hope to understand the code well enough to get at least some working. I have already learned quite a bit since I first started looking at the code. |
I used pcap; in this winpcap and just made my own program; hardest part was getting emu code to work outside of the emu(could use some portability) and figuring out that ntohl() can change the byte order of const* data if I'm not careful. -.-
The biggest problem probably isn't the opcodes; even on titanium there's only a few opcodes missing here and there, changing structures is what is really hard. And is also why anniv is stalled; we have the opcodes to get in to the game but once you do everything is messed up because the structure of packets has significantly changed. |
Ya, I figured that the packet structures were changing and causing issues as well.
So, if we do ever start working on getting anniversary edition or another version of EQ working, we have to update the opcodes in the .conf files, but we also have to update the /common/patches/<client version>_structs.h? Looks like maybe the /common/patches/<client version>.cpp might need to be updated as well. In general, are the packet structure changes a complete restructure, or just minor changes that still keeps most of the previous packet structure in place? Or would the entire structure need to be redone from scratch for any that change? Last night I made a discovery that I am sure some of you were already aware of, but I wasn't and I thought it was worth mentioning here; ShowEQ is still being updated and is current with EQLive! I had just assumed that ShowEQ was abandoned in 2003 or 2005 and was replaced by MQ. I know that much of the info in the opcodes .conf files was attained from ShowEQ. So, wouldn't ShowEQ be a useful tool in finding Opcodes and maybe packet structure as well? I would think that it might be a good packet collector for this project, but I could be wrong. Maybe even some of the source code in ShowEQ could be useful in updating the Emulator source to work with later versions of EQ. I haven't found an archive of ShowEQ versions, so I don't know if there is a version that might work with Titanium or Anniversary Edition. But, I think the current one could be useful in maybe getting fully patched version of EQ working with the emu. ShowEQ has install instructions for Redhat and Mandrake, but I run Debian, so I am still working to get it to compile properly. I have been able to get the ./configure to run, which is supposed to auto configure so that the make will run without errors, but the make is still erroring on pcab stuff. I will keep messing with it. Hopefully, once I get it running, I can find out more info on if it will be useful for this project or not. I have already pulled many of the opcodes in the current Live version of ShowEQ and put them in my live.conf file. But, I haven't reset my server yet to see what results from that. I am trying to look in every direction possible to find a helpful solution for getting the emu updated. Ultimately, I think it would be best if I could understand the output from IDA Pro, but I can't make much of that yet... So, I am trying it from other angles until I learn more. Here is the link to the showeq website: http://www.showeq.net/ It includes a link on that page to the current version of the source. |
Quote:
Quote:
|
Thanks for the input AndMetal. I saw that post, but I guess I forgot about it lol.
I was looking for packet structure as well, because I assume they have to have at least some of it defined for showeq to be able to read data packets and pull what they need from them. From what I could tell, they do seem to have some kind of packet structure code, but it is done in a completely different format that what the emu uses. Someone with more code knowledge would have to look into that to see if there is anything useful, because I can't tell. Though, they did seem to have some info on systems that the emu still needs to get working, like bazaar, ldon, titles, and others. I did finally get showeq running on my Debian box, but I need to move both PCs to share a hub so that the packets can be sniffed and I didn't want to do that last night since it would affect my players obviously. I will try to put a hub in the next time I reboot the server. Then, I can get a look at what it shows for Live at least. And see if there is anything useful coming into it. I would still like to find the source for one of the eq packet collectors that were developed to help find all of this stuff. Maybe the packet decoding, compression and other stuff from the showeq source could be used to update the packet collector. |
Talked with fnw a little bit about this in regards to live he listed 3 steps that he would take to find out opcodes and structures for any given client:
1: Steal from showeq 2: eqopfinder used to be good at finding recognizable packets once you had a good foundation and that the info gained from showeq was probably enough. 3: after that just digging through logs with collector and trying to identify any OP_Unknowns. Of course how well these methods work now is up in the air as well ...it's been a while. |
So, other than eqopfinder, I think we might be on the right track so far. If only I could make heads or tails from the SEQ source for packet structure lol.
|
/keys appears to be 0x68c4. I don't see it in the Titanium Opcode file.
Also, /emoteworld and /delcorpse appear to have the correct opcodes, but do not work. |
Quote:
The main current issue with the /blahblah client commands (as far as GM level commands) is that they're all flagged at the same level within the source. That is, if you can /zone, then you can also /summon. You would also be able to /delcorpse and /worldemote, etc. At some point, those client commands needs to be added to the commands table (or possibly a separate client_commands table) where permission levels can be assigned more granularly. Dax |
All times are GMT -4. The time now is 07:08 PM. |
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.