SiMPLE | Forum

It's also hard to make any kind of useful deduction from a snapshot in time like this.  And sometimes, hard to make a useful deduction using an ICMP Echo (ping) at all.

For example, it appears this snapshot shows that there was a 207ms "outlying" measurement on hop 7, even though the average for that hop is 59ms.  (i.e. Most were not 207ms.)  Essentially "a single time", the measurement came back as 207ms.

So "is hop 7 prone to high ping?"  We have no idea.  All we know is that when measuring the round-trip to hop 7, "one time" it came back slow.  It could have been hop 7 at fault, it could have been hop 6 at fault, or any prior hop.  It would take more observations and data to say "is this measurement consistently at hop 7, or spread between multiple hops", which could mean the closest of those hops is the one being flaky.

But the 100% packet loss you're seeing at hop 3 and at bf1942.team-simple.org is "usually completely normal", and is just an indication that the device itself (router, server) or the network of the datacenter simply doesn't allow ICMP responses (ICMP Time To Live expired), or ICMP requests (ICMP Echo or "ping").  They simply don't allow the kind of traffic this measurement is attempting to employ.  Nothing you can do about that for these existing tools, except try and make what conclusions you can about the intermediate devices that do respond to ICMP.

Meaning your in-game latency (which has to to with BF1942 game protocol, and nothing to do with ICMP Echo) may be fine, but attempting to PingPlot or traceroute shows failure.  Although you can actually change what port some ping applications use (e.g. so it tries to hit the BF1942 14567 UDP port instead of ICMP), it usually doesn't let you give a payload that the server would actually respond to.  Therefore even if using ping to hit the BF1942 game port, you would still have 100% packet loss, but for a different reason.

So it's almost like we need to create a BF1942-specific ping application, maybe hitting the smallest and easiest port 23000 status query the server can respond to quickly.  So that the traffic we're using is something that reaches all the way to the game server, because it's a protocol that is / must be allowed for game usage.  Whereas ICMP is not required and many times not allowed.

But the application would still employs IP TTL (Time To Live) when sending these game-specific ping attempts, to give a map of "how quickly did this communication attempt get failed from each hop."  At least for whichever hops actually allow ICMP Time To Live Exceeded responses for packets that exhausted their TTL, which they still would not be required to actually do.

Hey, nice to see you around.

I presume you've already covered enabling of DirectPlay, else it wouldn't play at all.  The "freezes" brings two things to mind:

Tuia's GameSpy fix also addressed the fact that querying a non-responsive master server (no matter who's master server you're querying) could hang the game for an extended time.  That issue is one of many good issues addressed in battlefield_1942_gamespy_patch_v1.61.exe, if you haven't applied that already.

The other one indeed could be resolution-related, and the fact that there's a hard-coded 800x600 attempt in the game, regardless of whether your system supports displaying 800x600 or not.  Bud recently pointed to an updated BF1942.EXE on bfmods.com which intends to address that, by using the configured game resolution for everything including the menu.

The Battlefield 1942 game itself does not have any issue with VPN connections.

This restriction is intentional and specific to the Team-SiMPLE server itself.

If you have your own LAN server, it would not have the same rejection of VPN clients.

Nope.  It's been down months for me, I believe.  The error I get is as though the DNS configuration is no longer correct, or the DNS servers are blocked from responding.  (Not a "name doesn't exist" kind of error, but "the DNS servers that would need to answer aren't responding" kind of error.)

They had reported the web site was getting DDoS'd around the same time as the server attacks back in August 2020, and I've been assuming they went underground and I just haven't had the need to ask where it's at now.

Wasabi pops in here from time to time, so maybe he'll have some redacted or unredacted comments about it.

"Woman shot" was a protester who was first to climb through a window the crowd had just broken through.  Not sure what media will actually play from your location; there were several recording the incident, but this one shows a simultaneous split-screen for multiple of them:
https://www.reddit.com/r/PublicFreakout … woman_not/

I had not heard of the other deaths yet, but there was at least one in critical condition who had fallen from the scaffolding that was outside.

Why any person shown in any of the pictures and videos thought they could just break through a police line and "move freely about the Capitol" seems weird.

American companies required to add bitter-tasting compounds to all air freshener to prevent people from drinking it in 3... 2... 1...

Amazon emailed today saying the new season is live.

On one level, it's showing the guy behind the camera with a laser pointer on the woman's buttocks, and the cat about to pounce on the red dot.  On another level , it's suggesting that Germany helped push Japan into attacking Pear Harbor.

I just can't stop watching that one.   Like, how long did they have to go around searching for seemingly the perfect trippy 1930's cartoon to pair with that....

The first thing that came to mind for me -- since I wasn't aware of anyone sitting on the source code of BF1942 in order to adapt it to other platforms -- was that "play this game in a web browser" would be spinning up a single-application view of Battlefield 1942 running on a Linux or Windows desktop.

i.e. Using on-demand Amazon or Google compute services to spin up however many of these are needed to service the players trying to join by web browser.  The "code" that must come through the web browser is purely remote control, not the game.  Consequently bandwidth requirements would be high compared to Battlefield 1942 itself, since you're transmitting remote viewing and not just the game protocol.

Don't know where that would fall on the legal spectrum, since you're not "giving their game code away" or making it available for download; you're giving away the ability to play their game, by essentially "borrowing a computer on which you have it installed."

Too Many Zooz - Bad Guy (BILLIE EILISH COVER)
https://www.youtube.com/watch?v=iD4RyLt_FbE

Too Many Zooz - Car Alarm (Official Video)
https://www.youtube.com/watch?v=xV7nHX2RLjQ

If it's a Windows-based server (which multiple of your posts have implied), you can also use tuia's "Windows server executable patched" downloads from http://team-simple.org/download/.  Or even if it's actually a Linux-based server, and you use the "Linux server binaries patched" downloads instead.  In addition to other fixes that these server binaries are patched with, they also include the replacement of master.gamespy.com with master.bf1942.sk for the DNS name, as described in the included readme files.

Interesting.  Never heard of doing that, and have never taken mine off of "LAN" regardless of which server I'm on or how many people.

What the symptoms suggested to me -- rightly or wrongly -- is that the CPU or GPU isn't keeping up.  As soon as there is "real work to do" with actual players in the proximity and lots of things needing to move on the screen, it's the computer itself that is slowing down.  That the ping rises is just a secondary effect of this.  Because of the computer being too busy to respond in a timely manner to network sends and receives, same as it's struggling to keep up with what needs to update on the screen.

That would be my suspicion anyway.  In addition to the "applications running in background" which could be stealing what should have been your CPU cycles, are we possibly just short of physical memory and causing disk swapping when things get busy in the game?

Folks with the Windows gameux.dll issue could also see symptoms like this.  So you might want to use Task Manager's "Details" list to sort by CPU consumption and see if there is a RUNDLL32 instance sucking your CPU, even though "you aren't running any other applications."

It doesn't happen to me often enough to have already tried this, but Windows actually introduced a "reset and restart my display driver" hotkey.

Windows Key + CTRL + SHIFT + B   
https://support.microsoft.com/en-us/hel … nk-screens

I wonder if that might not be "a quick path back to normal resolution" in cases where this happens.