[CabinetOnFire]

Description

We would like to add support for /tg/ specific functionality (like live-lighting preview), but since StrongDMM is codebase agnostic we can't really add this to the main repo. Instead of forking or making our own map editor this seems like a nice middle-ground, adding support for extensions that can do passes on the rendering pipeline (or change other functionality).

The extensions are cross-platform, and are packaged as '.sdmmext' archives which are just zip files with the executables for each platform and a manifest (to declare capabilities for example)

For extension authors, the important parts are:

• Declare what the extension can do, such as drawing render passes or adding right-click turf actions.
• StrongDMM sends map data and changes to relevant extensions.
• Extensions can return extra drawing commands, such as the lighting overlay.
• Extensions can add actions to the map’s right-click menu. (Unused right now, but its an example of how extension API could be set up)
• One generic build task builds all platforms listed in the manifest and creates the installable package. (This will need a module tag)

I've updated the rendering pipeline and shaders a little to make it possible to do what I needed to do for the lighting extension, but this should have no user-facing changes.

Here is a link to the plugin, including a release which you can use to test this on the tgstation repo if you're interested https://github.com/CabinetOnFire/StrongDMM-TG-Lighting-Extension

Type of change

• New feature (non-breaking change which adds functionality)

[CabinetOnFire]

Video of the linked plugin for reference

20260801-2312-50.2828559.mp4

[SpaiR]

Thanks for your contribution! 🙏

I've been thinking about implementing "extensions" for a very long time, but I never got around to it since I largely stopped actively developing the editor. Nevertheless, I'm really glad to see that someone was able to make it happen.

I'll need a little time to dive deeper into the details of what's going on here, but I can guarantee these changes will be merged!

And I know that this kind of change can sometimes benefit from user feedback, so I recommend grabbing the binaries generated by CI and inviting others from the TG community to test the new functionality. You might catch something unexpected that way.

P.S. On my end, I just wanted to mention that it might have been better to go with embedding Lua instead of relying on compiled executable files. But then again, that might have introduced other issues; I'm not entirely sure.

[SpaceManiac]

How do you plan to distribute the plugin binaries to /tg/station's mappers?

Have you considered a plugin boundary which is not Go-specific and might allow reuse in other tools?

Your commits have no email address set.

[CabinetOnFire]

I was thinking to either move the repos under the tg org if headcoders want it otherwise it'd be linked in the mapping guides.

I've not considered making it tool agnostic, It sounds like it'd be a lot of work and I also don't really see the use honestly.

[CabinetOnFire]

are you thinking to use it for the map thing used by the webmap viewer?

[SpaceManiac]

I think doing so would be a useful application of a per-codebase plugin system. But not if it's compiled binaries and Go-only.