1
Redstone petition
so i am a fan of making songs with redstone and note blocks. but these note blocks are so very limited by both their octave range and the tempos that they can create due to the limits on the redstone repeaters. oh and let's not forget the insane lag that is caused by lots of redstone being used. so I've decided to start a petition to upgrade the note blocks, and the repeaters. and to change the code in the redstone so that it's not as laggy. so who's with me? if we get enough names, they just might listen. (even if there's only a small chance, i'm annoyed enough to try.) so tell your friends. and post in a comment here something like "upgrade the redstone!" and things like that.
Create an account or sign in to comment.
11
1
NeptonicRevolutionalRedStone
It's not his computer which makes Redstone the slowest CA available, it's Notch
Don't blame Notch for something in a game he hasn't even touched in about a year.
Notch wrote the Redstone engine, and i know it has never been re-written; Jeb and DB added some items and changed the dust-powering rules but that's had no effect on the RS engine efficiency or the Hash-iteration ordering problem.
Neptonic
Also this is going to turn into a flame war, I can tell.
Internet forum flame-wars only occur amongst individuals uninterested in reconciling their various understandings and finding truth.
1
RevolutionalRedStone
It's not his computer which makes Redstone the slowest CA available, it's Notch
Don't blame Notch for something in a game he hasn't even touched in about a year. Blame Jeb, or more realistically, Dinnerbone since he actively works on redstone mechanics.
Also this is going to turn into a flame war, I can tell.
1
1b8I don't find redstone laggy at all.
No, it is simply that your expectations are skewed by bad programming.
With any computer you can buy today; you should be able to switch 1,000,000 torches without trouble. but you can't. even with an excellent $8,000 dollar computer you can't.
It's not his computer which makes Redstone the slowest CA available, it's Notch, it's Minecraft.
NeptonicEver heard of instawire?
Repeaters can't keep good tempo, my butt... Instawire! Don't just rely on prebuilt circuity for God's sake.
The problem cookies mentioned with tempo is not one of data-transmission speed...
It's one of update frequency; there are only 10 Redstone ticks per-second. instant wire might increase how much you can do in each of those steps; but the problem is fundamentally that there isn't enough steps; most songs include noises and breaks far shorter then 100 milliseconds.
1
Ever heard of instawire? Ya, go look at the wiki sometimes
Repeaters can't keep good tempo, my butt... Instawire! Don't just rely on prebuilt circuity for God's sake.
Repeaters can't keep good tempo, my butt... Instawire! Don't just rely on prebuilt circuity for God's sake.
1
I don't find redstone laggy at all. It's obviously just that you have a bad computer.
-1b8
-1b8
1
Harsh.
But probably true.
But probably true.
1
Please do not change the redstone, WE redstoners are planning TO KILL EACH AND EVERY SINGLE SERVER PLUGIN.... with redstone and ~~{style}~~
1
I'm a redstoner, and a coder, No.
1
That's a brilliant idea ( the petition ) and you're certainly not alone in wanting the underlying Redstone implementation to be improved.
As some back story, this information might be relevant:
( Regarding Redstone )
- Redstone approximates a long researched system called a 3-D Von Neumann Cellular Automata ( or CA for short ).
- Instead of per block Redstone is calculated per component using something called a hash-set iteration.
- The hash-set was implemented as an optimization; but Redstone still performs extremely badly; even when compared to old-unoptimized CA.
- The hash-set is the core key and reason for all bugs, glitches and indeterminacys in Redstone, because the order of iteration is not fixed; but instead extremely close too random. ( in fact it's based on your Minecraft clients memory usage )
- Computers have been used to simulate CA long before Minecraft or Redstone was even dream-pt up.
- Empirically; a well written CA even run on a basic work station can process many billions of interactions per second. ( Redstone maybe a few thousand )
Okay, so the primary things i would like to see implemented include:
An update command buffer : would removes almost all glitches.
( Rather then iterating over components based on hash-entrys; an idea invented long ago for basic CA called the command buffer could be used )
A deterministic rule-set : would remove the other few glitches.
( Rather then updating components based on there location in the world or there orientation or there distance from the player; Updates should be applied in a uniform and unchanging way )
A hash-look-ahead sparse binary voxel octree : would vastly increase performance.
( Rather then representing components as bits in a matrix or elements in a list; Hierarchicalize the data-set using oct or KD spacial partitioning and store the hierarchy instead; both spacial and temporal redundancy would be squashed out of the simulation step and performance would be increased for most circuits by something like one-hundred-billion times )
Great thread Cookies.
As some back story, this information might be relevant:
( Regarding Redstone )
- Redstone approximates a long researched system called a 3-D Von Neumann Cellular Automata ( or CA for short ).
- Instead of per block Redstone is calculated per component using something called a hash-set iteration.
- The hash-set was implemented as an optimization; but Redstone still performs extremely badly; even when compared to old-unoptimized CA.
- The hash-set is the core key and reason for all bugs, glitches and indeterminacys in Redstone, because the order of iteration is not fixed; but instead extremely close too random. ( in fact it's based on your Minecraft clients memory usage )
- Computers have been used to simulate CA long before Minecraft or Redstone was even dream-pt up.
- Empirically; a well written CA even run on a basic work station can process many billions of interactions per second. ( Redstone maybe a few thousand )
Okay, so the primary things i would like to see implemented include:
An update command buffer : would removes almost all glitches.
( Rather then iterating over components based on hash-entrys; an idea invented long ago for basic CA called the command buffer could be used )
A deterministic rule-set : would remove the other few glitches.
( Rather then updating components based on there location in the world or there orientation or there distance from the player; Updates should be applied in a uniform and unchanging way )
A hash-look-ahead sparse binary voxel octree : would vastly increase performance.
( Rather then representing components as bits in a matrix or elements in a list; Hierarchicalize the data-set using oct or KD spacial partitioning and store the hierarchy instead; both spacial and temporal redundancy would be squashed out of the simulation step and performance would be increased for most circuits by something like one-hundred-billion times )
Great thread Cookies.