ShowEQ 6.4.0 Release Candidate 2 is Available

[cn187]

I've uploaded 6.4.0-rc2 to SourceForge. It fixes an issue for Qt4 users. If you're using Qt5, you shouldn't need to update (but you can if you want to).

cn187 (07/19/24)
- Update to version 6.4.0-rc2
- Fixes:
    - Fix RegEx related issue causing high CPU utilization and UI
      unresponsiveness with Qt4.  Thanks to haikus for reporting the issue.

The tarball can be downloaded from https://sourceforge.net/projects/seq...wEQ-6.4.0-rc2/

tarball installation -

   $ tar xjvf showeq-6.4.0-rc2.tar.bz2
   $ cd showeq-6.4.0-rc2
   $ ./configure
   $ make
   $ make install

[Loki]

I don't recall this issue in 6.3 but NRO is way off on default zoom level. The whole zone is like 1/8 of the viewable area. Sort by Dist doesn't seem to be working.

[cn187]

It looks like the NRO thing is happening with 6.3 as well.

Upon further investigation, it looks like they swapped the order of the x/y coords in charProfileStruct some point.

I think nobody noticed because the client receives additional position updates, and the player position winds up being
correct by the time you finish zoning. So the only real issue would be in zones where there's a big difference between
the ranges of the x/y axes and the player spawns at one of the extremes. Like NRo.

I'm fairly certain this is the issue, and did some quick testing in a few zones, but I'm not going to have a ton of time to
play test this week, so I don't want to commit it quite yet. I've attached the patch if you want to test it (apply with -p1).
I don't think it should break anything else, but it would be good to have someone else banging on it to make sure.


Regarding the sorting - I don't recall if you're on Qt4 or Qt5. Sort is working fine for me with Qt5.15.8. I know there are still
some sort-related issues with Qt4, but I haven't had a chance it dig into them.

So if you're on Qt4, I'll try to get to the Qt4 issues soon.

If you're on Qt5, it should be working, so I'd be really interested in trying to figure out why it's not.

[Loki]

I will give that a shot tomorrow! Thank you.

As for Dist sorting, I am using QT 5.X (not sure the decimal point) I just tried it again, it doesn't seem to sort the Dist at all but it does with others like Name, Lvl, Class, etc. Just not the Dist. It is not displayed by default as I would tick it via Show Column right click. Not sure what I'm doing wrong.

EDIT: >> Found version.: 5.15.2

[cn187]

The weird thing is that I don't think we're handling any of the columns differently from the others, so I'd expect it to work for all or work for none.

Can you send me a copy of your showeq.xml?

[fransick]

I built a Fedora40 machine over the weekend to start playing around with QT5 and 6. QT5.15.14 is exhibiting the sort behavior Loki is reporting. Clicking the column header will change the sort arrow but does not change the sort. That said, I am getting some Wayland warnings in the console when clicking around the ShowEQ menus so I may have messed up my install a bit as I though I had it all pointing to X11 but apparently not.

qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

I also continue to see a lot of these messages in console when sitting in the guild hall:

Debug: Mon 7/29/2024 15:52:33 - ZoneMgr::zoneNameFromID: zone name not found: zoneId=33505
Debug: Mon 7/29/2024 15:53:02 - ZoneMgr::zoneNameFromID: zone name not found: zoneId=33505
Debug: Mon 7/29/2024 16:02:38 - ZoneMgr::zoneNameFromID: zone name not found: zoneId=33505
Debug: Mon 7/29/2024 16:02:39 - ZoneMgr::zoneNameFromID: zone name not found: zoneId=33505
Debug: Mon 7/29/2024 16:02:40 - ZoneMgr::zoneNameFromID: zone name not found: zoneId=33505
Debug: Mon 7/29/2024 16:02:42 - ZoneMgr::zoneNameFromID: zone name not found: zoneId=33505
Debug: Mon 7/29/2024 16:02:43 - ZoneMgr::zoneNameFromID: zone name not found: zoneId=33505
Debug: Mon 7/29/2024 16:02:44 - ZoneMgr::zoneNameFromID: zone name not found: zoneId=33505

Any idea what's causing this? I've poked around this one several times and cannot figure it out looking at the logs and packets.

Just patched RC2 and will report any notable outcomes. So far, seems solid despite a million warnings when compiling under QT5

[cn187]

That's odd. Sorting is working fine for me. Click the column, the indicator changes, and so does the actual order of the things in the window. Bizarre. I'll try to figure out what's going on, but without being able to reproduce it, it'll probably be tough.


Yeah, I'm not sure how much Qt5 actually supports wayland. If you really want a ride, my devel branch should compile against Qt6. Haven't tried it with Qt6 in a while, though, so I'm not sure how well it works currently.


I looked back through my notes about the zone name thing and did a little testing. Back then, I was thinking it was maybe a struct change, but it looks like they really are sending oddball zoneID values for player housing and guild halls. They're still sending the normal zoneID in the lower 12 bits of the field, but they have other bits set in the upper 4 bits. Not sure if that's to flag it as a player housing/guild zone, or some other reason.

Anyway, here's a patch to test (apply with -p1). I'm masking off the high bits for the check. If it causes problems, then we may need to adjust the mask, as 12 bits is an educated guess.

[fransick]

Anyway, here's a patch to test (apply with -p1). I'm masking off the high bits for the check. If it causes problems, then we may need to adjust the mask, as 12 bits is an educated guess.

RC2 with the earlier patch for X and Y was rock solid for a full night of raiding. I'll give QT6 a try on the devel branch too. It's fun testing all this new stuff out! Thanks Cn.

[cn187]

Thanks Loki for sending me your prefs file. With it, I was able reproduce the sort issue, and then it was pretty straightforward to track down.

The attached patch fixes it for me if you'd like to try it. (apply with -p1)

[Loki]

Thanks! It is working. RC2 with y/x have been working great also during last night raids, with two instances running (one via console and other via remote desktop on same Debian box) and two EQ machines.

[Loki]

Still working great. I like the new add filter option. No longer have to use keyboard - just click click click and done! Nice job.

[cn187]

Awesome. If no major bugs crop up between now and then, I expect I'll release 6.4 for this month's patch update.