"Physical" Multicrew broken for anyone else?

[CMDR James Northstar]

I played 10 hours in multicrew with 3 different teams yesterday, across a variety of activities. Laser mining, missions, conflict zones, etc.

No crashes or disconnects.

The only issue we had in one session was me trying to get into an instance where two people were already teamed up. They really need to sort this, or pop up a message explaining why I am landing at a station (or joining a conflict zone) where I can see team markers moving around, but not the actual team.

How can this still be a problem in 2021?!

Instancing in online games has been around for over a decade, every game that has it has a way for you to manually flip to the instance where your friends are.

I know FDEV couldn't care any less about multiplayer in this game, but a button that lets us change instances to where our teammates are can't be that hard to do.

 

[Sighman]

All those hours were across two different livestreams (not mine, I'm happy to leave the on-camera stuff to others.)

In one stream, I could see one guy when I rejoined, but the third member couldn't see either of us. In the other stream, I was the one who couldn't instance with the other two. In both cases it worked fine initally, then fell apart when someone died in the mission and tried to come back. In all cases we could see phantom 'team markers' moving around ground settlements/in space.

The words relog and instancing were used more than once, let's just put it that way.

I have port forwarding set up at my end. No idea about the others.

Unfortunately, to diagnose something like this FDev would need the network logs from all the team members, and with a stream going on that's a bit hard to coordinate. (Sometimes you only know someone by their commander name)

Alternatively, if there was somewhere to submit the 2-4 Cmdr names and a timestamp, they ought to be able to pull the relevant logs from their end. A bit of code to analyse them, and determine why certain team members were being connected to different servers, and that might start to unravel it.

 

[Ziljan]

Hey, I hear you, but sadly it does not since ED instancing is not server based but peer to peer. I strongly suggest you give the above advice a whirl.

Yeah, that's what we're saying needs to change. We've been saying it for years. If, the hamster wheel based peer to peer networking isn't going to work then you might as well make it a single player game and get it over with, instead of pretending like Teams is a viable feature.

Not going to be an unpaid beta tester filling out "TPS forms" in my free time.

 

[Sighman]

Yeah, that's what we're saying needs to change. We've been saying it for years. If, the hamster wheel based peer to peer networking isn't going to work then you might as well make it a single player game and get it over with, instead of pretending like Teams is a viable feature.

If they had a network connect dialog box which showed each member of the team, whether they were instanced, and if not why not - that would be great.

E.g.

'Cmdr not instanced because of restrictive NAT'
'Cmdr does not have port forwarding enabled'
'Cmdr connected through fallback mode'

Then you go off to the Frontier site to find the solution - or all point the finger at someone and get them to change their setup.


But it would be nice to see a list of team members with their pings and any connection problems/restrictions in game, like we used to get in most multiplayer games around the end of last century.

We do have 'Connection Statistics' available, but if this is on the Networking options page, you can only access that if you quit to main menu, not while you're actually in-game. Makes it hard to debug a team session if you've had to leave it to inspect the details.

"The Connection Statistics show the number of times the game tries to connect to another machine via different mechanisms: these are shown as Successes / Attempts"


BTW, I'm assuming most instancing problems are to do with routers and/or firewalls and/or ISPs - the client end, in other words.

 

[Imo]

It is broken for me too. Example: a friend joined my ship with his physical being. I docked in the Coriolis space station, went offline and my friend died like a helpless balloon when my ship suddenly disappeared from the game. I know a second before I quit the game my friend sat safe in the co-pilot chair...

 

[Sighman]

If you quit with a co-pilot aboard your ship, they get a countdown saying 'this ship will despawn in 10...9...8...'

They have to get out, and fast.

 

[MrTwister]

How can this still be a problem in 2021?!

Instancing in online games has been around for over a decade, every game that has it has a way for you to manually flip to the instance where your friends are.

I know FDEV couldn't care any less about multiplayer in this game, but a button that lets us change instances to where our teammates are can't be that hard to do.

This happens when an MMO (as advertised at least) game dev is unwilling to splash it out to run a few servers and insists that a garbage peer-to-peer networking scheme will hold a massively multiplayer game together just fine.

MMO networking has been around since at least 1997 with Ultima Online and works perfectly when devs know current technologies well and actually care about the customers. I still remember playing Mechwarrior IV games in 2001 using 56k modem connection and later DSL and it was remarkable how stable consistent and reliable connectivity was with a relatively significant number of simultaneous players in one area. But then - it was Microsoft Game Studios, if anyone would know how to do it well, it should have been them. It is also telling that you need client-server for proper results and to avoid the whole instancing b s with peer-to-peer..

 

[CMDR James Northstar]

sigh

Well, we fixed it. Multiplayer works just fine now.

You won't like how we had to do it.

See, apparently, letting uPnP manage this is just too much to ask for Elite Dangerous, so, had to configure the ports manually.

1) Rigged my computer and my wife's computer to have fixed IP addresses
2) In router settings, reserved those IP addresses for our specific machines to ensure we don't lose them
3) In router settings, set up port forwarding like this: Port 5100 routed to my machine's reserved IP address, port 5101 to her machine's IP address
4) In Elite Dangerous network settings, set Port Fowarding to ON. In my network settings, set the port to 5100, hers to 5101.

Haven't had an Orange Sidewinder or any other problem since. Steady as a rock, smooth as glass, no instancing problems where we can't see each other, it's just straight-up fixed.

This is all pretty advanced stuff to do right, I would never expect a layperson to be willing to do this. Certainly not to make one game work the way it's supposed to.

You hear that, Frontier? Your multiplayer issues are probably mostly being caused by the game client not playing nice with uPnP. I honestly do hope this helps you to identify the problems and fix them so that the people who are not obsessive weirdoes like me won't have to jump through these hoops and possibly jank up their network settings in the process.

 

[Brannor]

Update on efforts to consistently replicate the 'Odyssey team onboard crew disconnect on frameshift' bug.

Had team onboard crew working yesterday with the player it previously wasn't working with.
They had made some unspecified network changes on their side (security related) that may have addressed the issue.
Alternately, the consistent issue seen in our prior effort may have been a Frontier server side issue that has since been resolved or is intermittent.
(Source is unclear since, when we confirmed it was working, we didn't exhaustively test each of their network config changes to confirm if they were related or not.)

@Sighman , thank you for the comments on the peer-to-peer nature of multiplayer.
They were a helpful reminder that a consistent, replicable failure isn't always a server side failure.
In agreement with you that better client side error messaging would be helpful in identifying/addressing root cause on these issues.

 

[Globusdiablo]

Hey, I hear you, but sadly it does not since ED instancing is not server based but peer to peer. I strongly suggest you give the above advice a whirl.

Dark Souls uses P2P and has zero issues. Just saying. Multi crew has been broken since original release.

 

[Viajero]

Dark Souls uses P2P and has zero issues. Just saying. Multi crew has been broken since original release.

Not sure if it’s the same DS but a cursory search reveals tons of these:

https://www.reddit.com/r/darksouls3/comments/8dvh4z

Source: https://www.reddit.com/r/darksouls3/comments/8dvh4z/cant_play_with_my_friend_p2p_issues/

https://www.reddit.com/r/darksouls3/comments/4rpr03

Source: https://www.reddit.com/r/darksouls3/comments/4rpr03/cant_be_summoned_by_someone_on_the_same_internet/

p2p is inherently limited by our individual router / access to the internet set ups. As such I would be very surprised if DS p2p didn’t have many of the same issues.

Also I suspect the bandwidth requirements are not really the same. Even similar cockpit based games based on server such as war thunder or dcs struggle when close to 20 players…

 

[Globusdiablo]

Not sure if it’s the same DS but a cursory search reveals tons of these:

https://www.reddit.com/r/darksouls3/comments/8dvh4z

Source: https://www.reddit.com/r/darksouls3/comments/8dvh4z/cant_play_with_my_friend_p2p_issues/

https://www.reddit.com/r/darksouls3/comments/4rpr03

Source: https://www.reddit.com/r/darksouls3/comments/4rpr03/cant_be_summoned_by_someone_on_the_same_internet/

p2p is inherently limited by our individual router / access to the internet set ups. As such I would be very surprised if DS p2p didn’t have many of the same issues.

Also I suspect the bandwidth requirements are not really the same. Even similar cockpit based games based on server such as war thunder or dcs struggle when close to 20 players…

Having played DS extensively, I can tell you that it does not have anywhere near the same issues as E: D. But as you rightly point out, the cockpit based format struggles with up to 20 players, which is why Frontier should have looked a little closer at what successful P2P games like DS do, and limit the player count to 8 in it's latest iteration. P2P does work, it just has to be done right.

 

[Brannor]

Not sure if it’s the same DS but a cursory search reveals tons of these:

https://www.reddit.com/r/darksouls3/comments/8dvh4z

Source: https://www.reddit.com/r/darksouls3/comments/8dvh4z/cant_play_with_my_friend_p2p_issues/

https://www.reddit.com/r/darksouls3/comments/4rpr03

Source: https://www.reddit.com/r/darksouls3/comments/4rpr03/cant_be_summoned_by_someone_on_the_same_internet/

p2p is inherently limited by our individual router / access to the internet set ups. As such I would be very surprised if DS p2p didn’t have many of the same issues.

Also I suspect the bandwidth requirements are not really the same. Even similar cockpit based games based on server such as war thunder or dcs struggle when close to 20 players…

@Globusdiablo / @Viajero , this feels a bit off topic since DS2 performance (good or bad) isn't relevant to ED:O (not enough information to really confirm, and I seriously doubt the DS2 team is going to pop in and help out Frontier with identifying and isolating peer-to-peer connection problems.)

@Globusdiablo , if it is any consolation, I found the whole issue confusing since team onboard crew was clearly working and disconnecting only on certain explicit actions. It was very non-intuitive to me that a client side network or security configuration would be related to that since peer-to-peer communication had already been established and was working up to that point.

 

[Globusdiablo]

@Globusdiablo / @Viajero , this feels a bit off topic since DS2 performance (good or bad) isn't relevant to ED:O (not enough information to really confirm, and I seriously doubt the DS2 team is going to pop in and help out Frontier with identifying and isolating peer-to-peer connection problems.)

@Globusdiablo , if it is any consolation, I found the whole issue confusing since team onboard crew was clearly working and disconnecting only on certain explicit actions. It was very non-intuitive to me that a client side network or security configuration would be related to that since peer-to-peer communication had already been established and was working up to that point.

I hear you. My point was that P2P can work, but as Viajero correctly pointed out, it isn't flawless for everybody.

My grievance, no matter how FD chooses to network their game, is that it should be working out of the gate. Personally I like the free of charge P2P model, but it should have been kept small and stable. Multi crew has had networking issues since initial release, but has been left largely unattended, which saddens me. :/

 

[Brannor]

So the 'disconnect onboard team crew with frameshift' bug is back.
After a lot of testing last night, it does NOT appear related UPnP or Port Forwarding.
(Tested using @Sighman 's configuration, and was still seeing the problem.)
It happens roughly 1/2 the time on entering frameshift with a team crewmember onboard.

Tested telepresence crew as well, and it was NOT happening there.

The key point of failure appears to be the synchronization of the onboard crew on high wake completion / entering super cruise.
(i.e. if you fail to see the '<commander name> is onboard' message in blue in the upper right hand corner, you know the bug has occurred.)

What's interesting is that it is not complete communication failure between the clients.
For example, if using low wake to super cruise, if you drop back out of super cruise at the now visible 'wake signal' for your onboard crew member, their client will revert them back into normal space but with no ship or any other ability to interact.

This behavior appeared to have returned after the 3.0 update, but that may be coincidence.
If it is a peer-to-peer network comm. issue, there doesn't appear to be an effective work around at this time.

 

[El General]

sigh

Well, we fixed it. Multiplayer works just fine now.

You won't like how we had to do it.

See, apparently, letting uPnP manage this is just too much to ask for Elite Dangerous, so, had to configure the ports manually.

1) Rigged my computer and my wife's computer to have fixed IP addresses
2) In router settings, reserved those IP addresses for our specific machines to ensure we don't lose them
3) In router settings, set up port forwarding like this: Port 5100 routed to my machine's reserved IP address, port 5101 to her machine's IP address
4) In Elite Dangerous network settings, set Port Fowarding to ON. In my network settings, set the port to 5100, hers to 5101.

Haven't had an Orange Sidewinder or any other problem since. Steady as a rock, smooth as glass, no instancing problems where we can't see each other, it's just straight-up fixed.

This is all pretty advanced stuff to do right, I would never expect a layperson to be willing to do this. Certainly not to make one game work the way it's supposed to.

You hear that, Frontier? Your multiplayer issues are probably mostly being caused by the game client not playing nice with uPnP. I honestly do hope this helps you to identify the problems and fix them so that the people who are not obsessive weirdoes like me won't have to jump through these hoops and possibly jank up their network settings in the process.

Hi! I am experiencing these issues with onboard multicrew members. Does this configuration work? can someone please confirm this?

 

[sallymorganmoore]

Hey all o7

Just going through this thread whilst also noticing steady reports off Forum.

Let’s keep digging (totally appreciate how long this has been open), but unfortunately I do need to ask for your help on Issue Tracker to get these latest evidence reports in the right place.

Can you make your recent experience additions to:

https://issues.frontierstore.net/issue-detail/39251 please?

What would be FANTASTIC is for each time it happens, would you mind attaching your log files if you have a moment too, please? No obligation! It’s a big old ask but it’s just that extra layer of info.

Steps on how to grab the necessary files are at the top of that tracker ticket I linked above.

Thank you millions o7

 

[sallymorganmoore]

sigh

Well, we fixed it. Multiplayer works just fine now.

You won't like how we had to do it.

See, apparently, letting uPnP manage this is just too much to ask for Elite Dangerous, so, had to configure the ports manually.

1) Rigged my computer and my wife's computer to have fixed IP addresses
2) In router settings, reserved those IP addresses for our specific machines to ensure we don't lose them
3) In router settings, set up port forwarding like this: Port 5100 routed to my machine's reserved IP address, port 5101 to her machine's IP address
4) In Elite Dangerous network settings, set Port Fowarding to ON. In my network settings, set the port to 5100, hers to 5101.

Haven't had an Orange Sidewinder or any other problem since. Steady as a rock, smooth as glass, no instancing problems where we can't see each other, it's just straight-up fixed.

This is all pretty advanced stuff to do right, I would never expect a layperson to be willing to do this. Certainly not to make one game work the way it's supposed to.

You hear that, Frontier? Your multiplayer issues are probably mostly being caused by the game client not playing nice with uPnP. I honestly do hope this helps you to identify the problems and fix them so that the people who are not obsessive weirdoes like me won't have to jump through these hoops and possibly jank up their network settings in the process.

Goodness me, definitely passing this on o7
Thanks for all of the detail.

 

[sallymorganmoore]

Hey all o7

Just going through this thread whilst also noticing steady reports off Forum.

Let’s keep digging (totally appreciate how long this has been open), but unfortunately I do need to ask for your help on Issue Tracker to get these latest evidence reports in the right place.

Can you make your recent experience additions to:

https://issues.frontierstore.net/issue-detail/39251 please?

What would be FANTASTIC is for each time it happens, would you mind attaching your log files if you have a moment too, please? No obligation! It’s a big old ask but it’s just that extra layer of info.

Steps on how to grab the necessary files are at the top of that tracker ticket I linked above.

Thank you millions o7

The last few posts in here about the Upnp stuff didn’t show for me til a bunch of refreshes, but this response totally still stands if needed, for extra notice of the issue in general to awaken it on Tracker side o7

As I say, I’ll share the shared “self fix” info for absolute sure today.

Thank you still!

 

[Crunch Buttsteak]

Not sure if people have mentioned this before, but it is a really good idea if you utilize multi-crew often to determine whether or not your ISP is utilizing CNAT, where one public IP is shared among local nodes. Since Elite's multiplayer traffic is purely P2P with STUN relay, the cleanest connection possible should be utilized when available and if you're behind a CNAT or in a country with oppressive ISP regulations it probably means you might try a commercial VPN client and set your game's network settings to use the virtual network adapter that is usually installed with a software VPN. You can configure a VPN client on some commercial routers but that's a bit more of an advanced thing for most people.
There are many intricacies when it comes to global / cross-region P2P connections and NAT, but if you're on an ISP that utilizes CNAT it's worth trying a VPN if it's available to you.
I know Elite uses dynamic ports unless you're configuring manual port forwarding, so it shouldn't really matter because STUN, but the Internet and its underlying protocols are a fickle mistress.
Also, Windows can wreak havoc with this game sometimes. It's worth double checking your Elite client can accept inbound connections on Public and Trusted / Private networks. Most people close out of the window asking whether or not they would like the executable to accept inbound traffic without actually looking at what it's asking permissions for.

Edit:
Also, if you have access to IPv6 with your ISP, make sure that's an enabled option in your network settings.