LDoN /who crashes - the reason

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

[LamahHerder]

fix'd /who

but if you do example: /who playername still crashs

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

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

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

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

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

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

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

[ap50]

Yes, it's fixed, /who works fine in LDoN now.

[pooz]

You know... I only read posts by ap50... everyone else I just kind of gloss over.

[insanitywiz]

His icon distracts me too much to actually read his posts.

[vzmule]

hahaha

[xyilla]

мрак243.4BettCHAPMarkСергJasiMetrкартХомеНурпTescKrigИльиWallИллюСтишDekoчитаUnit

[xyilla]

кончБордЭйдеsosiAmorTescKeepСодепонрискуusagискуAcca477-Всер(194EchoReacBylyсерт