Starting Work on SoF Opcodes/Structs

[trevius]

Thank you VERY much, Derision! Understanding that better should help me quite a bit in getting more work done on this. It sounds like I will just have to look at the current examples of how the conversions from struct to struct depending on the patch version are being done. That sounds like it might be easier to do than I originally thought it was. I will check the files now that I have your explanation and hopefully I can make more sense of what is going on so I can get things adjusted properly where needed. When I got into working on this, I was under the assumption that it would just be finding opcodes for it and redoing structs where needed, but it seems there is a bit more to doing that than I originally thought.

All I know is that when I finally get past the point I have been stuck at for the past few weeks, I am probably going to yell loud enough to wake up my wife and daughter :P

[trevius]

After just looking at it quickly to see what is happening, it gave me a couple more questions;

It looks like unknowns are commented out in the Titanium.cpp ENCODEs, so I am wondering if the unknowns are somehow handled/converted automatically, or if they aren't needed at all. Doesn't it still need to know where to send unknowns out at to fill in the gaps?

The other question is about (OUT) vs eq-> usage. Some of the ENCODEs have (OUT) and then the struct field name. But, some of them have something like this "eq->deity = emu->deity;" instead. My guess is that they are both doing the same thing. If I am right, then "eq" is saying to get the eq_packet_structs.h structure and "emu" is saying to put that item from the structure into this position for this patch version. If I understand correctly, that is the same thing that (OUT) is doing. So maybe the eq = emu way is just the old way?

I have seen some warnings about eq and emu not being used when I am compiling. I am guessing that is because I was making blank structs, which also means blank encodes/decodes. And since they are blank, the eq and emu variables aren't being used, so it warns about it. Now that I think I understand it better, I don't think I should need those blank structs now to begin with. If I want to send a 0 size packet, I guess I can just make the new op and then have it get sent when needed directly from the client_packet.cpp. I don't think I would have to add anything anywhere else for them. I will mess with that more later tonight.

[KLS]

OUT(x) is the same thing as: eq->x = emu->x;

When you do your var allocation at the top it allocates both emu and eq; emu being the source struct from the emulator, eq being the dest struct that's going out on the wire.

That's for outgoing packets, as you imagine it's reversed for incoming. When you're decoding an inc packet IN(x) is the same thing as: emu->x = eq->x; and eq is the source from the wire and emu is the dest to the emulator.

[greldor]

As a side note, If anyone needs SoF to aid Trevius:

Newegg.com has Secrets of Faydwer for $19.99
with free shipping!



Greldor
The Grand Creation

[trevius]

Well, it looks like EQLive may no longer be an option at all for the emulator. Unless I am doing something wrong, I can't even get EQLive to connect to the eqemulator.net login server. I tried messing around with my host file (windows host file), but that didn't make any difference. I also tried adjusting my ini files in the EQ directory, but that didn't help either. I put in my username and password and hit connect, and it just hangs there indefinitely saying "Logging into the server. Please wait..." It never actually connects to the eqemu login server, and it never seems to time out either, it just stops doing anything else.

My guess is that they have some new opcode or structure or maybe encryption when logging into the LS, and it doesn't match what our LS uses. And, since we don't have access to the LS, it means we are basically out of luck other than developing a new login server (which has been discussed a little).

It isn't the worst thing in the world that the emu won't work with live anymore, but it does probably slow my progress down. Really, as long as I can get in game with SoF, that should be most of what I need to start working out the rest of the details. I mostly just need to get past the point I have been stuck at. The fact that EQEmu may not be able to work with EQLive is another reason why SoF is probably our best bet for a final version upgrade.

[KLS]

I connected to EMU login just 1 minute ago with a fully updated client so it must be: I am doing something wrong =p

[EvoZak]

Wow, how are you getting anything done with a fully patched client? Tomorrow's structs could be different from today's. Craziness.