23 lines
2.6 KiB
Markdown
23 lines
2.6 KiB
Markdown
# 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.
|