Elite Dangerous: Update 7.01 and Horizons Update (PC Only)

Well yeah, that just says you need to have extra software in place to allow the packets through - hence the complications to make the it work, unless you allow it somehow - say by opening the port, using uPnP, or fancy NATs - which not everyone has. All you are saying is 'there are other options' - which I agree there are. And one is port forwarding - assuming you know what you are doing. Which is presumably why it is a documented option on the game website 🤷‍♀️
The UDP protocol works the same way regardless - the fact that hole punching works at all serves to prove that your assertion that UDP requires port forwarding is wrong
Yeap, that's correct. But let's not forget that we are all behind a NAT
And the most common NAT implementations (symmetric nat) works only for a one-on-one communication. A call-response if you want.
That is between your game client and FDev servers. Your game-client calls FDev-server and FDev responds back using the com-channel initiated by the client. Someone else cannot respond using the same com-channel. So it works for a Solo session of Elite, but not so much for a Multiplayer session.

When multiplayer in a p2p architecture, you have to communicate directly with other players - a full cone nat could help, but that's regarded as quite insecure and its not widely implemented
And without a full cone nat or a turn server or some other form of proxy - the port forward (or the upnp) is needed for a p2p game. 🤷‍♂️

Edit, ninja'd sort off
If you weren't completely wrong, then I would be unable to play in anything other than solo - I can't access my ISP's gateway in order to forward a port back to my router, so even if I did try to port forward, it wouldn't make my network accessible from the internet. But I almost always play in private groups, with four or more people.

I don't have port forwarding, and I disable uPnP, and yet I play multiplayer all the time - either you're wrong, or my friends and I have been sharing a mass hallucination for a couple years
 
I don't have port forwarding, and I disable uPnP, and yet I play multiplayer all the time - either you're wrong, or my friends and I have been sharing a mass hallucination for a couple years
Or at least one of your friends does have the above set up, and your PC is never the host.

[edit]Or you're going through an arbitration server.
 
I don't have port forwarding, and I disable uPnP, and yet I play multiplayer all the time - either you're wrong, or my friends and I have been sharing a mass hallucination for a couple years

I do think FD employs some sort of inhouse proxy specifically for this cases - but that's either not able to work in every instance or it's very resource limited or both.
Also, as posted below, you should be able to connect to multiplayer instances held by other players which are able to use upnp or straight port forward (basically they're the servers and you are the client)

My understanding (I do the same thing and "sometimes" see other commanders in Open) is that this only works if at least one commander in your current instance is using some sort of port forwarding, thus acting as a host. That is, the two of us alone (no other commander in the same instance) should never be able to see each other in the game. We always have to rely on at least one commander using PF. I've always been curious about this and would have liked to check if it's true or not. However, I lack the motivation to find someone willing to sacrifice their time for such a test. My interest in multiplayer is also just not big enough for that.
 
yeap most probably - i preferred to use inhouse proxy as generic designation, but you're probably right
It was a stream with Dav talking about the networking issues - it seemed very much something they do as a last resort for those who don't set up their networks correctly.
 
My understanding (I do the same thing and "sometimes" see other commanders in Open) is that this only works if at least one commander in your current instance is using some sort of port forwarding, thus acting as a host. That is, the two of us alone (no other commander in the same instance) should never be able to see each other in the game. We always have to rely on at least one commander using PF. I've always been curious about this and would have liked to check if it's true or not. However, I lack the motivation to find someone willing to sacrifice their time for such a test. My interest in multiplayer is also just not big enough for that.
Obviously many people share that misunderstanding
It was a stream with Dav talking about the networking issues - it seemed very much something they do as a last resort for those who don't set up their networks correctly.
A correctly set up home network has no ports open

It's not a "last resort" mechanism - port forwarding is an easy workaround for problems that are difficult to solve without actually coming to your house. It's on par with "turn it off and on again" as far as "solutions" go, i.e. a shortcut that gets the laymen to stop bothering you with problems they don't understand enough for you to walk them through remotely. It does work, I'm not arguing that - but it is not required, and is not the recommended approach.
 
A correctly set up home network has no ports open

It's not a "last resort" mechanism - port forwarding is an easy workaround for problems that are difficult to solve without actually coming to your house. It's on par with "turn it off and on again" as far as "solutions" go, i.e. a shortcut that gets the laymen to stop bothering you with problems they don't understand enough for you to walk them through remotely. It does work, I'm not arguing that - but it is not required, and is not the recommended approach.

I guess you dont really get how p2p works. Especially in the absence of a middleman aka the Turn Server

Regarding the "last resort" - yea, it's quite appropriate.
ED is a huge bandwidth consumer. FD runs a multiplayer game with no monthly subscriptions.
A turn server incurs a huge bandwidth consumption that has to be assumed and payed for by FD simply because the traffic instead of going from A <> B, where A and B are ED clients, it has to go A<>C<>B with C being the Turn Server and FD paying for both A<>C and C<>B traffic
 
For those who feel they are experts (or actually are - I am not and my English is not sufficient to understand such a video, being quite helpless without DeepL), this video should explain the details of the whole network structure in ED. At least this is coming from the true experts on ED and not one of the endless legions of self-proclaimed ones.

Thanks - hadn't seen this before.

It's all pretty entry-level stuff though, tbf. I'd be staggered if most people in the audience couldn't have winged that regardless.
 
For those who feel they are experts (or actually are - I am not and my English is not sufficient to understand such a video, being quite helpless without DeepL), this video should explain the details of the whole network structure in ED. At least this is coming from the true experts on ED and not one of the endless legions of self-proclaimed ones:

Source: https://youtu.be/EvJPyjmfdz0


relevant parts

"So we start off with our game client and unfortunately they're behind a firewall or they might be behind a nat restrictive router, yay :) ... no ... yay :( "
Dav was being very plastic regarding his level of appreciation for nat restrictive routers :D

"So in order to help with UDP NAT Traversal we provide some basic network relay services"
"So we built a package based on Amazon minimal Linux system and we run an opensource turn server which provides stun and turn services and i wont talk about them in detail, they're just basic network services and we host those in various availability zones..."

"... but one relay server isnt really going to quite be enough because sooner or later we'd exhaust the network throughput of a single computer"

so they employ clusters of relay servers in different zones, load monitoring software so when a relay server gets close to capacity, another instance raises automatically


yeap, it cofirms what was already posted.
instancing works without port forward (nobody doubted that), but what it doesnt say it's the fact that using the relay servers will be indeed the last resort since it cannot offer the same level of latency and stability as a proper port forward or a properly implemented upnp (imagine a triangle, AB will always be shorter than goin AC then CB)

I wished some insight on how an instance holder is picked up, how it's switched over, on which criteria and how often that criteria its reevaluated.
But i guess... they might not want to make this information very obvious since it would make it easier for some people out there to exploit that info to manipulate instancing quality


Heck, even MS has a list of ports that have to be permitted by port forward or upnp to reach the Open Nat level required for a full, unhindered, multiplayer experience in XBox network.
 
yeap, it cofirms what was already posted.
instancing works without port forward (nobody doubted that), but what it doesnt say it's the fact that using the relay servers will be indeed the last resort since it cannot offer the same level of latency and stability as a proper port forward or a properly implemented upnp (imagine a triangle, AB will always be shorter than goin AC then CB)

This is what I've been trying to explain to people who say 'it shouldn't be necessary to configure my router/mess around with network configs/etc'

If you want stable gameplay with other commanders, and you're not getting that now, configure port forwarding. If you're happy to take pot luck and you're okay with losing connections to other players and teammates at random, don't set up port forwarding.

There's one other factor too: your frame rate is affected by the frame rate of the person hosting the instance*. (Those network packets have to be handled somewhere, and if their PC is struggling, yours is going to be idling as it waits around for the packets.) Personally I'd set up port forwarding just for that reason alone.

* I've verified this in the past with the help of two other commanders, one of them using a potato PC to run Odyssey.
 
It seems pretty obvious to me that the frame rate issues in ground CZs derive from the AI rather than graphical considerations, predominately. If this is so, I would imagine that the CPU is getting choked by pathing calculations, which I know are computationally very expensive, and possibly also line-of-sight calculations.

Have the developers considered pre-calculating paths for a grid-based look-up table for each settlement? Computationally, very cheap. I would imagine that in order to make decisions, the AI needs to continuously path between 24-25 mobile actors and then back-trace the path until line of sight has been reached, then recalculate line of sight to account for any obstructions. Each grid point could have a cheap line-of-sight look up table for that purpose, which could be calculated on arrival for the purposes of shooting and such like.

Without looking under the hood I'm just guessing at what the problems are. But, I wouldn't want the solution to compromise the simulationy aspect of ground battles. I like that.
 
So still CTD with EDO and the flashing white light in PowerPlay status board control tab is going to cause a seizure if FDev does not fix it soon; really making this game hard to play. Please Pretty Please :(
 
TL;DR When I said port forwarding is not necessary, I was correct.

False. A correctly set up home network has no unnecessary ports open. If you think no ports are necessary, then you have never desired to run your own server. Just because one is using a home network does not preclude one from running a server.
The basic home network does not have a public server on it - I already addressed the fact that port forwarding is specifically meant to open a port to allow external clients access to a server inside the network. The type of user who typically told to set up port forwarding in these scenarios is the type of player who typically connects to other peoples' servers rather than hosting their own - in other words, the exact opposite of the group that actually needs to port forward
I guess you dont really get how p2p works. Especially in the absence of a middleman aka the Turn Server

Regarding the "last resort" - yea, it's quite appropriate.
ED is a huge bandwidth consumer. FD runs a multiplayer game with no monthly subscriptions.
A turn server incurs a huge bandwidth consumption that has to be assumed and payed for by FD simply because the traffic instead of going from A <> B, where A and B are ED clients, it has to go A<>C<>B with C being the Turn Server and FD paying for both A<>C and C<>B traffic
Sounds like... there is no inherent requirement for a port forward, like I said all along.

But I see where the misunderstanding is - when I use the word "required" it's literally what I meant, while others took it to mean something other than "necessary to work at all"
 
The basic home network does not have a public server on it - I already addressed the fact that port forwarding is specifically meant to open a port to allow external clients access to a server inside the network. The type of user who typically told to set up port forwarding in these scenarios is the type of player who typically connects to other peoples' servers rather than hosting their own - in other words, the exact opposite of the group that actually needs to port forward
I covered this by not only stating "unnecessary", but emphasizing the word.
 
Just a minor visual bug related to fleet carriers. (Integer overflow)

First part, and this would appear to be a design choice: you can't set up a buy order for more than 2 billion worth of goods. It just stops you adding more.

So far, so good.

The issue comes when you try to set up a sell order for those 2 billion worth of goods at a higher price than you paid.

Just before the magic 2 billion estimated return:

20211010132804_1.jpg


After crossing the 2 billion:

20211010132807_1.jpg


As you go higher and higher the negative number drops to zero, then back to two billion, and then into negative two billion and so on.
 
Top Bottom