How I got SEQ going again...

I spent two days and alot of bandwidth trying to get my skittles back. I finally succeeded by using information from about 5 different areas. I felt I would list them all here and hopefully save someone the effort.

This is how I got SEQ skittles from a CVS reload. I linked the references where I could.


1) I renamed my old ~/showeq directory and then created a new empty /showeq directory for the new files.

2) Connected to cvs and did a new complete download. See SEQ FAQ step 2.5

3) cd to showeq directory and cp libeq.h libEQ.h

4) Apply Zoolander's 06/20 patch which places two files into your ~/showeq/src directory.

5) Apply Zoolander's 06/25 patch which patches your opcodes references.

(At THIS point.. I personally did a make && make install, but I am pretty sure it is not necessary to do so.)

6) Apply Merrilin's quickfix patch.

7) Do a recompile.


If you are as lucky as me. Skittles!!!


If anyone has any problems with this procedure I will gladly edit/delete as necessary. Just hoping to help out some who may have problems following the trail as I did at first.


Cryptorad

Nice post cryptorad :D

2 little things :

- at 3) use mv (move) instead cp (copy)
- the make after Point 5 is not nesscecary :)

Don't forget to download the new Veksar Map and copy it in your ShowEQ directory ;)

Great post anyway Ty =)

Quote:

---

5) Apply Zoolander's 06/25 patch which patches your opcodes references.

---

I took this patch and compiled, and had skittles.

Quote:

---

6) Apply Merrilin's quickfix patch.

---

I tried applying Thom's quickpatch.diff, and I was getting patch messages like 2 out of 2 hunks failed, and reject files were made for each of the sourcefiles.

I then tried to recompile and got alot of errors. I do not know if you actually need the quickpatch.diff or not, so I went and tried a few other combinations of this quickfix.

I went through and did everything over and did each step without a recompile, same thing.. so.. I left Thom's quickpatch.diff out of my 3rd try and had skittles again...

One thing I do notice, is mob updates are not "live" sometimes even player data is not, usually happens when the players are not close to you and the sync packets are sent slower. Reason I say this, is that I was trying to locate a player that was lost in Kael, and when I reached his location on ShowEQ, the player was not anywhere near that location, and it changed as I got there. Then it showed his location in a different location. I finally told the player to stop and not move, in order for me to find them.

This also happens on mobs that are not in my immediate location. I go searching for a mob and find it about 60% of the time, the rest of the time... as I get near the location.. it changes and shows the mob in a different spot.

I think this goes to the structs of the packets.. not sure.. as I am learning and slowly finding what goes where..

is there a packets.cpp discussion I can look at, or can someone point me into the right area for this?

Does interface.cpp set the promiscuous mode of the nic, right?

Where packet.cpp calls the object, interface.o after compiling interface.cpp, or does interface.cpp call packet.o after compiling packet.cpp? (that eludes me and is basically irrelevent to the discussion, as I am just trying to figure out the "Flow" of the compile).

I learn fast, and I did find a packet.cpp discussion that was about encryption, but not about the nature of the question that I am looking for an answer on.

Someone compile me a comprehensive PATCH, and I'll apply it after review.

Please make sure it's a valid patch that I can apply with patch :)

I have NOT revied this, it's simply what I used to get it working. I normally use mySEQ instead, but I often load up Showeq to compare diffs and when in PoG and need to see the spawn points of the pogs for timer.. ;-)

Anyway, have it it. The 'and' is replaced with && just for gcc 2.96 compilation.. ;-)

Oh yea, and i KNOW it aint pretty. Its simply what resulted from the patches and allowed showeq to hobble along..

Like QuerySEQ, I also had failed chunks with the quickpatch.diff. I am in the process of right now patching by hand. Other than that, SUPER work Cryptorad. Here's hoping I'll see skittles soon :)

Mine is working but is there a way to have the whole map refresh without having to zone everytime? If I'm in one spot killing mobs and they repop, I don't know it because SEQ shows them as not popped yet. Same goes for ppl that run by me or near me if I've been in the zone for awhile.

Cheers

I have had the same problem tardiss... i dont think theres a fix for it yet...

Quote:

---

Originally posted by QuerySEQ
I took this patch and compiled, and had skittles.


One thing I do notice, is mob updates are not "live" sometimes even player data is not, usually happens when the players are not close to you and the sync packets are sent slower. Reason I say this, is that I was trying to locate a player that was lost in Kael, and when I reached his location on ShowEQ, the player was not anywhere near that location, and it changed as I got there. Then it showed his location in a different location. I finally told the player to stop and not move, in order for me to find them.

---

One thing I know for certain is that player information (for PCs only) is NOT transmisted for every player in the zone. It only transmits this data (which includes movement data, turning, casting, etc, etc) for PCs that are wihtin a certain cylindrical area relative to you. This area is more limited on the z axis (up/down) axis than it is on the x/y axis. This prevents dial up users from getting flooded in crouded zones. It used to be that when you followed somebody in a hilly area, when they went up the hill a little ways you started seeing them running ina circle. This was because the z axis was too small and it stopped sending info on them. They have fixed this by expending the z axis again, but it took them over 2 or 3 years to do it.

A couple of other hings (and I'm sorry this isn't very pertenent to the posted topic). PC corpses don't show up in the corect location if the player died after you zoned in because it's converts the player entity to a corpse entity. If somebody dies and you need to see where their corpse is on seq you have to camp and come back to get the initial zone info. Also, this will show you the location of all PCs initially.

2 or 3 years? I don't think it has been that long since they implemented the change for PC vs PC distance filtering. Hell, that was when I got into EQ/SEQ and don't recall that issue being there at that time. When I started, there were no distance filters. You zone in, you saw the whole zone (players and all).

You still see all NPCs, corpses and PCs when you zone in. But that's the only time it sends you the data on all of them (unless they are all in range). I remember when they introduced the PC distance filtering, it was mid 1999 (I was still in black burrow :). If you were standing on the ledge (the high dive into the lake in the middle of BB) you couldn't see PCs on the upper surface and they couldn't see you. When you followed somebody through everfrost peeks, it was a disaster, they spun around at every hill top (if they were turning while going up the hill). It was still broke like this in late 2001 and early 2002 to my recolection.

Xith

I thought those issues were related to line of sight quirks.

nope.

I noticed that seq06252003.diff has a bunch of ^M stuff in there. Probably a simple editing mistake. I had to clean up the source code after the patch was applied.
Actually it was only in one small part of the diff file. hehe

You can see it in Emacs easily. Or in vi if you use the setlist command.

Still trying to get a version that doesn't segv.

L1A

^M means that it was edited under Windows and saved by a windows program (e.g. notepad). *nix and Windows use slightly different things to handle new lines in files.

Windows: <CR><LF>
*nix: <CR>

that is what dos2unix/unix2dos deal with when converting text files from one to the other.

There are multiple ways ^M can be caused

"^M" sometimes means (I dont know exactly what causes it) an ASCII (text) file was uploaded in binary mode - instead of ASCII. Always upload text files in ASCII. However, alot of web base upload scripts, frontpage, etc etc will f00k you up too and upload your text document in binary mode - yielding ^M characters.

If you are using "vi" text editor - you can remove the ^M from an entire text file (lets assume it has alot of lines) with the command:

:%s/^M//g

This is done by hitting the ":" key - then entering:
%s/CTRL+V CTRL+M//g

CTRL+V will give you the ^ in vi - and the CTRL+M will give you the M - for a complete - and correct ^M

Test it for yourself ;) Create a simple text file - ftp it up to your favorite server in binary mode - whallah ^M

Common mistake.

The reason for the extra ^M (I'll call [13] as it is ASCII value 13) is this:

DOS uses 2-bytes to do a carriage return. [10] to put the cursor back to column 1, and [13] to go to next line.

UNIX only needs the [10] to do both the line feed and resetting the column. Which is why you are left with the extra [13].

This is why it is important to FTP non-binary files using ASCII, it does the stripping of the [13] for you.

Ahhh! I knew there was a technical explanation for it - but wasnt sure exactly what it was. I knew if you uploaded txt files from windows to *nix in Binary you would get the ^M - but didnt know the technical cause for it.

Thanks for explaining it!

Quote:

---

Originally posted by uRit1u2CBBA=
The reason for the extra ^M (I'll call [13] as it is ASCII value 13) is this:

DOS uses 2-bytes to do a carriage return. [10] to put the cursor back to column 1, and [13] to go to next line.

UNIX only needs the [10] to do both the line feed and resetting the column. Which is why you are left with the extra [13].

This is why it is important to FTP non-binary files using ASCII, it does the stripping of the [13] for you.

---

I did everything on your post and it works fine till i tried to use the quickpatch.diff.

When i go in terminal mode and i type quickpatch i get an error

[root@localhost showeq]# quickpatch
bash: quickpatch: command not found

what i my missing.

Silly boy.. Diff patches are applied with the patch program.

patch < quickpatch.diff

Thanks for the info.

Ok. I read your post in all hopes of figuring out how to get my Myseq working for the Very First Time. I did exactly what it said to do under the post "Installing Myseq". I downloaded the server,client,and maps. Also downloaded .net framework. Now im doing this ALL on 1 machine just like Myseq says I can do... I installed everything to the directories it said to...got all the way in EQ...started the server...started the client...went to options and changed the IP to 127.0.0.1 (I also Tried my IP address) and hit GO. I got a page with a big black screen and a red dot. All the mobs,levels and all that info was blank. If i went to get map...I could bring up a map for where I was but thats it...NO interaction at all. I havent done anything else at all because this is what the posts I have read said would work... I am just learning Visual C++ and have VC++ 6.0 on my machine. Plz tell me what I'm doing wrong or what I'm not doing.

Wrong forum and wrong thread. This thread is about getting SHOWEQ to work, not MYSEQ.

Can someone please point me to a pkzip for linux? and, is there any particular reason why these patches were uploaded in windows PKZip format instead if gzip?

My linux box is a minimalist machine, I don't have the space or time/inclination to install Samba for linux-windows connectivity.. I would just like to download the patches on my linux box and install them.

Thanks

btw I don't have the "zip" or "unzip" utilities on my RH72 system, and gnorpm doesn't list a "zip" rpm under file applications. I downloaded PKwares "pklin251.exe" from tucows, and I get a "permission denied" (in superuser) when i try to run ./pklin251.exe ...

Any help appreciated thanks.

nm I found the unzip package on a redhat ftp site.