2 Commits

Author	SHA1	Message	Date
Evan Pelle	a7f992e9b0	refactor: convert to npm-workspaces monorepo (engine/core-public/shared/client/server) ... Restructure the single src/ tree into an npm-workspaces monorepo under packages/, rename core -> engine, extract a types-only core-public layer, and break the pre-existing engine -> client dependency cycle. Structure (packages/): core-public public API/wire schemas + shared enums (clean leaf) shared framework-agnostic helpers (clean leaf) engine deterministic simulation (was src/core) client rendering/UI (was src/client) server coordination (was src/server) Dependency DAG: engine -> {core-public, shared}; client -> {core-public, shared, engine}; server -> {core-public, engine}. - npm workspaces: root package.json workspaces + per-package package.json; tsconfig.base.json holds shared options + path aliases (core-public/* shared/* engine/* client/* server/*) resolved uniformly by tsc, Vite (resolve.tsconfigPaths), Vitest, and tsx. Lockfile regenerated. - core-public: moved Schemas/ApiSchemas/CosmeticSchemas/StatsSchemas/ ClanApiSchemas/WorkerSchemas/Base64/PatternDecoder; extracted the enums (GameTypes), GameEvent type, emoji table, and GraphicsOverrides schema. Engine re-exports the moved enums/types so existing imports keep working. - Broke engine -> client cycle: - renderNumber/renderTroops -> shared/format - NameBoxCalculator moved into engine - username validation returns translation key + params; client translates - applyStateUpdate moved to client (operates on the render-only PlayerState) - Config/UnitGrid/execution-Util/GameImpl now use structural read interfaces (engine/game/ReadViews: PlayerLike/UnitLike/GameLike) instead of importing client view classes; client imports view classes from a new client/view barrel; deleted the engine/game/GameView re-export shim. - Build/deploy updated: vite.config, index.html, eslint, Dockerfile (copies packages/ + tsconfig.base.json before npm ci), .vscode, tests. Verified: tsc --noEmit clean; 1364 + 65 tests pass; production vite build succeeds; engine has zero client/server imports; core-public and shared are dependency leaves. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-10 16:51:03 +00:00
Ivan Batsulin	20f428d19e	Fix middle-click SAM not upgrading other buildings when SAM is unaffo… (#3670) ... Resolves #3511 ## Description: When middle-clicking a SAM launcher you own, the game calls findAndUpgradeNearestBuilding which queries all upgradeable structures near the clicked tile. If you can't afford the SAM upgrade, canUpgrade is false for the SAM (because canBuildUnitType returns false when gold < cost), so the SAM is excluded from the candidates list. If a nearby building (e.g. a Factory) can be upgraded, it gets picked as the "nearest" target and is upgraded instead — spending gold the player was saving for the SAM. The fix: after finding the best upgrade candidate, check if there's an owned SAM within the same search radius as the clicked tile. If there is, but the best candidate is not a SAM (meaning the SAM couldn't be afforded), do nothing instead of upgrading the other building. This ensures middle-clicking a SAM either upgrades it or takes no action. ##Please complete the following: - [x] I have added screenshots for all UI updates - [x] I process any text displayed to the user through translateText() and I've added it to the en.json file - [x] I have added relevant tests to the test directory - [x] I confirm I have thoroughly tested these changes and take full responsibility for any bugs introduced ## Please put your Discord username so you can be contacted if a bug or regression is found: fghjk_60845	2026-04-18 21:35:23 -07:00