Frepo

This abomination could be a lump of flesh and bones, covered in pulsating blisters, and crawling around on mechanical legs. And when it gets close enough to the player it pops, releasing corrosive/infectious gas/acid/spores, causing the discussed effects.

Yeah, the caves REALLY need more content. I love the idea of cave-ins! Fits in well with the already existing concept of land slides (for dirt and gravel). How about some sort of tainted caves? Where all the stone blocks are tainted and poisonous, covered in some sort of goo (or some sort of fleshy material). You should get the feeling like you're inside the belly of some ungodly beast. Maybe being in there for too long will cause damage, like you're slowly being digested. Bones and skulls scattered about. Blood dripping from the ceiling. Tentacles sticking out of the walls, that attacks you if you get too close (think of the spine crawler from starcraft 2), that can submerge into the wall and reappear somewhere else (probably closer to it's prey). Spore sacks that, upon the slightest touch, releases poisonous/corrosive gas. Well... thats about as far as I've thought of it. There would need to be a reason for the player to venture into these caves. Maybe for resources exclusive to these caves. Maybe the story will have the player go there or something.

This is awesome! Generally, I'm for anything that makes survival harder! Themed or not, making sense or not, I don't care that much I haven't gotten into creating new entities, not skilled enough yet. But everything I've modded for our server so far is ONLY to make gameplay more of a struggle (although not as fun as a rot-creeper). Less meat drops from animals. Lower nutrition levels in soil. More fall damage. Can't sleep in rain or too cold envinronment, or when too hungry. Much more costly recipes. Standard rock blocks can crack and fall when mining nearby blocks. Lose half your inventory upon death. Can't mine ruins with hands. More blocks have the FallingBlock behavior. Drfiters spawn everywhere where it's dark enough. Less nutrition gained from redmeat in meals. Etc etc etc. Settings are (of course) set to increased monster strength and no coordinates or map. New and harder (and preferably interesting) enemies is a big thing if fell we're really lacking.

I agree! The game surely lacks an enemy with some sort of world destructive ability. Your idea of a "temporal creeper" is interesting. Hehe it would be cool if it created a new rift when it blows up. This entity feels like some sort of "artillery" unit, using itself as the ammunition I would pair it with a more basic enemy, perhaps a more beefy variant of a drifter, with hammers as hands, that simply just start breaking your house walls if it senses you inside. This encourages you to build your base in stronger materials, even reinforce the blocks (don't know how this works, but as far as I understood it's only relevant for PvP).

If it's not too much of a hazzle.... It would be nice for climbable blocks to have a ClimbSpeed property in the json. Perhaps functioning as a (float) multiplier. And then just multiply the motion.Y in the EntityBehaviorControlledPhysics.DisplaceWithBlockCollision. here perhaps? This would be very useful for future addons (and for modders) of alternative ways of Y-transportation, which I'm sure will come. .... ok, I'm just tired of climbing up and down 90 blocks on a vanilla ladder

Well... couldn't get it to work with a behavior. Still have no idea why. Solved it with a harmony-patch instead.

So, the other behavior could potentially interfere here. Since the base class 'BlockBehavior' sets handling to PassThrough. But that shouldn't matter here, since I add my behavior at the end of the array.

I guess they are....

Sounds nice! Perhaps in the future we get modular boat construction, like in Valheim.

This is driving me crazy! I thought it was solved, but apparently not... it's a simple behavior, from what I can see it SHOULD work, but it's not... BlockBehaviorExplosionDropNerf : BlockBehavior I've removed checks for type of block (which should be quite redundant anyway since the behavior is only patched into ore-gem, ore-graded and ore-ungraded), I've set dropChance to 0. Tried removing the BlastType check. Hell, I even tried removing all code and just having handling = EnumHandling.PreventDefault; return; PreventDefault should stop the drops, right??? But they still drop their loot! It's like the behavior is not even added at all. PatchExplosionDropNerf Vanilla ore-graded The already present behavior, 'BreakIfFloating' can't have anything to with it, right? Vanilla BlockOre Again, if I set handled = EnumHandling.PreventDefault in my behavior, it should stop the drops?

Planning on living permanently out on the (upcoming) oceans are we?

Name: Stalker Looks: A black, semi-transparent, hound-like creature with glowing orange eyes. Behavior: Stalks the player when you are not looking at it (when out of your FOV). When close enough it lashes out. While in your FOV it stops moving and lays low, until attacked or you get too close. Spawned stalkers avoid sunlight when dawn comes, seeking out dark areas such as a cave. Spawning: At any Y-level, but only during night (when it's dark enough). So spawning is not governed by the time of day, but rather the amount of sunlight. So you can expect more of them during winter when the days are shorter. -------------------------------------------------------------- This creature might not fit in thematically. But that can always be fixed, adding some rusty metal spikes to it's back, giving it's eyes the green/blue temporal color etc. The important thing here is the bahavior, every new creature added should have it's own unique behavior.

Or what if... Your stability goes down slowly no matter where you are (certain areas still makes your stability drop slower of faster). Sleeping will restore your stability. Add some tiered beds, restore more stability the better of a bed you're sleeping in. This would kinda simulate our natural need for sleep (but unnatural here). Then there could be another thingamabob that stabilizes an area, not making your TS go up, but at least stopping it from dropping any futher. Of course features fundamental to the game experience like these should be optional. So maybe a setting "No stable areas ON/OFF".

Excellent! Well then, I rest my case.

I couldn't find if this has already been asked for (I'm sure it has), but now I'm asking for it It would be nice to be able to see, when viewing recipes in the handbook, the output quantity. Just a little text in the corner e.g. "Output quantity: 3"

I think it's fine the way it is, you can always adjust the hunger rate in the settings. Hunger is either an issue, or it's not. Personally, I want it to be an issue in a survival game. It nicely ties in to other things such as inventory space and the decay mechanic, not to mention the nutrition system. You will have to plan before you go on an expedition, that's what makes it interesting for me.

So I've started looking into Harmony now. I copied some code from another mod with the intent to experiment with it. First thing I get is an error from just copying the over the code: I don't understand why this is not recognized by my compiler (when it obviously works in the original mod). It's a small mod with only one ItemClass, the mod core class, and this EntityPlayer_LightHsv_Patched class. Ok, it also comes with a config class, which I skipped. But can't see that the config should have anything to do with this error. Anyway, we are both refencing the same 0Harmony.dll ...or so I think, there were a bunch of 0Harmony-dll's in the package I downloaded. I'm referencing the net6.0 version (tried them all with the same result). What is this second parameter, "1"??? My compiler doesn't want it there.

So I've made a labeled trunk. Everything works fine, except for using pigment (say charcoal) on the right part/block of the trunk. Instead of opening the write-text-gui, it piles the charcoal on the ground in front of the chest. My entity (BlockEntityFTTrunkLabeled) is derived from the BlockEntityLabeledChest, so it shouldn't do that, at least not in ItemPileable... It so strange since I can open the trunk on both the left and the right block, that interaction works fine. But I can only trigger the write-text-interaction on the left. I've checked and compared the code a hundred times over, but I just can't find the error. It must be something either in the OnPlayerRightClick method: or in my json-file (which is basically a mash of the vanilla chest-trunk and chest-labeled I've paid extra attention to the multiblock behavior and collisionSelectionBox, but I guess it's not that since interaction (opening the trunk) works as expected. full BlockEntityFTTrunkLabeled class (if it helps)

I noticed in e.g. painting.json the following: shapebytype: { "@painting-(lastday|sodhouse)-.*": { base: "block/wood/painting2x1", rotateYByType: { "*-north": 180, "*-east": 90, "*-south": 0, "*-west": 270 } }, "*": { base: "block/wood/painting1x1", rotateYByType: { "*-north": 180, "*-east": 90, "*-south": 0, "*-west": 270 } } }, is this the same as: shapebytype: { "painting-sodhouse-.*": { base: "block/wood/painting2x1", rotateYByType: { "*-north": 180, "*-east": 90, "*-south": 0, "*-west": 270 } }, "painting-lastday-.*": { base: "block/wood/painting2x1", rotateYByType: { "*-north": 180, "*-east": 90, "*-south": 0, "*-west": 270 } }, "*": { base: "block/wood/painting1x1", rotateYByType: { "*-north": 180, "*-east": 90, "*-south": 0, "*-west": 270 } } }, or is there anything more to it (other than being a convenient way of reducing the number of lines)?

An excellent idea! I'm gonna try to mod this in the future. If don't think we even need to code any counting of the number of animals in the chunks. I think the mere existence of diseases (assuming it can spread to nearby entities) would limit the amount of creatures you breed. Since this mechnic would force you to go inspect your animals regularly to look for any sick individuals. This task would become more tedious the more animals you have.

I didn't know you could target a specific entry (or line or whatever it's called) within a "{ } -list". So if I understand this right, the op's behave like the following in a case like this (with /texturesByType) : add: adds a new entry at the end (we can't target a specific index since it's not an [ ]-array). and I can't use this command since "*" comes before my added line, making it unreachable? or is add only used to add a new property that isn't already present, e.g. /combustibleProps? replace: simply replaces the entire section. again, we can't target any specific entries? move: this one actually CAN target a specific entry. (/move on "*"). so I could (if I wanted) use it to move e.g. "*-flint"? remove: removes entire section (/textureByType). again, we can't target any specific entries?

Ok, interesting! That sounds extremely handy, I'll look into that for sure.

Dark, my man! I've been sniffing around in that behavior before, but I was only there to see how to get the saturation level. I would never have thought there was such a connection (through the watchedattributes)... oooh thank you!!! God knows how much time you saved me! Now... on to climb the next mountain; Making all players wake up if you run out of saturation while sleeping. And that (from what I can tell based on my limitied knowledge so far) doesn't seem possible without overriding the entire ModSleeping since it references BlockEntityBed in its WakeAllPlayers method. Meaning I must extend BlockEntityBed with my BlockEntityFTBed. And in BlockEntityBed are two cruicial methods i need to override (DidMount and DidUnmount) because the ticklistener is created there. But these methods are not marked as virtual, so I can't override them ...I was so close.

Oh my god, I think we're on to something here!

Yeah, that seems to be exacly what happens. Which could be good enough I guess. But I want it to behave consistently with the other restrictions, meaning the character wont lay down at all and instead the client recieves an error message. How do I make the server tell the client not to allow the player to lay down?