Page 6 of 6 FirstFirst ... 456
Results 76 to 86 of 86

Thread: ShowEQ 6 Beta Test

  1. #76
    Administrator
    Join Date
    Sep 2005
    Posts
    299

    Re: ShowEQ 6 Beta Test

    Quote Originally Posted by cn187 View Post
    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.

  2. #77
    Developer
    Join Date
    Nov 2007
    Posts
    539

    Re: ShowEQ 6 Beta Test

    Time to fire things up and check out ShowEQ 6.

    Thanks for keepin this stuff goin.

  3. #78
    Administrator
    Join Date
    Oct 2019
    Posts
    111

    Re: ShowEQ 6 Beta Test

    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.

  4. #79
    Registered User
    Join Date
    Apr 2019
    Posts
    49

    Re: ShowEQ 6 Beta Test

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

  5. #80
    Administrator
    Join Date
    Oct 2019
    Posts
    111

    Re: ShowEQ 6 Beta Test

    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.
    Attached Files Attached Files

  6. #81
    Registered User
    Join Date
    Dec 2001
    Posts
    32

    Re: ShowEQ 6 Beta Test

    Quote Originally Posted by cn187 View Post
    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

  7. #82
    Administrator
    Join Date
    Oct 2019
    Posts
    111

    Re: ShowEQ 6 Beta Test

    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

    Code:
    export QT_GRAPHICSSYSTEM=raster
    showeq
    or
    Code:
    QT_GRAPHICSSYSTEM=raster showeq
    and see what happens.

  8. #83
    Registered User
    Join Date
    Dec 2001
    Posts
    32

    Re: ShowEQ 6 Beta Test

    Code:
    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!
    Last edited by splooge; 04-16-2020 at 03:59 AM.

  9. #84
    Administrator
    Join Date
    Oct 2019
    Posts
    111

    Re: ShowEQ 6 Beta Test

    No problem. Glad it worked for you!

  10. #85
    Registered User
    Join Date
    Jun 2020
    Posts
    2

    Re: ShowEQ 6 Beta Test

    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.


    Code:
    # 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
    Code:
    docker build -t showeq:v6beta .

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


    Code:
    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
    Code:
    -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:


    Code:
    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.

    Code:
    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.
    Last edited by an old hacker; 06-15-2020 at 06:10 AM.

  11. #86
    Registered User
    Join Date
    Sep 2020
    Posts
    2

    Re: ShowEQ 6 Beta Test

    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!

Thread Information

Users Browsing this Thread

There are currently 2 users browsing this thread. (0 members and 2 guests)

Posting Permissions

You may post new threads
You may post replies
You may post attachments
You may edit your posts
HTML code is Off
vB code is On
Smilies are On
[IMG] code is On