Requests from modders to devs for 1.0 and 1.1


Yeah, I know. Actually, I don’t need a fractional hole in the wall, I just need some parts of the wall to disappear while the voxels are considered absent for pathfinding’s sake (a cutter with no visible effect and a shader allowing to remove parts of a wall via z-fighting check would do).


You previously had supercharged debug tools: a lright-click menu that allowed you to promote or level up hearthlings, make them hungry etc. I don’t know wether that is possible nowadays through the lua console, and if so, how to do it, but if not, please add this in for testing purposes.

I will also add my support for seperating the job roles/material tags/other similar cases into a list, rather than a space-seperated-string.


with the debug tools mod toggled on in the mods menu, shift left click your hearthling. you are welcome.


Edit: this got implemented

In the
function PopulationFaction:_load_traits()
Change the
self._traits = radiant.resources.load_json('stonehearth:traits_index')
lo load a kingdom based trait index instead (probably from the kingdom description json)

Not all kingdoms go well with all traits. Some does not have a few professions, other are not even humanoid and can’t have “magnificent beards”, etc… Many wants new traits.
If we could set our own indexes it would be possible to control those things in a mod friendly way. (Right now, if I remove or add something to my kingdom, others will suffer those changes too)


Will the modding guide ever be updated?

There’s a whole lot of sections that are referred to in the Table of Contents sections but don’t exist. I can understand that everything wouldn’t make the cut, but I’m hoping it gets a bit more filled out. And if new sections aren’t ever coming, maybe the links to them should just be removed :glum:

Also, the “Basic Modding” link from the “Modding Guide” Table of Contents doesn’t work even though that page does exist.


I was planning on pushing most of the basic guide that’s left soonish, hopefully after our next push to unstable (except the art guide, still no progress besides a minor update to include Goxel in the list).

Still nothing interesting for those of you that already know how to mod. I moved some things around, pages are connected so I’d rather push many at the same time (tried to keep the walls of text to a minimum / be more telegraphic, but still sometimes I reiterated some information).

And might still need to update certain things since some of the requests from this thread are coming, so I was waiting for the right moment so that I don’t have to update it later…


Edit: this got implemented
When you start a new game, ploping down your flag, along with it a hearth(firepit) is spawned.

Problem is, it is hardcoded. Every kingdom is forced to have it, and the best you can do is overwrite it with another qb, which ends up affecting everyone else.

My suggestion it to change the function GameCreationService:create_camp_command(session, response, pt) to take an entity defined somewhere else (probably kingdom description) so we have control of what it spawns.


seconded actually. that way i can make a more campfire-y-campfire for a start.


I agree that ideally this would be customizable, but I know there are at least a couple places where the game looks for the actual firepit/hearth entities. The ones I can think of are the town progression quests, which may or may not matter for a custom kingdom.


Landmarks are restricted to a single qubicle model.
It would be nice if it could use an array and chose randomly from it, so we could have small variations without the need to create a whole new landmark.


I’m not entirely sure it would work but if you declare several different landmarks as aliases (like the summon stones ones) and then you create a loot bag with your different landmarks - and finally you create a landmark that has nothing on it but a single voxel to spawn such loot bag…

I dunno if it would work but you could “theoretically” spawn different landmarks through the same landmark by doing this.

… Of course this is quite useless because you’d still have to create several landmarks nonetheless :jubilant:

BUT talking about variety and diversity, that could - hypothetically - allow you to create “composite” Landmarks made out of several other landmarks… For example, the farm and ruins one, imagine that you have 5 abandoned house models and 5 abandoned farm models. You create 10 landmarks but by spawning them through loot bags you actually allow up to 25 different landmarks to appear.

This is a tiny example but that power can be used to a lot more like~ randomly generated dungeons with randomly generated rooms; larger surface towns with different buildings/placements; etc.

Assuming my loot bag idea works, that is :merry:


That was my thinking as well, although the idea wasn’t properly formed in my head yet so I held off posting until I could picture it better hahaha.

But yeah, I can see how that would be a cool and powerful method to spawn very complex landmarks – the idea of building randomly-generated dungeons gets me absolutely salivating!

Another thought, which I think I’ve mentioned in the past, would be to use summon stones for new landmarks as entities within the original landmark; using the same method that places trees and plants randomly. I don’t know if that’s the same loot-bag system you describe or a slightly different method, although the effect would be the same. The key difference is that in your method the entire landmark would spawn in a single large step, whereas my alternative idea would spawn the landmarks over stages (I think each summon stone would proc individually.) The benefit of that option is a possible CPU saving (less changes to compute at once/spread the load over smaller steps) and the potential to watch a landmark grow in front of you (e.g. grow an Yggdrasil branch-by-branch); although a big downside I can see is that one sub-landmark may block the spawn of another… although as far as I can tell there’s a chance that would happen even if all landmarks are spawned at the same time.

I agree it wouldn’t be a time save if you only wanted to make, say, a rock pile with a couple of different configurations to choose from; in that case it would definitely be easier to use aliases if possible. However, for really large/ambitious projects (e.g. the dungeon idea) this would probably allow a lot of shortcuts, e.g. by using randomised rotation and a couple of different loot tables (e.g. one table only for dead ends, and one table for rooms with connections to all sides, one specifically for hallways, etc.) you could easily enough build very different looking dungeons from only a handful of parts. That’s just using a pre-set floorplan with some of the rooms being randomly rotated while the hallways remain fixed – if it then got into crazy levels (rooms which spawn hallways which spawn another room from a loot table so you could potentially get more hallways off it, and so on…), then you end up with something that could almost be a game mode in its own right. Dungeons could become truly massive, adding a whole layer of gameplay from exploring that dungeon.


Edit: this got implemented
Change the evolve component to accept either an uri or a list of uris, allowing the current entity to evolve into a random uri from the list.
Also, a “chance to evolve” value, where we could control how likely an entity will be able to evolve. (e.g., a tree could evolve only to small size, or reach big sizes )


Ohh, that’s an awesome suggestion!

Seconding it!


A “Flag” of some sorts to allow (or prevent) Landmarks from spawning according to game difficulty.

Landmarks with monsters are a cool idea but depending on how they work, it might be better to not have them on Peaceful games, for example.


Edit: this got implemented
This one is a repeated suggestion, I deleted the old one and reworked it to be clearer and with a code sample.

In short, the minimap colors are hardcoded, mainly the water color and the trees colors. With this change it will be possible to change those and also the other colors of any terrain elevation without needing to match the block color.

First example, the canyon map. It has orange mountains, but in-game the top is covered in grass. So I changed the top elevation color to reflect that, and tone down the water color.
screenshot%202018_10_25__15_30_53 -> 580889107

The archipelago also has grass over the rocks, but only in the first/bottom layer (the darkest rock), so I changed that gray layer color and also added a little of green to the ocean color.
screenshot%202018_10_25__15_42_03 -> 1171958799

The swamp currently already modded this in, but you can see how the map would look without any of the lua changes. There, I just changed the water color.
screenshot%202018_10_25__19_31_11 -> 1611624054

For the trees I made up this example biome (it is just the temperate) just to show how a tree color can affect minimaps too. In this, trees are now pink.
screenshot%202018_10_25__16_12_24 -> 928426198

The code is super simple, and backward compatible.
First, in the biome.lua at _generate_color_map, just a few changes:

function Biome:_generate_color_map()
   local palette = self._palettes[self._season]
   local minimap_palette = self._palettes.minimap
   local elevations = self:_get_terrain_elevations()
   local color_map = {
      water = minimap_palette and minimap_palette.water or '#1CBFFF',
      trees = minimap_palette and minimap_palette.trees or '#263C2C'

   for _, elevation in ipairs(elevations) do
      local terrain_type, step = self:get_terrain_type_and_step(elevation)
      local terrain_code = self:_assemble_terrain_code(terrain_type, step)
      local color

      if terrain_type == 'plains' then
         color = step <= 1 and palette.dirt or palette.grass
      elseif terrain_type == 'foothills' then
         color = palette.grass_hills
      elseif terrain_type == 'mountains' then
         color = palette['rock_layer_' .. step]
         error('unknown terrain type')

      if minimap_palette and minimap_palette[terrain_code] then
         color = minimap_palette[terrain_code]

      color_map[terrain_code] = color

   self._color_map = color_map

It will now read a new minimap palette from the biome json, and use colors from there for the water and trees, if the biome does not have that new json piece, it falls back to defaults.
Then it takes colors from different elevations based on the blocks colors as usual. But it will now overwrite those with minimap palette colors when those exists.

Then, the next file is the map.js at _drawCell. The function is big, and all you need is to change one line, so I will not paste the whole changed function here. Just go inside it, in the forest_density condition, in the line:

	context.fillStyle = '#263c2c';

replace it with:

	context.fillStyle = self.options.mapInfo.color_map.trees;

So it now can read the color set in the previous file (either a user defined color in the json, or the old default)


Then if a biome wants to change its minimap colors, all the modder needs to do is add a minimap table inside the palette, just next to the seasons palettes, with the elevations and colors he wants to replace, for example:

	"palettes": {
		"spring": {


Edit: this got implemented
We just got the drinking animation, but we can’t use it.
An option to chose which animation to run for specific food items would be nice. Right now it is hardcoded at the eat_item action.


Sorry if I’m late, but I totally love the idea of material_tags as an array! This will definitely improve my Better Storage mod.

If I have a request to devs, it will be a way to filter items which DON’T have some material tags. For example, in the current game an item with tags “stockpile_plant seed” will be stored in a filter “stockpile_plant”. Okay but if I want to store in “stockpile_plant” only items that miss other tags? Or just miss the “seed” tag? Could you find a way to do that ?