mirror of
https://github.com/openfrontio/OpenFrontIO.git
synced 2026-06-21 11:00:43 +00:00
VariableVince
318d1e2c44
## Description: 1) Have last localstorage calls for keybinds and attack ratio also use UserSettings cache instead, after #3481. Remaining calls to localstorage are for different things than user settings, so they are left as is. 2) Consolidate and centralize keybinds logic. And three fixes for it. - **UnitDisplay** and **UserSettingsModal**: _parsedUserKeybinds_ is introduced in **UserSettings** to centralize their logic. It is also used by _normalizedUserKeybinds_, see point below. - **UserSettingsModal** -- replaced unwanted cast `as SettingKeybind` by a typed QuerySelector. -- renamed this.keybinds to this.userKeybinds for more clarity, and distinction from defaultKeybinds. -- state private _userKeybinds_: remove type string[] since loadKeybindsFromStorage replaces a value array by its first string element, so it can not contain string[] anymore. -- _handleKeybindChange_ and _getKeyValue_: no need to check for Array.isArray anymore, see above reason. -- **Fix**: checks after calling _parsedUserKeybinds_ are improved a bit: don't delete all keybinds and print a console warning when finding just one invalid keybind and (i think i have seen people complaining about things being removed). Instead it now migrates or throws out the invalid ones but keeps the valid ones. Also works with the "Null" value expected and removed within **UserSettingsModal**._handleyKeybindChange_() and in **HelpModal**. When legacy value is an array and key is empty, don't put value as key but get first array element or empty string as key name. So that check on line 68 is true. - **HelpModal** and **InputHandler**: Also centralize/consolidate their logic more, by having __keybinds()_ from **UserSettings** perform fetching _getDefaultKeybinds_ and _normalizedUserKeybinds_. -- Functionality in _normalizedUserKeybinds_ is the same: Where HelpModal did return [k, v.value] if typeof (v as any).value === "string", this is now handled by lines 309-310 of normalizedKeybinds still the same but with less lines. Same for old HelplModal if (typeof v === "string") return [k, v], this is stil returned by line 112 of normalizedKeybinds. And return [k, undefined] when (typeof val !== "string") as was done in InputHandler, isn't needed as values that weren't strings were already filtered out right after which we still do on line 314 of normalizedKeybinds. -- **Fix** in _normalizedUserKeybinds_: added one extra thing that was a discrepancy between **HelpModal**/**InputHandler** and **UserSettingsModal** before: **UserSettingsModal** would handle array values, and normalize them by picking only the first value if it is a string. Now have _normalizedKeybinds_ do the same. Otherwise it would have thrown those values out while **UserSettingsModal** would have kept the first value. This may still help a returning player who hasn't played in the last version (i think i have seen people complaining about things being removed, but that may not have been about this). And makes the logic more consistent between **UserSettingsModal** and **HelpModal**/**InputHandler**. - **UserSettings**: -- _getDefaultKeybinds_: centralized/consolidated logic, accepts Platform.isMac parameter. In **HelpModal**, **InputHandler** and **UserSettingsModal** the same list with default keybinds was hardcoded. Now they all read from _getDefaultKeybinds_. The list of default keybinds in **HelpModal** was a little shorter, but that doesn't matter since its _render_() function has hardcoded which of the hotkeys **HelpModal** shows. Have thought about putting default keybinds in **DefaultConfig** but with all the logic handled through **UserSettings**, this seemed the better place in the current refactor. -- _removeCached_: make public, now that **InputHandler.test.ts** needs to be able to call it. We could instead make a public function like removeKeybinds() and keep removeCached() private, but went with this for now. -- _parsedUserKeybinds_: centralized/consolidated logic for **UserSettingsModal**/**UserDisplay**. Always returns an object, even an empty one if the JSON wasn't parsable. -- _normalizedKeybinds_: centralized/consolidated logic. Used by _keybinds_() which is now called by **HelpModal**/**InputHandler**. -- _keybinds_: now uses getDefaultKeybinds() and normalizedKeybinds() to get the default and user changed keybinds. -- **Fix** in _keybinds_: it now removes a key if it is Unbound by the user in **UserSettingsModal**. Instead of first loading the parsedUserKeybinds, removing "Null" keys from it, and then merging that with defaultKeybinds (so default key would overwrite an unbound key), we now merge parsedUserKeybinds with defaultKeybinds and after that remove "Null" keys from it (so that unbound key stays removed). For example if Boat Attack Up is set to "None" ("Null") by clicking Unbind, there is now no hotkey working for it anymore. Even when the default is "B". Why? This prevents the user from being confused, they have deliberately Unbound it, they don't understand why it still works (have seen bug reports and game feedback about this)? Also more importantly: they used to now be able to bind "B" to another action. Effectively making key "B" bound to two actions: the user choosen one and Boat Attack. This also makes the logic more consistent. Because building hotkeys in **UnitDisplay** already didn't work when unbound, eg. when Build Missile Silo was Unbound, the "5" key did not do anything anymore (there is a fallback in **UnitDisplay** in case the key is actually null, but it does respect "Null" as it should). -- _setKeybinds_: have it accept an object, it stringifies it itself. Callers UserSettingsModal and InputHandler.test.ts now just send either a string or an object. - **InputHandler.test.ts**: -- use **UserSettings** functions instead of localStorage for more real-world testing. -- change test "ignores non-string values and preserves defaults, removes 'Null' for unbound keys". As explained above, as a fix we no longer preserve unbound ("Null") keys within InputHandler. UserSettings.keybinds() now removes "Null" keys as explained above. - ControlPanel: use UserSettings to fetch initial attack ratio. ## 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: tryout33
OpenFront.io is an online real-time strategy game focused on territorial control and alliance building. Players compete to expand their territory, build structures, and form strategic alliances in various maps based on real-world geography.
This is a fork/rewrite of WarFront.io. Credit to https://github.com/WarFrontIO.
License
OpenFront source code is licensed under the GNU Affero General Public License v3.0
Current copyright notices appear in:
- Footer: "© OpenFront and Contributors"
- Loading screen: "© OpenFront and Contributors"
Modified versions must preserve these notices in reasonably visible locations.
See the LICENSE for complete requirements.
For asset licensing, see LICENSE-ASSETS.
For license history, see LICENSING.md.
🌟 Features
- Real-time Strategy Gameplay: Expand your territory and engage in strategic battles
- Alliance System: Form alliances with other players for mutual defense
- Multiple Maps: Play across various geographical regions including Europe, Asia, Africa, and more
- Resource Management: Balance your expansion with defensive capabilities
- Cross-platform: Play in any modern web browser
📋 Prerequisites
- npm (v10.9.2 or higher)
- A modern web browser (Chrome, Firefox, Edge, etc.)
🚀 Installation
-
Clone the repository
git clone https://github.com/openfrontio/OpenFrontIO.git cd OpenFrontIO -
Install dependencies
npm run instDo NOT use
npm installnornpm ibut instead use ournpm run inst. It runs the safernpm ci --ignore-scriptsto install dependencies exactly according to the versions inpackage-lock.jsonand doesn't run scripts. This can prevent being hit by a supply chain attack.
🎮 Running the Game
Development Mode
Run both the client and server in development mode with live reloading:
npm run dev
This will:
- Start the webpack dev server for the client
- Launch the game server with development settings
- Open the game in your default browser (to disable this behavior, set
SKIP_BROWSER_OPEN=truein your environment)
Client Only
To run just the client with hot reloading:
npm run start:client
Server Only
To run just the server with development settings:
npm run start:server-dev
Connecting to staging or production backends
Sometimes it's useful to connect to production servers when replaying a game, testing user profiles, purchases, or login flow.
To replay a production game, make sure you're on the same commit that the game you want to replay was executed on, you can find the
gitCommitvalue viahttps://api.openfront.io/game/[gameId]. Unfinished games cannot be replayed on localhost.
To connect to staging api servers:
npm run dev:staging
To connect to production api servers:
npm run dev:prod
🛠️ Development Tools
-
Format code:
npm run format -
Lint code:
npm run lint -
Lint and fix code:
npm run lint:fix -
Testing
npm test
🏗️ Project Structure
/src/client- Frontend game client/src/core- Shared game logic/src/server- Backend game server/resources- Static assets (images, maps, etc.)
🤝 Contributing
Contributions are welcome! Please feel free to submit a Pull Request.
- Request to join the development Discord.
- Fork the repository
- Create your feature branch (
git checkout -b amazing-feature) - Commit your changes (
git commit -m 'Add some amazing feature') - Push to the branch (
git push origin amazing-feature) - Open a Pull Request
🌐 Translation
Translators are welcome! Please feel free to help translate into your language. How to help?
- Join the translation Discord
- Go to the project's Crowdin translation page: https://crowdin.com/project/openfront-mls
- Login if you already have an account / Sign up if you don't have one
- Join the project
- Select the language you want to translate in. If your language isn't on the list, click the "Request New Language" button and enter the language you want added there.
- Translate the strings
Feel free to ask questions in the translation Discord server!
Project Governance
- The project maintainer (evan) has final authority on all code changes and design decisions
- All pull requests require maintainer approval before merging
- The maintainer reserves the right to reject contributions that don't align with the project's vision or quality standards
Contribution Path for New Contributors
To ensure code quality and project stability, we use a progressive contribution system:
-
New Contributors: Limited to UI improvements and small bug fixes only
- This helps you become familiar with the codebase
- UI changes are easier to review and less likely to break core functionality
- Small, focused PRs have a higher chance of being accepted
-
Established Contributors: After several successful PRs and demonstrating understanding of the codebase, you may work on more complex features
-
Core Contributors: Only those with extensive experience with the project may modify critical game systems
How to Contribute Successfully
-
Before Starting Work:
- Open an issue describing what you want to contribute
- Wait for maintainer feedback before investing significant time
- Small improvements can proceed directly to PR stage
-
Code Quality Requirements:
- All code must be well-commented and follow existing style patterns
- New features should not break existing functionality
- Code should be thoroughly tested before submission
- All code changes in src/core MUST be tested.
-
Pull Request Process:
- Keep PRs focused on a single feature or bug fix
- Include screenshots for UI changes
- Describe what testing you've performed
- Be responsive to feedback and requested changes
-
Testing Requirements:
- Verify your changes work as expected
- Test on multiple systems/browsers if applicable
- Document your testing process in the PR
Communication
- Be respectful and constructive in all project interactions
- Questions are welcome, but please search existing issues first
- For major changes, discuss in an issue before starting work
Final Notes
Remember that maintaining this project requires significant effort. The maintainer appreciates your contributions but must prioritize long-term project health and stability. Not all contributions will be accepted, and that's okay.
Thank you for helping make OpenFront better!