Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
"Your IP was shared" means steam made a P2P connection.
Works fine for me. Check your steam networking settings
In one post you have demonstrated both ignorance and a lack of reading comprehension. This game is unique in this behavior. No Valve titles (using that same back-end you blame) exhibit this behavior. Nor does any other title that I can self host with (P2P or listen servers).
Good diagnostic idea! One problem is I cannot find that equivalent in the Steam Deck interface. The PC we were working with did display the IP address shared message while suffering from the latency (as if it was connected through the WAN instead of LAN).
I don't think you understand.
I said it's "dependent." I'm not "blaming" Valves back end lol, there is nothing wrong with said back end. I'm not sure how it being unique or not matters? But sure, it's uncommon for games to have this limitation.
DRG simply can't make connections between players without that back end, it's not set up to do that, no Steam; no P2P. Doesn't matter if you're sitting right next to eachother in the same room, the data has to go: YOU>STEAM>THEM>STEAM>YOU
All that aside, the dev's said no:
Technical
LAN or local multiplayer
Neither split-screen nor LAN are planned for the game
10.09.2021 Dev Stream 10.09.2021
Wrong (or grossly oversimplified) again.
The only strict need for central servers in P2P networking is registering hosts for a directory. The clients can then make direct connections to the hosts using that registration data. This direct connection can be defeated by NAT where the direct host connection cannot be made. The ultimate mitigation to NAT issues is to host relay servers that tunnel all game traffic. That avoids the need for any customer system to accept connections in a networking sense. Most games use some for of NAT punch through with relay fallback. This is a little more complexity that both reduces server load and improves the customer experience. The clients attempt direct connection to the host, but on failure will connect to the relay server that the host is connected to.
I know the developers are unlikely to add this, but they flat out will never address it if no one complains about the status quo. I have an associate that will only play co-op with some friends on a LAN behind high latency internet. They are unlikely to do solo dives and their internet will not facilitate online play. I regret gifting them this game because they cannot enjoy it. While I may buy future GSG games sight unseen for there current track record, I would need to be very careful in considering gifting their games to others in the future.
It's not as if they just hid the feature from you, it just doesn't exist, they'd have to create it; and they're not gonna do that.
I was able to configure a second Windows client and confirm that connection between 2 Windows clients did not rely on a relay.
As this latest experiment demonstrates the scenario I originally described and proves my point, I hope (but don't really expect) Chibbity to take this as a learning opportunity.