Divine Intervention: The Joy of Discovery vs. Snail et al.

[jordancoles]

Btw

[KotMroku1]

https://youtu.be/yVqN5N9fVG8
Artist recreation.

[jorb]

If anyone wishes to report known offenders acting incognito under new aliases, my DMs are open.

[Austinh15]

@Loftar maybe run this idk i ran it through fable just trying to help bb

/goal Phase 1 — In-game test suite for the hafen client: JUnit-free runner, an in-game :test console entry, and a first wave of side-effect-free cases.

Workspace: F:\hafen-client-master\hafen-client-master (Java client, Ant build, source/target 1.8).
Plan: none yet — write spec/test-plan.md as step 0 (case catalog, runner design, checkpoint section) and keep it current.

Status (pre-Phase-1):
- No automated tests exist and no `test` Ant target. Don't add JUnit or a new build system.
- src/haven/test/ has headless bots only: TestClient (localhost:1870 dev server), Robot hooks (newwdg/dstwdg/uimsg), CharSelector, MultiClient.
- Console commands register via Console.Directory.findcmds() (see GameUI.cmdmap, MapView.cmdmap).
- Widget tree is guarded by synchronized(ui); asset access throws haven.Loading when not ready.

Three deliverables:

1. Runner core in src/haven/test/ (~400 LOC).
TestCase (name, tags, run(TestCtx) throws Throwable); TestCtx (ui, GameUI, Session, Glob, MapView; waitfor(pred, timeout) that polls on UI ticks and retries through Loading; wdg(Class) finder walking the tree under synchronized(ui)); TestRunner (ordered run, per-case timeout, setup/teardown, PASS/FAIL/SKIP + duration); TestReport (stdout + build/test-report.txt). Cases register in a static TestRegistry from a suite class, not classpath scanning. Pitfall: never touch widgets off the UI lock; never block the UI thread inside waitfor.

2. Entry points (~250 LOC).
(a) In-game: add "test" to GameUI.cmdmap: `:test list`, `:test all`, `:test <name|tag>`; runs on a HackThread, reports via ui.msg plus the report file. (b) Headless: a Robot subclass that starts the suite once GameUI appears through TestClient, for the localhost:1870 dev-server path; document that it cannot reach the official server (fixed cookie). Pitfall: GameUI is recreated on relog, so resolve it per run, don't cache it.

3. First wave of cases, all side-effect-free (~500 LOC, 12-15 cases).
session alive and connfailed==0; GameUI present; MapView.player() resolves; player grid present in MCache; maininv opens/closes and item widgets enumerate; Equipory present; CharWnd/OptWnd/MapWnd toggle open then close; ui.msg system-message round trip; Resource.remote().load("gfx/hud/...") resolves; FlowerMenu appears on right-click then cancels; Speedget cycles and restores; walk 2 tiles via MapView click, assert player coord changed, walk back. Pitfall: no dropping, eating, crafting or combat; every case restores prior state.

Out of scope (Phase 2): resource-code (get-code) cases, MultiClient load runs, screenshot diffing, LWJGL parity.

Pitfalls:
- Tabs at 8 cols, LF endings, LGPL header on new files, no camelCase identifiers.
- Java 8 syntax only: no var, records, or switch expressions.
- Build with `ant`; verify by running bin/hafen.jar and `:test all` in-game; report actual output, not assumed.
- Account creds only via local-config.properties (gitignored); never hardcode them.

Launch from F:\hafen-client-master\hafen-client-master so project memory loads.

And here's some test case tools to look into:

Recommendation first: for this repo, document cases as text in the tree, in spec/ next to the plan, and have the runner's TestReport emit JUnit-style XML. Nearly every tool below can import that XML, so you keep the choice of management UI open without changing the client.

Top ten, roughly ordered by fit for a small Java project with a custom runner:

1. Markdown or Gherkin in-repo (docs-as-code). One .md or .feature file per case, versioned with the code. Free, reviewable in diffs, and the case IDs can double as the names the runner registers.
2. Kiwi TCMS. Open source, self-hosted test case management with a REST API and JUnit XML import. Good middle ground if you want a UI without a vendor.
3. TestLink. The older open-source option. Dated interface, but stable, self-hosted, and exports cases as XML you can keep in the repo.
4. Qase. Cloud test management with a free tier, clean case editor, and a reporter API you could hit from a Java runner with plain HTTP.
5. Testiny. Lightweight cloud tool aimed at small teams. Fast case authoring, CSV import, and JUnit result upload.
6. TestRail. The commercial standard for manual and automated case management. Best reporting of the group, but paid and heavier than you need for one client.
7. Xray for Jira. Cases, test sets and executions as Jira issue types. Only worth it if you already live in Jira.
8. Zephyr Scale. The other Jira-native option, with better BDD and Gherkin support than Xray.
9. Allure Report. Not case management, but the best way to turn run output into a browsable report with steps, attachments and history. Emit its JSON from TestReport and you get screenshots per case for free.
10. Testmo. Unified manual, exploratory and automated results with a strong CLI for uploading JUnit XML from CI.

Two notes for your context. Since Linear is already connected to this session, you could track cases as issues with a test-case label and link each to its spec file, which is cheaper than adopting a new tool. And avoid anything that requires a JUnit or TestNG dependency in the build, since the client deliberately has neither and Ant would need extra wiring.
5. Testiny. Lightweight cloud tool aimed at small teams. Fast case authoring, CSV import, and JUnit result upload.
6. TestRail. The commercial standard for manual and automated case management. Best reporting of the group, but paid and heavier than you need for one client.
7. Xray for Jira. Cases, test sets and executions as Jira issue types. Only worth it if you already live in Jira.
8. Zephyr Scale. The other Jira-native option, with better BDD and Gherkin support than Xray.
9. Allure Report. Not case management, but the best way to turn run output into a browsable report with steps, attachments am TestReport and you get screenshots per case for free.
10. Testmo. Unified manual, exploratory and automated results with a strong CLI for uploading JUnit XML from CI.
Two notes for your context. Since Linear is already connected to this session, you could track cases as issues with a test-case label and link each to its spec file, which is cheaper than adopting a new tool. And avoid anything that requires a JUnit or TestNG dependency in the build, since the client deliberately has neither and Ant would need extra wiring.

GL buddy I know you got it

[h3lblad3]

EDIT: Didn't some market get absolutely shit on a few years back via something similar?

Irongete did it to a market hosted by a group that was giving his group trouble, I think.

[Austinh15]

TBH Joy of Discovery got shit on because of incompetence.

TBH not really your incompetence imo more really the fact that you trusted something to be fixed and tested and the lack of DEV TESTING caused this.

[menillos]

[Redlaw]

Not playign this world givne the higher focus on PvP and yet... those that would kill be bug abuse and get themselves removed. Fun times.

[SnuggleSnail3]

• We are always interested in good quality bug reports. Report before you 'sploit, and we can avoid affaires.

[Austinh15]

Dude, are we deadass.