Requests from modders to devs for 1.0 and 1.1


#68

Thanks for the suggestion! Unfortunately this would be a pretty large change, as we have a lot of assumptions in the code that assume a voxel is the smallest unit.

Also thanks to everyone for their suggestions and requests :slight_smile: ! Just wanted to let you all know we are looking at these and seeing which ones we can do for 1.1.


#69

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).


#70

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.


#71

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


#72

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)


#73

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.


#74

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…


#75

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.


#76

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


#77

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.


#78

From what I searched only those quests use it. It is expected from someone modding a new kingdom to have their own campaigns. I only see modded kingdoms using asc/rayya/na campaings as placeholders :slight_smile:


#79

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.


#80

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:


#81

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.