ShowEQ 6 Beta Test

[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

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