Improvements

[tacotexmex]

Here's a suggestion in order to do away with the formspec. The mod is halfway there with the floating overlay graphics, but it feels out of place.

If an itemframe-like placement of items on the anvil was possible, it would be clear from afar what item was placed. Players would place an item on the anvil with a right-click, then smash away with the hammer (visually on the actual placed item) until the item was restored. The health of the item could either be displayed as graphics embedded on the anvil, as sign-like text content and/or by playing different sounds according to item health level.

[FaceDeer]

That's a neat idea. I've given it a go, let me know what you think.

I stuck with the old hud-based bar for showing repair status, though - I'm quite familiar with itemframe-like entities at this point but I wasn't sure how to do the in-world display you suggested and it's eleven o'clock so I figured it was best not to start into that tonight. :)

I'll look into some nice blacksmithy clanging noises to add next time I've got some spare time. Maybe add some spark particles too.

[tacotexmex]

That's great! Will try it out soon.

I'll think som more on how to nicely incorporate the visual repair status and hit you back.

And yes, spark particles will go neat with clang sounds.

The one thing a formspec-less solution doesn't accommodate is a place to store the hammer, though I don't see is as that important. But if players really want to have a hammer nearby, how about just have them placing it on the anvil? When a player then right-clicks the top-faceing surface of the anvil with another item the hammer drops and the new item is placed, essentially switching places with one another.

[tacotexmex]

As for repair status, how about audio together with the function that the item drops from the anvil when it's fully repaired?

[tacotexmex]

I've tried the mod now and it is nice. However I think there are room for improvements.

I imagine the anvil being more of a full block in order to be able to place items on it so that they're lying down. It's not very realistic to hammer on a standing item. The anvil model from the old castle mod looks good enough and is a full block on top. .

With an itemframe mod I've sort of mocked how I imagine it would look like (apart from the block not being an actual anvil in the screenshot and some wood artifacts on the sides).

What do you think?

[FaceDeer]

I'm a little unclear about the context of that screenshot, is the steel block mounted on a wall or on the floor? I've been unable to get an itemframe in my local test game to work when it's laying flat on the ground, and based on my current understanding of how the entity-generating code works I don't see how it'd be possible. Entities don't have a "pitch" parameter that can be set, only a "yaw" parameter, so I don't know of a way to lay the tool-displaying entity down flat. If you've got an itemframe that can do that then please link me to the code, I'd love to pull it apart and see how it works. :) The only example of an entity I've come across that had a settable pitch was actually using an animation built into the entity's model to fake it (the turret from the "shooter" mod).

Personally, I prefer the Cottage-style anvil nodebox to the Castle-style one because it looks a lot more like an actual anvil. Should be simple enough to add a configuration setting to set which style is used, though. I'll add that in when I do the sounds and sparks, I'll probably have time for that tomorrow.

The upgrader lbm I wrote to convert old anvils that have hammers stored in their hammer slots actually does stick the hammer into the anvil's repair slot (if there's space for it there), but that is just intended as a simple way to eject the hammer from the now-inaccessible hammer inventory slot without losing it. I'm thinking it'd be simpler and more realistic to put a locked chest near the anvil to store your hammer in rather than having special-purpose hammer-storing functionality in the anvil itself.

IMO it's better to have a number of different mods each with a specific function and using them in combination when all of those functions are needed rather than having one mod that tries to do everything in one block. That way each mod can be separately upgraded or replaced with other things that perform that function better.

[tacotexmex]

I understand the confusion. The block is actually placed on a wall but the composition is made to look like it's standing on the ground. That is because I couldn't put the itemframe on a top-facing surface and that's for a good reason, I just learned. Perhaps that pitch function needs a PR to the engine to work then. 😞 Then I don't know what's best. Between a freefloating but faceup item texture and placed 3D entity I lean towards the latter, because it is at least placed in-world, don't rely on formspec and is visible from afar and to other players. Really hope that pitch thing can be made possible though.

The anvil style is secondary to me, both would definitely work out. The reason I wanted a larger surface was to be able to fit it when lying it down but that won't matter if it's the pitch is missing.

I also agree on your UNIX-style approach to the whole thing, "do one thing well".

[tacotexmex]

Have you looked into sofar's itemframes mod? I couldn't get it to run but is says it's not entity based, if that could solve anything.

[FaceDeer]

Unfortunately I don't think Sofar's approach will work well here. It has two main limitations:

• The displayed item is only a texture, it doesn't have "depth". The frame can display cubical nodes as 3D objects but that looks like a hard-coded special-case. So using this approach would just paint a picture of the item onto the surface of the anvil, which doesn't seem ideal.

• Every potential item that could be shown on the frame has to be hard-coded at initialization time. The second half of the frame's init.lua consists of a giant list of hard-coded items, the mod creates an entirely separate frame node definition for each of these (so for example there's a "Frame with Steel Pick" node, a "Frame with Bronze Pick" node, etc.) This would either make the anvil be unable to repair tools added by other mods that were not part of that hard-coded list, or it would make the anvil inconsistent about whether it can display the item that's in its repair slot.

When you tried running sofar's mod did it thrown an assert about a flowerpot not being a thing? I had to delete "flowerpot:empty" from the list of items to get the mod to work, it looks like this mod doesn't handle the absence of optional dependencies gracefully.

I'd love for there to be a convenient way of setting entity pitch. I investigated it recently because I was thinking of adding a ballista to the castle_weapons mod, and when I saw how the shooter mod handled it for the turret I decided to back-burner it for now. Which is a shame, why build massive castle walls without the existence of siege engines capable of assaulting them? :)

[tacotexmex]

How easy this implementation seemed, yet how impossible it really is 😩

Didn't know that sofar's solutions was so inelegant. So the hard-coding is required to overlay a texture on a block in-game, it can't be done dynamically at all?

[FaceDeer]

Yeah, each registered node's texture is set at the time that it is registered. As a familiar example, furnaces have a "lit" and "unlit" state and that's actually handled by having two different furnace nodes defined, one with the animated fire texture on its front and one with an unlit fireplace texture on the front. When the furnace ignites it swaps the unlit node for the lit node.

I imagine the reason why it's done this way is that a node's definition is global. So if we were to have just one furnace node defined and somehow changed the texture on it from unlit to lit, then every single furnace in the game would simultaneously switch from the unlit to the lit texture.

I just went looking around in the signs_lib mod mod's code, since it adds dynamic text onto in-world nodes I figured it might have some useful trick. It turns out to use an entity as well, like the original itemframe mod.

I suppose I could use an entity to display the tool's inventory image in a horizontal orientation, as if it was lying on the anvil. But it still wouldn't look "three-dimensional" even though it could hover some distance above the surface of the anvil, it would be like a paper cutout of the tool. Still seems kind of unsatisfactory, and would make it hard to tell what tool was on the anvil when looking at it from a distance.

All in all, yeah, this is a surprisingly tricky problem. I'm not sure that a perfect solution is available right now. Still, I do think that the current approach is better than the original cottage anvil's approach, I like seeing the piece being worked on even if it's positioned a bit oddly.

[FaceDeer]

Clang and sparks added, let me know what you think of them.

[sofar]

You can use an entity, and if you make it like a wield item it will have depth. (visual = "wielditem" I think?)

A creative solution may be too make the item actually a "dropped" item. Even while the item is dropped, you can still manipulate its properties and name or repair it. You can spawn it right on top the anvil. The player can punch it to pick it up. It would be spinning, but that's not so bad imho.

[sofar]

Didn't know that sofar's solutions was so inelegant. So the hard-coding is required to overlay a texture on a block in-game, it can't be done dynamically at all?

It is much more "elegant" than entities, since those tend to make multiplayer servers laggy because they force lots of processing on the server and client. And the entities have a tendency to disappear.

The design of my item frame solves the dreaded itemframe lag problem too, where the frames are all empty for several seconds before the items appear.

It just solves that problem by making lots of nodes.

However, there is an engine patch (long time pending) that would allow dynamic texturing of nodes. If that patch ever gets merged, all that manual registering of nodes falls away and there would be only one node for all frames.

So ultimately, I think the frame mod as I wrote it will be the best solution, and I have the code to support that statement, and on top of that, an argument for getting node setmeta merged in the engine.

And then we can make furnaces use only a single node, and this anvil too.

[FaceDeer]

Isn't a dropped item just another entity anyway? It wouldn't reduce the amount of entities in the world, and IMO dropped items are kind of unreliable - I've been on servers where dropped stuff disappeared after thirty seconds.

I don't think texturing will be ideal for displaying the contents of the anvil since the item would still look "painted on." Even though the current entity is oriented oddly I think this remains the best solution for the time being.

[sofar]

the server specifies how long it takes before dropped items get removed, the default is a lot longer though.

Using entities for anvils isn't so bad since the items are always going to be in there for only a short amount of time. It's not like a sign or item frame that just hangs on the wall forever.

[tacotexmex]

I noticed that my typo made it seem that I meant all sofar's solutions when in reality I was just referring to this one. And now I understand why, too.

I tried the new version out and the clanging adds a great feel to it. The gain could be lowered just a tad perhaps.

[tacotexmex]

Close this, @FaceDeer? Or keep it open for whenever entities get pitch?

[FaceDeer]

I'll close it. Who knows how long it'll be.

[tacotexmex]

Well, it took a year but entities have pitch now: https://forum.minetest.net/viewtopic.php?f=5&t=21548&p=337746&sid=86a2646f934f52ab6595d143d3a9406c#p337737

[FaceDeer]

Heh. Shall we reopen this issue, or start a new one? The anvil could probably use some other renovations anyway, it's been a long time since I worked on it.

[tacotexmex]

New one seems best. :)