[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

 

Just use autohotkey.

 

13 adress input 4 color input and 1 clock =, i can count to 16 with 4 pins but you know that

 

DOH! Guess I didn't have enough coffee this morning!

So yeah, 18 pins... what he said! LOL

 

@Malkierian Great tutorial! If you can make more of these I'll be honored to embed them I've also added your circuit library to the list. Forgot to do it yesterday.

@Mordenkainen I think I can add your suggestion about the parallel inputs as a special shiftregister mode. It means just adding a way to directly access the circuit's register if I understand correctly. I would really like to see a working example of serial data transfer in RC so I would rather work in that direction instead of adding an option for more parallel inputs and outputs.

I think adding variable start bit inputs to the transmitter could make that possible. You can make all your receivers work on the same channel but on different bitsets by using <channel name>:<start bit> as your channel argument. Then you can set the start bit of the transmitter to a different value each time to have the data go into a different receiver. The only problem is that if you have a huge channel you would need a lot of input pins to set the start bit. For 5000 pixels of 4bits each for example you would need 15 bits. But on the other hand 5000 is a lot!

About the special activation key discussion, I've added an /rcactivate command (btw I've also removed all dashes from command names) so it can probably be mapped to whatever you can think of by other plugins, circuits or other stuff.

On a completely different subject, here's a WorldEdit schematic file I made of one 7-seg display digit. It includes a 5-pin receiver connected to a segdriver in blankPin mode which is in turn directly connected to 7 pixel circuits running 7 segments of 2 wool blocks each. All this in a 4x7x11 region. The only thing necessary to display a digit is to send some bits to the receivers channel. Let me know if you manage to make it work. I plan to eventually add it to the wiki as well with screenshots etc. but wanted to make sure it works first.

 

@eisental Link for the schematic is dead.

@EveryoneElse OK, if I would make more tutorials, any requests on what I do first?

 

Oops, works now.

 

Couldn't find this in the documentation. We are looking to change the block types used, but I Wanted to make sure I don't screw everything up. First, can I use data values for blocks, or how does that work? Second, will it swap out the blocks for any current circuits, or do I need to go through and replace the blocks once I switch the preferences?

Thank you.

 

You can use data values by writing for ex. /rc-prefs inputBlockType wood:2 if you want to use wool colors you can just put the color name: /rc-prefs inputBlockType wool:yellow for example. In the current version the blocks won't change automatically but the old circuits will keep working fine. On the next release there will be a new command to update the block types to match the current setting. You would also be able to select an area and update all the circuits in that area.
In any case changing the preferences block types would only affect new circuits keeping the old ones working even if they use different block types.

Released RC0.88, BC0.88 and SL0.24

As usual, check out the changelogs on the 1st post.
Please try the new commands and let me know if you find any issues or have any suggestions or questions. I still need to update the circuitdocs and howto pages on the website. I'll probably finish it in a few hours from now. In the mean time you can get updated commands help using /rchelp from within the game.

To library authors: Circuit.saveState() and Circuit.loadState() are renamed to Circuit.getInternalState() and Circuit.setInternalState() respectively. This might break some 3rd-party circuits.

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

 

Heyhey me and shamebot found again time to make something.^^
Enjoy

 

very nice , and fast
but hey, very big thanks for that autohotkey thing

 

@needspeed10 Very nice! Does it make a circle every 12 hours when connected to the clock? What size is the screen?

EDIT: Finished updating the howto and circuitdocs.

 

Wow, man! Puts my clock to shame!

 

I'm tempted to make yet a third clock based on my newest circuit type.

 

It's nothing to rival the clock that was just posted, but here is a video of my proof of concept for a scrolling message board.

It's nothing special, but it's a start!

 

@Mordenkainen That's very cool! I didn't think 1 block pixels was possible. How did you do that?
Is the A letter read from an sram?

 

In the video the we're using a daytime with the arguements: earthtime and minute, so it cycles one time per hour.

Ok, this beats our clock.
Are these normal pixels?

 

Hello,

I've been secretly running this on my server to handle the backend puzzles and such without telling my users much about it, but I'm worried that if I do then they'll use up the wireless namespace and there'll be collisions everywhere.

Could you use the 3rd sign argument to specify the "network" that wireless channels are in, so I can have my own "admin" network for all channels there; and my users can have their own individual networks? You might even use the 4th sign argument for "super-networks" so I can have a "puzzles->rubiks->fronttopl" for the top-left color on the front face of my Rubik's cube which is in the "puzzles" super-network.

There's also the idea of integrating Permissions into your plugin, but the few users that'd be willing to use your plugin on my server I'd be willing to trust as long as I can give them their own networks.

Thanks,
-- Michael Burge

If you look carefully, many of the widths are exactly 3 wide. My guess is that he fills the entire area with red, and then stamps out white areas to give the appearance of 1-pixel wide red blocks.

 

The letter A is read from an SRAM chip, I am working on filling an SRAM with an 8x8 bitmap font, though currently is only has capital A and B in it for testing purposes.

As far as the pixels, no they are not "normal" pixels.

I have made a very minor (8 lines I think) change to the pixel chip to allow an additional parameter that results in a pixel that only updates a single block of wool, on a specified interface block face. I didn't want my test screen to be 24x24 blocks! LOL.

I would rather update it to allow you to be more specific in what you want the pixel to update, but for the moment this hackish fix is enough for my purposes. If people would like more details, I can provide them, but wouldn't want to interfere with anything eisental may have planned for the future!

I'm a modder at heart, so i hope I'm not annoying eisental by modding the hell out of his plugin!

Morden.

 

@Mordenkainen I suspected you made some code changes The reason I didn't add a radius arg to the pixel was that anything more than 3x3x3 seemed to be too much processing and I didn't think of making each pixel circuit of a different material so thought 1x1x1 was impossible anyways. I'll add it next time. Seems very useful

What do you mean by that? any concrete ideas?

@MichaelBurge I was also thinking about private channels and such and making private networks seems to be a reasonable idea. I think there needs to be a serious rework of the sign argument parsing code before that can happen though. It's becoming impossible to add new arguments to some circuits (like the pixel for ex.). Of course to manually manage name collisions in the case where all users trust each other, you can just check the list with /rcchannels each time you're making a new channel, making sure not to use an already existing one. Also, you can use much less channels if you use the channel name syntax with a start bit. For ex. pixel:5 instead of pixel5. There's theoretically no limit to the amount of bits each channel can use.

I was wondering how long it was going to take until someone mentions permissions. I'm still waiting for native bukkit permissions which seems to be pretty near. Do you have any ideas on a good way to implement it? I guess all commands should have a permission key but it can also work for specific circuit classes.

EDIT: You could add the network name as part of the channel 'address': <network>:<channel>:<start bit> that could work well with existing circuits.

 

Hi
This plugin is great, but could you add a chip to convert binary to BCD?
I'm trying to build a clock, but its difficult to calculate the digits. (16 hour: first digit is ((8 AND (2 OR 4)) OR 16)
second digit is (6 + the other outputs))
it would be much easyer to just convert this to BCD, and use this BCD code to set the segdriver.
greets,

 

i hope A comes from sram, otherwise, make it happen, all the power is in the sram! you can display anything. but i am very curious to know how 1 pixel is made, because i am waiting now, with a big screen, and a big plan, but waiting for the new circuit's (or is it in 0.88? have to check circuitdoc). thanks to that i still have to name my pixels (again) so if there is a way to change that, i would very like it! 5000 pixel screen will then be a 45000 pixel display LOOOL. HD is coming but it will be possible to build, the question is, how to set a full frame. every frame for every pixel has to be set first! i almost need a bot, that is able to set levers. again and again (not always the same) and some converter, that is able to read i.e an excell file with colours, and is able say read a cell color and convert it into 0101 (if green). it would be fun if it would be able to read a real image (picture) and convert it. the work i will do is actually a human scanner. hmmmm, better stay with my 3x3 and 5000, will be more then enough. (45000 for every frame. 50 frames = X45000

 

There are a lot of ways to do this now. You can use the ClockDisplay library or if you installed SensorLibrary 0.24 use minute1 minute10 hour1 hour10 or second1 and second10 as time fields to the daytime chip. I just realized I forgot to add them to the daytime doc page. 3rd option would be to use the divider in modulus mode.

@treve You can see in Morden's reply that it is indeed read from sram. I'll try to update basic circuits to support 1 block pixels very soon.

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

 

thats fast where are you from actually? i am not in building mood last days, just planning, and watching, project paused, want to do other things first, and offcourse testing 0.88 and new things i think its to big, setting input would be a hell of a job, much more then building would become, if my server would even hold it

 

Yeah, I'm just sitting next to the computer at the moment... I think it would be pretty easy to make a small program to convert images to sram file yaml format. Then you don't need to set any levers...

 

it would be nice if it was possible to copy/paste (worldedit) and copy the circuits also. and past it into other server, so it would work also (activated etc) but thats more a 3th party plugin job then RC, but its important it copies the circuits more then the blocks, so i post it here, but should not be a job for eisental.

lol, didnt read youre post. would it be possible? it would be crazy. i was about to hire some low-cost illegal workers to set sram for me

 

With RC0.88 you can mass activate all the circuits after pasting the blocks. Type /rcsel once, then right-click 2 corners and type '/rcsel activate' to activate all the circuits in the selection.

 

build a wooldblock, connect a lapisblock to it (interface)and then build a sandstone connected to the lapisblock
build a sign on the sandstone, containing tekst:
pixel
a1 (this is the broadcast channel, send colour to a1).

rcsel is very nice! the problem is (at least i think) you cannot copy a building (like the clocks posted) and paste them on youre own server, to connect it other rc-stuff, but that more for worldedit, but maybe its already possible

 

It's already possible with WorldEdit //save and //load. That's how I made the segdisplay schematic
(http://eisental.github.com/RedstoneChips/schematics/rc-segdisplay4x7x11.schematic)

 

Which, from what I could tell, worked perfectly! At least, it worked to paste it into my world. I started having problems with permissions at that point, though, so I couldn't keep going with it...

EDIT: OK, I JUST tried it, and it seems the inputs are a little weird. I assumed you hooked up a daytime to it, but when I did minutes, because of the clock and blank pins, it just barely didn't get through to e and f on the count. But, for what I can tell its design is meant to do, it seems to work exactly as expected. You just have to expect the right thing

 

Not concrete, no. I know what I would like it to be able to do though. There are two parameters I want to be able to specify to the pixel:
1. The area affected. For example a standard pixel would be 3x3x3. But if I only wanted a 3x2x3 pixel, or 1x1x1 pixel, it would be nice to be able to tell the pixel that.
2. Where the interface block is in relation to the wool. So if I want a 2x1x2 (2 high, 1 deep, 2 wide block of wool for example) with the interface block being in the lower lefthand corner of this 2x1x2 block I could. This is hard to explain, but using the example above the result would be something like this:

Code:

WW
IW

With W's being wool and I being the interface block.

I agree that commands could have permissions, but adding permissions to the classes could be troublesome from a server maintenance point of view. I personally wouldn't want to have to add a whole bunch of new nodes every time a few chips got added. (though I guess you could use "redstonechips.chips.*"). And then you have to worry about extension plugins chips as well.

One special case I thought of would be permissions for creating transmitters and receivers for particular channels, that way if you have a combination lock connected to a door wirelessly, someone can't make another receiver and get your code, or just create a transmitter that opens the door. But, I wouldn't use the permissions systems in Bukkit for that. I would add a command that sets permissions on the channel that the person creating the channel could use after they create the channel, rather than requiring them to bug the server admins to add a new permission node for them.

Another permission would be for destroying chips... I mean physically, not via command. Have a permission that indicates if a user is allowed to destroy chips that don't "belong" to them, and if not, do not deactivate the chip, give them an error and put the block back.

One other suggestion. Perhaps you should talk to the author of WorldEdit to see if there is a way to plug into his region selection the same way WorldGuard does. This is already a very robust method of selecting regions, and could even mean that when WorldEditCUI is updated the user will actually be able to see the region they have selected on the screen! Of course, you would either need to disable region selection when WE is not installed, or fall back to the existing method.

Morden.