Requests from modders to devs for 1.0 and 1.1

Edit: this got implemented

I already had a few requests floating around, but here are a few that would help me:

We can’t mod the first menus screens when creating a new game in a controlled way. For example, I can’t customize the menus based on if the Archipelago biome was picked, because changing those menus would change for everyone, even when other biomes are picked.

So my idea is to add in the root of those menus a few css classes, representing options picked in previous menus, like biome, kingdom, difficult, etc. This way, I can create a css file and customize the menu for only when the correct biome is picked. Or someone could go with a very monster-like theme if the player picked the hard difficult, or a simple theme adaptation based on the kingdom.

Here an example:

To achieve the above effect, I overwrite the js file to add the css based on the biome chosen:


Then I also have a css file targeting a “archipelago” class. This way, if the player pick the biome, the icons get customized, else it keeps the defaults.
Doing this without having to overwrite the js would be nice


Let’s link this one here I guess: Technical suggestion about entity tags (material_tags)


Edit: this got implemented
The water level is hardcoded. Changing it to be customized by json would be nice too.

I remember Allie showed us a sketch of the arctic biome she draw where it had a big ice cliff into the water, that would only be possible changing this value.


@BrunoSupremo Oh man, I’m imagining a beach biome where the water level is set to 0.01 below the beach level, and then the daily cycle includes screen-edge additions and removals of wet/dry stones at key times to flood/drain the beach. It would probably have performance issues, but it would be really cool!


Oh, great thread. Just noticed it :smiley:

Well, I posted something along these lines just now, so I’ll paste a link here:


I have a few ideas I would like to use myself, but I don’t know enough to successfully code them…

A service to switch between two models ingame:

  • I imagine it based on the harvest service which can switch models
  • either a button in the UI for a user friendly way to inform that this can be done to this entity
  • or this being another use for the harvest tool, which would after triggering switch to model no.2 and only after triggering again switch to model no.1
  • I can see this being an useful addition for general modding

Second idea is a service to give worth to an entity over time:

  • gives the modder the ability to replace the standard value line in the manifest
  • you will be able to set the minimum value and the maximum value and
  • either set the increment or write down all the increments needed in brackets
  • set up a time period (similarly to the evolution service) which will get triggered over and over until hitting the maximum
  • I see this one being useful for entities that can gain worth with age, like for example art
  • might need to be only working when the entity is placed in the world
  • might clutter the trader in sales if abused :thinking:

I suppose it’s a long shot for some of those, and I don’t know what is already available, but:

  • A solid, non-hacky way to register lua functions to be called once per frame, in any game state (i.e. including the menu). Ideally similar in client & server.
  • If possible, allowing the loading of .dlls (maybe via switch in the stonehearth.json/explicit whitelisting of filenames there? I’m not asking for Steam Workshop suppport or similar; this should be a manual intervention at best).
    I’m interested in two things:
    • Expanding lua with self-made binary modules (i.e. does not have to follow the normal binary module convention, so SH-proprietary API to register them can be used, so a method like void registerLua(lua_State*) would be called in the DLL).
    • if possible expanding CEF with self-made JavaScript functions (i.e. the DLL registers functions that should be exposed to JavaScript). For the latter, no synchronization of any kind must be assumed, although it would be nice to be able to into either side of the game (via an API of some kind).
  • Ability to fine-tune animations per script. Combined with 1), this could allow custom animations based on certain things (e.g. windmills turning depending on the wind). Idea. being able set the frame on an object (ent:get_component('animation'):set_frame(12))
  • Might be useful if it were possible to modify the bones per script too (ent:get_component('rig'):set_bone_rotation('post', Quaternion.Euler(0, 90, 0)))

Originally posted in the minor polishes thread, but I think it probably belongs here:

I remember there being a post about this from a while ago, but I was unable to find it. In addition to specifying a mod as “clientOnly” I’d like to be able to specify “serverOnly”. This would, when checking the client’s mod list against the server’s mod list, force the user to disable any mods specified as “serverOnly” that the server isn’t running. All three of my UI mods fail when the server doesn’t have them loaded (because they rely on server mixins/overrides), but because they’re primarily UI/UX mods, I don’t want to force users to use them just because the server is using them - they don’t affect actual game content.


This is a good one to do if we’re not getting access. I feel like this is one of the few things that would be an immense help if fixed up. Good thinking man !

12 posts were split to a new topic: Seasons: What Do They Do? Do They Do Things? Let’s Find Out!

I am still hopeful that there will be some universal way to identify the mod recipes / items originate from. This could be an icon that is called or even a simple mouseover that calls the mod name.


I bet there’s a super hacky way to do that with radiant.get_mod_list(), radiant.load_manifest(...), and radiant.load_json(...) to process through and try to find where something originated, but I agree that it would be nice to have things tagged with the mod name (and then you can look up the mod to get more detailed information about it). At that point it would be relatively trivial to add that information to tooltips, etc.

Here are some thoughts from my own modding experience that would make it easier for me to avoid monkey patching or large workarounds.

  • InsertCraftOrder (adds a button to the workshop view that calls a lua function to insert the new craft order at the top of the list instead of at the bottom):
    • if craft_order_list.add_order (or ideally, add_order_command) returned the order that it created, I would use existing functions to add the order and then move it to the top of the list, rather than monkey patching my own insert_order function into it. Yeah, I could use existing functions without that, but I’d still have to muck around with the order list’s saved variables, and that doesn’t feel good. I imagine there are many other similar places in the codebase where returning created objects would make it simpler to mod.
    • or in this particular case, even just an optional parameter to add_order (and add_order_command while you’re at it) to specify the index would greatly simplify it and could allow for other cool functionality to be modded in, like dragging an item from somewhere directly into a position in the craft order list and creating the order there. :slight_smile:
    • the other issue with this mod is that the base game’s App.StonehearthTeamCrafterView is loaded so late and takes so long to load that my mod gets loaded before it! That’s right, we’re not just talking about my mod being loaded before other mods, we’re talking about the Javascript for it being run before the Javascript initializing the base game’s App views has finished! This is the start of my show_team_workshop.js; I originally had it set to a static delay of 1000ms, but that could still fail on slower computers so I added the repeating check (and my unit frame mod works just fine reopening App.StonehearthUnitFrameView without a delay):
$(document).ready(function () {
    var _tryReopening_StonehearthTeamCrafterView = function () {
        if (!App.StonehearthTeamCrafterView) {
  , _tryReopening_StonehearthTeamCrafterView, 100);

  • UnitFramePlus (enhances the unit frame, primarily with extra buttons to simplify common tasks):
    • this mod is a bit of a mess because it’s my first major mod attempt (before that I was just making personal modifications to @Gruffus’s Town Monitor mod, some of which made their way into my latest Obligation/Timer Tracker mod in a much better way).
    • in order to add UI functionality in the simple/proper way, I have to mixinto some jsons to add a command to hearthlings (to show the promotion tree). This is a very smooth process, but requires the server to handle things that ultimately only affect the client (since the command being added is just to give easier access to client functionality).
    • toggling the “job” activity for hearthlings was pretty straightforward; the tricky part was monitoring when it changed for party members when you had that party selected, so that the UI could properly reflect that change. There are two parts to this that bear mentioning:
      • I had to (or thought I had to) override the entire components property of the view in order to add the bits I cared about. Information about using App.[View].reopen(...) effectively would be very helpful for UI modders. (Can components and other view properties like it be modified at run-time? [don’t get pedantic about “run-time,” you know what I mean :stuck_out_tongue: ])
      • I still don’t know how to observe changes to the selected party’s members (not changes to the membership of the party, but changes to the actual members themselves). My solution is terrible, but it works: if you select a party, until you change your selection a timer will check the party members every 100ms to see if the property I’m interested in has changed from its cached version; if so, it updates the UI. A potential “proper” solution would be to create a sub-view that tracks individual party members and then observes changes and passes the message back up to the main view, like how the Citizens view does it, but that seemed like overkill and probably lower actual efficiency than my stupid way.
  • Obligation/Timer Tracker (gives a simple UI way for viewing, interacting with, and automating common timer-based tasks like consumables):
    • tracking timers is not something that’s easily done currently (e.g., when is a timer created and for/by what controller/service) and would take a big rework to change I’m sure, so my service has to hack into lots of things. Hopefully my next addition, things that show up in the alerts view like trade agreements and goblin demands, will be a little easier to access.
    • I imagine there are a lot of limits on what could be exposed with the time tracker for performance reasons; similarly for the event system, which is what I would normally hope would get used more thoroughly like in .NET or other OO languages/frameworks. I guess I don’t have specific requests here, just wishes that the OO principles I’m familiar with could be used more effectively.
    • one of the biggest things I struggle with actually is HTML/CSS. I have no background in web development, and I get frustrated trying to figure out the exact combination of seemingly arbitrary tags that will get my UI elements to render somewhat close to how I envisioned. In this mod I have a div of the class “stupidContainer” that I don’t think I should need, but somehow prevents a grandchild component from spilling outside of a child component. I also had a heck of a time getting jQuery draggable to work, and ultimately had to counter-intuitively not include the handle parameter for it to function.

I guess my biggest modding requests are things that are probably already being worked on:

  • at the very least basic guides for how to create and modify Stonehearth-style Ember views including how to reference core/mod assets of all types in the different platforms (JS/HTML/CSS and Lua)
  • maybe take a single complex Ember view and its associated Lua references and really break it down and comment the heck out of it: what are these parts trying to achieve and why do they go about it this way?
  • and of course a complete MSDN-style object model reference, most of which can be auto-generated with scripts, but then maybe it can be transformed into a wiki or something so that ultimately the modders can flesh it out more and things like “related articles” and examples can help modders quickly locate the information they need.

It would be really useful for Template creators if the Template menu had some sort of categories or file architecture.

So for example you would have a list of parent categories such as:

  • Classic (The original templates)
  • Mod 1
  • Mod 2 etc

Then selecting each name would expand the list of templates nested within. You could organise this list and what goes where via the mod menu so that even templates that are created by players in the game can be neatly stored away in the templates menu.

I mean, pretty please if we’re making requests :smiley:


In general, I think there will be a vast amount of mods adding variants of existing things like furniture, windows, classes, templates etc. so ways to organise that vast amount of things would be much appreciated.

EDIT: I think it wouldn’t hurt anyone if the starting crop list JSON was reformatted a bit to allow specifying starting crops based on biome as well as kingdom, I’ve already made a mod making it possible and all it involves is slightly expanding one function in the farming service: biome_crops_mod.smod (3.2 KB)


There is an issue with traits which effect hearthling appearance, where the appearance changes do not get applied correctly when the hearthlings are created in the embark/new game screen.

Currently there is only one trait in the base game that does this and I believe this is why the magnificent beard trait is the only trait in the base game that cannot be obtained when embarking, only from new hearthlings joining the town. This will also effect any trait added by mods which effects appearance (shameless plug)

My hypothesis is that when a hearthling is created, its appearance is first randomized and then it’s traits are applied. However, when hearthlings are randomized in the embark window (but interestingly, now when they are first created even in the embark window) their traits are randomized and then their appearance is randomized. This has the effect of undoing any appearance changes made by traits.

If this does not get fixed, then if anyone finds a work around to this I would be very excited. Perhaps by having a handler that triggers when appearance is modified, which can immediately set it back? (although this could cause an infinite loop if two traits both affect the same element…)

Adding to @kaimonkey, more control over traits as a whole would be amazing!

Right now we have the “immigrant_only” tag but I’d love to see something like being able to specify traits by Kingdom, by Roles (inside kingdom) and some sort of trait “percentage” factor so we could have super rare traits or - alternatively - a common trait of sorts (100%) to certain kingdoms and such.


I must be doing something wrong, because I would swear to you that I’ve gotten it while embarking before (because I remember laughing at them being beardless, and having the Emperor’s Epic Beard instead of his clothes)… goes off to try now and get a screenshot if successful

Must’ve been before that got fixed. It has been a while since I’ve actually sat and played