If anything I'd say this is either a feature request, or a bug if the sound for mushrooms does exist.
I don't think it's a personal preference Paul, Minecraft has typically been rather good with their sounds, and Giant Mushroom blocks sounding like Wood isn't very good, and could be something that has been overlooked as Giant Mushrooms were added rather quickly.
@Carey
You could not make a client walk on water via only server side, the client would have to know about this, otherwise the client will assume you have fallen through the water block and your position will update based on the clients presumed physics of the block, only to be corrected by the server. That is exactly what happens when you're standing in an unloaded chunk, the client begins to fall because there is no block below you, the server corrects the client telling it that there is infact a block there and it should stay where it was, causing a jerking falling effect to occur.
So! For something such as walking on water, the client would have to know that the water is now walk-able, and that is why Mojang added a new packet for Plugin/Mod Channels, to inform a client about these sort of changes, Mojang have already reserved the MC| channel for minecraft, and it could so be used to update sound association information for the standard minecraft client.
What I think on this issue is that all standard sounds, that is walking, block breaking and placing, and simple things like punching a wall, should all be played immediately by the client without server instigation. Sounds that should be decided by the server are sounds by other players, such as being able to hear other plays cutting down a tree or building their house, or the sounds of mobs, which don't have any immediate visual cues that make it look like the sound is laggy.
The client could also play sounds like a tool breaking immediately when it breaks, because the client knows when it wears out by calculating it's own damage value, I've seen this done both correctly and incorrectly, such as a tool having more durability server side than client side, so the tool breaks and then respawns with low health, right back in your hotbar. These are all similar concepts to dead reckoning, the client predicting the server outcome to decrease the perception of latency, and now that the client and server are completely separate, even in single player. This is more important than ever.
Yes, These sounds that are now server sided, should be put back on client side, and the server should be given the option to change them as part of the Mod API. But I don't think that something like placing a block should be 100% server side. It can only cause annoying game play, and you'll never get it working correctly, not even on a LAN.
Yes, and the hover issue is a client/server sync bug it seems, the server knows that the item is under the block but the client renders it on top anyway.
I mostly notice this in Jungles when cutting trees, with all the leaves around, a lot of items fall under the leaves.
Could be fixed by making the items perceive all blocks to be opaque and solid.
Makes the Nether terrifying to be honest, the thought of walking along an edge surrounded by lava, only to be catapulted into it by a soaring arrow.
It's going to be a long time before I go back to the nether after 1.4, that's for certain.
That said, I don't think this is a bug, it'd be difficult to randomly cause a non-wither skeleton to spawn by accident.
I notice this with any moving entity in Multiplayer servers, from what I gather, sometimes the client gets confused about where the entity actually is, and because Minecraft's movement data is relative not absolute ( Unless teleporting or moving more than 4, i think it's 4; blocks in a single movement ). When this occurs, you can either try get the mob to move really fast, in the case of a player, tell them to run around and jump lots for your own sanity so they stop glitching in the ground, as for actual mobs. It's a bit more difficult to fix it, one solution is to walk away and come back, or to pick them up with a minecart.
I realise that there is no difference between multiplayer and the integrated single player now, but it does seem to occur more often in SMP, which I'm assuming is due to some sort of latency.
Solution?
Client assumes the mob is actually on top of the block using it's AABB, or the server periodically sends Teleport packets refreshing the client of the entities actual position. Maybe only within a few chunks of you do the entities have an update, this will reduce some of the bandwidth incurred by the extra packets.
Yes Enrique, I think you're right on there.
By removing the 'extra block's hitbox, and expanding the 'source block's hitbox to include both blocks, ( Top of the door, piston head etc ), it would certainly fix this issue.
That way the active block would be the one with the hit box and the other would be there for purely visual reasons.
Hitboxes I believe are typically floats from 0-1, 1 being a full block, I'm not certain if a hitbox can expand more than 1m-cube, but I don't see why not.
@Anon, Sand and Gravel never burn, we're talking about the Entities, not the items here. Sand and Gravel ( and any future falling blocks similar ) should not show fire as they do not burn. If it doesn't combust in Block form, it shouldn't show fire animation in entity form.
He said to override the isBurning method in EntityFallingSand, That only affects Sand, not every block.
I don't see anywhere that implies that all blocks should not burn.
Yes, me too. It's been a quirk I've noticed for a long time but never thought of actually reporting it.
Now that there is Mojira, I've actually been more aware of bugs in MC, such as last night when a player was floating above the bed.
But I'm no so good with the creating an issue and such
Then I guess the MobSpawner needs amending, this would all go in to the MC API imo.
If you go home, grab some sand, and put it on a fire, tell me if it burns. If it burns I'll eat my words, otherwise I stand by saying that sand doesn't burn as a block, and it shouldn't burn as an entity.
Why make an exception?
I think the title answers that for you, it's sand, sand isn't flammable. Walking Dead, Corpses and people are flammable, but not sand.
Edit: It's marked as resolved, DinnerBone approves that it's a bug, case closed I think.
Oh thank goodness, as this caused massive issues with mods also, every single tile entity would randomly not have any information associated it, NPEs across the board. It seems this may have been the issue, and there I was looking at the mod apis for bugs, never thought it to be a vanilla issue.
I'm not quite sure how the arrows were attached, but you could probably glScale the inverse of the scale used on the rest of the mob when rendering the arrow. But as I'm not aware of how it was implemented I can't suggest anything, We'll just have to wait and see if Mojang comes up with something.
Each entity has it's own instance, id's are irrelevant. You can scale differently depending on the size of the slime, which is just a datavalue thing I believe anyway, as you can spawn really large slimes with plugins/mob spawners/mods/other spawny thingies.
On collision it should raytrace itself to one of the boxes of the mob, and then solve it's location on the face it hit, it should then child itself to that box with it's rotation point and offset set accordingly to it's collision point and travelling vector at the time of impact. That said the raytrace is probably not required as all the collisions in game use AABB anyway.
Edit: It already works on players so all this code is already implemented, It's probably just a pain to get it rendering correctly once the arrow becomes a child of the entities model, due to said scaling.
After some watching of mobs that do this, It seems to occur after they collide with a wall, can anyone verify? It seems like when they hit a wall for some reason they drop in to the ground on occasion to the block below them, causing glitchy appearance
![NeverCast [Joshua Lloyd]](../../../data/avatars/users/10122.svg){kind=small}
If anything I'd say this is either a feature request, or a bug if the sound for mushrooms does exist.
I don't think it's a personal preference Paul, Minecraft has typically been rather good with their sounds, and Giant Mushroom blocks sounding like Wood isn't very good, and could be something that has been overlooked as Giant Mushrooms were added rather quickly.
@Carey
You could not make a client walk on water via only server side, the client would have to know about this, otherwise the client will assume you have fallen through the water block and your position will update based on the clients presumed physics of the block, only to be corrected by the server. That is exactly what happens when you're standing in an unloaded chunk, the client begins to fall because there is no block below you, the server corrects the client telling it that there is infact a block there and it should stay where it was, causing a jerking falling effect to occur.
So! For something such as walking on water, the client would have to know that the water is now walk-able, and that is why Mojang added a new packet for Plugin/Mod Channels, to inform a client about these sort of changes, Mojang have already reserved the MC| channel for minecraft, and it could so be used to update sound association information for the standard minecraft client.
What I think on this issue is that all standard sounds, that is walking, block breaking and placing, and simple things like punching a wall, should all be played immediately by the client without server instigation. Sounds that should be decided by the server are sounds by other players, such as being able to hear other plays cutting down a tree or building their house, or the sounds of mobs, which don't have any immediate visual cues that make it look like the sound is laggy.
The client could also play sounds like a tool breaking immediately when it breaks, because the client knows when it wears out by calculating it's own damage value, I've seen this done both correctly and incorrectly, such as a tool having more durability server side than client side, so the tool breaks and then respawns with low health, right back in your hotbar. These are all similar concepts to dead reckoning, the client predicting the server outcome to decrease the perception of latency, and now that the client and server are completely separate, even in single player. This is more important than ever.
Yes, These sounds that are now server sided, should be put back on client side, and the server should be given the option to change them as part of the Mod API. But I don't think that something like placing a block should be 100% server side. It can only cause annoying game play, and you'll never get it working correctly, not even on a LAN.
Yes, and the hover issue is a client/server sync bug it seems, the server knows that the item is under the block but the client renders it on top anyway.
I mostly notice this in Jungles when cutting trees, with all the leaves around, a lot of items fall under the leaves.
Could be fixed by making the items perceive all blocks to be opaque and solid.
Makes the Nether terrifying to be honest, the thought of walking along an edge surrounded by lava, only to be catapulted into it by a soaring arrow.
It's going to be a long time before I go back to the nether after 1.4, that's for certain.
That said, I don't think this is a bug, it'd be difficult to randomly cause a non-wither skeleton to spawn by accident.
I notice this with any moving entity in Multiplayer servers, from what I gather, sometimes the client gets confused about where the entity actually is, and because Minecraft's movement data is relative not absolute ( Unless teleporting or moving more than 4, i think it's 4; blocks in a single movement ). When this occurs, you can either try get the mob to move really fast, in the case of a player, tell them to run around and jump lots for your own sanity so they stop glitching in the ground, as for actual mobs. It's a bit more difficult to fix it, one solution is to walk away and come back, or to pick them up with a minecart.
I realise that there is no difference between multiplayer and the integrated single player now, but it does seem to occur more often in SMP, which I'm assuming is due to some sort of latency.
Solution?
Client assumes the mob is actually on top of the block using it's AABB, or the server periodically sends Teleport packets refreshing the client of the entities actual position. Maybe only within a few chunks of you do the entities have an update, this will reduce some of the bandwidth incurred by the extra packets.
Does this still happen with Smooth Lighting turned off?
Could be an AO bug.
Duplicate bug of
MC-119perhaps.Yes Enrique, I think you're right on there.
By removing the 'extra block's hitbox, and expanding the 'source block's hitbox to include both blocks, ( Top of the door, piston head etc ), it would certainly fix this issue.
That way the active block would be the one with the hit box and the other would be there for purely visual reasons.
Hitboxes I believe are typically floats from 0-1, 1 being a full block, I'm not certain if a hitbox can expand more than 1m-cube, but I don't see why not.
Thanks Jens,
You're wonderful!
Iron Golems have always been able to hold out roses, just check the wiki. In no way does this seem like a bug.
Woah, all the comments all at once.
@Anon, Sand and Gravel never burn, we're talking about the Entities, not the items here. Sand and Gravel ( and any future falling blocks similar ) should not show fire as they do not burn. If it doesn't combust in Block form, it shouldn't show fire animation in entity form.
He said to override the isBurning method in EntityFallingSand, That only affects Sand, not every block.
I don't see anywhere that implies that all blocks should not burn.
^ Don't forget to back up your saves folder if you want to keep your worlds
Thanks Charlie.
Yes, me too. It's been a quirk I've noticed for a long time but never thought of actually reporting it.
Now that there is Mojira, I've actually been more aware of bugs in MC, such as last night when a player was floating above the bed.
But I'm no so good with the creating an issue and such
Then I guess the MobSpawner needs amending, this would all go in to the MC API imo.
If you go home, grab some sand, and put it on a fire, tell me if it burns. If it burns I'll eat my words, otherwise I stand by saying that sand doesn't burn as a block, and it shouldn't burn as an entity.
Why make an exception?
I think the title answers that for you, it's sand, sand isn't flammable. Walking Dead, Corpses and people are flammable, but not sand.
Edit: It's marked as resolved, DinnerBone approves that it's a bug, case closed I think.
Now you're trolling, this issue is closed, and so is this conversation.
Oh thank goodness, as this caused massive issues with mods also, every single tile entity would randomly not have any information associated it, NPEs across the board. It seems this may have been the issue, and there I was looking at the mod apis for bugs, never thought it to be a vanilla issue.
Thanks again Jeb.
Probably because the arrow was attached to the model, @Meta.
But because some of the models are scaled, the arrow would also be scaled.
I'm not quite sure how the arrows were attached, but you could probably glScale the inverse of the scale used on the rest of the mob when rendering the arrow. But as I'm not aware of how it was implemented I can't suggest anything, We'll just have to wait and see if Mojang comes up with something.
Each entity has it's own instance, id's are irrelevant. You can scale differently depending on the size of the slime, which is just a datavalue thing I believe anyway, as you can spawn really large slimes with plugins/mob spawners/mods/other spawny thingies.
On collision it should raytrace itself to one of the boxes of the mob, and then solve it's location on the face it hit, it should then child itself to that box with it's rotation point and offset set accordingly to it's collision point and travelling vector at the time of impact. That said the raytrace is probably not required as all the collisions in game use AABB anyway.
Edit: It already works on players so all this code is already implemented, It's probably just a pain to get it rendering correctly once the arrow becomes a child of the entities model, due to said scaling.
After some watching of mobs that do this, It seems to occur after they collide with a wall, can anyone verify? It seems like when they hit a wall for some reason they drop in to the ground on occasion to the block below them, causing glitchy appearance