> ## Documentation Index > Fetch the complete documentation index at: https://summer-18f03259-codex-native-multiplayer-entry.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Extending Summer > Summer is an extensible engine. Three ways to add capability: GDScript editor plugins, native GDExtension libraries, and engine modules — what each one can reach, and which to pick. Summer Engine is the product. Its current upstream technical base is Godot Engine 4.7.2-stable. Summer follows upstream continuously; 4.7.2 is a compatibility fact, not the Summer Engine product version. Runtime and project compatibility ranges for this new base remain unmeasured, so treat native extensions as version-sensitive until the exact binary is loaded and exported successfully. There are three of them. They differ in what they can reach, what they cost to build, and whether you can use them at all. | You want to | Use | Language | Needs a compiler | Available to you | | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | ----------------- | ----------------------- | ---------------------------------------------------------------------------------------------------------- | | Drive the editor: bakes, forced reimports, custom docks, registering autoloads, anything under `EditorInterface` | [Editor plugin](/extending/editor-plugins) | GDScript | No | **Yes, today** | | Add fast native types, wrap a C/C++/Rust library, or do heavy per-frame work | [GDExtension](/extending/gdextension) | C++, Rust, others | Yes | **Conditional** — generate against the current 4.7.2 binary and load-test each binary/platform combination | | Change the engine itself: new servers, new core types, editor internals | [Engine module](/extending/modules) | C++ | Yes, plus engine source | **No.** Summer's engine source is not public | If you are an agent, or you are automating Summer, the answer is almost always the first row. An editor plugin is a text file you write and a line you add to `project.godot`. It needs no build step, no signing, and no engine source, and it hands you the entire `EditorInterface` — which is the only way to reach a large set of engine capability that is simply not exposed to ordinary scripts. ## Editor plugins A `@tool` script extending `EditorPlugin`, declared by a `plugin.cfg` in `addons//`, enabled through `project.godot`. It runs inside the editor process with full editor context. This is the path that turns "the API is not exposed to scripting" into "the API is reachable". Occluder baking, forcing the import of a file an agent just wrote, saving a scene from code, registering an autoload — none of those are available to a plain script, and all of them are available from inside an editor plugin. It also works without a window. `Summer --headless --editor` boots the editor, loads enabled plugins, and gives you a live `EditorInterface` from a shell — with one sharp hazard around your running editor that the deep page documents in full. Templates, the three ways to enable a plugin and why they behave differently, what `EditorInterface` actually unlocks, the verification step you must not skip, and the headless-editor hazard ## GDExtension Native shared libraries loaded from a `.gdextension` file. No engine recompile, no custom binary — the same mechanism stock Godot uses. Summer currently follows the 4.7.2-stable base. Generate the interface and API from the installed Summer binary rather than reusing headers from an older release. Match the exact API, architecture, operating system, compiler/runtime dependencies, and signing requirements, then run a real load/export test; the current compatibility range is not yet measured. Building, loading, and shipping native extensions in Summer ## Engine modules C++ compiled directly into the binary. This requires building the engine from source, and [Summer's engine source is not public](/knowledge-base/source-status), so modules are not an option for external developers today. The page exists because the distinction matters when an upstream tutorial describes an extension mechanism. What modules are, why they are internal-only in Summer, and what to use instead ## Using community Godot addons Community addons are candidates, not blanket-compatible inventory. Pure GDScript addons are usually lower-risk than native extensions, but Summer's minimum and recommended project compatibility ranges remain unmeasured. Judge every addon by these rules: * **Godot 4.7 or 4.x, pure GDScript, `@tool` + `EditorPlugin`** — the lower-risk case. No ABI, no compilation, no signing. Install into `addons/` and enable it like any plugin you wrote yourself. * **Godot 4.x with a GDExtension binary** — depends on the addon shipping a build for 4.7 and for your platform. A successful upstream load is useful evidence, not proof of a Summer load or export. Check [GDExtension](/extending/gdextension), then test the exact binary in a committed copy. * **Godot 3.x** — dead. The 3.x plugin API does not exist in 4.x. This is not a Summer limitation; the same addon fails on stock Godot 4. * **Anything shipped as an engine module or a custom engine build** — cannot be used. There is no way to compile it into Summer. Enabling a plugin runs its code inside your editor process with full filesystem access. Read what you are enabling. This is true of stock Godot too, but it is worth saying once. ## Next steps The deep page: templates, enabling, `EditorInterface`, traps Run the engine from a shell with no window: baking, importing, exporting *** Need help or have questions? Reach out to our founders at [founders@summerengine.com](mailto:founders@summerengine.com) or join our community on [Discord](https://discord.gg/yUpgtxnZky) for fast responses.