I apologize to the users of the Redstone Simulator who feel I've abandoned them, and my only excuse is to say that I have moved away from gaming for the most part in order to pursue my studies. I swear I never intended for the program to be "closed source"; I have just had bad experiences with open-sourcing software only to find that no one cares. I can't guarantee continued participation, but from the responses to my original post, I see that a genuine desire to improve on my work and expand the project. To that effect, I am releasing the source code, and would like to coordinate with anyone who is still interested to move development to a repository. (I've become quite fond of GitHub as of late.)
The source is available in raw form as a zipped version of the Eclipse project on my local machine. If/when this gets moved to a repo, the process should become a little cleaner.
(To moderators: I would like to have posted this as an edit of the original, but the thread is now locked. Can we get a link up from there to here?)
EDIT: Also, if anyone feels like filling me in on what's happened since last October (I think that was about when I left), I might be able to make some updates. A cursory glance has revealed that repeaters are new, and someone mentioned "recursion protection" to explain the long-known inaccuracy of certain arrangements of torches. I would like to state for the record that the reason I never fixed it is because I couldn't figure out how it worked, and I can't make any updates if I don't know how the game works.
What helps the most is a concise explanation of how a new element interacts with the other blocks in all the different arrangements and combinations. I'll see what I can do to incorporate all this, but I am no less busy now than I have been all year, and I can't even promise that I won't disappear again. But I'll track this post for a while if anyone has any pending feature requests.
I don't know what you mean by "recursion protection", but if I remember right from the last time I used your simulator, burnout was a feature not implemented in it. Assuming this is what you are referring to by "recursion protection", I'll explain how it works. I remember having to figure it out when I implemented a similar mechanic in my RedLightGreenLight mod.
The RSTorch class keeps a log of every time any torch in the world turns off and when it happened. Whenever a torch attempts an update, it clears the log of any entries older than 50 redstone ticks (100 world ticks). When a torch wants to turn on, it checks this log for all updates at its location; if there are 10 or more entries, it will not turn on. However, under "normal" circumstances, this means that a torch won't turn on again until its input line goes from on to off! To solve this problem, MC pulls 80 random coordinates per chunk (16x16 area of blocks) per world tick out of nowhere and updates any torches that happen to be at those coordinates. It does nothing with the coordinates that don't have torches at their location.
Hope this helps!
EDIT:: Also, you may want to check out the new Redstone subforum! It's where all redstone-related posts are now, including the threads for Simnik's and my simulators.
Oh, I forgot to mention how pistons are powered. They can be powered on the same level both directly and indirectly from any side except the side they face. However, they are also powered if the block above them is "powered", even if that block is air. This leads to some strange powering quirks where a setup like this:
(where is the piston and is a wire)
will power the piston when the wire is on. Even strange setups like the following will power a piston:
(where is a repeater)
(that last one I think should power it; I need to check and make sure)
I was aware of the burnout behavior, but I didn't implement it because I thought it was 'not important', in the sense that it shouldn't be a part of any "real" circuit, so it was not worth the annoyance of actually dealing with it (from the user's standpoint). Actually, I was referring to the case when certain torch updates would propagate through multiple torches in one redstone tick, which I believe is the cause of one-tick pulses being swallowed when they go through torches. (Do repeaters swallow one-tick pulses?) It was a very direction- or location-sensitive behavior, and I went crazy trying to deduce the logic behind it, so I gave up and called it a "known bug". (EDIT: I think this is now called the "N/S repeater")
Speaking of which, I get the feeling from the in-depth details of MC behavior that people have managed to de-obfuscate the client to a significant degree. Is there (a) a place where I can download a cleaned-up version of said source code (possibly illegal), (:cool.gif: a place where I can be told HOW to de-obfuscate the client's class files, or (c) a link to a good decompiler? I tried this route once, and I couldn't even get the loader sufficiently understandable to find where the real thing is, let alone clean enough to recompile from the decompiled source. (The decompiler would periodically get stuck, and so syntax errors like "JVM INSTR 1234" would be littered through the code, and I'd have to check the bytecode myself and try to figure out what it was trying to do. There were so many that I gave up after a while, and I never managed to get it to compile.
AnonymousJohn mentions that he's working on a kernel to simulate redstone, and the idea of separating the logic part from the GUI and maintenance activities intrigues me. I'd like to eventually get this implemented as a sort of "plugin" for MCRedstoneSim, but that's just an eventual goal at this point. I'll set up a GitHub repository to host this project soon.
EDIT: The GitHub repository is located at https://github.com/digama0/MCRedstoneSim (digama0 is my GitHub username), and I will try to update it on a semi-regular basis. If you have a GitHub account, PM me here or in GitHub and I will add you as a collaborator.
Speaking of which, I get the feeling from the in-depth details of MC behavior that people have managed to de-obfuscate the client to a significant degree.
A comical understatement.
You're looking for the Minecraft Coder Pack. It includes several batch files - the noteworthy ones might be decompile.bat, recompile.bat, and test_game.bat. It's powered by a collection of programs plus a couple of CSV files that map the obfuscated class/field/method names to the MCP crew's more descriptive names. MCP is used as a kind of SDK plus build system for making mods.
For a decompiler, I use JD-GUI and I think the only other one being used is JD's ancestor, JAD.
You're looking for the Minecraft Coder Pack. It includes several batch files - the noteworthy ones might be decompile.bat, recompile.bat, and test_game.bat. It's powered by a collection of programs plus a couple of CSV files that map the obfuscated class/field/method names to the MCP crew's more descriptive names. MCP is used as a kind of SDK plus build system for making mods.
For a decompiler, I use JD-GUI and I think the only other one being used is JD's ancestor, JAD.
HOLY **** THIS IS FANTASTIC. I wish I had this last year! So this is legal because the deobfuscated code is not being distributed, just the decompiler. But I thought that every time a new class was added, all of the autogenerated names (a.class, kj.class, etc) were switched around, so you'd have to fix everything after every patch? TBH, I'm surprised that this was allowed to become public - it's almost like MC is now open source. AND IT COMPILES. How? I'm blown away and offer my highest praises to the MCP team.
Maybe now I'll finally be able to fix those ancient "known bugs".
I was aware of the burnout behavior, but I didn't implement it because I thought it was 'not important', in the sense that it shouldn't be a part of any "real" circuit, so it was not worth the annoyance of actually dealing with it (from the user's standpoint). Actually, I was referring to the case when certain torch updates would propagate through multiple torches in one redstone tick, which I believe is the cause of one-tick pulses being swallowed when they go through torches. (Do repeaters swallow one-tick pulses?) It was a very direction- or location-sensitive behavior, and I went crazy trying to deduce the logic behind it, so I gave up and called it a "known bug". (EDIT: I think this is now called the "N/S repeater")
Ah, yes, the N/S quirk. From my examination of the source, this ought to be completely random, unpredictable, and not location/orientation dependant. On the other hand, if there was some way for an update on both torches to be scheduled for the same time (highly unlikely, but possible), it would be orientationally dependant whether they actually updated at the same time due to the order in which MC performs scheduled updates. I can't remember if it's consistent or not, though; if it is, the torches are both scheduling updates at the same time and we need to figure out why. If not, we already know why. Whoops! I forgot about the 2x2 orientation (like the diagram that follows). In that case, it makes perfect sense. Torches schedule an update for themselves whenever their "neighbors" change. Because the second torch appears above the block the redstone wire is attached to, it is in the area notified of changes to the wire. But so is the first torch. Therefore, both have updates schedule for the same time. Due to the order in which updates occur, depending on the orientation the torches may change during the same tick. Mystery solved.
As a side note, I remember a similar problem with repeaters attached to torches; both would update at the same time, but only with one particular delay on the repeater.
And no, repeaters do not swallow 1-tick pulses. They do have problems with 101-pulses, though. Sometimes it comes out 111 rather than 101.
To the contrary of your opinion, I feel that burnout is very important in the simulator; I would want to know if my circuit were burning out before I put it in the world.
About the north-south quirk and similar orienting or time-based quirks, then this thread is going very deep research on what's actually happening under the surface during a tick. It is a very tough read due to the very technically topic, but that is exactly what you are searching for. I haven't read the full text, need the last page or so, but I can summarize up what I got out of it. As a forewarning, then parts of this might be wrong.
Every time a change is made to a block, an update is scheduled two ticks later to any neighbor redstone torch (I don't know exactly what qualifies a block to be a neighbor), and a delay for repeaters that fits its options. A block can apparently only have one scheduled update at a given time. Each time a tick is run, the first 1000 blocks updates is run, postponing all other to the next tick (I presume it is per chunk). 80 random blocks per chunk is also updated. Now, each time a tick is run, the blocks are updated in the order they were added to the list, so the question is in which order the neighbors were notified by the block. This order is orient-depending ins some way. During the update of some redstone component, some neighbor blocks might have been notified and get an update scheduled, but if those blocks already have a scheduled update, then the new one will be discarded - also if its in the very same tick (I think). When a block updates, It does not looks at the state at the time of the schedule, but the current one. This can lead to special scenarios, like the N/S quirk.
The explanation of the N/S quirk is also in the thread:
Now, I don't know exactly how you are going to use this in the simulator. The only way I can see is copying the concept, hoping to the the correct bugs with, and keeping all other out. But I doubt it's worth it.
I was actually thinking I'd change the update system completely to match the way it's done in MC, in order to replicate these "features". I mean, the way I'm doing it now (update every block every time) is a little brain-dead simplistic, and it definitely doesn't scale well. It makes sense to keep track of updates and make sure you update only what you have to.
As a side note, I've been perusing the MC source (via the MCP) and I was wondering whether anyone can point me to the primary redstone logic classes. I'm sure I'll find it eventually, but there's a lot of code there, and this is my first crack at it.
Simnik, I'll read your summary of the thread tomorrow; I'm a little braindead right now after my 17-hour car ride home. Your explanation of the N/S quirk is spot on, though.
I was actually thinking I'd change the update system completely to match the way it's done in MC, in order to replicate these "features". I mean, the way I'm doing it now (update every block every time) is a little brain-dead simplistic, and it definitely doesn't scale well. It makes sense to keep track of updates and make sure you update only what you have to.
As a side note, I've been perusing the MC source (via the MCP) and I was wondering whether anyone can point me to the primary redstone logic classes. I'm sure I'll find it eventually, but there's a lot of code there, and this is my first crack at it.
Pretty much all the redstone logic is found in the BlockRedstone classes (there's three; one per component). The ticks happen via the Minecraft class's runTick method, but for what you need to look at, all the tick action happens in the World class's updateEntities (correct name?) and tick methods, I believe in that order. Good luck!
Rollback Post to RevisionRollBack
AJ's Thread O' Links! -- A thread of links to my projects, other supported projects, approved ideas, etc.
The source is available in raw form as a zipped version of the Eclipse project on my local machine. If/when this gets moved to a repo, the process should become a little cleaner.
MCRedstoneSim project folder, v2.2
(To moderators: I would like to have posted this as an edit of the original, but the thread is now locked. Can we get a link up from there to here?)
EDIT: Also, if anyone feels like filling me in on what's happened since last October (I think that was about when I left), I might be able to make some updates. A cursory glance has revealed that repeaters are new, and someone mentioned "recursion protection" to explain the long-known inaccuracy of certain arrangements of torches. I would like to state for the record that the reason I never fixed it is because I couldn't figure out how it worked, and I can't make any updates if I don't know how the game works.
What helps the most is a concise explanation of how a new element interacts with the other blocks in all the different arrangements and combinations. I'll see what I can do to incorporate all this, but I am no less busy now than I have been all year, and I can't even promise that I won't disappear again. But I'll track this post for a while if anyone has any pending feature requests.
The RSTorch class keeps a log of every time any torch in the world turns off and when it happened. Whenever a torch attempts an update, it clears the log of any entries older than 50 redstone ticks (100 world ticks). When a torch wants to turn on, it checks this log for all updates at its location; if there are 10 or more entries, it will not turn on. However, under "normal" circumstances, this means that a torch won't turn on again until its input line goes from on to off! To solve this problem, MC pulls 80 random coordinates per chunk (16x16 area of blocks) per world tick out of nowhere and updates any torches that happen to be at those coordinates. It does nothing with the coordinates that don't have torches at their location.
Hope this helps!
EDIT:: Also, you may want to check out the new Redstone subforum! It's where all redstone-related posts are now, including the threads for Simnik's and my simulators.
(where is the piston and is a wire)
will power the piston when the wire is on. Even strange setups like the following will power a piston:
(where is a repeater)
(that last one I think should power it; I need to check and make sure)
Speaking of which, I get the feeling from the in-depth details of MC behavior that people have managed to de-obfuscate the client to a significant degree. Is there (a) a place where I can download a cleaned-up version of said source code (possibly illegal), (:cool.gif: a place where I can be told HOW to de-obfuscate the client's class files, or (c) a link to a good decompiler? I tried this route once, and I couldn't even get the loader sufficiently understandable to find where the real thing is, let alone clean enough to recompile from the decompiled source. (The decompiler would periodically get stuck, and so syntax errors like "JVM INSTR 1234" would be littered through the code, and I'd have to check the bytecode myself and try to figure out what it was trying to do. There were so many that I gave up after a while, and I never managed to get it to compile.
AnonymousJohn mentions that he's working on a kernel to simulate redstone, and the idea of separating the logic part from the GUI and maintenance activities intrigues me. I'd like to eventually get this implemented as a sort of "plugin" for MCRedstoneSim, but that's just an eventual goal at this point. I'll set up a GitHub repository to host this project soon.
EDIT: The GitHub repository is located at https://github.com/digama0/MCRedstoneSim (digama0 is my GitHub username), and I will try to update it on a semi-regular basis. If you have a GitHub account, PM me here or in GitHub and I will add you as a collaborator.
A comical understatement.
You're looking for the Minecraft Coder Pack. It includes several batch files - the noteworthy ones might be decompile.bat, recompile.bat, and test_game.bat. It's powered by a collection of programs plus a couple of CSV files that map the obfuscated class/field/method names to the MCP crew's more descriptive names. MCP is used as a kind of SDK plus build system for making mods.
For a decompiler, I use JD-GUI and I think the only other one being used is JD's ancestor, JAD.
"We will absolutely not keep in mind what external mapeditors will have to do to read data from the disk, that makes no sense whatsoever." - Grum
HOLY **** THIS IS FANTASTIC. I wish I had this last year! So this is legal because the deobfuscated code is not being distributed, just the decompiler. But I thought that every time a new class was added, all of the autogenerated names (a.class, kj.class, etc) were switched around, so you'd have to fix everything after every patch? TBH, I'm surprised that this was allowed to become public - it's almost like MC is now open source. AND IT COMPILES. How? I'm blown away and offer my highest praises to the MCP team.
Maybe now I'll finally be able to fix those ancient "known bugs".
Ah, yes, the N/S quirk.
From my examination of the source, this ought to be completely random, unpredictable, and not location/orientation dependant. On the other hand, if there was some way for an update on both torches to be scheduled for the same time (highly unlikely, but possible), it would be orientationally dependant whether they actually updated at the same time due to the order in which MC performs scheduled updates. I can't remember if it's consistent or not, though; if it is, the torches are both scheduling updates at the same time and we need to figure out why. If not, we already know why.Whoops! I forgot about the 2x2 orientation (like the diagram that follows). In that case, it makes perfect sense. Torches schedule an update for themselves whenever their "neighbors" change. Because the second torch appears above the block the redstone wire is attached to, it is in the area notified of changes to the wire. But so is the first torch. Therefore, both have updates schedule for the same time. Due to the order in which updates occur, depending on the orientation the torches may change during the same tick. Mystery solved.As a side note, I remember a similar problem with repeaters attached to torches; both would update at the same time, but only with one particular delay on the repeater.
And no, repeaters do not swallow 1-tick pulses. They do have problems with 101-pulses, though. Sometimes it comes out 111 rather than 101.
To the contrary of your opinion, I feel that burnout is very important in the simulator; I would want to know if my circuit were burning out before I put it in the world.
I was actually thinking I'd change the update system completely to match the way it's done in MC, in order to replicate these "features". I mean, the way I'm doing it now (update every block every time) is a little brain-dead simplistic, and it definitely doesn't scale well. It makes sense to keep track of updates and make sure you update only what you have to.
As a side note, I've been perusing the MC source (via the MCP) and I was wondering whether anyone can point me to the primary redstone logic classes. I'm sure I'll find it eventually, but there's a lot of code there, and this is my first crack at it.
Pretty much all the redstone logic is found in the BlockRedstone classes (there's three; one per component). The ticks happen via the Minecraft class's runTick method, but for what you need to look at, all the tick action happens in the World class's updateEntities (correct name?) and tick methods, I believe in that order. Good luck!