ANNOUNCEMENT January Update - Beta Announcement

[boblaraclooze]

View attachment 152167​

Greetings Commanders,

As mentioned in October, our upcoming updates will be almost exclusively focused on addressing recent and longstanding issues and bugs. The next update will be our first step as part of that - and it will be coming towards the end of January.

For this update, our first and foremost priority is to ensure that everyone is able to have a seamless experience when playing Elite Dangerous, so our focus will be on aiming to resolve game breaking bugs and stability issues that cause disconnects, softlocks and crashes. By working internally with Customer Support, QA and Development teams, alongside the feedback you shared with us here and via the Issue Tracker, we've identified and are addressing a number of issues in the January Update, which we've detailed below.

As with previous betas, we found your feedback and assistance incredibly useful in helping us identify and resolve bugs and issues. The next updates will be coming with their own public beta, the first of which will run on PC from 27 November to 2 December for the January Update. We are also investigating the ability to extend future betas to console players as well, and will announce any developments about this when we have more information.

Due to this update focusing on a number of bug fixes, rather than new content and features, the beta will appear and play very much like the existing live game. However, getting involved and testing provides a huge benefit for all Elite Dangerous players, so we are very grateful for any time that you are able to spend in the beta. Every system, ship, loadout, module, mission, activity, rank or other part of the game played provides opportunities to test and identify issues. With your support, we hope to be able to identify and fix as many as possible before the update goes live, offering a smoother and better experience for all. Thank you to all who are able to get involved.


What we're addressing in the January Update (and the beta)
We wanted to highlight some of the top voted issues from the Issue Tracker, and what we plan on doing with them moving forward.

Alongside our own internal tests, we'll need the help of you, our community beta participants, to help us identify if the fixes we're introducing work as intended in a live, multiplayer environment.

Repairing Thargoid-attacked stations: not all delivery numbers counted

• We will implement a fix that will correctly account for all deliveries for starports that have been attacked by Thargoids.

High resolution screenshots create tiling artifacts in bright objects

• We will implement a fix that should prevent tiling artifacts in bright objects when taking a high-resolution screenshot.

Galaxy Map won't select systems I search for

• We will implement a fix that should allow you to select a searched system on the Galaxy Map.

Keyboard stops working within game

• We will implement a fix for this issue to ensure keyboards work in-game as intended.

SLF female npc crew member has no audio and no text in the comms

• We will implement a fix for this issue.

We wanted to bring your attention to the following issues, as these will need additional information and testing in the beta to ensure the fixes are working as intended:

FSS: Long delay when scanning planets with geological sites

• As it currently stands, in order for the geological/biological sites to be placed on the surface, the entire stellar body must be fully generated (we then know the topography and can place sites where they will be accessible). This can take tens of seconds.
• As part of the January Update, we aim to address this with an alternative process. We have run tests on thousands of in-game planetary bodies and by using this data, we're able to extrapolate the likelihood of geological/biologic sites being present on similar stellar bodies. We then use this data and indicate if the planet is ‘Unlikely’, ‘Likely’, or ‘Very Likely’ to have a geological/biological sites.
• It is not 100% guaranteed that there will be a geological/biological site on the planetary body, but does give commanders a much faster indication of probability. This will enable commanders to quickly ascertain if the planet's worth a visit.
• As this is an alternative way to display information, we would love to hear your feedback on it to determine whether or not it is better than the current process.
• Please note: this will not affect Thargoid or Guardian sites, which will show up instantaneously.

Conflict Zones have no contents

• We have identified that the LUA script responsible for populating Conflict Zones can stop running at times, which causes this kind of issue. We will implement a fix, but we'll need your feedback on whether or not the issue persists.

The Invincible Heart

• The team have been investigating this issue for some time, however, it has proven difficult to reliably reproduce in-house. As part of the beta, we'll be adding additional logging information and will need our community beta testers to try to reproduce the issue so we can collect more data to help us resolve it.

Instance splitting when fighting Thargoid Interceptor

• We'll be introducing a fix for this, but as it is a network-related issue, we'll need this to be extensively tested in the beta.

Thargoid Interceptor - Heart cycle reset

• We will implement a fix to ensure that the Thargoid Interceptor's combat state does not reset. As with the issue above, we'll also require commanders to identify if this is still occurring in the beta.

Exiting the Game just hangs, need to force terminate

• We will need additional feedback in checking if this issue is still occurring in the beta.

Please note that this is not an exhaustive list of all of the fixes coming in the January Update and more will be detailed in the beta patch notes, released next week.


We'll be investigating the following issues for future updates and will detail any fixes for these when available:

• Two major issues with light from the local star (so-called "tinting")
• Thargoid Interceptor - Shutdown pulses without warning
• Core mining fragments glitch inside the asteroid
• Wing Mining - Seismic Charges malfunction
• Chat icon displays "1" while no message is there
• Black screen after respawn in CQC / Game crashing
• Massive rubber banding of npcs and player around stations and sometimes in other instances.
• Crystalline Clusters Disintegrate Without Producing Materials

We also wanted to give you an update on the following issue: VR: Double Vision and Incorrect Rendering on HMDs with Non-Parallel Displays (ex. Pimax). At the current time, there are no plans to provide support for new HMDs outside the officially supported systems and platforms. The officially supported platforms are Valve Index, HTC Vive and Oculus.


BETA - how to get involved!
A new beta section forum will be set up with details on how to take part and how to submit bug reports, but here are the main details on how you can help us in the upcoming beta:

• The beta begins on the 27 November and will run until the 2 December.
• The beta will be only be accessible on PC. We are looking into expanding this for console players in the future.
• To take part in the beta, all you’ll need to do is load up the launcher and select (and update) the following product: Elite Dangerous: January Update (Beta) from the 27 November. Once that has been completed, you’ll then have access to the January Update beta. If this doesn't appear, please restart your launcher.
• We'll be updating the Issue Tracker with a January Update (Update 3.6) Beta section, and we encourage all those who are taking part in this beta to report any encountered bugs or issues through it. In addition, we will also be adding links from inside the game that will take you directly to the Issue Tracker site.

We just want to thank you once again for all the passion and involvement you show for Elite Dangerous. With your participation, we know that we can help to make our game more sustainable and beneficial for the future of this amazing galaxy!

HI Frontier, Thanks for all of your investigations!
Just I want to suggest one think that I need for the begining of the supercruise assist > We have realy need to bind a button to the joystick to activate or disactivate this function > So I suggest that you could implement this new binding in the new corrective release...
Thanks for advance

 

[Tomtom]

Why not... give the player a choice?

How's about:

Expensive discovery scanner: works the old way - it's slow but accurate.
Cheaper discovery scanner: the new way; fast but potentially inaccurate.

And engineering variants, of course

 

[varonica]

those percentages must be a joke ... I don't want to imagine the amount of failed trips and the time lost in this new thing.

I don't understand how anyone can agree with this, really.it's like they want to sabotage the own game.

I have already expressed my concern elsewhere about missed opportunities due to less accurate FSS scans, and that's when I was thinking the failure rate was in the single digit percentages, this 60% is way more than I expected.

My guess is that the distribution is strongly bimodal - we already know that volcanism+landable yields a very high probability of geo sites, for instance. So 60% may just be an arbitrary cutoff, while in fact virtually all bodies fall into either the <1% or >80% probability buckets.

From my own travels before the FSS where I used the planetary stats to estimate whether the body did or didn't have vulcanism based on orbital period, mass, age, size of parent body and composition of the body in question I would say these figures refer to vulcanism, not sites. I would suggest based on a huge number of scans that there is only a small percentage of occurrences of bodies with vulcanism that don't have geo, less than 1% range so I don't think that's even taken into consideration in these figures. A very small difference in distance from a parent body, say you have two small moons orbiting a gas giant at slightly different distances, can mean the difference between having and not having vulcanism so I think the percentages refer to this situation. How likely a body is to have vulcanism based on system stats and nothing else. I am sure there are criteria for biology but those appear to be a secret, it appear to depend on where in the galaxy you are in part so that's all theirs.

Now these percentages seem rather broad to me, my own experimentation led me to an accuracy rate of around 90%, so 90% of the time by examining the system stats I could make a positive prediction of vulcanism based on various factors, I would have expected FDEV to do way better than that, but in the end with their 90% they are really only matching what I could do for myself, I was expecting the "very likely" to be in the low single digit error level, disappointing indeed.

This leads my other statements of concern to be reiterated here, we are replacing an accurate system with a far less accurate one, and I can only see that as a step backwards. For me scanning time in the FSS for a volcanic body is around 5 seconds but I know it's much longer for many other people so I can see the desire to speed things up, but the sacrifice in accuracy really is unacceptable. Oh well.

 

[varonica]

Still playing “catch up” on the thread, but it occurs to me that the main problem with current state of geological POIs is that they are at the front of the queue for being counted, rather than that at the end.

I suspect that to do with procedural generation. Based on how it works, say if I was proceduraly generating an apple tree, we start with the trunk, then branches, twigs, leaves and only at the end can we decide about apples, because they depend on everything that happens leading up to this point, the very existence of apples depends on everything that happened before, let alone where on the tree they will be, and I have no control over that process because it's all done from a seed. So the queue for procedural generation of vulcanism is a fixed part of the entire process, you can't stop it and add a step for bio in there because bio is essentially part of the galaxy seed, which is why it comes up so quickly when only bio is present on a body, and that can only be done after the body is fully generated, which includes vulcansim, never before.

 

[Rokkotaco]

I'm so down to help with the thargoid testing. I've already got a bucket of testing to do for AXI anyway.

 

[Soron Silin]

I don't think the FSS needs any changes. What needs to be changed is the System Map.

The scanning doesn't stop when you move the FSS cursor off a body. You can go back to it 30 seconds later and see the results. So you actually only have to wait for the last one to scan.

But that's still painful, and you have to remember where they all were so you can check back on them, which is also a pain.

So what about a couple of new flags on the system map. One global flag says that scanning is still active. And one on each planet icon that says that there are POIs on the planet. Then add the POIs to the textual data.

Or we could have the new FSS, which would give us an indication that POIs were possible, and then the System Map gives the exact numbers when the surface generation is complete.

 

[Morbad]

With regard to scan times, decoupling the scan (and mouse sensitivity) from frame rate should have been done before the feature was launched.

I can't remember the last time a scan too more than four or five seconds to complete...because I get ~300 fps in the FSS. I can understand it being dependent on client performance, but capping one's frame rate should not alter this.

 

[varonica]

With regard to scan times, decoupling the scan (and mouse sensitivity) from frame rate should have been done before the feature was launched.

I can't remember the last time a scan too more than four or five seconds to complete...because I get ~300 fps in the FSS. I can understand it being dependent on client performance, but capping one's frame rate should not alter this.

As I explained earlier, capping the frame rate reduces the performance of the video card, and since it's the video card that is generating the body this will take longer for the body to get to the point it will be able to show the sites. Honestly displaying the Geo locations on the body probably takes a fraction of second, if that, most of the time we are sitting there watching the spinning circle is taken up with the vid card generating the body from the seed, then at the very end it does the geo sites. Because the geo sites are part of the procedural generation of the body this has to happen in that order, you can't place objects on the surface until the surface is generated as part of the procedural body generation.

So capping the frame rate alters it not because the frame rate is capped, that has nothing to do with it, it's just a correlation, the extended time has to do with the video card performing below it's maximum performance capability.

 

[Crimson Kaim]

Great response
I'd prefer that everything be unlocked for 'pennies' for the beta just to allow some luxury in choice to doing things I'd normally work my around to... The 3.3 beta last year, while removing 'restrictions' e.g. rank, still had everything 'full price' which was a disadvantage for 'poorer' players.
Both my CMDRs are low credits at the time of the snapshot (not improved much since, but do have Prismatics ) so it will be an 'interesting' beta for me

Even with alotta credits, nO amount of money can buy you the trip to crystalline clusters or spawn a NHSS to fight a tharg. The tools for testing are simply not unlocked for beta testers and I so do not understand why. SeeI will be testing the bugs that I feel affect me and leave out the others because the effort is too high and the time window for the beta too small. The result, I will fast test the targeted bugs (especially netcode) as much as I can without going into detailed tests and do the detailing part in the live version.

 

[Morbad]

As I explained earlier, capping the frame rate reduces the performance of the video card, and since it's the video card that is generating the body this will take longer for the body to get to the point it will be able to show the sites.

Capping frame rate doesn't reduce performance of the video card, unless the card falls to a lower power state (and this is absolutely not the case on my setup).

Capping frame rate reduces load on the video card, which, if anything, should free up more compute resources for generating such bodies.

Frontier has a lot of stuff tied to the renderer that should not be. Plenty of titles have wholly decoupled frame rate from other game mechanisms.

So capping the frame rate alters it not because the frame rate is capped, that has nothing to do with it, it's just a correlation, the extended time has to do with the video card performing below it's maximum performance capability.

I can demonstrate otherwise.

 

[yianniv]

Hello,

The numerical probability for each term is an approximation based on these percentages.

Very Likely = > 90%
Likely = 60-90%
Unlikely = < 60%

Hopefully this will help with testing!

This change is for the worst. Please revert it before the beta. I'd prefer (I daren't say "we") instant info on whether the planet contains bio or geo sites (we know it does because of the delay) and add the info in the locations panel so that we don't have to remember the interesting planets/bodies. The latter has been already suggested by other players in previous pages.

I apologise for insisting, but I cannot stress enough how bad I feel about this proposed change. It takes exploration many steps backwards.

I hope you reconsider.

 

[Chong-su]

Do you also fix the interception by the NPCs at the exit of the supercruise when they stop in front of the player causing damage? Because actually is not resolved yet.

Thank you

 

[Six6VI]

Even with alotta credits, nO amount of money can buy you the trip to crystalline clusters or spawn a NHSS to fight a tharg. The tools for testing are simply not unlocked for beta testers and I so do not understand why. SeeI will be testing the bugs that I feel affect me and leave out the others because the effort is too high and the time window for the beta too small. The result, I will fast test the targeted bugs (especially netcode) as much as I can without going into detailed tests and do the detailing part in the live version.

Just test the activities and favourite bugs you already notice, since you already notice enough to notice if they've been fixed or not. There will be plenty of other people that are already familiar with other activities you don't normally do and are therefore unlikely to notice the difference, that they can give feedback on.

 

[varonica]

Capping frame rate doesn't reduce performance of the video card, unless the card falls to a lower power state (and this is absolutely not the case on my setup).

Yes it does.

I posted an extensive description of the process of what happens when a vid card has the frame rate capped further back in the thread. Basically capping the frame rate, eg so that it can only send 60 frames per second to the display, results in the card waiting for the frame buffers to empty before it can process the next frame, this results in the execution queue filling and the GPU sitting idle while waiting for the buffers to clear. Uncapping the frame rate results in frames being discarded when the frame buffer fills before the next refresh cycle is available, thus freeing up the execution queue so that the GPU doesn't have to sit idle waiting. It's this idle time that causes the slow down in processing when you have the frame rate capped. You are artificially reducing card performance.

Many people set the frame rate to 60fps because that reduces load and temperatures on the card, it's not doing as much work and generating as much heat. ED uses the vid card for generating the bodies, so while the card is sitting idle it's not doing this, hence the body generation taking longer for people with frame rate caps.

 

[Jukelo]

I'm more curious to see how many Awesome Sites will be missed by results in the "Unlikely" range, when people go, "eh, there's probably nothing there, like the other 200 Unlikely sites I checked". Probably be an HGE Mine or something even better, but since it was "Unlikely", and we learned after being burned 200 times before....

I don't think that's really a problem: geo POIs are not exactly hard to find, and there is a near-infinite number of planets with them in the game, so even if you miss out on half those you encounter with the new system, you'll find a new batch of them in the next star over anyway, so unless you are currently checking every single POI you encounter, the new system wont change anything as far as missed opportunities are concerned.

 

[Morbad]

Yes it does.

I posted an extensive description of the process of what happens when a vid card has the frame rate capped further back in the thread. Basically capping the frame rate, eg so that it can only send 60 frames per second to the display, results in the card waiting for the frame buffers to empty before it can process the next frame, this results in the execution queue filling and the GPU sitting idle while waiting for the buffers to clear. Uncapping the frame rate results in frames being discarded when the frame buffer fills before the next refresh cycle is available, thus freeing up the execution queue so that the GPU doesn't have to sit idle waiting. It's this idle time that causes the slow down in processing when you have the frame rate capped. You are artificially reducing card performance.

Many people set the frame rate to 60fps because that reduces load and temperatures on the card, it's not doing as much work and generating as much heat. ED uses the vid card for generating the bodies, so while the card is sitting idle it's not doing this, hence the body generation taking longer for people with frame rate caps.

You aren't describing the capping of the GPU's performance, you are describing the capping of the game's performance. These are totally different things. The GPU is not losing performance, the game just uses fewer GPU cycles.

The problem is that whatever the game is doing to generate bodies is tied to frame rate, as are things like menu animations and mouse polling rates. There is no reason this needs to be the case. The renderer could be capped at a given present interval without touching any of that stuff, but it's not and that is the whole problem.

The amount of processing needed to generate planets is minuscule compared to what's needed to render the scenes being displayed and even if a fraction of the GPUs resources were devoted to it, scans would be perceptibly instantaneous on any decent hardware. The fact that an average scan takes two or three seconds while my card is pushing out ~300 4k frames per second demonstrates how trivial these calculations are in relation to the hardware available.

I'm sure it's easier to tie these together like the game currently does, but it's not mandatory (the game's physics engine is wholly decoupled from frame rate, for example), and not good.

 

[Soron Silin]

The amount of processing needed to generate planets is minuscule compared to what's needed to render the scenes being displayed and even if a fraction of the GPUs resources were devoted to it, scans would be perceptibly instantaneous on any decent hardware. The fact that an average scan takes two or three seconds while my card is pushing out ~300 4k frames per second demonstrates how trivial these calculations are in relation to the hardware available.

Actually, it shows that generating a planet could be a thousand times harder than creating a frame of video. It can create a frame in 1/300th of a second but takes 3 seconds to make a planet. The processing required may not be minuscule.

There's a lot of detail that we don't have. We don't know what resources are dedicated to which job or whether that split could be changed. We don't know whether they depend on particular features of the GPU such as array processors which some GPUs have more of than others. We know that people with 300fps do not see the delay and that they do if they artificially cap the frame rate. I don't think we know that the majority of people with 60fps are able to uncap their frame rate and see the faster FSS.

 

[Burke]

I don't understand how anyone can agree with this, really.it's like they want to sabotage the own game.

Funny how people seem to get this impression. I think its either organised troll feed back or somebody whos opinion matters more than the average player thats driving the game in this direction. Iv said it before, its like somebody got a grudge against explorers and has been suggesting changes that are designed to ruin peoples fun. Might aswell accept that ED is all washed up at this point.

 

[Morbad]

Actually, it shows that generating a planet could be a thousand times harder than creating a frame of video. It can create a frame in 1/300th of a second but takes 3 seconds to make a planet. The processing required may not be minuscule.

It only takes three seconds to make a planet on my system because my GPU is maxed out rendering those frames to display. There is no way it's devoting the majority of it's processing time to generating that planet.

I haven't found a cut off where planet generation stops getting faster. If I turn down settings until I get six-hundred FPS in the FSS, planets scan faster still. My main system gets CPU limited around that point, but if I removed that bottleneck, I'm willing to bet scan times would fall even further. The increase isn't linear, but it's clear that hardware performance is not the limiting factor...how it's scheduled is.

There's a lot of detail that we don't have. We don't know what resources are dedicated to which job or whether that split could be changed. We don't know whether they depend on particular features of the GPU such as array processors which some GPUs have more of than others. We know that people with 300fps do not see the delay and that they do if they artificially cap the frame rate. I don't think we know that the majority of people with 60fps are able to uncap their frame rate and see the faster FSS.

There is a lot of detail we don't have.

I don't know if it's practical to uncouple render frame rate from planet generation, but I am certain it's not impossible.

I do think we know that the majority of people with 60 fps caps are able to uncap their frame rates and see faster FSS. FSS frame rates are extremely high. If you get playable frame rates inside a starport, at a RES site, or on a planet surface, you are almost certainly going to get way more than 60fps in the FSS. I run settings targeting a 60fps floor in high-demand areas. These same settings produce ~300fps in the FSS. I've run ED on a lot of configurations and this general trend is nigh universal. The FSS is a very low demand scene to render.

 

[Jethro49]

I do think we know that the majority of people with 60 fps caps are able to uncap their frame rates and see faster FSS. FSS frame rates are extremely high. If you get playable frame rates inside a starport, at a RES site, or on a planet surface, you are almost certainly going to get way more than 60fps in the FSS. I run settings targeting a 60fps floor in high-demand areas. These same settings produce ~300fps in the FSS. I've run ED on a lot of configurations and this general trend is nigh universal. The FSS is a very low demand scene to render.

Agreed... I get 120 fps in SC, between 60 and 70 on high demanding scenes (starport, planetary surface), and more than 200 in FSS. When resolving geo sites, the FPS drops every half seconds to 140 for a few 100ms (that's the cause of the stuttering if I leave the planetary view to continue scanning other bodies).