Fixing the freportw and ecommons Zoneline

mwmdragon · #1 01-14-2005, 06:54 AM

I can't find the answer to this anywhere and I know I'm not the only person having the problem.

I tried changing the values in the database but it only makes a section of the zoneline work (A strip in the middle of the zone) However when zoneing from the sides I get droped at some ungodly place no where near the safe coordinated. I think my server reports it as 2.0,2.0,2.0 Which it seems to be pulling out of its ass because those coordiates are not in the database anywhere.

Can anyone give us a definate fix answer for this problem ?

Wumpas · #2 01-16-2005, 02:39 PM

Wumpas crawls out from under the rock hes been hiding under for so long...

Same exact problem mwmdragon at first i thought it was the 9999 that was in the target field but when i fixed that and placed in data for the freportw side as it was 0 0 0. All i could get to work were the sides of the zoneline either left or right not the whole thing.

Also none of the zonelines seem to put me in the right spot i always warp to the center of the zonelines even if i went through on the left side or right?

im using 6.0 dr2 with minilogin and kunark db.

Im in Iraq so I cant check this much If I figure it out in the meantime Ill try and post.

mwmdragon · #3 01-16-2005, 06:47 PM

common there must be more help out there. Someone has to have fixed this. Just give us some help or atleast some heads up as to what we can do to fix it.

Is it fixed in the new PEQ database ?

#4 01-17-2005, 02:39 AM

I had a talk with FNW about this yesterday actualy, for S2K. FNW says they still have some broke zonelines and he isnt sure which, but they wont be butting out what they have fixed till Velious is put out.

OrtRestave · #5 01-17-2005, 02:43 PM

The fix is actually very simple, I just discovered it myself. The problem comes from a case descrepancy between the zone name in the "zone" table and the "zone_points" table. For regular zonepoints, the case doesn't matter, but for dynamic zonepoints ("999999") the server requires the case to be the same. I.e. it's "Commons" in the zone table and "commons" in the zone_points table. Zoning from befallen to commons works, but ecommons to commons doesn't.

But you just have to change the name in either table to match, and it works perfectly.

**WildcardX** · #6 01-17-2005, 05:16 PM

I can confirm that the above post does in deed fix the zoning issue between ecommons and freporte as well as a couple other troubling zones like qrg and qeytoqrg.

I dont suppose you have any ideas about why the zone between felwithea and gfaydark doesnt work. It appears to be a different issue, as if there isnt a zone line in the DB in felwithea, but I do see an entry in the DB so I am boggled about why it flat out doesnt work.

OrtRestave · #7 01-17-2005, 05:40 PM

It looks like the same issue...for consistency's sake, all zone short names should probably be lowercase in all tables.

mwmdragon · #8 01-17-2005, 07:05 PM

Thanks for the fix...

It is rather rude that a databade dev team would choose to hide this data until they are the first to fix the problem. I know there are a lot of DB errors still but to with hold support from such a devoted interest group is kinda greedy.

No flame or anything, just a point of view.I love the work they do on te DB and release the DB for free. They are doing a great job.

wize_one · #9 01-17-2005, 07:48 PM

the PEQ team has posted a while back, that any and all support for their databases will be on their site.

#10 01-18-2005, 01:31 AM

Quote:

Originally Posted by wize_one

the PEQ team has posted a while back, that any and all support for their databases will be on their site.

This has nothing to do with there DB, this is an issue with ANY batabases.