Update in Radius only?

[DemonLord]

Hello people!

Just a q:
Did Sony change it or is it Yellows SEQ fault that mobs and players are only updated in a small radius around the player? The rest of the zone is frozen and only updating when i come near stuff. Mostly recognized in a zone with a lot of moving stuff, you see the radius around you, where every mob "stops". The resulting figure is a circle of mobs around you.

If it is Sony, i cant blame them. Sending the entire zone over and over is a major reason for lag.. :)

-Demon.

[jgorrell]

would that not break tracking if it were true? ;)

[LordCrush]

I dont run the newest version of SEQ (play on localized server) but i cannot think of a way to cut down the information to less than the whole zone without changing the complete structure of EQ. It depends that all infos of a Zone are availible ... so it seems to be a bug in SEQ .. i have read this in other threads ...

So please do a SEARCH before posting ;)

Edit ... and yes it would break tracking and some other things ...

[Highlander]

I noticed the same thing

[Cryonic]

What needs to be sent for current model of EQ to work (e.g. track characters).

1) all mob info on zone in
2) spawn and death of mobs
3) arrival/departure of characters
4) movement of mobs/characters within a given radius of char (say 3 - 4 times maximum visible range).

Track would work to a degree. In fact would behave more realistically. Instead of pointing you at the mob, it would point you to where you last knew the mob to be. Get close enough and it will repoint you in the right direction. They seem to have been heading towards this for a while (e.g. player position updates, reducing updates of mobs to movement, etc...).

[S_B_R]

Yep, the way mob position/movement data is sent was changed awhile back. Mob location data seems to only update when you are in range. Also when a mob starts moving you are updated with the Starting location, speed and direction. Where the mob stops is not sent, only when the mob begins to move again will it's location be updated, otherwise the mob appears to continue off in a straight line from where it started, with no regard for zone walls or etc.

At first glance it looks like the old ghosting problem, but there seems to be some method to the madness. ;)

[monster69]

This change is very noticable in large outdoor zones such as OT. I was standing stationary for a very long time there and ended up with a Semi-circle of mobs around me. I assume this is the "cone of visibility" of sorts that SOE is using to limit 1) how much data they must continually send and 2) limit the functionallity of sniffer programs.

Monster

[KaL]

I had the same semi circle of mobs around me last night in Skyfire. I think it might be related to not having all the opcodes correct, though. I know my version doesn't allow for mobs to "stop moving," -- they keep going in a straight line on ShowEQ after they stop in EQ.

[S_B_R]

Hmmm, that's probably closer to the truth KaL. But it does seem to effect in-game tracking in a similar fashion..

Hoepfully it is just an opcode thing, that would atleast be fixable from this end.

[Rhonwyn]

It seems to me that it must be an opcode thing since SEQ and EQ do not agree on where a mob is. The EQ server only sent a direction and speed when something started moving, eventually you would see it run in front of you, like the ghosting problem. What I am seeing is the mob run past me in SEQ, but I am not seeing the same mob in EQ. So something must be telling the client that the mob either stopped, changed direction, died, or just gave up existance.

[LordCrush]

Just a thought ... has MySEQ the same "feature" now ?... if not the info must be "somewhere out there" ;)

[Tomax]

Just so happens I compared MySEQ and SEQ last night and found that MySEQ did not have the problem. Mobs on MySEQ showed correctly and did not drift when the Mob in EQ stopped.

[S_B_R]

execellent. :D

[fester]

It may be as simple as the structure format and/or opcode is different for these two cases.

[LordCrush]

Originally posted by Tomax
Just so happens I compared MySEQ and SEQ last night and found that MySEQ did not have the problem. Mobs on MySEQ showed correctly and did not drift when the Mob in EQ stopped.

Thank You :)

[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?