Yes I did. Which immediately crashed MineCraft because I use OptiFine which gives a substantial performance boost, and MCPatcher and OptiFine don't play nicely together.
Having subsequently learned that Misa's Texture Pack is incompatible with OptiFine, I've uninstalled the texture pack. It's a beautiful pack and I commend Misa for terrific artwork, but I'm not going to give up the near-doubling of my framerate that I get from OptiFine.
For people who have really good hardware or the latest video cards, or to whom performance is less important than appearance, Misa's is definitely the way to go. :-)
I love this texture pack! One odd thing I've noticed since upgrading to 1.4.2 and getting the latest pack, my zombies look odd. They have no faces and the backs of their heads are missing. I also was attacked by an invisible zombie once. Not sure what that was about.
Mob farming is a natural and rational response to an enchanting system that continues to suck ass. If they want to nerf it that's their business but people who invested a lot of time into building such farms are going to be pissed. Rightfully so. A better way to reduce mob farming would be to fix the shitty enchanting system.
Geez, minecraft is giving me serious scares.
Even the epic experience in the school in F.E.A.R 2 didn't give me such paranoia and scares like an unexplored cave with a lot of unexplored and dark ways in minecraft give me.
Nothing compares to the sudden sound of an arrow cutting through the air and racing towards you, or the strange sound of a spider behind you, just for you to turn and don't see anything.
There's nothing like digging a square directly under you and falling to a huge, dark chamber, filled with monster noises.
Notch managed not to just make a survival game, but a creepy game too!
It's a computer game dude. I've yet to see one that is actually "scary". I'll never understand people freaking out over blocky-cartoony bad guys in a game where if you die you just pop right back into existence. But I like a good scare, so if it gives you chills and thrills, I'm happy for you.
I forget, big bebop server or something like that? I played on that for a few weeks until I tired of the immature chatter, the horrid lag, and people messing up my stuff. I just play single player now. Much more relaxing.
Sounds like it would have a lot of atmosphere even if it was completely decorative in nature. Not sure about the amethyst torches or the increased enchantability, but it would make for some cool caves. :-)
Historically, books were often bound with leather covers. The addition of leather is a hardship true, but the reasoning behind it (in addition to making books more realistic) probably has to do with balancing the game. It's so easy to get XP's now (mining coal, smelting sand, etc.) that enchanting has become a lot easier. It order to make it not be too easy, they made it harder to craft books.
That's just the way it is.
And your world has cows in it. If you walk far enough you will find them. Bring wheat.
Only in extreme situations do I notice weird lag problems like what was described in the OP. While conceptually I completely agree with what was said, you have to keep in mind that Client-Server games have to be written in such a way that the client feels smooth, and like everything happens in real-time. Giving the server the final say on everything is, indeed, the most effective way to prevent lag issues and other similar problems, but you run into a reverse of the problem you were outlining.
>Player breaks a block; Client sends information to server
>Block is not broken, because server has not acknowledged this
>Server agrees that block is broken; sends information to client.
>Block breaks.
This solves the problems, but makes the game feel clunky and slow. Technically speaking you're completely right about your post, but you have to remember the human element when it comes to playing games. No matter how perfectly and bug-free a game is programmed, the game has to actually feel smooth for the players. Sometimes, you just have to let flaws be flaws and "band-aid" fix some of them. Your solution of having the blocks "glow" or something similar does help reinforce the positive feedback of "I broke the block." but it would still feel very clunky, especially if the server - for some reason - does not register the command.
You're absolutely right of course, this is one of the reasons why I suggest it is a challenging problem that Mojang has themselves stuck in. The underlying pace and nature of the game UI is suffused with single-player concepts and turnaround expectations... sticky wicket that.
If pumpkins grow in the wild, so should melons. It wouldn't unbalance the game--it's already ridiculously easy to get plenty of food. Dump a bucket of water on grass and you'll get enough seeds to start a wheat farm. Wander in a big circle with a piece of wheat in your hand and you'll come home with enough animals to breed to keep you fed perpetually--especially chickens which lay eggs constantly. Given my druthers I'd choose to eat just about anything other than melon, and all that other stuff is way way way easier to get. I just want melon so I can have farms that feel "complete" to me.
Pumpkins are fairly rare and if they wanted to make melons much rarer that would be fine with me, but there is no compelling reason for them to be buried in mineshafts. They're plants and they should grow in the wild just like pumpkins, cocoa plants, vines, trees, and flowers do.
Preemptive note to mods: I spent a lot of time on this post. If this isn't the correct place for it, please don't just delete it--please help me move it to the proper place.
This is something about Minecraft that has been bugging me for awhile. I think the developers are aware of it and I think the move to one codebase which is strictly multiplayer is the first step in addressing it. Essentially the Minecraft client is sharing management of state information with the server, and it should not be. The server should maintain the state and the client should be as thin as possible. If you don't know what I mean by state information, read the next two paragraphs, otherwise skip them.
When you go to an automated teller machine (an ATM) you are dealing with a client-server system. The client application resides in the teller, and the server is in the bank. There's something that the teller is NEVER allowed to do, and that's make its own decisions about the state of your bank account or transactions. Without this safety check in place, you could have any number of problems arise.
For example, two ATMs next to each other. You walk up to ATM #1 and ask to withdraw $1000. It asks the server for your account balance of $1001. Your friend who also shares the account with you walks up to ATM#2 and asks for $1000, it too checks the balance and sees that it is $1001. Now if the ATM's were allowed to decide for themselves that it is okay to dispense money, you and your friend could collectively withdraw $2000 from your $1001 bank account. Oops. That piece of information (okay to dispense X dollars) is what we call "state" information, it's data that the system makes decisions based on, it reflects the "state" of the system.
In a client-server application (like Minecraft) you can't have the client and the server both managing the state. State management almost always should be entirely on the server side. In certain cases you might have small pieces of state information that exist on the client side that are pertinent to the client ONLY (i.e. the user pushed button X), but for the most part if the information matters to the server or to any other client, then that information needs to be maintained on the server only.
Watching the MindCrack guys playing UHC recently started making me crazy because people were taking damage by mining out blocks, stepping into the open space, and then the blocks would return causing suffocation damage ("block lag" in multiplayer parlance). What seems to be happening here is the client is deciding for itself "this block is gone, I'll remove it" and that's a recipe for lag-related bugs.
The client can't remove a block until the server says it's gone. Period. If the server says it's gone and then the server says it's back, your have bigger problems than shared state management. The minecraft UI is of course not conducive to this because folks are used to pressing and holding the mouse button while waiting for blocks to break. This is a continuous operation which means you can't just send one message to the server saying "user removed block x,y,z"... instead you have to send a stream of messages "user hit block x,y,z for 0.25 seconds with tool id t" every quarter second or something like that.
Doubtless the server is sending regular chunk updates to the client, and that's why we get blocks disappearing, reappearing and disappearing:
Server sends chunk update.
Before receiving the update, the client sends "user broke block x,y,z", and then decides for itself to remove the block.
Client receives old chunk update where the block still existed, and poof it comes back.
Server receives client message and updates the chunk to remove the block, then sends new chunk update.
Client receives next chunk update where the block is gone, and poof it disappears again.
In addition to the presence or absence of blocks, everything needs to be maintained on the server such as: player health, hunger and potion effects, damage to items in inventory, etc. etc. etc. We shouldn't have people drowning because the server says they are in water while the client says they are in an air pocket.
IMO the best solution is to move all state management out of the client--the client doesn't get to do ANYTHING but render the world and accept the user's inputs. If you wanted something that would make the lag time tolerable maybe this would work:
Once the client has sent a message to the server that block x,y,z should be broken, change the way that block is rendered, make it semi-transparent, or make it glow, play the block breaking sound but leave the block there. That way the user can move on to another block while the server is catching up and eventually (probably within a second or two) the broken block will disappear and the drop will be spawned.
That would be better than stuff "unhappening" and then "happening again"--the challenging thing is you would have to do the same with placing blocks. The general way in which users interact with minecraft and the feature set of the application (read: redstone) makes server-side state management problematic, but I'm sure the developers will eventually figure out how to balance state management in the game and give us the smoothest possible gameplay.
I like the MindCrack guys... I sub to VintageBeef, PauseUnpause, Guude, Etho, Zisteau, and BDouble0. I occasionally watch Docm, and AnderZEL but not as much. Love their ultra hardcore series when they come out.
Apart from them... CaptainSparklez I guess, he's pretty good.
I can't stand the really shrieky guys that put on lame voices and tell jokes of a variety that stopped being funny when I was twelve (in 1979), but my daughter likes to watch some of those sorts of videos.
I couldn't find any reference to the size of normal biomes, so I just traveled 128 blocks in the nether. It's exactly 1 map worth of distance, so if I wanted I could explore the ocean in between. It turned out that I was lucky.
0
Thanks. You'll note that in my post I said that I had updated both the texture pack and minecraft to the latest versions.
Yes I did. Which immediately crashed MineCraft because I use OptiFine which gives a substantial performance boost, and MCPatcher and OptiFine don't play nicely together.
Having subsequently learned that Misa's Texture Pack is incompatible with OptiFine, I've uninstalled the texture pack. It's a beautiful pack and I commend Misa for terrific artwork, but I'm not going to give up the near-doubling of my framerate that I get from OptiFine.
For people who have really good hardware or the latest video cards, or to whom performance is less important than appearance, Misa's is definitely the way to go. :-)
0
Everything else looks great though!
0
0
3
0
0
0
0
That's just the way it is.
And your world has cows in it. If you walk far enough you will find them. Bring wheat.
0
You're absolutely right of course, this is one of the reasons why I suggest it is a challenging problem that Mojang has themselves stuck in. The underlying pace and nature of the game UI is suffused with single-player concepts and turnaround expectations... sticky wicket that.
0
Pumpkins are fairly rare and if they wanted to make melons much rarer that would be fine with me, but there is no compelling reason for them to be buried in mineshafts. They're plants and they should grow in the wild just like pumpkins, cocoa plants, vines, trees, and flowers do.
1
This is something about Minecraft that has been bugging me for awhile. I think the developers are aware of it and I think the move to one codebase which is strictly multiplayer is the first step in addressing it. Essentially the Minecraft client is sharing management of state information with the server, and it should not be. The server should maintain the state and the client should be as thin as possible. If you don't know what I mean by state information, read the next two paragraphs, otherwise skip them.
When you go to an automated teller machine (an ATM) you are dealing with a client-server system. The client application resides in the teller, and the server is in the bank. There's something that the teller is NEVER allowed to do, and that's make its own decisions about the state of your bank account or transactions. Without this safety check in place, you could have any number of problems arise.
For example, two ATMs next to each other. You walk up to ATM #1 and ask to withdraw $1000. It asks the server for your account balance of $1001. Your friend who also shares the account with you walks up to ATM#2 and asks for $1000, it too checks the balance and sees that it is $1001. Now if the ATM's were allowed to decide for themselves that it is okay to dispense money, you and your friend could collectively withdraw $2000 from your $1001 bank account. Oops. That piece of information (okay to dispense X dollars) is what we call "state" information, it's data that the system makes decisions based on, it reflects the "state" of the system.
In a client-server application (like Minecraft) you can't have the client and the server both managing the state. State management almost always should be entirely on the server side. In certain cases you might have small pieces of state information that exist on the client side that are pertinent to the client ONLY (i.e. the user pushed button X), but for the most part if the information matters to the server or to any other client, then that information needs to be maintained on the server only.
Watching the MindCrack guys playing UHC recently started making me crazy because people were taking damage by mining out blocks, stepping into the open space, and then the blocks would return causing suffocation damage ("block lag" in multiplayer parlance). What seems to be happening here is the client is deciding for itself "this block is gone, I'll remove it" and that's a recipe for lag-related bugs.
The client can't remove a block until the server says it's gone. Period. If the server says it's gone and then the server says it's back, your have bigger problems than shared state management. The minecraft UI is of course not conducive to this because folks are used to pressing and holding the mouse button while waiting for blocks to break. This is a continuous operation which means you can't just send one message to the server saying "user removed block x,y,z"... instead you have to send a stream of messages "user hit block x,y,z for 0.25 seconds with tool id t" every quarter second or something like that.
Doubtless the server is sending regular chunk updates to the client, and that's why we get blocks disappearing, reappearing and disappearing:
- Server sends chunk update.
- Before receiving the update, the client sends "user broke block x,y,z", and then decides for itself to remove the block.
- Client receives old chunk update where the block still existed, and poof it comes back.
- Server receives client message and updates the chunk to remove the block, then sends new chunk update.
- Client receives next chunk update where the block is gone, and poof it disappears again.
In addition to the presence or absence of blocks, everything needs to be maintained on the server such as: player health, hunger and potion effects, damage to items in inventory, etc. etc. etc. We shouldn't have people drowning because the server says they are in water while the client says they are in an air pocket.IMO the best solution is to move all state management out of the client--the client doesn't get to do ANYTHING but render the world and accept the user's inputs. If you wanted something that would make the lag time tolerable maybe this would work:
That would be better than stuff "unhappening" and then "happening again"--the challenging thing is you would have to do the same with placing blocks. The general way in which users interact with minecraft and the feature set of the application (read: redstone) makes server-side state management problematic, but I'm sure the developers will eventually figure out how to balance state management in the game and give us the smoothest possible gameplay.
At least I hope so!
0
0
Apart from them... CaptainSparklez I guess, he's pretty good.
I can't stand the really shrieky guys that put on lame voices and tell jokes of a variety that stopped being funny when I was twelve (in 1979), but my daughter likes to watch some of those sorts of videos.
0