use minetest.override_item to redefine mese

[HybridDog]

it's just a small change

[Jeija]

Thanks, didn't event know it existed. This will be merged in 1-2 months, just to make sure noone uses mesecons with an old version, so that we don't break compatibility for no functional reason.

[HybridDog]

minetest/minetest@574ed6a
it was added at 14.1.2014
so it's maybe too new

--this could be used that it works with old versions, too
if not minetest.override_item then
minetest.register_node(":default:mese", {
...
else
minetest.override_item...
end
--maybe minetest.after needs to be used to avoid defining it 2 times (but I don't think so)

[Jeija]

Right, that would make the code longer; or just wait 1-2 months and 14.1.2014 will sound like a long time ago :)
(Especially as 0.4.9 was released on January 1, 2014 and therefore the current stable does not support the override feature).

[HybridDog]

ok.

[ShadowNinja]

@Jeija: 0.4.10 is released, with override_item.

[Jeija]

@ShadowNinja : Yes, I saw that. The thing is, I don't like the current state of mesecons as it is overcomplicated (e.g. the metarules) and bloated in other places. I was planning on rewriting mesecons with minetest 0.4.10 vectors, override_item etc., but I haven't found the time for it (I have only done like 5% yet). For now, I'd say better not touch the current mesecons repo and have it as a stable and future legacy version.

The reasons for the overcomplication is that mesecons was never intended to support nodes that have both inputs and outputs (microcontroller / gates / delayer etc.) apart from wires. Therefore, all these features were retrofitted making sure there is no major code rewriting involved and trying not to break compatibility.

The rewrite should hopefully use iteration instead of recursion, remove the need for metarules and be a little more performant in general. But most of all, it will be less bloated, more compact and easier to maintain.

If that takes too long for you, cantact me via my eMail address and we can discuss future plans for mesecons and work together on the project. I'm still trying to figure out a good way to reform the concept of conductors-effector-receptor and a totally different approach to how power spreads across the circuit.

[Jeija]

Sooo, I decided not to go with the rewrite. I was trying to rewrite mesecons and make things differently, but as it turns out, the way mesecons currently is like is not too bad after all. There really hardly is any way to make the mesecons code more easily understandable and maintainable without sacrificing stability and performance.
Therefore, I will continue to work on this codebase which means I can merge this now.