Improving DF's Development Ecosystem

[Vulcano]

Preamble​

These suggestions are a compilation of ideas I've had that I believe would enhance the overall experience for developers on the server. I’m unable to check for duplicate suggestions, as I am banned from the Discord guild. For ease of reading, I’ve condensed the suggestions into spoilers.

Spoiler: Contents

• Dynamically Linked Libraries
  • Libraries
  • Version Control System
  • Dynamic Linking
• External API
• Function Changes
  • Function Categories
  • User-Defined Code Blocks
  • Deprecation
• User-Defined Types
• Miscellaneous Suggestions
  • Error Handling
  • Comments
  • Compiler Settings
  • Environment Variables

Spoiler: DLLs

Dynamically Linked Libraries​

Libraries​

To begin, this suggestion would require the introduction of libraries in DF, which would necessitate a new plot type without a build area. I know this has been suggested before, but I have a different approach to how it could work. Libraries would be open-source and consist only of functions and processes. There would be a GUI that allows users to easily add these to their plots—I'll cover this more in the next section. Developers could also make libraries private, enabling the creation of internal frameworks or APIs without making them public. Libraries would be a huge time-saver for those who choose to use them.

Version Control System​

With no build area, version control becomes more feasible and would be essential for allowing developers to safely update the libraries they use. This system would help:

• Prevent large updates from breaking dependent plots
• Allow developers to fork and maintain their own versions of libraries

Dynamic Linking​

Here’s where the suggestion might seem a bit unconventional. One of the biggest drawbacks to libraries in DF is having to manually place functions. With dynamically linked libraries, this would no longer be necessary. They would be precompiled and linked; any plot using the same library would reference a shared, compiled version. If you're familiar with low-level programming, you might recognize this from the "dll" (dynamically linked library) file extension. This would move DF in a more modular programming direction.

Spoiler: External API

External API for Importing Code​

This suggestion is more straightforward. It's technically feasible to create an API that allows code to be placed directly on a plot, verified using an API key that can only be generated by the plot owner. This would streamline development in external languages by allowing a service to handle the code placement automatically.

Since templates are already stored as JSON, this system could:

• Use the same format with additional metadata for code placement
• Include an endpoint for plot size and create a new code-space automatically

Spoiler: Function Changes

Function Changes​

[NOTE] These suggestions also apply to processes.

Function Categories​

Function categories would clean up and organize the function UI, making development—especially when using libraries—far easier. When importing a library, it would:

• Appear under its own category
• Allow optional subcategories defined by the library’s creator
• Let users define subcategories within their own plots

User-Defined Code Blocks​

Users could move a category outside the main function block and into a new block defined by themselves. This would:

• Improve organization in large-scale projects
• Leave existing systems untouched for those who don't want to use it

Deprecation​

Functions could be flagged as deprecated, and optionally marked with:

• A replacement function
• A "marked for deletion" flag, alerting users of future removal

Spoiler: User Defined Types

User-Defined Types​

Users would be able to create variable objects using an interface similar to setting function parameters. These would:

• Act like dictionaries
• Automatically generate getter/setter functions
• Be organized in a new category per object (removable only by deleting the object itself)

Library creators could also define and distribute these, and they'd appear in the library’s function menu when imported. This would make DF development feel more like using a modern game engine like Unity.

Spoiler: Misc...

Miscellaneous Suggestions​

Error Handling​

When deleting object definitions or updating libraries, errors could arise. These should:

• Be caught before compilation if possible
• Display with a red border and an error message explaining the issue

Comments​

Comments used to exist as holograms, and I believe they’re still extremely useful. They could be reintroduced as:

• Block-tied text notes
• Viewable with a `/viewcomments` command (with optional range)
• Clickable in chat to warp directly to the relevant block

Compiler Settings​

Right now, DF compiles code as it's written, which usually works—but not always. There should be a setting to:

• Disable live compilation
• Require manual compilation via a command

Environment Variables​

Environment variables would be:

• Constants only visible to the plot owner
• Usable by any dev on the plot
• Ideal for securely storing things like API keys, especially since web requests are now possible

Conclusion​

These suggestions aim to make DF development feel more professional, flexible, and scalable—without breaking what already works. I hope they spark discussion or help inspire future updates. I’d love to hear feedback, additional ideas, or improvements to anything I’ve brought up here!

 

[Ace]

calling it a discord guild

 

[fireflash431242342134214]

i thought you got banned from df

 

[Vulcano]

i thought you got banned from df

No, I was banned from all official guilds, not the Minecraft server.

 

[Hellscaped_]

rejected because DF devs dont feel like rewriting the codebase to be compiled

 

[Vulcano]

rejected because DF devs dont feel like rewriting the codebase to be compiled

This shouldn’t require a full rewrite based on my understanding of the codebase, but it wouldn’t be compiled. In all honesty though, compiled would work better but not be worth it for DF, it would require a complete rewrite of how plots work. Devs would privacy be best off abandoning Java other than the API layer and the plugin. Or would require a high level virtual machine written in something like C++. Rust would work, but not be ideal. C would simply be hell to maintain. Swift would honestly be the best option due to its bidirectional interop with Java. This would obviously never happen, but DF would see a drastic improvement in performance doing this and switching hosts to a Mac based network. This would be far from feasible, but it’s cool in theory.

 

[Hellscaped_]

This shouldn’t require a full rewrite based on my understanding of the codebase, but it wouldn’t be compiled. In all honesty though, compiled would work better but not be worth it for DF, it would require a complete rewrite of how plots work. Devs would privacy be best off abandoning Java other than the API layer and the plugin. Or would require a high level virtual machine written in something like C++. Rust would work, but not be ideal. C would simply be hell to maintain. Swift would honestly be the best option due to its bidirectional interop with Java. This would obviously never happen, but DF would see a drastic improvement in performance doing this and switching hosts to a Mac based network. This would be far from feasible, but it’s cool in theory.

me when I don't know what I'm talking about

also DF runs on linux??? what are you waffling about with mac?

 

[Vulcano]

me when I don't know what I'm talking about

also DF runs on linux??? what are you waffling about with mac?

I know what I am talking about it brandie I have been able to recreate it. It would not be feasible to recode for DF, but it is possible. I simply like what Mac has to offer for servers over Linux, that doesn’t mean DF should migrate, but if it did it would be able to gain performance. It would be far from feasible but using Swift on Mac you can get extremely performant code.