How I got SEQ going again...

[cryptorad]

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

[LordCrush]

Nice post cryptorad

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 =)

[QuerySEQ]

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

I took this patch and compiled, and had skittles.

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.

[Ratt]

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

[shnauka]

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..

[trustno1]

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

[Tardiss]

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

[Roads]

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

[Xith]

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.

[Cryonic]

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).

[Xith]

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

[uncleubb]

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

[Xith]

nope.

[L1A]

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

[Cryonic]

^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.