Page 1 of 1
LDoN /who crashes - the reason
Posted: Sun Sep 14, 2003 10:41 am
by morannon
The problem is occuring in GetFullZone (in EQlib_utilities.cpp)
The ZoneID being passed in for LDoN zones is huge (over 1,000,000,000) this causes problems with lookups.
I changed the GetFullZone function to look like :
Code: Select all
PCHAR GetFullZone(DWORD ZoneID)
{
PZONELIST *pZone = NULL;
if (ZoneID > 10000) return NULL;
if (!EQADDR_ZONELIST) return NULL;
if (!*EQADDR_ZONELIST) return NULL;
pZone = (PZONELIST*) (((DWORD)*EQADDR_ZONELIST) + ZONELIST_STARTOFFSET);
return (*pZone[ZoneID]).LongName;
}
Not had a crash in LDoN yet with this change.
Posted: Sun Sep 14, 2003 6:02 pm
by LamahHerder
fix'd /who
but if you do example: /who playername still crashs
Posted: Sun Sep 14, 2003 7:18 pm
by kagonis
Hmm, I did /whotarget yesterday with a build from the 13th. Worked fine in LDoN, it was when I did regular /who (with or without switches) it crashed.
Posted: Mon Sep 15, 2003 1:25 am
by Nanan
Cool this works. Thanks for the insight. To totally fix this the var pzone is going to have to be set to a higher aloud value. In its current condition it is to small to handle the new zones masive number handle.
Posted: Mon Sep 15, 2003 3:12 am
by Amadeus
This actually sounds like something is wrong with the struct. Or, perhaps zoneID is now actually a float value *shrug*. Either way, it sounds from what you wrote, like something is changed in a zone struct of some sort.
I havn't bought LDoN yet (going to around Oct. 1) which is why I havn't contributed very much lately. If no one has dealt with it before then, I'll fix all the structs (including all the new LDoN data) around that time. I'm sure the COMMON struct must have a ton of new things in it for the new data.
Posted: Mon Sep 15, 2003 6:46 am
by morannon
If there was a problem with the struct, or the type had changed, then it wouldnt work for any zone would it ?
During several hours play yesterday, the number for a given zone (say taka) changed each time a new zone was summoned.
Given the way LDoN works, this makes sense - since the server needs to know which copy of a zone you have. I wouldnt be surprised to find that the zoneid is a value that corresponds to something server side.
ShowEQ has a similar problem - the zone was being reported as taka_NNN where NNN seemed to change from zone to zone.
There has to be a place ...
Posted: Mon Sep 15, 2003 11:34 am
by MacroFiend
where the LDoN zone info is normalized. Perhaps there is a new zoneid hiding in there someplace ... or maybe the very-large zone number can be broken down to make a standard zone id.
The reason I mention this is because even if you don't have LDoN, you would still see the long LDoN zone names on your guild info panel if a guildmate was in an adventure zone. So unless EQ is sending over the whole name, which would be a waste of bandwidth, there's some place that it is stored as a number.
Perhaps peeking around the memory area for the guild pane would be a place to start looking? Find a known zoneid for a guildmember and then track down an LDoN zoneid and see if it is the very-large number there?
Posted: Mon Sep 15, 2003 7:30 pm
by Nanan
Iv not tested it yet but im thinking the return for pzone in ldon zones is a composite number like... 123,456,789,012,345 where the initial 123456 is the zone ID and the 789012345 is the instance number.
Posted: Mon Sep 22, 2003 4:14 pm
by vzmule
I don't personally use LDON, but was wondering if anyone came up with a fix for the superwho problem with the zone IDs in ldon zones.
Posted: Mon Sep 22, 2003 4:16 pm
by ap50
Yes, it's fixed, /who works fine in LDoN now.
Posted: Mon Sep 22, 2003 9:39 pm
by pooz
You know... I only read posts by ap50... everyone else I just kind of gloss over.
Posted: Tue Sep 23, 2003 2:11 am
by insanitywiz
His icon distracts me too much to actually read his posts.
Posted: Wed Sep 24, 2003 7:36 am
by vzmule
hahaha