ANNOUNCEMENT January Update - Beta Announcement

[Winterwalker]

Wing Mining - Seismic Charges malfunction
Top to see this being looked at, especially as my Chief isn't able to carry shields when rigged to mining.

Having an asteroid blow up in my face went down as a genuinely entertaining industrial accident. The first time ..
Something I'll never forget; No shields, 100m, bosh .. a very near death experience!

Great to see this update happening, looking forward to it.

 

[MK Regular]

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.

This looks promising.

While I am a bit disappointed that I won't get a complete confirmation of whether or not a planet or moon has any geological sites, if this also fixes the issues I'm having when I FSS one or more planets with geological sites in quick succession (the FSS view jumps uncontrollably and rotates for no apparent reason) I will have absolutely no problems with the change. That said, part of me is curious if it would be possible to only determine the presence of geological sites rather than the number of geological sites and how it would speed up the scan time.

It's looking good so far, thanks for the info.

 

[Rubbernuke]

Maybe after a few thousand hours you just get a bit jaded.

Its one thing to be jaded, its another to be annoyed at the level of bugs in the game. FD don't fix what they make and hope no-one notices- if the underlying game features I play were robust and well maintained I'd be happy.

 

[Stigbob]

Its one thing to be jaded, its another to be annoyed at the level of bugs in the game. FD don't fix what they make and hope no-one notices- if the underlying game features I play were robust and well maintained I'd be happy.

That's not my experience of ED, Fallout 4 even now is unplayable but ED is one of the most stable least buggy games I've ever played. The worst thing that ever happened to me is just the odd disconnect I've never had a single gamebreaker in five years.

On the other hand I've never finished a Bethesda fallout game due to them always breaking in a savegame wrecking way, Skyrim too for that matter.

 

[PanPiper.]

FSS Scanner Change

The proposed solution for the FSS Scanner taking a long time potentially could make a worse user experience if the probabilities give too many false positives for bio sites. Leading to time wasted mapping bodies that have no sites.

I have been working on EDMC plugins that use the FSS journal events and have observed that the journal event is generated with a flag for volcanism almost immediately. This means that prescence of volcanism could be displayed immediately ( but not the count of sites ) Indeed the EDMC canonn plugin displays an Icon to show volcanism as soon as the scan starts and long before the scan has completed.

My proposal is that you simply do away with the count of signals on the FSS scan.

90% of the time only geological signals are present so and we know you could display the presence immediately without a count. This would massively improve scan times even if you continues the full scans for other types.

Bio sites and other sites generally scan quicker so if you simply displayed Biological without the count when the first site is resolved then I think that would be acceptable. The fact that the scan was taking longer would actually indicate that there might be something worth sticking around for and the wait would not be as annoying as it is now

This is the obvious solution, perfect.

I'm sure FD could test that even before beta to confirm it can work.

 

[Old Duck]

That's not my experience of ED, Fallout 4 even now is unplayable but ED is one of the most stable least buggy games I've ever played. The worst thing that ever happened to me is just the odd disconnect I've never had a single gamebreaker in five years.

On the other hand I've never finished a Bethesda fallout game due to them always breaking in a savegame wrecking way, Skyrim too for that matter.

Ed Lewis does not approve of this message!

 

[kofeyh]

Hi,

Have not visited forums in a long time. For fairly good reason, it seems, still. Pleased to see a more communicative and focused approach to bug fixes.

I still believe a regular PTS approach (public testing) would provide ongoing benefit, and not just brief infrequent testing, as the game has become incredibly complicated with many, many associative mechanics - changing or fixing a single aspect can have a string of ripple effects, which can take some time to test. I am sure the code reflects this.

That said, something is better than nothing, and a full, complete fix list will be vital for reliable testing. Please, please ensure that any code that has had a pass, no matter how trivial it might seem to be, is included in the final fix list. This is pretty vital.

More broadly, please consider the merit of turning discovery into hide-and-go-seek again, versus the performance aspect. The entire point of the FSS was to provide a more holistic approach to discovery and provide a method to both catalogue AND identify sites of interest. Hiding POI interest again, behind a cold, warmer, warmest mechanic is a step backwards to the time when commanders had to read the galactic tea leaves to locate POI.

If this is an approach where there is initial feedback in terms of probability, whilst the game processes the locations in the BACKGROUND still, so they are correctly identified but aren't impacting the UI, then this would allow the FSS to be a bit more performant and maintain it's designed purpose, ie to correctly identify candidate planets.

My understanding is the journal pretty much immediately records if stellar bodies have POI, however there is considerable processing required to delineate what that equates to.

Feeding the results to the system map is a long-standing request; as going back and forth to the FSS will lead to more than anything else. Since the initial flag is quick, the UI should update quickly. If we can have some surity of yes/ no then fed to the system map, we can better interact with it, and this then becomes more consistent with the fixed locations behaviour ala named settlements, thargoids, etc.

Locating the precise coordinates of a POI still requires the use of a scanner at close range; having us trapse across systems to scan a body based on a "maybe" probabilty scale is not a very good reversion - it sounds fun in theory but it never was.

Having a system that can give you a no, probably, definitely outcome quickly, with a backgrounded method to turn that into a binary yes/ no would provide a more fluid, usable. Hide and go seek in a multi billion system game does not work in practice; this is already very well understood.

Seeing some concerted effort to bugfix is welcomed and may encourage my return. But I have been promised this before, so please excuse any brusque tone that might be apparent as we have been down this road before.

I look forward to the complete patch notes. Thanks for the focus on some very long standing and horrendously impactful bugs that have caused quite a few of us to take a step back from the game.

 

[Sysmon]

• 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.

Superb idea. But 'Unlikely', 'Likely' or 'Very Likely' based on what? Since we are looking at a spectrograph anyway, I'd assume it would be hints of gas pockets at the planetary surfaces. Maybe there could also be a comment about what had been detected? Nitrogen, carbon dioxide, heterogeneity in heat signature, ...

S

 

[DaftMav]

This approximation will help to identify the likeliness of the geological/biological site, but for a full confirmation, you will have to get closer to the planetary body and scan it using planetary probes. We would love to hear your feedback on it to determine whether or not it is better than the current process.

I really dislike the idea of getting a "maybe" and then still having to fly over to these planets to be sure. The whole point of the exploration changes FDev did was to make scanning a system much faster and less tedious. Now we're going backwards again? Might be fine if it would still resolve into a definite yes or no after a while though, so if you get a "likely" you could choose to wait a bit longer (or like Wargrum's suggestion below, that it would show definite results in the navpanel so we can just keep scanning and check that afterwards).

Also it seems only the geological sites were the type that would cause long scans, so with the technical explanation in the top post as to why it occurs, I'm not sure why if a planet has just biological it DOES work fast? Regardless I don't think many people care that much about an exact number of sites, but we do want a clear 'present' or 'not present' indication. None of this "maybe?" and then require us to still supercruise over to these bodies to do a probe scan.

none of the data it discovers gets transferred to our other navigation systems. I'll be honest - I hate using the FSS. Its by far the worst GUI you have added to the game so far in my opinion. Once I've scanned a system I don't want to have to jump back into it again.

I want prospective finds to be shown on my system map and in my navigation panel. At the moment that does not happen until we surface map a planet. If I forget which moon I want to check next, I have to go trawling through the damn FSS again looking for it, because that information has not been added to the other navigation systems.

This. Why not let geo/bio sites resolve in the background as we continue to scan the system and then also show this info on the nav panel? FDev added a bunch of icons there but not for geo/bio etc.

 

[Azmuth Divarchchron]

the invincible heart sounds like it should be a band/album name

 

[avow555]

Should never have dropped the betas anyway.
Not the most impressive list but a start I suppose.

May login for some testing but not before, unless they drop some new kit or ships.

 

[m0rl0ck]

Whoohoo!!!

Love betas
Sounds like fun and a step in the right direction.

 

[kofeyh]

Superb idea. But 'Unlikely', 'Likely' or 'Very Likely' based on what?

Ideally the game won't generate confusion on this, again. Either POI exist, or they don't. This is a binary yes/ no for the candidate planet. The game's procedural code either adds this meta data to the planetaty body, or it doesn't. The journal already records this yes/ no flag as it is. The delay is in determination of the type and how many.

What they are, is a fuether clarification of the end result, and thus something that can be presented as meaningful data in the system map and associated system list in the ship HUD.

I'm a little less concerned of the type, I am more concerned the developer is attempting to resolve a process intensive issue, by using an indicative scale that presumably is procedurally less complex, rather than actually solving why it takes so long for the game to procedurally generate the POI type.

Arguably, if we no longer actually know if a POI is actually there at all, what it is, suddenly becomes a much lower order concern. A bit if a tasty burger exists or not, or whether it has pickles, and how many pickles there are. The reliable determination of the burger existing in the first place, is probably more useful. Once it exists, then the issue of the pickles can be dealt with.

Anyway, I shall depart again. Fixes good. Communication good. Ideally FSS poi lag can be solved without going back to playing "where's Wally?" all over again as that was, literally, one of the primary reasons for the discovery overhaul in the first place.

POI count and type and related meta such as composition sounds like an ideal use of the DSS. Wether they exist or not, shouldn't even be a question I have to interpret. The FSS should tell me.

 

[Graabeerd]

As an Explorer myself I find that while in FSS, I miss seeing that there are Geo/Bio sites on a planet/moon while resolving a whole system. It would be nice if there was a tab or indication that there is something on the same without having to rescan the whole system again. It's no telling how much I have missed because of crucial information was overlooked, I found this out the hard way recently and slowed down and wait for the scan to complete and note the location of the sites and ressults.

 

[Joey2o15]

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.

And we get...

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.

Yeah that's real game breaking stuff right there.....

 

[Sysmon]

Ideally the game won't generate confusion on this, again. Either POI exist, or they don't. This is a binary yes/ no for the candidate planet.

What they are, is a fuether clarification of the end result, and thus something that can be presented as meaningful data in the system map and associated system list in the ship HUD.

I'm a little less concerned of the type, I am more concerned the developer is attempting to resolve a process intensive issue, by using an indicative scale that presumably is procedurally less complex, rather than actually solving why it takes so long for the game to procedurally generate the POI type.

Arguably, if we no longer actually know if a POI is actually there at all, what it is, suddenly becomes a much lower order concern. A bit if a tasty burger exists or not, or whether it has pickles. The reliable determination of the burger existing in the first place, is probably more useful. Once it exists, then the issue of the pickles can be dealt with.

Anyway, I shall depart again. Fixes good. Communication good.

A geo PoI is a little cluster of dimples on a relatively large planetary body. If the FSS is a dimple detector, it must involve some sort of space magic especially when detecting dimples on the opposite side of planets. I find it much more likely that the scanner detects exhaust from vents (and from the bio PoIs too!) which would leave odd pools of light elements combined with hydrogen and oxygen in areas where they would not otherwise be found if there was nothing to generate them. So why not add a tool that specifically looks for these elements? It would be the tool detecting and defining atmosphere compositions - it would just help raise a flag when a atmosphere-free planet shows local signs of gas presence.

S

 

[Scubadog]

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!

So, where do Windows Mixed Reality headsets fall? I've had no issues with my WMR headset (specifically, an Acer rig) in ED via SteamVR. Does this mean they'll eventually not function?

 

[xondk]

I gather the bug regarding navigation panel body information panel, showing "mapping" incorrectly, will still be left unfixed?
It is currently shows if the planet is landable, rather then as it states, if or if not you've mapped it.
Its been reported repeatedly, unfortunately rather spread out.

It is....rather frustrating that this has not been fixed yet, and is overlooked, probably since it mainly affects few explorers, but it would do wonders not forcing people to use system map to check mapped status.

 

[CMDR Karrde Sun]

In before white knights start bashing around that 11 fixed bugs is the second coming. I don't think i care anymore.

ps. Yes removing the tallies of the fss makes alot of sense. You don't need to make it any more complicated. Instead, why not sneak in bug 12? Lucky us?

 

[kofeyh]

A geo PoI is a little cluster of dimples on a relatively large planetary body. If the FSS is a dimple detector, it must involve some sort of space magic especially when detecting dimples on the opposite side of planets. I find it much more likely that the scanner detects exhaust from vents (and from the bio PoIs too!) which would leave odd pools of light elements combined with hydrogen and oxygen in areas where they would not otherwise be found if there was nothing to generate them. So why not add a tool that specifically looks for these elements? It would be the tool detecting and defining atmosphere compositions - it would just help raise a flag when a atmosphere-free planet shows local signs of gas presence.

S

Because the purpose of bug fixing is to fix bugs, not overhaul mechanics into an entirely new system - this is how we end up needing fixes because people hijack a fix process with endless feature requests.

FSS exists now in part to define if a planet as POI. The issue is the time it takes to identify POI type. So let's have that solved.

I am less interested in head canon for how the FSS actually works? Just that it actually works, and identifies if something exists or not. Something existing should not be an existential thought experiment as far as the game is concerned. The POI exist, or do not. How many, coordinates and type is the process impacting performance. Making that a lucky dip process doesnt solve the problem. It's just, ostensibly, hiding it.

I just want the FSS to identify if POI exist, or not, on a body that might be 800,000 ls away. What they are, how they might have formed or other more scientific concerns, I'll leave to the game to present in a meaningful way, as a feature improvement.

Let's have the underlying issue fixed, first, yeah?