Corrected Player Packet

[codepig666]

Here is a more correct version of the charProfile structure.
Nothing past the zoneid has been verified, but I'm pretty sure about everything prior to that.

Hopefully this will cut down on the problems some folks had with it core dumping whenever you zoned with certain characters.

-piggy


struct charProfileStruct
{
/*0000*/ uint8_t opCode; // 0x36
/*0001*/ uint8_t version; // 0x20
/*0002*/ uint8_t unknown0006[6]; // ***Placeholder
/*0008*/ char name[64]; // Name of player sizes not right
/*0072*/ char lastName[20]; // Last name of player sizes not right
/*0092*/ char unknown0068[46]; // ***placeholder
/*0138*/ uint32_t unknown0138; // ***placeholder
/*0142*/ uint32_t gender;
/*0146*/ uint32_t race; // Player race
/*0150*/ uint32_t class_; // Player class
/*0154*/ uint32_t unknown0154;
/*0158*/ uint32_t level; // Level of player (might be one byte)
/*0162*/ uint32_t exp; // Current Experience
/*0166*/ uint32_t points; // Unspent Practice points
/*0170*/ uint32_t MANA; // MANA
/*0174*/ uint32_t curHp; // current hp
/*0178*/ uint32_t unknown0174; // ***Placeholder
/*0182*/ uint32_t STR; // Strength
/*0186*/ uint32_t STA; // Stamina
/*0190*/ uint32_t CHA; // Charisma
/*0194*/ uint32_t DEX; // Dexterity
/*0198*/ uint32_t INT; // Intelligence
/*0202*/ uint32_t AGI; // Agility
/*0206*/ uint32_t WIS; // Wisdom
/*0210*/ uint8_t unknown0210[48];
/*0258*/ uint32_t inventory[31]; // inventory images?
/*0382*/ uint8_t languages[28]; // List of languages (MAX_KNOWN_LANGS)
/*0410*/ struct itemPropertiesStruct invitemprops[31];
// these correlate with inventory[30]
/*0906*/ struct spellBuff buffs[15]; // Buffs currently on the player
/*1146*/ uint32_t unknown1146;
/*1150*/ uint32_t co2tainerinv[80]; // player items in containers
/*1470*/ uint32_t cursorinv[10]; // player items on cursor
/*1510*/ struct itemPropertiesStruct containeritemprops[80];
//just like invitemprops[]
/*2790*/ struct itemPropertiesStruct cursoritemprops[10];
//just like invitemprops[]
/*2950*/ int32_t sSpellBook[512]; // List of the Spells in spellbook
/*4998*/ int32_t sMemSpells[8]; // List of spells memorized
/*5030*/ uint8_t unknown5030[36];
/*5066*/ float y;
/*5070*/ float x;
/*5074*/ float z;
/*5078*/ float heading;
/*5082*/ uint32_t unknown5082;
/*5086*/ uint32_t platinum; // Platinum Pieces on player
/*5090*/ uint32_t gold; // Gold Pieces on player
/*5094*/ uint32_t silver; // Silver Pieces on player
/*5098*/ uint32_t copper; // Copper Pieces on player
/*5102*/ uint32_t platinumBank; // Platinum Pieces in Bank
/*5106*/ uint32_t goldBank; // Gold Pieces in Bank
/*5110*/ uint32_t silverBank; // Silver Pieces in Bank
/*5114*/ uint32_t copperBank; // Copper Pieces in Bank
/*5118*/ uint8_t unknown5118[32];
/*5154*/ uint32_t skills[74]; // List of skills (MAX_KNOWN_SKILLS)
/*5450*/ uint8_t unknown5446[412]; // ***Placeholder
/*5858*/ uint32_t zoneId; // see zones.h
/*5862*/ uint8_t unknown5862[548];
/*6410*/ uint32_t bindzoneId[5]; // bound to bindzoneId[0]
/*6430*/ float sYpos[5]; // starting locs per bindzoneId
/*6450*/ float sXpos[5]; // starting locs per bindzoneId
/*6470*/ float sZpos[5]; // starting locs per bindzoneId
/*6490*/ uint8_t unknown9490[20];
/*6510*/ struct itemPropertiesStruct bankinvprops[8];
/*6638*/ struct itemPropertiesStruct bankinvprops2[8];
/*6766*/ struct itemPropertiesStruct bankinvcontprops[80];
/*8046*/ struct itemPropertiesStruct bankinvcontprops2[80];
/*9326*/ uint8_t unknown9326[4];
/*9330*/ uint32_t bank_inv[8]; // itemIds of the 8 bank slots
/*9362*/ uint32_t bank_inv2[8]; // itemIds of the 8 bank slots
/*9394*/ uint32_t bank_cont_inv[80]; // itemIds of items inside containers in bank
/*9714*/ uint32_t bank_cont_inv2[80]; // itemIds of items inside containers in bank
/*10034*/ uint32_t deity; // deity
/*10038*/ uint32_t guildID; // guild ID
/*10042*/ uint8_t unknown10042[14];
/*10056*/ uint8_t pvp;
/*10057*/ uint8_t _level; // seems to be player level
/*10058*/ uint8_t anon; // 0 plain, 1 anon, 2 roleplay,
/*10059*/ uint8_t gm; // gm flag?
/*10060*/ uint8_t guildstatus; // 0 member, 1 officer, 2 leader
/*10061*/ uint8_t unknown10061[44];
/*10104*/ char GroupMembers[6][64]; // all the members in group, including self
/*10489*/ uint8_t unknown10489[24];
/*10513*/ uint32_t altexp; // alternate exp pool 0 - ~15,000,000
/*10517*/ uint8_t unknown10517[428];
/*10945*/ uint32_t aapoints; // number of unspent ability points
/*10949*/ uint8_t unknown10949[3353];
}; // 14302

[Zoolander]

This stopped the insta-crash with that one character for me. Still crashing sometimes when I get a newCorpseCode, but this is progress.

How can I dump decoded packets to a file to look at them? Once I can do that I can probably figure some of this stuff out for myself. :)

[codepig666]

edit packet.cpp and look for the following block of code:

if (showeq_params->logZonePackets)
if(!logDate(showeq_params->ZoneLogFilename, len, data))
emit toggle_log_ZoneData();



Move this block of code from where you find it to just before the line that reads:

switch (opCode)

All of this is in the EQPacket::dispatchZoneData method.

Depending on which version of packet.cpp you have, this logging block:
1 - may already be in the right place. (dump decrypted)
2 - may be at the beginning of the procedure. (dump encrypted)
3 - may be both at the beginning and in the correct place. (dump both)

Anyhow, if you just want to see clean data, move it to just above the switch statement, get rid of any other ones and turn on Zone Data logging from the Network menu option in the program.

As a courtesy, try not to make wild-ass guesses as to what things are. Examine the existing structure in everquest.h and locate all of those items. When you have identified all of them and verified their data-types, then move on to new information.

Notes/tips:
1: SpawnId is 16 bits.
2: Some structures are actually unions.
3: Everything is Intel ordered, so the hex values "12 56 9a de" represent the 32 bit number 0xDE9A5612. Could just as easily represent 2 16 bit numberx 0x5612 and 0xDE9A
4: Just because a number is "real" doesn't mean it is a "float"...coordinates are very often stored in fixed point notation.
5: Most things are split on byte boundries (with the noteable exception of coordinate/delta sets and heading/animation fields), so expect straightforward datastorage.
6: Learn to count. I posted some ugly code and I regret it. Before you post a structure, renumber it's comments and unknowns and make sure it adds up.

Have fun.
-piggy

[fester]

Originally posted by codepig666
4: Just because a number is "real" doesn't mean it is a "float"...coordinates are very often stored in fixed point notation.


Ok I have a question. I didn't follow what you mean by this? Is it a reference to how the "door" orientation is stored? (From memory it scaled from 128 to 512 for 0 to 360 degrees). Basically I am not sure I am following your definition of "real" and "float" here.

Also, did you verify all items not listed as unknown in the above structure?

Also, for anyone interested on packet structures there is some more info and code to help dump opcodes here:
http://seq.sourceforge.net/forums/showthread.php?s=&threadid=3491&highlight=howto

[suseuser7341]

fix point notation means that:

a loc of +1307.52 is stored as integer 130752. The decimal point is always before the last 2 digits ( thats why it is called fix point ;) )

Since the resolution of 2 decimals is fine there is no need for a true float representation, resulting in much faster integer calculations.

[codepig666]

Acutally, there is more to fixed point than that....

Fixed point algorithms assume that the encoder and decoder have shared knowledge about the precision of their numbers.

You are given a bunch of bits and you have to know before hand how many of them represent the divisor.

Take, for example, the X,Y, and Z coordinates and their corresponding "delta" values...

The X Y and Z values are 19 bits long with a 3 bit fixed point. This does NOT mean that the last 3 bits are the fractional part. This means that you take the all 19 bits and divide it by 8 (2^3) to get your floating point value.

The "delta" values are 13 bits long with a 2 bit fixed point, so you divide the 13 bit integer by 4 (2^2) to get the float.

This type of fixed point is also called "binary point" because it's the equivalent of just sticking a decimal point in the middle of your number:

The 7 bit binary number with 3 bit fixed point 0101010 means:

8_4_2_1_._1/2_1/4_1/8
0_1_0_1_.__ 0__1__0

or 5.25 which is 42/8

Sorry about the underscores. I was trying to line up the halves, fourths and eights columns in a way that made sense.

hope that was clear.

Fun fact: because of this, no zone can extend farther than 32767 feet from the origin in any direction and even the fastest bard can never exceed 1023 feet per second. (assuming that an EQ unit is a "foot")

-piggy

[Jel321]

Still crashes on me with the updated struct.

They patched test tonight so maybe something changed again.

[codepig666]

post your crash

[user387]

every character shows up as being male with this struct...

guess something isn't 100% correct yet.

[Jel321]

Here's the crash running with gdb.

Client Detected: 192.168.123.100
GuildMgr: new guildsfile written
GuildMgr: guildsfile loaded
WARNING: CharProfileCode (006b) (dataLen:3926 != sizeof(charProfileStruct):14302)!
Player::backfill():
Loaded map: '/usr/local/share/showeq/Qeynos2.map'
No Zone Specific filter file '/usr/local/share/showeq/filters_qeynos2.conf'.
Loading default '/usr/local/share/showeq/filters.conf'.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1085131840 (LWP 1690)]
0x404e86d3 in QString::deref() () from /usr/lib/qt-3.1/lib/libqt-mt.so.3

and the back trace that accompanies it.

#0 0x404e86d3 in QString::deref() () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#1 0x404e87bc in QString::operator=(QString const&) ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#2 0x08100199 in Player::setLastKill(QString const&, unsigned char) (
this=0x4066f27c, name=@0xbfffc7c0, level=61 '=') at player.cpp:727
#3 0x0806ea1b in SpawnShell::killSpawn(newCorpseStruct const*) (
this=0x836ff70, deadspawn=0x841cbf0) at spawnshell.cpp:903
#4 0x0807d7ef in SpawnShell::qt_invoke(int, QUObject*) (this=0x836ff70,
_id=19, _o=0xbfffc8a0) at qucom_p.h:312
#5 0x4026e040 in QObject::activate_signal(QConnectionList*, QUObject*) ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#6 0x0808b8ca in EQPacket::killSpawn(newCorpseStruct const*, unsigned, unsigned char) (this=0x836d8f0, t0=0x841cbf0, t1=34, t2=2 '\002') at m_packet.cpp:1312
#7 0x080866a6 in EQPacket::dispatchZoneData(unsigned, unsigned char*, unsigned char) (this=0x836d8f0, len=34, data=0x841cbf0 "\025\001\030\v", dir=2 '\002')
at packet.cpp:2107
#8 0x08084826 in EQPacket::dispatchPacket(int, unsigned char*) (
this=0x836d8f0, size=18970, buffer=0xbfffca9e "E") at packet.h:429
#9 0x08083fc1 in EQPacket::processPackets() (this=0x836d8f0) at packet.cpp:787
#10 0x0808f08d in EQPacket::qt_invoke(int, QUObject*) (this=0x836d8f0, _id=2,
_o=0xbfffd130) at m_packet.cpp:2174
#11 0x4026e0c9 in QObject::activate_signal(QConnectionList*, QUObject*) ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
---Type <return> to continue, or q <return> to quit---
#12 0x4026df6d in QObject::activate_signal(int) ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#13 0x4054f68b in QTimer::timeout() () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#14 0x4028ef12 in QTimer::event(QEvent*) ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#15 0x4020ff24 in QApplication::internalNotify(QObject*, QEvent*) ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#16 0x4020fb19 in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#17 0x401ead95 in QEventLoop::activateTimers() ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#18 0x401c88e8 in QEventLoop::processEvents(unsigned) ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#19 0x40223cf6 in QEventLoop::enterLoop() ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#20 0x40223b98 in QEventLoop::exec() () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#21 0x40210151 in QApplication::exec() ()
from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#22 0x08064bb9 in main (argc=2, argv=0xbfffd944) at main.cpp:930
#23 0x42015504 in __libc_start_main () from /lib/tls/libc.so.6

I do have 1 character that doesnt seem to crash at all. A noob with basically nothing on him but the start gear.

Thanks for looking into it. If you need anything else let me know.

J

[codepig666]

The heart of your problem is here:

WARNING: CharProfileCode (006b) (dataLen:3926 != sizeof(charProfileStruct):14302)!

This says that you are getting the right opcode with the wrong data.

Are you playing on Test? I have no idea if the opcodes for test are different. I always assumed they were.

If you aren't on test, then all I can recommend is a wipe of all your showeq files, a complete re-download and then grabbing the last few posted updates.

But honestly, I can't think of any legitimate way that the production servers would send you that opcode without the right packet with it, so something funky is goin on on your end.

-piggy

[Jel321]

I do play on test, and yeah i kinda figured that something was different on there.

They are patching on 11th, we'll see if carries over to production then.

Thanks again for looking at it.

[Amadeus]

Well..even if SEQ is only kindof working on test..that's good news considering the number of changes going in.

[Jel321]

Im not expecting a fix or anything really but some more info...

Before i put in the updated struct i would crash instantly on zoning in, after updating i usually get a full decode and crash only seconds before i finish the zone.

Plus, sometimes it actually fully works, which is even odder. Usually when i zone with nothing on.

So yeah, its kinda working, probably will be hit or miss if you start seg faulting or not. With how it has been behaving it seems like its related to the amount of inventoy (on char and in bank). Yes that's a wild ass guess. ;)

One last thing, if i seg fault and then fire up showEQ again before i finish the zone i get my PC position and unknown spawns to show up, so i can still use it as a mapping device most of the time. Have to manually open the map, but its better than nothing :)

[codepig666]

I know that the new bank is coming in the next patch, so that means the charprofile has changed at at least that point. In other words, everything after your bank is guaranteed to be shifted out of place.

To quote Dilbert, "Shift happens."

I'll review test tonight and see if I can start a patch for the coming release.

-piggy

[unknown_errors]

now that that i have this update what do i do with it ?

[S_B_R]

I believe Ratt has already added these updates to the CVS tree.

[gothopie]

even after patching and recompiling I'm still getting bad streaks of:
WARNING: CharProfileCode (006b) (dataLen:3926 != sizeof(charProfileStruct):14302)!
Player::backfill():
Segmentation fault
but only with certain zones, or certain chars, sometimes I can rezone alot and it fixes it, some places it will just refuse to work
Going up to Character and unchecking Auto Detected Settings seems to have fixed it for the time being
is anyone else still getting these messages as of june 18th?

[fester]

If I understand correctly, the 6/11/03 patch changed the size of the player structure. This will mean there needs to be a new patch to correct these changes. The packet size shrunk.

[user387]

Originally posted by fester
If I understand correctly, the 6/11/03 patch changed the size of the player structure. This will mean there needs to be a new patch to correct these changes. The packet size shrunk.

Correct..

it's in a different post, something about the test server, since it's the struct of the test server they used.

[gothopie]

ok, just making sure I'm not alone, or haven't done anything wrong and wanted to mention my "fix" for others who might have the same issue.
I think it's a little weird how sometimes it'll decode and run fine, other times it will totally crash (for BoT it would crash EVERY time I'd zone in, or log out then back in, other zones in pop were a bit more forgiving, giving me some chance of having it work)
In any event, great job on keeping seq alive Devs, it helps make my limited EQ time more enjoyable :)

[sea4th]

I was getting seg faults every few minutes so I read the thread about finding the actual opcode that seg faults by adding a printf statement to the packet.cpp file. After entering the printf and fflush statements, make distclean, make -f Makefile.dist, ./configure, make, make install it has not crashed one time in 2 days of continous use.

I am running RH7.2 with KDE on a 233MHz P2MMX 296M memory. I do not have an explanation of why this would be but thinking along the line of fflush having a positive effect here. I wold love to hear a better explanation.

Regards ---

[monklett]

I can confirm that turning off 'auto detect settings' under character drop-down seems to totally fix crashes after 6/11 patch. I am running CVS current as of 6/10 + diff posted in recent post titled 'latest patch' by oakley and I am playing on a regular blue server, not PvP or Test. I got no crashes after several hours of play with multiple zones and characters.

Unfortunately, disabling this setting also breaks SEQ's ability to color-code mobs according to their level. Color-coding also remains broken even if you manually enter the your character's level/class/race, which is likely a bug. However, this work-around is more than sufficient to have a working SEQ until a better patch can be constructed.

Thanks again for all your efforts guys.

[user387]

I donno, but I'm running with latest CVS, and that patch, and I don't have any crashes either. no need to turn anything off. Only thing that bothers me is the Loaded map: GARBAGE, which messes up my xterm every now and then.

[monklett]

Hmm, I probably have an older version of some file. My newest (unpatched) file is dated 6/7, although I did the CVS update on 6/10.

Based on the comments about changes to the size of the packet, I suspect that any virgin pre-6/11 CVS compile would (at least) require this workaround to be stable. So, this information might be useful to those that want a stable mostly-working SEQ while they wait for the next 'official' CVS update.

Nice to hear that you have it working flawlessly tho; hopefully, those changes will get blessed soon.

[Elyon]

Don't forget on the color coding, SOE changed the con levels with the last patch too. Lower level mobs that used to con Light Blue, now Con Blue, Green ones now con Light Blue.

I raised all the numbers in the table in player.cpp by 5. For instance, what was at level 64 - 65

greenrange = -18

is now

greenrange = -23

I did the same for all levels down to < 61 and it seems to be acurate, YMMV.

[monklett]

By broken, I mean that all mobs /con deep red, regardless of their level. Its as if ShowEQ is ignoring the settings you enter and treating the player's character as if its level 1.

Not a big deal; works fine otherwise.

[jesterbam]

Monklett,

I was having problems like you. Did a refresh CVS and applied the diff patch with no fix. It still crashed depending on which char and which zone.

So I blew away EVERYTHING associated with SEQ. Deleted each folder the did a fresh CVS download I compiled that first then applied the diff patch and compiled again. Bingo hasn't crashed in days.

You probably don't have to do the two compiles but that is what I did and it worked. iam running RH7.2.