ive seen that first one but i heard it is not very effective and about 50% of the sugarcane gets stuck..
You're not going to get an automated farm that doesn't lose some of the sugarcane. Since the block the cane is growing on can't be removed, and some of the cane is invariably going to fall on that block, there's not much you can do.
Since there's no need for the flip-flop to be silent in this case, why not use the super-compact T flipflop design?
Feed a signal to either blue block (like the button is doing - you don't need the button if you feed it a signal from something else) and the red output switches state from on to off. The only minus is that it is on the falling edge of the signal, but you can speed it up by putting an inverter on the line before it.
You can eliminate the need for a redstone block as well by putting a redstone torch in a hole under where the redstone block is shown, and replace the redstone block with whatever block type you want.
I have a 1.6.4 server I'm running, and I would love to have Runecraft on it (I'm using the development build of CraftBukkit, which seems to be working fine). Any chance you could post a quick recompile with the newer bukkit? I tried editing the .class files by hand, but that caused .... problems.
So I've been spending a good amount of time thinking about Mincraft without actually playing it due to computer issues. And I started thinking about how Optifine (which is an awesome mod) allows you to double your viewing distance. This is awesome, except for the fact that it takes a lot of time to load the chunk data and it eats up memory like there's no tomorrow. So I started thinking: what would it take to make the far view distance easier on the RAM?
I realized the solution rather quickly. You don't actually need to load all the data for a chunk when you're viewing it at a distance.
Unfortunately, this presents some significant coding challenges. Minecraft will need to keep track of two sets of chunk data for every chunk - the first is the whole kit and caboodle, with every single block mapped out whether it's visible or not, as well as the entity data, et cetera.
The second set of data is what would make this work. Only the visible blocks need to be loaded into memory when viewing them at a distance. Since there's no way you'll be interacting with these chunks, you aren't going to see anything that's underneath the surface layer of blocks. This limit means the 'visible blocks' metadata can be much smaller than the chunk data, which in turn means it can be loaded much faster. There's still the issue of framerate when viewing so much terrain at once, but that is another issue altogether. It's possible to calculate large faces of adjacent blocks as single polygons, but that's a different topic entirely.
Chunks would, however, need to be generated at a distance if it's viewable but outside 'active' range, and every time a chunk is changed, the 'visible blocks' metadata would need to change as well - though it's possible this could be calculated only when the chunk is unloaded.
It would be a challenge, that's for sure, but a different sort than most of the requests put forth on this forum. Maybe it'll pique someone's interest.
This looks -beautiful-. I've been missing having a good redstone sim ever since Baezon left. I like Simnik's continuation as well, but this one is practically future-proof. I love it! Thanks a million for moving forward with this, I hope to get a lot of use out of it. :biggrin.gif:
Holy cow, I'm away for a month and the server gets huge! I take it the MCRegion update made it easier for the server to deal with large areas without falling over? :biggrin.gif: Time to go stake out my own claim out in the wilderness and start building cool stuff!
No seriously, I used to get 15fps on it in Alpha. Now it's not playable. I fully expect my computer to crash and burn on 3D gaming. I only get about 6fps on most 2D gaming online. anyways, I'll be getting an AMD 2.4(?)GHz processor triple core, ATI mobility Radeon HD 4250 graphics card, 4gb RAM in a few weeks.
Okay, I can understand frustration with it getting slower. I suspect it has something to do with adjustments to the light rendering system.
You might try some of the Optimine mods, see if that speeds things up.
And thanks for being a good sport about my rant. :]
I'm running this game on an AMD Athlon XP 2500+ 1.84 GHz, 1.00 GB RAM....if this can do it, I dont know what cant?!
1.84 Ghz processor, 512mb ram and intel integrated graphics card.
.....wait.
You're trying to run... a 3D-intensive game... on an intel integrated GPU? And with 512MB RAM?
I hate to break it to you, but all the people who said 'get a better rig'?
They were right.
Intel cards do not do 3D well. It's not what they're built for; they're meant to be a simple graphics solution for non-gamers. You're going to run into all sorts of problems.
Also, most everything these days expects you to have at least 1GB of RAM. Minecraft especially tends to be a memory hog thanks to all the blocks it has to keep track of, and if you wind up having to use virtual memory it's going to slow to a crawl.
Quote from BlackMonarch »
A single-core 1.6 ghz Atom with a Geforce 9400 GT. It can handle Doom 3 just fine...
Doom3 is graphics intensive and not particularly processor intensive. A GeForce 9400GT is plenty for that.
Oh yeah, and Doom 3 came out SIX AND A HALF YEARS AGO.
Minecraft is just as processor intensive as it is graphics intensive. A single-core 1.6GHz Atom is NOT going to cut it. That's not even a desktop-class processor - it's a NETBOOK PROCESSOR. If Minecraft were compiled in C like the Doom 3 engine, it might work - but guess what? It isn't. It runs in Java. Java makes things slower because it has a whole extra layer of virtualization mucking things up.
For crying out loud, people. This is like asking why your phone can't play Black Ops.
If it's a laptop, then your integrated graphics chip -is- your nVidia accelerated graphics. It might not be making the best use of it, though. Try updating your graphics drivers.
Nah, not a scam - that's just how MasterCard does things. I've seen it other places. It can be a real major nuisance when you use NoScript though, as it doesn't tend to play well.
The Minecraft website is having some major issues, you may want to wait until a few hours later and see if traffic load's gone down a bit.
0
Works like a charm! Thanks for posting, and pass on our thanks to C'tri!
0
With 1.7 coming out on Friday you're far better served waiting for Bukkit to update to that, and then make the new build afterwards.
0
Shoot. I was just going to mention that too.
0
You're not going to get an automated farm that doesn't lose some of the sugarcane. Since the block the cane is growing on can't be removed, and some of the cane is invariably going to fall on that block, there's not much you can do.
0
Feed a signal to either blue block (like the button is doing - you don't need the button if you feed it a signal from something else) and the red output switches state from on to off. The only minus is that it is on the falling edge of the signal, but you can speed it up by putting an inverter on the line before it.
You can eliminate the need for a redstone block as well by putting a redstone torch in a hole under where the redstone block is shown, and replace the redstone block with whatever block type you want.
0
I have a 1.6.4 server I'm running, and I would love to have Runecraft on it (I'm using the development build of CraftBukkit, which seems to be working fine). Any chance you could post a quick recompile with the newer bukkit? I tried editing the .class files by hand, but that caused .... problems.
0
I realized the solution rather quickly. You don't actually need to load all the data for a chunk when you're viewing it at a distance.
Unfortunately, this presents some significant coding challenges. Minecraft will need to keep track of two sets of chunk data for every chunk - the first is the whole kit and caboodle, with every single block mapped out whether it's visible or not, as well as the entity data, et cetera.
The second set of data is what would make this work. Only the visible blocks need to be loaded into memory when viewing them at a distance. Since there's no way you'll be interacting with these chunks, you aren't going to see anything that's underneath the surface layer of blocks. This limit means the 'visible blocks' metadata can be much smaller than the chunk data, which in turn means it can be loaded much faster. There's still the issue of framerate when viewing so much terrain at once, but that is another issue altogether. It's possible to calculate large faces of adjacent blocks as single polygons, but that's a different topic entirely.
Chunks would, however, need to be generated at a distance if it's viewable but outside 'active' range, and every time a chunk is changed, the 'visible blocks' metadata would need to change as well - though it's possible this could be calculated only when the chunk is unloaded.
It would be a challenge, that's for sure, but a different sort than most of the requests put forth on this forum. Maybe it'll pique someone's interest.
0
0
0
0
Okay, I can understand frustration with it getting slower. I suspect it has something to do with adjustments to the light rendering system.
You might try some of the Optimine mods, see if that speeds things up.
And thanks for being a good sport about my rant. :]
1
.....wait.
You're trying to run... a 3D-intensive game... on an intel integrated GPU? And with 512MB RAM?
I hate to break it to you, but all the people who said 'get a better rig'?
They were right.
Intel cards do not do 3D well. It's not what they're built for; they're meant to be a simple graphics solution for non-gamers. You're going to run into all sorts of problems.
Also, most everything these days expects you to have at least 1GB of RAM. Minecraft especially tends to be a memory hog thanks to all the blocks it has to keep track of, and if you wind up having to use virtual memory it's going to slow to a crawl.
Doom3 is graphics intensive and not particularly processor intensive. A GeForce 9400GT is plenty for that.
Oh yeah, and Doom 3 came out SIX AND A HALF YEARS AGO.
Minecraft is just as processor intensive as it is graphics intensive. A single-core 1.6GHz Atom is NOT going to cut it. That's not even a desktop-class processor - it's a NETBOOK PROCESSOR. If Minecraft were compiled in C like the Doom 3 engine, it might work - but guess what? It isn't. It runs in Java. Java makes things slower because it has a whole extra layer of virtualization mucking things up.
For crying out loud, people. This is like asking why your phone can't play Black Ops.
p.s. if your phone can play Black Ops shut up.
p.p.s. why, oh why am I feeding the trolls
0
0
The Minecraft website is having some major issues, you may want to wait until a few hours later and see if traffic load's gone down a bit.
0