Trouble connecting client to the server across LAN or WAN

edited November 2015 in EmptyEpsilon
This game looks fantastic. I've long been frustrated with the limitations I've seen in Artemis, and this is a breath of fresh air. Lua scripting for missions, different sized ships - including little single pilot fighters! omgomgomgomg

I'm having trouble connecting clients and actually playing, though. When I start the server on one machine (Windows 7 Pro), and connect from another on my LAN i get 

"The program has encountered a serious error and needs to close."

This is running in Wine on Mac OS X, but also on another Windows machine. I've tried the last three builds. Is there a better way to try this game out?
«1

Comments

  • Crashes has been plaguing the last few releases. Problem is, I haven't been able to find the root cause yet. (Especially because it does not crash for me)

    I think the changes in the 10-10 release introduced the crashes, so you can try the build before that.

    I have no idea how well it will work on Wine.
  • I've tested it under Wine a month or so ago (from stock Repos on Debian 8). Don't think I had any issues that I can remember.

    I'm trying to get  the new crash logger builds working on my Linux VM. I'll test with Wine after I get it working.
  • When looking at the changes introduced in 10-10, I did notice a thing that potentially could crash clients on connecting.

    I've also updated my release-build script to include the crash logger on windows.
    Running a new build right now, hope that solves something with the fix I did, and else I hope to catch crash logs.
  • I was able to use the August build under Win7 and Wine, and get it to connect. Worked smashingly well.

    I'll try the latest version with Win7 and Win7, and get you a dump log.


  • edited November 2015
    Uploaded my RPT file to GitHub Gist.


    Also seeing SegFaults on Linux when trying to connect.
  • Think I fixed that crash bug.

    Happened when:
    * Client is connecting to a server
    * Server has a scenario loaded
    * Network is "slow", or lots of objects are in the game world

    So workaround is connecting before a scenario is selected.

    Also did a new build, so this crash should no longer plague everyone. If any more crashes happen, let me know. The crash report from kwadroke really helped.
  • Cool. Will test out.
    We were hoping to run EE this past Saturday and Sunday at the convention we were at, but the crash bug wouldn't allow us to connect.

    Don't believe I tried the selecting scenario after connecting, but I can test to confirm using the old build.
  • Ran a 10/18 build with no problems at a gaming event in Indy .... Artemis had probles, but EE ran smooth.. Only wish server could initialize a new scenario without completely disconnecting all clients and restarting the server mode.

  • edited November 2015
    @VolgClawtooth, I didn't go back that far with the releases, as I usually get rid of all but the last 2 or 3.

    Once this issue (https://github.com/daid/EmptyEpsilon/issues/59) is closed with a code change, you could theoretically have the clients autoconnect/reconnect using the options.ini file (or add to the end command to run the game). This is what I plan to do on my machines. Plus this way the stations can't be changed by other people (which can be a pain with people clicking on the screen with Artemis - newer versions broke this I believe)


    autoconnect=#
    Where # is one of the below numbers
      -- 6/5 Player Crew
    1 = Helms
    2 = Weapons
    3 = Engineering
    4 = Science
    5 = Relay
      -- 4/3 Player Crew
    6 = Tactical
    7= Engineering+
    8 = Operations
      -- 1 player crew/extras
    9 = Single Pilot
    10 = Damage Control
    11 = Power Management
    12 = Database

    13 = Main Screen (currently anything over 13 is considered a main screen)
  • Changing the scenario without restarting the server has some complexities. It's not impossible but does require some careful code changes to make sure certain states are properly reset, and the clients don't crash :-)
  • The commit for Issue 59 has fixed the auto-reconnect problem. If you use autoconnect, you won't have to restart the clients. You will still have to restart the server.
  • Ooh, I'll have to give it a go again then. I have a few of my crew interested in EE, I think we're going to get together this weekend and try a WAN game.

    I'll be sure to post back with results.
  • The fix hasn't been released in a new build yet. You might have to compile it yourself until daid gets a new one out.
  • Also working on changing the scenario without restarting the server. And seeing if I can work around the other connection issue Kwadroke encountered.
  • Ah, gotcha. OK.

    Well, using the 11/16/15 build, I no longer get the connection crash. Now it just doesn't connect.

    I can fall back to the August build for now, but am looking forward to a new one. We're going to get 4 people together this Sat to play over the net, and would love to see how it performs.
  • Not seeing connecting problems on the 11-16 build. Note that windows-firewall can be a huge pain in the ass, as it sometimes starts silently blocking incoming connections, especially when you build a local network without internet.
  • @ralphhogaboom Are you ever able to connect to the server using the new version?
    Are you testing it on the same machine perhaps? If so, check out daid's and my discussion here: https://github.com/daid/EmptyEpsilon/issues/59


  • Honest question, because my code skills are rust buckets and this recovery and work have kept me from looking, could the scenario/server reset be handled by the same server init code just by adding an optional socket option.. so if you call the iniit server with a socket it reuses it instead of trying to close and reopen it? The most common issue is server closes socket.. client is in lala land with open dead link and won't close it...locking up ports on both hosts....if it simply resused the existing link problem solved.. I think...
  • Latest code will not open a server dialog if it's not possible to start the server. That's 1 step better then the current behavior.
  • I was testing on a Win 7 box, Windows firewall disabled, using OpenWRT on the router and forwarding port 35667 through the firewall. I'll admit I didn't scan the server for open ports (love me some nmap) either on the LAN or WAN IPs, mostly because I just didn't give it enough time. I saw the newest build, and just thought I'd give it a go.

    I have a lab here at work with identical images on all machines. I'll try the latest build on those today or tomorrow  and see what I come up with.

    And I'll properly diagnose my connections at home with regards to firewalls and open ports in the next few days as well. I apologize for reporting issues without having done proper legwork! It is certainly not my intention to misuse your time with sloppy issue reporting!

    Meanwhile, keep up the good work, cats. Terrific game.
  • Oh, and to clarify - yes, I want this to work through the internet, not just LAN.
  • The server runs on port 35666. You will probably have to enter the IP of the server to connect. I haven't tested going through a firewall to the server.
  • Yes, internet play is untested. There is no reason it should not work, and it requires port 35666 (tcp) to be forwarded.
    You can enter IP addresses in the connect to server screen.
  • Ah, OK - I saw in the console window that popped up "Failed to bind to port 35667", then stopped the game, turned off Windows firewall, and restarted it. So I assumed that was the port.

    Is there an ini file somewhere that the port can be manually specified?
  • Nope, the port is hard coded. (As it's also used to scan for servers on the local network)
  • Well, I did test that version in our GIS lab - WIn 7 64 bit. As you can imagine, they connected right away and were very smooth.

    I'm going to try doing some internet connections with some of my Artemis crew this Saturday. I'll be sure to let you know it goes. 

    I'll try doing port forwarding for 35666 first, then if necessary put that host in the DMZ. 
  • (And FYI, the "Failed to bind port" is due to the server scanner, which uses ports from 32667 and up on clients, as they need a port to communicate as well, but this can be any port as long as it's not the normal server port)
  • This port also does not need to be forwarded, as it's just using UDP broadcasts for scanning servers on your LAN. Which cannot be forwarded.
  • Got it working. Played for about 30 minutes.

    OMG, I think I love this game. You've done an amazing job at taking the core concept of Artemis and making it better.

    I have a love letter to write about it, soon, but for now - technical report.

    We were unable to connect over the Internet until the server host (which wasn't me) lowered the entire firewall on his router. I don't know if he put it in the DMZ, but he said "all firewalls needed to be down", but then yes - we connected.

    There were a few times the main screen on my end (remote) lagged, but for the most part, it was very smooth.

    We had three people connecting with 6 clients - each a main screen and a station.

    One remote user had his clients crashing - this happened three times during the 30 minute playtesting. The other two were rock solid.

    It was very exciting to see the first glimpse of a new world. I can't wait to try again.
  • >One remote user had his clients crashing - this happened three times during the 30
    >minute playtesting. The other two were rock solid.

    With the latest windows version? This version generates crash logs, so I would love to have these to look into crash causes.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!