Roadmap and updates

Start with the published announcement

Use the website's News section to read official updates, release notes and other published development information. Open the actual entry rather than relying on a cropped screenshot or a paraphrase in chat. Read its date, scope and wording before deciding whether a change is already available, planned or simply being discussed.

A development idea, an announced plan and a released feature are different states. A mention in a conversation does not automatically establish a release commitment. When asking support about a feature, identify the announcement or statement you are referring to and explain which part is unclear. This helps the team answer the real question without treating a rumor as a published promise.

Distinguish plans from current behavior

A roadmap describes intended work and priorities at the time it is shared. The feature you can actually use should be assessed through the current game interface and the relevant release notes. Dependencies, testing and design changes can affect how work arrives. Do not assume that an old concept image describes the exact final behavior.

If a feature is described as available but you cannot find it, record your account, device, relevant screen and the steps you followed. Say whether the announcement mentions a limited scope or another condition. A question about availability is more useful when it starts with the exact published claim and the observed result.

Read patch notes as a set of specific changes

Look for the agent, weapon, mode, setting or fix that concerns your question. Compare the stated change with the action you are testing. A release can contain several unrelated adjustments, so do not attribute every new experience to the first item in the notes. Keep your comparison narrow enough to explain.

For example, if a weapon description changes, inspect the current Arsenal entry and the behavior you can observe. If a bug is listed as fixed, test the original sequence under comparable conditions when practical. A different failure with a similar symptom should be described separately rather than automatically called a regression of the same issue.

Keep older guides in context

Videos, screenshots and player guides can remain online after the game changes. Check their date and the version or context they describe. A control that moved, a renamed item or a balance adjustment can make old instructions confusing without making them deliberately misleading. Use the current interface as the reference for the action you are performing now.

If an official support guide itself appears outdated, report the page title, the specific instruction and the current result. You do not need to rewrite the whole guide to help. A focused discrepancy gives the team a clear editorial correction to investigate and prevents other readers from following the same obsolete step.

Verify what changed in your session

After a release, note when you joined and whether the app or game prompted an update. Use the normal update and rejoin paths when appropriate. Do not install a private “early patch” or run a script from a player claiming it unlocks the announced content. Official announcements should lead you through the ordinary product routes.

If the expected feature remains absent, describe the screen and account state rather than repeatedly resetting unrelated preferences. Include whether another session or device shows the same result if you already checked. A visible difference between sessions is useful context, but it does not by itself establish why the difference exists.

Example: a listed fix appears not to work

Suppose release notes say a particular interaction was corrected, but you observe a similar failure. Record the entry, your session time and the exact steps. Compare your sequence with the original issue as closely as you can without disrupting other players. Preserve the visible outcome and any error message.

Submit the report as an observation about the current build, with a link or title for the relevant News entry. Explain what matches the old issue and what differs. This helps the team distinguish an incomplete fix, a new condition and a separate bug. Avoid assuming the developers ignored the report simply because the symptom looks familiar.

Follow development without treating silence as a date

If no release date has been published, support may not have an approved date to provide. Ask about the currently announced status rather than requesting a promise based on an estimate. Repeatedly asking different staff members can produce fragmented information and does not change the published commitment.

You can still provide feedback about why the feature matters to you. Describe the player problem and current workaround through Feedback & ideas. That is useful input even when the team cannot give a schedule. Keep the feedback and the question about announced timing distinct so each can be answered clearly.

Use mailbox notices as a starting point

An in-game notice can alert you to an update, but the detailed announcement may contain more context. Read the full entry when you need exact changes. Communication preferences may affect optional notices, so missing a mailbox announcement does not by itself establish that the update is unavailable.

If a notice links to the wrong page or its text disagrees with the published release information, record both titles and the observed mismatch. Hide unrelated mailbox content in screenshots. A small comparison is enough to identify a communication issue without exporting the entire mailbox.

Frequently asked update questions

Does a planned feature have a guaranteed date? Use the actual wording of the published announcement. Do not turn an estimate or discussion into a stronger commitment.

What if a player says they have an unreleased feature? Check official information and report your own observed account state. Another person's claim is not an installation source or a reason to share credentials.

Can I report an outdated support article? Yes. Include the page, instruction and current behavior so the team can assess the correction.

Should I reopen every old bug after an update? Report a current reproducible observation when the problem remains. Keep the original case connected where possible and explain what changed.

Ask a question with the right reference

Name the announcement, date and feature involved. State whether you need help finding the feature, understanding a listed change or reporting behavior that contradicts it. Include device, relevant session context and the exact screen when those details matter.

For future ideas, use Feedback & ideas. For current failures, use the relevant gameplay or technical category. A clear reference to the published information lets support answer the question you actually have and keeps development discussion grounded in what has been announced or observed.