Update in Radius only?

[Wois]

this isnt a complete fix, but

go into src/opcode.h

replace

#define MobUpdateCode 0x0038

by

#define MobUpdateCode 0x0039

it helps

have fun

[ieatacid]

That makes it a little better, thanks

What if we increase it more? to, say, 0x0042 or something?

[Wois]

that won't work at all, just like 0x38

that number is an "opcode", it's a "unique" number that identifies the type of packet. it got changed in the last patch (and not included in zoo's patch to showeq i believe, i havent checked).

in our case, 0x39 now means a mob position update packet, while it was 0x38 before. it could just as easily have decreased or jumped to 0x143 (just a random number :P im not sure that's actually a possible numbers, anyone know? isn't there a "version" somewhere?)

[ieatacid]

Ahh, I get what you're saying.

[Baklan]

Is it necessary to remake SEQ after changing the opcode?

[Wois]

yes, anytime you change somethijng in there it's a good idea to remove the .o files and make it all over again (removing the .o seems to be nescessary as the makefile dependencies seems to be broken for opcode.h and everquest.h)

[arantius]

In fact, it would be beneficial for them in all ways (except perhaps a lot of distance calculations, which I expect would work out to less server overhead overall) to only transmit the info you need.
Broken tracking? Have the server always update location info for whatever you're tracking. This would even fix tracking players which would be very good. Long wished they did that anyway. Or simply moving the message to come from serverside would also work.

[junk]

What are the chances of throwing all the opcodes into a config file so we can change them at run time rather than only being able to change them at design time?

[S_B_R]

You know, that's a good Question.... There must be a reason it's not done that way, otherwise that would just be silly to not be doing opcodes that way....

Anyone know?

[LordCrush]

Atm the opcodes are in an headerfile as #defines. That means that the compiler inserts the opcode in the compiled program as numbers. So it is much faster than using a variable.

I have no clue if the time that is needed to look up an variable is too long, but it surely would slow down seq.

[user387]

since the opcodes are being used in packet.cpp, line 1852, in a case statement, you can't really put them in a config file unless you change a lot of things.

[LordCrush]

Btw where does it make much difference - just change header-file and recompile

[fester]

You could alter ShowEQ to use "native" opcodes and put an .ini file that is used to build an index table that translates from the "wire" opcodes to native opcodes so the switch code is retained. If someone would like to do so, look at my post about native vs wire opcodes (it contains how to extract the table from the eqgame.exe.)

[jonseq]

Fester's idea would work. A switch statement typically builds a jump table where you look up the code location to go to based on the switched variable ... and one extra indirection wouldn't be bad.

A similar idea would directly store function pointers into the opcode lookup table instead of a standardized index into a switch statement ... which might be faster, might be slower (if you pass a bunch of parameters instead of keeping things global, the function call would be expensive).

I guess it's moot. Recompiling is not a big deal as there are usually other bugfixes/improvements as often as there are SOE patches.

I suppose a dynamic opcode table would help people who are finding and testing new opcodes, though =)

[sea4th]

The idea of having the opcodes a form of an array of variables would allow for some 'self configuration' in the future. There are certain patterns in the opcodes and some opcodes appear much more often than others which should allow some of them to be identified by their time of occurance or correlation to known events or by the frequency of their appearance. If a simple subsitution is being made from one version of the code to another, the opcodes have been 'replaced' with new ones but they still have the same function. I would expect this is one of the techniques the developers use to indentify opcodes but probably by a manual technique or trial and error/ cause and effect.

Placing the opcodes into an array of vars would provide the ability to change them without having to recompile the program. A 'best guess' attempt at matching opcodes to new ones could be somewhat automated by combinations of correlation of events - local client loots a corspe (opcode sent) -> client responds. This would require some interaction with the showeq local client but would allow more less skilled showeqers to investigate the data stream and offer observations.

First step is opcode statistics by zone.... any suggestions on what peeps want to see as results?