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.
WhirlwaveX wrote: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?
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 wrote: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.
Michael Eh? wrote: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.
Michael Eh? wrote: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.
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.
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!
Last edited by adversity on Tue Nov 13, 2012 16:40, edited 1 time in total.
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.
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!
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 ....
I missed something?
