Addon evaluation tracker: dev tooling + modding aids #13
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Brainstorm 2026-10-24 (from chat): addons that could help development or make modding easier. Nothing installed — this issue tracks evaluation only.
Verdicts (with Zach's direction)
Orchestrator (asset 3209)
https://godotengine.org/asset-library/asset/3209
Zach's original note: paired with Logic Bricks as "basically the same thing? but different design". — modding surface, evaluate
Visual scripting language (OScript), GDExtension binary. Direction: explicitly for modding — lighter scripted events for modders; GDScript stays directly supported. License Apache-2.0 (per Zach). Open: verify a 4.6-compatible build; modding-surface design (OScript runtime ships in the game).
PSX Look Free (asset 5493)
https://godotengine.org/asset-library/asset/5493
Zach's original note: "could be neat for graphic tweaking in the FOSS build, (easy toggle off)". — graphics experiment, FOSS build
PS1-style viewport wrapper (vertex snap, affine mapping, 240-line render), GDScript+shaders only, 4.3–4.7, all renderers incl. Compatibility, CC BY 4.0 (credit line). Direction: "let's see how this goes" — not a major art-style change; neat for the FOSS build. Requirements: official content must be able to turn it OFF; mods must control it and replace it with their own. Open: XR rendering interaction test.
GoBuild (asset 5038)
https://godotengine.org/asset-library/asset/5038
Zach's original note: "definately useful for modding". — modding toolchain, try in editor
In-editor mesh editor (no Blender round-trip), editor-only so zero runtime cost. Direction: feeds the modding toolchain; a dedicated modding SDK comes later. Open: license check on the repo before vendoring.
Godular (asset 5442)
https://godotengine.org/asset-library/asset/5442
Zach's original note: "definately going to be useful for turning the game into modular components later that can be ripped out and re-used". — later, systems build-out
Code-level modularity (modules declare imports/providers/exports, DI container, command bus, jobs). Direction: for later, when systems are built out — the "ripped out and re-used" layer. Note: 0.1.0, tagged 4.7 (pin check needed), requires gd_promise. Complements (does not replace) the PCK/zip addon system.
LiteTerrain (asset 5316)
https://godotengine.org/asset-library/asset/5316
Zach's original note: "terrain testing? maybe?" — terrain testing
MIT, tagged 4.6, seeded chunked procedural terrain, one node. Direction: procedural terrain is a yes-in-principle (seeded terrain + placed assets saves level-design time), with constraints: scale must increase, geometry at that scale is a concern (links to Godotite's LOD story). Use for testing; Terrain3D (PR #7) stays the crafted-level candidate; don't ship both blindly.
Godotite (asset 5536)
https://godotengine.org/asset-library/asset/5536 — later, scale-dependent
MIT, 0.9.0, tagged 4.5, Nanite-style cluster LOD for large static meshes, uses the mesh's own materials. Revisit when terrain/world scale makes geometry a concern (see procedural-terrain decision above).
SMC (asset 3744)
https://godotengine.org/asset-library/asset/3744
Zach's original note: "might be redundant but could be helpful". — parked
MIT, DI + finite state machine, tagged 4.7. Parked pending the DI judgment below; do not adopt alongside Godular (at most one DI story).
Save Vault (asset 5478)
https://godotengine.org/asset-library/asset/5478
Zach's original note: "could be useful? maybe". — don't adopt, steal ideas
MIT, encrypted multi-slot saves + Steam Cloud + autosave. Conflicts with the save spec (plain diffable dumps, backup-first, one run slot). Mine for safe non-blocking autosave + conflict resolution ideas only.
Logic Bricks (asset 4822)
https://godotengine.org/asset-library/asset/4822 — not pursued
MIT, sensor/controller/actuator logic wiring, tagged 4.2 (stale). Narrower than Orchestrator; the visual-logic question is settled by Orchestrator if it goes anywhere.
Decisions recorded 2026-10-24
Open checks
please apply the original links
below is copy/pasted from before in our private messages
These two are basically the same thing? but different design
https://godotengine.org/asset-library/asset/3209
https://godotengine.org/asset-library/asset/4822
https://godotengine.org/asset-library/asset/5536
https://godotengine.org/asset-library/asset/5493 could be neat for graphic tweaking in the FOSS build, (easy toggle off)
might be redundant but could be helpful
https://godotengine.org/asset-library/asset/3744
could be useful? maybe
https://godotengine.org/asset-library/asset/5478
definately useful for modding
https://godotengine.org/asset-library/asset/5038
definately going to be useful for turning the game into modular components later that can be ripped out and re-used
https://godotengine.org/asset-library/asset/5442
terrain testing? maybe?
https://godotengine.org/asset-library/asset/5316
also please include our discussion, our discussion is getting moved here regarding this
More things we should consider
https://github.com/GodotModding/godot-mod-loader
https://github.com/patrykkalinowski/godot-xr-kit
https://godotengine.org/asset-library/asset/3839
https://godotengine.org/asset-library/asset/271
https://godotengine.org/asset-library/asset/3338
https://github.com/phosxd/Tesseract
https://godotengine.org/asset-library/asset/4301
if any of these are duplicates, we can discuss
Moving the discussion here, as requested.
Original links applied: the issue body now links all nine original assets, with your original notes attached where you annotated them (Orchestrator/Logic Bricks as "basically the same thing? but different design", PSX Look for FOSS graphics tweaking, GoBuild for modding, Godular for rip-out-and-reuse components, LiteTerrain for terrain testing, SMC as possibly redundant, Save Vault as possibly useful).
From comment 761 — duplicates:
From comment 761 — new, first-pass verdicts:
namespaceis just an author ID), no data deep-merge (whole-file replace), ZIP-only (no PCK tier), no sandboxing (mod code can touch nearly everything). No 4.6 claim found on its releases; adoption needs a 4.6.3 check. Verdict: steal the manifest mechanics regardless.So on your "several are valid" — yes: the mod loader's manifest and the inventory reference are the two with real design overlap; Synth and LimboConsole are conditional; Xterm isn't worth it. Further discussion on any of these lives here.
This would be very useful for building our prototype maps and blockouts as well as testing other details
https://godotengine.org/asset-library/asset/1420
Agreed — this one fits the tracker well.
Dev Blocks (asset 1420) is a collection of dev blocks using Kenney's prototype textures, with the textures aligned and scaled properly. License is CC0, so it passes the gate cleanly, and the textures themselves are the point: grid markings, arrows, and numbers make scale and orientation readable at a glance, which is exactly what you want when blockout-testing a map before committing to real art. For VR that's doubly useful — distances, reach, and traversal feel are hard to judge flat, so greyboxing early and walking it in-headset beats guessing from the editor view.
Two caveats, both minor:
And the usual prototype discipline: keep it in dev/blockout scenes. The placeholder look is the feature during prototyping, but it shouldn't leak into a shipped map.
Two questions: do you want this added to the issue body as a prototype/blockout verdict, and is the scope dev-sandbox-only, or should modders get the same blockout kit as a modding aid?
Agreed — this one fits the tracker well.
Dev Blocks (asset 1420) is a collection of dev blocks using Kenney's prototype textures, with the textures aligned and scaled properly. License is CC0, so it passes the gate cleanly, and the textures themselves are the point: grid markings, arrows, and numbers make scale and orientation readable at a glance, which is exactly what you want when blockout-testing a map before committing to real art. For VR that's doubly useful — distances, reach, and traversal feel are hard to judge flat, so greyboxing early and walking it in-headset beats guessing from the editor view.
Two caveats, both minor:
And the usual prototype discipline: keep it in dev/blockout scenes. The placeholder look is the feature during prototyping, but it shouldn't leak into a shipped map.
Two questions: do you want this added to the issue body as a prototype/blockout verdict, and is the scope dev-sandbox-only, or should modders get the same blockout kit as a modding aid?
Oh I didnt mean to link the Universal Inventory and Godot Xterm, my bad,
limbo console i was imagining could be helpful for in game stuff for debugging (console commands to spawn items, give player currency, deal healing/damage, etc)
For the godot-mod-loader what we could do is say "hey! here is the standard in which our files are packed" and then let people do what they want with the packaging, however we need to look into how the mod code works since there is no "pck" teir, which means it would negate the reason for using Orchestrator with node based coding for basic stuff, which is a feature I WANT for modding, as well as custom assets that CAN overwrite game assets.
load order is an important thing for this, so we might "fork" the modloader to add what we need, MAYBE, we shall see
for the Dev Blocks, the caveats are perfectly fine actually, this makes it so we have ready made default materials for objects that need it (map, test objects, etc)
Also "leaking into a shipped map" isnt something that should be enforced by this, as there may be requirements for that kind of stuff. remember this repo is the
Dead Air Enginebasically, where the actual gameplay and story content will be elsewhere as its own "mod", which is very important for the modloader to function how we want it. Because all of the story content and official maps will be in one mod, which means there will be assets, systems, and code that wont be present in the Engine, so we need the code-loading capabilities. I want the Node Based Code for mods that can use it to be simple and effective, but mods should still support using raw gdscript for coding incase the nodebased doesnt work for the personNoted on all three corrections — and the last one reframes the tracker a bit, so let me restate it back to make sure I've got it right.
Accidental links dropped: Universal Inventory and Godot Xterm weren't intended candidates, so I won't treat them as such. That's consistent with where Xterm already landed (don't pursue, license unestablished) — no action needed there.
Limbo Console, clarified use: in-game debug console — spawn items, give currency, heal/damage, that class of command. That's a different slot than I had it in: a debug/dev tool first, not a modding aid. As a debug tool the case is straightforward. The one thing worth deciding when it gets evaluated is gating: dev-build-only, or shipped but gated somehow. A console that can spawn items and hand out currency is a cheat surface if it rides along in release builds.
Mod loader, and the packing-standard idea: publishing "here is the standard your files are packed to" and letting people package however they want is a clean division of labor — the engine owns the contract, not everyone's tooling. But as you say, the contract is only worth anything if code actually loads through it. The open question is exactly how the stock loader carries mod code: if it can't carry code in the way you need, it undercuts both halves of the modding story — Orchestrator node-based scripting for simple stuff and raw GDScript for people the node-based path doesn't serve — plus asset overwrites. Load order is load-bearing there too, and it connects to decision 1 already in the body (mod dependencies + load-order resolution, design TBD): overwrites are only predictable if order is deterministic.
On the fork question: worth evaluating the stock loader against those three requirements (code loading, overwrites, deterministic order) before forking. A fork buys exactly the behavior you want, but it also buys tracking upstream forever. "Fork, maybe, we shall see" is the right order — verify the gap first, then decide if it's fork-sized.
The engine/content split is the big one: da-game as the Engine, with story content and official maps living in their own mod. That explains why code-loading is non-negotiable rather than nice-to-have — the engine ships without systems and code that only the content mod provides — and it reframes the Dev Blocks point: they're not a leak risk, they're ready-made default materials for objects that need them (maps, test objects). No enforcement question at all, just a default set the engine carries.
It also suggests a useful split for this tracker going forward: engine-side aids vs content-mod aids, since something can be right for one side and wrong for the other.
One question back: want me to fold these three verdicts into the body — Limbo as in-game debug console, Dev Blocks as engine default materials, mod-loader as open question (stock vs fork, pending the code-loading check) — or leave them in comments until the mod-loader check lands?