Experimental

In *DayZ*, there is a secondary version of the game client available to the general public referred to as **DayZ** **Experimental**. This version is available to everyone who owns DayZ. It is named so because it is generally a less polished version of the game and is used for testing new features or fixes before they reach a wider audience in order to ensure that they are ready. It is not intended to be the primary branch of play for users.

Experimental servers were used for small testing patches before Stable pushed to Beta, instead of full dedicated builds. This also marked the movement of 0.63 Experimental to Stable, and 0.62 Stable to a *Legacy* version of the game. Stress Test builds also ended at this time.

## Stable vs. Experimental

### What's the Difference?

There are two versions of the game available to most users at any given time, and the "normal" one intended for general consumption - is referred to as the *Stable* branch. It includes all public servers in addition to all private hive and private shard servers. Though its name should make this obvious, this is the version that has been through more rigorous testing and been found to be playable for the majority of the userbase without any crippling issues. Most builds used for this version have been previously tested for quality assurance by an internal team at the development studio as well as normal users on the game's second public version.

That second version is *DayZ* *Experimental*. Users must manually download this version by searching in their Steam library. Steam will download another folder with any files that are necessary to play Experimental version. There is still both Official and Community servers, while stable version's community servers are running by DayZ Server application, experimental version need separate *DayZ Experimental Server* folder that is available by downloading via Steam library.

Most of the time, users who have downloaded and running the Experimental version on Steam will be unable to play on Stable version servers because they will be using incompatible versions. However, occasionally the Experimental version is running the exact same build as Stable, and under those rare circumstances players are able to play on any server without having to switch between clients. However, Experimental servers are still on a separate hive, meaning character data does not carry over from the Stable version or vice versa.

### The Purpose of Experimental

So what is the reason for Experimental? Creative Director Brian Hicks defines it as the following (edited for clarity and formatting):

```
This branch is, by its own definition, "unstable". In the simplest terms, the purpose of [the] Experimental branch is for the development team to experiment with builds in a larger userbase than our internal QA.
Sometimes that results in us finding issues we cannot catch internally, sometimes that means we can verify fixes on issues with very low [reproduction] rates. Sometimes the builds are very unstable.

The branch exists for load/volume/stress testing. Those who go through the process of manually opting into this branch (it's not super visible - by design) and dealing with whatever issues the current build on it may have, get to sometimes see content and systems not quite ready for prime time. However, that does not mean that [this] is the branch's purpose. As the nature of the Experimental branch is for the above mentioned testing methods, neither uptime, character data, nor stability is guaranteed.

```

Over the time that DayZ Standalone has spent in Steam's Early Access program, Experimental has gained a reputation as the version where you play if you want to see new content/changes/fixes etc. before Stable release.

Users may encounter potential issues and bugs while playing DayZ Experimental due to the nature of the pre-polish pre-test gameplay.

### Special Servers

Official requests from the development team for players to concentrate on something specific will often come in the form of an open invitation (via DayZ Forums or official Twitter account) to play on some type of "special" server. In the past, that has taken the form of unique server configurations (extremely harsh weather), limited-time builds (0.58 camp hotfix), and stress tests (100 slot servers) just to give a few examples.

The purpose of these uniquely designated testing spaces is to gather specific data related to whatever it is that makes that server special. In the examples above, that differentiation is obvious and tangible, however at times these special servers are just a particular configuration that better suits the collection of a particular kind of data that the development team needs in order to improve something or fix a problem.

## How to play

Users can move back and forth between the Stable and Experimental version by playing on separate game clients, it either can be **DayZ (stable branch)** or **DayZ Experimental (experimental branch)**. Follow the simple steps below to switch between them.

The method of joining Experimental version is to download the Experimental Client in Steam.
This is a seperate full game download, users can switch between the two fast, but does require hard drive space aprox. 18GB free to install the experimental version.
Experimental servers are only up during testing of new versions.

## The Debug Monitor (outdated)

Previously exclusive feature to the Experimental version of DayZ is something called the *Debug Monitor*. This is a small, semi-transparent box that lives in the upper-right corner of your screen when playing on servers that are part of this branch. It exists to give testers more information about their character in order to aid them in filing related tickets on the Feedback Tracker.

The following character information can found on the monitor:

* Health
* Blood
* Body Temperature (ºC)
* Position (3D)
* Last Damage (falling, zombies, melee, etc.)
* Modifiers (energized, drenched, sick, etc.)

## How You Can Help

### Play on Experimental

The simple act of playing on the Experimental version is helpful to the efforts of the development team. Although ideally there would be a steady stream of people in these servers at all times, that is often not the case between major updates being previewed on this branch. There may not always be new content to see, but in the true spirit of Experimental there are is almost always something that needs to be tested. That "something" is not always stated outright by the developers because sometimes it is a sensitive issue (i.e. security-related), but if there is an alternative build available here then it means that they need to collect data from players.

It is strongly suggested that you document your experiences on this branch and submit feedback, however this is not a requirement to play on Experimental, and merely playing on this branch generates data that can potentially be used to verify fixes or better understand a problem. Better yet -- bring your friends! Play on Experimental together.

### Submit Feedback

Taking Notes
First, let's talk about how to capture your thoughts, ideas, and observations so that you can reference them later and use them to submit feedback in some form or another. Personally, I'm a huge fan of keeping a pen and a notepad next to the keyboard when I'm playing, that way I can take notes about a bug I've encountered or write down ideas without having to Alt+Tab out of the game and without risking the possibility of forgetting it all later. Some may see this as old school, but it's important to have a quick and ready method of recording these things. Alternatively you could use a note-taking app on your phone or tablet, have a second monitor or computer available, etc.

Now that you've got some way of getting your thoughts down on paper so to speak, you can begin training yourself to take notes as you play. By all means go crazy with your comments, draw doodles, whatever, just remember to be coherent and thorough so that you're not asking yourself, "What did I mean by that?" later on when you go to share the information. Also remember that bad or incomplete information can be worse than nothing at all because it can be misleading or confusing, so be as detailed as possible if you're recording information to report a bug.

Feedback can be submitted in many forms, but the most helpful commentary is filing a ticket on the Feedback Tracker. Before you go and create a ticket however, let's discuss what kind of information to gather in addition to what else you may want to include with your submission.

The goal of a feedback ticket (or really any constructive feedback) is to provide information that will hopefully result in a problem being fixed. In order to fix anything, the developers need to know how to reproduce that bug so that they can observe it for themselves and determine the cause. If you do not provide them with adequate information to reproduce the bug, then your feedback isn't nearly as useful because it's essentially just a statistic. If you want to be helpful, be detailed in your note-taking so that you can then be thorough in your explanation.

When documenting an issue, try and be as scientific as possible. Eliminate variables as much as you can while still reproducing the bug, because the fewer outside factors there are, the easier it will be to determine the cause of the problem. If possible, recreate the bug a few times to be sure that it is both repeatable and consistent.

Information you should record and include for submission:

1. Where does the bug occur? If it is specific to a location, like the roof of City Hall in Chernogorsk, say so and include map coordinates if at all possible. When it is not bound to a particular location but instead only when walking on a hill, or only when climbing a ladder, etc. then that is what you should be indicating.
2. When does the bug occur? Some bugs are triggered by being in a specific spot or by completing a certain action. Is it only at night, only when holding a weapon, only when riding in a V3S, etc.? If you are unable to reproduce it, you would want to indicate that instead.
3. How frequently does the bug occur? This is important because not only does it help gauge how severe the bug is, but also tells the person trying to reproduce it how many attempts might be necessary to encounter it.
4. Give a short, simple explanation of the bug -- a summary, basically.
5. Basic information about your computer such as what operating system it is running and what version of the game you were playing when you encountered the bug (i.e. 0.58.129488).

Compiling information for feedback doesn't have to be exclusively text either -- sometimes a picture or video is just as helpful if not better. If you are so inclined, I recommend checking out the the various methods of in-game video capture such as Fraps, Bandicam, Dxtory, ShadowPlay, etc. Many of these same programs will allow you to snap screenshots as well, but if you just want to create one quickly and don't want to install video software, the Steam in-game overlay is more than sufficient for providing evidence to include with your report. That overlay can be enabled under your "In-Game" options on Steam.

Submitting a Ticket
When in doubt, submit a ticket. Don't assume that the development team is already aware of an issue that you've encountered. Others before you may have encountered the same issue and made the same assumption -- "they probably already know." You can't be sure until you check out the Feedback Tracker.

If you've taken good notes and you're satisfied with the information and materials you would like to submit, then it's time to visit the Tracker. Before you go creating a new ticket however, do a search: find out if there is an existing ticket for the same issue. If a ticket has already been started for that issue, contribute additional relevant information or pictures/video as a comment or "subtask" to that original ticket rather than creating your own. This reduces clutter within the Tracker and aids the bug fixing process by making it as easy as possible to reproduce the issue thanks to all of the data being available to reference in one place.

After you have searched and are certain a prior ticket for the same issue does not exist, you can create a new one by clicking the + symbol at the top and choosing either "New DayZ Bug Report" or "New DayZ Security Bug Report" depending on what type of issue you are reporting (see the post linked below if you are unsure what category your report should go to). The form you are given will ask you for all of the information I outlined in the previous section. Provide everything that you are asked for and anything else you feel may be helpful in identifying and fixing the bug, including pictures and video which can be uploaded as part of the ticket. You aren't asked for too many things, but it's better to provide too much information than not enough, so detail as much as you know about the issue because you never know what may help track it down.

Before hitting submit, ask yourself one last time if what you're submitting is helpful and informative; if not, consider going back and elaborating further or compiling more evidence.

Submitting a report for a bug that crashes the game requires a few extra steps in order to sufficiently inform the development team. In the future, the hope is that it will be possible to send the necessary data automatically, but for now it is a manual process. You will need to do the following things:

1. Add the -dologs command to your Steam launch parameters. Right click the game's name, select Properties, and under the General tab select "Set Launch Options..." In the text box that pops up, add the text "-dologs" (without the quotes). This will allow the game to generate a report about the crash when it happens.
2. Gather those crash dump reports. They can typically be found here on your computer: C:\Users\\AppData\Local\DayZ\. You will need to copy all of the files from this folder and create a .RAR or .ZIP archive from them. Include several for the same crash if at all possible.
3. Get your DirectX Diagnostic (DxDiag) report. This program will generate a text file about your PC's hardware for you to include with your submission. Information about it can be found here: https://en.wikipedia.org/wiki/DxDiag

Both of these reports can then be uploaded as part of your ticket. You can do this by simply dragging the file from wherever you have it on your computer into one of the text boxes on the form (preferably the "Description" box). Files can also be uploaded by clicking the "Upload File" button that you'll see within the row of icons at the top of each text box.

A link to the Feedback Tracker itself can be found below, and a guide on how to navigate the Feedback Tracker can be found on the official forum.

External Resources
* Official Discussion Forum
* Feedback Tracker

## See Also

* Changelog
* Servers