Thanks for the help! I was thinking about reducing the time the input is on by connecting a circuit that sends a pulse when the input changes from on to off:
I don't know if that's enough of a delay. I seem to require those three inverters in a row instead of just one, otherwise the output doesn't turn on. Anyways, your suggestion looks more elegant.
My design is exactly yours, but more compact and including an AND gate, which allows it to trigger on the off->on state change rather than the on->off change (since we expect results when we press the button).
Quote from Sven_The_Slayer »
Found a problem with the simulator. When you build double doors they do not act as they would in Minecraft. The double door is reversed so it's closed with power and open without. This requires that doors opening to the right (hinges on the right facing the door from the outside) will need an inverter. I'm not sure if this is a glitch in Minecraft or intended to be that way, just that The Simulator should mimic minecraft best it can.
Double doors have been a mess. First they were unimplemented, and people complained. Then I implemented them, and people (including me) complained that they were not true to Minecraft. Here's the thing: Doors don't flip. EVER. When you first place a door, it will appear to flip by being placed open if there is an adjacent door, but applying power will make it obvious that both doors open clockwise. In the next version, I will remove powered doors. (The inconsistent state of doors before redstone power is applied serves only to confuse, and will not be honored.)
Quote from Atomizer »
Actually, unless its been fixed(haven't tried recently): -snip-
Atomizer, your screenshots say "1.0.1_01". Redstone behavior has changed since then, so I can't trust the contents of your screenshots.
Quote from Atomizer »
Quote from Snateraar »
Uh, I'm using Windows 7(64 bits) and I can click buttons, change layers and dimensions, select parts, but can't place them. Any idea why?
Using the right mouse button? If you are, then no idea, im using the same OS as you and it works fine
I concur. I, in fact, work on a Windows 7 x64, and designed this very program on it. To reiterate:
[*:2gd9fy2y]Left click to activate buttons and switches, and delete other tiles.
[*:2gd9fy2y]Middle click to reorient buttons, switches, torches, and doors.
[*:2gd9fy2y]Right click to place tiles from the palette.
The control scheme was designed to be reminiscent of Minecraft's (although the ability to orient objects, which comes naturally in a 3D environment, had to be added with the middle click).
Also, I wish to ask the populous: I have successfully managed to translate both ways into and out of Alpha. The problem is that I don't know a good control scheme. What would the easiest method be to import an Alpha map into MCRedstoneSim, and how do you control where your schematic should be placed on your map? The simplest method would be to manually input coordinates, but that is not the most user-friendly manner. Ideas?
Integrating it with another editor might be best, unless you want to make one yourself.
It should be possible to save it in a format compatible with, say, MCedit.
I hope you don't decide to removed the doors, there isn't much else that redstone does right now.
Have you considered, (Once all the redstuff logic is complete), expanding this to be an all inclusive Blueprint creator? If it also had all the blocks available instead of just generic yellow tiles we might be able to map out entire structures and have it count all resources for us as well as being able to run the circuits. I'm not sure how much extra of a project that would end up being though.
Rollback Post to RevisionRollBack
Playing Minecraft since [Friday, March 19, 2010, 9:20:21 PM] (First indev world save)
I hope you don't decide to removed the doors, there isn't much else that redstone does right now.
Have you considered, (Once all the redstuff logic is complete), expanding this to be an all inclusive Blueprint creator? If it also had all the blocks available instead of just generic yellow tiles we might be able to map out entire structures and have it count all resources for us as well as being able to run the circuits. I'm not sure how much extra of a project that would end up being though.
To clarify, I'm not removing doors. I am removing the current behavior in which doors placed next to other doors open counter-clockwise, rather then clockwise. Keeping this behavior will only confuse and misinform people, as it is incorrect.
If I added more tile types, I would have to ditch double-layer viewing (which is a huge plus for me), and it wouldn't make redstone simulation any more accurate. If you want a 2D editor of Alpha levels, try NBTEdit. It has many more features to satisfy your tile-editing needs. If you just want tile counts, that might work as a separate program, but it sounds pretty limited. (I currently am doing my level editing in Mathematica, J/Linked to Tag.java from the wiki. It allows me the flexibility to design any shape or edit I want, while avoiding MCEdit, which (for me) slows to a 1fps crawl a minute after loading, which isn't long enough to fiddle with the depth controls, etc. just to clone a region. I can share my .nb files, but I doubt anyone else has Mathematica anyway. If you want stats on a level or a portion of a level, send me it and I can calculate whatever you want.)
Quote from Peewee223 »
Integrating it with another editor might be best, unless you want to make one yourself.
It should be possible to save it in a format compatible with, say, MCedit.
Does it count as "integration" if I tell you to go to NBTForge, get the coords, then plop them into MCRedstoneSim? I'm certainly not going to re-re-invent the 3D wheel.
Does it count as "integration" if I tell you to go to NBTForge, get the coords, then plop them into MCRedstoneSim? I'm certainly not going to re-re-invent the 3D wheel.
How would you like to export as a schematic?
The arrays are indexed [y,z,x]. The Data array holds the blockdata in the low four bits of each byte.
Does it count as "integration" if I tell you to go to NBTForge, get the coords, then plop them into MCRedstoneSim? I'm certainly not going to re-re-invent the 3D wheel.
How would you like to export as a schematic?
The arrays are indexed [y,z,x]. The Data array holds the blockdata in the low four bits of each byte.
I'll do you one better: I'll adopt the .schematic file type as the native save/load file format! (The .rdat format is as simple as they come, and I only invented it so that designs could persist. I will keep it for loads for backwards compatibility, though.) I assume that it is just like a chunk file, except with more manageable size? If this is your "pencil" export format, then I guess that will solve all my problems! However, there are many behind-the-scenes architectural changes I will have to make, due to shoddy research when I started:
[*:yh00awym]Z is up, not Y (actually, which way is "north"? +X or +Z or other? Keep in mind that I am using this picture for orientation reference.)
[*:yh00awym]level data is a byte[][][], rather than byte[]
[*:yh00awym]block data is custom mapped to the 8 block types in use
[*:yh00awym]extra data is done differently for each block
I'm sure there are more, but some problems only show themselves after you've punched a hole in the wall with your head. Wish me luck, and prepare for version 2.0, which will have save/load .schematic (which amounts to import/export to Alpha if you include MCEdit), Export as .gif, and TWO TYPES OF GROUND SWITCHES! That's right, whether you want the kind which powers its block or the kind which doesn't, you can have it either way! (Will need to modify the ground switch design to indicate.)
There is one incompatibility, though: Minecraft doesn't seem to indicate when blocks are wire-powered or torch-powered, so I may have to add data there. If I put data in the high 4 bit of the data array, will MCEdit safely ignore it?
Oh right, I forgot to clarify. These all hold true for any minecraft level format and the minecraft renderer itself:
In game, Y is altitude. The sun rises in the -Z and sets in the +Z. Clouds travel -X.
X is Width, Z is Length, Y is Height. Here's your easy formula for indexing the flat Blocks and Data arrays:
def getBlocks(x,y,z):
return blocks[x + z*Width+ y * Length* Width];
And I just double-checked... I'm using the high-order bits of the byte to store the block data. I guess it's because Minecraft uses the high-order bits for the lower of the two blocks. I'm not using the low-order bits so keep whatever you want in there. You could probably keep whatever you want anywhere in the NBT tag structure as well.
(actually, it's because the schematics are based on Indev files. the high-order bits of the BlockData array in those files correspond to the block data, while the low-order bits hold the lighting. this also explains why the block order is different from alpha)
I'm curious why you need to add data that doesn't get put into the Minecraft level, though. What difference does it make?
If possible, I will avoid it, but the current operation of my program holds completely different data from Minecraft, since it was designed without really probing how it's done in MC. Here's the pseudocode for the "update" function (this recalculates wire activation states, and is called every time anything is modified. It does not modify torches; that is the job of the "tick" function.)
For each tile:
---if it is a wire, set power to 0.
---if it is a block:
------if an active torch is underneath it, or an active switch or button is attached to it:
---------mark it as torch-powered (this will be in the low-order bits)
For each tile:
---if it is an active button, switch, torch, or torch-powered block:
------Follow each wire surrounding this tile, marking them with power starting at 15 and decaying to 0.
For each tile:
---if it is a non-torch-powered block:
------if a powered wire is touching this block, mark it as wire-powered (this will be in the low-order bits)
For each tile:
---if it is a door:
------if any blocks around the door are powered, open this door; otherwise, close it.
The tick function just turns off the torches if the block they are attached to is powered.
If you can find a way to do this with fewer than 4 global loops (which is really bad, IMO), or without storing "powered" data for blocks, please let me know.
I'd like to offer advice on that, but I admit I don't understand redstone enough to say.
I'll just offer this thought-problem:
I'll import your circuit schematic into my world using MCEdit, then select the circuit and export it to another schematic. Identical to the first one, except it lost your special data because it went in and out of a Minecraft level.
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.
Responded at logic gate thread. Seeing your circuit doesn't change my response. That is a sure short-circuit.
Quote from codewarrior »
I'd like to offer advice on that, but I admit I don't understand redstone enough to say.
I'll just offer this thought-problem:
I'll import your circuit schematic into my world using MCEdit, then select the circuit and export it to another schematic. Identical to the first one, except it lost your special data because it went in and out of a Minecraft level.
What now?
Not a problem. The information is stored during the update function, and used later in the update function, and in the tick function, so usually all data is written before being read. I can see a potential problem if someone loads, then immediately ticks (as doing just about anything will cause the update function to be called), but that can be solved easily enough. If I post the source, would anyone be interested enough to help?
Actually, unless its been fixed(haven't tried recently):
Double doors was the first thing I made when redstone came out.
Nope still reversed.
Playing Minecraft since [Friday, March 19, 2010, 9:20:21 PM] (First indev world save)
Using the right mouse button? If you are, then no idea, im using the same OS as you and it works fine
My design is exactly yours, but more compact and including an AND gate, which allows it to trigger on the off->on state change rather than the on->off change (since we expect results when we press the button).
Double doors have been a mess. First they were unimplemented, and people complained. Then I implemented them, and people (including me) complained that they were not true to Minecraft. Here's the thing: Doors don't flip. EVER. When you first place a door, it will appear to flip by being placed open if there is an adjacent door, but applying power will make it obvious that both doors open clockwise. In the next version, I will remove powered doors. (The inconsistent state of doors before redstone power is applied serves only to confuse, and will not be honored.)
Atomizer, your screenshots say "1.0.1_01". Redstone behavior has changed since then, so I can't trust the contents of your screenshots.
I concur. I, in fact, work on a Windows 7 x64, and designed this very program on it. To reiterate:
[*:2gd9fy2y]Left click to activate buttons and switches, and delete other tiles.
[*:2gd9fy2y]Middle click to reorient buttons, switches, torches, and doors.
[*:2gd9fy2y]Right click to place tiles from the palette.
The control scheme was designed to be reminiscent of Minecraft's (although the ability to orient objects, which comes naturally in a 3D environment, had to be added with the middle click).
It should be possible to save it in a format compatible with, say, MCedit.
This is not a spammy link, but rather a handy guide
DISCLAIMER: any diagrams I post should be taken with a grain of salt.
Have you considered, (Once all the redstuff logic is complete), expanding this to be an all inclusive Blueprint creator? If it also had all the blocks available instead of just generic yellow tiles we might be able to map out entire structures and have it count all resources for us as well as being able to run the circuits. I'm not sure how much extra of a project that would end up being though.
Playing Minecraft since [Friday, March 19, 2010, 9:20:21 PM] (First indev world save)
To clarify, I'm not removing doors. I am removing the current behavior in which doors placed next to other doors open counter-clockwise, rather then clockwise. Keeping this behavior will only confuse and misinform people, as it is incorrect.
If I added more tile types, I would have to ditch double-layer viewing (which is a huge plus for me), and it wouldn't make redstone simulation any more accurate. If you want a 2D editor of Alpha levels, try NBTEdit. It has many more features to satisfy your tile-editing needs. If you just want tile counts, that might work as a separate program, but it sounds pretty limited. (I currently am doing my level editing in Mathematica, J/Linked to Tag.java from the wiki. It allows me the flexibility to design any shape or edit I want, while avoiding MCEdit, which (for me) slows to a 1fps crawl a minute after loading, which isn't long enough to fiddle with the depth controls, etc. just to clone a region. I can share my .nb files, but I doubt anyone else has Mathematica anyway. If you want stats on a level or a portion of a level, send me it and I can calculate whatever you want.)
Does it count as "integration" if I tell you to go to NBTForge, get the coords, then plop them into MCRedstoneSim? I'm certainly not going to re-re-invent the 3D wheel.
How would you like to export as a schematic?
The arrays are indexed [y,z,x]. The Data array holds the blockdata in the low four bits of each byte.
"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'll do you one better: I'll adopt the .schematic file type as the native save/load file format! (The .rdat format is as simple as they come, and I only invented it so that designs could persist. I will keep it for loads for backwards compatibility, though.) I assume that it is just like a chunk file, except with more manageable size? If this is your "pencil" export format, then I guess that will solve all my problems! However, there are many behind-the-scenes architectural changes I will have to make, due to shoddy research when I started:
[*:yh00awym]Z is up, not Y (actually, which way is "north"? +X or +Z or other? Keep in mind that I am using this picture for orientation reference.)
[*:yh00awym]level data is a byte[][][], rather than byte[]
[*:yh00awym]block data is custom mapped to the 8 block types in use
[*:yh00awym]extra data is done differently for each block
I'm sure there are more, but some problems only show themselves after you've punched a hole in the wall with your head. Wish me luck, and prepare for version 2.0, which will have save/load .schematic (which amounts to import/export to Alpha if you include MCEdit), Export as .gif, and TWO TYPES OF GROUND SWITCHES! That's right, whether you want the kind which powers its block or the kind which doesn't, you can have it either way! (Will need to modify the ground switch design to indicate.)
There is one incompatibility, though: Minecraft doesn't seem to indicate when blocks are wire-powered or torch-powered, so I may have to add data there. If I put data in the high 4 bit of the data array, will MCEdit safely ignore it?
In game, Y is altitude. The sun rises in the -Z and sets in the +Z. Clouds travel -X.
X is Width, Z is Length, Y is Height. Here's your easy formula for indexing the flat Blocks and Data arrays:
And I just double-checked... I'm using the high-order bits of the byte to store the block data. I guess it's because Minecraft uses the high-order bits for the lower of the two blocks. I'm not using the low-order bits so keep whatever you want in there. You could probably keep whatever you want anywhere in the NBT tag structure as well.
(actually, it's because the schematics are based on Indev files. the high-order bits of the BlockData array in those files correspond to the block data, while the low-order bits hold the lighting. this also explains why the block order is different from alpha)
"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
"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
Kudos to you, good sir! :biggrin.gif:
If possible, I will avoid it, but the current operation of my program holds completely different data from Minecraft, since it was designed without really probing how it's done in MC. Here's the pseudocode for the "update" function (this recalculates wire activation states, and is called every time anything is modified. It does not modify torches; that is the job of the "tick" function.)
For each tile:
---if it is a wire, set power to 0.
---if it is a block:
------if an active torch is underneath it, or an active switch or button is attached to it:
---------mark it as torch-powered (this will be in the low-order bits)
For each tile:
---if it is an active button, switch, torch, or torch-powered block:
------Follow each wire surrounding this tile, marking them with power starting at 15 and decaying to 0.
For each tile:
---if it is a non-torch-powered block:
------if a powered wire is touching this block, mark it as wire-powered (this will be in the low-order bits)
For each tile:
---if it is a door:
------if any blocks around the door are powered, open this door; otherwise, close it.
The tick function just turns off the torches if the block they are attached to is powered.
If you can find a way to do this with fewer than 4 global loops (which is really bad, IMO), or without storing "powered" data for blocks, please let me know.
I'll just offer this thought-problem:
I'll import your circuit schematic into my world using MCEdit, then select the circuit and export it to another schematic. Identical to the first one, except it lost your special data because it went in and out of a Minecraft level.
What now?
"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 doesn't work as a toggle in game either.
Playing Minecraft since [Friday, March 19, 2010, 9:20:21 PM] (First indev world save)
Responded at logic gate thread. Seeing your circuit doesn't change my response. That is a sure short-circuit.
Not a problem. The information is stored during the update function, and used later in the update function, and in the tick function, so usually all data is written before being read. I can see a potential problem if someone loads, then immediately ticks (as doing just about anything will cause the update function to be called), but that can be solved easily enough. If I post the source, would anyone be interested enough to help?
I'd help if I could, but...
"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