A careful workflow for distinguishing patch changes from save problems and using Breathedge 2's built-in report tool.
Preserve the evidence before experimenting
When a save behaves differently after an update, resist making a long chain of changes immediately. Note the installed version, the last action before the problem and whether the issue happens every time. Keep the affected save where possible before testing another state. This does not require guessing the game's save-file path or editing files you do not understand.
The goal is to preserve a clear before-and-after account. If you change controls, move objects, repeat quests and overwrite progress before recording anything, it becomes difficult to tell which step affected the outcome. A controlled test changes one condition at a time. That helps you recover when a simple fix exists and gives support a coherent case when it does not.
Read the patch's actual scope
A patch saying that one save-related bug was fixed does not mean every reported load problem has the same cause. Version 0.8.7 addresses a particular shuttle-flight save timing issue and a depot yoke problem. The developers also mention reports of falling through the world after an update, but say the submitted saves they examined loaded correctly for them. That is an unresolved diagnostic situation, not a universal fix or proof that players imagined the symptom.
If your case resembles a listed issue, first confirm the update finished and then test the relevant interaction once. Describe the result precisely. If it differs from the note, that difference is useful evidence. Avoid a blanket conclusion such as 'all old saves are broken' from one occurrence, or 'all saves are safe' because one test succeeded. Early Access support works better when reports preserve their actual scope.
Distinguish a changed rule from a broken quest
Some problems disappear once the current rule is understood. The taxi letters are deliberately spread over a 20-meter radius rather than the demo's pile. Certain dismantling interactions now require the Twister. The hatch can accept a battery collected elsewhere after 0.8.6. A guide built around the earlier behavior may make a working quest look broken.
Before reporting, read the current objective and prompt. Compare them with the recent official notes, then perform the interaction that the current build requests. If it advances, update your personal notes so you do not repeat the old assumption. If it fails, your report can say that you checked the relevant change and still reproduced the issue. That removes ambiguity without forcing you to troubleshoot the entire game yourself.
Use the in-game report tool
The launch announcement describes a built-in reporting route: press Esc, choose Report Bug and write the problem. A toggle at the bottom can attach a save. The developer also asks for optional contact details when follow-up may be helpful. Share only what you are comfortable providing, and keep unrelated personal information out of the description.
A useful report has four parts in ordinary language: where you are, what you did, what you expected and what happened instead. Add whether the result repeats. For example, identify the quest stage and the object involved rather than saying 'mission broken.' If you attach a save, explain what the developer should do immediately after loading it. That turns an attachment from a large mystery into a practical test case.
Keep hardware symptoms separate from progression symptoms
The launch hotfixes include input and display problems as well as quest issues. Version 0.8.6 addresses a controller mode lock and a missing cursor associated with connected wheels, pedals or yokes. Version 0.8.7 corrects 5120 by 1440 resolution reverting to a lower ultrawide mode. If your problem concerns input or display, include the relevant device and resolution rather than burying it in a quest narrative.
For a clean comparison, note which peripherals were connected and whether the symptom appears in menus, gameplay or both. If you temporarily disconnect an optional device to test, record that as a test result rather than announcing it as a guaranteed fix. The AZERTY issue was still acknowledged in the 0.8.5 notes; none of the later notes retrieved for this guide explicitly declares it fixed. Do not assume an unrelated controller fix resolves keyboard layout behavior.
Return to playing after one useful test
Troubleshooting can consume more time than the original problem. Once you have confirmed a reproducible issue, preserved the relevant state and submitted a concise report if desired, stop repeating the same failed action. Continue from another usable save or pause that objective if the game allows it. If no safe continuation exists, keep the evidence for a later update instead of overwriting it in frustration.
When a new patch arrives, read for your specific symptom and test the smallest relevant sequence. Update your notes with the result. This is a manageable way to participate in Early Access: you keep your own progress understandable, avoid unsupported promises about save compatibility and provide feedback that can actually lead to a fix.
Build a report that can be read in one pass
Use a short structure: version and device, location or quest, steps, expected result, actual result and repeatability. Put the failure near the beginning. A reader should not have to work through a full session diary to discover that the hatch interaction never advances. Add background only when it changes the reproduction, such as having collected the battery before reaching the objective.
A sample structure is: 'On the current build, I loaded the attached save at this objective. I approached the named object and used the displayed interaction. I expected the stage to advance, but the prompt remained unchanged. It happens again after reloading the same save.' Replace every placeholder with your observation. Do not claim repeatability unless you tested it. This format is useful because it identifies a start state and an action, letting someone else assess the same behavior without guessing what you did.
Describe what the attached save contains
An attached save is more useful with a sentence explaining where it starts and how close it is to the failure. Say whether it is before the action, immediately after the issue or an older comparison point. If the relevant object is not in view, give a nearby landmark. The developer should not have to solve the quest from scratch just to find the situation you meant to report.
If you have several saves, choose the one that best preserves the reproduction rather than automatically attaching the newest. A newer save may already be past the important trigger. Keep the other states available if support asks, but avoid sending a confusing collection without labels. This guide does not give an unverified filesystem path or tell you to edit a save. Use the reporting mechanism the game provides and describe the state in ordinary gameplay terms.
Distinguish missing progress from changed progress
Missing progress means the loaded state is earlier than you expected or lacks an action you remember completing. Changed progress means the same stage now behaves differently under a new build. Begin by identifying which you observe. Check the save you selected and your recent play history before assuming the update rewrote the quest.
If you use more than one computer, mention which device last held the desired progress. A synchronization issue can produce an older state without any in-game quest failure. Conversely, the correct recent state can load and still contain a progression bug. Keeping those branches separate helps you seek the right support. Do not select an overwrite or repeatedly save over the state while still deciding which copy is relevant. Establish the timeline first, then test the gameplay behavior on the copy you intended to load.
Compare one change at a time after an update
When a new patch arrives, complete the ordinary update process and retest the relevant action before applying unrelated workarounds. If you also change several graphics settings, unplug devices and load an older save, a successful result becomes hard to interpret. A clean comparison asks whether the update alone changed the symptom under the same conditions.
If the symptom remains, then choose the next test based on its type. Input problems deserve an input comparison; a missing installed asset may justify file verification; a quest trigger deserves a saved-state reproduction. Write down the result and stop repeating a test that gives no new information. This keeps troubleshooting proportional. You can provide useful evidence without spending hours testing every possibility or pretending that a single successful attempt proves the whole class of problems is resolved.
Include hardware details only when they matter
For a display issue, the resolution, display mode and graphics hardware can be relevant. For a controller issue, the device and other connected peripherals matter. For a particular quest interaction that behaves consistently, a long hardware inventory may be less useful than the quest stage and save. Tailor the report to the symptom rather than copying an enormous generic diagnostic template.
If support requests more detail, provide it then. In the first report, keep the information readable and avoid including account credentials, unrelated personal files or a full desktop capture with private content. A helpful report does not need sensitive information. Precise gameplay steps, the build and a relevant save usually establish a better starting point than speculative system details. The purpose is to make the next diagnostic question easier, not to overwhelm the recipient with everything you can find about the computer.
Report balance feedback differently from a malfunction
A mechanic can function as intended and still feel unpleasant. If your concern is that survival drains too quickly or an interaction takes too long, describe the experience as feedback unless you have evidence of a malfunction. Include the difficulty, the activity and what result you wanted. That helps the team distinguish a tuning request from a broken trigger.
For example, explain that repeated returns interrupt reading or exploration on your current setting, rather than asserting that the meter is bugged because you dislike the pace. If you believe the meter behaves inconsistently, describe a comparable test that shows the difference. Clear feedback can influence design without being mislabeled as a technical fault. It also helps other players offer relevant advice: a difficulty change may address an experience preference, while it will not necessarily repair a quest that fails to register an action.
Keep follow-up messages tied to the original case
If you later discover a more reliable reproduction, update the same report channel where practical and identify the new detail. Say what changed: a particular object arrangement, an earlier save or a different input state. Avoid sending the same vague complaint repeatedly without additional evidence. One coherent case is easier to follow than several disconnected accounts that appear to describe unrelated problems.
If the issue disappears, mention the build and action that now work. Do not erase the distinction between a confirmed fix and a symptom you can no longer reproduce. Both are useful outcomes, but they mean different things. If you are comfortable providing optional contact details, make them relevant to follow-up and keep them out of public posts when unnecessary. The aim is to help resolve the case while keeping your communication and personal information under your control.
Maintain a small recovery record for long breaks
Before leaving an Early Access run for a while, note the current version, active objective and why you stopped. Mention any unresolved issue and the report you sent. On returning months later, this record can save you from mistaking a forgotten task for a new bug or repeating a workaround that a patch made unnecessary.
Read the current notes for the affected system, then test the narrow issue once. If it works, continue the run and retire the old workaround. If it does not, your earlier record provides context for a renewed report. This is a manageable continuity habit, especially when the game is expected to gain major content over time. You retain a clear account of your own progress without assuming that every future update will preserve every state or require starting over.
Close the loop when the problem is resolved
When the relevant action works again, update your personal record with the version and the result. Remove any temporary workaround from your routine unless it still serves a clear purpose. Continuing to apply old fixes after the underlying issue changes can create fresh confusion, especially if they alter controls or the order of actions.
If you posted a public request for help, a short factual follow-up can help the next player: identify the patch or changed condition and say what now works. Avoid declaring every related problem solved. A narrowly accurate resolution is more useful than a sweeping claim, and it preserves the distinction between your tested case and issues that other players may still be investigating.
Sources & verification
This article combines cited facts with practical editorial advice. Follow the version and uncertainty notes before applying an older route.
