Difficult question, difficult answer. I’ll refer to Forge/Minecraft modding as MC and “us” as Stonehearth modding, including the official way (using given lua APIs) and semi-official ways (exploiting existing APIs and bending them with some monkey patching or similar).
It’s not comparable, not really. It’s a different… environment, a different mindset. In MC, you don’t have any real API at all, so people made them themselves by rewriting the engine. That’s possible, albeit annoying, it being Java and all. There’s a huge, dedicated community devoted to pushing boundaries, modifying the core engine and making the API better.
There’s no such community in Stonehearth, there’s only a few people that are willing to push boundaries or develop new things (as in, code-wise). It’s not possible to modify the engine at all, there are some constraints that you have to adhere and that cannot be circumvented. The game does offer a modding API, through which all content is routed. This has advantages, because it means the engine needs to be somewhat flexible, but also a disadvantage, because the engine will only feature whatever feature was required for the core game and/or maybe on a request by the community.
So while you can modify the engine directly in MC, you can only talk to it in Stonehearth. Radical changes, or insights, of the engine are impossible. For example, the game has a tickrate of 200ms - that can’t be changed. If you require more updates, or finer updates, it’s not possible to modify the engine to do it, because you can’t and there’s no API/lua binding to do so.
There’s also vastly different mentalities. MC is a lot more classic, code-driven development. Therefore, the API is quite rich in functions and helpers (… I assume, I have not much experience) and interfaces and what not. Stonehearth aims to be data-driven, which means that ideally, you won’t have to touch code at all but just write a rather huge JSON file. I’m more a fan of the first approach, as the second can generate ridiculous amounts of useless data (for example, see the (early) camping JSON files - they’re not really readable, nor are they understandable without looking at the code, so the whole benefit of having it as data instead of code is kinda defeated in my opinion).
So the short answer is, if you merely wish to copy something that already exists (creating a new furniture item, or clothing, or item), then that’s easily possible because of the data-driven approach. There’s little to no documentation at all, however.
If you want to go deeper and add new features to the game that are not implemented or have been prepared by the devs, you can, to some extent, make them yourself. If it’s a simple component, observer, buff, profession or what not, then that is more or less easily doable, to some extent with data alone too. However, more complicated things, or more specialised things, are frustratingly not possible at the moment. A quick list of things that would have been handy as hell in the past, but are not available:
- ability to create, modify and assign models/matrices at runtime. This would be really handy for customization stuff, be it different/random colors on an item or procedurally generated models. I’m aware that multiple models may be loaded onto a model variant, but that is a simple merge of two models. I can’t tell it to place the set of ears three voxels higher or lower, or even have them upside-down, for example.
- synchronisation of client and server and/or client and GUI. Because cross-domain communication is done with polling, it’s near-impossible to get stuff to sync up properly.
- fine control over animations and effects. In GMod, I can tell each bone each frame where I want it to be displayed. In SH, I can only tell it to play an animation. When it plays, with what speed and what frame it is at is entirely in the engine’s discretion. I have zero control over it. For the trains, I would have wanted to control the animation myself - so I could have the train’s wheels turn appropriately to the current velocity. It’s part of the reason I’ve stopped work on the project and kinda gave up Stonehearth modding.
- lack of documentation, for both code and architecture/processes. For example, at one point controllers got introduced and replaced some previously existing structures. So are they to be used now? What can they do? What are they for? Why is thing X using a controller and thing Y is still a normal class? Stuff like that drives you insane if you aim for a pretty solution, rather than the first one that “works”.
So in the end, whether the game is ready for modding depends on what you want to do. For me, it’s not. It was cute at the beginning and I was able to do stuff because I knew how it worked, but it’s been too limiting and I’ve gone for a while. When I came back, the game had so many new features and approaches, some of them contradicting each other and previous ones, that I simply didn’t know whether what I wanted to do was A) even possible to achieve, B) was already done somehow/somewhere and C) was worth the effort. Because the development schedule is not completely open, it’s not clear what they’re working on the current/next Alpha. So whatever you spend a month working on might be in the next Alpha already anyway.
Once there’s a proper documentation, the engine is more accessible and the performance has improved, I could imagine doing stuff for SH again. But as a pessimist, I’ll say that won’t happen before the release, i.e. after the beta.
I guess if you want to ask for something specific, rather than an overview, you can always ask and I, or others, can tell you whether there’s a feasible way to do it already or whether you need to do your own research… or whether it’s impossible altogether.