ShowEQ 6 Beta Test

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!

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.

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!

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.

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.

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.

Excellent! Will test it now. :)

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

Thank you!

Quote:

---

Originally Posted by 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.

---

#1 and #2 fixes are perfect. :)

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

Quote:

---

Originally Posted by 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.

---

Nice work! That's HUGE help.

Quote:

---

Originally Posted by Loki

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

---

Already fixed ;)

Thanks Loki and cn187. I appreciate your help.

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.

Quote:

---

Originally Posted by fransick

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.

Quote:

---

Originally Posted by cn187

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

Quote:

---

Originally Posted by fransick

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.

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.

Quote:

---

Originally Posted by cn187

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.

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.

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?

Quote:

---

Originally Posted by 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? 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.

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!

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.

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.

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!

Quote:

---

Originally Posted by 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!

---

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

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.

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

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.

Quote:

---

Originally Posted by Loki

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!

Quote:

---

Originally Posted by fransick

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?

Quote:

---

Originally Posted by 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.

---

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.

Quote:

---

Originally Posted by cn187

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.

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?

Quote:

---

Originally Posted by cn187

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.

Quote:

---

Originally Posted by 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?

---

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.

Quote:

---

Originally Posted by fransick

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.

Quote:

---

Originally Posted by 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?

---

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.

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

Quote:

---

Originally Posted by cn187

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

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

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".