Palatial guild hall map not loading

[Nstalkerga]

(did a search and didnt see topic covering it)

OK wondering if its just me.
Not sure when it started .. or if its always been this way.

But ive used both myshoweq and showeq on and off for a long time.
For some reason i cannot get the palatial guild hall to load the map automatically on showeq. Works fine on myshoweq.
I've pulled down maps new maps, copied them from myshoweq.
reran conversion, tried raw maps. Hell i even tool maps from showeq .. put them on myshoweq.
wiped and cleared the showeq and recompiled as well.


pretty much always works on myshow, never on show.

Thoughts.

[cn187]

Will you please zone into the guild hall and post (or PM me) the snippet from the console that shows the zone and map load? It should look something like this:

Zone: EntryCode: Client
Info: Attempting to load map: /root/.showeq/maps/poknowledge.txt
Info: Loaded SOE map: '/root/.showeq/maps/poknowledge.txt'
Zone: Zoning, Please Wait... (Zone: 'poknowledge')

[Nstalkerga]

douh guess i could have looked there too to see the shortname it was looking for

Info: No Map found for zone 'guildhalllrg_int'!
Info: Checked for all variants of 'guildhalllrg_int.map', 'guildhalllrg_int.txt', and 'guildhalllrg_int_1.txt'
Info: in directories '/root/.showeq/maps' and '/usr/local/share/showeq/maps'!
Info: Loaded spawn points: /root/.showeq/spawnpoints/guildhalllrg_int.sp


Mine all show that map as
guildhalllrg.map

knowing that i can copy it to the _int file and it works for now.

[cn187]

That explains the issue.

I'm a little curious what the _int suffix is for. I know we needed to add a workaround for a _progress suffix that started showing up on some (presumably TLP related) DZs. I just added a workaround for _int to my cn187_devel branch. I also updated the display names for the guild halls, because they didn't match what alla/magelo said they were called (Palatial was getting called Grand, and Grand was getting called Greater).
I'll merge them to trunk soon-ish, but in the mean time it's fixed there.

IIRC, there are a couple of places in the zone packet with the shortname, one with the suffix and one without. I haven't investigated the possible impact, but rather than continuing to add workarounds for various suffixes, it may just be as simple as switching to using the other name field in the packet. I'd need to see what else it might break, but I think it would be fairy safe.