I guess I am going to break down EQLive and see what each Opcode is so I can get an accurate order for what packets should be going when. Using SEQ, it shouldn't be too tough to get that all sorted out. Once I know the specific details, I am hoping to try them on SoF and see if it works.

Here is what I have so far:

I will edit this list as I can make more confirmations. It shouldn't take me long to figure out most of this list. I can tell for sure that some of the orders have changed, so I think if I can get that sorted out, it may work almost flawlessly for SoF.

I stumbled on a new struct last night. It doesn't really help this effort much, but it is probably worth noting for use later when we might be able to actually put it to use. There is a feature on Live that was in SoF as well, but not in Titanium. The new feature let's the client set certain spells to be blocked from hitting the client. This is for keeping buffs from overriding each other if you don't want them to.

The EQLive opcode for this is 0x0baa and I found the SoF opcode for it too. I built a struct for it with placeholders just to have something in place for it even though I don't know the values for it yet.

I also confirmed that EQLive now has 60 pages in the spell book as apposed to 50 in Titanium. This means that the MAX_PP_SPELLBOOK is now 480 in EQLive and probably in SoF as well. They had to add it when they upped player levels to 75, so I am sure it was in SoF, otherwise druids and maybe other classes could have overflowing spell books.

I am sure that most of my struct for SoF are correct or very close to it. I think I am just missing something minor that is keeping me from getting past this point I have been stuck at for the past couple of weeks. If I can just get pass that point, I feel that the rest will be much quicker and easier. My current guess is that I may not have all of the right opcodes being encoded on the way out that need to be for SoF. The client is expecting a 0 size opcode 0x1FA1, which is new since Titanium. Basically, it seems to be the same as SendExpZonein, accept instead of server sending that and getting it back from the client, it now sends this new opcode and waits for the SendExpZonein back from the client.

From looking at the EQLive logs, it looks like almost all packets are encoded now, at least while entering a zone. Maybe I have to set them all to be encoded for the client to get all of the info it needs for logging in. That is going to be a bit of a pain, because as far as I can tell, I have to create the handling stuff for each opcode that needs to be encoded. If there was a way for me to just set an opcode to be encoded in the Anniversary_ops.h and then only have to tell the Anniversary.cpp to use the structure for encoding, that would be pretty easy. But, it looks like I need to do something more like this for each one:

I'm not exactly sure what the OUT stuff means, but I am guessing that all of the stuff set to go OUT is the stuff that gets encoded. If so, then I wonder what happens to stuff in the structure that isn't set to go OUT in the ENCODE. Does that stuff just get ignored?

Long time lurker, 1st time caller. . .


This work you've been doing is very exciting. With the last ever boxed edition of EQ1 possibly being SoF, this is a big step. I have been looking through the wikis and the forums, and trying to find some up to dat info on if there is anything someone with an active eqlive account can do to collect information for the Devs.

Let me know if there is something that can be done with no experience besides setting up a mini login server in the basement.

Thanks,

Greldor
The Grand Creation

my god man...
 

i didnt believe in intelligent machines until i read this thread.

Trevius isnt human i tell you! he is the real life Bender!!!!


you're awesome man, good things are comming peoples!


on a nearly equally pointless side note. every time i type/read Trevius' name i think of Golan Trevise from the Foundation series. :) any relation by chance?

The ENCODE/DECODE is used when the struct is different between Client versions.

ENCODE 'encodes' packets on the way out, from the server to the client, and DECODE does the reverse.

The ENCODE is a translation from the struct in common/eq_packet_structs.h to the struct in the client specific struct in patches/<Client version>_structs.h.

To take your example for OP_ManaChange. The 'EMU' struct for this, in common/eq_packet_structs.h is:

while the Anniversary struct is:

As you can see, Anniversary has an extra field at the end of the struct.

Essentially, the ENCODE section in Anniversary.cpp is copying the fields from the Emulator version of the struct to the version that Anniversary edition needs. I think the outgoing packet is filled with zeroes before the ENCODE takes place, so unknown12 and unknown16 would be zero.

For each struct that has changed in SoF, you would need to map out the fields in the new structure and add it to Anniversary_structs.h, add the Opcode to Anniversary_ops.h and do an ENCODE in Anniversary.cpp.

You would also need to do the same for Client to Server opcodes where the struct has changed, but this time do a DECODE from the SoF client structure to the Emu struct.

@ greldor - Thanks. I wound up paying to get my old EQLive account active again. I am currently using ShowEQ to watch all opcodes from Client to Server on Live where I need to be looking. Right now, I am still working on just logging in. Once I can get past that point, I think it won't be too hard for me to break down each individual structure that has changed and get them updated as well as start filling in missing opcodes. I have switched directions for now and am going to see if I can get the emu working with EQLive. It should be much easier to get it working with Live, because I can see exactly what the client wants and is expecting from looking at the SEQ logs. Then, even if I don't know what a certain packet is, I should be able to just duplicate what I saw the Live server sending from the SEQ logs and trick the client to log all of the way in until I can fill in the missing information. There isn't really much other people can help with right now until I can get logged in all of the way. Once I do that, I will update the SVN so others can assist in filling in and updating opcodes and packet structures and making any other needed tweaks to finalize it. I am not planning to try to chase Live by making the emu work with it, I am only trying to get in on an EQLive version because it should be easier than SoF. Once I get in game with the EQLive version, I will try to work backwards and get SoF working with it. I think that will be much easier than trying to work from Titanium to SoF, since Live seems much closer to SoF than Titanium is.

@ unknownhost - No, no relation to the name. My avatar name is named after my nephew Trever, but with a fantasy twist to it :P I am definitely no machine, I am just persistent enough to keep going even when I am failing miserably. There are certainly a few people on this project who have much more experience than me and probably would have had this working by now already. Unfortunately, none of them have SoF, and more importantly, I don't think they have the time needed to do it. I am more than willing to do all of the grunt work in getting this stuff to work, but I admit it would be nice if one of the more experienced people were able to help figure out some of the more problematic issues (like currently being stuck at the first main loop). The big time involvement here is getting each of the needed opcodes and verifying they are accurate, and also getting each of the packet structures and verifying they are as accurate as possible. To the point I am currently failing at, I think I have all of the required opcodes and most of the packet structures should be good enough to be working for it. I haven't worked much past that point yet, because there isn't a point to until I get to the point where I need them. I didn't know anything about coding 8 months ago and have only learned by examples from reading the emulator source code and working on it. I have learned alot and learn new things every day, but I am sure the more experienced people would probably be able to help alot if they had the time. I will keep working away at it and will get it eventually, hopefully. All of the time I am working on this has really forced me to learn things I wouldn't have otherwise, so that is actually a good thing, but VERY time involved. It has officially been more than a month that I have been working on this so far, and I have worked on it for hours every single night. I made alot of progress in the first week or so, but since I got stuck on this main loop, I haven't been able to get past it. At this point, I still don't know what is causing it to hang up at that point. It could be anything from a wrong opcode, packet structure, something else missing, or whatever. Without logs directly from a packet collect (preferrably from SEQ) from when the SoF eqgame.exe was being used (patched Sep 7th 2007), it is hard to know exactly what might be missing. That is why I am hoping getting it working for EQLive will help me work back to getting SoF working.

@ Derision - Thanks for the info :) So, any opcode that isn't added to the patch_ops.h will use the eq_packet_structs.h for their structure? I have tried adding a few new opcodes to the anniversary_ops.h and it requires me to put structs into the eq_packet_structs.h for it to compile. If it is supposed to be using the anniversary_structs.h, then why does it require to have a struct in eq_packet_structs.h as well?

The main thing I am trying to figure out is how to know which packets are encoded/decoded. Is it only the ones that are put in the patch_ops.h and set to be encoded/decoded, or are all packets automatically encoded/decoded by default? The only raw packets I see from live are the acks and some of the sessions and network status stuff, everything else is encoded and some is also combined.

I am also trying to understand why anniversary.cpp seems to be telling the server how to handle the opcode packets, but we also have client_packet.cpp, which has handling instructions for each opcode as well. It seems that anything I add to anniversary_ops.h and anniversary.cpp also has to be added to client_packet.cpp. I am not really too clear on what is going on with that just yet. It seems like there is redundancy in some of this stuff and it makes it more complex for me, heh.

I verified most of the opcodes I need to get logged into the emu with an EQLive client last night. I just have to fill in a couple more and then adjust a couple of structures slightly and I should be able to at least get to the same point I am at trying to get in with SoF. I was able to get almost all of the player profile for EQLive mapped out just by looking at the SEQ hex output. I still have a bit more to do to finish that struct 100%, but it should be pretty accurate when I am done with it, at least for Live. But, Live and SoF have very similar structs. They are much closer than Titanium and SoF are.

First thing to say is that what ShowEQ shows as a 'Decoded' packet has nothing to do with the with the EQEmu ENCODE/DECODE terminology.

You are correct, anything that isn't in <patch>_ops.h just gets passed straight through using the common/eq_packet_structs.h structure for that Opcode.

By putting an Opcode in anniversary_ops.h, you are saying that this Opcode requires the struct to be translated from the version in common/eq_packet_structs.h to the version in Anniversary_structs.h, hence why you need a copy of the struct in both files. If the Opcode is a new Anniversary-Only opcode, you don't need to put it in Anniversary_ops.h, and if there is a struct associated with it, you can just put it in common/eq_packet_structs.h.

The only time you need to put something in Anniversary_ops.h is if the same opcode exists in 6.2/Titanium and/or Anniversary, but the structs are different. In that case you need to put the SoF struct in Anniversary_structs.h and code in Anniversary.cpp to encode the struct from the version in common/eq_packet_structs.h to the version in patches/Anniversary_structs.h to account for a different order of fields in the structure, or new fields, etc.

The only packets that are encoded/decoded for a particular client version are those listed in patches/<patch>_ops.h . All other packets are passed along using the struct in common/eq_packet_structs.h. As I said, encoding/decoding is only required if the packet struct for a client version (SoF in this case) is different than that specified in common/eq_packet_structs.h

As above, when SEQ says it has 'decoded' a packet, this just means it recoginised the EQ Application Opcode and doesn't correspond to the encode/decode terminology used in EQEmu.

Anniversary.cpp isn't telling the server how to handle the packet. It is telling the server how to translate the struct associated with that Opcode from the version that particular version of the client is sending into the structure that is in common/eq_packet_structs.h. Once the struct the client has sent has been translated into the 'emu struct', the Opcode is then passed through to client_packet.cpp to handle.

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

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.

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.

this may help
 

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

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.

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

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

He probably means he was able to hit the login server, not actually functionally connect.

No, I wasn't even able to hit the Login Server. Thanks for confirming that it works, KLS! Now to figure out what I am doing wrong lol. I should know how to do this by now, LMAO!

Evozak, as long as I don't patch past the point my client is at now, I don't have to worry about the structs changing. I am not trying to get the emu to work with live and have us chase live as we did in the past at one time. I am just trying to get in game with Live for now so I can hopefully use some of that info to figure out what is stopping me from getting in with SoF. Since I have the exact breakdown of the structures (or at least I can see the actual packets from live with SEQ), I should be able to get everything I need set correctly to connect. I am hoping that if I can get in with a Live client, that I can use that info to help me figure out what is stopping me with SoF. If I have to, I should be able to force the exact packet structures from Live just to trick the client to logging all of the way in. Then, hopefully I can figure out the details later.

Well, I can't figure out why my live client won't connect to the emu LS... If I put the wrong info in the host file, it times out and says to check my network connection like normal. If I put the correct eqemu stuff in the host file and log in, it just hangs trying to connect. It is like it connects, but doesn't know what to do next. The only thing I can think of is that it is something to do with one of my INI files or maybe because I only own up to SoF. I tried messing around with my INI files as much as I could think of, but it didn't make any difference at all. So, maybe since I am using SoF, it has to do some extra check before going to the login server. I would guess it has to do the check to see if I want to purchase SoD or something, and since it is connecting to the emu LS, it fails that check and just hangs.

KLS, does your EQLive client have all expansions up to SoD? If so, maybe that is why you go right through, and I get stopped when it is trying to do that final check. I can't really think of what else it might be. All of my other client versions work fine to get to the LS, including my fresh SoF install from the DVDs. It was only after I patched to live that it stopped letting me connect to the LS.

I just tried with a live client and could confirm the same symptoms as you. Bad info, times out and gives an error. EQLive, connects to server select. EQEmu? Hangs and never gives an error. Extremely odd.

Maybe KLS is running on a trial account client? I thought about using a trial account before I decided to pay to renew my old Live account. Unfortunately, the trial accounts are not the same as a fully updated live client. They have some limited files, and seem to only patch to a certain bare minimum point to be able to handle just the Tutorial zone. I never tested the trial version to see if it could connect to the emu LS, but I imagine it can. Even the UI on the trial version is a really old one (looks like Titanium UI). I tried using SEQ on the trial version and it didn't work at all. So, the trial definitely uses something other than EQLive. That is why I had to just pay to renew my old one instead.

Thanks for confirming that, Secrets. At least I know I am not crazy now lol. I have been wasting too many hours on trying to figure out why EQLive won't connect to the emu LS. Can anyone else confirm if it works for them or not? I would love to get it working to help me progress, but if it doesn't work, there is no use for me to waste anymore time on it!

If you just want live packets dumped out into your eqemu server its simple to connect. EQmain.dll is everquest loginserver. Swap the live one with your titanium file and your live patch will allow you to login to eqemu login server. Dunno how far you will get from there tho.

My EQLive folder is 5.63GB, eqgame.exe modified on jan 9th, eqmain.dll modified on jan 9th.

The acct I patched with has only a few expansions I think whatever titanium had with it. =p

To add another data point, I can't connect to the LS with the live client either. I ran the patcher today, but it looks like eqgame/eqmain haven't changed since December:

I bought the Anniversary digital download a year or two back, so that's all the expansions I have.

Titanium EQmain.dll is 2005 Live patch is 2008 thats why you are not connecting, So swap your live one with the titanium one then you will connect.

They did change the netcode for the live LS recently but it shouldn't of broken anything. They added the ability to force boot your account offline. The basic code is the same, or should be, very odd that it works for both live and emu for me.

Maybe there's something settings dependent, or as mentioned you can just use the older netcode with the titanium eqmain.

Edit: My patch brings me an eqgame and eqmain.dll that don't match those sizes. Puzzling.

KLS, do you currently own an active (paid) EQLive account? As I said earlier, you can patch only up to a certain point if you don't own a currently active EQLive account. You have to log in to patch all of the file, and the only 2 options are having a paid account, or one of the free trial accounts. If you tried with a trial account, then you aren't running the same version as EQLive.

I will see what happens if I try swapping out an older eqmain.dll with the EQLive one. I would think it would have some errors if I do, but no harm in trying.

I have a live eq and eq2 acct. I know right? I'm thinking maybe it didn't fully patch for some reason (I didn't actually try to log into live after patching). It changed my eqhosts.txt so I'm guessing it patched the right directory.

Well there were patch files waiting so I'm guessing that's what happened. =(

Ahh yeah, I think if you haven't patched before, it usually needs to exit and restart the patching again to get everything fully up-to-date. Thanks for the info though. At least I know I am not crazy now lol.

Well I wouldn't say we could come to that conclusion... =p

Well, it isn't much, but I did make a little progress on getting into SoF tonight. I found that I had the wrong opcode for zonespawns that I thought was correct, but wasn't.

Here is the new stuff in the SoF EQ Debug output:

Since I was looking into Item Serialization more again today after seeing a post from Derision in another thread, I started working on it a bit more again. I think I have the serialization stuff mostly worked out. If only I had a single log from someone logging in during SoF (preferable 9/7/07 to 11/13/07), I could get everything working pretty easily at this point I think.

The thing I can't figure out with item serialization is that it seems to be sending the wrong structure for OP_CharacterInventory. I don't even see a structure for it in the structs file. I assume it is all being handled in the anniversary.cpp encode stuff. In the log above, this is the only 1 of my characters that will even log 1 item before it crashes. The others all just fail before getting to the first one. So, I assume it is something about that particular item that is letting it get that far. I don't know what the number 2083552304 means, but that number is supposed to be the inventory slot the item is in according to normal log files. Here is an example from titanium:

2083552304 is 7C307C30 in Hex. Ascii code 7C is the pipe symbol, |, and 30 is the number 0, so 7C307C30 is |0|0 which looks like serialised item data.

I should add that when I was working on the Bazaar, I was looking at some Live traces and *think* that I wasn't seeing item data being sent in a serialised format (didn't see any of those long strings of numbers separated by | symbols that are easy to spot in a packet trace). Maybe they stopped using that format for sending item data at some point.

If SEQ is showing the full packet, then you might be right. It seems more like they have each field broken down into int8,int16,int32,char,str, etc. Here is an example from SEQ from live:

The section highlighted in green is what I believe to be a single complete item. I was able to break down some of the serialization of the item and it is pretty similar to the order I already have set for SoF. As far as I could tell, it matched perfectly, at least for EQLive.

I was thinking the same thing about the number being the serialization. I'm not sure where equip slot is sent, because I don't see it in the serialization.

Here is some of the serialization breakdown I was doing, which was some guesswork and some simple hex converting and comparing to the itemfields list as well as looking at the 13th floor info for this item:

Item Instance Info:

Item Fields breakdown:
So, it looks like strings are separated by 0s and the rest is just defined sizes.

Note: If you scroll up and down on the code box with the green hex code in it above, it looks kinda like the Matrix screen, LOL :D

My guess is that in those packets, the inventory slot is 8 bytes into the struct.

The first item:

Would be slot 0, charm slot.

Second item:

The least significant byte is to the left, so this is 0x000007d0 which is 2000, which is the first bank slot. You'd have to know which slots those items were actually in on the character to confirm.

This ties in with the field order in the Serialized item data in Titanium. If you look in common/patches/Titanium.cpp at SerializeItem, the third field is the slot_id or merchant_slot.

Since strings seem to be separated by a single 0 bit, those should be easy to change over to the new format of removing the pipes | from the serialization. But, for chars and ints, I need to find a way that I can define a certain number of bits to use. It seems like most of them are set to work like int8, int16, int32 or so using 1, 2, 4 or so hex bits for each field. So, I need the serialization to be able to figure out how many bits to send for each field.

For example; If I want to send the Item ID, the example I gave in the last post would be to send "bb 88 00 00". That would be item ID 35003, but it is important to send the last to 0 bits there to make sure the item structure aligns properly. Maybe I could make an actual structure in the structs file to do it, but I don't really know how to pull database fields for structures.

From looking at the anniversary_itemfields.h "TRY NEW" section, it looks like they tried to assign lengths to each field. But I can't figure out how the serialization would work for that. Here is an excerpt from the file:

I replaced that section on my test server a while back and had almost forgotten about it. I didn't understand what the numbers next to the defines were, but it makes sense now, lol. I guess the serialization was changed back when Anniversary actually came out or before it.

Any suggestions on how to change the SerializeItem below to work with the "TRY NEW" itemfields the way it needs to for clients later than Titanium? I don't think it would require much of a change, but I just don't know how to set it to know that "I4" means to use 4 bit even if only 1 of them gets filled with data.

Well, I am trying to work out how to make the serialization match up with how it works now for Live (and apparently since Anniversary or so), but I can't seem to get it to send the integers followed by null (00 in hex) bits.

I copied the function (GetNextItemInstSerialNumber()) to make Item Instanced Serial Numbers similar to how live does it to use in the Item Instancing part of the Serialization. That part seems to be working properly and I will definitely keep that in the final Serialization code. It may not really be required, but it doesn't hurt to copy the way Live does it as close as possible.

I then tried making the changes noted in green below, to force it to send the integers as int32, hoping that it would send them each as 4 bits. It still seems to just be sending the integers, without the 00s after them as it needs to be doing.

I also found the item_struct.h file which I hadn't seen before and it helped me understand how the serialization is working a little better. Basically, the item_struct is just handled in it's own separate file for some reason instead of being included in the eq_packet_structs.h file. So, if I understand correctly, it seems that the patch_itemfields.h files are just separate files to do basically the same thing as the encodes in the patch.cpp files.

I even noticed that the item_struct already has sizes defined for each field like int8, int32 etc just like normal structs. So, I think that I could just use that struct, and edit the field sizes where needed and add them to the anniversary_structs.h file and then do an encode of them like normal. But, I will still need to figure out how to make it send the structure as the size that it is supposed to be. The structure will vary in length slightly, because a couple fields are strings and don't have a set size limit on them. But, other than that, the rest should always be the same size.

O..M..G! I finally got in game! @#$@% WOOT!

Turns out the whole time, the thing that was stopping me was sending the incorrect structure for AA tables. I simply commented out the opcodes for AA stuff in the .conf file and got in game first try! Of course, nothing really works yet, but now that I am at this point, I think things will start progressing very quickly!!! As soon as I can iron a few things out, I will get this stuff on the SVN ASAP. I will try to add new files for it so I don't just overwrite the current anniversary files. I just need to figure out how to create new patch files and I will get them up. I will knock out a few more opcodes and clean up packet structures more too though, so it is less messy than what I currently have for it.

I am VERY excited!!! I have been stuck at the same point for over a month now! I will have more updates here shortly! Things are looking bright :D

Excellent work Trevius!

(I know you don't want your thread cluttered up, so feel free to delete this post :) ).

LOL, Thanks Derision! No worries about the clutter. After all of the hours it took to get past that part, I am glad to see a reply :)

I am still working on figuring out some of the unknown opcodes I am getting from the client atm. I may be able to have something up tomorrow night.

I forgot we had message boards. I admit it.

you are a god, keep it up. If I was any good with graphic design i'd photoshop your avatar onto Jesus.

k, maybe not THAT far.

but good job!

WAY TO GO!

Well done Trev, that is so exciting!

All I can think of is this.....


"I think and think for months and years. Ninety-nine times, the conclusion is false. The hundredth time I am right. "
~ Albert Einstein



Way to go and a big round of applause 8-)