EQEMU v0.6.2, My Experience

[WildcardX]

I have pretty much dedicated my weekend to getting 6.2 with PEQ RC1 DB working.

I am pretty sure the opcodes.cfg file is missing several opcodes, but aside from that after re-sourcing the db like 4 times, I found that when i suprressed screen output on mysql with the "-s" option and then sourced the DB, not only did the source command take like 1000% less time, but I also have a working DB. Now this might just be coincidence, but each time I sourced the DB I got a different result, as far as error messages from world.exe. I dunno, but I do know I have now have a working 6.2 server with the latest peq database and I was even able to log off my server and then log back in with the same char and zone with no problems, something I have not been able to do since Friday. I am also using the latest 4.0.X mysql version.

[vRandom]

Can you attack mobs? If you can then your doing better than me...

Though i might try this -s option, i dont have errors in my world but i do get a op_clientupdate or something like that wrong size error... which from other posts is not updating my char's location on the server, but client side i can run all over the zone....

edit: and i can't zone correctly... zoning from ecommons to west freeport and i end up in nek forest ....

vRandom

[Shredomatic]

I had the opcode errors as well, I copied and pasted the names of the missing ones from the world.exe window into the opcodes.conf file and just zeroed out the values. No idea if this worked, the error didn't come up, but on to my next issue..

I tried both the eqdr2 db and the peq db, and I can't get either one to work. The eqdr2 db spits out a bunch of errors in world.exe, and then says "make sure you sourced utils/items-0.6.0-DR2-0.6.1-DR1-convert.sql" I have no idea where to get this file. I'm not even sure if this db works with 0.6.2, but at least it lets me load up the zone servers.

I also tried the peq db, and I get no errors from world.exe that I can see, but when I run boot5zones.bat they immediately crash.

I'm just stumbling my way through this, but I'm close, I can feel it. I guess I'll just keep plinking away until someone figures it out. Where are those PEQ guys, they have a working server :)

[WildcardX]

sadly, i can not attack anything. I get a "your target is too far away, get closer!" message, no matter how close i am.

But I can zone from ecommans to west freeport with no problem.

I also notice I can zone to poknowledge, vex thal and shar vahl, although these zones are all empty.

And in kael and i think all of velious in general, i notice none of the mobs move.

[tallerin]

alot are having the target to far away bug. Dunno if this would help anyone to figure out what would be causing it but i run a quick packet collect on PEQ then on sacred annialation server and quite frankly both packet collects pretty much match each other for the opcodes and stuff. i did the same thing in both servers from makeing a toon to walking out of spawn point attacking a guard and attacking a guard when your first spawn in only diff is in peq i died fast lol and SA i just stood there with the to far away msg. so if PEQ runs on linux (dunno) and were trying to run a windows possible that the other post i seen in hear may hold some possiblities. But i am by far no coder or know any c++ mumbo jumbo so i'm lost heh.

[vRandom]

well poo... :(

I guess we are waiting for a dev person to figure out the glitch. Something to do with the wrong size client update thing,.... sorry shutdown my server in preps to go out, so dont have exact line... but you likely have the error/notic in your zone window... op_something expected 38 got 36...

Catch you all later, :)

vRandom

edit: or like tallerin mentioned, it could be a compile difference between linux and windows... i'm not a c programmer either but that was mentioned in another post....

[WildcardX]

I cant click on merchants or do quests either with NPCs i know to have quests. I also cant stop any npc by hailing it. I think this is related to not being to attack anything. Its like the server doesnt have my correct zone coordinates? Except that i can open doors and cross zone lines so i dunno...

[WildcardX]

In my zone.exe, and yes, i am running this on Windows 2000 server, before i get the "OP_ClientUpdate expected:38 got:36" or "OP_ClientUpdate expected:38 got:37", I get a "OP_AnnoyingZoneUnknown (#299, eq=0x0000), size: 8" message when I first zone in. And like I said, I can walk around and open doors and cast buff spells on myself, but I can not attack via melee or spells anything and I can not get any quest npcs to respond.

Also, in my world.exe, I see a TCPConnection::RecvData(): Error: 10053. Looks like this happens everytime I zone and right after it says something like "Removing zoneserver from ip:0.0.0.0 port:0" and then right after that it says "3713250 New TCP connection: 127.0.0.1:16777343". And I think this is related to what I see in the game, every so often I see a broadcast from ZServer about a lost connection from world. Eventually, I see a message that the zone has reconnect to world.exe.

[kasodo]

Anyone able to attack mobs or get the client to update with the server yet?

[jillmatik]

Still no luck attacking on mine.. here's a trick though to confirm that you aren't actually moving..

Zone in and run around as far as you want then target yourself and #summon

It'll summon you right back to where you zoned in. Not that we're still trying to confirm the fact that the character is not updating coordinates to the server... I think we're all in agreement there.

I'm anxious to get this working!

Aside from this, 0.6.2 on PEQ Velious RC1 is working pretty good. Some merchants work, some don't but it'll just take me some time.

Shredomatic: I was getting these errors too regarding my items table. At the end of the error message it was referring to missing fields.. I just manually altered the table with the fields it was asking for and this worked. I think I missed a .sql file in my setup.. try the following before doing your item import from 13thfloor:

ALTER TABLE items CHANGE UNK145 UNK150 int not null;
ALTER TABLE items CHANGE UNK141 UNK145 int not null;
ALTER TABLE items CHANGE UNK137 UNK140 int not null;
ALTER TABLE items CHANGE UNK133 UNK135 int not null;
ALTER TABLE items CHANGE UNK129 UNK130 int not null;

ALTER TABLE items ADD clicklevel2 int not null AFTER clicktype;
ALTER TABLE items ADD proclevel2 int not null AFTER proctype;
ALTER TABLE items ADD wornlevel2 int not null AFTER worntype;
ALTER TABLE items ADD focuslevel2 int not null AFTER focustype;
ALTER TABLE items ADD scrolllevel2 int not null AFTER scrolltype;

After import, try running this:


alter table items change unk130 unk129 not null;
alter table items change unk135 unk133 not null;
alter table items change unk140 unk137 not null;
alter table items change unk145 unk141 not null;
alter table items change unk150 unk145 not null;

alter table items drop column clicklevel2;
alter table items drop column wornlevel2;
alter table items drop column proclevel2;
alter table items drop column focuslevel2;
alter table items drop column scrolllevel2;

I tried finding the original post to reference this fix. Sorry I can't remember who to give credit to for this solution. It worked for me however and I hope it will work for you.

[WildcardX]

Well the TCPConnection::RecvData() error 10053 is the result of the winsock function WSAGetLastError() spitting out the following error:

WSAECONNABORTED
10053
Software caused connection abort.
An established connection was aborted by the software in your host computer, possibly due to a data transmission time-out or protocol error.

I'm still reading the code to understand why for the love of baby jesus this is happening, but my edumacated guess so far is that this problem originates from the opcodes file...

[WildcardX]

Anyone out there running 6.2 with the PEQ Velious RC1 DB on a linux platform and do you get the errors I described above or is it running fine for you? I'd be interested to know because I have read in earlier posts that some might be seeing different server behaviour between a Windows platform and a linux platform. The server code does make a distinction in which code logic to execute based upon platform.

[Memener]

lol glad to see people with the same problem as me :)

Like yall i cant hit anything #kill works tho...

[tremor]

i'm useing cavedudes 6.1 database running 6.2 everything works some zones need updating but having same probs with mobs. i got the skeletons to attack me 3 times at NRO now but you have to run around them for a while and you can't hit back, there attacking each other also lol. heres a few pics

http://www.imagehosting.us/index.php?action=show&ident=660668

http://www.imagehosting.us/index.php?action=show&ident=660662

[Strakens]

I am running 0.6.2 with the PEQ Velious RC1 DB on a SuSE Linux Enterpise Server 9 sp2. My World server and MiniLogin 0.6.2 server come up and talk and I can create a new Charater. No errors in my logs for this process. However I do have a problem with my Zoneserver. It fails to load and so I am unable to zone into the game from the Character selection screen. When booting my zone server it get the following:

[Debug] Starting Log: logs/eqemu_debug_zone.log
[Debug] Warning: Perl dosub called for my_eval when perl is allready in use.

[Quest] Starting Log: logs/eqemu_quest_zone.log
[Quest] Loading perlemb plugins.
[Quest] Loading perl commands...
[Debug] Warning: Perl dosub called for my_eval when perl is allready in use.

[Quest] Loading perlemb plugins.
[Quest] Loading perl commands...
[Status] Starting EQ Network server.
[Error] Starting Log: logs/eqemu_error_zone.log
16381 New TCP connection: 192.168.1.2:33663168
[Error] Zone bootup FAILED!
Connected to worldserver: 192.168.1.2:9000
New zoneserver: #1 192.168.1.2:54579


So Not sure If I have a problem with my Pearl version/config or if something else is going on.

[tremor]

samething here with perl and debug crashs on loading spells for me but the normal zone is ok.

this is the windows error from event viewer if it helps

[zoneperl error]
Description:
Faulting application zoneperl.exe, version 0.0.0.0, faulting module perl58.dll, version 5.8.7.813, fault address 0x00065b11.

Data:
0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 7a 6f 6e ure zon
0018: 65 70 65 72 6c 2e 65 78 eperl.ex
0020: 65 20 30 2e 30 2e 30 2e e 0.0.0.
0028: 30 20 69 6e 20 70 65 72 0 in per
0030: 6c 35 38 2e 64 6c 6c 20 l58.dll
0038: 35 2e 38 2e 37 2e 38 31 5.8.7.81
0040: 33 20 61 74 20 6f 66 66 3 at off
0048: 73 65 74 20 30 30 30 36 set 0006
0050: 35 62 31 31 0d 0a 5b11..


[zonedebug error]
Description:
Faulting application zone.exe, version 0.0.0.0, faulting module zone.exe, version 0.0.0.0, fault address 0x001fae3f.


Data:
0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 7a 6f 6e ure zon
0018: 65 2e 65 78 65 20 30 2e e.exe 0.
0020: 30 2e 30 2e 30 20 69 6e 0.0.0 in
0028: 20 7a 6f 6e 65 2e 65 78 zone.ex
0030: 65 20 30 2e 30 2e 30 2e e 0.0.0.
0038: 30 20 61 74 20 6f 66 66 0 at off
0040: 73 65 74 20 30 30 31 66 set 001f
0048: 61 65 33 66 0d 0a ae3f..

also world disconnects me after character select screen i can play alright but when i camp out it says client disconnected instead of exiting the game normally

[vRandom]

Maybe one of you can make sence of this...

I think this is where the error is returned

if (app->size != sizeof(PlayerPositionUpdateClient_Struct)) {
LogFile->write(EQEMuLog::Error, "OP size error: OP_ClientUpdate expected:%i got:%i", sizeof(PlayerPositionUpdateClient_Struct), app->size);
return;
}


OP_ClientUpdate expected:38 got 36

now if i look for the PlayerPositionUpdateClient_Struct

I find


/*
** Player position update
** Struct sent from client->server to update
** player position on server
**
*/
struct PlayerPositionUpdateClient_Struct
{
/*0000*/ uint16 spawn_id;
/*0022*/ uint16 sequence; //increments one each packet
/*0004*/ float y_pos; // y coord
/*0008*/ float delta_z; // Change in z
/*0016*/ float delta_x; // Change in x
/*0012*/ float delta_y; // Change in y
/*0020*/ signed animation:10; // animation
signed delta_heading:10; // change in heading
signed padding0020:12; // ***Placeholder (mostly 1)
/*0024*/ float x_pos; // x coord
/*0028*/ float z_pos; // z coord
/*0034*/ unsigned heading:12; // Directional heading
unsigned padding0004:4; // ***Placeholder
/*0032*/ uint8 unknown0006[2]; // ***Placeholder
/*0036*/
};


Now if i'm understanding this doesn't that last line /*0036*/ mean this is 36 byte, then how does it expect 38, the only thing i dont understand is app->size since its part of the if statement and i either dont understand it or its being set to 38 somewhere which causes this to expect a 38 when it only gets a 36...

does any of that make sence?
vRandom

I'm not a c programmer so i could be totaly not reading it correctly... :)

[cobra80]

Anyone managed to load the peq velious rc1 database into a fresh install that mind sharing how they managed? All i keep getting is tables missing when i try to directly insert it or this error when trying to update things.

ERROR 1060 (42S21) at line 468253: Duplicate column name 'lootdrop_id'

[WildcardX]

vRandom,

I was just looking at that exact code! the reason why the server is "expecting 38" is because it is getting that number from the sizeof(STRUCT) function.. So 38 in this code is pretty much a constant as the memory signature of the PlayerPositionUpdateClient_Struct doesnt change. What is changing, the "36" and "37" from app->size is the size of that same struct the client is sending to the server. In effect, the server expects the size of this structure to be 38 bytes long, but the client is sending 2 different PlayerPositionUpdateClient_Struct sizes of 36 and 37 bytes. Upon reviewing the code further, I see this struct is instrumental in determining both player coordinate position in the eq world as well as positions of mobs. I'm still trying to understand this more so I can attempt a fix. I would think its simply the opcode for the OP_ClientUpdate is wrong and that we simply need to recapture this packet, but what I am confused about is why the client is sending 2 different sizes for the same structure unless the client has changed and broken what was once OP_ClientUpdate into 2 different opcodes...

[vRandom]

WildcardX,

That would be a good question, hummm

Can we get it form the peq server, i mean dont they have one that works?
vRandom

[jillmatik]

You guys are blowin my mind here.. I'm so clueless about this stuff. From the snipets you've posted, it seems that the problem area has been isolated and I really hope you can stick with it and find something!

I think I'm doin good if I can just edit some ini files lmao! Keep at it!

[WildcardX]

Thats a good question. I hope that is the answer. I did log onto the PEQ server over the weekend to make sure my client worked, but I didnt try to attack anything. When I get home (I am at work right now. I am a c++ and c# developer for a software company and a project I just completed is being tested out by the bug team so I have some down time right now) I'll have to log back onto PEQ to see if I can attack anything.

[vRandom]

Cool, I'm in that downtime spot atm too... but i work from home so i can make downtime but today is vacation day :)

I refuse to work and more than i must today... lol

I'm running around and killing stuff with spells and just goofing off atm

I am getting this when i'm sitting in a zone and doing nothing for awhile.


[Error] Unhandled incoming opcode: OP_Unknown (#0, eq=0x0000), size: 8, Client:
Blahs
0: 49 DD 12 00 00 DD 12 00 | I.......


though i dont understand how to figure out what they are...
vRandom

edit: sure i open my mouth about being on vacation and the damn phone rings and now i have to go fix something grrrrrrr

[WildcardX]

Anyone know if this ever got done?

case CLIENT_CONNECTED: {
ClientPacketProc p;
p = ConnectedOpcodes[opcode];
if(p == NULL) {
//TODO: replace this 0 with the EQ opcode
LogFile->write(EQEMuLog::Error, "Unhandled incoming opcode: %s (#%d, eq=0x%04x), size: %i, Client: %s", OpcodeNames[opcode], opcode, 0, app->size, GetName());
if(app->size<1000)
DumpPacket(app->pBuffer, app->size);
else{
cout << "Dump limited to 1000 characters:\n";
DumpPacket(app->pBuffer, 1000);
}
break;
}

Notice that comment: //TODO: replace this 0 with EQ opcode... In the source I am looking at, it seems:

p = ConnectedOpcodes[opcode];
if(p == NULL)

is kicking out the error message when zone.exe starts for a char about OP_AnnoyingZoneUnknown. Thats the first error message we see in zone.exe before we start seeing all those messages about OP_ClientUpdate. Unfortunately, I can not debug this at work atm and will have to wait until I get home to place a break point here to see what this value is.

[Status] 99875 New client from ip:xxxxxxxxxx port:1038
[Error] Unhandled incoming opcode: OP_AnnoyingZoneUnknown (#299
e: 8, Client: Tallerin
0: 37 02 00 00 40 00 00 00 | 7...
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:37
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36

EDITED: I think I am on to something.. I dont know what OP_AnnoyingZone opcode is suppose to do, but I believe it is wrong in opcodes.cfg. The above log is truncated. (#299 is missing some digits) Right now in the latest opcodes.cfg, OP_AnnoyingZone equals = 0x63da which is 25562 in decimal. The missing digits from the above log, #299... This is the opcode that OP_AnnoyingZone should be, right? I think I am correct but it will have to wait until I get home to check for sure. Meanwhile, if someone wants to try this, just run your server and note that error message and get the full 5 digit number from your output. Then open a calc in windows and switch it to scientific view. Then select "decimal" and type in that 5 digit number, then select "hex" and you should get a number like 0x63da. Then replace that number in your opcodes.cfg for OP_AnnoyingZone and then rerun your server and BE SURE TO COME BACK TO THIS THREAD AND REPORT RESULT THX!! :-)

[jillmatik]

I can start testing this now.. here's my error code.. what number should i replace in opcodes.conf ??

Received Message SyncWorldTime
Time Broadcast Packet: EQTime [10:26 pm]
[Status] 161941651 New client from ip:ipaddress port:1964
[Status] Weather should change in 6932 seconds
[Error] Unhandled incoming opcode: OP_AnnoyingZoneUnknown (#299, eq=0x0000), size: 8, Client: Test
0: 38 02 00 00 40 00 00 00 | 8...@...
[Error] Unhandled incoming opcode: OP_AnnoyingZoneUnknown (#299, eq=0x0000), size: 8, Client: Test
0: 38 02 00 00 80 00 00 00 | 8.......
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36

Just tried editing the opcodes.conf file with the updated hex number. This was the resulting output:

Received Message SyncWorldTime
Time Broadcast Packet: EQTime [02:28 am]
[Status] 196613 New client from ip:ipaddress port:1997
[Error] Unhandled incoming opcode: OP_Unknown (#0, eq=0x0000), size: 8, Client: Test
0: 3A 02 00 00 40 00 00 00 | :...@...
[Error] Unhandled incoming opcode: OP_Unknown (#0, eq=0x0000), size: 8, Client: Test
0: 3A 02 00 00 80 00 00 00 | :.......
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36

I agree.. hopefully someone will chime in! Worth a shot though thanks for the work!

[WildcardX]

Nevermind, it seems that the 0 that the TODO comment was talking about is in the following line of the client_packet.cpp file:

LogFile->write(EQEMuLog::Error, "Unhandled incoming opcode: %s (#%d, eq=0x%04x), size: %i, Client: %s", OpcodeNames[opcode], opcode, 0, app->size, GetName());

The third variable in, is hard coded as a zero which is while your output and everyone elses says (#299 0x0000). That 0x0000 should be the real opcode that the server recieved from the client for the OP_AnnoyingZone opcode. To bad its hard coded like that or we could use that number and plug it into opcodes.cfg. But based on what I am seeing with just this one opcode I am 100% convinced that the opcodes.cfg file that ships with both the source and binaries for 6.2 is inaccurate and needs to be updated.

This is the first time I have ever looked into the EQEmu source before so I hope an enxperienced EQEMU developer reads this and can chime in to let us all know for sure. If I am correct, then we all need to start up our packet sniffers to come up with a correct opcodes.cfg file to get this working, unless PEQ already has a working one and they can share it with the rest of us.

[WildcardX]

I just noticed something else, no where in the code can I find any mention of OP_AnnoyingZone opcode. Shouldnt this be one of the opcodes mapped in the void MapOpcodes() function of the client_packet.cpp file? If this is a valid opcode and should be handled, whats it suppose to do? I guess this is why we are seeing this error message in zone.exe. This opcode is defined in opcode.cfg, but is not being used at all in the source code. Someone can try to remove this opcode from their opcode.cfg file and try it out. Like dont just zero it out, delete the whole definition for OP_AnnoyingZone altogether and see what you get. You will probably still see the second error message or maybe zone.exe will blow up altogether. Still would be nice to know how this changes the behavior.

EDIT: to complicate matters even more, OP_AnnoyingZoneUnknown is what I meant as the offending opcode and its defined in our opcodes.cfg and the ONLY place it is mentioned in the entire server code is in emu_oplist.h. But it is never handled anywhere. I think just removing this from the opcodes.cfg file will not work because the code will still try to look for it, but it never uses it and doesnt know what to do with it when it recieves it from the client. You can try to remove it from opcodes.cfg, but I dont believe it will buy us much. I guess we need to know from the devs the following:

1. what is this opcode suppose to do
2. is it something we need to add a handle to the server to do something or is it safe to remove it from the opcodes.cfg file and the emu_oplist.h file and then recompile.

I dont believe this is causing the second OP_ClientUpdate error but I am still confident our opcodes.cfg files are inaccurate.

[tallerin]

well i removed and it removed the first error

[Error] Unhandled incoming opcode: OP_AnnoyingZoneUnknown (#299
e: 8, Client: Tallerin <---- no loger showing

[Status] Successfully loaded Zone Config.
[Status] Loading timezone data...
[Status] Init Finished: ZoneID = 54, Time Offset = 0
[Status] Zone Bootup: gfaydark (54)
[Status] 135547 New client from ip:127.0.0.1 port:1180
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:37
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:37
[Error] OP size error: OP_ClientUpdate expected:38 got:36
[Error] OP size error: OP_ClientUpdate expected:38 got:36

[WildcardX]

Atleast zone.exe still works without it lol

But I didnt expect that to fix the second error, although I was hoping. Its the first rule of troubleshooting... Fix the errors in sequential order. I'm on my way home now and I'll try to debug the server's zone.exe process to see whats the deal with that second error. Although, I fear that one will be more complicated. Maybe I can find some time to help out the other devs with EMU now that I am sticking my nose into the code.

Tallerin, when you made the change did you log into your server and try to attack something? Chances are good that this change has nothing to do with that problem, but it wouldn't hurt to try it out either in case the absence of processing that opcode may impact some other part of the server's subsystems.

[tallerin]

ya i tryed my normal rutine logged in under my toon (woodelf druid easier to test) i can attack my druid master and aggro them and hit them and die from them lol. but if i go out side the druid guild i still get the target is to far away still.

[deazone]

vRandom,

I was just looking at that exact code! the reason why the server is "expecting 38" is because it is getting that number from the sizeof(STRUCT) function.. So 38 in this code is pretty much a constant as the memory signature of the PlayerPositionUpdateClient_Struct doesnt change. What is changing, the "36" and "37" from app->size is the size of that same struct the client is sending to the server. In effect, the server expects the size of this structure to be 38 bytes long, but the client is sending 2 different PlayerPositionUpdateClient_Struct sizes of 36 and 37 bytes. Upon reviewing the code further, I see this struct is instrumental in determining both player coordinate position in the eq world as well as positions of mobs. I'm still trying to understand this more so I can attempt a fix. I would think its simply the opcode for the OP_ClientUpdate is wrong and that we simply need to recapture this packet, but what I am confused about is why the client is sending 2 different sizes for the same structure unless the client has changed and broken what was once OP_ClientUpdate into 2 different opcodes...

6.1dr1 also receives two OP_ClientUpdates
as shown below:
[Error] OP size error: OP_ClientUpdate expected:30 got:31

Normally the 6.1 client does send 30 bytes.

I believe the opcode in opcodes.conf is correct. I believe it is serverside which is not allocating the PlayerPositionUpdateClient_Struct correctly.

void Client::Handle_OP_ClientUpdate(const EQZonePacket *app)
{
if (IsAIControlled())
return;

if (app->size != sizeof(PlayerPositionUpdateClient_Struct)) {
LogFile->write(EQEMuLog::Error, "OP size error: OP_ClientUpdate expected:%i got:%i", sizeof(PlayerPositionUpdateClient_Struct), app->size);
return;

As you can see sizeof(PlayerPositionUpdateClient_Struct) is always showing as 38, the clients are sending the 36byte packet. Every now and then a 37 byte packet.

Could it be that:

VCPP is not allocating the same memory as GCC. Normally eqemu has no problem with the OS port. However perhaps something was missed. Does anyone have a linux server up that could confirm this?

[tallerin]

Also i have to agree the opcode in the opcode.conf is the right one as i get 0x14cb for the OP_ClientUpdate from peq server when i ran a packetcollector

[WildcardX]

It is true that different platforms will get different sizeof() results for datatypes. I did notice in that structure you mentied above that some structure members are declared as a float instead of the cross platform accepted float32 type, for example. That could result in a different sizeof(structure) result.

[MikeyUSC]

/*
** Player position update
** Struct sent from client->server to update
** player position on server
**
*/
struct PlayerPositionUpdateClient_Struct
{
/*0000*/ uint16 spawn_id;
/*0022*/ uint16 sequence; //increments one each packet
/*0004*/ float y_pos; // y coord
/*0008*/ float delta_z; // Change in z
/*0016*/ float delta_x; // Change in x
/*0012*/ float delta_y; // Change in y
/*0020*/ signed animation:10; // animation
signed delta_heading:10; // change in heading
signed padding0020:12; // ***Placeholder (mostly 1)
/*0024*/ float x_pos; // x coord
/*0028*/ float z_pos; // z coord
/*0034*/ unsigned heading:12; // Directional heading
unsigned padding0004:4; // ***Placeholder
/*0032*/ // COMMENT ME OUT!! uint8 unknown0006[2]; // ***Placeholder
/*0036*/
};

Simply comment out the last line, and all is well..

RadarBlipBox on the LoginServer is now running with this modification..try & see if anyone has any problems..

[jillmatik]

I'll definitely try this server once I get home from work. If this does turn out to be the fix, would greatly appreciate a link for any updated files! I have no way to compile any updates :(

Thanks,
J

[tallerin]

wooohooo thats it i can move somewhere else and attack and it works on radarblipbox

[WildcardX]

ugh someone beat me to the fix!! hehe Good job!

I really wanted to find the fix for this one and it was staring me in the face the entire time. That line you comment out is the 1 to 2 byte difference in the structure size. I'll try it out and recompile now! woot!

[vRandom]

cool, now who is willing to share a compiled binary :)

vRandom

[tallerin]

should have mention before NICE JOB had a burp in net connection but reconnected and is working great having no issues yet. well except for 2 skelies not liking me and killing me. But i was very much able to hit and do dmg again nice job.

[jillmatik]

should have mention before NICE JOB had a burp in net connection but reconnected and is working great having no issues yet. well except for 2 skelies not liking me and killing me. But i was very much able to hit and do dmg again nice job.

LOL!

Great work! Thanks again MikeyUSC

[Sakrateri]

Any able to post a compiled fix here ? Please ?

[WildcardX]

hehe I'm compiling as fast as I can.. :-) Wife made dinner so...

[vRandom]

hummmm fooooood...... lol

edit: depending on what your having, you could post that here too
i'm hungry....
vRandom

[rojadruid]

Anyone managed to load the peq velious rc1 database into a fresh install that mind sharing how they managed? All i keep getting is tables missing when i try to directly insert it or this error when trying to update things.

ERROR 1060 (42S21) at line 468253: Duplicate column name 'lootdrop_id'

I am running the lastest peq velious rc1 database. all I did was run gthe following in a cmd window: "mysql -u[user] -p[password]" this brings up your mysql window. In it I typed "CREATE DATABSE eq;" followed by "USE eq;" next I sourced two of the four files from the website. by typing "source load_system.sql;" once it finished, took awhile to do I did the next file "source load_empty_users.sql;" after that nothing else have I changed.

after that I just configured the three ini files and I was good to go.

I can load the server, only errors I see are the missing opcodes everyone else is getting, and the no attacking thing which if reading thru here is right is a translation problem.

I am also having a router issue where to login on my network I have to set all the ips in the ini files to localhost, but when configured for public play anyone else but my local lan can play including th computer hosting the server.

[MikeyUSC]

Any able to post a compiled fix here ? Please ?

If I must.. =)

This is JUST World.exe & Zone.exe

Mike

http://www.asrc.info/beta/EQEmuFixed.zip

[WildcardX]

bah I am stuck on a farkin linker error... See my posthere if anyone has seen this one and knows what I didnt include correctly.

http://www.eqemulator.net/forums/showthread.php?p=113078#post113078

MickeyUSC, do you happen to have a zoneperl.exe as well? Or better yet, know what I need to add so I can generate my own bins?

[rojadruid]

If I must.. =)

This is JUST World.exe & Zone.exe

Mike

http://www.asrc.info/beta/EQEmuFixed.zip

Just downloaded and tested it, I can now run around and attack, Well done.

[vRandom]

yep, can run around and kill stuff :) thanks to all

vRandom

[lleo22]

I used the above fix and it solved the melee out of range but spells still say I cannot see my target. I used #summon on a mob and tried casting and still get the error.

[tallerin]

I used the above fix and it solved the melee out of range but spells still say I cannot see my target. I used #summon on a mob and tried casting and still get the error.


make sure you have download the map files with out them in your eqemu folder you will not have line of sight. Therefor causeing the you can not see the target.

[tremor]

Thanks Mike :grin: now i just have to stop everything from chasing me down like a wild dog lol

[cobra80]

I am running the lastest peq velious rc1 database. all I did was run gthe following in a cmd window: "mysql -u[user] -p[password]" this brings up your mysql window. In it I typed "CREATE DATABSE eq;" followed by "USE eq;" next I sourced two of the four files from the website. by typing "source load_system.sql;" once it finished, took awhile to do I did the next file "source load_empty_users.sql;" after that nothing else have I changed.

after that I just configured the three ini files and I was good to go.

I can load the server, only errors I see are the missing opcodes everyone else is getting, and the no attacking thing which if reading thru here is right is a translation problem.

I am also having a router issue where to login on my network I have to set all the ips in the ini files to localhost, but when configured for public play anyone else but my local lan can play including th computer hosting the server.

I got it to work by just loading load_empty_users before load_system. Very odd. :P

[tremor]

is this normal???

Ceerke: Large position change: 61.826026 units
Coords: (592.4846, 3252.9341, -61.3056) -> (616.4312, 3195.9385, -60.5851)
Deltas: (2.38, -6.20, -1.31) -> (2.42, -6.21, 0.00)
Message: Hail, Talin O`Donal
Ceerke: Large position change: 105.569448 units
Coords: (620.9136, 3159.3523, -60.7372) -> (607.6788, 3054.6328, -58.8456)
Deltas: (-0.72, -6.61, 0.00) -> (-0.82, -6.62, 0.00)
Ceerke: Large position change: 53.924070 units
Coords: (607.6788, 3054.6328, -58.8456) -> (600.6883, 3001.2468, -55.8666)
Deltas: (-0.82, -6.62, 0.00) -> (-1.18, -6.56, 0.00)
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
Ceerke: Large position change: 64.509332 units
Coords: (592.1464, 3280.5466, -59.2402) -> (584.3849, 3344.1687, -51.9296)
Deltas: (-0.98, 6.59, 0.00) -> (-0.57, 6.64, 0.00)
[Error] OP size error: OP_ClientUpdate expected:36 got:37
Ceerke: Large position change: 62.741442 units
Coords: (576.5767, 3319.5452, -54.3136) -> (578.0970, 3381.5046, -44.5565)
Deltas: (0.06, 2.50, 0.00) -> (0.16, 6.64, 0.00)
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37
[Error] OP size error: OP_ClientUpdate expected:36 got:37


i was running through everfrost and noticed zone was saying something diff then OP_ClientUpdate expected:36 got:37 when i walked in a curtain spot
i took a screen capture so you know where i was at the time

http://img372.imageshack.us/my.php?image=backeverfrost6sn.jpg

http://img372.imageshack.us/my.php?image=front6tk.jpg

[WildcardX]

I noticed that too last night. If its having an effect in the game, I havent noticed it, but I think those messages only appear when you turn right or left. They didn't seem to pile up in my log for not moving, backing up or going forward.

[tallerin]

those op size error can be ignored as they do only show when turning. only thing that might happen is someoneelse on your server might see you looking another way on there screen when your faceing them till you walk foward or reverse.

[Dr Zauis]

If I must.. =)

This is JUST World.exe & Zone.exe

Mike

http://www.asrc.info/beta/EQEmuFixed.zip

Aargh!! I think I need this fix. Everything seems to work now. Except my position(Server)remains at zonepoint. I also need to make the correct DB as mine is missing the correct Items table.

Well..On to the fixing DB problems. I hope I can get the rest soon.

[tallerin]

his link is down for me but if you need to get it you can get it here while it last. don't know how long it will stay up sooo.

http://www.rapidsharing.com/out.php/i1017_EQEmuFixed.zip

[WildcardX]

I did compile a new zoneperl.exe last night, but it has another problem and I haven't had time to look into it, yet. It kicks out a run-time error from the perl quests and crashes the zoneperl.exe that generated it.

[WildcardX]

I was just doing a little reading of ActiveState perl's README and I see in there a blurb about Perl 5.8 not being compatible with earlier releases of Perl and "You have to recompile your XS modules." I believe the quest subsystem uses these XS modules, right? So either I need to recompile those or I need to back down to a previous release of ActiveState Perl? Like 5.6? I wonder if thats not what was tossing that runtime exception in my updated zoneperl.exe last night... My server does have ActiveState Perl 5.8 installed and I think thats a relatively recent release of ActiveState Perl. Anyone else running ActiveState Perl 5.8? Anyone have this working ok with ActiveState Perl 5.6?

[tallerin]

for my 6.0 and 6.1 i used ActiveState Perl 5.8 and had no issues. for 6.2 i dunno i don't have a working zoneperl for 6.2 nor do i have perl installed yet from having to do a reformat.

[WildcardX]

Cool then I guess it must be a real bug in the zone.exe code. I was hoping it was the Perl 5.8 though when I read that README.. :-)

[tremor]

sorry for my noob question but how do i get those error logs to work?? with world and zone, the only logs going it to the logs folder are zone commands .txt

[jillmatik]

Anyone get a working Zoneperl.exe compiled successfully yet with the ClientUpdate fix? Loving attacking mobs on the server but hoping to start working on that huge collection of PERL quests I downloaded!

Thx
J

[Dr Zauis]

his link is down for me but if you need to get it you can get it here while it last. don't know how long it will stay up sooo.

http://www.rapidsharing.com/out.php/i1017_EQEmuFixed.zip

Thanks..That worked. At first world.exe was crashing when I try to zone. So I put the original world.exe back in and now it seems to work a treat!
I also am using a new database so now the only errors I get are the opcode thingies.

[tallerin]

Well i have been playing around and well i found another issue. The world.exe in the EQEMUfix zip that mikeusc did has an issue with it (for me at least). If you try to use the command #zone you get a loving M$ error window. when i am in BB and type #zone firiona the zone will bootup all looks normal till the error window pops up saying world.exe has encounterd an error and needs to be closed. Fix for was i went back to the original world.exe from the ninaries and i can sit here and bounce from BB to firiona via the #zone command.

not sure anyone else encountered this or not seems some files work better on other pc's and some pc's the files hate them heh. so if you encounter this you can replace the fixed world.exe with the original one or worlddebug.exe from binaries.


/me runs and hides from the mob for finding another bug

[WildcardX]

That might be because when he released the "fix" he only released a changed world.exe and a zone.exe, however the source code file he edited is used in EmuMemShare.dll as well! I might be wrong about that causing the problem you describe, but I was thinking it might lead to some instability since the EQEmuShareMem now expects a Player struct that is "different" than what world and zone will offer up.. Anyway, When I get home maybe I can give you a new fix you can try out. Right now I'm working on a project for my employer and I'm looking at zoneperl issues when I'm bored.

[jillmatik]

Well i have been playing around and well i found another issue. The world.exe in the EQEMUfix zip that mikeusc did has an issue with it (for me at least). If you try to use the command #zone you get a loving M$ error window. when i am in BB and type #zone firiona the zone will bootup all looks normal till the error window pops up saying world.exe has encounterd an error and needs to be closed. Fix for was i went back to the original world.exe from the ninaries and i can sit here and bounce from BB to firiona via the #zone command.

not sure anyone else encountered this or not seems some files work better on other pc's and some pc's the files hate them heh. so if you encounter this you can replace the fixed world.exe with the original one or worlddebug.exe from binaries.


/me runs and hides from the mob for finding another bug

I haven't run into this one yet. When I get home today I'll try the specific zones you've referenced. I'm using both World and Zone that MikeyUSC provided.

[tallerin]

well i have nomore M$ error by just replacing the zone file from his fix and by useing the original worl or worlddebug. now i'm just trying to find which arangement of files will work best together to try and make it alitter easier for a first timer to get started.

[WildcardX]

I have compiled a working zoneperl.exe along with a world.exe and a EmuMemShare.dll that looks good. Quests work and I can attack stuff, well, kinda.. While attacking stuff I found a new error message in my zoneperl.exe.. "Catching Mob Crash". It happens everytime my char "strikes" a mob in melee. Not sure whats causing this yet, but spell attacks do work so, thats good.. hehe As soon as I figure out the "catching mob crash" error, I'll be happy to share my patches with anyone interested.

[vRandom]

I have compiled a working zoneperl.exe along with a world.exe and a EmuMemShare.dll that looks good. Quests work and I can attack stuff, well, kinda.. While attacking stuff I found a new error message in my zoneperl.exe.. "Catching Mob Crash". It happens everytime my char "strikes" a mob in melee. Not sure whats causing this yet, but spell attacks do work so, thats good.. hehe As soon as I figure out the "catching mob crash" error, I'll be happy to share my patches with anyone interested.

me interested :)
vRandom

[jillmatik]

I have compiled a working zoneperl.exe along with a world.exe and a EmuMemShare.dll that looks good. Quests work and I can attack stuff, well, kinda.. While attacking stuff I found a new error message in my zoneperl.exe.. "Catching Mob Crash". It happens everytime my char "strikes" a mob in melee. Not sure whats causing this yet, but spell attacks do work so, thats good.. hehe As soon as I figure out the "catching mob crash" error, I'll be happy to share my patches with anyone interested.

I found this article posted back in 11/04. Maybe there's a note in a changelog somewhere that might help?

http://www.eqemulator.net/forums/showthread.php?t=16839&highlight=catching+crash

[WildcardX]

Its only like that post in that it is the same error message, but its not "continuous" or "spammed" in zoneperl.exe. You really do get 1 error message for each tiem your char "strikes" a mob in melee. I'm trying my newest zone.exe now to see what thats like so I know if this really is isolated to only zoneperl.exe.

EDIT: I just tried my latest zone.exe which should match MickeyUSC's patch and i can melee and spell attack mobs no prob, so that mob crash is isolated only in the perl code within zone.exe (zoneperl.exe). I'll looking to it...

[vRandom]

only reference i found to "Catching Mob Crash" was in net.cpp around line 419

printf("Catching Mob Crash...\n");

if that helps
vRandom

edit:
could just be there for debugging, its wrapped in an if

#ifdef CATCH_CRASH
try{
entity_list.MobProcess();
}
catch(...){
printf("Catching Mob Crash...\n");
}
#else
entity_list.MobProcess();
#endif

only difference is the message....

[WildcardX]

I'd like to think that's there for a good reason. Obviously, that line is tossing an exception, but since i'm getting ready for bed I'm commenting that out for the sake of a test and I'm going to try it out quick before I go to sleep. I'll post back here in a minute or two and update if its "workable" for now.

[WildcardX]

As I feared, simply commenting that out for a quick fast just leaves an unhandled exception that crashes zoneperl.exe. I did search the source quick and it looks like the only good that can toss an exception is limited to the perl subsystem, which explains why only zoneperl.exe is producing this error. The good news is, its just an unhandled exception. Shouldnt take me too long to locate the where and why of it. Maybe I'll stay up for another hour... :-)

[vRandom]

As I feared, simply commenting that out for a quick fast just leaves an unhandled exception that crashes zoneperl.exe. I did search the source quick and it looks like the only good that can toss an exception is limited to the perl subsystem, which explains why only zoneperl.exe is producing this error. The good news is, its just an unhandled exception. Shouldnt take me too long to locate the where and why of it. Maybe I'll stay up for another hour... :-)

Such dedication ;)
vRandom

[WildcardX]

Can I trade "dedication" points for a simple answer to the question that is just driving me nutz? Why oh why is this source code not allowing me to debug it with breakpoints? Its crazy! If I could place breakpoints and debug it like I've done with any other source code since 1992 I'd probably have more bugs fixed. It's totally slowing me down.

Anyway, I'm recompiling now. I'm going to see exactly what this exception message is and then hopefully I'll be able to offer a patch soonish.

[vRandom]

Good question on the breakpoints, they are quite helpfull. Sorry I can't offer any suggestions, maybe its solar flares (http://www.tbnweekly.com/content_articles/091105_fpg-02.txt) lol ;)

I just now got my .net installed...But thats as far as i've gotten atm... had to go back to work... grrr

vRandom

[WildcardX]

When you can next, give it a try. lay a breakpoint, recompile in debug config and watch it never stop... Or just try to "step into instance".. that doesnt work either.

[vRandom]

When you can next, give it a try. lay a breakpoint, recompile in debug config and watch it never stop... Or just try to "step into instance".. that doesnt work either.

Ohh boy sounds like tons of fun.... lol that will drive a person nuts....

vRandom

[MikeyUSC]

It's DLL code.. gotta love it =)

[Sakrateri]

Any luck on getting a Perl enabled zone compile yet? Thanks for what you've done so far !

[MikeyUSC]

I got it to compile.. but it's buggy as hell... I'm going through Inventory at work, so I won't have time to actually debug anything till after Tuesday.

[Sakrateri]

Ok , thanks for working on it . EQ is kind of useless without quests. Mabey rename it EK for EverKill ? lol well anyway everyones time is appriciated thanks .

[WildcardX]

I havent had much time this week to look for into the zoneperl.exe issue, except I have narrowed the cause a little bit. With the source code I have, when I compile my zoneperl.exe, quests work but I can not attack a mob with melee, although I can with spells. The problem is there is an exception being thrown somewhere in the code, but I cant figure out what exception class it is. Unfortunately, catch(exception e) isnt catching it, although (...) is. Its being tossed out of this line in the entity.cpp file under ::MobProcess():

if(!iterator.GetData()->Process())

What looks "weird" to me, is the Process() method is a virtual method of the Entity class, but the object it is suppose to process is Mob class, but Mob class does not have a defined override of the Process method. I wish I could trap this exception, but after spending hours "guessing" at exception classes from std lib, I guess I'm feeling burned out. Maybe someone else here could toss in there 2 cents...

[jillmatik]

Has anyone had any success recompiling zoneperl.exe with the client update fix yet? I've been playing more on live lately and have been a bit out of touch with my Emu server for awhile.

J

[EQEmu102]

Bumpitty =)

Zoneperl gets quests working right? That would be cool

[Dr Zauis]

I have had many problems with zoneperl crashing on me..On the other hand the way Server pack-2 is loading quests works very well without crashing. So if anyone have trouble try Server pack-2..

[phasepuma]

Well, here is somthing interesting. I noticed today setting those problem zones that like to crash with zoneperl to static prevents them from crashing.

This is with 6.2 Zoneperl