Help AnyPS5 without coding: logged tests and useful community reports
ItsOOGWAY · Recorded PC guides · 04
Help AnyPS5 without coding: logged tests and useful community reports
A practical reporting companion: record the source and game versions, run a repeatable test, choose the right evidence, and review a report before sharing it with the AnyPS5 community.
Resources from this video
Project links & documentation
Every resource URL from this video’s description is collected here. Recorded-release links identify the build used; current project pages may describe newer versions.
Watch the recorded video
Watch on YouTube ↗ · Screenshots below come from this final recording.
Video chapters
- 0:00 Help AnyPS5 without coding
- 0:47 What this Silksong test demonstrates
- 1:42 Source and preparation
- 2:36 Convert the game to Windows
- 3:34 Direct launch vs logged launch
- 4:27 Run a repeatable gameplay test
- 5:28 Exit states and incomplete sessions
- 6:16 Select the right report evidence
- 7:08 Write useful observations
- 7:55 Review and export the report ZIP
- 8:51 Where to share a game test
- 9:44 Logs vs performance traces
- 10:39 Compare another source snapshot
- 11:26 The community testing workflow
Before you start
- Join the ItsOOGWAY server before opening its direct Workbench download post; it is a community frontend, not the official upstream project.
- Use your own supported, already-decrypted dump and retain the exact source commit and content version.
- Decide what you are testing and keep original data, saves and private logs separate from anything you share.
Stage 01
Establish a conversion you can identify
Choose the official source ZIP, select the supported game input, click Find games, confirm the discovered title, and choose an output folder outside the original dump. Convert with baseline options and keep the resulting package intact.
The recorded source is commit 3e3e8b905018be3c0daf318511a260ddd1124893. If you test a newer source, record its new identifier. The description’s Workbench 0.5.2 note concerns changed Windows compiler requirements and a later build validation; it is not evidence of additional gameplay tests.
Stage 02
Use a logging launch when runtime evidence is needed
The original footage starts the converted Play.exe directly. That can show a game and a terminal without saving a captured Workbench runtime session. For a new logged test, use Run converted game or Launch with logs.cmd in the output folder.
If attaching to an older package, the recorded narration describes Select an existing converted game as the route for installing its logging helpers. Choose a repeatable sequence, such as menu → new save → opening area, and note the last stage reached.
Stage 03
Select the evidence that actually belongs to the run
Open Export community report and inspect Run to include. Match the chosen session to the event you are describing. The footage’s export says build, conversion and legacy logs only, so it must be described as a limited export.
A file named session.json is not sufficient proof of a captured run: its contents matter. If no runtime session exists, either share conversion evidence honestly or repeat the test through the logging route. Do not label absent logs a complete crash report.
Stage 04
Write a small, reproducible observation
Set Furthest point reached to what you observed. Menu is different from In game. Describe expected behavior, actual behavior and the action just before a failure. Include source commit, content version, operating system, GPU and driver.
For this footage, a defensible observation is that Silksong reached its early playable area and movement was shown. Do not invent a measured frame rate or full-game compatibility. Distinguish an intentional Stop action from a crash, and a running-session export from a final exit result.
Stage 05
Review the ZIP before making it public
Open the generated report archive and read its Markdown draft, available logs and session details. Redaction is best effort. Check for names, personal paths or credentials yourself rather than trusting an archive filename.
The report is intended to exclude game assets, saves, keys and memory dumps. Share the report instead of the converted game folder. Workbench saves locally; it does not automatically upload your report, diagnose a bug, or submit a GitHub issue.
Stage 06
Use the right upstream destination
Search the official Game bring-up discussions for the title ID before adding a compatibility result. Use an existing title thread where appropriate. For a reproducible bug, follow the current issue form and connect it to the relevant discussion.
A terminal log is not a dedicated performance trace. Upstream performance reporting has its own capture requirements and controlled comparison procedure. The recording shows reporting guidance, not a completed upstream submission. Review and submit your own evidence after checking the destination instructions.
If your result differs
| Situation | Next useful check |
|---|---|
| Export has no runtime evidence | Repeat through the logged launcher if needed. Keep a limited conversion report labelled as limited. |
| Game was stopped manually | Record that action and the last visible screen. Do not call a deliberate stop an unexplained crash. |
| Build profile error on a newer snapshot | The description links the later Workbench update. Its build validation does not prove a game now runs. |
A useful report is exact and modest: identify the versions, describe what happened, attach the evidence you actually captured, and let upstream investigate. You do not need to guess a code-level fix.
Comments
Post a Comment