Latest Patch

[trustno1]

The diff patch didn't work on everquest.h, but did on logger.cpp and player.cpp, so I manually changed everquest.h and now it works great. Last night every zone I went to would generate a seg fault. Thanks for this quick and dirty hack!

[uRit1u2CBBA=]

I was given a message stating that everquest.h didn't work, but when I manually inspected the file, it looked like it did.

I started compiling it (P233, so it takes a while) but had to go to work before it was finished.

When I get home from work, I'll find out if it worked or not -- if not, I'll have to wait for an official CVS patch.

[Thom_Merrilin]

If you are getting that kind of error, then your everquest.h file is probably earlier than the revision 1.65(last updated 4 days ago in CVS)

The quick and dirty patch should install without errors on the latest CVS.

As for previous versions, it might work... but I don't know enough about this stuff to know either way.

So for those of you reading this... Be sure to get the latest CVS, then apply the patch.

(Disclaimer) If the latest CVS has files newer than this post, then do not apply the patch. It will prolly screw things up.

[Zoolander]

Sorry for the sketchy instructions. My logger.cpp and player.cpp files aren't the same as what's in CVS so I can't really provide a patch. I don't have any characters that are guilded or with AA points to spend so I can't track down those last 2 fields in the struct. Maybe someone else can and then provide a struct suitable for properly patching against.

[cheese_poker]

Man, you guys are just too good. Thanks a ton for your continued efforts.

[exslam]

took me a second to figure it out, but thanks to the info in this post worked great!

Great Job guys ^_^

[Alwayslost]

did this a few times, fixes the problem for 15-20 min then Seg's out again... Maybe I'm missing something.. getting some sleep, maybe that's it.

[jesterbam]

Yep same here. I downlaoded a fresh CVS did the patch all with no errors and I last a few mins more in the zone then Seg Fault.

[uRit1u2CBBA=]

Strange - works fine for me, I was running it for about 4 hours last night.

[QuerySEQ]

Okay.. reading and reading.. I noticed varying degrees of this seg fault.

I have SEQ running and monitoring 2 EQ games at once. (Just puting SEQ into 2 different workspaces and having it monitor through 2 network cards to 2 different PC's)

Just to explain what I am doing... I have Dual Monitors and can split the work spaces between the two sessions.

The seg fault happens are different times, more in higher traffic zones.

I went to Plane of Storms, and on zoning in.. BOOM.. session "A" went down with a seg fault, but session "B" stayed up. I camped the char that session "A" was monitoring and logged back in. Session "B" stayed up on zoning.. At the EXACT moment session "A" character spawned in game. Session "B" went down with a seg fault, and not more than 10 seconds later, Session "A" went down with a Seg Fault again.

Soo.. I moved over to Tenebrous Mountains with both chars.. and stayed fine and no Seg Faults, for about an hour.. then.. Zoned to Katta.. BOOM! both sessions seg faulted.

The randomness and sometimes "patterned" seg faults got me to thinking. COULD it be possible that mob location/player location structs are varying coming from the game? or possible spawn location? To me it seems more like a change in a variable from time to time.. something non-sequential.

Also.. I use a modified skin.. and my Spell Book "magically" closes or opens on 4 occasions.. when that occurred.. BOOM, Seg fault..

I mainly use SEQ to locate corpses and for mapping.. hardly ever to locate mobs or such because I have been playing soo long I know where the mobs are.

Well.. I hope this helps some.. not sure if any of this is related, just throwing a few observations out that may spark a light somewhere.

[Wois]

giving "behaviors" of showeq is not really useful. if you want to help put

printf("OPCODE: %d",opCode);

before the switch(opCode) line in packet.cpp and recompile (i know it IS crude at least knowing which opcode it crashes on can be a HUGE help (i know about the size check, but i if they just shuffled it and kept the same size you're out of luck)

beware the console spam :P

[tristanbfg]

printf("OPCODE: %d",opCode);

Don't forget fflush(stdout);



I've done that on more then one occasion....

Anything new on this btw?

[QuerySEQ]

Okay.. I would LOVE to help.

printf("OPCODE: %d",opCode);
before the switch(opCode) line in packet.cpp and recompile

Okay.. I see where that goes.. but then tristanbfg states:

Don't forget fflush(stdout);

could you tell me where this part goes.. or at least the whole thing I need to put in. That way I can SEE what it is everyone is looking for.

Thank you for the advice..

[Wois]

fflush(stdout);

that forces stdout to be written, which is a GOOD idea considering it'll be crashing soon after :P thanks, didnt think of this one

so this should go before switch

printf("OPCODE: %d\n",opCode);
fflush(stdout);

(notice the missing \n before)

just saying this as a hint to the "newcomers", they might as well help with the data if they cant fix it :P

[Wois]

another FYI if anyone wants to take a look, the opcode that seems broken atm is 0x0115
(newCorpseCode/newCorpseStruct). don't have the time to look at it atm so i'm posting it here

ah yeah, don't ask where i come from, just a returning user from a LONG time ago