PDA

View Full Version : Wrong Op Codes



BlueAdept
11-24-2007, 09:50 AM
I believe there are still some issues that need to be worked out. Here are a list of warnings I am getting.

Warning: OP_NewZone (0xadc) (dataLen: 920) doesn't match: sizeof(newZoneStruct):916

Warning: OP_Action2 (0xa8c) (dataLen: 28) doesn't match sizeof(action25Struct): 24

I think it also loses synch after a while. I did a 24 hour camp and started getting

Warning: OP_TimeOfDay (0x175) (dataLen: 22) doesn't match: sizeof(timeOfDayStruct): 8

and

Warning: Op_Consider (0x10fa) (dataLen: 22) doesn't match: sizeof(considerStruct):20

It seemed to lock up SEQ it was stuck in the zone I was in. I had to restart SEQ.

If I come across any more, I will let you know.

BlueAdept
11-24-2007, 10:44 AM
These should fix some of the errors

Op_Action2 in everquest.h

/*
** Battle Code
** Length: 24 Octets
** OpCode: ActionCode
*/

// This can be used to gather info on spells cast on us
struct action2Struct
{
/*0000*/ uint16_t target; // Target ID
/*0002*/ uint16_t source; // Source ID
/*0004*/ uint8_t type; // Bash, kick, cast, etc.
/*0005*/ int16_t spell; // SpellID
/*0007*/ int32_t damage;
/*0011*/ uint8_t unknown0011[13]; // ***Placeholder
/*0024*/ uint8_t unknown0024[4]; // ***Placeholder (11/24/07)
/*0028*/
};


This will fix the zone struct.

/*
** New Zone Code
** Length: 916 Octets
** OpCode: NewZoneCode
*/
struct newZoneStruct
{
/*0000*/ char name[64]; // Character name
/*0064*/ char shortName[32]; // Zone Short Name (maybe longer?)
/*0096*/ char unknown0096[96];
/*0192*/ char longName[278]; // Zone Long Name
/*0470*/ uint8_t ztype; // Zone type
/*0471*/ uint8_t fog_red[4]; // Zone fog (red)
/*0475*/ uint8_t fog_green[4]; // Zone fog (green)
/*0479*/ uint8_t fog_blue[4]; // Zone fog (blue)
/*0483*/ uint8_t unknown0483[87]; // *** Placeholder
/*0570*/ uint8_t sky; // Zone sky
/*0571*/ uint8_t unknown0571[13]; // *** Placeholder
/*0584*/ float zone_exp_multiplier; // Experience Multiplier
/*0588*/ float safe_y; // Zone Safe Y
/*0592*/ float safe_x; // Zone Safe X
/*0596*/ float safe_z; // Zone Safe Z
/*0600*/ float unknown0600; // *** Placeholder
/*0604*/ float unknown0604; // *** Placeholder
/*0608*/ float underworld; // Underworld
/*0612*/ float minclip; // Minimum view distance
/*0616*/ float maxclip; // Maximum view distance
/*0620*/ uint8_t unknown0616[84]; // *** Placeholder
/*0704*/ char zonefile[64]; // Zone file name?
/*0768*/ uint8_t unknown0764[36]; // *** Placeholder (12/05/2006)
/*0804*/ uint8_t unknown0800[32]; // *** Placeholder (02/13/2007)
/*0836*/ uint8_t unknown0832[12]; // *** Placeholder
/*0848*/ uint8_t unknown0844[4]; // *** Placeholder (06/29/2005)
/*0852*/ uint8_t unknown0848[4]; // *** Placeholder (09/13/2005)
/*0856*/ uint8_t unknown0852[4]; // *** Placeholder (02/21/2006)
/*0860*/ uint8_t unknown0856[36]; // *** Placeholder (06/13/2006)
/*0896*/ uint8_t unknown0892[12]; // *** Placeholder (12/05/2006)
/*0908*/ uint8_t unknown0904[8]; // *** Placeholder (02/13/2007)
/*0916*/ uint8_t unknown0916[4]; // *** Placeholder (11/24/2007)
}; /*0920*/


They have not been commited to the tarball nor tested.

BlueAdept
11-24-2007, 01:42 PM
This will also be included in my next tarball but I tought I would post it here.

There is a file called staticspells.h. It has all the spells that are cast. It was generated from a perl script called spells_en2spellsh.pl. It isnt currently in the tarball but luckily it is in the cvs. I will re-add the file to the tarball along with updating the staticspells.h in the tarball.

The new staticspells.h file can be found here (http://www.eabos.com/staticspells.h).

Razzle
11-24-2007, 04:50 PM
I was looking at the spell list, and I would have buffs repeated on my char, same buff, and would be 3 or 4 occurences in the window. I did some looking, and it looks like there are some comparisons going on between unsigned and signed integers. Here is what I did to make it better.

In spellshell.h

From:

SpellItem* findSpell(int spell_id);
To:

SpellItem* findSpell(uint16_t spellId);


In spellshell.cpp

Associated type changes in findSpell:

SpellItem* SpellShell::findSpell(uint16_t spellId)
{
for(QValueList<SpellItem*>::Iterator it = m_spellList.begin();
it != m_spellList.end(); it++)
{
SpellItem *si = *it;
if (si->spellId() == spellId)
return si;
}
return NULL;
}
Changes in spellshell.cpp, so findId() passes an int parameter, instead of unsigned int:

selfStartSpellCast()


...
int tid = c->targetId;
if (c->targetId &&
((s = m_spawnShell->findID(tSpawn, tid))))
targetName = s->name();

item = findSpell(c->spellId, c->targetId, targetName);
...


buff


...
int sid = b->spawnid;
if (b->spawnid &&
((s = m_spawnShell->findID(tSpawn, sid))))
targetName = s->name();

item = findSpell(b->spellid, b->spawnid, targetName);
...


action


...
int tid = a->target;
if (a->target &&
((s = m_spawnShell->findID(tSpawn, tid))))
targetName = s->name();
...




...
int sid = a->source;
if (a->source &&
((s = m_spawnShell->findID(tSpawn, sid))))
casterName = s->name();
...

BlueAdept
11-24-2007, 06:32 PM
great. Thanks. I'll try it tonight. If anyone else makes the changes, can you let me know if there are any issues? I only play a couple hours a week. If there are no issues, I will add it to the tarball.

Jaxxian
11-25-2007, 06:34 PM
Yeah, I noticed when I installed the new 5.11.0.0 tarball it has a few weird things going on. Lots of times when I kill a mob instead of showing up as a small blue cross it stays looking like a live mob. This makes kills spots very messy very fast as far as telling what is what. Also in an AG instance atm and had to zone in and out and no map showed up when I rezoned in so I loaded one and only like 3 other of the 54 players show up and everything cons red to me even like level 34 familiars. So not sure why it would do that. Hard to be able test stuff on raids. Not much room for horsing around zoning and such. Will let you know if I see anything else. Thanks guys.

BlueAdept
11-25-2007, 07:17 PM
Actually I have had some problems since the expansion came out.

In the terminal window it should show the warnings, but those are the only ones I have seen, except for when it lost synch and I had to restart it.

Jaxxian
11-25-2007, 09:04 PM
I zoned a few times and it seemed to settle down some. Guess it was just being wonky. Seems to be working good now. Will keep you guys apprised if anything more pops up other than instablility flakiness. I know a lot of that can come from the Linux box and things like that so usually just try to ignore it.

ieatacid
11-25-2007, 11:19 PM
Those structs were posted in this thread (http://www.showeq.net/forums/showthread.php?t=5943&page=5&pp=15) ;)

As for the opcode stuff and ShowEQ locking up, I'm betting it sent a new obfuscator seed which caused all the opcodes to be wrong.

BlueAdept
11-26-2007, 07:58 AM
Those structs were posted in this thread (http://www.showeq.net/forums/showthread.php?t=5943&page=5&pp=15) ;)

As for the opcode stuff and ShowEQ locking up, I'm betting it sent a new obfuscator seed which caused all the opcodes to be wrong.


Hehe...sue me. There was so much going on in that thread that I missed them :) But at least I fixed it.

If it changed the seed, then zoning should have corrected it (I am guessing since it does the first time you log in), but it didnt even recognize that I had zoned.

Stupid question since I haven't looked, is there an opcode for the obfusicator seed? I have been logging all the packets in order to see if I can get it to replicate. If so I can watch for it. Maybe put a check into SEQ to check for changes.

Just so you know, I still havent heard from Ratt.

ieatacid
11-26-2007, 03:34 PM
is there an opcode for the obfusicator seed?

OP_ObfuscatorInfo should be at the top of zoneopcodes.xml.

If you uncomment line 1157 in packet.cpp it will debug spew the obfuscator seed to the console every time it receives it.

I've also been playing around with ways of resetting the opcodes when a new seed comes along, but I haven't had the luck of getting one to change while I'm logged in.

ieatacid
11-26-2007, 11:11 PM
I was getting warnings about OP_CorpseLocResponse


<opcode id="0292" name="OP_CorpseLocResponse" updated="11/26/07">
<comment>old CorpseLocCode:</comment>
<payload dir="server" typename="corpseLocStruct" sizechecktype="match"/>
</opcode>

BlueAdept
11-26-2007, 11:29 PM
Is SEQ still working for you? Everything is coming up as unknown for me.

ieatacid
11-26-2007, 11:52 PM
Yeah, I haven't noticed any unknowns at all. I'm still using 5.10 with the patches I posted and the action2 struct that someone else posted. I didn't get around to adding the spell stuff.

I also got it to save the obcodes and load them the next time you start. If the seed hasn't changed you log right in with skittles.

It also resets them all if it gets a new seed or if you switch servers (which gives you a new seed, too) but then the map is frozen until you restart the program. I can't figure out why, for the life of me. So it seems pretty useless to add all that if I can't figure out how to get the map to work after the opcodes are reset.

uRit1u2CBBA=
11-27-2007, 07:07 AM
Something may be wrong with some of the info posted in the last batch of code updates above in this thread. I never applied them, and things are fine.

I'm using he 5.11 tarball unmodified.

BlueAdept
11-27-2007, 08:29 AM
I went back to the tarball 5.11.0.0 and am still having the problem on my server. It may be server specific. Tonight I will check out another server that I have some toons on.

BlueAdept
11-27-2007, 09:11 PM
Wierd tonight it is working....

I wonder if it was server lag that was causing it.

BlueAdept
11-27-2007, 10:14 PM
I also got it to save the obcodes and load them the next time you start. If the seed hasn't changed you log right in with skittles.

It also resets them all if it gets a new seed or if you switch servers (which gives you a new seed, too) but then the map is frozen until you restart the program. I can't figure out why, for the life of me. So it seems pretty useless to add all that if I can't figure out how to get the map to work after the opcodes are reset.

I do not know how the seed works, but I was thinking the easiest way would be when ever the seed is broadcast, to save it to a variable (better yet, write it to a file too) and have it compare it to the current seed. If it changes, move the variable to the one that is currently being used.

I have done some programming, but I am not vary familiar with this source yet.

As for the map, I am not sure. I would have to try to figure out how things are done before I could help you with that.

ieatacid
11-27-2007, 10:52 PM
Yeah, that's what I have it doing. I just had it make a file called opcodes.log that looks something like this


seed=1f4b872
seed2=ee
482c=7b
3167=104
211a=4b8
...
..


When it starts, if there's a saved seed it loads the saved opcodes. If the seed was the same as the last one it saved then your opcodes will be the same and you'll log right in with skittles (edit: it actually saves both of them since they both change). If the seed has changed it reloads the new opcodes but then the program does nothing.

It also checks every time it gets an obfuscator packet to see if it's the same as the last saved one. If it's different it reloads them and, like it does if you log in with a different seed, I expect it will then also stop responding. I just haven't tracked down what's causing it yet :(

BlueAdept
11-27-2007, 11:07 PM
I wish I had more time to actually look at the code to try to figure it out. Long hours at work, girlfirends and life in general leave me little spare time. Of the couple hours a week, I usually end up pling some gimp toons because I don't have the time to raid anymore.

If there is anything I can do to help, let me know.