Understanding RDF in 4.3.4

So I was trying to figure out what happened to random dungeon finder (it’s “broken”), RDF in 4.3.4, but I’m stumped so far on it. I noticed that all the CMSG and SMSG for RDF are set to STATUS_UNHANDLED, so I tried changing them to somewhat resemble a workable one.

Obviously it failed lol. I debugged parts of it and came upon WorldSession::HandleLfgJoinOpcode(WorldPacket& recvData), and there, I found that numDungeons in the code doesn’t actually read the amount of dungeons the client checks in RDF… Now, I checked this against a workable RDF and I noticed that numDungeons does indeed read what was checked. So something changed on how clients send their RDF requests.

Since numDungeons was only needed to count how many dungeons to parse from the packets, I thought about just reading all the content on packet and simply shoving it into LfgDungeonSet newDungeons. It worked, or I thought it did because numbers went in. But on the next part, JoinLfg, the data it parsed wasn’t usable.

So, yes, I’m stumped on that one /emoticons/default_smile.png. Is there anyone working RDF or has someone figured it out yet?

4.3.4 is considered Alpha, which means unsupported, and expected to not work correctly, I’m sure someone set them to unhandled, just to get the core to run without a bunch of errors or crashes, and has not gone back and implemented the opcodes correctly, yet.

And, for those others reading this who are always saying things like “But, I saw many private servers running Cata/MOP already” they are running this same, crippled version, or, one very similar to it, that allows the client to login, and, maybe run around and kill some things, etc. but, does not work much, if any, better than what you see here… sometimes, it is not enough to just be able to connect (look at how mangos had wotlk for a very long time, but, no working vehicles at all…) people using TC 4.3.4 as a public server, other than breaking the law, are also stealing money if they charge for access, because it just is not in the proper state to be called working correctly. All of that said, people who are not using the current TC 4.3.4 to help find and fix bugs, etc. as this fine citizen seems to be doing, should either suffer in silence, and not ask for any help here, or, go back to using the master branch (3.3.5a) and feel free to ask for support, even if they don’t actually contribute anything to the development, although, they should.

Ahh thanks that’s nice to know /emoticons/default_smile.png.

Well, I did try a few more attempts to unravel this…

So getting the data from the worldpacket sent with 4 dungeons checked:

9, 0, 0, 0, 33554432, 79616, 77825, 78081, 79873

2 dungeons checked (from the previous 4):

9, 0, 0, 0, 16777216, 78080, 79873

I can tell that 9, the first one is same as 3.3.5a’s for setting the roles since that consistently changes whenever I changed roles.

However, I can’t seem to get what that 5th long number is for, and those numbers after it, which I think are your selected dungeons, shifts around depending on how many dungeons selected, so I can’t map those numbers to any dungeon on a 1 to 1 basis.

I’m probably approaching this all wrong so I’ll step back from this to avoid looking like a fool xD.

Check WPP for the correct packet structure, anyways, Warpten is (should be?) working on that already,

^ Correct.