looking for a shove in the right direction...

[The Mad Poet]

Does anyone have a good primer on structs and opcodes - I would like to understand what is going on and how you guys are figuring out the info in the packet to make the changes.

If anyone has good info like that please post a link =)

[Alfred]

Well the first question for you... is:

What do you know about programming in the first place? What type of programming, if any?

[Poncho]

That reply sucked...... We all have to start somewhere, and his question is very valid. I'd like to know (and learn) this information as well so I can actually lend a hand from time to time.

If we had more people like that - just imagine~

Any place to start? Digging into the code cold is one way. Getting at least a couple good leads and some structure sure goes a long way to helping.

I honestly havnt programmed anything since basic (for the most part) and I suppose that is before most of your times, but I used to be able to write some mean stuff for the time with a little guideline from those that learned it and worked with it before me. I, in turn was able to pass the knowledge along to others. Isnt this what opensource is all about?

Direction would be great. I'm willing to sit and learn.

~Poncho

<<edit>>
After reading my own post, and the reply, I was assuming that Alfred was being fecitious in his reply. If this is not the case, and that reply was setting up to figure where to start helping, I sincerely appologize to Alfred.

[The Mad Poet]

I program in C++, I am fairly comfortable looking through code and trying to figure out what it does.

I'm assuming you guys are reading the packets with a sniffer then figuring it out by the data in the packet - but that's what I'm not sure of how to do.

Knowing the structure of a packet and writing a program to use it is not difficult - what I'm not sure of how to go about is the dis-assembly of the packet to figure out how to code for it.

*edit* I usually use C Builder for my programs and in the keygen section you can find a post where I wrapped a key gen into a graphic interface using builder... if that helps you guage where I am programming wise...

[datadog]

I didnt care for the reply either..

Dont know C++ well, but I do know networking well and linux well enough..

I would love for someone to put together a quick how-to on correcting the opcode/packet structure problems after patches..

Not asking for a white paper.. just enough info to get started...

I have been trying to find a way to contribute to the project more. I was thinking that this MIGHT be way to do it.. /shrug

[iluvseq]

Existing packet structure info is largely in everquest.h

opcodes are in opcodes.h

I'm not sure on the newest nity grity details, since the compression changed things a bit. Mvern clearly gets it :)

However, in the "old" days. Each packet came in with an opcode that allowed you to match it to a struct.

When patches came out, sometimes SOE would change what opcodes matched up to what structs, or they would modify the various structures a bit, or both.

Now, with the compression of packets in place, I believe each packet must be de-compressed before you can get at the opcode, but after that, it's largely similar to the way it was before.

I could be wrong, however.

I know showeq has an option to log invalid opcodes (ie: packets that come in with an opcode that doesn't match one in opcodes.h)

Also, if you witness it giving you errors regarding struct size mismatches, this generally means that SOE has changed a structure a bit (or that the opcode has changed) either way, you can set showeq to log packets that match a specific opcode. Then you can analise those packets, to determine if (a) they represent a different packet (opcode changed) or (b) they are just a tad off from the expected packet, but with different structure (struct change)

Once you've narrowed it down, you can start fiddling bits in everquest.h and re-compiling till you've figured out the new structure format.

Hope that helps some.

[fryfrog]

what the heck was wrong with the first reply? the guy was just asking what kind of programming he knew to get an idea of how to answer the question. he didn't even insult mad, just asked him what kind of programming he was into and how good he was.

maybe mvern will post and tell us how he does it, but i would bet it is some combination of playing the game (and doing the SAME thing over and over in an unbusy zone with no one around) and watching the packets in something like ethereal or tcpdump or something else. but that is just a guess :)

[Mr. Suspicious]

Aye, that's pretty much the only way to do it fryfrog. Do stuff ingame, watch what packets you are getting, analyse it and start to learn.

[suseuser7341]

Actually there is some log option within SEQ that helps with the encryption/compression. Please don't ask me where, but I know I stumbled over it some time ago.

[Ratt]

In my experience with any language and project, to get started... pick a feature, preferably something small/easy to do, that you'd like to see, and try to impliment it.

In my case, with SEQ, I started working with Maps of all things (if any of you remember, I made a good portion of the Kunark dungeon maps, etc... my best one is still Howling Stones, took me hours for that sucker).

Then I moved on to little bug fixes and tweaks, and then the project died on Megatons server and was down for awhile.

Finally, I gathered all the posted diffs, put 'em together and fixed a few bugs and opened a SF account... and here we are, 3 years later. (Christ, it's been that long)

A number of people on the project have come and gone, and I think it's great. That's what Open Source is all about. I miss the guidance and chats I have had with those people in the past, but I also understand the need to move on, and losing interest.

But I digress... I'm old and wax nostalgic now and then... Anyway, just pick something and go for it... supply a diff. Keep the diffs coming, and eventually I or Fee will give you dev access to make things easier on everyone.

I don't hand out dev access very readily because of the nature of the product, and the potential for abuse. I've always had, and always will have the best interests of the players as my driving force, and because of that, we have to be careful of what's put into the CVS... because I'll wager most of you don't review the new code each time there is an update, and even if you were, a vast majority wouldn't even know what they are looking at. That's what us, as the devs, are here for ... so it's a fairly responsible position to put someone in, and I need to make sure that person can handle it.

Diffs, diffs, diffs are the path to becoming an "official" dev, whatever that is.

[datadog]

Thanks Ratt... Excellent advice..

Just to be clear..I definitely wasn't looking for a 'how to be a dev' post or anything.. just looking for a way to use some of my existing skills in networking to contribute to the project.

I do have some experience in packet and protocol analysis as part of my job, and I thought the learning curve for helping with finding and correcting the broken opcodes might be a way to contribute. /shrug

I remember a few patches back (PoP?) where a bunch of folks where posting proposed opcode changes on the Dev forum. This got me thinking about it. The public posting of opcodes changes seems to have quieted down the last few patches, and now folks like mvern are doing their work behind the scenes and submitting complete patches to the devs.

Anyway, it was just my concience poking at me to find a way to help. I'll take your advice and poke around in the folders and see what I can find.

Thanks again for everything.. to all those who contribute...

[Alfred]

Originally posted by Poncho
That reply sucked...... We all have to start somewhere, and his question is very valid. I'd like to know (and learn) this information as well so I can actually lend a hand from time to time.

If we had more people like that - just imagine~

Any place to start? Digging into the code cold is one way. Getting at least a couple good leads and some structure sure goes a long way to helping.

I honestly havnt programmed anything since basic (for the most part) and I suppose that is before most of your times, but I used to be able to write some mean stuff for the time with a little guideline from those that learned it and worked with it before me. I, in turn was able to pass the knowledge along to others. Isnt this what opensource is all about?

Direction would be great. I'm willing to sit and learn.

~Poncho

<<edit>>
After reading my own post, and the reply, I was assuming that Alfred was being fecitious in his reply. If this is not the case, and that reply was setting up to figure where to start helping, I sincerely appologize to Alfred.

Wow :)

Yes I was really trying to get a better feel for what our friend knows int the first place. His post was was extremely open ended. You can't really help someone in these cases until you help them clarify thier own situation.

Anyhow, it looks like others have answered the question a hell of a lot better than I could. My programming is more along GIS mapping in java of all things, with a previous life in C.

[Poncho]

I stand corrected Alfred. I did take your reply in the wrong context. I guess I was expecting a flame right off the bat. My appologies friend.


Looking for some simple exercises to put myself through to learn this stuff. This is going to be a hoot. I am not so much interested in the Opcodes - moreless the general framework of the SEQ skeleton intrigues me the most.

~Poncho