Paul the Great's modding vertex

How do you intend to translate that grass eating thing to the snow and desert biome?

Plants, including grassy-type plants, still grow in those biomes (year-round, even!), so it’s mostly a matter of adjusting spawn/growth rates and making the color and possibly model variants match the biome.

Oh, so you are actually adding grass itself? I thought, you just meant the green cubes :smiley: Well, then it’s an entire different story. Way to go, dude, way to go :+1:

Thanks, I already got it working, just need to implement seasonal/weather effects and then someone else is making the models. I also got nearby water affecting crop growth rates, next step there is to extend it to wild/cultivated (non-farmed) plant life.


My latest additions to ACE’s codebase are a generic heatmap service (to replace the existing appeal heatmap) and a concept of “wilderness” that’s primarily used for modifying the spawn rate of trapping zones but can also be integrated into other entities (imagine a bird bath that, if there’s enough wilderness around it, periodically does an effect of birds or other animals coming up to it).

The heatmap service allows you to set up a heatmap by providing just a few settings and functions in a Lua file and adding the proper index to stonehearth_ace/services/client/heatmap/data/keys.json. The appeal heatmap was the first converted into the new system (plus a small fix for it being offset by 0.5 on the x axis for some reason), and naturally I made a wilderness one as well. The third example heatmap is for “ore detection:” it shows where ore veins are underground, with a brighter color for ore that’s closer to the surface or more numerous (my idea is that this will detect ore up to 10 voxels deep, or 20 if you’re playing as dwarves or have a particular town bonus, but of course that’s all subject to change). It does not show what type of ore, but it’s still a little cheaty because you can use it very effectively in slice mode (however, it doesn’t detect ore that you wouldn’t be able to see normally because it’s too far away; so it’s no more cheaty and rather simpler than preview-mining everywhere).

These latter two heatmaps are square rather than circular. For the wilderness one, this was important because I wanted the calculation to be very similar between the heatmap and the wilderness_signal_component which is used in trapping zones and is necessarily rectangular (it doesn’t just display in a square, it also looks at all entities within a rectangular region centered on the point [for the heatmap] or region [for the trapping zone] when calculating wilderness values). For the ore one, it just made sense because it’s a world of squares, and the ore veins are all rectangular.

This segues nicely into the concept of wilderness. The primary goal was to make trapping zone spawn rates more reflective of the area they’re in. In the base game, the only alteration that’s made to spawn rates is checking what the majority ground material is: if it’s “rock,” the spawn interval is between 70-100 in-game minutes; otherwise, it’s between 50-70 in-game minutes. The new wilderness_signal_component factors in dirt, grass, plants, and “animal”-kingdom critters (not pets, pasture animals, or farmer crops) as positives and buildings as negatives. “Mobile” critters are equipped with a separate wilderness_component that periodically checks to see if it’s within a wilderness signal region (or if it’s left one it was in before) and updates those signals accordingly. The wilderness_component can be attached to any entity to specify its wilderness value (and setting is_mobile to true will make it periodically check its location).

Raw default wilderness values are as follows: 5 for an animal, 1 per voxel in the collision or destination region of a plant, and -2 per voxel in the collision or destination region of a building. When a sampling region is passed to the wilderness_util.get_value_from_entity(...) function (as it is with the wilderness signal and heatmap), only the part of the building or plant region that intersects with the sampling region is counted. For both the wilderness signal and heatmap, the sampling region extends past the visible bounds of the region by a set amount to take into account nearby entities. Additionally, dirt terrain and grass terrain add 0.01 and 0.02 wilderness value, respectively, to a voxel. The total value of all the entities and terrain in a sampling region is then divided by the flat area of that region to come up with the actual wilderness value, which is then compared to a table of “tiers” similar to the tiers of appeal (and to the water affinity tables used by the water_signal_component and growing/evolving crops/plants).

In the future I hope to integrate humidity and temperature a little more mechanically with biomes, seasons, and weather, but in the shorter term I at least want to get biome-specific spawn rate modifiers implemented (e.g., you shouldn’t need the same number of big trees in the desert in order to attract the local wildlife as you need in the temperate forest). I already have a modifier for the type of animal you’re trying to trap (critters require less wilderness than normal, bugs require a normal amount, and big game* require more).

*Oh, did I forget to mention that I also added a level 6 tier of trapping grounds for big game? Currently only deer (and somewhat rarely “horned deer”) will spawn there, but we’re planning on adding bears, and perhaps wolves also.


the innter asterix and obelix lover in me needs to ask: any chance of wild boar for that large trapping grounds :stuck_out_tongue: ? the big variety? (inb4 monster hunter sized meals :stuck_out_tongue: )


Sure, not my department though. :stuck_out_tongue:

Check the top post for my new mod: What’s Stuck?


What’s Stuck? now reduces reporting false positives by waiting “10m” to report new things as stuck. I’ve also removed the Buildings tab for now since I was running into problems there, but I added an Enemies tab in its place to alert you when enemies can’t path to your hearth (since stuck enemies can be a significant source of lag).

1 Like

Here’s a new thing. It’s not going to look perfect because it’s trying to compress a graph into a tree, but for our purposes it should work fairly well (and anyone else can mod it to display differently/better): multiple job requirements!

The plan so far is to include this with ACE. Not the ridiculous requirements for a potter for the Dwarven kingdom, but the capability to specify multiple required jobs for a hearthling to be promoted to a particular job. You can even specify some of those requirements as only needing "one_of" them. The first required job specified in the "parent_jobs" array will be used as the organizational parent (e.g., in this case the mason was specified as the first of the potter’s parents). Perhaps a cook should be promotable from either a farmer or a trapper? That’s now a possibility!


So this would enable things like needing both blacksmith and knight levels to become super_blacksmith? Awesome!

Yup! Or footman + engineer to make some sort of combat engineer who crafts and uses ballistas, wears armor, and repairs things in combat.


You guys forgot the most classical example? Knight+Cleric = Paladin :slight_smile:


So, what I’m currently working on is a bit of an undertaking, and it will hardly get used in ACE, but I think it should provide a lot of opportunity for future modders: it’s a generic entity connection service. This service won’t exactly “do” anything on its own: it merely allows you to specify ways in which entities can “connect” to one another, and then maintains graphs of those connections. However, you can then build other services/systems that make use of those connection graphs.

The specific one I have in mind for ACE is a “mechanical” system that allows you to translate mechanical power from something like a water wheel across axles/gears into something that can consume it, like a grain mill (having a water wheel power an enhanced workbench is something we’re currently planning for, if I recall correctly, the engineer in a town that selects a particular Tier 3 bonus). Could this particular objective be achieved in a vastly simpler way? Sure, but then the infrastructure wouldn’t be there for doing similar mechanical things. And it wouldn’t be there for doing other connectivity things, like, for instance, redstone.

If I succeed with this endeavor, ACE will contain an easily expandable system for using entities to create/translate/consume mechanical power (even if it’s only used for a handful of entities with limited interaction), as well as this system being an example for creating other systems that use the connection service.


Honestly this sounds the coolest shit ever to me Paul XD
(back in the days when minecraft was still fun and not owned by m$, there was a mod with mechanicle stuff too, that had promise back then except the guy who made it did -not- like compatabillity…with anything. so i never actually played with it. but mechanicle power transmission is a thing i love :smiley:


Paul’s been awfully quiet for a few months, hasn’t he? I wonder if he’s been working on a new mod after ACE 0.9.3 went live a little while ago… I bet we’ll find out real soon!


Nah. I bet he was just kidnapped by aliens. It’s always aliens. You just can’t be too careful these days.


I would say I’m more likely than aliens to kidnap Paul :eyes:


Oh no, that must logically means that @DaniAngione is an alien. (Flawless logic)