ANNOUNCEMENT January Update - Beta Announcement

The worst part is it reinforces design by tantrum.

I know anything beyond taking off and landing is heresy to some, but the tracker does not highlight large problems that are endemic in ED now.

September ruined ED for me, so I'm actually looking forward to seeing if this update fixes these problems- but I'm sad that FD allowed this to happen in the first place, this update is running to stand still.
 
September ruined ED for me, so I'm actually looking forward to seeing if this update fixes these problems- but I'm sad that FD allowed this to happen in the first place, this update is running to stand still.
Me too, and my FOV-pop Max Headroom stutter bug is not in the list to get fixed anytime soon, so I continue to play other games instead of ED. I may still try the beta just to see if FOV-pop has been fixed "accidentally".

 
As an explorer I'm delighted you guys are looking into improving the FSS delay, 20-30 seconds isn't an eternity but when there's 40, 50 or 60+ bodies in a system it certainly can feel like it. Thanks guys

The proposed solution doesn't improve the delay. It just doesn't perform the scan.

Washing the dishes goes much, much faster if I don't wash the dishes; sweeping the floor goes much, much faster if I don't sweep the floor. But then my dishes haven't been washed and my floor hasn't been swept. So that's not a very effective solution to any problem that I have.

I hate the long surface scan times at least as much as anybody else - yesterday I scanned a system with 99 bodies in it (!). But I do want the surface scan data. So speeding things up by not giving me the data is a lot like leaving me with a sink full of dishes and a regrettable floor.
 
This may have been mentioned higher in the thread, but it would be nice if FDev reopened the investigation into SLF lag.

FDev says they fixed it by removing the ability to spam commands. But a lot of players claim it still makes lag... even game breaking.

I use the SLF extensively and have been around many other players with SLFs. Usually I see no lag at all. And in the few times I’ve experienced lag I never saw any evidence definitively incriminating the SLF (as opposed to normal networking issues.)

It would be great to play without being accused of “cheating” in PVP :(
 
The proposed solution doesn't improve the delay. It just doesn't perform the scan.

Washing the dishes goes much, much faster if I don't wash the dishes; sweeping the floor goes much, much faster if I don't sweep the floor. But then my dishes haven't been washed and my floor hasn't been swept. So that's not a very effective solution to any problem that I have.

I hate the long surface scan times at least as much as anybody else - yesterday I scanned a system with 99 bodies in it (!). But I do want the surface scan data. So speeding things up by not giving me the data is a lot like leaving me with a sink full of dishes and a regrettable floor.

Yes the reasons for implementing it is due to the fact that it takes too long as it is now.... but putting more of the discovery on what is on a planets surface onto the detailed surface scanner just makes more sense imo.
the advanced system scanner or what ever it is called now gives us details about major planetary body features and DSS is for stuff on top.

Does this not seem a better fit to you? Further more, because using the DSS is itsself a more hands on process which takes a little bit longer, the generation of the surface features can be obfuscated.
 

Deleted member 38366

D
I hate the long surface scan times at least as much as anybody else - yesterday I scanned a system with 99 bodies in it (!). But I do want the surface scan data. So speeding things up by not giving me the data is a lot like leaving me with a sink full of dishes and a regrettable floor.

I'm with you on that.

My suggestion on this issue would be to simply
  • untie the process from framerate and
  • make it an own, separate (if feasible multithreaded) process that always runs at optimal possible speed

That way the delay would be minimized to a perfectly acceptable duration on most machines while still yielding the precise data - which I appreciate.
(nonwithstanding that any Planet with indicated Volcanism can still unexpectedly end up resolving as "None" on the Geologicals)
 

Stephen Benedetti

Community Manager
Important question regarding the "missing repair deliveries" bugfix:
Will goods delivered in the beta affect live server totals?

Hi @CMDR That Other Guy27,
As some of the commanders have stated, anything that happens in the beta, stays in the beta! So anything you do will not be applied to the live game.

Are players going to receive Beta Tester decal for participating?
Hello @rootsrat
Unfortunately, there will be no decal issued for this beta, but this is something we're could look at introducing in the future.

Hello Stephen,
have you considered to include a soft female German voice into Covas for the January update?
Hi @Henoch
We have an amazing audio department filled with talented audio specialists. They are really good at deciding what voice to use, so it is up to them! We've passed your suggestion on, though.

Will this be the only Beta test period for the January update or are you guys planning a follow up beta test period to see if the issues detected during the first beta period are fixed before you launch the final update in January?
Hi @Crazy Joe
This is the only beta testing period that we will be doing for the January Update at the current time. If we feel we need more testing for this update, we will be sure to let you know as soon as possible.

Are you saying that there will be no way to know for sure if there are geo sites without visiting?
Are this new method will be inserted INSTEAD of old system, or sites will be shown in FSS after some time?

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.

Additional note:

We have been reviewing your feedback, and we wanted to let you know that if anyone feels that we are not prioritising their particular issues, please up-vote them on the Issue Tracker. This will bring up their priority on the Issue Tracker for future fixes. As we mentioned in the OP, we've worked internally with Customer Support, QA and Development teams, alongside the feedback you shared with us here and via the Issue Tracker, to identify which issues we'll be tackling in the January Update, which we've detailed below.

Remember, this is not the full list of issues we are addressing and will present these next week in the Patch Notes.

Edit: Updated clarification on geological/biological FSS comment.
 
Last edited:
My suggestion on this issue would be to simply
  • untie the process from framerate and
  • make it an own, separate (if feasible multithreaded) process that always runs at optimal possible speed

In my own experience there's little (if any) effect of framerate on the scan speed. I've disabled VSYNC and the scan times are still very long.

If the scan is not already a separate multithreaded process I would be very surprised.
 
Yes the reasons for implementing it is due to the fact that it takes too long as it is now.... but putting more of the discovery on what is on a planets surface onto the detailed surface scanner just makes more sense imo.

I'm sure I'm in a minority on this, but in the kind of exploration I do I have very little interest in celestial bodies. I'm exclusively interested in the things you find on and around them. So, for me, a "there might be something here" scan is redundant: I already know! Having to map every body to really find out if there are surface locations would be slower and even more frustrating than the long FSS scans.
 
Top Bottom