Frontier Developments have asked us to assist them in hunting down instancing problems, in hopes of improving their netcode to prevent these problems. As we are a fairly well-organized team with a very varying type of clientele, and the ones who most frequently put special effort into resolving such problems, we are a good source of information for them on this.

To assist in this, we have a dedicated JIRA project which FDev can access to review instancing logs.

Preparing your Elite: Dangerous client for IPR

To enable FDev to glean as much useful data as possible from your log files, you must alter your AppConfig.xml.

The section you are looking to replace is the Networking section. Replace it with the following:

<Network
       upnpenabled="0"
       LogFile="netLog"
       DatestampLog="1"
       ReportSentLetters="1"
       ReportReceivedLetters="1"
       VerboseLogging="1">
 </Network>

This is the configuration you should normally use when testing IPR. Do not set up static port forwarding on your router unless you MUST, as the normal config is what FDev presently want to test.

If you need to use port forwarding to set up a working connection:

<Network
       Port="5100"
       upnpenabled="0"
       LogFile="netLog"
       RouterPort="5100"
       DatestampLog="1"
       ReportSentLetters="1"
       ReportReceivedLetters="1"
       VerboseLogging="1">
 </Network>

Then, consult your router's manual on how to set up a port forward to your computer. You want to forward UDP traffic on port 5100 to the computer which runs Elite: Dangerous. Alternatively, you may place your computer in the router's DMZ, although this is considered less secure than forwarding just the port itself. 

Please note that whenever you update your client, you must make this change to AppConfig.xml again, as the update process overwrites the file.

Procedure during rescue

If you are participating in the IPR program, and you fail to instance with a client, note the approximate time that you dropped to the client, but failed to instance with them. If you later succeed in instancing with the client, please note that time as well.

You should also note the client's CMDR name, the system the rescue happened in, and any other factors you notice (Failed to get text comms, wing iconography being wrong (Showing destroyed or similar), or instancing problems with other rats.

If possible, ask if the client has verbose logging turned on, and if they would be willing to submit their netlog file to help us help FDev research these problems. If the client is willing, ask them to mail you, or otherwise make available on the internet, the log file.

Post-rescue paperwork

Once the rescue is complete, if you experienced instance problems, you need to open a JIRA issue in the IPR bucket by clicking here.

Please be prepared to provide the following information:

• Your CMDR name
• The client's CMDR name
• The system the rescue happened in
• The approximate time the instancing failed in GMT/UTC (The in-game clock is UTC, you may use that as reference)

You will also need to attach your NetLog file for the relevant time period. The Netlog files are stored in the Products\Elite-Dangerous-64\Logs directory on Windows and in the Elite Dangerous/Logs directory on macOS, and are split into parts while your client is running. It is therefore important that you locate the correct file to submit. It should be:

• The correct date
• If there are multiple files for that date, the last modified time stamp for the file should be AFTER the instancing problem happened, but you should pick the file with the CLOSEST TIME AFTER the instancing problem happened.
• If the file is large, you can compress the file as a ZIP file. Most modern operating systems allow you to compress the file by right clicking it. Please only use .zip or .7zip formats if you are using a standalone compression tool.

If the client has also provided you with a logfile, download that, and attach it as well.

The description of the issue should include as much data as you can provide about the event surrounding the failed instance, such as:

• Did you see the wing beacon only when you dropped to normal space? 
• Were you able to send and receive text comms with the client? 
• Did the wing iconography show the client as destroyed even if they weren't?
• Did supercruise hop or a restart alleviate the problem?
• Were you altogether unsuccessful with instancing with the client?
• Did you have instancing problems with any of the other rats?
• Did you see the client or other rats in Supercruise?
• Did you collect the client's netlog?

Provide too much information rather than too little, but try to keep to relevant information to the instancing problem, not to the rescue itself.

Create an Instancing Problem Report