Add Something Akin To Redstone's Observer

[benrob0329]

In almost every circuit I make nowadays I find that I need pulses. Pulse when something comes on, pulse when something turns off, pulse to grab that block, or pulse to push that one back out. I find that for complex setups (mostly when making piston doors) that I can end up with multiple monostable circuits for pulsing at different times and this bloats up the size of things quite a bit as I then have to route wires around things and it all becomes quite a mess.

My idea is to add a block called the "Pulser" (or similar) which takes a mesecon input (as block updates are hard and slow to detect in Minetest) and outputs a pulse the length of a gate's delay (or the fastest possible monostable circuit as of now). This would help immensely with projects that need to pulse a piston, movestone, light, or shorten a signal at all. It would also help with routing signals as you can use them to pass a pulse through a chain of "Pulsers" and even split them in ways you can't easily without using mese block stacks (which then interact with nodes next to them).

[Desour]

Building something like this isn't that hard and takes not too much space: or

Something this specialized might be better in a mod like moremesecons.

[benrob0329]

First, nice circuit; I feel really stupid for not having thought of that myself. Second, you can't use LuaCs or FGPAs to argue against other components because they will always win as they can impliment any other component.

What you call "specialized" I call "So friggen useful for so many things It'd make NoController builds a heck of a lot smaller". Your circuit is still 2x3 blocks, thats small but still will add a lot of space when you start to need more than 1.

[numberZero]

FGPAs ... can impliment any other component.

It can’t. It has no memory. Circuits like that weren’t intended to work (and are in fact unreliable). Custom gates with memory (8 bits would fit in param2 nicely) were suggested but never implemented. Still, these shouldn’t be able to generate signals without external (clock) source. Self-clocking devices are possible but are out of scope of mesecons IMO.

Nevertheless, monostable devices may be added. Edge detector is a nice thing; it’s trivial to make out of LuaC but that shouldn’t be necessary for such a simple gate. And it won’t overload the server because it will always fall to the passive state in a short period of time.

[numberZero]

MoreMesecons has time gate but something simpler, delayer-like is probably suitable for core Mesecons.

[Desour]

Note that it shouldn't have variable delays. It is important that the delay is a multiple of a gate delay (2 globalsteps). If you add something into the actionqueue with a delay greater than 0, it's not deterministic, how many globalsteps it will actually take. This can result in signals that are only 1 globalstep long, which can overheat some gate constructions.

Adding such an edge detector should be relatively easy. But how many different types should there be?

• 3: rising edge, falling edge and any edge
• 2: rising edge and any edge (you can get the falling edge detector with two additional not gates, this takes more space however)
• no any edge (any edge can be made by ORing rising and falling edge)

I guess 3 new gates is the best option.

[numberZero]

See the PR. I’ve experimented with 1-tick pulsar, some devices work perfectly with that but others get stuck. So it now waits one more tick like a conventional circuit would.

you can get the falling edge detector with two additional not gates

With one NOT-gate, obviously. But it would delay the signal so if you want to be perfect, you have to prepend a diode to the rising edge detector as well. And ORing these together delays the signal too, in addition to taking considerably more space, so double edge detector is a thing probably...