The main idea is to have to "Work" a little to get the information on F3, then the server admin can turn debug info off, or have it off by default in a future patch.
We've had F3 as a tool for so long, it's become part of the gameplay, that probably was not the intended design.
Now that we will soon have the game rule: reduced Debug Info (which I like). I was thinking of alternatives for the coordinate system. Most of these ideas, I've had since before the new game rule. Never really liked the idea of using a debug screen to get the information, but I still think the information is useful, especially for multiplayer.
The game always lacked ways for finding friends in a multiplayer game. And no easy way to bookmark an area. So here are different ideas I've had, and you guys can discuss which ones you like and don't like.
* New Item: GPS. This would keep the F3 functionality, but at least you have to work and craft the item to get it. Would be interesting if the GPS only worked on the surface.
* New Item: Whistle or Horn. You can craft this item and use it to alert nearby players. They would use the audible range and stereo sound to locate where you are. Maybe have both items and one has more range than the other.
* Better Maps
- The maps could show coordinates whilst using it. Note that maps in real life do have coordinates.
- Combining a map with any color Dye, adds a dot where you are standing on the map. Note you can do this on your inventory 2x2 crafting area.. eg: Map + Ink Sac, would add a black dot on the map, where you stand.
Now that we will soon have the game rule: reducedDebugInfo (which I like). I was thinking of alternatives for the coordinate system. Most of these ideas, I've had since before the new game rule. Never really liked the idea of using a debug screen to get the information, but I still think the information is useful, especially for multiplayer.
The game always lacked ways for finding friends in a multiplayer game. And no easy way to bookmark an area. So here are different ideas I've had, and you guys can discuss which ones you like and don't like.
* New Item: GPS. This would keep the F3 functionality, but at least you have to work and craft the item to get it. Would be interesting if the GPS only worked on the surface.
* New Item: Whistle or Horn. You can craft this item and use it to alert nearby players. They would use the audible range and stereo sound to locate where you are. Maybe have both items and one has more range than the other.
* Better Maps
- The maps could show coords whilst using it. Note maps in real life do have coordinates.
- Combining a map with any color Dye, adds a dot where you are standing on the map. Note you can do this on your inventory 2x2 crafting area.. eg: Map + Ink Sac, would add a black dot on the map, where you stand.
There's no safe way to keep cows. If i put them in a pen, they escape. If I put them in the pit they suffocate. Seems to happen more when loading the world, but I think it's not limited to that. Maybe loading/unloading the chunk due to distance will cause it too.
I have a square pen with 10x10 fence, and roughly around 20 cows. I wouldn't say that is overfilled. Not even close to overfilled. Cows just push each other until they clip out.
If I put them into a 10x10x2 pit, they push into the wall until they suffocate. I think it's the same "clipping" problem.
Entities like cows should never clip into walls/fences to begin with, because once they are in, they will just try to auto-fix by going out in any direction. I think it's possible the entities are moving before the chunk is fully rendered? In that case it would be better to restrict movement until the chunk (and the 8 adjacent ones) are rendered.
We run a small minecraft server. The server runs on low end hardware and for performance reasons we chose to lower the view-distance on the server settings to 8. Which fits nicely with the "normal" render distance on the client. The fog on the client side would hide the loading of the chunks.
But this seems to hit bug #2536 (View distance affects mob spawning)
I really don't understand the principle behind the bug, as 8 chunks is the point where mobs should despawn immediately. AFAIK mob start spawning 24 blocks away from you (16 for mob spawners), that's roughly 2 chunks! And the code to despawn them (randomly) starts at 32m, which would be anything beyond the 2 chunks.
So the way I see it, except for the despawn immediately functionality, Any view-distance of 3 or greater, should be enough for the mob spawning to work.
If anything, the conditions for making them go away (despawn) are less. AFAIK, when chunks are unloaded everything is kept as it was. Like when you leave the nether and come back. The mobs should be in the same place. Or when you teleport to a very far distance, and then come back. Those mobs are kept as well.
But like I said, I really don't understand the principle behind the bug. The purpose of this thread is to raise awareness on it, and thus finally get it fixed. And maybe understand a little bit more on why it happens.
The curious thing is, when map was just recently generated, we had a lot of mobs the first few nights. But now I can go exploring at night without putting a single light source, and not have to worry much about mobs. The lack of mobs has already been tested many times by different people tracking this bug (and it's duplicates) so no need to go over that part.
The wiki and various other pages claim that Nether Brick is nonflammable. That doesn't seem to be the case.
I tried both igniting it myself or letting the Ghast do it, and it will always set on fire for a few seconds.
It would be interesting to have 1 block type in the game, apt for construction, that is 100% flame retardant. Especially for the nether.
I've built various bridges and walkways on the nether counting on this, only to find out any form of cobble/stone would have been better/easier. And stone is actually easier to see in the Nether.
IMHO, creepers should fully land before they start detonating, and not start detonating in mid air. This would fix any bugs with the hissing sound. So even if they drop, you still have about the same time to respond and you'll still hear the hissing sound.
Even if you hear the hissing and die anyway, I think it's more fun that way. It reminds me when I played Wolf:ET, the panzerfaust made distinct charging noise that really didn't give you much time to react to. So most of the times: "It's the sound of inevitability, that is the sound of your death".
Now would be a good time to check everything you use to browse the Internet for updates.
I.- Browsers:
* Internet Explorer (go to Windows Update)
* Firefox (go to: click the firefox button and go to Help, About Firefox. Or visit the firefox website)
* Chrome (go to: click About Google Chrome on the menu. Or visiit the google chrome website)
II.- Java (Oracle/Sun):
Go to Java.com and click the "Do I have Java?" link.
Remember that if you have a 64-Bit OS, you will need to update both 32-bit and 64bit manually. AFAIK the automatic update feature does not work for the 64-Bit java installation. So it's possible your 32-Bit has been updated while the 64-Bit has fallen behind.
You might be able to use the "Internet Explorer (64-Bit)" shortcut on your system, and redo the test at java.com (haven't tested this)
There should be better negotiation of view distance on the server and render distance on the client. Two important aspects come to mind.
* Chunk Cache: This should be the minimum of both. Currently this seems to be regulated by the server alone. But if the client is using a lower distance than the server, it still loads the other chunks like the OP stated. Maybe the intent was for single player games to generate the correct amount of "life" around the player (generation of mobs, growth of plants, etc)
But for multiplayer scenarios, generation is happening on the server anyway, the client doesn't need to know there is a cow 3 chunks further than his view distance, the information can be sent if the player gets closer to the cow.
* Fog effect: The fog can gracefully hide the loading of chunks, so that they load just beyond the fog, and you don't see the chunks popup right before your eyes. But the settings on the client have no automatic relationship with the server.
Use the "far" on the client and a server with the lowest view distance, and you will see a whole lot of nothingness. The fog could easily cover that excess nothing
I think the fog should also be a minimum of both. So if you are lower than the server, it will use your fog setting. and if the server is lower than you, it will use the server's fog setting. This could be a 5th option on the client's render distance settings.
It could either match it exactly and the world would render just beyond the fog, so you will never see it popup. Or it could be +1 for those who don't want to miss anything. But anything beyond that loaded chunk is nothing, and might as well be fog.
Right now you could lower the render distance until you achieve the effect, but the jumps are rather big, especially on the higher settings. So you can't really fine tune to match the server.
I've heard about a Java option: -Xincgc
Has anybody tried this with Amazon's micro instance?
-Xincgc
Enable the incremental garbage collector. The incremental garbage collector, which is off by default, will eliminate occasional garbage-collection pauses during program execution. However, it can lead to a roughly 10% decrease in overall GC performance.
This could help "avoid" long bursts of GC, which could cause throttling by Amazon, thus being a good thing.
OR
It could cause more overall CPU usage in total, which could cause more throttling by Amazon, and thus be bad.
Some still argue of the anvil is OP, Fair, or Too Expensive. Regardless, I think there's a few things that need to be tweaked.
I.- Repairing Un-enchanted Tools:
Currently there is no reason to do this on an anvil. It's actually A LOT worse than using the old repair method using the Inventory. I think this should be entirely the opposite.
There should be some benefit to using an anvil to repair un-enchanted tools compared to using the old method via the inventory. Using an anvil requires more effort in total, and thus you should be rewarded for your investment. In Comparison: You need a lot of iron to build the anvil, the Anvil wears down, and you have to move to the location of the anvil.
What could change? (for un-enchanted items)
* The resulting tool should not stack up a repair count on it. It should result like the inventory repair.
* Repairs should require no XP, the anvil still spends some of it's uses in exchange for a "better" repair, like:
* Better % boost for normal repairs. From the current +10% via the inventory to for example +20%
* Lower costs when using raw materials. It seems the anvil doesn't distinguish between a shovel and a chest piece. So right now repairing a shovel requires more raw materials than making a new one. The repair should consider the amount of raw materials used in the original recipe.
I think requiring 75% (and rounded up) of the original raw material should be enough for a full repair from any durability level. Which would look something like this:
Boots 4 * .75 = 3
Helmet 5 * .75 = 3.75 => 4
Leggings 7 * .75 = 5.25 => 6
Chest-plates 8 * .75 = 6
All Tools end up requiring the same materials as the original recipe, save the sticks.
Smaller repairs would require the corresponding fraction.
In Comparison, You can in theory:
1) Use an item up to the last point of durability.
2) Make a new one for the purpose of usage and repair of the old one.
3) Use it until its durability is 90% or less
4) Repair it with the other item using the inventory repair interface
5) You'll get +10% free durability on the repair, meaning that if you do it at exactly 90% the item will go back to 100% regardless of what is left on the old one.
The table above may yield slightly more than 10% (depending on the item) but I think that's the reward you should get from using the anvil on unenchanted items. Otherwise the anvil would be completely useless for those type of items.
II.- Level Cap on repairs, eg: "Too Expensive"
This removes freedom from the a game that's supposed to be a sandbox. Gaining levels is slower and slower the higher you go, and I think the effort required should be fair enough for the bigger anvil upgrades. The anvil's formula already values items with multiple high level upgrades quite expensively. If a combination needs level 70, so be it. It will require some effort and crafting the upgrade should be the reward for it.
I think this option in particular should be part of the server.properties file Which could also add some regulation to the use of the anvil on multi-player servers.
III.- Stacking Repair Counts on Items.
Again, I think the way the anvil already values the levels of the enchants is fair enough. The price of 1st repair may already be high enough. I don't think an additional raise in price is needed.
After a while, Red Stone can actually start saturating your chests, with not much to do with it. Unlike most minerals, you can't even group 9 redstone dust into a 1 block either (which would be another suggestion). Most minerals can be sold to NPCs already (from Coal to Diamonds), except Red Stone Dust.
Coal 16-23:1
Iron 8-9:1
Gold 8-9:1
Diamond 4-5:1
The Priest is the NPC villager with the least buying offers (just gold). And he sells redstone dust already. I suggest he should also buy redstone dust at stacks similar to Coal (16-23:1)?
0
I was (again) looking at why we got so few mobs when the view-distance is lower than 10 on the server, and why it hasn't been fixed yet.
I stumbled upon the mob cap formula, according to the wiki:
And the constants are:
So I plugged in the data and this is what I get:
Note: I'm not sure if the constant is also a hard-cap, or if it can go over the constant.
Does this information look correct? or Is there some other issue at hand?
Why do we even have this mob cap formula? It seems most people would rather have view-distance and mob caps untied from each other.
1
The main idea is to have to "Work" a little to get the information on F3, then the server admin can turn debug info off, or have it off by default in a future patch.
We've had F3 as a tool for so long, it's become part of the gameplay, that probably was not the intended design.
0
The game always lacked ways for finding friends in a multiplayer game. And no easy way to bookmark an area. So here are different ideas I've had, and you guys can discuss which ones you like and don't like.
* New Item: GPS. This would keep the F3 functionality, but at least you have to work and craft the item to get it. Would be interesting if the GPS only worked on the surface.
* New Item: Whistle or Horn. You can craft this item and use it to alert nearby players. They would use the audible range and stereo sound to locate where you are. Maybe have both items and one has more range than the other.
* Better Maps
- The maps could show coordinates whilst using it. Note that maps in real life do have coordinates.
- Combining a map with any color Dye, adds a dot where you are standing on the map. Note you can do this on your inventory 2x2 crafting area.. eg: Map + Ink Sac, would add a black dot on the map, where you stand.
0
For example the maps could have coordinates (like they do in real life) or there could be a GPS item that does the same job, but needs to be crafted.
http://www.minecraftforum.net/forums/minecraft-discussion/discussion/2165905-reduceddebuginfo-true-and-coordinate-alternatives
0
The game always lacked ways for finding friends in a multiplayer game. And no easy way to bookmark an area. So here are different ideas I've had, and you guys can discuss which ones you like and don't like.
* New Item: GPS. This would keep the F3 functionality, but at least you have to work and craft the item to get it. Would be interesting if the GPS only worked on the surface.
* New Item: Whistle or Horn. You can craft this item and use it to alert nearby players. They would use the audible range and stereo sound to locate where you are. Maybe have both items and one has more range than the other.
* Better Maps
- The maps could show coords whilst using it. Note maps in real life do have coordinates.
- Combining a map with any color Dye, adds a dot where you are standing on the map. Note you can do this on your inventory 2x2 crafting area.. eg: Map + Ink Sac, would add a black dot on the map, where you stand.
0
I have a square pen with 10x10 fence, and roughly around 20 cows. I wouldn't say that is overfilled. Not even close to overfilled. Cows just push each other until they clip out.
If I put them into a 10x10x2 pit, they push into the wall until they suffocate. I think it's the same "clipping" problem.
Entities like cows should never clip into walls/fences to begin with, because once they are in, they will just try to auto-fix by going out in any direction. I think it's possible the entities are moving before the chunk is fully rendered? In that case it would be better to restrict movement until the chunk (and the 8 adjacent ones) are rendered.
PS: This happens on a single player world.
0
But this seems to hit bug #2536 (View distance affects mob spawning)
I really don't understand the principle behind the bug, as 8 chunks is the point where mobs should despawn immediately. AFAIK mob start spawning 24 blocks away from you (16 for mob spawners), that's roughly 2 chunks! And the code to despawn them (randomly) starts at 32m, which would be anything beyond the 2 chunks.
So the way I see it, except for the despawn immediately functionality, Any view-distance of 3 or greater, should be enough for the mob spawning to work.
If anything, the conditions for making them go away (despawn) are less. AFAIK, when chunks are unloaded everything is kept as it was. Like when you leave the nether and come back. The mobs should be in the same place. Or when you teleport to a very far distance, and then come back. Those mobs are kept as well.
But like I said, I really don't understand the principle behind the bug. The purpose of this thread is to raise awareness on it, and thus finally get it fixed. And maybe understand a little bit more on why it happens.
The curious thing is, when map was just recently generated, we had a lot of mobs the first few nights. But now I can go exploring at night without putting a single light source, and not have to worry much about mobs. The lack of mobs has already been tested many times by different people tracking this bug (and it's duplicates) so no need to go over that part.
0
I tried both igniting it myself or letting the Ghast do it, and it will always set on fire for a few seconds.
It would be interesting to have 1 block type in the game, apt for construction, that is 100% flame retardant. Especially for the nether.
I've built various bridges and walkways on the nether counting on this, only to find out any form of cobble/stone would have been better/easier. And stone is actually easier to see in the Nether.
0
Even if you hear the hissing and die anyway, I think it's more fun that way. It reminds me when I played Wolf:ET, the panzerfaust made distinct charging noise that really didn't give you much time to react to. So most of the times: "It's the sound of inevitability, that is the sound of your death".
0
I.- Browsers:
* Internet Explorer (go to Windows Update)
* Firefox (go to: click the firefox button and go to Help, About Firefox. Or visit the firefox website)
* Chrome (go to: click About Google Chrome on the menu. Or visiit the google chrome website)
II.- Java (Oracle/Sun):
Go to Java.com and click the "Do I have Java?" link.
Remember that if you have a 64-Bit OS, you will need to update both 32-bit and 64bit manually. AFAIK the automatic update feature does not work for the 64-Bit java installation. So it's possible your 32-Bit has been updated while the 64-Bit has fallen behind.
You might be able to use the "Internet Explorer (64-Bit)" shortcut on your system, and redo the test at java.com (haven't tested this)
III.- Flash:
You can check your flash installation here:
http://www.adobe.com...re/flash/about/
Note, Internet Explorer and other browsers use different types of plugins, thus different updates. Remember to check all the browsers that you use.
IV.- Go to Windows Update and check your antivirus software, to get the rest of the updates.
0
* Chunk Cache: This should be the minimum of both. Currently this seems to be regulated by the server alone. But if the client is using a lower distance than the server, it still loads the other chunks like the OP stated. Maybe the intent was for single player games to generate the correct amount of "life" around the player (generation of mobs, growth of plants, etc)
But for multiplayer scenarios, generation is happening on the server anyway, the client doesn't need to know there is a cow 3 chunks further than his view distance, the information can be sent if the player gets closer to the cow.
* Fog effect: The fog can gracefully hide the loading of chunks, so that they load just beyond the fog, and you don't see the chunks popup right before your eyes. But the settings on the client have no automatic relationship with the server.
Use the "far" on the client and a server with the lowest view distance, and you will see a whole lot of nothingness. The fog could easily cover that excess nothing
I think the fog should also be a minimum of both. So if you are lower than the server, it will use your fog setting. and if the server is lower than you, it will use the server's fog setting. This could be a 5th option on the client's render distance settings.
It could either match it exactly and the world would render just beyond the fog, so you will never see it popup. Or it could be +1 for those who don't want to miss anything. But anything beyond that loaded chunk is nothing, and might as well be fog.
Right now you could lower the render distance until you achieve the effect, but the jumps are rather big, especially on the higher settings. So you can't really fine tune to match the server.
0
Has anybody tried this with Amazon's micro instance?
-Xincgc
Enable the incremental garbage collector. The incremental garbage collector, which is off by default, will eliminate occasional garbage-collection pauses during program execution. However, it can lead to a roughly 10% decrease in overall GC performance.
This could help "avoid" long bursts of GC, which could cause throttling by Amazon, thus being a good thing.
OR
It could cause more overall CPU usage in total, which could cause more throttling by Amazon, and thus be bad.
0
I.- Repairing Un-enchanted Tools:
Currently there is no reason to do this on an anvil. It's actually A LOT worse than using the old repair method using the Inventory. I think this should be entirely the opposite.
There should be some benefit to using an anvil to repair un-enchanted tools compared to using the old method via the inventory. Using an anvil requires more effort in total, and thus you should be rewarded for your investment. In Comparison: You need a lot of iron to build the anvil, the Anvil wears down, and you have to move to the location of the anvil.
What could change? (for un-enchanted items)
* The resulting tool should not stack up a repair count on it. It should result like the inventory repair.
* Repairs should require no XP, the anvil still spends some of it's uses in exchange for a "better" repair, like:
* Better % boost for normal repairs. From the current +10% via the inventory to for example +20%
* Lower costs when using raw materials. It seems the anvil doesn't distinguish between a shovel and a chest piece. So right now repairing a shovel requires more raw materials than making a new one. The repair should consider the amount of raw materials used in the original recipe.
I think requiring 75% (and rounded up) of the original raw material should be enough for a full repair from any durability level. Which would look something like this:
Boots 4 * .75 = 3
Helmet 5 * .75 = 3.75 => 4
Leggings 7 * .75 = 5.25 => 6
Chest-plates 8 * .75 = 6
All Tools end up requiring the same materials as the original recipe, save the sticks.
Smaller repairs would require the corresponding fraction.
In Comparison, You can in theory:
1) Use an item up to the last point of durability.
2) Make a new one for the purpose of usage and repair of the old one.
3) Use it until its durability is 90% or less
4) Repair it with the other item using the inventory repair interface
5) You'll get +10% free durability on the repair, meaning that if you do it at exactly 90% the item will go back to 100% regardless of what is left on the old one.
The table above may yield slightly more than 10% (depending on the item) but I think that's the reward you should get from using the anvil on unenchanted items. Otherwise the anvil would be completely useless for those type of items.
II.- Level Cap on repairs, eg: "Too Expensive"
This removes freedom from the a game that's supposed to be a sandbox. Gaining levels is slower and slower the higher you go, and I think the effort required should be fair enough for the bigger anvil upgrades. The anvil's formula already values items with multiple high level upgrades quite expensively. If a combination needs level 70, so be it. It will require some effort and crafting the upgrade should be the reward for it.
I think this option in particular should be part of the server.properties file Which could also add some regulation to the use of the anvil on multi-player servers.
III.- Stacking Repair Counts on Items.
Again, I think the way the anvil already values the levels of the enchants is fair enough. The price of 1st repair may already be high enough. I don't think an additional raise in price is needed.
0
Coal 16-23:1
Iron 8-9:1
Gold 8-9:1
Diamond 4-5:1
The Priest is the NPC villager with the least buying offers (just gold). And he sells redstone dust already. I suggest he should also buy redstone dust at stacks similar to Coal (16-23:1)?
0
"Any sufficiently advanced technology is indistinguishable from magic."
http://en.wikipedia.org/wiki/Clarke's_three_laws
Monthy Python - The Holy Grail:
We Found a Witch:
Quotes:
--We have found a witch. May we burn her?
--How do you know she is a witch?
--She looks like one. (-.-)Zzz