[MECH] RedstoneChips 0.97 - Integrated circuits plugin [1.5.1-R0.2]

RedstoneChips 0.97 / BasicCircuits 0.97 / SensorLibrary 0.34
(Last update on April 30th, 2013, cb 1.5.1-R0.2)

Website | BukkitDev​

circuitdocs * howto * videos * wiki​

Features:

• Build chips with any number of input and output pins, from compact 2 block chips up to whatever you can imagine.
• Choose from over 50 different chip types and several 3rd party chip libraries.
• Most chip types can work with a wide or infinte range of i/o configurations. Sign arguments allow you to customize chip behavior.
• Chips can communicate through redstone, or directly by touching each other. Some chip types can also communicate over wireless channels.
• Chips can be built in almost any imaginable structure allowing very compact circuits.
• Debug and maintain large projects using various tools and commands.

Help me spend more time working on RedstoneChips. Please donate

Circuit libraries made by other people:

• LightControl by @Mordenkainen - A RedstoneChips library for controlling light sources
• MobSensor by @Richard Robertson - Specific mob detection circuits.
• MessageCircuit by @Richard Robertson - a circuit that sends a player a message when any of its inputs receive power.
• PuzzleQuest by @MichaelBurge - Redstone-Powered Questing (Interacts with uQuest).

Changelog (open) Changelog (close)

RedstoneChips 0.97 (Apr 30th, 2013)

• Fixed the saving bug on cb 1.5.1.
• Added an option to disable update checking.

BasicCircuits 0.96 (Apr 30th, 2013)

• pixel: Added a maximum distance value preference to prevent lags and server crashes. The max can be changed using/rcprefs pixel.maxDistance x and defaults to 7.
• sram: Fixed a problem with anonymous memory.

SensorLibrary 0.34 (Dec 1st, 2012)

• daytime: Fixed daytime offset bug.

Full changelogs and source code @ github.com:
RedstoneChips BasicCircuits SensorLibrary

 

Popping in to say: Great plugin!
There does seem to be a slight glitch with transmitters/recievers, though. I was trying to build a simple segdriver circuit (still am, but that's probably more a user problem ) and had hooked up everything up to the pixel segments. Then I realized that the segments were to small so the pixels were bleeding into the other's segments. So I tear down everything and rebuild it only to find that the new wool I'm placing keeps switching still, before placing the new pixels!

If you need any specific info from me, just ask!

 

@Mordenkainen
1. I can understand the usefulness of something like this. The reason i didn't atleast add a radius arg was because it became a too difficult to make all the pixel sign args work together in all the possible combinations. I'll try to find a solution.

2. Chips can be built with any block type since RC0.82 exactly so you could do that. There's no such thing as chip material anymore. Try it, it's supposed to work.

3. This could lead to RedstoneChips without any redstone. Interesting :-p. I don't want to add any special signs that's for sure. If there's a simpler way to implement I will.

@Darksteel Mike I think I saw this issue once. So you think it has something to do with the wireless communication? Anyway, will investigate...
I changed the way pixel paints wool in one of the recent versions so that wool that doesn't actually touch the circuit (directly or indirectly through other wool blocks) will not be painted. This makes even 1-wool per segment displays possible, so I don't really understand how you get color bleeds.

And thanks both of you for the kind words

 

Actually he has a unique request. He wants to be able to have something like this.

Code:

    [Sn][Sn]
[In][C1][C2][In]
[Ot][C1][C2][Ot]

Where [Sn] = sign, [In] = input, [Ot] = output, and [C1] and [C2] are two different kinds of chip blocks.

 

Hmm, yeah should work.
You'll have 2 chips with whatever you write on the signs.

 

How do you configure it so that both block types count as chips? Like if the one on the left were made of sandstone and the one on the right were made of dirt?

 

I check the block type the sign is attached to and continue to look for the same type.

 

Oh, that's pretty sweet. I didn't know that ever changed from being a set block.

 

Ah, I just looked at the sources. And re-read the howto....

Sorry, my bad, I didn't realize that the "chip block" type is whatever material the sign is attached to. I thought it still had to be Sandstone. Problem solved then!

As far as the "I/O" block, could it be a redstone repeater? Those have directionality (So CircuitManager knows if it's an input or output), and only occupy 1 block of space. I wouldn't think you would need to change the repeaters state, just activate the input of the next chip. Only question is how you deal with having more than 2 circuits touching the same "I/O" block.

Thanks
Morden.

 

I even made a movie

Well this could possibly work. I never tried to use any diodes but if you can get the direction of the diode then it's possible, only problem is that the diode has its own redstone function that might conflict with it as an IO block.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

According to the minecraft wiki:
Redstone repeater Data Values:
Low (1st & 2nd) bits:

• 0x0: Facing east
• 0x1: Facing south
• 0x2: Facing west
• 0x3: Facing north

High (3rd & 4th) bits:

• 0x0: 1 tick delay
• 0x1: 2 tick delay
• 0x2: 3 tick delay
• 0x3: 4 tick delay

As far as the redstone function of the repeater, that is why I was suggesting you not activate it. Presumably, if it's not being sent a redstone current, it shouldn't be outputting one, so shouldn't cause spurious inputs. That said, I don't know how the repeater is coded up, so who knows.

Morden.

 

Ok, no problem getting the direction then.
You could accidentally activate it by putting redstone wire on top of the chip block the repeater is connected to. Also not activating the diode when the input state is high seems confusing.

Solved (but not yet released of course), thanks!

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

Then I would be concerned about the delay imposed by the repeater. If activating it also causes it to delay the signal, that could cause issues. If you are activating it even though you are directly communicating the pin change to the other circuit, then the input might be held high for whatever the repeater is set to after the initial circuit turns it off.

Sorry for the double post, but I have a question that I hope some of the redstone experts could help me with.

I am building a clock using the daytime sensor, and the 7-seg driver.

Since the daytime sensor will give me a 6 bit binary output for minutes and a 5 bit for hours, I need to convert that to two 4 bit binary numbers to feed into the 7-seg drivers. Does any one know the best way to take a 6 bit binary number and convert it to 2 4 bit BCD numbers?

I have a circuit that will do it, but it only works up to 25, and I'm not quite sure how to go about expanding it. the design for this can be found here: http://www.electro-tech-online.com/...ews/12728d1178504364-simple-clock-bin-bcd.gif

Also, does the clock actually go from 0-60 minutes, or is it really 1-60, or 0-59?

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

Okay, I have a question about developing plugin-libraries for RC. I'm using IntelliJ IDEA if it matters.
I've followed the readme to the end (installed maven, "maven package install" both RedstoneChips and LibraryTemplate) but when I go to edit test.java to replace it with my own chip it complains that it can't find org.bukkit.command.CommandSender. Specifically, it can't find org.bukkit. On a hunch, I downloaded the latest bukkit snapshot and ran "maven package install" for that as well to no avail.

Is this even an issue? Can I reference it anyway in some voodoo way?

Also, and this feels like a slightly stupid question, once I have the .jar of my plugin, what do I do to use it on my server?

 

When exactly do you get this error? When you write in the IDE, or when you compile with Maven?
It could be a problem with the IDE which I know nothing about.
Do you get this error by running 'mvn package' on your altered LibraryTemplate?

About the jar file, once you create it all you need is to put it in the plugins folder. It's just another plugin and it will register with RedstoneChips automatically.

Updated to RedstoneChips 0.86

• Wool color or any other block with data value can be used as an indicator block (input/output/interface). For example: /rc-prefs inputBlockType wool:silver will now work.
• `/rc-list` will now show only the circuits in the current world by default. Using `/rc-list all` would show circuits in all worlds and display each circuit's world.
• `/rc-list` shows each circuits sign arguments (or at least part of them).
• `/rc-channels` shows how many receivers and transmitters are communicating on each broadcast channel.
• Using /rc-debug on a circuit you're already debugging will turn debug for the circuit off.
• Added hex values and changed the message format of input-change debug messages
• Changed the circuit id system. Circuits will keep their id numbers after rc-reset or server restart.
• New backup redstonechips.circuits files won't overwrite older ones.
• Invalid pref values entered using /rc-prefs are now caught properly.
• Some command format changes and bug fixes.
• Fixed a little bug when removing rc-type circuits.

Download links at the top...

The clock goes from 0-59 and 0-23. Same as normal clocks...

I don't know how to solve the other problem. Could be nice to see how it's usually done.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

Alright, sounds easy enough to install, though you never know

My IDE complains about org.bukkit when I open the altered LibraryTemplate project.
FAKEEDIT: Hey, figured it out. I had to add bukkit as a dependency to the LibraryTemplate's pom.xml. Works fine now!

 

Oh, I thought having RedstoneChips as a dependency was enough since it's dependent on Bukkit on its own.
In any case, I added the dependency to the pom.xml on github. Thanks for pointing that out...

 

The easiest way would be to use modulo or integer division, but you would need to subtract numbers in both cases, which isn't supported yet. But negative numbers seem to be on eisental's to-do list.

 

Ok, thanks, just to let you know the doc for the daytime chip says minutes are 0-60, so that is why I questioned it.

I figured out the BCD stuff. There is a formula for doing this, so I implemented the formula physically.

The formula is:
Binary number < 10 add 0
Binary number 10 - 19 add 6
Binary number 20- 29 add 12
Binary number 30 - 39 add 18
Binary number 40 - 49 add 24
Binary number 50 - 59 add 30

So what I did is set up 6 comparators and a few AND gates to give me 6 outputs that only one goes high to indicate the binary numbers range per the rules above. I fed these outputs into a router, and set the router up so that it outputs a binary 0, 6, 12, 18, 24, or 30 depending on the range. Then I fed the output of the router into an adder, along with the original binary number. The result is two 4 bit BCD outputs representing the individual digits of the input number.

Seems to work quite well, but is large, something like 14x14x25.

Morden.

 

Haha, that was a long time ago... I think negative numbers in the constant are the only problem. Encoding the negative number yourself on the adders input should work. You would need to encode it into a two's complement negative number which is kind of annoying: to make a binary number n into -n you flip all the bits and add 1.

http://en.wikipedia.org/wiki/Two's_complement#Calculating_two.27s_complement

I guess that's a typo then. Sorry...
I didn't understand the formula though. What do u mean by add 6,12,...?

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

ah cool, didn't know that and spared to read the full code; but he couldn't use my method with the existing circuits, because the divider rounds.

 

Yeah, maybe it shouldn't round. I should probably change that.

 

or just add a sign arg

 

Sweet, after the dependency hiccup it was smooth sailing. Quickly implemented a sweet new random circuit. Not sure what I'll use this bad boy for yet but 31 bits of random data ought to come in handy somewhere! Kudos for the ease of use!

 

Depending on the range the original number falls in, adding a particular number to it will result in the BCD version of the original number.
Binary number < 10 add 0
Binary number 10 - 19 add 6
Binary number 20- 29 add 12
Binary number 30 - 39 add 18
Binary number 40 - 49 add 24
Binary number 50 - 59 add 30

So some examples:
Dec 10 = Bin 1010. 10 is between 10 and 19, so we add 6 to it. 10 + 6 = Dec 16 = Bin 0001 0000 (1 and 0)
Dec 18 = Bin 10010. 18 is between 10 and 19, so we add 6 to it. 18 + 6 = Dec 24 = Bin 0001 1000 (1 and 8)
Dec 27 = Bin 11011. 27 is between 20 and 29, so we add 12 to it. 27 + 12 = Dec 39 = Bin 0010 0111 (2 and 7)
Dec 54 = Bin 110110. 54 is between 50 and 59, so we add 30 to it. 54 + 30 = Dec 84 = Bin 0101 0100 (5 and 4)

 

Handy. So if I had a truncating division operator, I could just divide by 10, multiply the result by 6, then add to the input?

 

Yep....

Edit: Added a couple of screenshots of the encoder. This is the minute encoder.



In the side shot, you can identify the different layers of logic by the sandstone. From right to left it is:
6 Receivers for time data
6 Magnitude Comparators to identify range of number
5 AND gates to reduce the output of the comparators to a unique bit for each range.
1 Router to convert range to value that needs to be added
1 Adder to add the two numbers together (this adder has a 7th receiver attached to input the original number)
2 Segdrivers to convert to a segment format
14 transmitters to send the output to my display

NOTE: I used a lot of receivers because then it meant I didn't have to worry about routing 6 bit busses all over the place! There are 7 components that need the same input data (Adder and 6 Comparators)
Also, I'm sure you can see how some sort of I/O block could shrink this down quite a bit!

Also, I think I found a problem with the daytime circuit. it reports tick 0 as hour 0 (midnight) when in fact it's 8 AM. So all the times are off by about 8 hours in relation to the actual time based on the night and day cycle.

 

@Mordenkainen Ok, now I get it Nice construction.
I usually do everything with receivers/transmitters. It's also much faster than redstone wire lines that can sometime cause weird delay issues (the signal travels at 1 wire block per game tick).
You could possibly save some signs by using 6-bit receivers and transmitters, although they would each need an extra clock input/output bit for synchronization. You could also build the segdrivers directly attached to the display, then use two 4-bit transmitters for each digit instead of 14bits, saving some space.
I'll try to implement the truncating (is that a real name?) integer division option soon.

 

I believe it's properly called "integer division". I don't know the proper term for the associated remainder operation. In programming it's mod or modulo.

 

Remainder is modulo. Programming gets the name from mathematics where modular arithmetic provides looping systems.

 

Thanks for he suggestion on the segdriver, I'll give it a try.

As far as the receivers, I'm already using 6-bit transmitters/receivers. I just have 7 of them because I have 7 places the date value needs to get fed in.

If you are going to be looking at the sources, perhaps you can find the time to look at the 8hr offset with daytime? should be easy to fix, one way would be to add 8 to the value, then subtract 24 if it's > 23. I am currently doing this with a couple of adders and a comparator. BTW, 2's complement subtraction works fine!

One other suggestion I thought of would be receivers configured to only take a particular bit from the transmitter. So for example, you could say to the pixel circuit that it is channel "digit1", bit 0, and use a standard 7 bit transmitter to send the full 7 bits, with only the appropriate bit being picked up by the receiver.

Morden.