Big Red Book of Redstone Standards

  • #41
    Quote from Coolie_747

    you should plz fix your server first


    waiting on stable recommended bukkit + worldedit release :tongue.gif:

    Edit: also not touching anything until redstone changes are, for sure, will not be patched back to 1.8 mechanics
    Last edited by dracoix: 12/2/2011 2:53:50 PM
  • #42
    Quote from dracoix

    Stay in school kids, don't multitask while in class and then forget to read it after.

    BRB while I fix that, and thank you for pointing that out.

    Also I didn't break it by starting at 1, some use 0-index, some use 1-index in programming, it doesn't matter as long as you state which one you used.

    There is a 7-segement display place holder and it's translating components combining a display code with a translator code means it's a display of whatever system.

    I'll port some information from it's original thread for better understanding as well. But please, do read for better clarification or spot more corrections needed.

    Anyway, time to fix!




    I agree that it weren't one of my best posts, but I wouldn't recommend being that negative about the people that is giving you feedback, I actually had some points, and it's people like me that is going to use this standard. It will make you look just a little bit arrogant, like you did after this post. You don't know who is behind the scene, and you might end up underestimating people, like you did here. You know nothing about what I did during that time. The truth is that I was pretty tired, but knew I had to submit it before going to bed, otherwise I would never get it done. I feel the need to disprove you, so this time I have read ANYTHING, and I will be much more clear and extensive.





    On-topic

    I think it is a great idea to have some kind of standard for redstone, but I am a little bit uncertain what exactly this is. In the original thread there is much focus on that this will be a huge database with numerous different designs of each entry. But is this thread there is not any focus on such database. Am I correct when I assume that it is because this thread represents the standard, while the database is based on this standard, but not incorporated in it? If yes, then what about the size calculations you proposed is the original thread.

    I personally think that this standard should contain of 256 groups with 256 individual entries each, and not more. it should be written is the format "IPRE-xxx.yyy", so you can easily see under which category in belongs under, and not like "IPRE-xxxxx" as you have done several times in the OP. The D should only be applied if you are referring to a category. If you were to make a database, you would require schematics, and the idea of being able to store things is 32-bit words disappears. How the different versions of the same entries are rated, should depend on the database, and I will here not comment on that.



    The concept of the standard

    For my next point to be clear, we will have to throw up the basic question. What is the actual point of having this standard? Is it...:
    1. ...To be able to list every creation under an entry, so you will be having codes for each circuit?
    2. ...To prevent the never-ending postings of people that think they have created something revolutionary?
    3. ...To have a common reference for comparing circuits?
    4. ...To be able to use it as a base structure for a huge database of the different designs?

    My thought on each of these:
    1. We can quickly agree that there is no limits on how many different circuit designs we can make, so the ultimate goal here is already lost. If we group these by functionality, we have less to deal with. But still, as long as you keep making more complicated circuits, the possibilities grows too high. This means that we in some way will have to limits us to the simple creations for these standards.
    2. There will always be people proclaiming they found something remarkable, but if we wish to use these standards to disprove it, we will have to have the most of the simple system covered with entries, since it is these that suffers from it.
    3. Some circuits, like adders, will there be many different version of, and therefore these should maybe be split into different entries for the different concepts. But on the other hand, it won't work if there is entries with very few or none examples in them.
    4. To have a database of large machines makes no sense to me, but having a database of components makes good sense. Therefore there should be room for all the components that you think is generally useful.

    I personally think that #3 is most important, but the others are also very valid. In any case, I would say I can conclude several things of how the properties of such standard should be:
    • There should be entries for almost all the components with a general purpose that is made of redstone.
    • Popular circuits should be covered better than non-popular.
    • You should be careful on not to make them too complex.
    • Some very popular entries should have several entries if they are possible to make with different techniques/results.

    One other thing that I think also should be present, is entries for tileable versions of the different components. A full-adder is good, but I would only use it if is can be tiled is a good way. The use of tileable circuits is very important if you get to do more difficult things.



    The actual standard

    You can see from my arguments above, that I really think there should be some modifications to the current list of categories and entries, before this will be really that useful as I hope it will be. I will here come with ideas to categories and entries that I personally think should be present. These are not set in stone, and will not be, since that will prevent improvements.

    First of all, It is nuts that 70% (guess) of all redstone circuits designed is compressed into the first two D-categories, while you are having 150 is reserve for backward compatibility, bug abuse and special cases. How is backward compatibility preserved if you are storing the old version in different categories? You have also stated that make things ready for expansion, but compressing things doesn't do that. Also, some of the D-categories are having no children, so why should they take up room if you have no specific ideas?

    This list is not meant to be complete, nor to be adopted directly. I hope there can be many more entries, this is only meant to showing which kinds of components is going into the different categories. A dot can represents multiple entries. (* may change), means that there could be more entries with different *.

    List


    Boolean functions/combinational devices
    • The fundamental 2-bit boolean relationships
    • Multi-input versions of those possible of that
    • 2-wide tileable versions (may contain different slices)
    • MUX and DEMUX
    • Multi-function logic gates
    • Combinational locks
    Basic sequential logic
    • RS-NOR (different version, like Basil-flop, etc.)
    • T-, and D-flip-flops
    • Sequential locks
    Timing components
    • Monostable circuits
    • Inversion clocks, torches (speed may change)
    • Pulse clocks, repeaters (speed may change)
    • Long time clocks (different versions, like dispenser-clocks, web, etc.)
    • Pulse length detectors
    Arithmetic components
    • Half-adder
    • Full-adder
    • Tileable ripple-carry adder (size and bits may change)
    • Carry-look-ahead adder
    • Tileable Instant-carry adder (size and bits may change)
    • All above as subtracters
    • All above as combined adders/subtracters
    • Recursively multipliers (bit size may change)
    • Wallace tree multipliers (bit size may change)
    • Linear multipliers (bit size may change)
    • Two's complement inverters (different version, like absolute value)
    • Division circuits
    • Compare modules (<,>,=)
    • Random Number Generator, RNG
    Registers
    • D-flip register (width may change)
    • T-flip register (width may change)
    • Shift register (PISO,SIPO,PIPO, and mixes)
    • Bi-directional shift registers
    • Feedback shift registers
    • Counters (synchronized or not)
    • 2D version of above
    Computer components (many variables, like bus width, functions, size, etc.)
    • ALU
    • RAM
    • ROM
    • PC
    Event sensitive components
    • Block Update Detector, BUD (T or normal)
    • Particle Emission Detector, PED
    • Proximity detectors
    • Light sensitive units (mechanisms may change)


    After a little personal startup, I hope you will be able to look positive at this, and think about my arguments. This kinds of project should belong to the community, and you cannot expect it to be perfect after almost none revision.

    I still always find it good to see people doing something for other, by their free will. Thumps are still up for that.
    Participate in the completely free MIT course 6.002x "Circuits and Electronics". You can still enroll!
  • #43
    Quote from Simnik

    -snip-


    (quick reply to a misunderstanding)

    I was referring to myself for the "stay in school" comment.

    Most of my type-ups are done in-between college classes rather quickly and sometimes after a lecture I do not re-read them for corrections, rather add to them. So forgive me if the post seemed arrogant as much of it is quickly typed up and "submit" before class starts on a "oh crap, hurry up type, then go." :smile.gif:

    (also now reading your post in its entirety, just wanted to get the misunderstanding out of the way)

    EDIT: Also the "back in the cave" comment was directed at my room-mate's post.
    Last edited by dracoix: 12/2/2011 8:24:27 PM
  • #44
    Quote from Simnik

    I think it is a great idea to have some kind of standard for redstone, but I am a little bit uncertain what exactly this is. In the original thread there is much focus on that this will be a huge database with numerous different designs of each entry. But is this thread there is not any focus on such database. Am I correct when I assume that it is because this thread represents the standard, while the database is based on this standard, but not incorporated in it? If yes, then what about the size calculations you proposed is the original thread.


    This thread represents population of codes to link to the database. I know there are some disconnects between threads and no database up and ready to start throwing stuff in. Remember, I am only one person, who is in college, and approaching finals, after that, all fury will be set loose on this.


    Quote from Simnik

    I personally think that this standard should contain of 256 groups with 256 individual entries each, and not more. it should be written is the format "IPRE-xxx.yyy", so you can easily see under which category in belongs under, and not like "IPRE-xxxxx" as you have done several times in the OP. The D should only be applied if you are referring to a category. If you were to make a database, you would require schematics, and the idea of being able to store things is 32-bit words disappears. How the different versions of the same entries are rated, should depend on the database, and I will here not comment on that.


    You can write it like IRPE-xxx.yyy, or rather just "IRPE xxx.yyy" I see no problem in that and already expect people would. I doubt anyone would write out the full short-hand anyway. And as far as doing it with the bigger number format, that's more or less for organizational reasons (I like me some numbers, I'm sure others do as well.)


    Quote from Simnik


    The concept of the standard

    For my next point to be clear, we will have to throw up the basic question. What is the actual point of having this standard? Is it...:
    1. ...To be able to list every creation under an entry, so you will be having codes for each circuit?
    2. ...To prevent the never-ending postings of people that think they have created something revolutionary?
    3. ...To have a common reference for comparing circuits?
    4. ...To be able to use it as a base structure for a huge database of the different designs?


    1) Yes.
    2) Somewhat of a goal, though those that do not use google or read redstone guides will always post something.
    3) Definitely Yes.
    4) One function, many, many, many different designs. So yes.

    Quote from Simnik

    My thought on each of these:
    1. We can quickly agree that there is no limits on how many different circuit designs we can make, so the ultimate goal here is already lost. If we group these by functionality, we have less to deal with. But still, as long as you keep making more complicated circuits, the possibilities grows too high. This means that we in some way will have to limits us to the simple creations for these standards.
    2. There will always be people proclaiming they found something remarkable, but if we wish to use these standards to disprove it, we will have to have the most of the simple system covered with entries, since it is these that suffers from it.
    3. Some circuits, like adders, will there be many different version of, and therefore these should maybe be split into different entries for the different concepts. But on the other hand, it won't work if there is entries with very few or none examples in them.
    4. To have a database of large machines makes no sense to me, but having a database of components makes good sense. Therefore there should be room for all the components that you think is generally useful.


    1) "No limit" is such a naughty word in mathematics, in a per perspective sense, yes, there are almost no limit to designs per function. In a technical sense, there is a chunk load & active limit also the height limit (which all can be changed, though many are set to default) thereby limiting the size of creations and thereby limiting what can be created. But yes, I completely agree with you, these standards should be meant for the simple creations. I have no plans for standardizing each massive full-working computer or redstone game map, that was kinda thrown out when I typed up the OP. Do to this I am even hesitant whether to even populate the 50-99 region. Thanks to your feedback I probably will not unless someone states otherwise it should be in there.

    2) Yup.

    3) Pardon my redstone illiteracy as I have never built an adder in redstone. I look at redstone logic creations from a broad viewpoint having been using hard logic in my professional (programming) and hobby (robotics in the past) life. A function is a function, there is only one RS/SR NOR function in logic, though you can build one in several different ways, the same with adders and other circuits. But yes I agree, no basic examples provided in either how it works or what it would look like in redstone would be a pitfall.

    4) I agree as stated in #1.

    Quote from Simnik

    I personally think that #3 is most important, but the others are also very valid. In any case, I would say I can conclude several things of how the properties of such standard should be:
    • There should be entries for almost all the components with a general purpose that is made of redstone.
    • Popular circuits should be covered better than non-popular.
    • You should be careful on not to make them too complex.
    • Some very popular entries should have several entries if they are possible to make with different techniques/results.

    One other thing that I think also should be present, is entries for tileable versions of the different components. A full-adder is good, but I would only use it if is can be tiled is a good way. The use of tileable circuits is very important if you get to do more difficult things.


    Agree with much of what is stated. Tileable circuit designs have been addressed with adding a "t{v,h}" tag to the complexity of volume. Although some creations cannot be tiled, it's important to note that some can and should be stated so. If it needs to be clearer to the reader then it should be stated in the title itself.

    Quote from Simnik

    The actual standard
    You can see from my arguments above, that I really think there should be some modifications to the current list of categories and entries, before this will be really that useful as I hope it will be. I will here come with ideas to categories and entries that I personally think should be present. These are not set in stone, and will not be, since that will prevent improvements.

    First of all, It is nuts that 70% (guess) of all redstone circuits designed is compressed into the first two D-categories, while you are having 150 is reserve for backward compatibility, bug abuse and special cases. How is backward compatibility preserved if you are storing the old version in different categories? You have also stated that make things ready for expansion, but compressing things doesn't do that. Also, some of the D-categories are having no children, so why should they take up room if you have no specific ideas?


    Due to the recent and dramatic change in redstone mechanics I can only predict that it will happen again and would store the first 100 parent classes of the previous Minecraft version to the 100-199 area. And then see what would be flagged as broke and adjust accordingly. At least that was an idea. Catagories with no children are left up to the imagination of anyone who wants to make a guess at them. Again, I am only one person, and only one brain with a couple cogs loose, I cannot think up of everything possible, only attempt to prepare for it. Also it can expand by doing: "255.0.1.4" which would be the same as "0.1" but with an expanded node to the "4" for a unique function and creation. The 255 part expands the node tree. It can even be done again such as "255.255.0.1.4.6". It's almost infinitely expandable, provided a clear broad spectrum of populated titles to do so. Also it would just be stated as IRPE 0.1.4 and an API would note that it's an expanded 32-bit tree version.

    Quote from Simnik

    This list is not meant to be complete, nor to be adopted directly. I hope there can be many more entries, this is only meant to showing which kinds of components is going into the different categories. A dot can represents multiple entries. (* may change), means that there could be more entries with different *.

    List


    Boolean functions/combinational devices
    • The fundamental 2-bit boolean relationships
    • Multi-input versions of those possible of that
    • 2-wide tileable versions (may contain different slices)
    • MUX and DEMUX
    • Multi-function logic gates
    • Combinational locks
    Basic sequential logic
    • RS-NOR (different version, like Basil-flop, etc.)
    • T-, and D-flip-flops
    • Sequential locks
    Timing components
    • Monostable circuits
    • Inversion clocks, torches (speed may change)
    • Pulse clocks, repeaters (speed may change)
    • Long time clocks (different versions, like dispenser-clocks, web, etc.)
    • Pulse length detectors
    Arithmetic components
    • Half-adder
    • Full-adder
    • Tileable ripple-carry adder (size and bits may change)
    • Carry-look-ahead adder
    • Tileable Instant-carry adder (size and bits may change)
    • All above as subtracters
    • All above as combined adders/subtracters
    • Recursively multipliers (bit size may change)
    • Wallace tree multipliers (bit size may change)
    • Linear multipliers (bit size may change)
    • Two's complement inverters (different version, like absolute value)
    • Division circuits
    • Compare modules (<,>,=)
    • Random Number Generator, RNG
    Registers
    • D-flip register (width may change)
    • T-flip register (width may change)
    • Shift register (PISO,SIPO,PIPO, and mixes)
    • Bi-directional shift registers
    • Feedback shift registers
    • Counters (synchronized or not)
    • 2D version of above
    Computer components (many variables, like bus width, functions, size, etc.)
    • ALU
    • RAM
    • ROM
    • PC
    Event sensitive components
    • Block Update Detector, BUD (T or normal)
    • Particle Emission Detector, PED
    • Proximity detectors
    • Light sensitive units (mechanisms may change)


    After a little personal startup, I hope you will be able to look positive at this, and think about my arguments. This kinds of project should belong to the community, and you cannot expect it to be perfect after almost none revision.

    I still always find it good to see people doing something for other, by their free will. Thumps are still up for that.


    You have shifted my perspective a lot, and I'm going to have to sleep on some of this. Though it still comes down to just how big the possibilities are in a small space and also taken from real life. But yes, I agree with much of what you said and revisions will be coming like a hail storm SOONTM.
  • #45
    Misconceptions is always a bad thing, now I feel like we cleared it up. :smile.gif:

    I don't really get that extension part, why would that be good? Maybe it is because I don't think the standard should contain of other codes that the category and the entry.

    I would also like to specify that I think there should be a difference between the database and the standard. The standard should work without the database, and the database should be based on the standard. So in the standard itself, there should also be entries for tileable versions, due to the code limit I thought of in the last paragraph.

    If I am to comment on the database, then you don't need to compress anything into codes, but you could make the software capable of sorting after different values, such as size on the different axises, tileability or delay. But someone have to do it, and as you said, you are only one man.

    I don't know how to incorporate bug-use or delay into this, but maybe that should be present in the database only.

    I have I slightly idea of that you haven't had that much experience with redstone since you joined October 13, and since incorporated the JK-Flip-Flop (which noone use), but only just one full adder. I would gladly help making this standard more fitting for what really happens around us with redstone.
    Participate in the completely free MIT course 6.002x "Circuits and Electronics". You can still enroll!
  • #46
    Ow ow OWWW! It hurtz mah brainz!
    Quote from Zenrax »
    Nature is now out of balance. The only solution is to burn it all down.
  • #47
    @Simnik: Very nice post.
    2-wide tileable versions (may contain different slices)

    Every circuit can be checked if it's tileable.

    Multi-function logic gates

    I think those are the same as an 1-but ALU.

    Monostable circuits

    These should be subdivided with RET and FET.

    All above as subtracters

    I haven't seen a device that can only subtract and not add.

    Two's complement inverters

    I don't think you wrote it down in a particular order, but still I would like to point out that this should probably come before subtracters.

    Random Number Generator, RNG

    Not sure if an RNG is an Arithmetic component, but I don't have a better place for it.
    Quote from Simnik
    If I am to comment on the database, then you don't need to compress anything into codes, but you could make the software capable of sorting after different values, such as size on the different axises, tileability or delay. But someone have to do it, and as you said, you are only one man.

    If the database idea continues, we can incorporate much more variables into the system indeed. Maybe even have an online schematic parser. It could even be made to check tile-ability. They would need to be color coded, though, for the system to recognize the in and outputs.

    These fields come to mind:
    • Name
    • Short description
    • Long description
    • Uploader
    • Creator
    • Width
    • Height
    • Depth
    • Redstone dust used
    • Redstone torches used
    • Repeaters used
    • Pistons used
    • Sticky pistons used
    • Gravity blocks used (sand/gravel)
    • Dispensers used
    • Wooden pressure plates used
    • Stone pressure plates used
    • Buttons used (I actually used them to direct wires)
    • Levers used
    • Tileability in directions
    • Worst-case speed in ticks (this would be very hard to parse, specially with pistons and gravity blocks. A certain javascript simulator might prove very useful :wink.gif:)
    • Glitches used (would be joined with 'glitches' table internally)
    • # of bits
    • Schematic downloads (for static purposes)
    • Rating (if incorporated)
    • Date uploaded
    • Last working in minecraft version #
    • Special notes
    • Extra credits
    • Directional dependance
    • The schematic itself
    You would have the ability to go crazy.
    Last edited by CX_gamer: 12/5/2011 1:21:51 PM
  • #48
    Quote from Simnik

    Misconceptions is always a bad thing, now I feel like we cleared it up. :smile.gif:


    You'll know when I'm a ****, it is not pretty and normally ends in me constructively trolling... a lot. :smile.gif:

    Quote from Simnik

    I don't really get that extension part, why would that be good? Maybe it is because I don't think the standard should contain of other codes that the category and the entry.


    Extensions dive into the broad-shot classification. So if 0.0 is the raw component of logic and rules... 0.0.1 would be another set of rules more explicitly defined. Or something like 17.2.1 would be the extension of the original 17.2.0 to designate a design or method of the specified function. The common: "Yo dawg I heard you like functions, so we put a function within a function so you can program with a function that does its own functions."

    Quote from Simnik

    I would also like to specify that I think there should be a difference between the database and the standard. The standard should work without the database, and the database should be based on the standard. So in the standard itself, there should also be entries for tileable versions, due to the code limit I thought of in the last paragraph.


    The standard should already work without the database. Though the standard is just a formatted entry explaining what a creation does and how it is similar to other creations of the same function. A door with a button is the same function as a door with a lever, classified as the same function, but two distinct methods that open the door, thereby two different design entries upon the same class code.

    Quote from Simnik

    If I am to comment on the database, then you don't need to compress anything into codes, but you could make the software capable of sorting after different values, such as size on the different axises, tileability or delay. But someone have to do it, and as you said, you are only one man.


    The problem is the software may be able to sort out what was used, but not the function, similar to music... Computers can tell what notes were used to a point, but it's still just noise. It may not know if it can be tileable unless specified, it may know what the delay might be, but without an assisted (circuit simulator inheritance :tongue.gif:) it will not know jack.

    If you might be so bold to create a blinded perl/php circuit parser, simulator, and predictor you might as well have created a Mathimatica (Wolfram-Alpha) version of a real-time logic interpreter.

    Quote from Simnik

    I don't know how to incorporate bug-use or delay into this, but maybe that should be present in the database only.

    I have I slightly idea of that you haven't had that much experience with redstone since you joined October 13, and since incorporated the JK-Flip-Flop (which noone use), but only just one full adder. I would gladly help making this standard more fitting for what really happens around us with redstone.


    I do my best, though I'm a redstone puzzle builder, not a CPU builder. I have information theory (compression/encryption/entropy) embedded in my mind and that carries through into redstone. I see everything as a problem (functional one, not a bad one) and one that needs to be solved or simulated, and then exploited (in a good way.) Although this is not on the scale of Regular Hexahedron, dude, or any other who-who of redstoners, but on a basic playable sense. /gloat-response-flattery

    Although no one may use a JK latch or flop, they still exist in logic; sequential and conditional logic. And when playing with sequential logic, it can be used for cascading and random (simulated) generation. Hook up a few JK's with unique primed-length ticks, it will start to look a little random the more prime JK's you add. (At least from my understanding of JK-flop = tick-tock-flip-flop, and JK-latch = bloop-bloop-flip) Hook up Wolfram Rule 30 and let it run for a few days, no one could tell it was from a sequential rule-set.

    If a logic can be simulated in redstone, it will be included in the database and thereby have a standard formatted explanation and possible example.
  • #49
    I just wanted to say that I completely support this project, and though I don't think I'm learned enough to help populate the fields. I really look forward to being able to use it in the future?

    What would you say is the state of completion of this project? 25%? More? Less? Do you have a projected completion date?
  • #50
    Quote from whereswalden90

    I just wanted to say that I completely support this project, and though I don't think I'm learned enough to help populate the fields. I really look forward to being able to use it in the future?

    What would you say is the state of completion of this project? 25%? More? Less? Do you have a projected completion date?


    Projected complete date is when it's finished. I think I put more hours into this project than college study and classes combined. :tongue.gif:

    Compiling raw population data here for now. Yay putting my old day job to good use in a very sloppy quick way. Feel free to comment (this is my own Beta version layout, not Grygz's.) Hopefully you all might see what I'm aiming for.
  • #51
    You are the definition of awesomeness :biggrin.gif:
    Last edited by RiiBzxX: 12/6/2011 11:58:10 PM
    If I was helpful, click the ...
  • #52
    Never been a fan of overly graphical interfaces. But yes, it does look good. :smile.gif:
  • #53
    hi?
  • #54
    Quote from longtrenton1

    hi?


    Finals week?

    /random-lurk
  • #55
    In half an hour, I'll be doing an exam of networking. :biggrin.gif:
  • #56
    interesting.... :mellow.gif: :mellow.gif:
  • #57
    Slight update...

    Trying to compile all the feedback from both threads. All codes are basically node categories, the same D.A format, only that's what it will be going by. However, holiday season right after my finals are slowing me down. So much other things I have to do. I'm taking a nibble out of this project every day just to keep myself interested and motivated to get this done.
  • #58
    Quote from dracoix

    Chapter 8 - How to Submit a Schematic or Request Help (Beginner)

    SOONTM

    nice
  • #59
    I WARMLY WELCOME YOU TO REDSTONE BV redstone since 1879
    what the hell i am talking about!
    youre ''big red book of redstone'' helped me very much!
    Last edited by remlly: 12/30/2011 4:10:10 PM
    Well, I don't care if it's God's own anti-son-of-a-­ machine, or a giant hula hoop, we're not gonna let 'em have it!
    Sergeant Johnson
  • #60
    Another slight update:

    Break is almost over and I can finally stop going to family parties. But due to an issue with lets just say a site with "Go" and "Daddy" in it, I am doing some "moving" one might say. Business returns as normal on Tuesday. :smile.gif:
  • To post a comment, please or register a new account.
Posts Quoted:
Reply
Clear All Quotes