2.6 KiB
Repository Guidelines
Project Structure & Module Organization
This repository is a DP-S game-server hotfix tree. Main.nut is the entry point and hot-loads five roots: OfficialConfig/, OfficialProject/, _DPS_/_Core/, _DPS_/_BuiltProject/, and MyProject/. Put shared framework code, hooks, and callback glue in _DPS_/_Core/. Treat _DPS_/_BuiltProject/ as bundled baseline features. Add official feature modules under OfficialProject/<功能名>/, usually with a matching <功能名>.nut and optional Proj.ifo; keep module JSON beside it in OfficialConfig/. Use MyProject/ for local or experimental scripts. Runtime outputs belong in log/; native binaries and maintenance scripts live in lib/.
Build, Test, and Development Commands
There is no standalone compile step for .nut scripts; the server reloads them through GameManager.OpenHotFix(...) in Main.nut.
git status- check the workspace before editing or submitting.git diff --stat- review the size and scope of your change.Get-Content Main.nut- confirm hotfix load order and active roots.Get-ChildItem OfficialProject, OfficialConfig, MyProject- inspect feature and config layout.bash lib/strip_other_funcs_unix.sh lib/libAurora.so- maintenance-only helper for the Aurora binary; do not run unless you are intentionally updating symbols.
Coding Style & Naming Conventions
Use 4-space indentation and keep lines readable. Follow existing Squirrel patterns: PascalCase for helper functions, callback maps like Cb_*, and descriptive feature names for folders and main scripts. Keep one primary feature per folder/file pair, for example OfficialProject/战力榜/战力榜.nut. Name configs by feature, optionally with a server suffix such as 战力榜配置_南瓜.json. Prefer small, focused hooks over large unrelated edits.
Testing Guidelines
This repo has no automated test suite yet. Validate changes on a development server by reloading the affected hotfix path, exercising the related GM command, callback, or dungeon flow, and checking log/ for regressions. When a module reads JSON, test both the script change and the matching config file together.
Commit & Pull Request Guidelines
Recent history favors Conventional Commit prefixes such as feat, fix, refactor, and docs, often with a scope: feat(偷窃系统): .... Keep new commits in that style even though older messages are mixed. PRs should explain gameplay impact, list touched paths, call out config or data migrations, and include screenshots or log snippets when the change affects announcements, UI text, or player-visible flows.