Rainbow Fresh

If this is actually the case for the forge's current fuel's base temperature then I agree it should be looked at. An item shouldn't start cooling immediately the second you take if off the forge just because it sat there waiting for its turn for a while. However for everything else I don't really agree. The only way the item is "already significantly cooled" is when you use a bellows to temporarily heat the forge past the fuel's base temperature. So if you put in black coal (for base 700°) and use the bellows to heat it to 800° for iron smithing, it will eventually drop back down to 700° if you do not re-supply the air necessary to boost the coal's temperature. But it will never go below 700° for as long as black coal is still burning. This is intended and everything else would make no sense. If you'd just need a bellows to give it 2 pumps and be done for the remaining 2.5h of fuel there is no point to have reworked the forging system like this in the first place. It is also not how it works IRL, timing balance not accounted for. Maintaining the right heat for smithing is a conscious effort. I don't know if you have a mod that messes with things or I do, but that is how it already work from my experience. Had two iron ingots on the forge simmering in the black coal's 700° base temperature. Put a third, fresh, cold ingot on there as it didn't fit with the original stack of 4. The entire stack on the forge changes color from "glowing hot" to "just an ingot" in an instant as the displayed forge item temperature snaps down do 500 something. Granted, I did not test taking the fresh ingot off again to see if the underlying 2 ingot would snap back to their previous 700° or not, but the overall presentation of the item temperature did adjust for an averaged-out temperature like when stacking items. Since bellows are already a thing and necessary for iron+ smithing now, broken or not underneath the bellows already fix this issue as well. Just... give the forge another pump before taking off the next work item. Resets the timer guaranteed because temperature is going up again.

Anyone have one of those? Something that doesn't require me to have a 3x3 square of cobble or other non-flamable things with a floating dirt block above? Something that looks intentional and is functional even if built in cramped spaces. On a side note, does the block directly above the kiln need to be free or can I just worst-case scenario slap an iron trapdoor of it and call it a day?

I don't know for sure but I would certainly assume that simply placing a dungeon template via World Edit does not actually register it to any other system in the game; see your already encountered missing land claiming. Would probably be easy enough to test if whatever trigger/NPC (Treasure Hunter? Resonance Archives post-boss?) are supposed to give you a map marker to the location will actually recognize it but my gut feeling says no as structures like this are usually (see TOBG) handled on a deeper level than "place block template". Otherwise a dedicated command for it would not need to exist.

I understand that any further discussion about the intrisic details of the game's inner workings is pointless at this point. The concept of a quiche has been simplified enough and the actual implementation details should a quiche become a thing left open for discussion. However I am going to be petty about it and so I did snoop through the source code, which you yourself can also do for confirmation at https://github.com/anegostudios/vssurvivalmod/blob/master/BlockEntity/BEPie.cs while also looking at the base game assets for, in my test scope, readmeat, vegetables and cheese to have the behavior of the vanille potpie mixed ingredients and a not potpie-able but generally pie-able third ingredient. The pie does track slots, and is as such vaguely akin to the cooking pot, yes. With the main difference being that you do not see those slots, you cannot take out from slots and you only ever insert in a first-come-first-served manner. The important detail as is what I was trying to convey is that there is no logic for a recipe. In fact, it goes even further than I assumed - pie recipes aren't real. Every ingredient defined with pie properties allows the combination of a 4x2 pie of that type. Meaning defining eggs as pie ingredient, I think, automatically makes an "egg pie" a reality, consisting of 4x2 eggs. Pie combinations are just a "steps of insertion" comparison with the pie ingredients defining which category/name? of combination pie they make. As the only example in the game, readmeat and certain vegetables define that they are combinable in the "potpie" category. Meaning that is it possible to make a new combination category "quiche" which could be set on the same chosen vegetables, meat and eggs to allow combining these into a pie. That would also result in you adding vegetables and meat to make a pot pie, then still allowed to add eggs as third or fourth ingredient changing it to a quiche. Though I do currently not remember if the name of the resulting pie is set at adding the top crust or not and it is too late in the day for me to go in-game and confirm. Either way there is no further logic for limiting combination options. The logic is, in fact, so simple that any combination pie can only ever *require* two different food categories of ingredients. Ingredients within the same category (all same-class vegetables, all meats, all cheeses - luckily neither eggs nor milk would have competition here) always mix without changing the outcome. Starting upon adding a second category that is allowed for mixing and shares a possible combination outcome with all other ingredients (your "the game doesn't let you add fruit to a pot pie") the first fitting combination is taken. Ignoring the, again I *think*, automatic all-egg pie that comes with making eggs pie-able, if you stick with eggs, vegetables and cheese from your first recipe (not sure if liquids like milk would even work) there is no overlap here. As meat is not allowed, no confusion with the pot pie. If you were to say eggs, vegetables and meat, the eggs are the required ingredient to change it away from a potpie. So yes, limiting combinations is generally possible. But also, as I was trying to convey from the get-go, *no*, you cannot limit ratios. The resulting pie is solely the work of combining enough ingredients to rule out all other combinations. If a quiche *supports* eggs, vegetable and cheese, because of the currently very limited scope of pie options, *vegetables and cheese alone would make a valid quiche*. The current pie system does not support any more complex than that and is probably the reason we only have one "mixed" pie yet that only contains 2 ingredients, because at 3 the system falls apart. EDIT: So tl;dr. Implementing a quiche that is more than just an "egg pie" is rather difficult with the current implementation of pies and if there is some feature we should really be suggesting, it is a better pie system. EDIT 2: Having gotten curious I just looked at the existing Quiche mod. It is indeed a just an all-eggs pie. The mod also claims you can put eggs into meat pies now without me seeing any patch for that at which point I realized - eggs are in the protein group. Meaning, as per explained above rules of ingredient insertion yes, eggs - as soon as marked pieable - will be a substitute for meat in meat pies and there is no way to circumvent this without making eggs nutrition category-less.

Technically, that exists already - it's the "always passive" creature hostility setting. We'd need separation between monsters and animals for those, yes, but other than that passive monsters are just decoration and if you know they don't do anything they aren't scary even if you run into one in the deepest, darkest depths of a dungeon. Personally, I am always all for more enemy variety because killing my 50th drifter this night just because the rift activity turned apocalyptic gets old real fast. As with multiple other previous discussions though, that's only nice if we do get a surefire way to earn safety in our base. Because even the 50 drifters, bee-lining single file into my blade, disrupt anything and everything else you'd ever want to do in the game, and there is alot of stuff to do at home. So, make the wild land a horrific, postapocalyptic hellscape full of creatures beyond human comprehension that turn even the slightest resin-run into Expedition 33 for as long as I can return home and relax there in-between.

As from your initial opening post: You want there to be a pie recipe with eggs. The Quiche. The thing where you slap 2x dough on a table, slither 4x2 something else on it, top it off with 2x dough and put it in the oven. You have also just confirmed, again, that you are thinking of having "minimum 4 eggs" as the recipe. That is not how pie recipes work in the game. That is how cooking pot recipes work. A pie can take any valid ingredient and the name of the resulting pie is solely on a compared list of all ingredients used. You put in 4x vegetables, it is called a vegetable pie. You put in 3x vegetables and one times meat, it is a pot pie. There is no "atleast 2x vegetables and 2x meat" for a pot pie. Neither can there be "atleast 4 eggs" for a quiche. Either egg has to be the only ingredient, or every ingredient necessary (egg, milk and almost anything) NEEDs to be present in whatever quantity is allowed to reach the requirement of WHICH ingredients are in. So with your original recipe of eggs, eggs, maybe eggs or vegetables and maybe eggs, vegetables or cheese - the only actually implementable recipe of that would be that a "Quiche" pie requires either ANY of eggs, vegetables OR cheese to be present (clashing with 4x cheese for cheese pie and 4x veggie for the vegetable pie) or ALL of those in any quantity, be it 1x eggs, 2x cheese and 1x veg or 2x veg and 1x cheese and 1x egg, both if which go against your "minimum 4 eggs". The only system supporting individual measurements is the cooking pot recipes where you can say "Yes we need a slot of and another slot of egg and then we need milk and then we can take this list of possible fourth ingredient." In order to still make a pie out of it in the way you described, you'd need a new item "Quiche base" or whatever that is made in the cooking pot so you can control the ratio of ingredients, and then use this intermediary item as only ingredient allowed for the quiche pie. EDIT: Also just to clarify, I do agree that having egg-based pies is a good idea. Iirc there is a mod that does it already. Just saying that your specific recipe is not gonna work the way you want it to.

https://mods.vintagestory.at/upgradedlakes

You have given a clear example. 2 eggs. 2 eggs. 2 vegetables or 2 more eggs. 2 cheese, or 2 vegetables, or 2 more eggs. That means for the game, a quiche pie is made with either cheese, or vegetable, or eggs in any slot. That means, theoretically, 8x eggs is a quiche (which is fine and as you intended). That also means, 8x vegetable is a quiche, which clashes with the existing 8x veggies "Vegetable Pie". Same for 8x cheese which would be a valid quiche recipe then and clashing with the existing 8x cheese "Cheese Pie" (according to the wiki that's a thing?). Only solution would be to make it require all ingredient categories to be present, like the pot pie does with meat and veggies. Meaning to make a quiche you would need eggs, cheese and veggies guaranteed. With maybe a same-name-but-different-id recipe for a just eggs quiche. Mixing and matching specific things only in specific quantities (like 4-8 eggs and 0-2 cheese and 0-4 vegetables) or assigning specific slots (1x2 eggs + 1x2 eggs + 1x2 eggs OR vegetables + 1x2 eggs OR vegetables OR cheese) is a feature only of cooking pot recipes. Hence my solution suggestion of making a cooking pot recipe to prepare the quiche base from your very specific ingredients, then using 8x quiche base to bake the actual pie with.

The numbers were, as mentioned, eyeballed. They do not need to be balanced - that is the job of the person actually implementing a system like this to do and testing to prove with possible configurability in mind. I just wanted to convey the general working of the proposed system in an easy manner. You mean if you satiety is at 50% nothing changes and if your satiety is at 100% you get maximum max health regeneration and at 0% maximum loss? Because that would mean you always have to keep your hunger over 50% at all times no matter what or you slowly die. The point is not to make satiety bar even more of a nuisance but instead add a deeper, more complex system that keeps the punishing nature of "not eating food" while shifting away from the satiety bar being the sole indicator of life and death. I also think a lagging delta is more realistic, as you too would not just go from "weak and dying and critically malnourished" to "fit as a fiddle" just because you ate a full hearty stew today.

Making Bellhead Shivers function like Bells is part of Temporal Symphony, which I'd recommend to anyone anyway regardless (but also fits the "not spooky enough" pretty well)

Oh boi oh boi, time to copy paste! Cause I just answered a very similar thread. In order to have the forgiving nature of not-immediate death starvation while still aiming at a punishing, detrimental system heavily encouraging actually eating like a human would as well as trying to avoid softlocking unaware players, how about we tweak the numbers and systems like this: There is still the slow starvation aspect whereas if you reach 0 satiety, you will grow weaker and weaker until you eventually die. Recovery should be harder than starving so we can say -1 Max HP per day vs. +0.5 Max HP per day. Instead of just being a timer that ticks if satiety = 0 and doesn't if satiety > 0 for starvation with a second timer that ticks with satiety >0 and stop with satiety = 0, how about a moving delta; Baseline you neither lose nor gain Max HP (only base HP, not nutrition bonus). When your satiety reaches 0, your delta moves by, let's just eyeball, -0.25 delta Max HP per day. Meaning if you keep your satiety at 0, you will lose 0.25 Max HP per day after the first day, 0.5 Max HP per day after the second, 0.75 and so on. The longer you actively starve, the worse it gets until you will inevitably die. If you get your satiety up to over 50%, you apply a reverse delta. +0.1 Max HP delta per day, for example, so you slowly recover. That also means if you are too far gone already, you will not recover in time before your Max HP reach 0, killing you. For incentive and player control, we could also add certain hearty dishes (tied to the current hunger pause mechanic, maybe?) that give a bigger boost to try and heavily course-correct but only if you actually invest in proper food. In order to not completely screw anyone over who is struggling and didn't manage to get any food for a single day with a permanent drain, there is also baseline correction. Over time, if your satiety is >0 you will slowly, naturally drift towards 0 delta. Meaning if you are a struggling beginner who doesn't get any food for a single day and briefly hits 0 gaining Max HP loss, then struggling to find enough to get reliably above 50% satiety, you will still slowly stop losing Max HP. Not gain any back unless properly fed, but also not doomed to die. As for death penalty; I'd say you keep respawning with half satiety (no free recovery) and the -delta is set to 0 but instead you keep your Max Health reduced to a minimum of, let's say, 25% of the world setting base health. That way you have a small leverage to try and recover while being handicapped enough to discourage tactical food ignorance. As a bonus, because pure penalties are shit, even when at full base Max HP you can retain positive delta up to a certain cap. This allows you stave off onsetting starvation through enough healthy eating beforehand. Natural delta decay will, however, also affect positive deltas so if you do not eat very healthily constantly, you will naturally go back down +-0. Finally, the nutrition system of the game needs no changing imo. Death cuts it in half already. It naturally decays with lack of food. And pre-filling all your nutrition bars gives a bigger buffer to potentially outlast severe starvation where food would otherwise not course-correct your Max HP loss fast enough. That is my approach to your idea of a Max HP-based slow starvation system. I don't really agree that teas should aid with combating starvation. Starvation is because you are critically lacking food and as such energy in your body. No matter how much of a Spiffing Brit fan one is, Tea does not give you superpowers. I can still see it aid with your other suggestions, but not fight off starvation.

Are you using the same type of sand, gravel AND rock?

It is kinda not. Pies have fixed ingredients but not fixed slots. So you'd only be able to say "It's a quiche if it has eggs and potentially vegetables and/or cheese". Not that it needs to specifically has something in a particular order. Following that you could also go 2 vegetables and 2 vegetables and 2 vegetables and 2 eggs to make a quiche pie, because the last 2 eggs are what distinguishes it from the end result becoming a vegetable pie. If you want fixed order/ratios of things, only cooking recipes support that. So you'd need to take a double-layered approach of cooking the quiche base or something and then making a pie with 4x2 quiche base.

Try something like this https://donatstudios.com/PixelCircleGenerator and then just carve out only the top half across all involved blocks. For reference, if you go the finest level a single block is 16x16 voxels. If going that fine looks too detailed/out of place for the blocky rest of the game, I usually use the 2x2 setting for detailing so one block would be 8x8.

All the back and forth discussion aside for now, I still think a more in-depth hunger system is neat and I agree that the mods out there already existing have questionable or over-tuned approaches. We don't need Project Zomboid's whole weight and nutrition system to spice things up beyond "Bar go down. Bar 0 = death". Not to mention even PZ's system only, eventually, pushes the player into the one and only min-max strategy of eating nothing but rabbit all day every day cause everything else is not worth it in the long run. (Atleast back in V41, haven't played the new V42 yet). So a layered approach separating the immediate effects of the hunger bar from the notable effects of starvation is a good idea in my opinion. That said, the previous discussions have brought up a couple valid points so let me throw my 2 cents in aswell: In order to have the forgiving nature of not-immediate death starvation while still aiming at a punishing, detrimental system heavily encouraging actually eating like a human would as well as trying to avoid softlocking unaware players, how about we tweak the numbers and systems like this: There is still the slow starvation aspect whereas if you reach 0 satiety, you will grow weaker and weaker until you eventually die. I agree with LadyWYT here that recovery should be harder than starving so we can say -1 Max HP per day vs. +0.5 Max HP per day. Instead of just being a timer that ticks if satiety = 0 and doesn't if satiety > 0 for starvation with a second timer that ticks with satiety >0 and stop with satiety = 0, how about a moving delta; Baseline you neither lose nor gain Max HP (only base HP, not nutrition bonus). When your satiety reaches 0, your delta moves by, let's just eyeball, -0.25 delta Max HP per day. Meaning if you keep your satiety at 0, you will lose 0.25 Max HP per day after the first day, 0.5 Max HP per day after the second, 0.75 and so on. The longer you actively starve, the worse it gets until you will inevitably die. If you get your satiety up to over 50%, you apply a reverse delta. +0.1 Max HP delta per day, for example, so you slowly recover. That also means if you are too far gone already, you will not recover in time before your Max HP reach 0, killing you. For incentive and player control, we could also add certain hearty dishes (tied to the current hunger pause mechanic, maybe?) that give a bigger boost to try and heavily course-correct but only if you actually invest in proper food. In order to not completely screw anyone over who is struggling and didn't manage to get any food for a single day with a permanent drain, there is also baseline correction. Over time, if your satiety is >0 you will slowly, naturally drift towards 0 delta. Meaning if you are a struggling beginner who doesn't get any food for a single day and briefly hits 0 gaining Max HP loss, then struggling to find enough to get reliably above 50% satiety, you will still slowly stop losing Max HP. Not gain any back unless properly fed, but also not doomed to die. As for death penalty; I'd say you keep respawning with half satiety (no free recovery) and the -delta is set to 0 but instead you keep your Max Health reduced to a minimum of, let's say, 25% of the world setting base health. That way you have a small leverage to try and recover while being handicapped enough to discourage tactical food ignorance. As a bonus, because pure penalties are shit, even when at full base Max HP you can retain positive delta up to a certain cap. This allows you stave off onsetting starvation through enough healthy eating beforehand. Natural delta decay will, however, also affect positive deltas so if you do not eat very healthily constantly, you will naturally go back down +-0. Finally, the nutrition system of the game needs no changing imo. Death cuts it in half already. It naturally decays with lack of food. And pre-filling all your nutrition bars gives a bigger buffer to potentially outlast severe starvation where food would otherwise not course-correct your Max HP loss fast enough.

Bit of a shameless plug and self-answering; but in case anyone ever thought "Hey, I want the shiny new bushes without walking 1.000.000 blocks!" I made a mod that does it. https://mods.vintagestory.at/upgradedberrybush

Every time someone goes "Everything is shit they should do better", all I can think is "Well then do it better yourself, see how that goes." Every time someone says "Oh but it's Indie and Early Access and far from finished, it's ok", all I can think is "Game's been existing for 10 years. Even 7 Days 2 Die managed to get a full 1.0 Release by then and they re-invented the basis of the game every other update." Seeing both in a single post by a single person makes me confused as to what to think

I just checked and it seems to actually be the same distance as normal water. I could have sworn it was way shorter when I tried to move the darn thing to my base.

Weakpoints sound like a great idea. Maybe being able to briegly stun the boss in a recoil animation if hit hard/often enough with the boss's moves (maybe a dedicated blocking move) trying to shield itself against the attack; think Breath of the Wild Hinox. Adds some more dynamic, espcially the kind that the player can somewhat control, other than "roll the die. It's attack 1; roll the die. It's attack 3. Roll the die..."

/entity find only checks loaded chunks and obviously only returns existing entities. If your mount truly disappeared into the ether, nothing is going to help. And iirc it is a known bug that sometime, when the planets align juuuuust right, mounts can be deleted from the game on chunk unloading. So it is possible your mount is *gone* gone. No reading IDs from the log would help. And even knowing the ID would not help because you'd need the position. Which you'd have to find by manually snooping through the savefile's database looking for the entity entry for that ID and finding it's in-world coordinates, which map differently than the in-game displayed coordinates (in-game is centered around the middle of the map being 0|0 while true coordinates are based on the... bottom-left corner? Top-left? either way, on a 1mil x 1mil world your 0|0 world spawn would be 500.000|500.000). That said, I don't know if there is anything logged anywhere that actually would tell you the ID of the entity in any discernable form. For the future, considering you probably did not do that this time around? You should acquire an elk medallion. You can put that onto a mount (elk and most modded mounts support it) to truly claim the mount as yours, making its "last known" position have its own map marker much like your player marker. That way you can always find where it's *supposed* to be to discern if it was eaten by the savefile spaghetti or not. Cause even if the entity vanishes, the marker will still be there.

Darn. That modding post showed that it is possible to simply run the /bir commands needed to remap the block ids - it however also showed that that is not going to work the way I hoped. So the only way to achieve this would be a mod after all which patches the behavior of old berry bushes with some code that make their entire behavior "if init then delete and spawn new bush".

I remember Maple Story 2. Found it shortly before Nexon pulled the plug. It was cozy - cause in its dying breath they just gave everyone the endgame gear for free; aside from that though, there were alot of non-combat elements that were really nice and cute so I'd say yeah, Maple Story is/was less of the grindy "farm mobs 24/7" MMO and more of Cube World Online. As for the on-topic boss discussion; yeah, making boss fights is hard. Especially if you are not Dark Souls and cannot sell the "eternal suffering" as "part of the experience" until the player "gits gud". Vintage Story is not Dark Souls and shouldn't be. Its challenge and threats come from pseudo-realistically complex world mechanics and a general notion of having no "fix all" solution to the monsters in the world while each individual encounter with such, under normal surface circumstances, is rather unimpressive. So while I do think that a stationary boss you just have to tank for long enough is boring as hell, I genuinely wouldn't know how to make a more impressive fight out of it. Not to mention that a suitably sized arena would be very hard to hide in the world considering the incredible scale of the rest of the dungeon already. Maybe instead of head-on boss fights gimmick "bosses" that play into the puzzle aspect of story dungeons could help? Like some sort of greater threat that needs dealing with without having to wail on a big corpse for an hour. Think of a locust, or harder yet, bell factory still operation and you need to shut it down lest infinite mobs spawn. Mobs you can run past to find the source, not be forcibly locked into combat forever. A pipe bursting somewhere and the area flooding and you need to find the shut-off valve lest you drown. A big creature boss with many small phases that require less attrition and more problem solving to figure out. Something like that, maybe.

Rapids flow 3 blocks from the "source". So if you build a staircase-canal that drops 1 block every 4 blocks you can transport the rapid away from its origin. With this unfavorable ratio of vertical-to-horizontal distance your options will be very much still limited though, unless you happen to come across a rapid source at the highest top of a build-height mountain.

I agree that a larger cooking pot would be a very neat addition for a variety of reasons. It feels like progress, considering progress in the food department spans the whole of Pottery Age to Copper Age; with the Pottery age being when you unlock food (cooking, everything else is a waste) and the copper age being when you gain the ability to mine salt and craft buckets/barrels/the distillery. That is... not alot considering the need to eat is a permanent companion into the Steel Age and beyond. It would also be very handy to have bigger, *rounder* portion sizes to cook so you can spend less time watching to pot/campfire fuel and don't have to awkwardly handle the two spare portions or artificially handycap yourself to only cooking 4 portions at once. Luckily, until the day the devs pick up on this, there is a neat little mod doing literally just this https://mods.vintagestory.at/metalpots

Hey, don't call me out like that!