Increase instance player cap per request for player run events

There was a lot of commotion over this:
Record-Setting 53 Player Distant Worlds Expedition Fleet Star at Sagittarius A*
2Rsze2h.png
Which led to some official responses like this:
"@Frontier_Help DWE wants to plop more people this sunday into one instance by Saga. Are we sure 52 is the hardest limit?"
"@ByRaidedVikings There is talk of the hard limit being 64, so it *might* be possible, but it will be very hard to get above ~53. Good luck!"
"@Frontier_Help can anything be done on your end to "artificially" increase the cap for a specific instance if given prior notice?"
"@ByRaidedVikings Unfortunately not as much as I would love to! Sounds like a good suggestion for our suggestion forum though. :)"
And which brings to me to suggest this:
It would be great if large player groups had the ability to request an increase to the instance cap during player group events in advance of them

Argument:
  1. We can do big coordinated battles, trade convoys, races, synchronized ballet if we have a big enough player group that demands it without the instancing issues we suffer from, doing so (capped at 16 without wing)
  2. Frontier_Help would love to do this for us if they were capable
  3. Rather than distributing server bandwidth evenly across all instancing, they could promote the ones that need it the most and support long term players
  4. David Braben likes community organised events with as many CMDRs involved

Requesting for comments, declarations of support and highlighting of issues. :)

[tweet]700661617848143872[/tweet]
[tweet]701096302852055041[/tweet]
[tweet]701362643911753728[/tweet]
 
Last edited:
"It would be great if large player groups had the ability to request an increase to the instance cap during player group events in advance of them"

This would be a great addition and would help with certain large scale events if technically possible.

+1
 
It certainly would be most awesome to have huge instances. The thing is, people have wanted larger instance capacities ever since the infrastructure for the game was announced.
 
Important Questions
Q1: Can be size of the island defined client side ?
* in past (alpha/beta) it was possible
Q2: Can be size of the island defined based on popularity/importance of system ?
* (player visits) and e.g. being owned by player-driven minor-faction ?
* the more players = the bigger island sizes
Q3: Can be the island size large enough to include all members of player-group (not just wing) ?
* yes I'm aware there is no player group system ingame (yet,sadly)
Q4: Can be size of island set to 64,96,128,256,512)?
* I'm aware there will be playable threshold but why not try investigate it and try keep pushing the ceiling
Q5: Can we help with hosting our own 'island' controllers/routers (imagine it as dedicated client w/o rendering interface/dedicated server) ?
*e.g. protected process running within virtual box environment (look at BOINC science projects)


note: island = session/instance
 
Last edited:
There needs to be more infrastructure for groups. Groups that get and maintain a certain number of players should earn prestige in some form or another, getting advertising space on the title screen, get perks regarding instancing, etc.

Groups need to become the custom servers lots of other multiplayer games have (custom within the scope of the game, such as Mobius, or a specific powerplay group). People would stop whining about not getting the experience they are looking for in Open if they can get it in a group.

In the same vein, groups should be able to agree to go to 'war' with another group, which temporarily merges them as far as matchmaking is concerned.

ED needs more group infrastructure. The people whining about open are starting to get annoying.
 
Last edited:
This is why F-DEv should allow players to rent dedicated servers for player groups to assign regions of space. If a player group could assign say 64 or 128 players to their home system, I am sure people would jump all over the opportunity to throw money at it.
 
Well, we can be pretty sure that the hard cap is NOT 64, given that DW just stuffed 80 people into one instance. The servers were even unhappier though; entering Sag A* at all was a crapshoot.
 
Well, we can be pretty sure that the hard cap is NOT 64, given that DW just stuffed 80 people into one instance. The servers were even unhappier though; entering Sag A* at all was a crapshoot.

Given the nature of the game, the hard cap is based on the instance host's upload speed. The higher it is, the more you can fit. We had issues earlier getting more than 36 till we switched the instance host.
 

Robert Maynard

Volunteer Moderator
It looks like 101 commanders have made it into a single instance today:

[video=youtube;tfa6ktnuEdo]https://www.youtube.com/watch?v=tfa6ktnuEdo[/video]

.... which is a quite astonishing 5050 simultaneous P2P connections (plus 101 connections to the Frontier servers, of course).
 
Last edited:
we have varying counts above 101 but 101 was the number we're certain we at least had before people started crashing.

Things became less stable as time went by and this is why we could use a service like what we had. We have 50 other commanders who weren't able to join in the instance before crashes started occurring. Nevertheless, We are all members of the Distant Worlds Expedition.
 

Robert Maynard

Volunteer Moderator
we have varying counts above 101 but 101 was the number we're certain we at least had before people started crashing.

Things became less stable as time went by and this is why we could use a service like what we had. We have 50 other commanders who weren't able to join in the instance before crashes started occurring. Nevertheless, We are all members of the Distant Worlds Expedition.

The game is P2P/Server-Lite, i.e. players are P2P connected to each other player in the instance and the Frontier server - the server does not host the instance. As such, the stability of the instance is largely reliant on the quality of each player's internet connection and consequently their connection with each other player.

I do not expect that the server bandwidth for a 101 player instance would be much greater than that of 101 single player instances - however the P2P network traffic between players would be exponentially greater than that of 51 two player instances.
 
The game is P2P/Server-Lite, i.e. players are P2P connected to each other player in the instance and the Frontier server - the server does not host the instance. As such, the stability of the instance is largely reliant on the quality of each player's internet connection and consequently their connection with each other player.

I do not expect that the server bandwidth for a 101 player instance would be much greater than that of 101 single player instances - however the P2P network traffic between players would be exponentially greater than that of 51 two player instances.

If you are using mesh, it is N-1^2.

If you are using b-tree or super nodes, it is less.
 
Hey all, the Elite Racers are soon going to do this https://www.reddit.com/r/EliteRacers/comments/46xoqw/important_help_improve_elite_dangerous_submit/ for all events to contribute to a better understanding of the problems.

Transcript (sorry for the format, I'm terrible at it):

Hey all, thanks to
/u/StuartGT who had the great idea!

In an effort to improve Elite's netcode, I think that Elite Racers can contribute greatly to Frontier's understanding of server performance while under heavy load. Due to our unusually high player count in proximity to station assets andNPC traffic, we sit in a unique position to provide insight.
Follow the steps in the "Still have connectivity issues?" section and submit your logs with an explanation of any problems you may have encountered at today's event (e.g. station dissapearing, not able to instance, rubber banding") at this link here https://support.frontier.co.uk/kb/faq.php?id=78.
This will become a regular practice after every event for those interested in helping out. Even if you didn't run into any problems, it might be good to submit your logs alongside everyone else.
Include somewhere in your ticket the following phrase: "Elite Racers ______ Event"

Hopefully, this does some good :)
Cheers,
FH
p.s. "To activate Full Logging before an event add these lines of code to the AppConfig.xml file
ReportSentLetters="1"
ReportReceivedLetters="1"
VerboseLogging="1"
Full Logging is used by FDev Support whenever a CMDR has P2P/network troubles. It logs ALL Server & P2P requests. Don't worry about the file sizes, they only reach a few MB after an hour or two." - StuartGT


Anyway, I know that we could use some better network stability for our events. It usually takes us 45+ minutes to get everyone into an instance and today was absolutely horrible. We managed to get everyone into the instance about 10min after the start time (new record) but then the servers crashed :(

So yes, I'm in support of this idea!
 
Last edited:
Here is my professional opinion, as an IBM certified Enterprise Architect with 2 patents in data migration:

The current system was probably an elegant solution that balanced server load and client load.

However, it is not scaling well, especially considering the incredibly variable quality of service of so many players scattered around the world.

The underlying technology needs to be scrapped and replaced with something tried and true.
Granted, it might not be as elegant or efficient as the current solution, but sometimes Ugly and reliable (think python) is the right tool for the job.

This problem has been solved since the 90s with Everquest Raids, there is no reason we should have issues now.
 
Here is my professional opinion, as an IBM certified Enterprise Architect with 2 patents in data migration:

The current system was probably an elegant solution that balanced server load and client load.

However, it is not scaling well, especially considering the incredibly variable quality of service of so many players scattered around the world.

The underlying technology needs to be scrapped and replaced with something tried and true.
Granted, it might not be as elegant or efficient as the current solution, but sometimes Ugly and reliable (think python) is the right tool for the job.

This problem has been solved since the 90s with Everquest Raids, there is no reason we should have issues now.
thanks for sharing your expertise. I wanted to wait for other responses, how long would you say it would take to write and migrate the game over to a more reliable system?
 
Back
Top Bottom