TO ALL THE FOUNDERS!

Thank you for taking the time to help out in the Founder Testing! Below you are going to find a guide on how to properly create a bug report! The guide provided is very important to follow as this will make it much easier for QA and Developers to, not only better understand the issues you are reporting, but to also help make sure all the proper information is being provided.

Before this guide starts, please make sure you are providing bugs that are related to the current type of Founder Testing that is being performed. As well as ABR – Always Be Recording. This will help you in making sure you are capturing the issues you would like to report on.

To begin, I have some helpful tips and requirements for you

It is HIGHLY recommended that you either have OBS (Open Broadcast Software), Nvidia Shadowplay, or Windows Gamebar configured to capture media, such as Pictures/Screenshots, and videos. MEDIA IS REQUIRED ON ALL BUG REPORTS as it is one of the most crucial parts of a bug report, as they give visual aid to the issue/bug that is being described.

If your media does not fit within the file size requirements for Discord, please fill out the form below to make sure you provide the media to the proper bug.

On the Form you will provide the link to your Discord Bug Report, State what type of bug it is, and then upload your media with the form.

DEADROP Founder Testing Bugs – Large File Submission Form

Game logs will also be required for all bug reports.
PLEASE MAKE SURE TO CLOSE YOUR GAME BEFORE GRABBING YOUR LOGS
These can be found by executing WIN + R and put %localappdata%

Find the Moon Folder
Once in the folder, Select Moon > Saved > Logs.
Moon.log is gonna be the Log you want

if you HAVE launched your game again, the logs will be named similar to this “Moon-backup-2024.07.10-17.51.35”
To make sure you grab the proper log, sort the items by “Date Modified” and grab the latest one before Moon.log
Logs from Crashes will automatically be uploaded to ADT
Please try and be as accurate as possible when providing logs

Please make sure to include the proper Tags that represent your bug when creating your Discord Bug Report.
You will not be able to complete a Discord Bug Report unless you select a Tag

HOW TO HELP US WITH YOUR BUGS

When writing bugs, there is a basic format that you must follow to make sure all the relevant information is provided to help the Developers understand, and fix the issue quicker. Below is a default format for you to copy and paste to use. Please make sure to follow the guide to understand what each part of the formatting you need to follow in the bug report.

Bug Format – Copy/Paste

Your Title will be the name of your Post
[DESCRIPTION]
[REPRO RATE]
/ %
[REPRO STEPS]

Launch public-test *CL ?????
*CL = Changelist. The CL number is what we use to identify and sort our builds.

TITLES

The first thing is to provide a clear and concise Title. In a lot of different QA studios, you’ll hear of the term; PAL Format. PAL stands for Problem, Action, Location. This format helps us structure bug titles so that a Developer can look at a title and understand what the bug is about.
An example of a bug title would be:

Player loses the ability to fire their weapon when walking into the hideout” ^{No this is not a real bug that is currently in the game lol}

Now this title can be broken down into PAL:
Problem: Player loses the ability to fire their weapon
Action: Walking into the hideout
Location: The Hideout

With just that info, the developers can tell what the issue is, how the issue is being triggered, and where the issue is occurring.

If a bug is occurring about 75% of the time, we will want to use words similar to Often, or Frequently.
Ex: “Often, the player loses ability to fire their weapon when walking into the hideout”

If bugs are only happening about 50% of the time, we will use words such as sometimes or Occasionally.

If you got a bug that is only happening about 25% of the time you might want to use a word like Rarely.

If you have a bug that is 100%, there is no need to indicate how often it is occurring in the title.

THE IMPORTANCE OF DESCRIPTIONS

When writing a bug, being able to describe the conditions at which you, the player, were in before, at the time, and after at which the bug occurred.
Let’s continue with the bug we referenced in the example before with the title – “Player loses ability to fire their weapon when walking into the hideout”.
[DESCRIPTION]
When navigating around the hideout playspace, the player must use/activate a button to open a door to access the hideout. Upon doing so and entering the hideout, the player is not able to fire their weapon afterwards. Attempting to swap weapons or holster/unholster them does not fix the issue. The player also must be holding their weapon in their hands when activating the button for this issue to reproduce. If the player attempts to interact with the door again, it does however fix the issue and they are no longer unable to fire their weapon.”
Within that description, the developers know what the player did to cause the issue as well as have additional information and clues as to what exact object/system may have caused the bug to occur as well as info that the player can also get themselves “unstuck”. This info can also help determine how severe the issue is and may indicate what priority the bug may have in terms of when it is fixed.

REPRO RATES

Repro Rates are simple. This indicates how often a bug is occurring. To figure this out, you will need to establish the repro steps and follow them to see how often the bug occurs. This is usually shown in the simple format like this:
Repro Rate: 5/5 100%
Repro Rate: 7/10 70%
Repro Rate: 1/5 20%

ESTABLISHING REPRO STEPS

The repro steps to a bug are very important. This is what we use to also understand further how a bug is occurring but also to aid us in our Fix Verification process and in making sure older fixes have not regressed. An example of repro steps are:
[REPRO STEPS]

Launch public-test CL 33895
Press Enter on the Main Menu
Once spawned in, navigate to the Button that opens the door to the hideout
Press Tab
Select the Loadout Tab
Equip a Weapon
Press Tab to exit the Menu
Now with your weapon equipped, interact with the button and open the door
Once the door is opened, attempt to fire your weapon that you have equipped
a. Notice you will not be able to”
With that, we have now identified a set of repro steps that will reproduce the bug that we are reporting on.

THE COMPLETED BUG REPORT

Now with that info in mind, below is what a completed and fully filled out bug report should look like following the format provided at the beginning of this guide.
[TITLE]
Player loses the ability to fire their weapon when walking into the hideout
[DESCRIPTION]
When navigating around the hideout playspace, the player must use/activate a button to open a door to access the hideout. Upon doing so and entering the hideout, the player is not able to fire their weapon afterwards. Attempting to swap weapons or holster/unholster them does not fix the issue. The player also must be holding their weapon in their hands when activating the button for this issue to reproduce. If the player attempts to interact with the door again, it does however fix the issue and they are no longer unable to fire their weapon.
[REPRO RATE]
5/5 100%
“[REPRO STEPS]

Launch public-test CL 33895
Press Enter on the Main Menu
Once spawned in, navigate to the Button that opens the door to the hideout
Press Tab
Select the Loadout Tab
Equip a Weapon
Press Tab to exit the Menu
Now with your weapon equipped, interact with the button and open the door
Once the door is opened, attempt to fire your weapon that you have equipped
a. Notice you will not be able to”

Congratulations, now you know how to write a bug for Founder Testing!

Again, thank you for taking the time to help us out and provide feedback and bugs! Together, we are going to create something amazing!

AJ Helling
Senior QA Engineer