Ohhhh that's clever! Just do it twice! Very clever, very clever indeed.
That looks like a fun redstone world. If I set up a little server for us to do redstone on it every now and then, would you be interested in collabs?
- Registered Member
Member for 10 years, 5 months, and 19 days
Last active Wed, Sep, 4 2013 10:00:33
- 0 Followers
- 567 Total Posts
- 26 Thanks
Jul 25, 2012m37Zz, that was my original idea funnily enough, of course the output is inverted (the right-most lever triggers the left-most output) and so you'd have to flip them all and that would be a LOT of redstone, but the other issue is that you need both ends connected to the machine.Posted in: Redstone Discussion and Mechanisms
Video coming in a few hours of my new design.
Jul 25, 2012Actually, I just managed to improve this HUGELY. I'm getting a video out tomorrow, but the size per segment of wire is 7x5x1, with 1 extra segment needed at the beginning. It's 3-tick delay to turn on, 1-tick delay to turn off, and it looks beautiful because all the outputs are on one side!Posted in: Redstone Discussion and Mechanisms
In other words, it's the pinnacle of redstone decay decoding. Video coming out tomorrow, pretty excited to show you, I even made it colorful this time.
Jul 25, 2012So split the wire into 2, and alternate between decoding each one? I suppose that would work, although the "t" junction of redstone would surely make you lose 1 more block of space between the decoder? Ideally, 5 inputs would require 5 bits of wire on the other end, and everything between would be empty space, so that if redstone wire travels 15 blocks and you want 4 values, you would have 15-4*2=7 spaces of pure wire between them. If I'm understanding your idea correctly, it would always take 1 extra bit of space?Posted in: Redstone Discussion and Mechanisms
Jul 24, 2012That's awesome! Well, how do you think we could improve it, then?Posted in: Redstone Discussion and Mechanisms
What I'm thinking is a smaller decoder... Maybe decode back to binary somehow? Take the 3 inputs, encode into a decimal 0-7, apply current at that position, then decode current back in to decimal, and again decode into binary...
Well the main part of that is the decoding the decay part, and the only way we could improve that would be to either make a smaller IMPLIES gate (xor gate would also work, but I can't find a 2 wide one), or to somehow move the gates to one side of the wire...
This'll be hard but I'm up for a challenge. Any early thoughts on getting either of these improvements?
Jul 24, 2012Yeah, that one is certainly cool but also very different- That one sends a bitstream down a wire (4 ticks per bit, it would seem). Mine, instead, sends 3 bits down a single wire instantly. The other difference is that with theirs, the input is a huge machine- On mine, the input is a single wire.Posted in: Redstone Discussion and Mechanisms
Interestingly, if they had used the 3 bits that decaying can give you, they could have tripled the speed of their device, by not only sending a pulse, but also starting the pulse closer/further to add another 3 bits to each signal. This is exactly what I find useful about my finding- It packs more data into a single line, which should be able to triple the speed of a minecraft computer.
Jul 23, 2012Hey, I decided to hook up 8 levers to 1 wire, and then decode the amount of decay to figure out which lever is switched on. I really would like to know if this has been done before- I'm a decent minecrafter just trying to get recognized a bit. Here's a video.Posted in: Redstone Discussion and Mechanisms
Jul 23, 2012time4dan posted a message on Strange behaviour in tiny circuit, need explanationAs I said, it felt like a BUD bug... However, I was not aware that a block actually updates even if it's air. Does that mean air block above the piston is triggering a block update to all adjacent blocks just because its redstone current value changed, even though it's an air block and that can't possibly actually affect anything? That's the part that confuses me- It's an air block, it can't send power, so why dispatch a block update when it's power level changes?Posted in: Redstone Discussion and Mechanisms
Jul 23, 2012time4dan posted a message on Strange behaviour in tiny circuit, need explanationIn the circuit below, the blue lever can turn on/off the piston.Posted in: Redstone Discussion and Mechanisms
However, when the pink lever is on, the blue lever can only turn the piston on, not off. The repeater will still turn on/off, but the piston will not turn back off.
I'm in snapshot 12w27a, and I honestly can't explain this. Any help? It feels like some sort of BUD bug...
Jul 22, 2012The 3D model would already have been sent to the GPU, hopefully, and so a chunk would essentially take zero cpu time, but can still be queried as a whole, in which case it would load its tiles into memory from the hard drive. It's reverse-caching, because minecraft is too heavy on the ram (especially the server).Posted in: Discussion
I do understand that HDD access is much slower than ram (although on computers with a decent ssd such as mine, the difference really drops), but seeing as almost all the chunks in a map are most often not being modified, it makes no sense to keep them all in ram.
Additionally, when I was making my minecraft clone, I actually found it faster to render the very-near chunks in real-time, because the amount of light/water/place/destroy actions taking place near a player made it faster to simply render in real-time than to keep re-writing and re-sending a model.
Finally, I always wondered why non-functioning chunks of a lower resolution couldn't be displayed outside of our current render level? Essentially, just past Normal distance would be chunks in which a block is the size of 2x2x2 normal blocks, meaning a chunk has 1/8 as many blocks. You wouldn't notice too much, but it would allow you to see absolutely huge distances with, again, little lag.
I think, right now, minecraft's horrible performance should be a mojang priority, especially with the server+client merge. The latest snapshots are really quite slow. It's too heavy on the CPU, and they need to balance it out more- Send some work to the hard drive, maybe use threads a little more intelligently, and when you're playing single-player, just have the LAN server that you're connected to in single player run on a separate thread but accessing the same region of ram..
I'm sure there's a lot of things that could be done, and I read that they will be working on the performance for 1.4, but they might lose some people if they release a game that half the userbase can't render on anything further than short.
Jul 22, 2012Just a thought from a programmer...Posted in: Discussion
When a block is changed in a chunk, that chunk should reset a timer to 2 minutes.. When the timer fires, that chunk should be saved directly to the hard drive and the ram should be de-allocated, but the actual model of the chunk should remain and still be drawn. When access, if it's not loaded, it should load it in from the hard drive into ram again.
Wouldn't this, essentially, cut the ram usage of minecraft down considerably with only a slight hit when you mine into an old chunk, while still allowing redstone and such to function perfectly fine?
Jul 22, 2012Oh so it was a pulse? Maybe hooked into a T flip-flop? Interesting.. I might be able to improve mine slightly now. Thanks!Posted in: Redstone Discussion and Mechanisms
Edit: I tried out your method, but because it's pulse-based, it ended up being much slower. You had to wait for the button and piston to both reset so it's just over a second (12 ticks, I think) before you can re-toggle it. However, with my technique, you can spam the level and it will always catch up within 2 ticks. However, I noticed your technique came without a clock which is a benefit.
- To post a comment, please login.