Printable View
I just pushed to SVN the changes that I've been sharing in the helpdesk thread, which resolve the problems caused by the past couple of game patches. I held off on bumping the version and creating a new tarball due to fransick's indication of possible problems. I'd like to make sure he can get it running. I also included stddef.h in message.h since some users have trouble compiling without it. I'm hoping it doesn't cause problems for those that didn't need it.
Thanks r6. I havent had time to try it.
As posted in help forum, compiled fine and is working. I'll set about working on missing opcodes over the weekend. I have that process down and actually enjoy the puzzle it represents more than the game itself these days. Go figure...
Are there any concide notes on howto find opcodes these days?
I'd like to be more help round here than I am currently.
Simplest explanation is probably something like this:Quote:
Originally Posted by Spanners
0) Hurry up and read this post before the next EQ patch comes out
1) Startup a stable version of ShowEQ
2) Click Network -> Log -> Zone Data (or hit F7)
3) Login a pet-class character to EQ to a mostly quiet zone like Arena, Guild Hall, etc.
4) Create a pet
5) Dismiss the pet
6) Kill a mob
7) Rename ~/.showeq/logs/zone.log to ~/.showeq/logs/zone.log.yyyyMMdd
8) Preserve that renamed zone log file for when the next patch comes out
9) On patch day, repeat steps 1-6
10) Compare the new zone.log with the preserved zone.log and try to match the packets with the new opcodes
11) Update zoneopcodes.xml with new opcodes
12) Rinse and repeat until satisfied
Those steps will work for patches that don't change structs. For heavier patches, it will likely require digging through the zone.log packet dumps with a fine tooth come to re-align the structs.
Working on more opcode updates tonight... already have a bunch updated but you guys had most of the critical ones done already!
Thanks r6express, I'll do 1-8 now and await patch day ;)
great stuff.
SVN updated with opcode updates. Also made a slight change to interface.cpp to ignore struct match on groupinvite.
Didn't increment the version number just yet as I am hopeful I'll be able to make a few other fixes this week (not traveling for change). Just need to better understand r6express' changes... now if Sandy doesn't knock out the power...
Fransick,Quote:
Originally Posted by fransick
The charProfileStruct change is now modeled after how the spawnStruct is populated. Instead of doing a simple byte copy from the packet data into the charProfileStruct, it now starts at data byte 0 and dynamically reads each piece of information and then puts it into the correct struct location. I had to make this change because EQ now sends dynamically sized information, primarily related to string sizes. Specifically, the potion belt or bandolier data segments were compacted to a set of dynamically sized strings instead of a hardcoded string length. This made the packet smaller but forced us to read the charProfileStruct more intelligently. If you look at the new function called fillProfileStruct(), you can see how it starts at byte 0 of the packet's data array and starts to read each individual piece of info. Also, I noticed that apparently for a very long time showeq was making a lot of assumptions about how many array elements are in the object arrays embedded in the packet data. However, I found that each array inside the packet is prefaced with the array length. So my new function first reads the array length and then iterates across that count, populating each new array element. So it's now less brittle for those occasions when SOE increases the amount of elements stored in the arrays. That said, there are still several MAX_*** constants that should be removed from showeq and instead the charProfileStruct array should be instantiated based on the dynamic count I'm now reading in the packet. I didn't take the time to clean that up because it was busy work and I didn't have a lot of time to spend on it. Also, some more cleanup would be to remove all those now unneeded filler struct members like unknown00801, etc. Since we don't fill the struct in one big byte copy those filler members are pointless now.
I'll try to check the forums more frequently in case you have more questions.
Very cool... I'll see if I can make heads or tails of it all and do some of the busy cleanup. I have very little programming experience (read that as none in fact) so it is a bit of a jigsaw puzzle exercise for me but I enjoy the challenge and the learning that comes with it! As soon as I have some time at home, I'll see if I can get after that busy work.Quote:
Originally Posted by r6express
Somewhere Ratt, Dophaz and others are cringing that I am playing with code...
I just turned on email notifications for my forum account, so if you want me to do a quick review when you're finished, PM me or reply here and I'll come a'running.Quote:
Originally Posted by fransick
Just a quick FYI. Got hit hard with sandy. Still no power. 3 1/2 feet of water. Heater and water heater shot. No inet at place Im staying. Hope to get back to normal soon.
Fransick, no one is going to cringe. It's great that you're getting your hands dirty. It is people like you that have showeq going over the years through many different sets of developers. I didn't know what I was doing when I started either, but through the patience and help of ksmith, Doodman, FatherNitWit, Quackrabbit and others, I eventually knew what I was doing.
Some of those MAX_ constants are used cross-struct in everquest.h. Some are used to malloc UI data. Someone who wants to clean things up should just remove them all, see what horrors happen, and clean up the remains.
i feel for those in need. Good luck BA.Quote:
Originally Posted by BlueAdept
You are doing a bang up job Fran. Keep at it. Everyone appreciates your hard work.
Razzle