I'm also getting a TON of errors in every single zone launch and on other files:
queryserv: Code:
--------------------------------------------- Code:
--------------------------------------------- |
Try 127.0.0.1 rather than localhost.
|
lerxst thanks, that got me a bit further. Still having issues but I think that's from losing the login database and having to rebuild it by hand, slowly.
|
ok new stumbling block. I redid my eqemu_config.xml and login.ini because my old versions were out of date and missing stuff for queryserv and what not. After fiddling with IPs and account names, I'm now to this in the login server window. Everything else seems to be functional at this point. ALL of my internal IPs are now 127.0.0.1, because using the computer's own address of 192.168.1.5 would get rejected for some strange reason.
Code:
[Debug] [11.18.13 - 23:28:45] Logging System Init. |
EDIT: nevermind. Solved it. I had the password for the server login table encrypted SHA like accounts are, put it into plaintext and it worked fine. :)
|
Ok, I think this might be the last step to getting the server reanimated from the grave. I had forgotten that the old login db was a separate db, so in my fury to delete/reinstall mysql a few times a couple days ago, I deleted the whole directory after dumping peq, but forgetting about peqlogindb. I didn't empty recycle bin, recovered the raw data files, but don't have the server instance or anything in registry left. What's the easiest way to attach those raw data files to a server to extract whats in them? If I can get access, I can just migrate the data easy enough.
Edit: don't have the account data file..only had the adminregistration table and serverlisttype >.< by hand it is. |
Sounds like you have really been thrown some bad luck here.
Hope you figure it out, I'll watch this thread for a few days in case you have more issues that I might be able to assist with. |
Thanks Wolf, I think I actually managed to figure out most of it. I had to rebuild the login table by hand, which ended up making the tblLoginAccounts ID field out of sync with Accounts.lsaccount_id, so a simple query to rewrite that id to match the login table data made the rest sync up. Successfully logged in with multiple accounts now, characters, tested fights...I did briefly encounter a "invulnerable to melee" issue, but haven't since a reboot.
I do believe that unless unforeseen issues come up, the server is ready for play again, and luckily, all character and valuable player data is intact. :) |
Thats good to hear. Also you made sure, double checked & triple checked, to run all the SQL that match up with the version of source you are updating to?
|
Yep, did that successfully. I'm still being very alert to other possible bugs popping up as a result of this transfer, but I'd rather have the headaches than lose all the progress the server has on its 50 or so characters, most of whom are max level (but horribly under-geared). :)
|
Just because I know a couple people are watching and have helped me a lot already, I just wanted to report everything looks smooth so far, and thank you for the assistance! :)
|
Ok I'm back. System works great on LAN...will not work for clients outside the router. They can get logged in and get to the server select screen..but they can't get character select. Black screen and dump to login screen. I know I have the port forwards needed (I did 7000-7100, 9000, and 5990-5999, to catch any ranges the server might want). I've gone so far as to temporarily DMZ the server machine itself. The OS firewall is completely disabled (and wouldn't matter since local works fine), and antivirus is not interfering either.
The only two things I can think of at this point would be either a config file being wrong somewhere, or Verizon FIOS blocking the world server's incoming ports, but not the login server's. When I watch the command windows on the server, internally I see the login server catch and resolve the login, then disconnect as it hands the client off to the world server, which I see clearly pick it up and proceed happily. When the client is remote instead of local, I see the login server pick up, resolve, and hand off...but the world server never receives the handoff. To clarify, I'm using the SoD client, and it works internally perfectly...just does not work externally...and the server at this point is DMZ'd. I shall include my eqemu_config.xml and login.ini files for scrutiny. eqemu_config.xml: Code:
<?xml version="1.0"?> Code:
[database] |
Ok guys, figured it out I believe.
I have one of Verizon's newest ActionTec routers. I DO have the ports forwarded correctly, but for some lame reason, on the new models, the firewall inbound policy overrides the port forwards, whereas on previous models, the forwards overrode the global policy. I had to kill that policy and suddenly it works. Take note for anyone else with a similar issue. :) |
I'm currently the one working with Khalathas, trying to connect to his server from my home PC via internet, OUTSIDE his LAN. I log in just fine, server select works fine, but when I get to Character Select, nothing works. I can see (and select between) my characters that were already there from when the server was active before. None of the buttons are responsive at all: Create New Character, Delete Character, Enter World, Quit... None of them trigger anything when clicked. Also, the character models seem glitchy and unstable.
I'm running Windows 10 (not activated), AMD FX 9370 8-core CPU, 32 GB DDR3 RAM, Dual MSI GTX660 Ti's in SLI I have EQ operating from a single core on my CPU and I have Windows Firewall turned off. I'm using the EXACT SAME client file as Khalathas is using to connect locally. |
Do you have a way of testing on a non-win10 machine?
|
All times are GMT -4. The time now is 03:39 AM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.