Arisilde

Oh yeah, that's trees

@Nat_VS Ah, I didn't see that detail. Tbh, I can't see it even after you've pointed it out unless you mean the tree leaves? That's really good to know for future reference about the full pane versus just black texture. Thanks.

This isn't a texture issue, it's actually a world lighting issue. There's 0 light so the world is pitch black even when the sky seems lit. I've seen it happen to single chunks before, but never the whole world at once Usually reloading or time fixes it (chunk regenerates). There's also a server command /debug chunk relight you can use to force it to recalculate the light. might try that and see if it fixes the chunk you're in. Then at least you'll have a data point. I thought there was another command to recalc light for the whole server, but I'm not finding it at the moment. If this is a persistent problem that isn't going away over multiple relogs, I'd do as Lady says and start removing mods. Though typically you do half your list of remaining mods each relog. This narrows it down for you in significantly fewer tries.

Something like this wouldn't tie up resources. The UI would be run on the client, so any load is negligible since the user is standing there doing the crafting anyway, so they're not to be producing any other load, and not going to notice any potential load this would cause. Performance-wise I think it would be no different than smithing ultimately. The server would only have to accept a network packet for the new recipe, run the parser, and register the new item/recipe. That's essentially instant for something as small as an item json. I was theorizing this with a mod in mind. I wasn't even thinking about this forum being for game additions tbh. Just running my mouth

Just my 2 cents, but seems to me the server settings for a system like suggested would limit any "theft" concerns if you're being reasonable about it. Just set the timer to a sensible length and no one can honestly say they got robbed. If you legitimately disappear for an extended length of time, honestly that's on you. You're doing a disservice to the rest of the server. Claims get locked forever without admin intervention. On high turnover servers this can become a real pain for admins who also just want to play, not spend all their time on admin duties. Systems like this actually help both sides, players going on hiatus, and servers dealing with abandoned claims. You just need to build in a couple safeties. A command/system so the owner, a person with permissions, or a server admin, can add time to a specific claim's timer. If you leave for a legitimate reason, there's no reason you can't add time yourself to cover how long you expect to be gone, or shoot a message to the admin or one of your friends with access so they can do it for you. Even if you leave unexpectedly, it takes 1 minute to send a message. If you're injured or fall sick, your friends can keep things going until you return with no risk to your claim. Designate a temporary caretaker. If you're going to be gone for a very extended amount of time without communication, give a friend temporary rights that supersede normal access permissions. They can do all the things an owner can do, other than give away or delete the claim. This lets them overrule others in place of the owner for the following systems. If the timer runs out, a configurable grace period starts where people with claim permissions get the first chance to have ownership pass to them. The caretaker gets first pick, then other users with permissions in stages based on permission level. The claim doesn't go up for grabs until after the grace period ends. This is a second line of defense for both the owners and regular users. It gives the owner's friends a chance to claim the ownership so they can hold onto the plot in the owner's stead if they are unreachable for some reason, allowing them to give it back if the owner returns. It also allows for situations where membership is more loose, not specifically friends. It gives regular users of the claim a chance to take over if the owner disappears without leaving a caretaker, instead of just someone random taking ownership. And finally, it still allows completely abandoned claims to be cleaned up without constantly being a burden on the admins. These arguably give reasonable flexibility for basically all legitimate real life reasons a person might disappear for a while, or for users of a claim to prevent someone else from taking it just because the owner may have disappeared, without skewing to heavily in favor of filling servers with dead claims. It's also probably not that difficult to create, and not at all heavy on server performance. Just an array of tiny structs keeping a record of claims and their timers, some server commands, and a little logic for the grace period and other permissions tie ins. And of course it would be a mod or server option, so not forced on anyone.

That's fair. Honestly I think it's more just about immersion than strictly making sense. Like chiseling in general People just love customization. There's a lot of resulting complications you'd have to work out. Do you add variable resulting damage, swing speed, etc? Seems like there would need to be some sort of balance for using more/less metal for the craft. That does actually give me another potential idea though. Probably not "easier", but possibly more understandable/scalable. Could do something like chiseling. Create "blueprints" before actually forging. "Chisel" out a block into the exact shape you plan to forge, and have that save as a new recipe. Then you just forge that item directly. Actually now that I'm saying it, that sounds a lot easier. You could copy the anvil behavior to create a custom "prototyping" bench. Start with a raw clay brick, place it on the bench and it becomes a "clayworkitem". This would be a new item class that either inherits from workitem, or inherits from item and copies some of workitem's functionality. Use the same forging hammer UI to do the block edits. Push pixels around, cut them off, add more from clay in your hotbar. Then rather than locking into an existing recipe to finish the item like normal forging workitems, you'd just need a finish button on the UI. Clicking that runs the recipe creation parser. The leftover clayworkitem could be deconstructed back into the raw clay since you'd just be working wet clay realistically. Man, the more I talk about this, the more it makes me really want to build it. I'm just tied up in another project right now

I think you could probably make custom weapon shapes tbh, it would just be a significant amount of work. Shapes are just arrays of points in VS, basically. You could write a custom json writer to copy an item file of the same type as you're crafting, edit the shape/texture attributes, and then save it to disk. That part doesn't even seem that difficult. The harder part is the "minigame" to create them. Currently, work items have preset shapes they require to trigger being "done", the defined recipe. You'd have to write a completely custom system for the anvil behavior, the workitem class, probably some other things. You'd then have to register the new item so the game knows it exists. Not impossible, just complicated. You could probably have it automatically generate a new forging recipe for repeating the pattern with normal smithing in the future. That's just off the top of my head, but it seems doable to me. I could be wrong

I don't disagree with you at all, I was just offering a currently available suggestion that in my opinion is better balanced than glowing highlights. Take it for whatever you will. The chance to break covers a lot of the idea of losing arrows in the wild, so for me at least making the existing arrows a little easier to find isn't that gamey. You can just edit the arrowhead recipe and make it output 30 if that's the solution you feel works for you. It's a simple json edit or addition. Currently there's 6arrowhead.json and 9arrowhead.json. You could add another or edit one of those and change the output stacksize.

Probably not that specifically, as the <3.5m fall negation would cover the vast majority of that behavior unless you're dropping down extremely steep inclines, and honestly you probably ought to take damage then. I do think it should be a server setting instead of a hard coded 3.5m though. Far too much in this game is hard coded. I think it boils down to faulty "landing" detection at the end of the day. Either for the ground, or because they have a system for stopping a fall when you connect to a ladder that also might be part of the problem. That detection might be misfiring. To be fair, anything beyond basic OnGround checks tends to be tricky. You almost immediately start running into ballooning edge cases. You're likely right on the part about them landing on "good enough for now" because of this.

Every single water block is an infinite source, so any transport at all fails to fulfill what you were asking for. Now if we're talking down the road, an option to make water blocks not infinite that's a whole different story. I do think that should be included as well. It's just not supported right now, so I was suggesting a currently available option.

Any sort of timeframe/estimate you've seen for that?

I don't disagree, but until it's added; here's a mod you can use to do this: https://mods.vintagestory.at/accessibilitytweaks

There's a very handy little mod that takes care of this, without being too imbalanced. You still have to hunt around to actually find the things, but it puts you in the right spot. https://mods.vintagestory.at/projectiletracker

There's actually a server setting to disable transport of fluid source blocks, "noLiquidSourceTransport". Domestication seems to actively be being worked on, based on dev posts. Some of the new AI is already in the game, and you can look at it in the files. So seems like we'll be getting a new system before terribly long.

Trees are defined in json files, in: Vintagestory\assets\survival\worldgen\treegen This wiki page explains how it works: https://wiki.vintagestory.at/Modding:Trees I think you could technically do it, but I don't think treegen is really suited for this. Sounds like you'd have to define a trunk array for each block of the tree's footprint, which... It might be possible to fake it with a custom landform that's made of tree trunk instead of dirt/rock, but that would remove the tree cutting behavior, which tbh for a tree that size would likely be for the best anyway. You'd need to figure out branches though, which would be pretty tricky, but maybe not impossible. Maybe custom defined "trees" with no trunks, just a branch definition. Have them spawn all over the surface? Honestly no idea. This is likely why you've never seen it done