Few apparent bugs in the 5/24 CVS that I have found....

[Jezebell]

Seems to occur with older versions too, just wanted to mention what version I was running.

#grid and #wp do not seem to be working.
Also #wpinfo is not implemented yet.

Changing the long_name works for some zones but doesn't work for alot, including:

gfaydark
felwithea
felwitheb
kaladima
kaladimb
rivervale
sseru

It DOES work for:

tutorial
potactics
shadowrest
hole

These apparantly issues with the code not reading the long_name field or perhaps the long_names are hardcoded into eqgame.exe for alot of zones. Anyone have any isea on this?

[cofruben]

when you zone,you see a text: Entering Tuturial... for example.That is hardcoded,but if you look,after zone,you can see:"You entered tutorial".The last one can be changed.

[Jezebell]

when you zone,you see a text: Entering Tuturial... for example.That is hardcoded,but if you look,after zone,you can see:"You entered tutorial".The last one can be changed.

Actually the "Entering Tutorial...." text can be changed by editing eqstr_us.txt with Wordpad, just open it, search for Tutotial and change it to whatever you want then save it.

The "You have entered Tutorial." text is what I am talking about as having a problem. The changing of the zone name text is handled in the database under the "zone" table in the "long_name" field, but it appears that changing the "long_name" does not work for every zone and I have had Khan test this on his server and he verified it. Which means that:

1. Either some of the "zone" "long_names" are hardcoded into eqgame.exe

or

2. The EQEMu code is not reading the "long_name" field in the "zone" table properly.

[Derision]

I just took a very brief look at this. As in your case, it worked for potactics but not gfaydark for me also. I noted that I had a gfaydark.cfg file, but not a potactics.cfg file.

On renaming my gfaydark.cfg file to old_gfaydark.cfg, it then used my altered long_name for gfaydark. It would appear that if a <zone>.cfg file exists, it is using the long name that is stored in the .cfg file.

Added:

If you update the long_name in the db then go to that zone (even if the <zone>.cfg exists). If you then do #zsave <zone> it appears to write the long_name from the database to the .cfg file, so if you zone out, wait for the zone to shutdown, next time you zone back in you will get 'You have entered <your new long_name>'.

[KhaN]

Very interesting Derision, i was having the same problem as Jezebell, but now, my question would be "What is the real use of <zone>.cfg ?".

[Derision]

Another thing I noted is if you change the long_name and your new name is shorter than the old one in the .cfg file, you will get something like this:

Old name=Greater Faydark
New Name=Test

Name saved in zone.cfg = Testter Faydark

To get around this, pad out your new name with spaces, e.g.

update zone set long_name="Test<put enough spaces here to overwrite the old name>" where short_name="gfaydark" ;

As for what the .cfg files are used for, I think they have the safe co-ordinates for the zone, sky texture, and other such things. Not 100% sure.

[Jezebell]

Thanks Derision, I suppose that fixes that issue.

Know any reason why #grid, #wp, and #wpinfo are not working? :D

[RexChaos]

To my knowledge (and from messing with them) the zone.cfg's are just for fog color, sky texture, clipping minimum and clipping maximum. Safe loc's are in the db.