Contribute

The Arma Reforger mods documented here are open source. Fixes, translations, testing and new features are all welcome — from people who have never written a line of Enforce Script as much as from people who have shipped their own addons.

Everything starts in Discord. It is where work in progress gets posted, where you can check nobody is already building the thing you want to build, and where you will get an answer fastest.

Ways to help

Writing code is the smallest part of keeping a mod alive. All of these matter:

• Play it and report what breaks. Especially on a populated server — most bugs only show up with several players, a long-running world, or persistence enabled.
• Translate. String tables are plain key/value tables; you need no tooling and no code to add a language.
• Improve the docs. If something on this site is wrong, out of date, or assumed knowledge you did not have, say so. Confusing docs are a bug.
• Test release candidates. Before a Workshop update, a build usually needs someone to run the full loop end to end and confirm nothing regressed.
• Make assets. Models, textures and icons, provided the licensing is clean (see below).
• Write code. Bug fixes, new features, compatibility layers for other mods.

Before you start

Talk first, build second. For anything bigger than a small fix, raise it in Discord before you write it. This is not bureaucracy — it is so you do not spend a weekend on something that conflicts with work already in progress, or that was left out deliberately.

Scope matters more than size. A change that does one thing gets reviewed and merged quickly. A change that fixes a bug, reformats three files and renames a component is painful to review and will sit unmerged. Keep them separate.

If you are building a compatibility or integration mod, check the existing ones first — the pattern you need may already exist, and you can build on it rather than reinvent it.

Ground rules

• Be decent. Assume good faith, keep criticism about the code, and leave the drama in other communities. That applies in Discord, in issues and in review comments.
• Credit people. If you use someone's model, texture, script or idea, name them. Attribution is not optional, and for some licenses it is a legal requirement.
• Do not break other people's servers. These mods run on live communities. A change that invalidates saved data, changes prefab GUIDs, or silently alters gameplay balance needs to be called out clearly so admins can plan for it.
• Respect upstream. When a mod builds on another mod, the upstream one is not ours to modify. Extend it from outside rather than forking or editing its prefabs.
• Ask. “I do not understand how this works” is always a reasonable thing to say, and usually means the docs need work.

Code standards

These are Enfusion-specific habits that keep the mods maintainable and compatible with each other.

• Prefix everything. Classes carry a mod tag — GW_ for Growing Weed, FF_ for Freedom Fighters addons, FF_GW_ where one bridges the other. Scripts live under Scripts/Game/<ModName>/.
• Extend with modded class. To change existing behaviour, override the method and call super. Do not copy a class to edit it.
• Inherit prefabs, do not fork them. To add a component to someone else's prefab, create an inherited .et that adds only what you need.
• Expose tuning as prefab attributes. Durations, prices, yields and patterns belong on the prefab so server owners can change them without touching code. Do not hardcode a number someone will predictably want to change.
• Write it server-authoritative. State changes belong on the server, and spawned entities need an RplComponent. If you only tested in single-player, say so in the pull request.
• Do not tick every frame. Use CallLater at a sensible interval. A timer that fires once a second is almost always enough.
• Keep resource names stable. Renaming or re-GUIDing a shipped prefab breaks saves, other people's integrations, and world-placed entities.

Assets and licensing

Asset licensing is the one area where a mistake can force a mod offline, so it is stricter than everything else here.

• Only contribute assets you have the right to contribute. Your own work, or something whose license clearly permits redistribution in a game mod.
• Never rip assets from another game, another mod, or a paid pack you are not licensed to redistribute.
• Bring the license with the asset. Tell us the source, the author and the license terms when you submit. “I found it online” means it cannot be used.
• Attribution lines are exact. Some licenses, such as CC BY 4.0, require specific wording. It goes in the credits and it stays there.

Localization

No user-facing string should be hardcoded English. Strings live in the string table and are referenced by key, so any language can be added later without touching code.

• Keys follow the vanilla convention with the mod tag first, e.g. GW-Item_SativaSeeds_Name and GW-Action_FillWithDirt.
• Adding a language means adding a column and translating the values — no code changes, so this is a good first contribution.
• Translate meaning, not words. Keep it to the register a player expects in-game, and note regional variants (for example Latin American versus European Spanish) when they differ.
• If a key has no translation yet, leave it empty rather than guessing.

Test before you submit

Run the loop your change touches, from start to finish, in a Play session:

• No new errors on script reload. Compile and attribute errors surface immediately — check the console is clean before anything else.
• The full feature loop works, not just the step you changed.
• It survives a restart if the mod is persistence-enabled.
• Multiplayer behaves, or you have flagged that you could not test it.
• Nothing leaked into the tree — no .log, .tmp or .blend1 files, and no development-only tooling.

Submitting your change

• One logical change per pull request, with a description of what it does and why.
• Say what you tested and on what — single-player, a listen server, or a dedicated server with persistence. This is the most useful thing in the description.
• Call out anything that changes saved data, prefab GUIDs, or balance.
• Expect review comments. They are about getting the change right, not about you, and they usually come with the reasoning.
• Publishing to the Workshop is done by the maintainer, so a merged change goes out with the next release rather than immediately.

Reporting a bug

You do not need a GitHub account or Discord to report something. Use the bug report form, or post in Discord if you would rather talk it through.

A good report has:

• What you expected, and what happened instead.
• Steps to reproduce it, even rough ones.
• The mod version, and whether you were in single-player or on a server.
• Other mods loaded — conflicts are common and this saves hours.
• Console output or a crash log if you have one.

Licensing of your contribution

Contributions are accepted under the license of the project you are contributing to, and you keep the credit for your work. If you are contributing an asset under a license with its own conditions, flag it when you submit so the terms can be carried into the credits.