SHED 1.3.2 (Unofficial) +Effect Editor!

Yep, probably right. Sounds more sensible.

Hang on a minute, that mod looks awfully familiar.
Oh wait, It’s mine. That’s an awesome idea though.


Ok, fun’s over everyone! :smile:

Around the 30 minute mark of the last stream (Twitch), we find that SHED stands for “Stonehearth Editor”.


I’ve played around with the idea of extending Jofferson with features like these, seeing as Jofferson can already read and “understand” mod objects. However, there’s some… issues:

  • Entity references are just pure nightmare stuff. It’s sometimes not possible to determine whether something is a missing reference or just a proprietary name.
  • It would need to be modular as hell. The huge part would be the components part, it requires one module per component. These would have to be maintained properly too, as components tend to change in-between versions. Because every component is different, it’s very hard to have a one-size-fits-all module to cover them; the best you can do is a module that takes a “component schema” and tries its best to display this data somehow useful.
  • Most components aren’t (directly) visible - there’s nothing you get from an editor that you wouldn’t get from just editing the values manually.
  • It’s almost impossible to have a visual editor outside of the game. For example, to have particles, you would need to imitate the particle engine Stonehearth uses in a ridiculously precise way. The same applies for about everything: Model viewers don’t get the lighting properly done, effect editors won’t get the effect feel correctly realised - the list goes on.

In the end, I would opt for some sort of in-game editor, i.e. an editor that is not a standalone but rather uses the game directly. That way, you don’t only have access to all the assets but also have meaningful ways of displaying them.

This is, however, at the moment not really possible. It’s possible to fake-reload JSON files in the lua side, but the engine caches them too - so until there’s some sort of reloadAsset() button, I doubt that there can be a truly complete editor.

Then again, I’ve never been a fan of something clicky-colory if the solution was to open notepad and change one number. It’s much more hassle for me, so I might not be the best person to ask about how useful this could be, in whatever state.


@Tom mentioned it in a stream recently (see OP)… I’m guessing “Stonehearth Editor” or similar. Basically official or quasi-official mod tool(s). If you’ve seen any of the streams, he’s occasionally grumbled at how many steps they need to take to add an item (or w/e) into the game, so if nothing else I expect SHED to go a long way towards automating this and doing all the tedious copy/paste/etc bits.

1 Like

I’d like to launch Microworld from within SHED.

However, you’ll have to make the qb files and animations with outside programs, and then browse to your files and copy them to your mod folder. Initially, that’s inevitable.

Quote from @wizaerd (May '14):

Edit: it’s a 64bit build? I can’t test it. Maybe in the future… :disappointed_relieved:

1 Like

Yea, same problem for me. Where do you exactly add that filepath?

1 Like

In the js/view/mod_manager.js file. I tried adding it between lines 188/189, in the possible_paths array.

(But in the end I wasn’t able to run it, apparently because it’s for 64 bits or something :disappointed_relieved:)

Thanks for the comments, everyone! I want to reply to a lot of them later tonight but just wanted to say that I just pushed a switch to a 32-bit version. That should take care of you, @Relyss.


@RepeatPan I want to build something useful but I want to do it in a way that’s fun and challenging for me. Writing a mod that uses the actual rendering engine to get perfect visual results for something would be ideal, but tedious for me.

I do want to avoid writing useless stuff or creating more problems. A text editor inside SHED probably isn’t the best idea, but a particle editor in WebGL sounds awesome and would probably get you results that are close enough to really help.

I’m not sure what I want to do with entities/components yet. I need to learn a bit more about them first.

@Relyss I was thinking about something like a test world launcher. As long as that’s all achievable via config files, it shouldn’t be too hard. That might be one of the next things I try, depending on when Radiant releases whatever they were talking about recently.

I’m working on some more improvements and will post an update when I’m done! :slight_smile: Thanks again for all the comments.

1 Like

Updated. @Froggy, @Miturion, @Relyss I believe this takes care of your outstanding issues. It now looks for a path, but if it can’t find one you can go into settings and set it yourself.


  • Added settings page so you can manually configure Stonehearth installation folder
  • Cleaned up some UI

They should have written the engine, then the editor and finally the game :confused: one of the downsides to kickstarting I guess…

The trouble with that is that the editor would have been useless after a month. As the game is developed often things have to change to make things work.

Edit: Software development is a whirlwind of changes and refactoring. Building the editor first might save some time initially because you’ll be able to quickly perform common actions. However, as the game features change and evolve, the editor has to evolve right alongside. This creates lots of additional work and probably wouldn’t be worth it until those types of changes really slow down.


how is it additional work if the goal is to provide a mod-able game with an editor? My suggestion nets out to less work but more of it front loaded. Once the editor is done, making the game becomes trivial. (I armchair dev in this forum a lot and I rather not, so I’ll just stop here.)

:slight_smile: The additional work comes from changes. Let’s say the editor is fully built and the game is being developed. One day Radiant decides to add enchantments to weapons. Now they need to go into the editor and make it support enchanted weapons. This isn’t that bad right at the start. You added a feature and updated the editor.

Except now let’s say the enchantment feature changes three or four times because it was unbalanced, was incompatible with some other new feature, or just sucked and needed redone. Each of those changes requires you to also change the editor so it still works. If you build the editor at the end of the game, then you don’t have to go through all those changes and you just get to do that work once.

It sort of comes down to budget and time. With a small team on a limited budget, they can’t spend the time making changes to the editor all the time when they can develop pretty quickly without one. Plus, maintaining an editor might increase time between alphas from 1 month to 1.5 months. Over ten or fifteen alphas, that adds up to an extra 5-7 months! Might be a bit extreme, but the point is that everything would take longer. With a larger budget this might be OK, but I think Radiant has found the right balance between making the game moddable and making the game moddable with really awesome tools.

Except for maybe a few things (test worlds!) I think most people would prefer features first, modding tools later.

You misunderstood what I wrote… it sounds like you haven’t done much interactive programming. If the editor was written in the engine, most of your arguments don’t make sense. :smiley:

There are many old school games with editors built into the engine, if it’s done properly it is LESS work. It’s really that simple. There is a huge body of evidence for this in computer science literature, the history of REPLs and smalltalk/squeak are good things to google if you’re interested.

I have been working in software for 17 years. Using REPLs/interactive development is just faster. When tooling a system from the ground up, it is often times worth it to build tools first… this is just common sense really, look at any wood shop. But because this game is being developed publicly and crowd funded the best technical solution is not always the best solution for the problem at hand. As evidenced by the lack of scaffolding in mines, for example. I really like the game so far, and I respect that a lot of hard work is going into it… but that doesn’t change which methodology is known to work better.

Not saying you’re right or wrong, but if (when?) Radiant Entertainment make their next game, they’ll at least have the experience of Stonehearth to know when they might want more specialised tools like you suggest.

However, I would say that, notwithstanding the devs’ experience in non-gaming software development, they’re still learning a lot on the job as it were. I would be surprised if their efficiency does not improve in their next title, and indeed improve during the development of Stonehearth itself.


Yes and no. While this seems like a rather primitive but sane flow (create tools, use tools to build other tools, use other tools to build final product), it wouldn’t have worked. I don’t think there wasn’t a fixed, precise software design in the beginning (and there doesn’t need to be one for a game, in my humble opinion) so creating an editor would have proven difficult.

While having an editor might would speed up development, it’s nowhere as useful as having actual gameplay. We’re talking about plaintext assets here: lua, JSON, HTML, JavaScript, CSS - it’s not like to change a model we all have to open a hex editor and flip bits. Creating and editing assets is easy enough - surely it could be easier, more comfortable and all that, but it wouldn’t justify the effort. I don’t think Radiant would have, in the course of their development, saved more time using an editor than building and maintaining it in the first place.

On top of that, having an official editor will cause more work (not only maintenance but also support) and it has the danger of becoming dependent on the editor, as in “Well, we can’t improve our entity system because somebody would have to rewrite the editor/because the editor uses way X”. Without one, you don’t have those issues.


Yes, I agree very strongly with you here. This is really the only counterargument needed. Your other points are also good.

I tend to sound more negative than I intend to. I would have done something else personally, but I rarely finish my coding projects so their decision seems completely reasonable to me :smile: