Go Back   EQEmulator Home > EQEmulator Forums > Support > Support::Windows Servers

Support::Windows Servers Support forum for Windows EQEMu users.

Reply
 
Thread Tools Display Modes
  #1  
Old 11-18-2017, 03:45 PM
kuahara
Sarnak
 
Join Date: Aug 2010
Location: Wichita Falls, Tx
Posts: 36
Default

Does it matter where in the eqeqmu_config.xml file that <localaddress> tag goes?

Also, do you know of any reason my spells or dbstr files might not be correct? I referred to your response in another thread where you told someone to run

export_client_files .\exports

to acquire those files. I've done this and it spits out the 4 files I'm expecting. When I drop these in my eq folder, the behavior I observed was what I might expect if the spells file was wrong. When I right click a gem in game, the spell categories all read "unknown DB string xxx" and so did all the subcategories. If I follow the menu path down to the spell itself, the spell names were fine. Just the categories leading to them all say that. Issuing a /who command in game returns good information for all but the player races. Races still come up "unknown DB string xxx".

Yesterday, that was all fine and good. It didn't stop me from playing the game, but today I'm just experiencing one crash after another. I can get my GM character into the world, but after a minute or so, it crashes. When I pick items up from my inventory or from the equipment slots on the character, they never appear on the cursor. The game partially behaves as if the item is there, but never does what it is supposed to do when I try to re-equip it, drop it into an inventory slot, etc... and then I crash a second later. If I try to use #zone, I crash. Yesterday, I did not have these problems.

Am having all the trouble in the world resolving this today. Any advice is appreciated.

Thanks.




Edit: restarting the server partially resolved this. I'm not crashing anymore and I can pick up items. Still can't figure out the unknown DB string non-sense, though.

Edit2: The crash and cursor issues seem to be specific only to MQ2 + GM Characters. If I start MQ2 and log in using a GM, I can't pick up items anymore. The items disappear. /gate #zone, etc... will crash the GM. Also using F1 to target self with the GM character logged in will crash the GM toon if MQ2 is running. I can log a regular toon in while MQ2 is running and pick up items, /gate, /zone, etc... just fine.

Edit3: Ok... so what I've determined with the GM account is this: If MQ had been running at any time on the client PC, even if I turn it back off before I log in a GM account, all of the problems with picking up items, targeting self, and crashing recur. Even with MQ turned off, if I log in a GM account and hit F1 to target self, I can cause an immediate crash. This issue does not go away until I restart the server (t_stop_server, not actually rebooting the VM my server runs in). Once I restart the server, if I leave MQ turned off, I can log in a GM, target self, pick up items, etc... This is not too big of a deal. I just need to remain aware that there are certain things the GM simply can't do. I can still utilize him for all my GM needs #leveling toons, #gi , etc... MQ2 and regular players all seem to work as intended.

Out of all this, I'm still most interested in trying to resolve the unknown DB string business. Forgot to mention that when I click the Alt Advancement button, I can't see what AAs I'm purchasing either. Those all say "Unknown DB string xxx" as well.
Reply With Quote
  #2  
Old 11-19-2017, 11:05 AM
kuahara
Sarnak
 
Join Date: Aug 2010
Location: Wichita Falls, Tx
Posts: 36
Default

Update: fixed the "Unknown DB string xxx" problem. I wound up using the server files from agnarr-eq.com

I thought I'd tried the dbstr and spells_us files already (I use the underfoot client), but there were also 2 files that needed to go into the resources folder. I don't remember doing anything that would have changed these from when I actually played on the agnarr emu server, but apparently something was changed along the way. Using all their files with the exception of eqhosts.txt resolved the issue I was having.

Also, someone messaged me and said that MQ2 discussion might not be permitted. My apologies. I thought it was condoned here since most of the servers allow it with varying sets of rules to make multiboxing easier.

I also stuck <localaddress>ip</localaddress> just below <loginserver2></loginserver2>. Will give that a try and report back.

Edit: Was trying the <localaddress> thing because after a while, my response time with the server increases from 30ms to nearly 30,000ms (full 30 second delay). I usually have 21 characters logged in. This happened even with the <localaddress> bit in the eqemu_config.xml file in the place I specified above. The response time sits at about 100ms with 21 toons logged in, but after a while, will suddenly start climing from 100 to 900, then 1500, 5000, 19000, and usually stop climbing somewhere between 27000 and 29000. I am not sure if I am triggering this problem or not. The last time it happened, I had just issued an MQ2 command on the GM character. This could have triggered it or it could have been nothing but a coincidence. Won't know without experimenting further. Just updating here in case someone already has an answer.

Edit2: I issued a /bcaa //gate command to make 20 toons all try to gate at once. Usually this is broken in such a way that it just causes the toon to rezone to the current zone in the current location. The idea was to make them all rezone and see if that fixes the problem with the long response time to/from the server. For some reason, on the bards (bound in gfay by default), /gate actually works and sends them to gfay. All toons that were bound in PoK by the soulbinder were kicked to the server select screen when I did the mass gate. The bards wound up in gfay with 30ms response times from the server.

This is also taking up quite a bit of memory. I am not sure that that would contribute to long response times, but when I had 21 logged in, I noticed my machine was using 26.5GB of memory. I have 32GB in this machine. The server runs in a VM on the same machine. Most of the eqgame.exe instances are using about 732MB of memory. EQ instances only account for 15GB of the memory being used. The rest is other garbage running on the machine (firefox, excel, vmware, etc...) The CPU (an i5 @ 3.4GHz) is not being beaten to death or anything. With a toon zoning here and there, I was seeing 15-24% usage.
Reply With Quote
  #3  
Old 11-19-2017, 12:17 PM
Akkadius's Avatar
Akkadius
Administrator
 
Join Date: Feb 2009
Location: MN
Posts: 2,072
Default

Unknown DB string is going to show up depending on the types of data you're dealing with on older clients.

if you want to minimize string related issues on the client side I would suggest using ROF2

You can grab a clean version of ROF2 and use its spells_us and dbstr files to import to the server before you try exporting. The database tables are not guaranteed to be up to date.

And yes - this is not really the place for MQ2 support - there is mqemulator.net for that.

Memory footprint from the emulator is not going to be that large
Reply With Quote
  #4  
Old 11-19-2017, 12:35 PM
kuahara
Sarnak
 
Join Date: Aug 2010
Location: Wichita Falls, Tx
Posts: 36
Default

ok, but what about the <localaddress> bit from the last question? Is that in the right place? Would that have anything to do with the long delay? 30s delay makes this unplayable.


Thanks.
Reply With Quote
  #5  
Old 11-19-2017, 12:41 PM
Akkadius's Avatar
Akkadius
Administrator
 
Join Date: Feb 2009
Location: MN
Posts: 2,072
Default

Quote:
Originally Posted by kuahara View Post
ok, but what about the <localaddress> bit from the last question? Is that in the right place? Would that have anything to do with the long delay? 30s delay makes this unplayable.


Thanks.
localaddress just needs to be under the <world> section

As far as your delay - you're going to have to narrow down that issue, it could be anything. We have servers in production with folks with 50+ box crews who zone in seconds. I'd suggest looking at your PC's resources when the slowdown occurs.
Reply With Quote
  #6  
Old 11-19-2017, 07:34 PM
kuahara
Sarnak
 
Join Date: Aug 2010
Location: Wichita Falls, Tx
Posts: 36
Default

I'm getting closer to an answer on this 30,000ms delay thing. I don't think it has anything to do with MQ, but more testing is required.

Right now, I've had 18 characters logged in and all of their delays are 30-50ms. They have all been logged in for over 2 hours, which is way longer than it was taking for this 30 second response time bug to kick in yesterday. Individually, they can all change zones in 3-5 seconds (assuming the zone was already up). I zoned 18 characters all at the same time and it took 27 seconds for it to complete.

Shortly after the mass /gate, all the toons had response times from anywhere between 400ms and 1200ms. This seems to be correcting itself slowly over time while I have them sitting in place not doing anything. Many of the 500ms response times lowered down to 300ms after a minute or two. My main cleric's 1200ms response time was down to 850 and lowering. I think this will work itself out as I wait.

My current theory is that the huge lags don't really kick in until I bring the bards online and make them start twisting their songs. I have 3 total bards and when they are simultaneously twisting, it generates quite a lot of chatter in the chat windows of 20+ toons all at once. I am wondering if more is going on in the background with bard songs that might be contributing to this giant delay. Going to wait for the response times on all my toons to get back down to 100 or less, then bring them online and make them /twist. I will monitor response times both before and after issuing /twist 1 2 3 (makes them twist spells in the first 3 gem slots).

Sorry for bringing up anything MQ related in the post. I'm not seeking MQ support here at all. If I determine that to be a contributor to the problem, I will take this discussion elsewhere. I am including the information for the sake of drawing a more complete picture.


Edit: I brought the bards online. They all three had 30ms response times while in gfay. I #summoned them to PoK with the rest of the toons and they had 40-50ms response times. I left them idle there for several minutes. My response times on all toons are still gradually lowering during the several minutes. Response times on all toons were between 125ms and 135ms. They didn't seem to be lowering further than that, though perhaps it might have happened if I waited longer. I decided to make all three bards twist the songs in their first 3 gem slots. Most of the chatter is in the GM's chat box. It displays the full name of every song as soon as it is successfully cast. The other toons just have a bunch of "The elemental chorus fades" entries in their chat. If this is what triggers the problem I'm investigating, I imagine it could take 15-20 minutes or so for it to kick in. Will edit the post again if it recurs.

In the meantime, this is what my performance currently looks like. Left is the host machine where the eq clients are running. Right side is the guest machine, where the server lives.

Reply With Quote
  #7  
Old 11-19-2017, 09:18 PM
kuahara
Sarnak
 
Join Date: Aug 2010
Location: Wichita Falls, Tx
Posts: 36
Default

Well... I'm back to where I started. I have no idea what was causing that problem. The bards have been afk twisting, took the wife out for about an hour, came back, and everyone's response time is at 90-135ms.

Was hoping to have something useful to reply back with. Sorry for all the fruitless chatter.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

   

All times are GMT -4. The time now is 11:55 PM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3