Direct public contact
The current public contact route for V Rising Forge is the GitHub repository connected to this site: github.com/liuguangliang99999/vrising. Use that repository for correction requests, policy questions, and site feedback.
If you want the cleanest route, use the repository issue forms. There is now one form for guide corrections and one for support-page or policy feedback, which makes it easier to send one exact page-level issue instead of a vague general message. Guide pages also now link directly to the guide-correction form from their visible follow-up panels.
What happens after feedback arrives
A useful report should turn into one of four outcomes: a small wording fix, a page-level review pass, a patch-sensitive note on the Updates hub, or no change when the current page is already cautious enough. That keeps feedback tied to visible page quality instead of disappearing into a private inbox.
| If the feedback shows | Likely next action | Public signal to check |
|---|---|---|
| One sentence is too broad or too confident | Rewrite the sentence and keep the page review scope clear. | The changed page and, when useful, the Worklog. |
| A route, boss, material, layout, or mod detail may have drifted | Send the page to a focused review pass before changing surrounding guides. | The page maintainer notes, Updates hub, or public Worklog. |
| A real screenshot would settle the doubt faster than more text | Move the page higher in the visual proof queue or connect the next real screenshot when available. | The Visual Coverage page and the page's screenshot status block. |
| The issue is outside this fan site | Leave the guide unchanged and point readers toward official support or source pages when appropriate. | The Contact page boundary and non-affiliation notes. |
What to include
When reporting an issue, include the page URL, the part of the guide that seems wrong, and enough context to understand the problem. For gameplay corrections, mention the patch version if you know it and describe what happened in your save.
30-second pre-report check
Make sure the page is actually wrong, not just narrower than your save
A useful correction starts by naming the mismatch correctly. Sometimes the guide is outdated. Sometimes the route only changed because of server rules, stage mismatch, or a screenshot gap that the page already labels honestly.
Check the page scope first
If the guide is clearly written for early, solo, or first-haul play, do not treat a later-game or group-only mismatch as the same problem without saying so.
Check world or server rules
If teleport rules, loot rates, PvP pressure, or other settings changed the result, mention that directly. A route can be fine on default rules and still fail on your world.
Check Updates if the drift feels patch-based
If the issue only started after a visible patch, a loader change, or a mod dependency shift, open Updates first and then report what still reads too confidently.
Check proof status if the doubt is visual
If the real question is whether a route, layout, or install step already has a linked screenshot, open Visual Coverage before treating the missing image as a hidden claim.
Pick the smallest useful route
One guide looks wrong
Use the guide-correction issue form when the problem is one route step, boss note, material source, mod instruction, or castle claim.
One support page looks wrong
Use the support-page or policy feedback form when the issue is really About, Contact, Updates, Disclosure, Privacy, or Terms.
The issue started after a patch
Check Updates first, then send the correction if the page still reads too confidently after that check.
How to send a useful correction fast
- Link the exact page.
- Name the exact route, step, unlock, layout point, or mod note that looks wrong.
- Say what changed: patch drift, route danger, wrong unlock order, changed material source, or outdated install behavior.
The goal is not writing a long message. The goal is sending enough detail that the page can be checked against one concrete claim instead of guessing what part felt off.
If you include visual proof
A screenshot helps most when it is tied to one claim: the boss route, resource loop, castle room flow, unlock screen, or mod folder that no longer matches the guide. If you suggest a file name, keep it short, numbered, and literal, such as 01-first-ore-segment.webp. Do not include private server details, account names, passwords, payment information, or anything you would not want visible in a public GitHub issue.
How reader screenshots are reviewed
A submitted image is not automatically published or counted as proof. The site treats it as a lead until the claim, context, safety, and public page wiring have all been checked.
| Review step | What gets checked | Public outcome |
|---|---|---|
| 1. Match the claim | The image must show one named route, unlock, resource pocket, castle loop, or mod setup—not a vague “the game looks like this” moment. | It is mapped to one planned proof slot or left as supporting context. |
| 2. Record the context | The report should name the tested game version, world or server rules, solo/group context, and mod loader details when they affect the result. | The caption keeps the recommendation from sounding universal when it is save- or patch-specific. |
| 3. Remove private data | Account names, server addresses, passwords, payment details, private chat, and other personal information must be cropped or withheld. | Unsafe images are not published, even if the gameplay claim looks useful. |
| 4. Wire it publicly | If accepted, the same file must appear on the guide, use a short literal filename, and be reflected on Visual Coverage and the Worklog. | Only then can one proof slot move from pending to connected. |
| 5. Keep a re-check trigger | A patch, route drift, server-setting change, or reader correction can make an otherwise useful image stale. | The page keeps a visible review note instead of treating the screenshot as permanent truth. |
There is no automatic public upload or instant-proof shortcut. A real image can help the queue move faster, but the editorial check still happens before the site presents it as first-hand evidence.
Example of a strong correction
Useful format
Page: /resources/where-to-get-iron/
What looks wrong: the first safe ore segment recommendation now pulls extra pressure on my current patch path.
What changed: the route still works, but the page should warn players to clear one extra patrol lane first before treating the first loop as low-risk.
Why this helps: this gives one exact page, one exact step, and one exact claim to re-check instead of only saying “the guide feels outdated.”
Correction request checklist
| Feedback type | Include this | Why it helps |
|---|---|---|
| Boss, route, or resource correction | The guide URL, the exact step that felt wrong, and the route or patch context from your save. | It helps separate a real gameplay drift issue from a route-prep or timing issue. |
| Castle layout feedback | The page URL, whether you play solo or group, and which loop felt slow: unloading, refining, crafting, or expansion. | Castle advice depends heavily on how the base is actually used every session. |
| Mods or patch-sensitive feedback | The mod category, loader or dependency context, and whether the issue happened after a visible update. | Mod guidance can age faster than normal route advice, so patch timing matters. |
| Privacy, disclosure, or policy question | The policy page URL and the specific sentence, label, or disclosure that needs clarification. | Policy feedback is easier to review when it points to one exact public statement. |
How feedback is used
Feedback is used to decide which page needs the next review pass, screenshot check, wording cleanup, or update note. A correction does not automatically mean the whole guide is wrong; often it means one route condition, patch-sensitive detail, or follow-up link needs to be tightened.
Public vs private feedback
The current correction route is public because public issues are easier to connect to visible page changes. Do not include private account details, passwords, payment information, server credentials, or personal information in a GitHub issue. If the site later adds a private inbox or form, this Contact page and the Privacy Policy should be updated before that route is treated as active.
What this site can reasonably answer
- questions about the site's public guide structure and editorial policy
- correction requests for boss, resource, progression, castle, map, or mod guides
- basic business, privacy, disclosure, or policy questions about the site
What this site does not currently offer
- user accounts or support tickets
- comment moderation or community submissions
- official V Rising or Stunlock Studios support
- private troubleshooting for individual servers, purchases, bans, crashes, or platform accounts