Breaking down the spawnlog

[Asterof]

I have search but found no message explaining the log entries
Could some one break this down please

+:Quillmane00(2793):30:-15240,-46720,202:05.49.37:3:southkarana:04.56.04.17.3256: (0):-1

x:Quillmane00's corpse(2793):30:-1949,-5878,15:05.50.29:3:southkarana:05.13.04.17.3256:Xa stik00(2783):65535

Mostly dont understand the time

(2793):30:-15240,-46720,202:05.49.37:3

04.56.04.17.3256:(0):-1

and the extra stuff here
Thanks

[Asterof]

I would have notice the header line in the file
Sorry

[sea4th]

+:Quillmane00(2793):30:-15240,-46720,202:05.49.37:3:southkarana:04.56.04.17.32560 ):-1

x:Quillmane00's corpse(2793):30:-1949,-5878,15:05.50.29:3:southkarana:05.13.04.17.3256:Xa stik00(2783):65535

==========================

For the new spawn location it doesn't make sense for some of the spawns. The "x" for the corpse shows a valid location of (-1949,-5878,15) but the spawn location isn't on the map (-15240,-46720,202). Codepig and others have some posts on this as well as posts on the ghosting , warping , and mob movement updates. I have noticed seeing a mob in EQ and running toward it would cause it to jump or leap a large distance away. Just be aware that EQ is buggy ana ShowEQ adds it's own bugs from interpretation of the data stream.

[karrde]

Originally posted by sea4th
+:Quillmane00(2793):30:-15240,-46720,202:05.49.37:3:southkarana:04.56.04.17.32560 ):-1

x:Quillmane00's corpse(2793):30:-1949,-5878,15:05.50.29:3:southkarana:05.13.04.17.3256:Xa stik00(2783):65535

==========================

For the new spawn location it doesn't make sense for some of the spawns. The "x" for the corpse shows a valid location of (-1949,-5878,15) but the spawn location isn't on the map (-15240,-46720,202). Codepig and others have some posts on this as well as posts on the ghosting , warping , and mob movement updates. I have noticed seeing a mob in EQ and running toward it would cause it to jump or leap a large distance away. Just be aware that EQ is buggy ana ShowEQ adds it's own bugs from interpretation of the data stream.

Ok, this is bugging me still... not sure if anyone really looks at it though.

I think we need to look at the code, and the fuctions that are called on zonein/new/death/removal. And I think we'll find that it's some sort of typecasting problem.


void
SpawnLog::logZoneSpawns(const zoneSpawnsStruct* zspawns, uint32_t len)
{
int spawndatasize = len / sizeof(spawnStruct);

const QDateTime& eqDate = m_dateTimeMgr->updatedDateTime();
#if (QT_VERSION > 0x030100)
const QTime& time = QTime::currentTime(Qt::LocalTime);
#else
const QTime& time = QTime::currentTime();
#endif

for (int i = 0; i < spawndatasize; i++)
{
const spawnStruct& spawn = zspawns->spawn[i];
logSpawnInfo("z",spawn.name,spawn.spawnId,spawn.level,
spawn.x, spawn.y, spawn.z,
eqDate, time, "", 0, spawn.guildID);
}
}

void
SpawnLog::logNewSpawn(const newSpawnStruct* nspawn)
{
const spawnStruct& spawn = nspawn->spawn;
logSpawnInfo("+",spawn.name,spawn.spawnId,spawn.level,
spawn.x, spawn.y, spawn.z, "", 0, spawn.guildID);
}

void
SpawnLog::logKilledSpawn(const Item *item, const Item* kitem, uint16_t kid)
{
if (item == NULL)
return;

const Spawn* spawn = (const Spawn*)item;
const Spawn* killer = (const Spawn*)kitem;

logSpawnInfo("x",(const char *) spawn->name(),spawn->id(), spawn->level(),
spawn->x(), spawn->y(), spawn->z(),
killer ? (const char*)killer->name() : "unknown",
kid, spawn->GuildID());
}

void
SpawnLog::logDeleteSpawn(const Item *item)
{
if (item->type() != tSpawn)
return;

const Spawn* spawn = (const Spawn*)item;

logSpawnInfo("-",(const char *)spawn->name(),spawn->id(),spawn->level(),
spawn->x(), spawn->y(), spawn->z(), "",0, spawn->GuildID());
}



And you'll have to forgive me because my c++ is way rusty. The two type of spawnlog entrys that report sane numbers are passed pointers to the direct structure and are refered to as 'spawn->x()', The ones who don't report sane numbers are both passed as elements of an array and are referenced as 'spawn.x'. As I said, my c is very rusty, I know it the difference between pointer and direct reference, but trying to make them into pointers to emulate the other functions is not helping matters sice I can't get it to compile......

[Freakyuno]

Some of what you are seeing is related to an unfixable problem.

My understanding is that quite some time back. EQ implemented code with it's patch to "reduce client bandwidth needed". One of the effects of this code was, that after you move a certain distance away from something, you stop recieving updates about it.

As far as I am concered, was a very shotty way for Sony to do it, but thats the way it is. That is why when your looking at a whole zone, and decide you need to kill mob X half way across the zone, you start running at it, and then it "jumps". You got close enough that the server decided you needed updates regarding this mob again.

If I understand this wrong, then feel free to delete this.

[Cryonic]

I think there was something about this in another thread.

http://seq.sourceforge.net/forums/showthread.php?s=&threadid=3787

Apparently MySEQ has no issues with tracking mobs even across a large zone, so SEQ must still be missing some mob update packets.

[karrde]

I guess I should have started a different thread, since you're grabbing onto the wrong complaint. My complaint is not the mobs are not updating properly. My complaint is that while everything else in SEQ sees mobs at resonable locs, when zoning in and when a new mob spawns are written to spawnlog.txt the cordinates that are written out are completely bogus. However since deaths and removal of corpses seem to give proper cordinates, and the actuall write of the line in the spawnlog is the same fuction, I can only assume that how the parameters are being passed in the seperate instances are causing the discrepancy.

[karrde]

While staring at the code for a while longer and just not following the flow... I just looked at the numbers that were being put out.

Going into a zone where I could pretty much kill mobs on the spawn point, I looked at the results:


+:Lord_Gimblox00(2130):30:-2904,-6368,464::3:soldunga::(0):-1
x:Lord_Gimblox00's corpse(2130):30:-363,-836,57::3:soldunga:::65535


as an example. The X coord is a ratio of 8:1 the Y is slightly less and the Z is slightly more. So I wasn't as good at killing him on the spot. But if you take the coords and do the division by 8 you come up with (-363.5,-796,58) which looks suspiciouly like the soldunga.sp file that says (-363 -796 58).

So for whatever reason zone/new mobs are reported at coords that are x8 greater than they should be.

[Zaphod]

Originally posted by karrde
While staring at the code for a while longer and just not following the flow... I just looked at the numbers that were being put out.

Going into a zone where I could pretty much kill mobs on the spawn point, I looked at the results:


+:Lord_Gimblox00(2130):30:-2904,-6368,464::3:soldunga::(0):-1
x:Lord_Gimblox00's corpse(2130):30:-363,-836,57::3:soldunga:::65535


as an example. The X coord is a ratio of 8:1 the Y is slightly less and the Z is slightly more. So I wasn't as good at killing him on the spot. But if you take the coords and do the division by 8 you come up with (-363.5,-796,58) which looks suspiciouly like the soldunga.sp file that says (-363 -796 58).

So for whatever reason zone/new mobs are reported at coords that are x8 greater than they should be.

And that is correct, if you look at how spawn.cpp and spawnshell.cpp you'll find that all those numbers are in fact divided by 8 (well, bitshifted 3 to the right which is the same thing). This is because the position information for the spawns, and their updates are currently sent down using fixed point math with q=3.

Enjoy,
Zaphod (dohpaZ)

[karrde]

Originally posted by Zaphod
And that is correct, if you look at how spawn.cpp and spawnshell.cpp you'll find that all those numbers are in fact divided by 8 (well, bitshifted 3 to the right which is the same thing). This is because the position information for the spawns, and their updates are currently sent down using fixed point math with q=3.

Enjoy,
Zaphod (dohpaZ)

so perhaps the following is called for:

*** spawnlog.cpp.orig Sat Nov 8 09:06:55 2003
--- spawnlog.cpp Sat Nov 8 09:07:44 2003
***************
*** 17,23 ****
: SEQLogger(fname, NULL, "SpawnLog"),
m_dateTimeMgr(dateTimeMgr)
{
! version = 3;
zoneShortName = "unknown";
}

--- 17,23 ----
: SEQLogger(fname, NULL, "SpawnLog"),
m_dateTimeMgr(dateTimeMgr)
{
! version = 4;
zoneShortName = "unknown";
}

***************
*** 25,31 ****
: SEQLogger(fp, NULL, "SpawnLog"),
m_dateTimeMgr(dateTimeMgr)
{
! version = 3;
zoneShortName = "unknown";
}

--- 25,31 ----
: SEQLogger(fp, NULL, "SpawnLog"),
m_dateTimeMgr(dateTimeMgr)
{
! version = 4;
zoneShortName = "unknown";
}

***************
*** 97,103 ****
{
const spawnStruct& spawn = zspawns->spawn[i];
logSpawnInfo("z",spawn.name,spawn.spawnId,spawn.level,
! spawn.x, spawn.y, spawn.z,
eqDate, time, "", 0, spawn.guildID);
}
}
--- 97,103 ----
{
const spawnStruct& spawn = zspawns->spawn[i];
logSpawnInfo("z",spawn.name,spawn.spawnId,spawn.level,
! spawn.x >> 3, spawn.y >> 3, spawn.z >> 3,
eqDate, time, "", 0, spawn.guildID);
}
}
***************
*** 107,113 ****
{
const spawnStruct& spawn = nspawn->spawn;
logSpawnInfo("+",spawn.name,spawn.spawnId,spawn.level,
! spawn.x, spawn.y, spawn.z, "", 0, spawn.guildID);
}

void
--- 107,113 ----
{
const spawnStruct& spawn = nspawn->spawn;
logSpawnInfo("+",spawn.name,spawn.spawnId,spawn.level,
! spawn.x >> 3, spawn.y >> 3, spawn.z >> 3, "", 0, spawn.guildID);
}

void


This way the coords in the spawnlog.txt will be consistant, since in these two instances the unshiften numbers are reaching the logging functions.

Edit: I also put in a change of logging version so that the script I'm writing can tell the difference between when to divide and not.

[Zaphod]

Yeah, that's basically the same fix I applied to the sources that'll be included in my next CVS commit.

Enjoy,
Zaphod (dohpaZ)