[Mod] Mesecons (= redstone) [GitHub] [minetest-mod-mesecons]

[RealBadAngel]

is there a chance that someone would like to impliament a way to detonate nukes from the nuke mod using mesecons?

you shall register nuke node as mesecons effector.
heres an example from my mod, registering my own machine to be controlled by mesecons signals:
https://github.com/RealBadAngel/technic/blob/master/node_breaker.lua#L36

[Homura]

Although it is question, like MineCraft, the tools with features such as Redstone repeater, is it implemented?
Are there any plans to make or?

[Alfino]

if you find a delayer then it's already in mesecon.(unfortunately you must go to creative mode to get it)

[VanessaE]

Since Mesecons don't lose signal strength over distance, repeaters aren't necessary. However, as Alfino implies, there is a delayer which you can use that will at least replicate the delaying effect of a redstone repeater.

[GloopMaster]

There isnt a crafting recipe for the delayer? :o

If that is true, you can use this:

TMT
CCC

T=Mesecon torch
M=Mesecon wire
C=Cobble

[Temperest]

WhirlwaveX: this is the kind of steup you need:

Your phone or window isn't wide enough to display the code box. If it's a phone, try rotating it to landscape mode.

Code: Select all

S
D

Where S is the sign, and D is the player detector.

Comp52: I'll see to it right now. If successful, I'll post it to the Nuke mod's thread.

Edit: See the Nuke mod thread for the Mesecon additions.

[BrandonReese]

Ive got a question. I need to make a vault door that opens to certain players only. Ive done the wiring already, but i need to know how to place the sign on top of the player detector so it only opens to who i want to. I need to know in which position do i place it, block height from the player detector etc. If someone could direct me to a video even better. Thx in advance.

I've tried with the sign directly on top of the player detector, and on the block above it to no avail. It uses default:sign_wall are there multiple sign nodes?

[Temperest]

In the vanilla game, no, but many people have installed things like locked_signs and xsigns, this may be the issue.

[Michael Eh?]

What I like to see in the next revision...

FIX
Mesecons running along walls and ceiling. Looks weird that mesecon floating midair to supply power to meselamp on ceiling.

NEED
Internal wiring or blocks that have mesecon passing through. Would be similar recipe to insulated mesecon but selected blocks. Would appear like a regular block but with a little mesecon terminal block in the middle.
Reason: To make it easier to pass power through a wall from a solar panel.

Optional ideas:
We have water, solar, plant power. What about wind? Recipe could be similar to water turbine but the sticks are in the corners rather than the sides.

Tuned Noteblocks
Noteblocks are cool. I thought it would be nice to be able to set the note for each block. I thought of replacing the iron ignot with a more ores ignot to set a ptich. Though to have a organ or have series of blocks that plays a short tune as a switch is pressed. Of course, then means having moreores as default so maybe better off as a seperate mod.

[VanessaE]

The noteblocks' instruments are set by the block under it, and the pitches are set by punching them one or more times.

[Ragnarok]

What has happened with mesecons_door? :( I missed something?

[PilzAdam]

What has happened with mesecons_door? :( I missed something?

xdoors2 has mesecon support.

[Michael Eh?]

The noteblocks' instruments are set by the block under it, and the pitches are set by punching them one or more times.

Palm2face

Think you missed the point of the suggestion of fixing the pitch of the noteblock. My thought of placing mesetorches for delays between 'tuned' noteblocks to play a song. As in so others can't change it easily. I see that there is tuning pitch in hitting noteblocks now.

[Temperest]

What I like to see in the next revision...

FIX
Mesecons running along walls and ceiling. Looks weird that mesecon floating midair to supply power to meselamp on ceiling.

I agree that it looks weird, but how would they join with other mesecon? What I do is run it behind the wall so it's not visible at all.

NEED
Internal wiring or blocks that have mesecon passing through. Would be similar recipe to insulated mesecon but selected blocks. Would appear like a regular block but with a little mesecon terminal block in the middle.
Reason: To make it easier to pass power through a wall from a solar panel.

I think a more general solution would be to add a transmitter device, which could transfer power across a single node. What do you think? We already have the framework in Mesecons, so it would not be terribly difficult.

[OdnetninI]

I need a mod that create a button witch, close, or not the circuit, but not generate electricity.
Only, allow electricity pass, or not.

[Temperest]

That's an AND gate. You can use either an AND block or a microcontroller to accomplish what you described.

In electronics, this is the purpose of a switching transistor. When the base is powered, current can flow.

[Molekula]

How can i make a flashing light?
I used a delayer, but at every time setting, the light don't flash.
This is a bug? If yes, please tell me how can i fix it, or give me a way to make flashing lights.
Thanks.

[Jeija]

It's not a bug, a single delayer cannot make a light flash, because the current goes in a loop.

(I guess you tried that circuit:
_D_
|___|__Light


In order to make a flashing light you have these possiblities:
- Use a blinky plant: BlinkyPlant----Light
- Use 2 delayers:
_
| |
DD
|_|____Light

D = Delayer, place them in opposite directions.
Turn on one half of the circuit for a moment.

- Use Delayer + NOT (recommended)
_<D<N_
|________|__Light

D = Delayer
N = NOT gate(recommended)/Microcontroller programmed as NOT-Gate/Mesecon Torch
> indicates the output direction of the parts

I hope I could help you!

[Jeija]

I updated the website a little, basically moved to php.

mesecon.ohost.de / mesecon.tk / mesecons.tk

Wondering if I should buy the domain mesecons.net + webspace...

[adversity]

Hello everyone,

I am loving the mesecons mod and the functionality it brings to Minetest!

I do have a question to ask:

I am working on stacking sticky pistons both vertically and horizontally. However, when I try to power the second piston it will sometimes not retract when the power is removed. I have been able to somewhat circumvent this using a microcontroller set to delay the circuit from powering the second piston until after the first piston has extended. My question would what causes the second piston to fail to retract when powered directly?

Thanks!

[prof-turbo]

You should update your video on mesecons.tk

[Jeija]

I was already working on that, prof-turbo (some cooperation with jordan4ibanez). I recorded some scenes for a video too, but at the moment I don't have the time to cut it.

[adversity]

Hey all,

In case my prior post was not detailed enough, I have conducted more tests in an effort to gain a better understanding of the mechanics. I also managed to find more questions.

/Begin wall of text:

Legend:
cb = cobblestone
mc = microcontroller
sn = sand
sp = sticky piston
sw = switch


Scenario 1:
Sand block on top of 1 Up sticky piston on top of another Up sticky piston powered by switch with just plain mesecon wiring between the bottom UP sticky piston and the switch.

Pre-power:
[sn]
[sp]
[sp]--[sw]

Powered:
[sn]

[sp]
][
[sp]--[sw]

The first piston extends as intended and the second piston does not extend but the sand moves up a block as if the second piston did extend.

Post-power:

[sn]


[sp]
[sp]--[sw]

Turning off the switch retracts the first piston which also lowers the second piston but the sand now stays suspended 2 blocks above the second piston. Oddly enough, if I place a new sand block directly below the suspended sand block, they both fall as intended.

Scenario 2:
Sand block on top of 1 Up sticky piston on top of another Up sticky piston powered by switch with an insulated mesecon connection to just the bottom most piston and another insulated mesecon connection that is 2 blocks high to the top most piston. The connections are separate but run to the same switch.

Pre-power:
[sn]
[sp]---|
[sp]--[sw]

Powered:
[sn]

[sp]
][ ---|
[sp]--[sw]

The first piston extends as intended and the second piston does not extend but the sand moves up a block as if the second piston did extend.

Post-power:

[sn]


[sp]---|
[sp]--[sw]

The outcome is the same as Scenario 1 even though the supply of power has been split for each piston as it is still all arriving immediately.

Scenario 3:
Sand block on top of 1 Up sticky piston on top of another Up sticky piston powered by switch with an insulated mesecon connection to just the bottom most piston and another insulated mesecon connection that is 2 blocks high to the top most piston with an inline micrcontroller delaying the signal to the second piston by 2 seconds. The connections for each piston are separate but run to the same switch.

microcontroller code: after(2, "sbi(A, C)");
{C is the switch side and A is the top piston side}

Pre-power:
[sn]
[sp]--[mc]
[sp]---|--[sw]

Powered:
[sn]
][
[sp]
][ --[mc]
[sp]---|--[sw]

This setup works correctly other than prior to the top piston extending the sand is already a block above the top piston. Once the top piston extends though, everything looks correct.

Post-power:
[sn]
][

[sp]--[mc]
[sp]---|--[sw]

Turning off the switch correctly retracts the bottom piston but breaks the top piston by retracting the bottom half of the piston and leaving the extended arm in place which also keeps the sand suspended. The arm is permanent and cannot be altered by tools.

The only known ways to clean up the arm is to either turn on the switch and turn it off before the 2 second delay powers the top piston or change the microcontroller code to after(2, "sbi(A, C)") off(A); (the latter method actually makes the entire mechanism work correctly - see Scenario 4).

Scenario 4:
Cobblestone block on top of 1 Up sticky piston on top of another Up sticky piston powered by switch with an insulated mesecon connection to just the bottom most piston and another insulated mesecon connection that is 2 blocks high to the top most piston with an inline micrcontroller delaying the signal to the second piston by 2 seconds. The connections for each piston are separate but run to the same switch.

microcontroller code: after(2, "sbi(A, C)") off(A); {C is the switch side and A is the top piston side}

Pre-power:
[cb]
[sp]--[mc]
[sp]---|--[sw]

Powered:
[cb]
][
[sp]
][ --[mc]
[sp]---|--[sw]

This setup works correctly other than prior to the top piston extending the cobblestone is already a block above the top piston. Once the top piston extends though, everything looks correct.

Post-power:
[cb]

[sp]--[mc]
[sp]---|--[sw]

Turning off the switch correctly retracts the bottom piston and the top piston but the cobblestone remains 1 block above the now retracted top piston. No know way to get the suspended cobblestone re-stick to the top sticky piston.

/End wall of text

Can someone smarter than me please explain the following:

Scenario 1 & 2: What causes the sand to stay suspended? It seems something is in the block below it which is why it does not fall as it should nor be pulled down by the sticky piston immediately below it.

Scenario 3: After modifying the microcontroller code to get the mechanism to work correctly, is this working as intended or will there be changes? Are there better means to accomplish the same goal?

Scenario 4: Why does the cobblestone stay suspended?

Thanks for suffering through this long post and for any feedback given!

[0gb.us]

There's a bug in mesecons_pistons/init.lua. The piston removes blocks like a player sometimes, and removes them like a non-player other times. This bug effects pistons, but does not seem to effect UP and DOWN pistons. To fix it, all you need to do is replace all occurrences of dig_node with remove_node. This will make the pistons act like a non-player every time. The functions even take the same parameters, so a simple search and replace will do the trick.

Normally this bug wouldn't matter, but when combined with certain types of block protection, it can be used to create a block cloning machine ....

[Jeija]

@adversity
I tried out some of your scenarios. I will answer your questions and if possible fix some bugs as soon as I have enough time for it.

[adversity]

@0gb.us:

Thanks for the reply and the info! I did a find and replace in the mesecons_pistons/init.lua as you suggested (even though you said it did not affect UP or DOWN pistons and all of my scenarios utilize UP pistons). I then re-ran all of my scenarios and noted the changes:

Scenario 1: no change as the sand block is still suspended 2 blocks above the retracted pistons and placing a sand block immediately below again causes both sand blocks to fall as intended.

Scenario 2: the top piston does not extend now and everything retracts properly when the power is removed. I wonder why the top piston fails to extend?

Scenario 3: no change as the arm still breaks without the "off(A)" switch in the microcontroller and then everything works as before with the "off(A)" switch added to the microcontroller.

Scenario 4: no change as the cobblestone block still remains suspended above the top piston after the power is removed.

Other than the regression on Scenario 2, you were correct. Thanks for the info, maybe this will help out along the way.

@Jeija:

Thanks for taking a look at this! I am patiently awaiting your findings!

[0gb.us]

So the upper piston fails to update now that the lower piston is consistently acting like a non-player. That gives us the solution to the hovering sand problem. Sort of. If you alter the pistons to consistently act like a player, the upper piston will extend as expected, and the sand will probably fall. But pistons will quit functioning when used in zones protected by, well, probably all block protection plugins.

I will try to work out a compatible solution as soon as I can. I think we need to have the pistons act like non-players, but then somehow tell the block they push to update itself. I have an essay to write right now, so it will take a couple days before I can work on this. Sorry.

As for pistons failing to extend or retract when they should, I'll try to find the problem, but I don't think I'll be much help. I'm not all that familiar with the piston code yet.

EDIT: I hate to suggest it, but maybe the pistons should move blocks as a player with an invalid name, such as "-!-" (invalid, so no one can register an account that makes them have the same overrides the pistons do), the string server messages are prefixed with. Then block protection plugins can allow the -!- player to make changes in protected areas. But that would require workarounds be built into every block protection plugin, so it would be best to avoid that if we can. As I said, I'll try to come up with something a lot better when my essay is done.

[0gb.us]

I'm looking in the default plugin's code, as that's where sand mechanics are defined, and I might have an answer for the sand issue. Call nodeupdate_single(pos) on the coordinates of the node pushed by the piston after the piston extends or contracts. Or, call nodeupdate(pos) on the same block's coordinates, to update both the pushed block itself and the blocks surrounding it.

I'm still not sure what to do about the pistons themselves though, as far as them not extending or retracting when they should. You could try these functions on the pistons themselves, but I don't think it would work.

[adversity]

@0gb.us

That's a good bit of information to digest. I never guessed this would affect block protection.

I am toying around with your suggestions but I have not been able to access the minetest website for a day and a half for some reason. Not sure why. Also, I am still a novice with Lua and the inner workings of minetest so I probably will not have much to contribute but I will definitely try.

Thanks for the additional feedback!

[Nore]

Thanks for that awesome mod!

The microcontroller is very useful (I already made a binary-to-bcd converter and a 7-segment display with it)...

I have got a few suggestions that add new content (I tried to code them, but I am not very good at Lua):
- A 2x2 microcontroller, with 8 inputs/outputs
- Colored mesecons: they connect only to normal mesecons or mesecons of the same color

Could you make them please ?