- Joined
- Sep 11, 2020
- Messages
- 261
- Reaction score
- 65
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.- 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
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.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
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
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.
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