redram

There is no tracking of fuel vs items in the kiln. The fuel cost is the same if you have a bowl, or if you have stacked the kiln floor to ceiling with bricks. This may change in the future. But for now it is what it is.

I think it's somewhere in the 18-20 area, iirc.

1.20.4 is still a 'release candidate' version, meaning it could still have issues, and should be treated with caution. So you should probably make a backup of your save if you intend to try it out on a 'long term' world.

At some point we will add glazing, which will expand the color options. But this will be applied after the bricks are made, not mixed in with the raw clay. And it will use the types of ingredients one would use irl, so mostly metal and mineral powders. Possibly plant-based ashes. We'll see.

For folks having this problem recently, what version of the game are you using? 1.20.4 was supposed to have fixed the insta-firing. But 1.20.4 is currently in 'release candidate' mode, so your game probably won't auto-update to it, you'd have to do it manually. If you're on 1.20.4 and this is still happening, that would be good to know. Otherwise if you're still on 1.20.3, know that it will hopefully be fixed in 1.20.4. Aside from the insta-firing issue, some clarifications: - The kiln should do a block damage check every 168 hours (7 days) of burn time. So you should be able to run at least 7 batches before it does a check for damaging blocks. This may have seemed erratic previously, because the issue with insta-firing was that the kiln door was not properly resetting it's timer (I'm told - I'm not a coder). So it would be counting up hours when it should not, you'd go to fire a batch, it would already have counted up 168 hours despite nothing going on during that time, and then boom, insta-fire. iirc a batch should take about 16 hours or so (including warm-up time). The reason the check interval is 168 hours, btw, is because it inherited this from the cementation furnace. - The fuel piles do not have to be full stacks, you just have to have *some* fuel in all 9 spots. iirc you only need to fill them slightly over halfway to run 1 batch. If you over-fill the piles, you'll be putting hours on your kiln door (hence, advancing toward damage time) unnecessarily. - Yes, the doors' positions at the moment of finish check time is what matters. Trying to keep some running total of states on an hourly basis was deemed too complex for the time we had this update, and possibly a limitation of the game, due to chunk unloading, and moreover the possibility of hatches being in different chunks than the doors. And honestly, it's unnecessary. It's just meant to give a simple way to control the color result, without having to create a raw clay type for every single fired color. We unfortunately did not reach all our goals for the beehive kiln this update, so it is true that some functions are not optimal. We hope at some future time to make the mechanic more flexible in terms of fuels. So that you could mix fuel types, or run the kiln without having fuel in all 9 spaces. We may also distribute the block damage more over time, with the caveat that broken blocks would not fully halt the firing, but slow it down instead (up to a point, after which it would stop). These things probably will not happen any time soon, and when they do the cementation furnace will likely get the same changes. But I thought I'd clarify things for those of you who were wondering. And please do let me know regarding what version you were playing when you had the insta-firing issues.

The new header bricks (the smaller kind)

Yes, Thorfinn is correct on both counts.

Ya generally speaking, in any situation where the expected interaction is not working, it's best to try the alternate keyboard key. So if you were expecting shift-rightclick, try cntrl-rightclick. And vice versa. That's quite often the difference.

This is pretty much a matter of tuning. What was done, was that it was made so that mobs - upon being damaged, if the player is not in their detection range - they run in a random direction. This is meant to prevent what used to be the case, where they would just stand in place and get hit over and over. At least if they move immediately, you have to re-adjust your aim. So, it's kind of a matter of finding the perfect balance of detection range and targeting (in)accuracy. Right now our focus is still on getting the rest of the update (the story part) completed, so we're slower than normal on addressing the bug reports this time around.

Yep, still planned. Someday.

This is correct. Original plan was to require you to use a stick to get termites out. But it went the standard drops-when-broke route for expediency. Maybe someday the stick method might get implemented.

Yes, we have plans for more immersive glass mechanics. It's just not a priority right now as glass doesn't play much of a role in the game. Once we get to alchemy, it becomes much more relevant.

To address your concerns @Streetwind, it will not be a thing for *all* crops. Just some. For instance any crop whose seed is also the food, it will certainly make no difference (grains). At least some root crops will likely remain basically the same as they are now. The idea is for crops to not all just be essentially reskins of the same thing, with minor variations in temperature and nutrient and so forth. We want them to actually *feel* different to grow, as much as we reasonably can. So server players might avoid those crops which are trickier to grow, but not all crops will be like that - but on the flip side, having a dedicated farmer than can give the trickier crops the attention they need, hopefully will be rewarding. You may even get things like biennial crops that only produce seeds on a second year, but produce a lot of seeds then. We'd like to have varieties that produce better with trellising (tomatoes, cucumbers, peas), varieties that yield a little over time, rather than a large yield all at once (beans, peppers), and more. Right now there are technical differences between crops (nutrients, temperatures), but in the end they all still feel the same to grow - ya stick em in the ground and come back at the end. Variety is what we want, not same-ness. And it goes beyond the plants themselves, we have plans for all kinds of adjacent systems. In totality, it'd be an update on its own probably. Which is essentially why we've avoided much 'tinkering around the edges', so far.

Yes, going to seed will be a thing in the future. It's kind of toying around the edges though, and not really a priority right now, as far as implementing it by itself.

Traps should have a handbook entry now as of 1.19.2, explaining their functioning. It's worth reading. Did you know that if an animal is left too long in a trap it will die?

As I understand it (and I am not a coder) they should, yes. The game does an initial spawn check when a chunk is first generated. But then, over time, it will backfill in mobs into appropriate-condition chunks. That is my understanding of the nuts and bolts behind it. The backfill can be rather slow though from what I understand, so it's probably most likely to happen in chunks you spend a lot of time around, like near your base. Note that goats have pretty specific spawn conditions, mostly involving rather high altitudes, so they can be a bit tricky to find even in fresh chunks.

As far as I know, yes, it also applies to gates. The snow thing should have been fixed some time ago I think (like 2 or 3 versions ago?), not sure how long ago it was that you had that happen.

Currently animal AI will not path over fences. That is, they won't step on them, even if their step height is capable of it. This is why bears cannot get over fences, even though their step height is well capable of it. So as far as fences are concerned, this change will not allow animals to escape. However if your bighorns are in an enclosure that is just 2-high standard blocks, then yes, they could escape. It may well eventually come to pass that some animals (such as deer) will be allowed to path over fences in the future - there is after all good reason that deer for the most part have never been domesticated. But for 'standard' domestication animals, we probably won't do that.

Also just discovered recently that hay blocks had not been given the proper tag to make them fodder for animals. So that's another slip-up that'll be fixed next rc.

Glad you're liking the goats @lastwazy! We wanted to have horns on the females, but Tyron was already pretty overloaded with more critical tasks, so the female horns will have to come in later. The original horn mechanic was set up for deer, who shed their horns and the females don't normally have horns. So I had to get him to re-adapt it once to have the option for permanent horns, and it was just too much to get him to adapt it yet again for females to be able to have horns (but not as big of horns as males) so late in the update cycle. Another day. @Venusgate If you're having problems with breeding or milking the new goats, please do tell more details. What breed(s) you tried, and what food you were trying to feed them, if they were eating the food or not, etc. The more details the better. They should be totally milkable and breedable. If your latest experience was 1.19.7, I do believe the behaviors were added after that version. Now, unfortunately - as I understand it - the legacy bighorns ended up having their breeding behaviors messed up by the new goats' breeding behavior, so if the problem was with legacy goats, that should be fixed in the next rc release. We're not done with planned features for goats (and other animals for that matter) yet. They will definitely eventually be able to be sheared (someday, probably not this update). And Angoras should provide the most mohair of them all I think. You won't see it right now because they can't be sheared so their state never changes, but their model is set up with 4 different states of hair growth, from freshly shorn to overgrown. So eventually when you shear them, they'll look it, and if you neglect to shear them too long, they'll look that too!

No, not implemented yet sadly. And won't be in 1.19. Probably not 1.20 either. We'll need to get to an industrial update probably.

All else being equal, yes. However the hidden variable, which the player cannot know, is the ore density map. This value is modified by the other situational factors that you *can* know. Since cassiterite, even under favorable conditions, only returns a very small range of ppm with almost no nuance, I would say it's likely that your area with much more igneous thickness simply had a weaker base ore map to start with. And so the end result looked similar to another area with less valid rock depth, but a stronger ore map. I would assume large cassiterite veins are factored in (disclaimer, I'm not a coder), but the chance being so small, it shouldn't affect it too much. A large cassiterite vein averages almost 6x as large an area as a normal size vein, but a normal vein occurs 70x as often. The larger veins on average will contribute only 12% or so of the ppm reading, assuming large veins are included in the calculations. In the scope of a range of 0 to .2, it won't affect what you see often. The ppm reading is a result of, among other things, the multiplication of the tries per chunk by the average vein *area*. Small veins that have several tries per chunk will produce many small veins. Generally speaking the larger the vein size (radius), the fewer tries per chunk it gets. So the result is fewer but larger deposits. But this is not a direct relationship in terms of overall total ppm. For the ppm results of the propick, it does not matter whether it's 10 veins of 100 blocks each, or one vein of 1000 blocks. The ppm is the same either way, as far as the propick is concerned. One other detail worth mentioning, is that the propick does not take into account caves. So the more volume of caves in an area, the farther the reality will diverge from the statistical propick results.

Ya each category of verbal descriptors covers a range of ppms. So the ppm result can be used just as you say, to find the best spot of several with the same text description. Though this doesn't work well with smaller deposits like cassiterite and bismuth, since they're so small a range that one decimal of ppm can encompass multiple verbal descriptors. And this becomes less important with ores that have less than 1 try per chunk. Halite for instance, I've seen many cases where the densest center has nothing, but several deposits are in outlying areas. This is, I think, due to the sheer number of lower density chunks. You'll have a better chance at success in 200 chunks with a 1% chance each, than 10 chunks with a 5% chance each, for example.

Streetwinds advice is good, but I'd just point out for clarity that insofar as the ppm mode is a 'statistical' result, while it may be true that in the end all attempts to generate nodes are made randomly even in non-valid areas of stone and y level, the propick does consider the amount of 'correct' stone and 'correct' Y level at the sample spot, and uses this in its ppm results calculation. So if a given spot only has 10 valid blocks of height of the right stone type and y level, you'll get much lower ppm result (all else being equal) than if there were 50 valid blocks of height. So I'd say that the propick does in fact take these into account in its results. Keeping in mind that the ppm result is a statistical average, and the actual nodes generated can thus deviate from this average.

As said, we are aware of both Dynamic Trees the MC mod, and also of the various forks of TFC. And always have been. As someone on discord mentioned, fruit trees in VS are already somewhat dynamic, though not to quite the level of 'the mod'. There's never enough time to put in all the things we'd like, so we try to prioritize those that are the most 'bang for the buck'. And sometimes we take things in stages.