Patch Notes Update 2.1.04 update incoming

Hey guys,

We have a small update coming for PC and Xbox One players. Specifically to address a number of fixes and stability issues. Servers will be down from 12noon BST for about 30- 45 mins.

Broadcast messages should have already started

Patch notes

Stability Fixes
Fixes for crashes when Hyperspace jumping
Fix for crash when entering Supercruise from a Conflict Zone
(Xbox) Fix for title entering unresponsive state after disconnecting the WAN Network cable
(Xbox) Fix for title crash from launch

General Fixes
(Xbox) Fix for loss of Horizons access after launching from Engineer Base
Fix for Docking Computer and NPC’s drifting off target landing pad
Various text updates

that is all? [uhh]
 
One word STORAGE, where and when is any storage coming for engineer commodities, (or any system to change this) thankful for the DC fix though.
 

Ian Phillips

Volunteer Moderator
you assume moderators of this forum have to show when they edit a post ? just because us plebs do ?

Having to provide an Editing reason when changing a post is an automatic forum function - whoever does it. It has to be done otherwise the post cannot be edited.

This means that if there is no editing reason, - the post has not been edited.
 
Last edited:
Two Questions for FDEV then:
1 - if Limpets are cargo why can't we transfer them ?
2 - if they are not cargo why do they occupy cargo space and mass ?

It says that "Drones can not be transfered" or something similar when I tried it. But yes... I agree with you... it is weird that limpets (drones) can't be transfered. A good explanation from the devs to why this is the case would be most welcome.
 
Allow me to elucidate you. Don't worry, its not as pervy as it sounds!

Here are the steps (assuming FD follow a fairly standard practice):

1) Problem is identified by playerbase or QA. Ok, that was on day 1.
2) QA log the issue in JIRA or whatever they are using, and pass to the dev team.
3) PM (probably) takes a look at his available devs, priority of the issue, and assigns it to a dev.
4) Unless its uber level hotfix critical, probably goes into his pile of jobs to do for the week. Probably being told it needs to be solved if possible by the next patch.
5) When they get the chance, they look at the issue, and try and identify the problem. This can vary depending on the complexity of the problem. They might get it in 5 minutes, it could take hours.
6) Dev informs PM their estimate for duration of the fix. If fix is going to take many hours, the PM might decide to escalate to his manager to ask whether a fix should be produced as a priority or not considering the estimate. However, let's assume the fix takes no more than an hour.
7) Dev produces fix and tests it themselves on their local build (possibly)
8) Submit the bug fix to the testing build for QA to test.
9) QA tests. Reports back whether it worked or not. If not, we got back to step 5 or thereabouts. If it works...
10) Fix is submitted to the release branch.
11) Build manager accepts patch, along with other patches being submitted for the next patch.
12) Await higher management give green light for release of next patch.
13) Patch is released.

There you go, it might not work exactly like that in FD, but its pretty typical.


Now try to think of all the so called bugs that you know of, multiply that by 3 and you will have a close estimate of what is going on in the dev department, and Yes using a Software like JIRA and this kind of workflow is necessary to make a project this big stable, so if by any chance the player base expectations are not met, something or more than one thing was skipped on this workflow !!!
 
Allow me to elucidate you. Don't worry, its not as pervy as it sounds!

Here are the steps (assuming FD follow a fairly standard practice):

1) Problem is identified by playerbase or QA. Ok, that was on day 1.
2) QA log the issue in JIRA or whatever they are using, and pass to the dev team.
3) PM (probably) takes a look at his available devs, priority of the issue, and assigns it to a dev.
4) Unless its uber level hotfix critical, probably goes into his pile of jobs to do for the week. Probably being told it needs to be solved if possible by the next patch.
5) When they get the chance, they look at the issue, and try and identify the problem. This can vary depending on the complexity of the problem. They might get it in 5 minutes, it could take hours.
6) Dev informs PM their estimate for duration of the fix. If fix is going to take many hours, the PM might decide to escalate to his manager to ask whether a fix should be produced as a priority or not considering the estimate. However, let's assume the fix takes no more than an hour.
7) Dev produces fix and tests it themselves on their local build (possibly)
8) Submit the bug fix to the testing build for QA to test.
9) QA tests. Reports back whether it worked or not. If not, we got back to step 5 or thereabouts. If it works...
10) Fix is submitted to the release branch.
11) Build manager accepts patch, along with other patches being submitted for the next patch.
12) Await higher management give green light for release of next patch.
13) Patch is released.

There you go, it might not work exactly like that in FD, but its pretty typical.
So glad to see this write up on the development process. There are additional steps when dealing with Microsoft for an Xbox patch as well, not to mention getting the patch ready on Steam and out to distribution points for the launcher, and testing to make sure the final patch is ready and still fixes the issues it's reported to fix. So really there's probably 4-5 more steps beyond this that happen.
 
What about fire at will turret bugs?

Yes, this needs a fix ASAP - I'm sure I've seen a bug report somewhere about it, so they'll be on it - I'll double check and submit one if I can't find it.
Just to clarify, the issue is that the setting for turreted weapons always reverts to FaW when entering/leaving SC, so if you are interdicted or drop into a CZ (or anything else really) you have to switch to the right hand panel, switch to the correct tab, then check & change the setting before you can engage the enemy.
 
Last edited:
they always have, but now they only do, and that is the problem !!!

You can change it but they reset to kill will every time you enter SC or HC .I've got into the habit of looking at my functions panel and switching it back as soon as I'm in normally space it's not ideal but also not game breaking.

Thanks Gary and agony aunt for the info.
 
Last edited:
Yes, this needs a fix ASAP - I'm sure I've seen a bug report somewhere about it, so they but be on it - I'll double check and submit one if I can't find it.
Just to clarify, the issue is that the setting for turreted weapons always reverts to FaW when entering/leaving SC, so if you are interdicted or drop into a CZ (or anything else really) you have to switch to the right hand panel, switch to the correct tab, then check & change the setting before you can engage the enemy.

There's a Bug report on the Xbox bug reports on this one, not sure if there's anything on the PC side though
 
Back
Top Bottom