ShowEQ 6 Beta Test

[Loki]

Hello,

I have the beta built and running. I am running Debian 9 Stretch with KDE. I make uninstall from official ShowEQ 5 build and then installed from 6. I also did rm -rf /root/.showeq just for clean start. I have found a few issues.

1. Empty spaces for Top and Bottom Controls. I can't seem to make it smaller like normal. I can uncheck Top and Bottom and have no empty spaces at all. See this pic -> Removed

2. Options/Con Colors seems to be broken. I have dark theme with grey background on KDE so dark blue on dark grey background is hard to make out - I adjust the dark blue con to lighter blue so I can see it better. Once I did that, it doesn't take effect, it still stuck at default dark blue con.

3. showeq.xml is not being saved to /root/.showeq but to /usr/local/share/showeq. It probably doesn't make any difference but just noticed that.

So far it worked on GMM zone showing skittles. I have not played yet but once I did and if I run into more issues, I'll post ...

Thank you!

[Loki]

Been playing for 3 hours, the skittles/tracking seems to work fine. I do notice the dots are a bit bigger - not complaining about it though.

[cn187]

Thanks for the feedback so far!

1. I have a fix for this. I'll commit it soon.

2. Added to the list to work on. Changing colors of things is one thing I hadn't tested yet, so it's probably not just con colors that are affected.

3. This seems like a subtle/intermittent issue. In your first post, you say it's being saved in /usr/local/share/showeq, and the screenshot in your second post shows it using /root/.showeq/showeq.xml as expected. In a similar vein, I've been able to reproduce it once or maybe twice, but so far, not more than that. If you happen to notice any consistency in what does/doesn't make it happen, please let me know.

Possibly related: how are you getting your root shell to run showeq? Are you logging in as root? Using sudo? Using su? If one of the latter two, could you give me the command line (including args) that you're using? Or if there's different method that you're using, could you give me enough info so I could try the same thing here?

Thanks!

[Loki]

I load Konsole and type 'su -' with root pass then 'showeq' from there. I did not specify IP/eth0 on command line as I did it via menu. I will experiment with the #3. Will be playing a couple hours tonight. :)

Thanks

EDIT: My bad on my OP - I meant Debian 9 Stretch... not Squeeze.

[cn187]

I just committed version -pre4. It has fixes for #1 and #2, as well as some miscellaneous other things.

I still haven't had much luck with #3. I was hoping I could reliably reproduce it so I could just step through it with the debugger, but I'll start combing over the code to see if I can figure out what's happening.

[Loki]

Alright here's what I found. This #3 issue exist in official build also as I tested it tonight.

If I rm /root/.showeq/showeq.xml and rerun showeq and save preferences, it's back in /root/.showeq.

If I rm -rf /root/.showeq and rerun showeq and save preferences, it saved it to /usr/local/share/showeq/showeq.xml and it shows "Finished saving preferences to file: /usr/local/share/showeq/showeq.xml" in console, then I modified a setting and save preferences again, it saved it to /usr/local/share/showeq/showeq.xml again. But when I closed showeq and restart showeq, it tried to load from /root/.showeq/showeq.xml but says "Unable to open file: /root/.showeq/showeq.xml" and it loaded default settings again. Then I was able to save it to /root/.showeq/showeq.xml and it works as normal. So I guess since /root/.showeq didn't exist on first run. I'll probably just ignore this #3 "issue" since it's in official build and nobody else complained/cared about this.

[Loki]

Excellent! Will test it now. :)

Since #3 exist in official build, I wouldn't worry about it (see previous post).

Thank you!


I just committed version -pre4. It has fixes for #1 and #2, as well as some miscellaneous other things.

I still haven't had much luck with #3. I was hoping I could reliably reproduce it so I could just step through it with the debugger, but I'll start combing over the code to see if I can figure out what's happening.

[Loki]

#1 and #2 fixes are perfect. :)

I'll post back whenever I run into any other issues.

[cn187]

Alright here's what I found. This #3 issue exist in official build also as I tested it tonight.

If I rm /root/.showeq/showeq.xml and rerun showeq and save preferences, it's back in /root/.showeq.

If I rm -rf /root/.showeq and rerun showeq and save preferences, it saved it to /usr/local/share/showeq/showeq.xml and it shows "Finished saving preferences to file: /usr/local/share/showeq/showeq.xml" in console, then I modified a setting and save preferences again, it saved it to /usr/local/share/showeq/showeq.xml again. But when I closed showeq and restart showeq, it tried to load from /root/.showeq/showeq.xml but says "Unable to open file: /root/.showeq/showeq.xml" and it loaded default settings again. Then I was able to save it to /root/.showeq/showeq.xml and it works as normal. So I guess since /root/.showeq didn't exist on first run. I'll probably just ignore this #3 "issue" since it's in official build and nobody else complained/cared about this.

Nice work! That's HUGE help.





Since #3 exist in official build, I wouldn't worry about it (see previous post).


Already fixed ;)

[BlueAdept]

Thanks Loki and cn187. I appreciate your help.

[fransick]

Installed QT4 and compiled pre_6_0_beta on my antiquated Fedora 14 box with gcc-4.5.1. Is there a reason all the maps render improperly? I re-imported them from EQ and opened maps that rendered properly on current live showeq. Most everything else appears to be working well but it is hard to tell in most zones as the map is an explosion of lines that tends to cover up most everything else.

[cn187]

Is there a reason all the maps render improperly?

I did some testing, and it looks like an issue with the map import/conversion. My maps display fine, but I converted them outside of SEQ using a script I found here on the forums. I tried to open an SOE map directly without manually converting it first, and I get the weird lines you're talking about. I'll try to get a fix in for it sometime this weekend.

[fransick]

I did some testing, and it looks like an issue with the map import/conversion. My maps display fine, but I converted them outside of SEQ using a script I found here on the forums. I tried to open an SOE map directly without manually converting it first, and I get the weird lines you're talking about. I'll try to get a fix in for it sometime this weekend.
You are indeed correct, using the mapconvert script stickied on the forums worked just fine. What didn't was converting Brewell's maps. Those came throuogh without any lines and the existing .map files I have are a mess. Weird! If you need any help testing maps, let me know. In the meantime, I'll use the lame ones I converted from everquest/maps folder and test other SEQ functionality.

So far the convert to qt4 is looking great! Nice job

[cn187]

What didn't was converting Brewell's maps. Those came throuogh without any lines

Hmm. That's a little strange, since I'm using Brewell's with no issues. Though, mine are seriously old (I think HoT was the last time I played semi-regularly, and I haven't updated them), so maybe that has something to do with it.

Once I get the issue fixed, I'll go through and spot-check a few maps to make sure that SOE, Brewell, and Goodurden are converting without problems. Are there any other map packs that people use regularly that I should test?

Then maybe I'll go through the mapconvert script and fix the issue you're seeing with Brewell's. It's always good to have more than one way to do things.

[cn187]

OK, so I was wrong. It turned out to be a rendering problem after all, and the pre-converted maps only worked because the conversion script just happened to accidentally work around the bug.

Unfortunately, I can't even blame the QT upgrade tool... Due to API changes, I had to rewrite some of the line drawing logic in order for it to work with QT4, and in the process I managed to screw it up. So it's totally my fault. Sorry about that.

Anyway, as far as I can tell, it's fixed now. I've tested it with a handful of random maps from SOE, Brewall, and Good, and they look normal to me.

Though, there could still be lurking issues with the rendering changes, so if anyone *does* want to do a bunch of map testing, please go right ahead.

I've committed version -pre5 with the fix.

[Loki]

Already fixed ;)

That's great! You're quick! I haven't played in last couple days but will be tonight and tomorrow.

EDIT: I didn't even notice on the map issue, but I was only playing in GMM zone and dying to GH/GL. I got some old quests I gotta do. I box 4 or 5 characters with mercs at a time.... Maps I am using is using mapconvert script posted by Razzle and my own "merge" script.

[fransick]

Maps I use in SEQ5 are all loading without issue. Fix looks to be right on. It's been rock solid but I see significant lag and difficulty repainting the map screen that I don't experience with 5. Not sure where to start troubleshooting. It takes a few minutes to kick in then sticks until I close and restart. In other words, zoning doesn't fix it.

[cn187]

This could definitely be tricky to troubleshoot. A few questions come to mind that might help me get started:

When you say difficulty repainting, do you mean as it relates to the laggy behavior, or are there other repainting issues like ghosting or artifacts?

How does the lag act - does it seem like a slideshow - the whole screen updates at once but the updates are too far apart? or is it more like part of the screen updates, then another part of the screen updates, then another part of the screen updates, until everything is updated?

If it starts lagging after a few minutes - does the amount of time before it starts to lag seem to be fairly consistent, or is it pretty variable?

Once it starts lagging, does it seem to get worse the longer it runs, or does it get to a certain level of lag and sort of stay there?

Have you seen it start happening while you're in different zones, or have you pretty much been in the same place when it happened?

[fransick]

This could definitely be tricky to troubleshoot. A few questions come to mind that might help me get started:

When you say difficulty repainting, do you mean as it relates to the laggy behavior, or are there other repainting issues like ghosting or artifacts? No Ghosting or Artifacts. Behaves more like the FPS drops to 1 FPS

How does the lag act - does it seem like a slideshow - the whole screen updates at once but the updates are too far apart? or is it more like part of the screen updates, then another part of the screen updates, then another part of the screen updates, until everything is updated? Whole screen updates but they are far apart. When sitting in PoK, I can see all the NPCS and PCs move but at something close to 1 FPS

If it starts lagging after a few minutes - does the amount of time before it starts to lag seem to be fairly consistent, or is it pretty variable? Time it takes seems fairly consistent.

Once it starts lagging, does it seem to get worse the longer it runs, or does it get to a certain level of lag and sort of stay there? Reaches a point then stays there

Have you seen it start happening while you're in different zones, or have you pretty much been in the same place when it happened?
Happens in all zones I have visited

I was contemplating setting up another Linux box with a more current distro and better equipment to see if that changes anything. Didn't have time this weekend and traveling next few weeks so might be a bit before I can test.

[cn187]

Thanks fransick, that should get me started.

If you do get a chance to test with something more recent, that would be great. But of course, RL comes first. Who knows, maybe I'll have it figured out by the time you get back. Safe journeys!

[cn187]

So far, I still haven't been able to reproduce the map lag.

If you right click on the map window and go to "Show", at/toward the bottom is "show debug info". That will overlay an FPS counter in the corner of the map. I'd be curious to know what it says both when things are working normally and when it's lagging.

[BlueAdept]

Of all times for the beta testing to happen, it has to happen when I am closing on a new house and moving. Sorry guys, I will be out of action probably until January. I close on my house on the 18th.

[Loki]

I have not seen any map lags either - I will keep testing though. So far it's been solid.

BlueAdept - Congrats on your new house!

[fransick]

Thanks fransick, that should get me started.

If you do get a chance to test with something more recent, that would be great. But of course, RL comes first. Who knows, maybe I'll have it figured out by the time you get back. Safe journeys!
Some further testing with map debug... once the lag starts it persists through zoning and is unshakeable until a restart of SEQ. It drops the FPS to 1 and ms vary between 52 and 150. Super slow and does not happen on SEQ5. I can say that it hasn't Seg Faulted once and doesn't seem to have a problem with "
SEQ: Giving up on finding arq" which are two things I have been seeing on SEQ5 of late

[cn187]

fransick -

Today I spun up a Fedora 14 VM, compiled SEQ there with the available library versions, and spent some time in-game. But still no luck reproducing the lag issue here. No matter what I set my FPS limit to (even 1fps) my render time never goes above 5ms.

Maybe you could try dumping some profiling data so we can see if something is taking a bunch of time that isn't supposed to? You'll need to "make clean", re-run configure with "--enable-profiling" (and any other flags you usually use) and then re-compile.

Then run SEQ, and once it starts lagging, wait some more so there's plenty of data, then exit out of SEQ. That will produce a file called "gmon.out" in the current directory. Then you run "gprof showeq > profile_info" and it will convert all of the binary profiling data in gmon.out into something that's human readable and put it in profile_info. Then if you can post that profile_info file here, I can compare it to what I have and see if anything stands out.

Thanks.

[Loki]

Does it happen in any zone? Are you playing EQ Live? TLP?

[Loki]

Got a Color Con .."bug".. (I'm not sure if it's a bug or it's intended - probably the latter - and it is also in Official build). The "Even Spawn" is default to 255/255/255 to show black fonts on white background. Since I have dark theme on KDE, it still shows it black color but I just drop one of the color down to 254 and it shows white. Also DROP: or DOOR: etc will show black color and there isn't any option AFAIK to change that.

Performance still seems fine.

[fransick]

Does it happen in any zone? Are you playing EQ Live? TLP?
Seems to be any zone playing on live. Just for kicks I spun up a fresh install on a more current distro and it looks like I am having issues with pcap. It will zone and show skittles but then only capture packets randomly after that. The packet counter increments every once and while so something is up. And here I thought doing a fresh install would just be easier than messing with an old install!

[cn187]

it looks like I am having issues with pcap. It will zone and show skittles but then only capture packets randomly after that. The packet counter increments every once and while so something is up.

A couple of things to try:

1) when you're running SEQ and experiencing the map lag and packet loss, can you run "top" (or similar) and grab a screenshot?

2) Does going to the Network menu and selecting "Real Time Thread" help/change the issues you're seeing?

[cn187]

Got a Color Con .."bug".. (I'm not sure if it's a bug or it's intended - probably the latter - and it is also in Official build). The "Even Spawn" is default to 255/255/255 to show black fonts on white background. Since I have dark theme on KDE, it still shows it black color but I just drop one of the color down to 254 and it shows white. Also DROP: or DOOR: etc will show black color and there isn't any option AFAIK to change that.

Performance still seems fine.

Thanks. Since it's in the official build as well, I'm not going to consider it a show-stopper, but I'll add it to my list of stuff to work on. I've also noticed a lot of little things about the UI that could use fixing/improvement, so feel free to share whatever you find even if the issue is present in the official build.

[fransick]

A couple of things to try:

1) when you're running SEQ and experiencing the map lag and packet loss, can you run "top" (or similar) and grab a screenshot?

2) Does going to the Network menu and selecting "Real Time Thread" help/change the issues you're seeing?
A fresh Centos7 install and all is well. Had to redo preferences off of default xml. Did notice that adding a mac address seems to cause issues getting skittles. Once I left that blank it worked fine. Now to get down to some testing! Thanks for the suggestions. Wasn't worth chasing the odd performance issues on an old box.

[Loki]

Had a segmentation fault when zoning into Stratos last night and couldn't repeat it. If I enable debug (I should have in first place), will it show the errors in console? What steps should I take to give you the errors you need?

[Loki]

Thanks. Since it's in the official build as well, I'm not going to consider it a show-stopper, but I'll add it to my list of stuff to work on. I've also noticed a lot of little things about the UI that could use fixing/improvement, so feel free to share whatever you find even if the issue is present in the official build.

I agree. It's just little things.

[cn187]

Had a segmentation fault when zoning into Stratos last night and couldn't repeat it. If I enable debug (I should have in first place), will it show the errors in console? What steps should I take to give you the errors you need?

Best would be to compile with debug, but also --disable-optimization and --disable-inlines. Then, right before you run SEQ, run "ulimit -c unlimited" to enable core dumps for that session. A segfault should drop a core file in the same directory (at least on debian). It will be large, but will contain a snapshot of memory and program state from when the crash occurred.

The ideal thing would be for me to get a copy of that core (it'll be too big to post here, but I could arrange someplace to upload it). Second best would be a copy of a full backtrace generated from that core file (from the same directory, run gdb ./showeq core, then at the gdb prompt, do "bt full"). That could be copy/pasted here without too much issue.

[cn187]

A fresh Centos7 install and all is well. Had to redo preferences off of default xml. Did notice that adding a mac address seems to cause issues getting skittles. Once I left that blank it worked fine. Now to get down to some testing! Thanks for the suggestions. Wasn't worth chasing the odd performance issues on an old box.

Cool, glad to hear it's working better. I'll look into the MAC issue.

[cn187]

Had a segmentation fault when zoning into Stratos last night and couldn't repeat it. If I enable debug (I should have in first place), will it show the errors in console? What steps should I take to give you the errors you need?

FYI, I also had a crash while zoning (a couple actually) and was able to get a core file. A quick look shows a null pointer dereference in spawn-related code. I won't have time to investigate further and come up with a fix until after the holiday weekend, but I'll try to get it sorted out as soon as I can.

This may or may not be what's causing *your* crash, but I'd say there's a fair chance it is. If you do happen to get another crash and can get me a backtrace and/or core file then we can use that to confirm whether or not it's the same issue. Otherwise, you can wait and see how it does after I get this fix in.

[Loki]

It actually just crashed a few minutes ago after a while. PM'ing you.

[fransick]

FYI, I also had a crash while zoning (a couple actually) and was able to get a core file. A quick look shows a null pointer dereference in spawn-related code. I won't have time to investigate further and come up with a fix until after the holiday weekend, but I'll try to get it sorted out as soon as I can.

This may or may not be what's causing *your* crash, but I'd say there's a fair chance it is. If you do happen to get another crash and can get me a backtrace and/or core file then we can use that to confirm whether or not it's the same issue. Otherwise, you can wait and see how it does after I get this fix in.

I've been trying to capture a backtrace too. I haven't had a crash in 2 weeks! If I leave it running while sitting in the Guild Lobby for a few days, it is rock solid which my old setup was not nearly as stable. I'll post if I can get it finally crash :o

[Loki]

Yeah it's rare here too. Had two crashes so far since.

[cn187]

The null pointer exception was easy to enough fix, but while testing it I started getting a lot of crashes in one particular zone (but nowhere else). This led me to a different issue in the same area of code. I have a hacky work-around for that problem, but I'm looking for a better long-term fix. It may require some significant changes to do "right".

[Loki]

Ever since I started hunting Kael (new "ToV" expansion - my brain is still registering ToV as Temple as Veeshan), it has been crashing in this zone a lot lately - had 4. Going to install official build temp to see if ti's crashing there as well...

[fransick]

Anyone else seeing that right clicking a mob and trying to add to alert filter doesn't add anything? I can manually type it into the filter list by hand but trying to add from spawn list doesn't do anything

[Loki]

Official build is crashing in Kael but didn't dump a core. Recompiling with --enable-debug etc switches.

[cn187]

Anyone else seeing that right clicking a mob and trying to add to alert filter doesn't add anything? I can manually type it into the filter list by hand but trying to add from spawn list doesn't do anything

Yes, I noticed this, too. But I could swear it did the same thing under the QT3 version. (though I don't have a copy handy to verify that right now, so I could be wrong).

[fransick]

Yes, I noticed this, too. But I could swear it did the same thing under the QT3 version. (though I don't have a copy handy to verify that right now, so I could be wrong).
I used it all the time with QT3 compile without issue.

[cn187]

Fair enough. I must be confusing it with something else.

[fransick]

Fair enough. I must be confusing it with something else.
Sorry, I didn't mean for my reply to come off as short. Sometimes I am too economical with words, haha. I'll fire up my old qt3 box and do some testing to confirm it worked just so we can be sure. Cannot imagine why it would work in 3 and not 4 so you may very well be right that it broke more recently and went unnoticed. Will report back when I get motivated to hook up qt3 again.

Thanks for all you've done to date! Super cool and rock solid for the most part.

[Loki]

fransick, I will test it for you. I have both qt3 and qt4 on same box. What exactly do you do for the filters? I rarely use them myself too. I mainly use the Find: bar on top.

[cn187]

Sorry, I didn't mean for my reply to come off as short. Sometimes I am too economical with words, haha.

No worries, I didn't take it that way at all. Maybe I'm the one being too economical with words ;)

[fransick]

fransick, I will test it for you. I have both qt3 and qt4 on same box. What exactly do you do for the filters? I rarely use them myself too. I mainly use the Find: bar on top.
you should be able to right click on a name in the spawn list and add it any number of filters. I usually add named to the Zone Filter. Then you should be able to go to filters and choose Edit Zone Filters and see the named you added. Right now I add a spawn and the filters file stays blank.

[Loki]

It seems to work fine on official. Is there a way I could add it so it'll do blinking white circle around like it would if I use Find: bar on top? Since I recompiled with --enable-debug on offical I stopped hunting in Kael and moved on to other zones to finish the merc quests. Haven't crashed yet. As soon it did I'll notify.


root@loki:~/.showeq/filters# cat eastwastestwo.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE seqfilters SYSTEM "seqfilters.dtd">
<seqfilters>
<section name="Alert">
<oldfilter><regex>Name:#Sofia the Quiet</regex></oldfilter>
</section>
</seqfilters>
root@loki:~/.showeq/filters#

[cn187]

It seems to work fine on official. Is there a way I could add it so it'll do blinking white circle around like it would if I use Find: bar on top?

Yes, put it in the "hunt" section.

[cn187]

I think I found the spawn filter issue. I've committed 6.0.0.0-pre9 with the fix. Please test and let me know if you still see any problems.

On a related note, there were A LOT of menu-related changes between QT3 and QT4. I've tested and fixed a lot of the issues, but there are lots of menus, lots of menu items, and lots of windows with their own menus and menu items. So I'm sure I haven't tested everything.

If anyone wants to go through and test various menu and window items to help me sort the rest of that out, please feel free to do so.

[fransick]

I think I found the spawn filter issue. I've committed 6.0.0.0-pre9 with the fix. Please test and let me know if you still see any problems.

On a related note, there were A LOT of menu-related changes between QT3 and QT4. I've tested and fixed a lot of the issues, but there are lots of menus, lots of menu items, and lots of windows with their own menus and menu items. So I'm sure I haven't tested everything.

If anyone wants to go through and test various menu and window items to help me sort the rest of that out, please feel free to do so.

Thanks cn! I'll take a look at what I can. Since Newby wrote a script to help with critical opcodes, my contributions here have waned. There a few small things I've been meaning to fix that I need to get after and do. I'll test what I can on the menus too.

Anyone else feeling like the Find: input box has become more case sensitive of late? I cannot tell if DayBreak suddenly found the shift key/changed the spawn capitalization conventions they've used for years or if some functionality in SEQ changed though, haha

[cn187]

I don't really use the find input (except when I'm in the wrong window and wind up searching for wwwwwwwwwwww instead of moving) so I hadn't noticed, but I'm 99% sure that's a QT-related issue. There were a lot of case sensitivity related changes to the API. I thought I got all of it sorted out, but I guess not. Thanks for mentioning it, I'll take a look at it.

[BlueAdept]

Hey Fransick, I havent seen that script, or at least I am not familiar with it. Can you put it in the dev forum?

[BlueAdept]

Things are finally getting back to normal. I got some of the essentials unpacked and got some furniture assembled. In about a week or so, I should have some time to play around with the new version.

[cn187]

Having dug through the forums *a lot* in order to try to get up to speed, I assume he means this one - http://www.showeq.net/forums/showthread.php?7003-patch-day-tasks&p=48772&viewfull=1#post48772

It was a big help to me when I first started trying to figure out opcodes. I'm mostly doing something different now, but still use the script as a fall-back.

[cn187]

Fransick,

Regarding the Find issue - I've managed to reproduce a case-related issue, but I'm not sure of the cause yet (contrary to my previous thought, it may or may not be QT related), or if it's the same issue you're seeing.

Out of curiosity, do you do an empty search (to clear the highlights) in between searches? Or do you go from one thing directly to another?

[BlueAdept]

Lol I dont remember that at all, but I see I replied to it! I have it bookmarked now. Thanks.

[fransick]

Fransick,

Regarding the Find issue - I've managed to reproduce a case-related issue, but I'm not sure of the cause yet (contrary to my previous thought, it may or may not be QT related), or if it's the same issue you're seeing.

Out of curiosity, do you do an empty search (to clear the highlights) in between searches? Or do you go from one thing directly to another?

Both. I'll keep any eye out to see if one way or the other causes the issue. I kind of didn't pay attention at first just thinking DB changed the naming convention of non named mobs but after visiting some old zones it seemed like something changed.

[fransick]

Hey Fransick, I havent seen that script, or at least I am not familiar with it. Can you put it in the dev forum?
It's not something I've seen. I think it's something Newby did to help automate whatever manual process he was going through to find critical opcodes. I could be wrong but I thought he mentioned something. If I am wrong on that, apologies. When I do them it's the old fashioned manual approach, haha. Whatever he is doing it is way faster than what I am doing haha.

[splooge]

I'm running both SEQ5 and SEQ6 side-by-side (not at the same time, obviously) on a Raspberry Pi 4-4G and while SEQ5 is super snappy compared to what it was on the Pi 3B+, SEQ6 is very slow, to the point it's almost unusable. Not sure what information I can offer to help analyze the issue but if you have any ideas I'm happy to try. I've tried exporting the display to different PC's but that doesn't make any difference.

[Loki]

Ok, it's definitely crashing.. but its not leaving a dump file for some reason, I recompiled with the switches and it's still not dumping the core file... this is with official build. I'm not sure what's going on :(

[cn187]

Both. I'll keep any eye out to see if one way or the other causes the issue. I kind of didn't pay attention at first just thinking DB changed the naming convention of non named mobs but after visiting some old zones it seemed like something changed.

There is for sure an issue if you search "mob x", then clear the line and hit enter, and then search for "mob x" again - it ignores it completely. I've already got a fix for this, but I haven't committed it yet.

So far, I haven't been able to reproduce any other case-sensitivity issues in Find, so any kind of test cases that exhibit the problem would be helpful.

[cn187]

I'm running both SEQ5 and SEQ6 side-by-side (not at the same time, obviously) on a Raspberry Pi 4-4G and while SEQ5 is super snappy compared to what it was on the Pi 3B+, SEQ6 is very slow, to the point it's almost unusable. Not sure what information I can offer to help analyze the issue but if you have any ideas I'm happy to try. I've tried exporting the display to different PC's but that doesn't make any difference.

Upthread, fransick had reported some performance issues (map lag) but they were resolved by a clean install. I'm not sure if that's an option for you, but if so, you might give that a shot. I suspect there could be some sort of conflict between qt3 and qt4, or some other "cruft" that's causing an issue.

Are you running Raspbian, or some other distro? What version? Was QT installed via the package manager, or a different way? What version?

Upthread I gave instructions on getting profiling data. That may or may not help, but since I still haven't been reproduce any kind of performance issues, it might at least give an idea of the problem. I'll think about it some more and see if I can come up with any more ideas, but that's all I've got for now.

[splooge]

Upthread, fransick had reported some performance issues (map lag) but they were resolved by a clean install. I'm not sure if that's an option for you, but if so, you might give that a shot. I suspect there could be some sort of conflict between qt3 and qt4, or some other "cruft" that's causing an issue.

Are you running Raspbian, or some other distro? What version? Was QT installed via the package manager, or a different way? What version?

Upthread I gave instructions on getting profiling data. That may or may not help, but since I still haven't been reproduce any kind of performance issues, it might at least give an idea of the problem. I'll think about it some more and see if I can come up with any more ideas, but that's all I've got for now.

CentOS 7. http://ftp.osuosl.org/pub/centos-altarch/7.7.1908/isos/armhfp/ I started with the minimal install (minimal-4-1908) and did a groupinstall of KDE Plasma since the KDE image wouldn't install for me (I couldn't get it to boot, could be a bad SD card I copied the image onto, need another SD card to troubleshoot with)

Everything was installed via yum:

[root@rpi4 ~]# yum info qt-devel
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* base: ftp.osuosl.org
* centos-kernel: mirror.keystealth.org
* extras: mirror.keystealth.org
* updates: ftp.osuosl.org
Installed Packages
Name : qt-devel
Arch : armv7hl
Epoch : 1
Version : 4.8.7
Release : 3.el7_6
Size : 32 M
Repo : installed
From repo : base
Summary : Development files for the Qt toolkit
URL : http://qt-project.org/
License : (LGPLv2 with exceptions or GPLv3 with exceptions) and ASL 2.0 and BSD and FTL and MIT
Description : This package contains the files necessary to develop
: applications using the Qt toolkit. Includes:
: Qt Linguist

[root@rpi4 ~]# yum info qt3-devel
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* base: ftp.osuosl.org
* centos-kernel: mirror.keystealth.org
* extras: mirror.lax.genesisadaptive.com
* updates: ftp.osuosl.org
Installed Packages
Name : qt3-devel
Arch : armv7hl
Version : 3.3.8b
Release : 51.el7
Size : 35 M
Repo : installed
From repo : base
Summary : Development files for the Qt 3 GUI toolkit
URL : http://www.troll.no
License : QPL or GPLv2 or GPLv3
Description : The qt3-devel package contains the files necessary to develop
: applications using the Qt GUI toolkit: the header files, the Qt meta
: object compiler.
:
: Install qt3-devel if you want to develop GUI applications using the Qt 3
: toolkit.
The best way to describe the slowness is that it takes about 10 seconds for SEQ to re-draw itself, almost as if this were Windows 3.1 and you're trying to drag a window around with a mouse and a slow video card. From the top of the SEQ Window to the bottom, you can watch it draw itself out in realtime.

Come to think of it, I was getting an error running `make`:
In file included from /usr/include/c++/4.8.2/cstdint:35:0,
from everquest.h:42,
from interface.h:47,
from main.cpp:56:
/usr/include/c++/4.8.2/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
As soon as I added
-std=c++11 to CFLAGS in the Makefile it compiled without any further complaints.

I'll try a re-install of the minimal image and this time I'll leave KDE out of the picture, I'll just install the dependencies as it complains about them being missing.

Thanks for all the time you're putting into this, if you have paypal or venmo I'd like to send you a donation.

[cn187]

I'll try a re-install of the minimal image and this time I'll leave KDE out of the picture, I'll just install the dependencies as it complains about them being missing.


Thanks for the info. If you do the reinstall, then I suggest maybe trying to build/run *only* QT4/SEQ6 at first, see how it behaves, and then go back and add in QT3/SEQ5 if you still want/need to.

[cn187]

Thanks for all the time you're putting into this, if you have paypal or venmo I'd like to send you a donation.

Regarding this - thank you. I appreciate the offer. While I'm doing the work on SEQ for a number of personal reasons, financial gain isn't really one of them. Well, unless you're super rich and want to donate enough that I can quit my job and retire to a life of playing EQ and working on SEQ and other open source software. Then I might reconsider ;)

I'm also the "new guy", and while I have been doing a lot of work on the codebase recently, I think that the folks that have been keeping this project alive all along (BlueAdept, Newby, Fransick, and others) deserve donations more. Without them and their efforts, there might not have been anything left here for me to contribute to. Maybe you could kick them a few bucks instead.

[BlueAdept]

Bah, I dont do anything really. I just happen to a user that has been around longer than most. Anyone who actually contributes to the code base are the ones that deserve the credit. Without all you, this project would have been dead and buried long ago. Putting a donation link is fine and deserved.

[brainiac]

Hello, its been a really long time since I visited. 10 years or so ago I was working on a port of ShowEQ to Qt4. I figured I'd just link it here in case you were curious what I did. https://github.com/brainiac/showeq
I don't really remember what state i left it in, but i remember it having performance issues that I never finished working out. It was running on mac/windows/linux at some point though. Its probably not worth much but I figured it worth sharing.

[Loki]

I'll gladly donate as well.

[robregen]

I had issue with showeq beta finding eth0 device. I guess the naming convention had changed to enp0sXXX from eth0XXX in newer linux distro.

I follow the instruction on changing the name to eth0 using this: https://www.linuxtopic.com/2017/02/how-to-change-default-interface-name.html

After that, Showeq finally launched.

[BlueAdept]

long time no see brainiac.

Thanks for posting that.

[cn187]

I had issue with showeq beta finding eth0 device. I guess the naming convention had changed to enp0sXXX from eth0XXX in newer linux distro.

I follow the instruction on changing the name to eth0 using this: https://www.linuxtopic.com/2017/02/how-to-change-default-interface-name.html

After that, Showeq finally launched.

For what it's worth, you can specify the interface name when you run showeq using the "-i" flag:

showeq -i enp0s1

You can also set the interface in the application by going to the Network menu and selecting Set Device (though I don't think SEQ will start with an invalid interface in order to get to that point - so maybe that should be considered a bug). And it *should* save as part of the preferences so you don't have to keep specifying it, but I'm not 100% sure that works like that, either. It's something I've been meaning to investigate but I haven't gotten around to it.

[fransick]

For what it's worth, you can specify the interface name when you run showeq using the "-i" flag:

showeq -i enp0s1

You can also set the interface in the application by going to the Network menu and selecting Set Device (though I don't think SEQ will start with an invalid interface in order to get to that point - so maybe that should be considered a bug). And it *should* save as part of the preferences so you don't have to keep specifying it, but I'm not 100% sure that works like that, either. It's something I've been meaning to investigate but I haven't gotten around to it.
I can confirm SEQ will not start with an invalid interface. The workaround was to edit the showeq.xml file in .showeq folder with the proper interface. Once that was done, ShowEQ would load and you can manage the interface name from the Network menu option as cn187 theorizes.

[Razzle]

Time to fire things up and check out ShowEQ 6.

Thanks for keepin this stuff goin.

[cn187]

I think I have a fix for one of the crash bugs. Unfortunately I don't have a ton of time to play right now, so short of leaving my toon logged in and just sitting there waiting for a crash (which I've done for the past few hours), I'm not going to get much active testing done in the very near future.

So I've gone ahead and committed the potential fix to the beta 6 branch, in case anyone else wants to help test it.

Loki - this is the fix for the "dump1" crash. The "dump2" and "dump3" crashes seem to be the same issue, but I don't have a fix for them yet. I may need to get some more info from you about those -- I'll let you know.

[Loki]

Sorry for delays, Will send the two dumps very soon.

[cn187]

I think I've found the cause for the other crash. Unfortunately, I don't have time to play right now in order to test it. And for that matter, I haven't been able to reproduce this crash in-game, so I might not be the right person to test it anyway.

So here's the patch with the possible fix. Loki, or anyone else that's seeing crashes, if you could please apply it and let me know how it goes, I'd appreciate it. Once there's confirmation that it fixes the issue, I'll commit it.

Thanks.

[splooge]

Thanks for the info. If you do the reinstall, then I suggest maybe trying to build/run *only* QT4/SEQ6 at first, see how it behaves, and then go back and add in QT3/SEQ5 if you still want/need to.

I saw a post that you cured someone of some slowness by fixing something in libpcap. Hoping I would see the same results, I went ahead and did a fresh install of CentOS 7 and ShowEQ 6 on a Raspberry Pi 4-4G.

Same slowness, without even sniffing packets yet. I'm forwarding the X11 display over SSH from the RPI to a laptop. Poking around, I saw that sshd was taking 25% utilization. Interesting. So I decided to do the X11 forwarding without ssh. Still slow.

I wanted to see what was going on with the network, but I couldn't find ntop for arm, so I just went ahead and looked at my laptop's task manager, and here's what I found.

ShowEQ 5 with QT3 exporting the display to the laptop uses almost zero network bandwidth: 0.1Mbps

ShowEQ 6 with QT4 exporting the display to the laptop uses about 800x the bandwidth: 82.9 Mbps

I have zero idea what could be causing this, but I figured you'd be interested in seeing what I'm running into. Perhaps not many others are exporting their display to a remote machine which is maybe why you haven't heard any other people complain? I'm using Xming, an X server for Windows as well as XQuartz, an X server for MacOS. Both show the same issue.

And maybe this is a problem everywhere, but is hidden by the fact that most PCs can probably handle this sort of graphics locally?

Here's some screenshots of Windows task manager reporting the network utilization of the X server:

https://i.imgur.com/4Ws9wDN.png
https://i.imgur.com/U7NJHAf.png

I hope that offers you some insight as to what might be going on. I can't make any sense of this at all.

Thanks

[cn187]

Based on that info, I did some quick searches for QT/X11 rendering issues, and found several pages talking about overriding the default rendering mode by setting the QT_GRAPHICSSYSTEM environment variable before running the app. (there's also a "hidden" command line switch, but it goes away in QT5, so it's better to use the env var). Valid settings are "native", "raster", and "opengl".

It sounds like raster used to be the default in older versions, but changed to native in newer versions. I have NO idea if this will help, but it's worth a shot. Try either


export QT_GRAPHICSSYSTEM=raster
showeq

or


QT_GRAPHICSSYSTEM=raster showeq

and see what happens.

[splooge]

QT_GRAPHICSSYSTEM=native showeq

This did the trick! Network throughput to the X server seems to be hovering around 2.5Mbps now! Still a bit more than ShowEQ 5 but this is totally usable! It's very responsive now! Nice find, thanks for taking the time to look into it! :cool:

[cn187]

No problem. Glad it worked for you!

[an old hacker]

Hey all, long time user, first time poster: Back in the 2000s I, like many, used showeq and then life took over and I parted ways with the game. I've rediscovered eq and thus showeq. I've been keen to get back to it and with qt3 being hard to use, I thought to give this beta a try since it's using qt4.


I'm using this in a pretty unique way, within Docker.




# Dockerfile
FROM debian:buster


RUN \
apt update && \
apt install -yy subversion build-essential automake libtool xdm x11-apps libvte9 qt4-dev-tools subversion libtool make automake libpcap-dev libqt4-dev libgd-dev && \
mkdir -p /build && cd /build && \
svn checkout https://svn.code.sf.net/p/seq/svn/showeq/branches/pre_6_0_beta && \
cd pre_6_0_beta&& \
make -f Makefile.dist build && \
./configure && \
make && \
make install


ENTRYPOINT ["/usr/local/bin/showeq"]



This can be built with
docker build -t showeq:v6beta .


Running this is a bit of a challenge and sadly requires elevated privileges for the container.



docker run --network host -e QT_GRAPHICSSYSTEM=native -e DISPLAY=192.168.86.96:0 --privileged showeq:v6beta


(Note: I'm projecting X onto a Mac with XQuartz, hence
-e QT_GRAPHICSSYSTEM=native.)


This is definitely an MVP with a number of limitations:


* No persistent volumes for anything
* No configuration (showeq.xml)
* No maps
* No filters
* Will try to attach to eth0


Getting all these extras into the container are pretty trivial uses of Docker's -v, or curled down in with the container build. But I haven't got any of those yet, so it's fine.


Any options can be appended right to the docker run just like you're calling showeq, so:



docker run --network host -e QT_GRAPHICSSYSTEM=native -e DISPLAY=192.168.86.96:0 --privileged showeq:v6beta -i enp2s0


Maybe other folks will find this useful.



EQ box (physical) ---> SEQ box (enp2s0; 192.168.1.0/24)
|
|
\---> Internet (wlp3s0b1; 192.168.0.0/24 network, wireless)
\---> XQuartz (on 192.168.0.0/24 network)


Edit: I forgot to mention that this will not work on MacOS because the Docker daemon is itself running inside a virtual machine, and thus does not have access to actual host networking, including any bridge device set up for Internet sharing. There might be some deep hacking to enable this, but there is a much lower barrier to entry to use Mac XQuartz + headless Linux box + Everquest PC.

The purpose of using a container is to keep QT and X isolated from headless box. It's also possible that the container only needs the NET_ADMIN capability, and not privileged, to put the device into promiscuous mode.

[GuardianX]

First off, thanks a ton for turning me onto Docker, never messed with it before now!

Question though, I'm running Docker on the same machine that I am playing on and am still not seeing any feedback on the instance running in docker.

Ran through the usual things of having it monitor IP address, looked through ip link and tried various configs, nothing seems to spawn any connection.

Wondering if you had any thoughts / experience with this, thanks!

[kimmel]

I'm not sure if anyone else is running into this or if this is a functionality of SEQ5/6 but is there a way to have it always monitor client IP? At one point in time I had SEQ5 working so that I never had to restart it, it would load after I zone or logged on between sessions, accounts, whatever. Now I have to restart SEQ when I swap accounts or close EQ completely. I have SEQ6 'Monitor EQ Client IP Address' set but when I swap accounts or close EQ I have to either restart SEQ or go in the same 'Monitor EQ Client IP Address' and hit ok and zone. It still has my IP saved in there, but not actively monitoring it.

Wondering if anyone has it so SEQ is always monitoring and will just pickup new sessions?

[cn187]

It's not much of a shortcut, but rather than restarting, you can select "Monitor Next EQ Client Seen" while at character select, or right before you zone, and it should pick it up.

Out of curiosity, do you have Session Tracking enabled? If you do, then I'd be curious if turning it off would help. Though turning it off could lead to other issues, so that may not be an actual fix. It could be a useful data point, though.

[kimmel]

I did notice next EQ client seen works. I have Session tracking on, I had it one because a few versions ago I was crashing and it stopped, let me try SEQ6 with it off.

[kimmel]

Turning off session tracking is now detecting session disconnect and auto monitoring new session. So far no crashes, I'll use it a few days but this seems great that I don't have to touch SEQ each play session.

edit: doesn't always work, seems sometimes I have to relog or zone for it really pick it up.

[kimmel]

new thing that I'm not sure if its a bug with v6 or not. If I'm on for extended period or time, SEQ will just stop working. If I zone it is fine again. This only happens on one computer, somethings at hour 2 and sometimes later it will just stop updating and says session disconnected. Never noticed this happening with v5.

[cn187]

Yeah, that's the issue that session tracking is supposed to help with. If you turn session tracking back on, it should reduce that happening. But then you don't get auto-session detection. It's basically one or the other until I can figure out a decent solution.

[kimmel]

Yeah, that's the issue that session tracking is supposed to help with. If you turn session tracking back on, it should reduce that happening. But then you don't get auto-session detection. It's basically one or the other until I can figure out a decent solution.

Thanks for the info! Makes sense now.