I didn't know about the PC limits, but this behavior does not surprise me. I can leave my 8-bit counter running, then go anywhere, even through a portal into the nether, then come back, and see that the thing has never stopped working. Yet that same counter will jam up if I were to leave it running, save the game, then load it back up. I need to remember to switch it off before saving, else I have to go break up some redstone and lay it back down to refire it.
The same goes for my roller coaster, which I have set up to work properly without a passenger. It also triggers some pistons to push a little "HI" out of the sand every odd lap. On even laps, it brings the sand back down flush, and the lil' greeting disappears. (Detector rail and flip flop at work here.) Again, I can leave this running and go anywhere on my map and the nether, and when I return,. the cart is still merrily doing its rounds, with HI" popping up and down.
This may be one of the reasons the world size is fixed. The way it was implemented, its vital data need to be in memory all at once? It would seem so.
OP claims that redstone signals can travel around the whole xbox map without limits, this means you can build very big computers or track switching systems for example. This is limited in the PC version to some chunks around you (numbers are quoted before) .. and i would expect something similar on the xbox with its general map limit and the chunk loading stuff..
Can anyone already confirm what the OP claimed? Because this...
does not work .. at least for me ... it was the first thing i wanted to build, a blinking sign for me skyscraper.
But whenever i wander a bit farther away from it the blinking circuit just stops working.
I even have a bigger problem here, when i get closer to it, one repeater usually "hangs" so i can't restart my circuit properly.
(Hanging repeater means it outputs a signal although it has nothing on its input, similar to this after reloading the map at 0:30
)
So what am i doing wrong? Maybe the redstone cricuit is loaded as long as it is connected to a running chunk? So a long blinking line to you would work, but a blinker far away without connection to you would stop?? Need to go on testing later..
I'd be already happy to solve my hanging problem so the blinker would restart automatically when i get in range again :/, at the moment i have to destroy one part of my cricuit and rebuild it , anyone has an idea about that?
Edit: Ah i think my one problem is this http://www.minecraft...r_Reboot_System .. but still wondering why my blinker stops working not only after save/reload but when i walk away some 100 blocks.
Hmmm, well since the beginning of Minecraft history, whenever you load the game, clocks, or any kind of looping circuits, will be stuck. Because of your other problem I was starting to think maybe it just kept chunks loaded that had circuits connecting to a chunk near the player. But, according to this member...
I didn't know about the PC limits, but this behavior does not surprise me. I can leave my 8-bit counter running, then go anywhere, even through a portal into the nether, then come back, and see that the thing has never stopped working.
...that seems to not be the case. Are you sure your clock is slow enough to be stable? A 3-clock or faster will always burn out eventually, even if you stand right beside it. Also, when you have the space for it, use a few torches in your clock, make sure it's an odd number. More torches = more stability and gives it a better chance of restarting itself when you load the game or it does burn out. In addition to the methods listed on the Wiki, you can also use a rapid pulser and some pistons to force updates near a clock and get it running again. A pulser, from what I've seen, will always restart itself.
Yet that same counter will jam up if I were to leave it running, save the game, then load it back up. I need to remember to switch it off before saving, else I have to go break up some redstone and lay it back down to refire it.
Refer to the post above, by McGizmo, and my reply to it, we listed some effective methods of restarting automated circuits. No matter what, from now until the end of time, when you load the save, any circuit that was in the middle of moving power at the time of saving, will stick. You can't expect the chunks to be loaded even when you're not playing the game.
I'm glad you're not having trouble with the distance factor though, it seems one person may be. (I'm thinking the issue is just an unstable clock.) I would like to see more people testing my theory, just for variety. In the case of any experiment, there is no such thing as too many results. I will also start doing additional tests, maybe setting a clock up with no rebooting mechanism. I can see if it works without the line, sort of recreating McGizmo's problem.
Refer to the post above, by McGizmo, and my reply to it, we listed some effective methods of restarting automated circuits. No matter what, from now until the end of time, when you load the save, any circuit that was in the middle of moving power at the time of saving, will stick. You can't expect the chunks to be loaded even when you're not playing the game.
. . .
Right. But my point is that if the data were being unloaded for distant chunks by the game, then reloaded when you went back to them, wouldn't clocked circuits left running exhibit the same anomalies they suffer when you save and load your game? The game continues to process these circuits regardless of how far away you go, and even through a portal to the other realm. That falls in line with your discoveries.
Right. But my point is that if the data were being unloaded for distant chunks by the game, then reloaded when you went back to them, wouldn't clocked circuits left running exhibit the same anomalies they suffer when you save and load your game? The game continues to process these circuits regardless of how far away you go, and even through a portal to the other realm. That falls in line with your discoveries.
Ohhh, I see, you weren't just complaining about it failing. You were confirming my theory with its failure. You still could use a method to reboot it though, or perhaps use a torch in the clock, and power it when you want the clock to be off. Then if it froze, I would think flicking it off and on again would un-stick any frozen pistons. You probably have found a solution already, I'm just trying to be helpful.
Yes! Your theory is consistent with my observations. As for solutions, all my clocks have off switches, and I generally leave my circuits off unless I'm actively using or observing them.
One new problem I'm experiencing is detector rails occasionally getting stuck in the high state. The solution is to mine them and replace them, but it's still annoying, particularly on my 2-pulse clock made up of a track loop, 2 detector rails, and of course a mine cart. It keeps the pistons that move a cycling roll of blocks in proper lockstep, until one rail decides to glitch out. It's really disappointing, because up to now, I thought that rails were very reliable. The pistons themselves may look glitchy, but they do their job properly.
Yes! Your theory is consistent with my observations. As for solutions, all my clocks have off switches, and I generally leave my circuits off unless I'm actively using or observing them.
One new problem I'm experiencing is detector rails occasionally getting stuck in the high state. The solution is to mine them and replace them, but it's still annoying, particularly on my 2-pulse clock made up of a track loop, 2 detector rails, and of course a mine cart. It keeps the pistons that move a cycling roll of blocks in proper lockstep, until one rail decides to glitch out. It's really disappointing, because up to now, I thought that rails were very reliable. The pistons themselves may look glitchy, but they do their job properly.
Hmmm, I've seen power/detector rails used in circuits, (usually clocks) but have never actually used them myself. Will block updates fix this as well? Try placing a block beside the track, if the rail is still on, try removing or placing a block beside the block the rail is on. I'm guessing rails can become corrupted just as easily as blocks or redstone, and it sounds like that is what's happening here.
I've noticed the visual bugs too. Not just with pistons, even with redstone dust. A 1-clock looks like it is having some sort of seizure, yet when it is hooked up to a note block you can hear that it is working properly.
Been a while, but the post grabbed my attention.
I did a Redstone distance experiment sometime before pistons first came out to determine signal distance.(I'm not digging through the forums to find where I posted this)
At roughly 300 blocks or more I could see or follow my signal from a torch clock.
At the time, I was just trying to determine a simple way to determine distance before digging a rather complicated long tunnel.
This did not seem to grab anyone's attention then. Not sure why it does now. Is it the activation? The fact that chunks are active while not loaded? Or did I miss something in the post?
Further.
Why do other folks on pc have massive contraptions that operate without the redstone hassle we do On xbox? Because they are generally playing on servers that do not shut down. And there is no auto save.
Anytime you exit and save while redstone is in cycle, the box tries to save the info(state on on/off). But since it is in cycle, power may not correctly save in real time. When you reload, power is resent from your cycle source, and some areas may already have power. This results in repeaters or redstone being stuck in a "on" state or causes burnouts which can lead to the "persistent burnout" that plagues torches.
If you play with auto save, the info is saved as above, but if your not in the active chunk area, the same result occurs.
As Cobra has stated, (and I've posted this over and over) "make on/off" switches. Power down your contraptions before exiting and saving. And if a clock is not in use, turn it off. Use piston clocks to power pistons. Use torch clocks to power anything else.
Rollback Post to RevisionRollBack
Seatbelts are not as confining as Wheelchairs. Buckle up.
Hmmm, I've seen power/detector rails used in circuits, (usually clocks) but have never actually used them myself. Will block updates fix this as well? Try placing a block beside the track, if the rail is still on, try removing or placing a block beside the block the rail is on. I'm guessing rails can become corrupted just as easily as blocks or redstone, and it sounds like that is what's happening here.
I've noticed the visual bugs too. Not just with pistons, even with redstone dust. A 1-clock looks like it is having some sort of seizure, yet when it is hooked up to a note block you can hear that it is working properly.
Yes, I've had a similar experience with my marquee circuit wired to some note blocks. The visual progression across the repeaters is uneven, yet the notes play with perfect regularity.
I'm thinking the same thing about detector rails, that they can get "stuck" or "burned out" like redstone. It's a shame, and takes some wind out of my sails. I hope they can fix the issues with circuitry soon.
Update: I've succeeded at doing the 2 pulse clock with redstone now. The problem is getting quick pulses out of a slow clock, not the 2 separate pulses in lockstep, which are easy to do by inverting one lead from the clock output. I went back to the brilliant and there was the solution staring me in the face (1:50 to 1:56). Two blocks separated by a repeater with 3 ticks of delay, and a redstone torch on the side with some dust going back to the front. This does the magic, though I confess I'm not quite sure what's going on. (My guess is that the delay allows the side output to get through for its duration, and then shuts it off.) The output is quick and reliable. Works like a charm now, without the dodgy minecart fallback.
My roll is only 3 bits wide, but it works exactly as in the video, including how the data passes or is blocked. It's 10 blocks of cycling data per bit (opaque for 1, glass for 0). I'm not doing anything with the data yet, and like I said it's only 3 bits. I'm just elated that this is working so well now.
Been a while, but the post grabbed my attention.
I did a Redstone distance experiment sometime before pistons first came out to determine signal distance.(I'm not digging through the forums to find where I posted this)
At roughly 300 blocks or more I could see or follow my signal from a torch clock.
At the time, I was just trying to determine a simple way to determine distance before digging a rather complicated long tunnel.
This did not seem to grab anyone's attention then. Not sure why it does now. Is it the activation? The fact that chunks are active while not loaded? Or did I miss something in the post?
Further.
Why do other folks on pc have massive contraptions that operate without the redstone hassle we do On xbox? Because they are generally playing on servers that do not shut down. And there is no auto save.
Anytime you exit and save while redstone is in cycle, the box tries to save the info(state on on/off). But since it is in cycle, power may not correctly save in real time. When you reload, power is resent from your cycle source, and some areas may already have power. This results in repeaters or redstone being stuck in a "on" state or causes burnouts which can lead to the "persistent burnout" that plagues torches.
If you play with auto save, the info is saved as above, but if your not in the active chunk area, the same result occurs.
As Cobra has stated, (and I've posted this over and over) "make on/off" switches. Power down your contraptions before exiting and saving. And if a clock is not in use, turn it off. Use piston clocks to power pistons. Use torch clocks to power anything else.
Well, I believe one factor of our experiments made the difference. Your experiment to test the distance needed for whatever you were building. Mine was to find the absolute limit, and made the discovery of all chunks remaining active at the same time. Who knows, maybe the story did help a bit. I like to add a little element of storytelling to a thread whenever I can, especially when it's a long one. Makes it just a tad more fun to read.
I see what you're saying, though people often do have these redstone bugs on PC. Just not as much, thanks to servers. Either way, we all have to deal with the bugs at some point, since different states of a redstone item, according to the data, are a completely different block. I just don't understand why there is nothing to make it revert back to the way it should be, besides a block update.
Directly in that session or just after next loading? If you could confirm the first that would stop my confusion and i don't need to time an autosave test %)
And what do you mean with active chunk area, because all this suggests that all chunks are active the whole time?
I suppose it's possible an autosave could make things stick. Perhaps after an autosave, the game reloads all chunks around you? That would provide an explanation for a clock still working if you autosave beside it, but having errors if you autosave at a good distance from it.
About 1604 using both sides of the line, not counting repeaters. And it wouldn't quite be at once, it would be 30 at a time with a tenth of a second in between explosions... and that would happen 57 times.
That actually sounds pretty epic. Somebody with a capture card should try it.
It would BE cool, but it wouldn't render. At all. LOL
I tried to capture a friend blowing up a house he was bored with. He only used about 35 TNT, and it lagged so badly as soon as the first 6 exploded, that it just looked like the house disappeared after sitting motionless for 10-12 seconds.
Whoa nice find Nose_Job. Kudos for your dedication to laying all that redstone lol. I was curious about this as well, I had some ideas about making a lock that would only open if you found all the switches in the world (adventure type map) but wondered if I could place a switch on the opposite end of the world and have it still work. You have given me a reason to bother to wire all that up. Thanks, I'm sure my friends and family will thank you when they call and ask why I haven't left my house in a week and my boss calls and wonders why I'm not at work
Whoa nice find Nose_Job. Kudos for your dedication to laying all that redstone lol. I was curious about this as well, I had some ideas about making a lock that would only open if you found all the switches in the world (adventure type map) but wondered if I could place a switch on the opposite end of the world and have it still work. You have given me a reason to bother to wire all that up. Thanks, I'm sure my friends and family will thank you when they call and ask why I haven't left my house in a week and my boss calls and wonders why I'm not at work
That's an idea I hadn't even thought about, and a good one! I'm planning on building some sort of internet system. I've toyed with the idea of GPS too, but that would be a lot of work, and pointless 90% of the time.
I know this topic is old, but it has been brought up again and intrigues me. I have set up a test similar to the OP but with some helpful differences. I have stretched a Redstone line with repeaters from -400 to 400 (800 blocks - a rubber band on the controller is your friend here). Then I took the line 100 blocks to the side then 800 blocks back and then 100 blocks back to the start making a huge rectangle. It does not reconnect so it is not an infinite loop. I can confirm that a pulse sent will make it all the way around in about 10 seconds. I have more tests planned withe devices triggered at the far end sending signals back to see if that works. Let me know if you have suggestions for tests to run.
Edit: I meant to include this earlier but didn't have time:
The benefit of my test is this - I can see the effect of what is going on at the distant side of the map without actually having to go there. This means that whatever devices I put there for a test will have to work completely independently of a player's proximity. In my other tests I refer to here I sent the signal over about 300 blocks and then flew over to see the results - which were not very good. But I couldn't really tell what was a rendering issue and what was an actual redstone signal issue. For me, if it renders
Here are a few tests I have planned:
1. an RS NOR latch at the far end that when triggered will send the pulse back to the start.
2. a piston repeater (piston pushing block over torch) that when triggered will send the pulse back to start.
3. some tests with multiple pulses at specific delays with AND gates at the far end that will send the pulse back to start only if they receive the correct pulses (this is specific to my application).
4. a minecart on powered rail that is put in motion when it receives the pulse and then travels to a detector rail triggering the pulse to be sent back to the start. (this one really intrigues me because of all the different elements, not just redstone. I might even include a track that has to switch to make the cart go to the detector rail)
I know this topic is old, but it has been brought up again and intrigues me. I have set up a test similar to the OP but with some helpful differences. I have stretched a Redstone line with repeaters from -400 to 400 (800 blocks - a rubber band on the controller is your friend here). Then I took the line 100 blocks to the side then 800 blocks back and then 100 blocks back to the start making a huge rectangle. It does not reconnect so it is not an infinite loop. I can confirm that a pulse sent will make it all the way around in about 10 seconds. I have more tests planned withe devices triggered at the far end sending signals back to see if that works. Let me know if you have suggestions for tests to run.
Edit: I meant to include this earlier but didn't have time:
The benefit of my test is this - I can see the effect of what is going on at the distant side of the map without actually having to go there. This means that whatever devices I put there for a test will have to work completely independently of a player's proximity. In my other tests I refer to here I sent the signal over about 300 blocks and then flew over to see the results - which were not very good. But I couldn't really tell what was a rendering issue and what was an actual redstone signal issue. For me, if it renders
Here are a few tests I have planned:
1. an RS NOR latch at the far end that when triggered will send the pulse back to the start.
2. a piston repeater (piston pushing block over torch) that when triggered will send the pulse back to start.
3. some tests with multiple pulses at specific delays with AND gates at the far end that will send the pulse back to start only if they receive the correct pulses (this is specific to my application).
4. a minecart on powered rail that is put in motion when it receives the pulse and then travels to a detector rail triggering the pulse to be sent back to the start. (this one really intrigues me because of all the different elements, not just redstone. I might even include a track that has to switch to make the cart go to the detector rail)
I will let you know what I find out.
The quest for knowledge continues!
I'm glad to see someone has brought back interest to this, it has re-sparked my own as well. I'm curious to see how more complex mechanisms operate in an "unloaded" chunk. From your own thread, it appears most of your issues turned out to simply be graphical glitches. I'm going to set up a couple transceivers and see how well writing/reading long-distance pulses will be handled. If all goes well, I'll build more advanced mechanisms from that point. I'm really wondering how well something like piston tapes would work in partially loaded chunks. Ultimately it would be great to build two computers and have them talk to each other. It would start as just transferring feckless data back and forth, but it's still impressive for a first step. Definitely something that would turn MCPC engineers green with envy.
I'm glad to see someone has brought back interest to this, it has re-sparked my own as well. I'm curious to see how more complex mechanisms operate in an "unloaded" chunk. From your own thread, it appears most of your issues turned out to simply be graphical glitches. I'm going to set up a couple transceivers and see how well writing/reading long-distance pulses will be handled. If all goes well, I'll build more advanced mechanisms from that point. I'm really wondering how well something like piston tapes would work in partially loaded chunks. Ultimately it would be great to build two computers and have them talk to each other. It would start as just transferring feckless data back and forth, but it's still impressive for a first step. Definitely something that would turn MCPC engineers green with envy.
Soon to be continued... in the name of SCIENCE!!!
creating a bbs (for those who don't know, it stands for Bulitin Board System, a pre-internet way for dial-up internet connected pc's to "talk" to each other) system in a software game, being run on a firmware OS, on a gaming console... i think you'd break the space-time continuum if you achieved it... now only if we could then get that BBS (if you manage it) to play a simple text based game, like L.O.R.D. or something else like it.
creating a bbs (for those who don't know, it stands for Bulitin Board System, a pre-internet way for dial-up internet connected pc's to "talk" to each other) system in a software game, being run on a firmware OS, on a gaming console... i think you'd break the space-time continuum if you achieved it... now only if we could then get that BBS (if you manage it) to play a simple text based game, like L.O.R.D. or something else like it.
Well, my good sir, prepare to **** bricks. Some guys over at VoxelBox have been working on a roguelike dungeon crawler RPG engine... built out of redstone.
Now that your brain has been properly exploded, I shall continue. It's already crazy enough that it's possible to run software (redstone CPU program) on "hardware" (redstone CPU) that's being emulated by software (Minecraft) that's being emulated through firmware (360's integrated OS) by hardware. (Xbox 360's physical components)
Okay, I am now done making anyone reading this post question everything they've ever believed was true. A text-based game would be much more complicated in redstone than it is on a modern day computer. It's like comparing Snake to a MUD, the MUD is going to be much more sophisticated. Think of the redstone games you've seen, they usually consist of a game like Pong, or something where you control an entity no larger than 1 - 4 pixels. Most text-based RPGs are extremely descriptive, the largest word processor I've ever seen had a screen that could only support roughly 30 characters. It would be nice to see, I just don't think we'll ever have that pleasure.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffThe same goes for my roller coaster, which I have set up to work properly without a passenger. It also triggers some pistons to push a little "HI" out of the sand every odd lap. On even laps, it brings the sand back down flush, and the lil' greeting disappears. (Detector rail and flip flop at work here.) Again, I can leave this running and go anywhere on my map and the nether, and when I return,. the cart is still merrily doing its rounds, with HI" popping up and down.
This may be one of the reasons the world size is fixed. The way it was implemented, its vital data need to be in memory all at once? It would seem so.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffHmmm, well since the beginning of Minecraft history, whenever you load the game, clocks, or any kind of looping circuits, will be stuck. Because of your other problem I was starting to think maybe it just kept chunks loaded that had circuits connecting to a chunk near the player. But, according to this member...
...that seems to not be the case. Are you sure your clock is slow enough to be stable? A 3-clock or faster will always burn out eventually, even if you stand right beside it. Also, when you have the space for it, use a few torches in your clock, make sure it's an odd number. More torches = more stability and gives it a better chance of restarting itself when you load the game or it does burn out. In addition to the methods listed on the Wiki, you can also use a rapid pulser and some pistons to force updates near a clock and get it running again. A pulser, from what I've seen, will always restart itself.
Refer to the post above, by McGizmo, and my reply to it, we listed some effective methods of restarting automated circuits. No matter what, from now until the end of time, when you load the save, any circuit that was in the middle of moving power at the time of saving, will stick. You can't expect the chunks to be loaded even when you're not playing the game.
I'm glad you're not having trouble with the distance factor though, it seems one person may be. (I'm thinking the issue is just an unstable clock.) I would like to see more people testing my theory, just for variety. In the case of any experiment, there is no such thing as too many results.
Right. But my point is that if the data were being unloaded for distant chunks by the game, then reloaded when you went back to them, wouldn't clocked circuits left running exhibit the same anomalies they suffer when you save and load your game? The game continues to process these circuits regardless of how far away you go, and even through a portal to the other realm. That falls in line with your discoveries.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffOhhh, I see, you weren't just complaining about it failing. You were confirming my theory with its failure.
One new problem I'm experiencing is detector rails occasionally getting stuck in the high state. The solution is to mine them and replace them, but it's still annoying, particularly on my 2-pulse clock made up of a track loop, 2 detector rails, and of course a mine cart. It keeps the pistons that move a cycling roll of blocks in proper lockstep, until one rail decides to glitch out. It's really disappointing, because up to now, I thought that rails were very reliable. The pistons themselves may look glitchy, but they do their job properly.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffHmmm, I've seen power/detector rails used in circuits, (usually clocks) but have never actually used them myself. Will block updates fix this as well? Try placing a block beside the track, if the rail is still on, try removing or placing a block beside the block the rail is on. I'm guessing rails can become corrupted just as easily as blocks or redstone, and it sounds like that is what's happening here.
I've noticed the visual bugs too. Not just with pistons, even with redstone dust. A 1-clock looks like it is having some sort of seizure, yet when it is hooked up to a note block you can hear that it is working properly.
I did a Redstone distance experiment sometime before pistons first came out to determine signal distance.(I'm not digging through the forums to find where I posted this)
At roughly 300 blocks or more I could see or follow my signal from a torch clock.
At the time, I was just trying to determine a simple way to determine distance before digging a rather complicated long tunnel.
This did not seem to grab anyone's attention then. Not sure why it does now. Is it the activation? The fact that chunks are active while not loaded? Or did I miss something in the post?
Further.
Why do other folks on pc have massive contraptions that operate without the redstone hassle we do On xbox? Because they are generally playing on servers that do not shut down. And there is no auto save.
Anytime you exit and save while redstone is in cycle, the box tries to save the info(state on on/off). But since it is in cycle, power may not correctly save in real time. When you reload, power is resent from your cycle source, and some areas may already have power. This results in repeaters or redstone being stuck in a "on" state or causes burnouts which can lead to the "persistent burnout" that plagues torches.
If you play with auto save, the info is saved as above, but if your not in the active chunk area, the same result occurs.
As Cobra has stated, (and I've posted this over and over) "make on/off" switches. Power down your contraptions before exiting and saving. And if a clock is not in use, turn it off. Use piston clocks to power pistons. Use torch clocks to power anything else.
Yes, I've had a similar experience with my marquee circuit wired to some note blocks. The visual progression across the repeaters is uneven, yet the notes play with perfect regularity.
I'm thinking the same thing about detector rails, that they can get "stuck" or "burned out" like redstone. It's a shame, and takes some wind out of my sails. I hope they can fix the issues with circuitry soon.
Update: I've succeeded at doing the 2 pulse clock with redstone now. The problem is getting quick pulses out of a slow clock, not the 2 separate pulses in lockstep, which are easy to do by inverting one lead from the clock output. I went back to the brilliant and there was the solution staring me in the face (1:50 to 1:56). Two blocks separated by a repeater with 3 ticks of delay, and a redstone torch on the side with some dust going back to the front. This does the magic, though I confess I'm not quite sure what's going on. (My guess is that the delay allows the side output to get through for its duration, and then shuts it off.) The output is quick and reliable. Works like a charm now, without the dodgy minecart fallback.
My roll is only 3 bits wide, but it works exactly as in the video, including how the data passes or is blocked. It's 10 blocks of cycling data per bit (opaque for 1, glass for 0). I'm not doing anything with the data yet, and like I said it's only 3 bits. I'm just elated that this is working so well now.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffWell, I believe one factor of our experiments made the difference. Your experiment to test the distance needed for whatever you were building. Mine was to find the absolute limit, and made the discovery of all chunks remaining active at the same time. Who knows, maybe the story did help a bit. I like to add a little element of storytelling to a thread whenever I can, especially when it's a long one. Makes it just a tad more fun to read.
I see what you're saying, though people often do have these redstone bugs on PC. Just not as much, thanks to servers. Either way, we all have to deal with the bugs at some point, since different states of a redstone item, according to the data, are a completely different block. I just don't understand why there is nothing to make it revert back to the way it should be, besides a block update.
I suppose it's possible an autosave could make things stick. Perhaps after an autosave, the game reloads all chunks around you? That would provide an explanation for a clock still working if you autosave beside it, but having errors if you autosave at a good distance from it.
It would BE cool, but it wouldn't render. At all. LOL
I tried to capture a friend blowing up a house he was bored with. He only used about 35 TNT, and it lagged so badly as soon as the first 6 exploded, that it just looked like the house disappeared after sitting motionless for 10-12 seconds.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffThat's an idea I hadn't even thought about, and a good one! I'm planning on building some sort of internet system. I've toyed with the idea of GPS too, but that would be a lot of work, and pointless 90% of the time.
Edit: I meant to include this earlier but didn't have time:
The benefit of my test is this - I can see the effect of what is going on at the distant side of the map without actually having to go there. This means that whatever devices I put there for a test will have to work completely independently of a player's proximity. In my other tests I refer to here I sent the signal over about 300 blocks and then flew over to see the results - which were not very good. But I couldn't really tell what was a rendering issue and what was an actual redstone signal issue. For me, if it renders
Here are a few tests I have planned:
1. an RS NOR latch at the far end that when triggered will send the pulse back to the start.
2. a piston repeater (piston pushing block over torch) that when triggered will send the pulse back to start.
3. some tests with multiple pulses at specific delays with AND gates at the far end that will send the pulse back to start only if they receive the correct pulses (this is specific to my application).
4. a minecart on powered rail that is put in motion when it receives the pulse and then travels to a detector rail triggering the pulse to be sent back to the start. (this one really intrigues me because of all the different elements, not just redstone. I might even include a track that has to switch to make the cart go to the detector rail)
I will let you know what I find out.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffThe quest for knowledge continues!
I'm glad to see someone has brought back interest to this, it has re-sparked my own as well. I'm curious to see how more complex mechanisms operate in an "unloaded" chunk. From your own thread, it appears most of your issues turned out to simply be graphical glitches. I'm going to set up a couple transceivers and see how well writing/reading long-distance pulses will be handled. If all goes well, I'll build more advanced mechanisms from that point. I'm really wondering how well something like piston tapes would work in partially loaded chunks. Ultimately it would be great to build two computers and have them talk to each other. It would start as just transferring feckless data back and forth, but it's still impressive for a first step. Definitely something that would turn MCPC engineers green with envy.
Soon to be continued... in the name of SCIENCE!!!
creating a bbs (for those who don't know, it stands for Bulitin Board System, a pre-internet way for dial-up internet connected pc's to "talk" to each other) system in a software game, being run on a firmware OS, on a gaming console... i think you'd break the space-time continuum if you achieved it... now only if we could then get that BBS (if you manage it) to play a simple text based game, like L.O.R.D. or something else like it.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffWell, my good sir, prepare to **** bricks. Some guys over at VoxelBox have been working on a roguelike dungeon crawler RPG engine... built out of redstone.
Now that your brain has been properly exploded, I shall continue. It's already crazy enough that it's possible to run software (redstone CPU program) on "hardware" (redstone CPU) that's being emulated by software (Minecraft) that's being emulated through firmware (360's integrated OS) by hardware. (Xbox 360's physical components)
Okay, I am now done making anyone reading this post question everything they've ever believed was true. A text-based game would be much more complicated in redstone than it is on a modern day computer. It's like comparing Snake to a MUD, the MUD is going to be much more sophisticated. Think of the redstone games you've seen, they usually consist of a game like Pong, or something where you control an entity no larger than 1 - 4 pixels. Most text-based RPGs are extremely descriptive, the largest word processor I've ever seen had a screen that could only support roughly 30 characters. It would be nice to see, I just don't think we'll ever have that pleasure.