Bug report
I found a bug while building a flipflop..
I experimented a bit and found the problem area:
The Latch starts flashing like crasy.. That doesn't happen ingame.
That doesn't work as a toggle in game either.
Thats because its not a toggle :wink.gif: (check the wiki to find a working T Flip-Flop)
Its just a piece of circuit which acts different in the simulator..
Try building this in the game and in the simulator. The simulator starts acting different to the game.
The simulator should act just like the game...
Quote from Baezon »
That is a sure short-circuit.
I know its actually a short-circuit but doesn't race ingame.
NOOOOOO! Just when you think you have it figured out, something like this comes around. When you turn off the switch in this or related circuits, one torch will reliably turn on while the other doesn't. I suspect it has something to do with the order through which blocks are iterated. What you, Samonite, have discovered is a sub-tick race condition -- a race condition in the code of Minecraft itself. My previous thinking had me evaluating wire power states, then torches based on the wires, then wires based on the torches, etc. Now it would appear that the wires around each torch are modified immediately after each torch changes state, so that torches can pass information further down within a single tick. A simple example:
[] [] [] [] [] [] [] [] []
[]
:Iron:=switch
Construct this in any direction, then turn the switch on and off again. Depending on your choice of direction, the torch at the end will either flash a few times or not. If it doesn't (I'll call this the "downhill" configuration), that means that in the tick immediately following your turning off the switch:
[*:2gp48n5b]The first torch to be evaluated is the left one. Since the wire below it has just gone off, it turns on.
[*:2gp48n5b]The wire at (3,1) is activated by the torch.
[*:2gp48n5b]The second torch to be evaluated is to the right. Since the wire at (3,1) is on, it turns off.
[*:2gp48n5b]Repeat until you reach the last, which is turned on.
Note that the whole process takes place during 1 tick. If you have the torches going the opposite configuration ("uphill"):
[*:2gp48n5b]First tick:
[*:2gp48n5b]The first torch to be evaluated is the right one (from the original picture). Since the wire below it has just gone off, it turns on.
[*:2gp48n5b]The second torch to be evaluated is to the left. Since the wire below it has just gone off, it turns on.
[*:2gp48n5b]Repeat until you reach the last; all torches and interstitive wires are now on.
[*:2gp48n5b]Second tick:
[*:2gp48n5b]The first (rightmost) torch is unchanged.
[*:2gp48n5b]All other torches turn off because of the active wires behind them.
[*:2gp48n5b]Third tick:
[*:2gp48n5b]Leftmost three torches turn on.
[*:2gp48n5b]Fourth tick:
[*:2gp48n5b]Leftmost two torches turn off.
[*:2gp48n5b]Fifth tick:
[*:2gp48n5b]Leftmost torch turns on.
My sim does the second one regardless of direction. Currently doing tests to determine which directions are "downhill": bottom to top is confirmed; working on X and Z now. Then I will need to find which directions have priority.
This is, in fact, a great thing. What it allows is for a signal to pass a long distance (indefinitely?), even through torches, in a single tick, as long as each torch only affects "downhill" torches. Long story short: needs more study. See what you guys can figure out.
I'll bet you the directions for the current propagation go negative to positive, and in the order X, Z, Y.
I suspect as much (although I have yet to properly internalize the axes in my thinking), however, there is another aspect to deal with: chunk boundaries. In preliminary tests, I have not managed to get the "sub-tick propagation" to cross a chunk boundary, and in fact trying to perform the experiment detailed in my last post over a chunk boundary has caused situations where, say, the first, third, and fourth torches light up in the first tick (which indicates that two separate propagation waves 1-3 and 4-5 are being observed). It may be impossible to cross a chunk in less than a tick, which limits the possible usefulness of this behavior (with thought to superfast telegraphs or signal lines), but I will keep probing, as data continues to be inconsistent. It is too early to tell.
Huh. Are you saying the chunk boundaries affect how the currents run in-game? That's something to watch out for.
I think Notch did something in MC 1.0.1_13 that limits the propagation of light and currents, because he mentioned exponential frame time increases happening before that patch.
Huh. Are you saying the chunk boundaries affect how the currents run in-game? That's something to watch out for.
I think Notch did something in MC 1.0.1_13 that limits the propagation of light and currents, because he mentioned exponential frame time increases happening before that patch.
TBH, I'm not sure. Every test I've done has given me inconclusive results. Try that experiment yourself, with a large number of torches, and you'll see what I mean. Factors which may have a bearing on the result:
[*:21yir1en]The location of the switch
[*:21yir1en]The direction of the torches
[*:21yir1en]The location of chunk boundaries
[*:21yir1en]The length of the switch input wires
[*:21yir1en]Randomness?
Here's the latest result: From a string of 18 torches, covering 4 chunks, set up in the manner described above, the first tick looks like this:
1 0 | 1 0 1 1 1 | 1 1 0 1 0 (1) 0 1 1 1 1 |
The strings of "1 0 1 0" are the propagated currents, and "1 1" means that the propagation stopped. The vertical bars are chunk boundaries, and the parenthesized torch straddles a boundary. That exact sequence comes up every time I do the test, and also from different switches located at the ends and the center of the field. I want to emphasize that although results seem random, I always get the same result from a particular setup.
I may just decompile this damn program to figure out how this stuff works, since it's failing to behave common-sensically on every occasion. For now, people must get used to the fact that one-tick pulses and the simultaneous off setups on RS NOR latches which are the biggest causes of cascade failures in my program are almost never going to cause MC itself to do this. Two other (possibly related, and possibly related to the above) differences:
One-tick pulses are "eaten" by torches as if they never happened. I have no idea how this is done, and so no idea how to replicate.
In MCRedSim, it is almost trivial to set up cycles of even numbers of torches and get them to maintain a pulse in a manner similar to odd numbered clocks. For example, tie torch 1 to 2 to 3 to 4 to 1 again to make a "4-clock". Then, use the time control, along with switches or other torches, to set it up so that 1 and 2 are on and 3 and 4 are off in one instant of time. If you play time, this pattern will maintain itself and make a "2-clock" (since each torch is on for 2 ticks and off for 2). Besides the fact that this would burn out torches in the real thing, it is also impossible to construct in the first place, even if you are ninja-fast or hack the initial state. There is something going on that causes even large even-numbered clocks to lose these "irregularities" and end up in a stable state.
I suspect the same agent causes both these problems, and possibly the irregularities in the 18-torch experiment above. But what is it?
EDIT: Okay, I think someone else needs to tackle this. Although this is fascinating stuff, if I keep working on this, no one will see 2.0, and that would be a shame. Call me back when we have an idea of how this works and I'll implement it. This is stuff anyone can do.
Is there any chance you could increase the maximum number of tiers/levels?
I couldn't plan out my project in the sim because it only allowed 7(?) levels.
Tip of the day: An apparently hidden feature in MCRedSim is the "Adjust" button under the size indicator, short for "Adjust Size" from earlier versions. Press it, and a small window will pop up with twelve buttons. Use the buttons to expand or contract any face of the bounding cuboid. The "top" buttons will move the top up or down, the "left" button will move the left side left or right, etc. The "circle with a dot" icon (borrowed from physics) represents an arrow pointing at you, and the "circle plus" is an arrow pointing away from you. Additionally, pressing the "back > away" button will create entire levels of dirt, useful for designing "underground" circuits. If you contract the bounding cuboid over your design, the program will warn you that you are destroying components. Hold SHIFT to skip.
I've found that when MC recalculates blacked-out areas, it will stop partway through a chunk. Formerly, the edges of the darkness where MC stopped recalculating always lined up with the edges of chunks. Now, the edges are less predictable:
I've found that when MC recalculates blacked-out areas, it will stop partway through a chunk. Formerly, the edges of the darkness where MC stopped recalculating always lined up with the edges of chunks. Now, the edges are less predictable:
How do you clear lighting data? I have a custom program to set block data, but when I excavated a mountain, the inside was still in shadow. Unlike when I use your program (and it is black, but updates as soon as I place anything), it remains this way until I climb all the way up to where the phantom block was and place and remove a block there, and even then it only makes a "hole" in the shadow. Better yet, could we recalculate the lighting data ourselves? The formula looks simple enough.
The key point is after modifying terrain you have to update the height map. The height map is indexed [z,x] which is different from every other array. The height map's values are the y-coord of the lowest block in each column where the light from the sky is still at full strength. E.g. if water is at 63, the height map is 64. I use MCEdit to verify height map values in natural terrain.
The height map is used to make sky light calcs run faster, but I haven't figured out how. I've got some lighting code on an old branch that seemed to do the right thing often enough, I'll see if I can dig it up.
(I had the axes backwards on the height map for two weeks, then after finding out and swapping them, I rewrote that code using numpy and had them backwards again. )
Set all blocks at y=127 to have skylight=15.
Put the x,y,z coords of these blocks into an "active blocks" list.
Each tick:
-Each active block:
--Adjust that block's skylight downward by that block material's light absorption value
--Copy its skylight - 1 to each of the neighboring blocks.
--Copy its full skylight to the block below if that block can see the sky. (I used the heightmap here.)
--If any neighboring blocks had their light changed, add them to active blocks.
Stop when active blocks has zero length.
This is for full recalculation of a blackened area's skylight only.
I looked at Minecraft's code, too. It has an efficient, localized version for dealing with single-block changes. I haven't looked too closely at it, but it looks like it does both emit light from a cell and absorb light from neighboring cells in the same step.
it will not start for me, the jar is just opened by WinRar.
That is a problem I hope will be sorted out by having an executable release at some point, in the meantime, create a .bat file in the same directory in notepad with the following:
java -jar MCRedstoneSim.jar
and just save it as something like run.bat(make sure there is no .txt after it), and then run that
it will not start for me, the jar is just opened by WinRar.
Problem: You set the default association of your JARs to WinRAR (probably because you wanted to retexture something and opened minecraft.jar). This is sloppy and not recommended, as JARs are made to be executed, with opening of secondary priority.
Solution: If you have Java installed (and I expect you do, if you play Minecraft), right clicking and selecting "Open With > Java" should work under Win XP/Vista/7.
If this doesn't work, type Win+R to open the run dialog, type "cmd" at the prompt, then type "cd C:\path\to\folder", giving the folder which contains the MCRedstoneSim.jar file. Then type "java -jar MCRedstoneSim.jar" and it should run. Obviously this is complicated and difficult, and you should try to reassociate JARs to Java, but the exact method to do this depends on your OS.
[ninja'd] Atomizer's method is a version of the second given method, and may be simpler in the long run. I had not had any plans of making an executable launcher, as Java is more cross-platform (I'd have to make a version for every OS, including those I don't own). I'll bet some solution is available on the web for something like that, though. I'll see what I can do, but 2.0 takes priority for now.
Codewarrior: Thanks for that. Although if I use the schematic file format, I won't need to incorporate this into MCRedSim, I can still use it for my Mathematica level editor. One question though: the only thing missing is the "light absorption value" for all the blocks. Is this just 1 for things like dirt/stone/wood, and 0 for air, glass, and non-blocks (mushroom, ladder, torch)? And speaking of torches, they are not handled by this code.
it will not start for me, the jar is just opened by WinRar.
Problem: You set the default association of your JARs to WinRAR (probably because you wanted to retexture something and opened minecraft.jar). This is sloppy and not recommended, as JARs are made to be executed, with opening of secondary priority.
Solution: If you have Java installed (and I expect you do, if you play Minecraft), right clicking and selecting "Open With > Java" should work under Win XP/Vista/7.
If this doesn't work, type Win+R to open the run dialog, type "cmd" at the prompt, then type "cd C:\path\to\folder", giving the folder which contains the MCRedstoneSim.jar file. Then type "java -jar MCRedstoneSim.jar" and it should run. Obviously this is complicated and difficult, and you should try to reassociate JARs to Java, but the exact method to do this depends on your OS.
[ninja'd] Atomizer's method is a version of the second given method, and may be simpler in the long run. I had not had any plans of making an executable launcher, as Java is more cross-platform (I'd have to make a version for every OS, including those I don't own). I'll bet some solution is available on the web for something like that, though. I'll see what I can do, but 2.0 takes priority for now.
Ah, good point, I hadn't thought about that, because then youd need to make a dmg, exe and linux binary, complicating things further.
I also did not think about setting java as the default application, by default winrar assigns itself to be able to open jar files, and java doesnt as far as I know(could be wrong, but I had winrar before I installed java)
One question though: the only thing missing is the "light absorption value" for all the blocks. Is this just 1 for things like dirt/stone/wood, and 0 for air, glass, and non-blocks (mushroom, ladder, torch)? And speaking of torches, they are not handled by this code.
The value is 0 for air, glass, and the things you mentioned, 1 for leaves, 3 for water and ice, and 15 for solid blocks. Oddly, it's 255 for lava. The torch code is only different in the position of the light sources, and that light always falls off in all directions instead of continuing down at full strength.
Fun facts! Internally, Minecraft uses a floating point value for the amount of light a block type emits. This value is always some multiple of a sixteenth (Torches are 0.9375). Since it is multiplied by the maximum light value of 15, this seems to round down the intended light by one step.
One question though: the only thing missing is the "light absorption value" for all the blocks. Is this just 1 for things like dirt/stone/wood, and 0 for air, glass, and non-blocks (mushroom, ladder, torch)? And speaking of torches, they are not handled by this code.
The value is 0 for air, glass, and the things you mentioned, 1 for leaves, 3 for water and ice, and 15 for solid blocks. Oddly, it's 255 for lava. The torch code is only different in the position of the light sources, and that light always falls off in all directions instead of continuing down at full strength.
Fun facts! Internally, Minecraft uses a floating point value for the amount of light a block type emits. This value is always some multiple of a sixteenth (Torches are 0.9375). Since it is multiplied by the maximum light value of 15, this seems to round down the intended light by one step.
Are you saying that I could use a certain well-known local memory editing program to change the amount of light being emitted by a block?
...Do you have a list of these light values..?
..Someone should have stuff like this all listed in one spot. I think it'd be helpful to anyone else who decided to write a script to checkerboard the map with random light values or something.
Pretty please with diamonds on top?
Rollback Post to RevisionRollBack
Quote from VIROS »
No, all of you are wrong. He's going to implement flying invisible creepers that drop smaller invisible creepers on your base.
GENERATION 15: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social experiment.
Are you saying that I could use a certain well-known local memory editing program to change the amount of light being emitted by a block?
...Do you have a list of these light values..?
..Someone should have stuff like this all listed in one spot. I think it'd be helpful to anyone else who decided to write a script to checkerboard the map with random light values or something.
Pretty please with diamonds on top?
No, I'm saying that you could use an NBT editor to do it, which is a lot simpler. If you change BlockLight, you can get such a pattern, but it will be recalculated if you place any blocks. If you change HeightMap too, you can get it to stay. But why would you want to do that? You could also use blocks in the sky to do it, and save yourself the hacking.
NOOOOOO! Just when you think you have it figured out, something like this comes around. When you turn off the switch in this or related circuits, one torch will reliably turn on while the other doesn't. I suspect it has something to do with the order through which blocks are iterated. What you, Samonite, have discovered is a sub-tick race condition -- a race condition in the code of Minecraft itself. My previous thinking had me evaluating wire power states, then torches based on the wires, then wires based on the torches, etc. Now it would appear that the wires around each torch are modified immediately after each torch changes state, so that torches can pass information further down within a single tick. A simple example:
[] [] [] [] [] [] [] [] []
[]
:Iron:=switch
Construct this in any direction, then turn the switch on and off again. Depending on your choice of direction, the torch at the end will either flash a few times or not. If it doesn't (I'll call this the "downhill" configuration), that means that in the tick immediately following your turning off the switch:
[*:2gp48n5b]The first torch to be evaluated is the left one. Since the wire below it has just gone off, it turns on.
[*:2gp48n5b]The wire at (3,1) is activated by the torch.
[*:2gp48n5b]The second torch to be evaluated is to the right. Since the wire at (3,1) is on, it turns off.
[*:2gp48n5b]Repeat until you reach the last, which is turned on.
Note that the whole process takes place during 1 tick. If you have the torches going the opposite configuration ("uphill"):
[*:2gp48n5b]First tick:
[*:2gp48n5b]The first torch to be evaluated is the right one (from the original picture). Since the wire below it has just gone off, it turns on.
[*:2gp48n5b]Second tick:[*:2gp48n5b]The second torch to be evaluated is to the left. Since the wire below it has just gone off, it turns on.
[*:2gp48n5b]Repeat until you reach the last; all torches and interstitive wires are now on.
[*:2gp48n5b]The first (rightmost) torch is unchanged.
[*:2gp48n5b]Third tick:[*:2gp48n5b]All other torches turn off because of the active wires behind them.
[*:2gp48n5b]Leftmost three torches turn on.
[*:2gp48n5b]Fourth tick:[*:2gp48n5b]Leftmost two torches turn off.
[*:2gp48n5b]Fifth tick:[*:2gp48n5b]Leftmost torch turns on.
My sim does the second one regardless of direction. Currently doing tests to determine which directions are "downhill": bottom to top is confirmed; working on X and Z now. Then I will need to find which directions have priority.
This is, in fact, a great thing. What it allows is for a signal to pass a long distance (indefinitely?), even through torches, in a single tick, as long as each torch only affects "downhill" torches. Long story short: needs more study. See what you guys can figure out.
"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
I suspect as much (although I have yet to properly internalize the axes in my thinking), however, there is another aspect to deal with: chunk boundaries. In preliminary tests, I have not managed to get the "sub-tick propagation" to cross a chunk boundary, and in fact trying to perform the experiment detailed in my last post over a chunk boundary has caused situations where, say, the first, third, and fourth torches light up in the first tick (which indicates that two separate propagation waves 1-3 and 4-5 are being observed). It may be impossible to cross a chunk in less than a tick, which limits the possible usefulness of this behavior (with thought to superfast telegraphs or signal lines), but I will keep probing, as data continues to be inconsistent. It is too early to tell.
I think Notch did something in MC 1.0.1_13 that limits the propagation of light and currents, because he mentioned exponential frame time increases happening before that patch.
"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
TBH, I'm not sure. Every test I've done has given me inconclusive results. Try that experiment yourself, with a large number of torches, and you'll see what I mean. Factors which may have a bearing on the result:
[*:21yir1en]The location of the switch
Here's the latest result: From a string of 18 torches, covering 4 chunks, set up in the manner described above, the first tick looks like this:[*:21yir1en]The direction of the torches
[*:21yir1en]The location of chunk boundaries
[*:21yir1en]The length of the switch input wires
[*:21yir1en]Randomness?
1 0 | 1 0 1 1 1 | 1 1 0 1 0 (1) 0 1 1 1 1 |
The strings of "1 0 1 0" are the propagated currents, and "1 1" means that the propagation stopped. The vertical bars are chunk boundaries, and the parenthesized torch straddles a boundary. That exact sequence comes up every time I do the test, and also from different switches located at the ends and the center of the field. I want to emphasize that although results seem random, I always get the same result from a particular setup.
I may just decompile this damn program to figure out how this stuff works, since it's failing to behave common-sensically on every occasion. For now, people must get used to the fact that one-tick pulses and the simultaneous off setups on RS NOR latches which are the biggest causes of cascade failures in my program are almost never going to cause MC itself to do this. Two other (possibly related, and possibly related to the above) differences:
One-tick pulses are "eaten" by torches as if they never happened. I have no idea how this is done, and so no idea how to replicate.
In MCRedSim, it is almost trivial to set up cycles of even numbers of torches and get them to maintain a pulse in a manner similar to odd numbered clocks. For example, tie torch 1 to 2 to 3 to 4 to 1 again to make a "4-clock". Then, use the time control, along with switches or other torches, to set it up so that 1 and 2 are on and 3 and 4 are off in one instant of time. If you play time, this pattern will maintain itself and make a "2-clock" (since each torch is on for 2 ticks and off for 2). Besides the fact that this would burn out torches in the real thing, it is also impossible to construct in the first place, even if you are ninja-fast or hack the initial state. There is something going on that causes even large even-numbered clocks to lose these "irregularities" and end up in a stable state.
I suspect the same agent causes both these problems, and possibly the irregularities in the 18-torch experiment above. But what is it?
EDIT: Okay, I think someone else needs to tackle this. Although this is fascinating stuff, if I keep working on this, no one will see 2.0, and that would be a shame. Call me back when we have an idea of how this works and I'll implement it. This is stuff anyone can do.
All of the stuff I've mentioned is MC-exclusive. It's not in the sim because I didn't know it existed.
I couldn't plan out my project in the sim because it only allowed 7(?) levels.
Tip of the day: An apparently hidden feature in MCRedSim is the "Adjust" button under the size indicator, short for "Adjust Size" from earlier versions. Press it, and a small window will pop up with twelve buttons. Use the buttons to expand or contract any face of the bounding cuboid. The "top" buttons will move the top up or down, the "left" button will move the left side left or right, etc. The "circle with a dot" icon (borrowed from physics) represents an arrow pointing at you, and the "circle plus" is an arrow pointing away from you. Additionally, pressing the "back > away" button will create entire levels of dirt, useful for designing "underground" circuits. If you contract the bounding cuboid over your design, the program will warn you that you are destroying components. Hold SHIFT to skip.
"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
How do you clear lighting data? I have a custom program to set block data, but when I excavated a mountain, the inside was still in shadow. Unlike when I use your program (and it is black, but updates as soon as I place anything), it remains this way until I climb all the way up to where the phantom block was and place and remove a block there, and even then it only makes a "hole" in the shadow. Better yet, could we recalculate the lighting data ourselves? The formula looks simple enough.
The height map is used to make sky light calcs run faster, but I haven't figured out how. I've got some lighting code on an old branch that seemed to do the right thing often enough, I'll see if I can dig it up.
(I had the axes backwards on the height map for two weeks, then after finding out and swapping them, I rewrote that code using numpy and had them backwards again. )
"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
Okay, here's what I was doing:
Set all blocks at y=127 to have skylight=15.
Put the x,y,z coords of these blocks into an "active blocks" list.
Each tick:
-Each active block:
--Adjust that block's skylight downward by that block material's light absorption value
--Copy its skylight - 1 to each of the neighboring blocks.
--Copy its full skylight to the block below if that block can see the sky. (I used the heightmap here.)
--If any neighboring blocks had their light changed, add them to active blocks.
Stop when active blocks has zero length.
This is for full recalculation of a blackened area's skylight only.
I looked at Minecraft's code, too. It has an efficient, localized version for dealing with single-block changes. I haven't looked too closely at it, but it looks like it does both emit light from a cell and absorb light from neighboring cells in the same step.
"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
That is a problem I hope will be sorted out by having an executable release at some point, in the meantime, create a .bat file in the same directory in notepad with the following:
and just save it as something like run.bat(make sure there is no .txt after it), and then run that
Problem: You set the default association of your JARs to WinRAR (probably because you wanted to retexture something and opened minecraft.jar). This is sloppy and not recommended, as JARs are made to be executed, with opening of secondary priority.
Solution: If you have Java installed (and I expect you do, if you play Minecraft), right clicking and selecting "Open With > Java" should work under Win XP/Vista/7.
If this doesn't work, type Win+R to open the run dialog, type "cmd" at the prompt, then type "cd C:\path\to\folder", giving the folder which contains the MCRedstoneSim.jar file. Then type "java -jar MCRedstoneSim.jar" and it should run. Obviously this is complicated and difficult, and you should try to reassociate JARs to Java, but the exact method to do this depends on your OS.
[ninja'd] Atomizer's method is a version of the second given method, and may be simpler in the long run. I had not had any plans of making an executable launcher, as Java is more cross-platform (I'd have to make a version for every OS, including those I don't own). I'll bet some solution is available on the web for something like that, though. I'll see what I can do, but 2.0 takes priority for now.
Codewarrior: Thanks for that. Although if I use the schematic file format, I won't need to incorporate this into MCRedSim, I can still use it for my Mathematica level editor. One question though: the only thing missing is the "light absorption value" for all the blocks. Is this just 1 for things like dirt/stone/wood, and 0 for air, glass, and non-blocks (mushroom, ladder, torch)? And speaking of torches, they are not handled by this code.
Ah, good point, I hadn't thought about that, because then youd need to make a dmg, exe and linux binary, complicating things further.
I also did not think about setting java as the default application, by default winrar assigns itself to be able to open jar files, and java doesnt as far as I know(could be wrong, but I had winrar before I installed java)
The value is 0 for air, glass, and the things you mentioned, 1 for leaves, 3 for water and ice, and 15 for solid blocks. Oddly, it's 255 for lava. The torch code is only different in the position of the light sources, and that light always falls off in all directions instead of continuing down at full strength.
Fun facts! Internally, Minecraft uses a floating point value for the amount of light a block type emits. This value is always some multiple of a sixteenth (Torches are 0.9375). Since it is multiplied by the maximum light value of 15, this seems to round down the intended light by one step.
"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
Are you saying that I could use a certain well-known local memory editing program to change the amount of light being emitted by a block?
...Do you have a list of these light values..?
..Someone should have stuff like this all listed in one spot. I think it'd be helpful to anyone else who decided to write a script to checkerboard the map with random light values or something.
Pretty please with diamonds on top?
GENERATION 15: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social experiment.
No, I'm saying that you could use an NBT editor to do it, which is a lot simpler. If you change BlockLight, you can get such a pattern, but it will be recalculated if you place any blocks. If you change HeightMap too, you can get it to stay. But why would you want to do that? You could also use blocks in the sky to do it, and save yourself the hacking.