ShowEQ 6 Beta Test

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

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