[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

 

Oh man is that true? It was working until 1.7 (whatever the latest CB that was 1.6), I was hoping there would be an update to make it work in 1.7.

 

I really don't think it's redstonechip's fault, the stacktrace says the error occurs when the input of the dclock chip changes, so you might ask in the ClockDisplay thread.

 

my apology, i have asked in that thread, one of the players asked us to add redchips specificly for the clock feature

 

lol?

 

i mean sorry for blaming redstonechips if it was the fault of the clock attachment

 

Is there going to be a 1.7 Update?

 

I haven't tried it, but expect Redstone Chips should work on 1.7. I don't think anything changed that would break this plugin.

If you are getting an error, post the details.

Morden

 

I had an issue after upgrading to the 1.7.2-compatible bukkit server (git-Bukkit-0.0.0-904-g9277096-b953jnks (MC: 1.7.2)).
In one corner of my castle, I have a lot of redstone chips, and after upgrading, all signs nearby went blank and all chests nearby were empty. I can mail (or put online) an archive of the world and the redstone chips database.

PS: I have created a BCD chip with offset, modulo, clock-per-group and blank-per-group. It should be able to replace ClockDisplay. I'll soon find out how to put it online.

 

@Morden

I'll post the error later on, but there is an issue with making any NEW redstone chips under 1.7.2. I got a large server log but can't really don anything until I can get the server cleared off tomorrow.

EDIT: I found that it was indeed Clock Display that was at issue. I have since modified ClockDisplay and currently have it working without any issue. As soon as I have tested it thoroughly I will post a link to that modified file for others to use.

 

Heyya, having a weird problem, and thought I'd see if anybody knew if it was redstonechips related.

Short version: signs are blanking themselves out

long version: random signs are blanking out... some are keeping their text, some are not. This causes alot of trouble as we use redstonechips/uquest/puzzlequest/falsebook and signs are needed to drive events that occur in the world. I'm not sure if possibly one of them might be the culprit, but I thought I'd check here and see if anybody knew anything.

 

Only signs on redstone chips, or signs in general?

If it's signs in general, I would expect that to be a CB issue.

 

signs all over... on chips, falsebook IC's, just... signs hanging on walls, everywhere. It's odd too, as it's in a multiverse world, not our main world.. but out of 4 worlds, it only seems to be happening in 1.. the one that heavily uses uquest/puzzlequest/redstonechips

 

For me, it seems to affect the chunks with too many redstone chips. If I had to guess, it's like a buffer overflow in the chunk's data storage for chests and signs (which should not be possible in java).

Is this similar to your experiences?

 

actually, it turns out this may be a bukkit issue

http://leaky.bukkit.org/issues/1052

 

is there any permissions or way to change the chipBlockType? I'm OP on the server. using craftbukkit 1.7.2

/redchips-prefs chipBlockType sandstone did nothing...

 

I'm honestly confused about all these commands on RedstoneChip, and I read that for the transmitter, if it has more than one output, then it will treat it like a clock, how do I fix this?

Reason I ask is because I can't get this to work:
http://gyazo.com/b283a7ec7f60d3f25a2b90d0f15e1410.png

 

The chipblock type is the block type you attach the sign to. There is no configuration for it, and it is not a fixed type. It just tries to use whatever type you activate the sign on.

Do you need to activate these pistons independently, or do you want them all to move at once?

 

i want all the outputs to get power, not just 1

 

Ok...

So first you need a single input transmitter...

Next you need a single output receiver. Connect the output of that receiver to a repeater chip with one input and three outputs.

That should do what you want.

Morden.

 

I get what you mean (heres the pic http://gyazo.com/8c76f1d3dd062119626fb18bf5314e4c.png )
but is their a way so I don't need that extra bulk? Trying to make a door as efficient as possible.

 

You can make it a little smaller. Put the gold block for the receiver right next to the iron block for the repeater. Put redstone on top of iron block, put a lever on top of the gold block.

Morden.

EDIT- I think it could be done even a little smaller than that, but I would need to experiment a little and know more about the space constraints you are working under.

Also, you could use a multi-bit receiver, which would save a lot of space, but require some special wiring.

Smallest I can get it without playing around is 5 tall x 1 wide x 3 deep (not counting extra space required for signs.).

 

Yeah. I was thinking of multi-bit receivers, but I didn't really know how to do that. Do you have a tutorial or something?

 

Not a tutorial really, but for your application:

At the pistons, a single receiver with 4 outputs. The output closest to the sign should not be connected to anything, the other three should be positioned the same as you have now (so put the first output underground or something like that.).

The transmitter should have 4 inputs. connect the last 3 inputs together with redstone. run redstone from those inputs to a lever, or button, or whatever is going to send the signal. Also connect that 'whatever" to a delay chip, set to some very low delay, and connect the output of the delay chip to the first input of the transmitter.

I know it's a horrible description, but it you give me a few minutes I'll post a diagram that may explain it a little better.

Here is the diagram:

View attachment 4674


Actually, there is an error there. The delay chip should be a delay chip, whose output should be sent to a pulse chip with a pulse of "0" and the "doubleEdge" parameter. The output of that pulse should go to the transmitter.

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

 

That's a bug in Minecraft, thus affects Bukkit as well - jeb acknowledged it on his twitter. I'm running RedstoneChips fine on 1.7.2 and haven't run into that bug yet (and hopefully won't until it's fixed!)

 

Quick explanation of multi bit transmitters and receivers:
If you have a single bit transmitter, any change to the input is immediately reflected at the output of the receiver. With a multibit setup, things work a little differently.

The first input of the transmitter becomes a "clock" input, so any change to the inputs are not sent to the receiver until the clock input is pulsed. It is likewise for a multibit receiver. The first output is the clock output, it will send a pulse whenever a pulse is sent to the clock input of the transmitter, indicating that the receiver has received new data.

This allows you more control over when the data will be sent out.

One additional feature may be added in the next version of RedstoneChips. If the transmitters clock input is kept in an "on" state, then any changes to the data inputs will be sent immediately, similar to how a single bit transmitter behaves.

Multibit transmitters and receivers have many more features, but they are a little too complex to get into here.

 

That mod is awesome!
I like it, got latest version from github, made some custom chips, everything works fine now.
But also I had some drawbacks (which I managed to fix by using sources). For example when the server starts up and receiver and transmitter are both switched on, transmitter would send it's state, but it can be lost because of loading order (it send but receiver is still not there), and after that when you turn transmitter off it sends s 0 bit, receiver gets it and sees it got itself a zeroed bit already (its put 0 in initialization i suppose) and it does not check lever to be outputting 1, it just thinks it is 0 like said to be and does not turn off. (My fix was to make each receiver get current channel bits while initializing channel for itself - that fixes load time mis-ordering, and also i added output state check during initialization to prevent first change desynchronization of initial zeroed state and levers).
Also there was a thing after some minecraft+bukkit update: I have construction where two neighboring pistons have output under them: gold block to one and lever to other, if you switch lever yourself - pistons move both, but if you use receiver or something else - only lever's piston do move. Made a rude fix for this by force-updating nearby redstone-dependent blocks. (still does not help sometimes)
And I have chosen a 'beta' clock to the one which was in latest sources (had no interest in transmitting clock, that bothered me after simple one because it used my frequency not as frequency but as channel)

And my own circuits are:
- 'antigrav': for gravity lifts, they take living entities above interface block and apply them lifting force depending of their aim
- 'lightning': which is remake of original 'spark' (from Sensors) but stripped to one interface/input but can do standart and fake lightnings
- 'lightsensor': remake of original 'photocell' which is checking not every block around which is not in that circuit but only some transparent ones
- 'mobspawner': that obviously spawns chosen creature when input goes on
- 'presencescan': remake of 'pirsensor' which now has integrated clock and needs only on/off input (that is perfect to make automated doors which open if someone comes near)
- 'rslatch': it is memory cell with set input and reset input, gives on if 1 on set-input and resets to 0 if reset-input (and keeps 0 if reset is 1 even if set is 1 also)
- 'tranceiver': that one is just like transmitter but without clock pin, it sends data as it changes instead

 

Or add an option "noclock" in the third line. An option "level" could do what you described (so existing setups will continue to work). Maybe you'll wnt an "edge" option which would make the default behaviour explicit.

A "noclock" receiver will have no clock output, and a "level" receiver will reflect the clock state instead of pulsing the clock line on input changes (and keep it's value while the transmitter's clock is off).

A "level" receiver with a "noclock" or normal transmitter will just pulse the clock line.

PS: I think I could use your chip designs.

This seems a general problem with setting levers from plugins. Unless you add a redstone wire, the game's behaviour is very erratic. The "best" workaround is to have a redstone wire on some blocks next to the pistons and to power it.

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

 

Another one problem is torches: they sometimes stuck in switched off state and do not turn on in any case: You place a new one, you replace redstone wires nearby - it still off and I could not manage to reproduce error precisely to make a fix for it

 

Much of that can already be done with the existing transmitters and receivers.

In the majority of cases a multibit transmitter is not particularly useful without a clock, since you have no way of knowing when the data is ready to process. If you have an 8 bit, no clock transmitter, the data will change up to 8 times before the "final" value is present on the receiver outputs. If your output circuit processes every state change, you are consuming server time you probably don't need to. You can only do so much in a game tick before you introduce lag.

A multibit receiver without a clock is already possible using bit ranges. (though the transmitter still requires a clock)

I'm not sure I see where the "level" system would be useful, but in any case can already be done using other chips.

So, for permissions in RC, what would people want to see?

Here is what I can think of off the top of my head:
- The ability to restrict users from creating certain chips.
- The ability to restrict users from destroying certain chips.
- The ability to restrict users from using certain commands.

What else?

Morden.

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

 

Set up a github account and upload your changes. I would love to take a look.