Sycholic
- sycholic
- sycholic
- America/New_York
- Yes
- No
no enchanted effect visible. seconded
Entities fall thru block after passing over blocksless then half in height.Entities fall thru block after passing over blocks > 1/8th thickness < 1/2 thickness
Entities (skeletons, chickens etc) fall thru the block they are walking to after walking off blocks less then 1/2 in height but greater then 1/8th thick snow block. Could not check anything between the size of 1 layer of snow to half half a block did not feel like server hacking the thickness.
Repo:
Fence in an non snow area. place a repeater down. spawn some entities. E's should fall after walking over the repeater. Go to a snowy area, make some area clear of snow, and repeat. E's should not be falling thru the blocks in this case. Further testing would be placing a double layer of snow and a triple layer of snow testing out the heights between 1/8 and 1/2 of a block in height.
Im going to try and see if sunken fences how they kick up whatwalksovertop of them might cause the same thing as well... will update issue as more testing comes thru.Entities (skeletons, chickens etc) fall thru the block they are walking to after walking off blocks less then 1/2 in height but greater then 1/8th thick snow block. Could not check anything between the size of 1 layer of snow to half half a block did not feel like server hacking the thickness.
Repo:
Fence in an non snow area. place a repeater down. spawn some entities. E's should fall after walking over the repeater. Go to a snowy area, make some area clear of snow, and repeat. E's should not be falling thru the blocks in this case. Further testing would be placing a double layer of snow and a triple layer of snow testing out the heights between 1/8 and 1/2 of a block in height.Further testing showed sticking a fence in the ground and walking over it does cause this also. Having just a single layer of snow next to the fence or repeater also stops this effectively.
this is where I noticed the snow stops this effect.
Entities (skeletons, chickens etc) fall thru the block they are walking to after walking off blocks less then 1/2 in height but greater then 1/8th thick snow block. Could not check anything between the size of 1 layer of snow to half half a block did not feel like server hacking the thickness.
Repo
:
Fence in an non snow area. place a repeater down. spawn some entities. E's should fall after walking over the repeater. Go to a snowy area, make some area clear of snow, and repeat. E's should not be falling thru the blocks in this case. Further testing would be placing a double layer of snow and a triple layer of snow testing out the heights between 1/8 and 1/2 of a block in height.Further testing showed sticking a fence in the ground and walking over it does cause this also. Having just a single layer of snow next to the fence or repeater also stops this effectively.
Entities (skeletons, chickens etc) fall thru the block they are walking to after walking off blocks less then 1/2 in height but greater then 1/8th thick snow block. Could not check anything between the size of 1 layer of snow to half half a block did not feel like server hacking the thickness.
[Repo]
- Fence in an non snowy area.
- Place a repeater or sink a fence post in the ground.
- Spawn some entities.
- E's should fall after walking over the repeater or a sunken fencepost.
E's should not be falling thru the blocks in this case. Further testing would be placing a double layer of snow and a triple layer of snow testing out the heights between 1/8 and 1/2 of a block in height.
Further testing showed sticking a fence in the ground and walking over it does cause this also. Having just a single layer of snow next to the fence or repeater also stops this effectively.
Me either... can we get some Enviroment details please? OS, Java ver, etc etc
actually I think it is working, it just doesnt happen for 'natural' villages' because Im running 1.5.1 right now and looking at about 30 zombies all running around a village farm I just created and they appeared instantly out of nowhere, but regardless maybe this is the cause for them not starting for a natural village siege to start.
btw this is a dup of what I reported... not the other way around. and still existing in 1.5.2
minecraft_server.1.8.exe 10.2mb still present error.
minecraft_server.1.8.jar 9.89mb different error present same source, GUI logger related[11:34:20] [Server Shutdown Thread/INFO]: Saving players
2014-09-11 11:34:20,654 ERROR Attempted to append to non-started appender ServerGuiConsole
Exception in thread "Server Shutdown Thread" org.apache.logging.log4j.core.appender.AppenderLoggingException:
Attempted to append to non-started appender ServerGuiConsole
at org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:89)
at org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:425)
at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:406)
at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:367)
at org.apache.logging.log4j.core.Logger.log(Logger.java:110)
at org.apache.logging.log4j.spi.AbstractLogger.info(AbstractLogger.java:1011)
at net.minecraft.server.MinecraftServer.r(SourceFile:377)
at pe.run(SourceFile:715)
F3+C Crash report
When viewing snow falling, appears white. But soon as it intersects with water as a background it turns to a shade of blue. I highly doubt this is intented as snow particles die when hitting water surfaces as it should. This happens for both static water and moving water. Even if the snowfall passing in front of ice, soon as it intersects with the blocks of water under the ice, it changes the tint.
When viewing snow falling, appears white. But soon as it intersects with water as a background it turns to a shade of blue. I highly doubt this is intented as snow particles die when hitting water surfaces as it should. So snow falling above the waterline would have no reason for a color change. This happens for both static water and moving water. Even if the snowfall passing in front of ice, soon as it intersects with the blocks of water under the ice, it changes the tint.
Apparently... the /deop command does not follow/check for removal of the entry for the player in ops.json by UUID. If you have multiple duplicate names in the ops.json file it will only just remove the first one it finds. This isnt a serious issue but it could be if you just happen to have a op that changes their name and then someone else takes it. as it will create two entries for the same name with different UUID's. This is also easily possible by a server going online and offline mode for testing as well... Main concern here is that the proper entry in the ops file is not removed.
Apparently... the /deop command does not follow/check for removal of the entry for the player in ops.json by UUID. If you have multiple duplicate names in the ops.json file it will only just remove the first one it finds. This isnt a serious issue but it could be if you just happen to have a op that changes their name and then someone else takes it. as it will create two entries for the same name with different UUID's. This is also easily possible by a server going online and offline mode for testing as well... Main concern here is that the proper entry in the ops file is not removed.
Granted that this might be a rare thing indeed but it is still a security issue since you are only 'name matching' for the first match that shows up.
Hostile monsters that normally would catch on fire in 'clear' sunny weather, still are attempting to catch on fire and burn in 'rain/stormy' weather. This starts with vanilla server 1.8.0 and happens with all versions after that so far Ive tested. Its easily noticeable by the constant 'fire/water sizzle effect sound' that you get when you put something on fire out with water. (like mobs swimming in sunlight) Thought maybe it was a client sync issue at first so re-logged also to verify it still happens. This does not happen in server/client 1.7.10 or older.
Looks like double high plant growth got broken. Take some grass use bone meal on it to grow it into a double block high grass. The top block will be missing completely at first I thought this was my texture pack causing this
only to find out its specific to 1.8.3. First elimated texture pack by using default, then started at vanilla 1.8 server and worked up.. Apparently starting with 1.8.3 vanilla it appears.Repo: plant normal plant that can grown to double high (eg. tall_grass) block, use bonemeal on it to make it grow into a double high block... result will end up with a single high block with the lower half texture of a double high block with the top half block missing.
Looks like double high plant growth got broken. Take some grass use bone meal on it to grow it into a double block high grass. The top block will be missing completely at first I thought this was my texture pack causing this. First elimated texture pack by using default, then started at vanilla 1.8.1 server and worked up.
Vanilla 1.8 correctly grows plants...
Repo: plant normal plant that can grown to double high (eg. tall_grass) block, use bonemeal on it to make it grow into a double high block... result will end up with a single high block with the lower half texture of a double high block with the top half block missing.
Looks like double high plant growth got broken. Take some grass use bone meal on it to grow it into a double block high grass. The top block will be missing completely at first I thought this was my texture pack causing this. First elimated texture pack by using default, then started at vanilla 1.8
.1server and worked up.Vanilla 1.8 correctly grows plants...
Repo: plant normal plant that can grown to double high (eg. tall_grass) block, use bonemeal on it to make it grow into a double high block... result will end up with a single high block with the lower half texture of a double high block with the top half block missing.
Looks like double high plant growth got broken. Take some grass use bone meal on it to grow it into a double block high grass. The top block will be missing completely at first I thought this was my texture pack causing this. First elimated texture pack by using default, then started at vanilla 1.8 server and worked up to 1.8.3
Vanilla 1.8 correctly grows plants...
Repo: plant normal plant that can grown to double high (eg. tall_grass) block, use bonemeal on it to make it grow into a double high block... result will end up with a single high block with the lower half texture of a double high block with the top half block missing.
Looks like double high plant growth got broken. Take some grass use bone meal on it to grow it into a double block high grass. The top block will be missing completely at first I thought this was my texture pack causing this. First elimated texture pack by using default, then started at vanilla 1.8 server and worked up to 1.8.3
Vanilla 1.8 correctly grows plants...
Repo: plant normal plant that can grown to double high (eg. tall_grass) block, use bonemeal on it to make it grow into a double high block... result will end up with a single high block with the lower half texture of a double high block
with the top half block missing.Looks like double high plant growth got broken. Take some grass use bone meal on it to grow it into a double block high grass. The top block will be missing completely at first I thought this was my texture pack causing this. First elimated texture pack by using default, then started at vanilla 1.8 server and worked up to 1.8.3
Vanilla 1.8 correctly grows plants...
Repo: plant normal plant that can grown to double high (eg. tall_grass) block, use bonemeal on it to make it grow into a double high block... result will end up with a single high block with the lower half texture of a double high block. The top half block missing completely and not generated in world.
Looks like double high plant growth got broken. Take some grass use bone meal on it to grow it into a double block high grass. The top block will be missing completely at first I thought this was my texture pack causing this. First elimated texture pack by using default, then started at vanilla 1.8 server and worked up to 1.8.3
Vanilla 1.8 correctly grows plants...
Repo: plant normal plant that can grown to double high (eg. tall
_grass) block, use bonemeal on it to make it grow into a double high block... result will end up with a single high block with the lower half texture of a double high block. The top half block missing completely and not generated in world.Looks like double high plant growth got broken. Take some grass use bone meal on it to grow it into a double block high grass. The top block will be missing completely at first I thought this was my texture pack causing this. First elimated texture pack by using default, then started at vanilla 1.8 server and worked up to 1.8.3
Vanilla 1.8 correctly grows plants...
Repo: plant normal plant that can grown to double high (eg. 175:2 double_plant aka double tallgrass ) block, use bonemeal on it to make it grow into a double high block... result will end up with a single high block with the lower half texture of a double high block. The top half block missing completely and not generated in world.
Seems that gravel physics is flaking out like how minecarts can sometimes and end up being pushed together as one object inside each other. Found this out by being in a old abandoned mine and broken some cobwebs only to find gravel fall and stack together and then keep on falling then break as it hits the ground under the cobwebs.
Very possible this is 'physics' related bug to same issues with minecarts that stack up physically together....
Repoduction: Any game mode: Place 2 cobwebs ontop of each other, place 2 or more gravel blocks above that. Break top cobweb block. Gravel will then fall and stack up together as one block and keep moving thru the last cobweb till hits the ground, then breaks to the ground as items to be picked up.
Gravel Stacks inside each other when falling in some cases, like minecart stacking that stack up...




















yeah I was just going to post this... its changing the texture of the piston base block's top for both sticky and normal piston bases. Not too serious of an issue but this would be possibly a hit on performance (esp with large piston builds) as there is no need to change the texture nor makes sense to.
enchantment not visible, seconded.
N Yan, check out
MC-1559thats my enviroment, unless someone asked otherwise that would be a good template to follow. Mainly OS, Java ver, and basic hardware info, exact game version (or in some cases server version) is what they are asking for.Can we get some screenshots? did you /save-all? Ive had issues with shutting down and the saving after unloading the world doesnt happen always. (but its hard to confirm for me because I still see messages saying it is.) Like is the chunk 'empty/corrupted'? or just basically what you made was like rolled back as it never existed in the first place.
I tried my best to repo could not repo. even with the fastest 3 tick loop (2 repeaters 1 inverting torch) the dispenser was firing away... I thought maybe at first the dispenser had a delay in activation between firing but guess this isnt the case either. any faster then 3 ticks and your torch burns out anyway (maybe the cause why?)
How many did you remove? and how big were they and what buffs so someone can repo this?
can you post your commands you are using please? they really should have a variable for who triggered the event not who's closest or even have a possible @r in one of your blocks. Want to try and repo this. Are all your blocks in a central locale and then return blocks back from where they take you? or they just randomly all over? Also if you using a button or redstone see if its being stuck 'on' after using the teleporter... if so then its likely related to
MC-638dont think this qualifies as a bug its just how the generator made it, example desert temples underground or my fav a jungle temple hanging mid air over a massive sinkhole. Ive seen this always since Ive been playing MC. Are there static models of these structures? I was always under the impression its just basically quasi-random placement of sub-chunks following a 'life' style generator.
On retracting.... it switches the top graphic of the piston base block to the top of the piston top either type of piston.
Yes duplicate of https://mojang.atlassian.net/browse/MC-136
btw that work around is relative to the draw distance the server is set up for it can be low as 4 or high as 16chunks.
Have someone watch you from the side and see if you look like your falling or turn/flash 'blackish' like how entities do.
you cant even do that in chat either as well. you cant use alt codes in chat so guessing book/signs follow same rules.
Actually if you really think about it, if you dropped sand in lava it wouldnt put it out at first it would just displace it and it would still melt the outer surface in this case a cube shape so the flames does kind of make sense.. but I can see D's point is it really a bug? because I think blocks turning black when falling is a bug then. Should it not just look like a blurred/moving texture?
What is your server draw distance on? Server.Properties:view-distance= ? Is it possible bad chunks? Have you tried moving your world dirs and regnerating a new world to see if it keeps happening?
Also you have listed both 32 and 64 bit java installed.... which version are you using for MC?
more to the point.. Have you just renamed your /nether folder and let the server regen it again with the same seed # could just be a very unique seed not really a bug. you can control the terrain gen by placing the seed number in server.properties after copying it with /seed in the nether.
or pass on the seed here we can try and dup by try doing a terraform with the same seed and see if it happens for us as well.
but as others have said there is gravel in the nether normally. but I think its typically on the range of like 3% of the blocks or something redicilously low.
also here is where I noticed that the single layer of snow (1/8th thick) definitely stops them from falling thru.
not a bug that is how MC is and has been.
Duplicate
MC-515pls search first before opening new tickets. Also vote and comment on 515 so its reopened as it was 'supposedly' fixed.Duplicate
MC-515pls search first before opening new tickets. Also vote and comment onMC-515so its reopened as it was 'supposedly' fixed.Duplicate
MC-515pls search first before opening new tickets. Also vote and comment on 515 so its reopened as it was 'supposedly' fixed.Duplicate
MC-515pls search first before opening new tickets. Also vote and comment onMC-515so its reopened as it was 'supposedly' fixed.Reports still comming in from 1.4.3-pre this still exists reopen pls.
This happened to me a few times infact on multiple different seeds I think it might be intentional to keep from getting agro from ED upon spawning and give a person time to rez. I know in 1.3.2 sometimes you would spawn in the end you were getting attacked by ED before you could even move because nothing was rezzed yet. (imho)
True, but regardless intentional or not its bad modeling/rendering and in large amounts leads to severe performance and even graphical glitches... good example go play 'Second Life'. But anyhoot there is something wrong with end result. Either the hinge point is too low or as you said one of the polygon's should be bigger then the other.. top or bottom shouldnt matter long as they arent trying to occupy the exact same plane of existence.
Whats even more odd is this still has yet to be confirmed by someone (officially)..... and yes I_L thats how I actually stumbled upon it when trying to make a custom texture for chests.
Xavier you wont see it on the stock textures as the color values are the same, but its still happening. easy way to see it clearly is just make a white lid and a black base. (just never posted the photo with that when I first found it) only showing how the model itself is not correct.. simple change in the model will fix this for all. And if someone can find the source code for it, I'll fix it myself. I just dont have the time to search for it. (hell wish RL paid me to do this stuff lulz)
Oddly enough its still not confirmed.
if hes refering to anything could it be the bug when you place a block at a specific distance at the edge of your placeable distance and you follow up with another block touching it and they both go. Poof... Ive also had this spawn items magically (example spawn beacons glitch out stacks of xp potions o.O) Ive tried many times to capture it happing but its one of them bugs (atleast for me) that happens more when you arent trying then trying to repo.
Add: http://www.youtube.com/watch?v=rd9DECFqwNk nice video of the bug Im atleast refering to maybe Eir is as well.
confirmed. 1.5.2 both vanilla and bukkit server no plugins SP/MP any game mode
http://www.youtube.com/watch?v=rd9DECFqwNk
Also now it also drops items from them glitching out on the placement. Example Ive had a random # stack drop of xp potions after the placed block dissapeared (no I cant say which block as its kinda a serious exploit in the game mechanics).
Actually you could change the size of the lid, just when you render it ignore the one layer of pixels (thats overlapping ie. dont render it) or just do the simple solution. Move the lid up one layer of pixels.... which Ive suggested since the start of this. You also could just make the lid have a indent towards the center of the lid and then if you rendered the texture as is, it wouldnt fight as it would be inside the lid. There is plenty of ways to do this funny how no-one on the dev team hasnt still flat out ACK'd that is actually an existing bug instead of it just being 'community consensus'
btw you dont use the --nogui option its just 'nogui'
eg. java -d64 -Xms1024M -Xmx1024M -jar minecraft_server.jar nogui
also when loaded properly only shows this.. as of 1.8.exe server file.
2014-09-11 11:43:55,200 ERROR Error processing element Queue: CLASS_NOT_FOUND
2014-09-11 11:43:55,231 ERROR Unable to locate appender ServerGuiConsole for logger
Still existing even in 1.8. updated affected versions to reflect this.
Screenshot of issue still unresolved as of 1.8
Here is a very simple resource pack for testing and verification without having to jump thru hoops to prove its still there. I cant remember how chest textures and resources were arranged for chests for older versions this will work for 1.8 just a simple texture mod nothing fancy but makes it very simple to see the problem that is normally just not 'visible'
Single player client mode? Multiplayer? Running vanilla server? What OS and Java is this running under? definitely need more information....
crash log would be really nice as well...
Only happens for me when chunk rendering is pushed past 12 regardless of memory settings or VBO on or off. Does not happen for me long as chuck distance is <= 12. Happens in both Single, and multiplayer as of 1.8 never had issues with this kind of graphics garbage from 1.7.x or older. Also -d64 option did nothing... nor did using uselessly 2gig of xmx/xms ram settings. The visual glitches for me are oddly not ALL around. its only on the leading edge of unloaded chunks to the east and west, and moving to them doesnt move it back either. Also moving north and south is fine and loads properly... Btw everyone testing on a 'server' should increase the server render distance, only a 'local' running game can render 12+ typically.
https://help.mojang.com/customer/portal/articles/325948-minecraft-system-requirements Java 6 r45 at the least. If thats not correct anymore then Mojang needs to update their help and min. requirement info.
http://minecraft.gamepedia.com/Tutorials/Setting_up_a_server Also likely your problem is that you are not using your 'internal' IP address of the server. (typically like 10.0.0.x or 192.168.x.x)
Mojang says Java6 r45 is the minimum if this is not correct anymore then this also needs to be updated.
https://help.mojang.com/customer/portal/articles/325948-minecraft-system-requirements
Well likely the issue of why its never been fixed is the fact that both the lid and the case has that trim of brown around where the overlapping is occuring and they just are not seeing it for that fact (same colors but the Z fight still happens just not visibly) Im going to try and make up a fix since its clear this is 'considered' not important, maybe they'll implement it if someone else does the leg work _. j/k I love MC and I have zero problems with mojang infact I never have or had issues with MC other then lil non serious glitches.
confirmed 1.8 release/final. Also this is a duplicate of
MC-64440. Note its labeled other way around dunno why as 64440 is a dup of this one, as it was filed before this one.[22:33:31] [Client thread/INFO]: LWJGL Version: 2.9.1
[22:33:31] [Client thread/INFO]: Reloading ResourceManager: Default
[22:33:32] [Sound Library Loader/INFO]: Starting up SoundSystem...
[22:33:32] [Client thread/WARN]: File minecraft:sounds/mob/ghast/fireball.ogg does not exist, cannot add it to event minecraft:item.fireCharge.use
[22:33:33] [Thread-6/INFO]: Initializing LWJGL OpenAL
[22:33:33] [Thread-6/INFO]: (The LWJGL binding of OpenAL. For more information, see http://www.lwjgl.org)
[22:33:33] [Thread-6/INFO]: OpenAL initialized.
[22:33:33] [Sound Library Loader/INFO]: Sound engine started
[22:33:35] [Client thread/INFO]: Created: 512x512 textures-atlas
[22:48:13] [Client thread/INFO]: Connecting to localhost, 25565
btw other way around
MC-64484duplicates this as this one was filed earlier thenMC-64484This is likely a hardware issue. Cant repo. Infact for me it only does it when im sneaking, and going forward left. ie. Shift+WA. and then I get a quite annoying beep at me. (happens in any program) again I think that is a hardware/OS issue. Not MC specifically at fault.
http://minecraft.gamepedia.com/Damage#Damage_inflicted_by_mobs
Dont see any fire killing them for me in both single stand alone, or multi player servers in MC1.8. Infact takes 3 direct strikes on a pigman to kill one, 2 for a blaze. But neither died from a fire dot it was the initial direct dmg far as I could tell.
How I tried repo it: dig a hole 2 blocks deep put a block above said hole 1 block leaving a opening to watch the mobs. /summon LightningBolt x y z and spawned the bolt to directly hit the mob in the hole. First even had a 1 block level of water in it to hear if the water would trigger the fire quench sound didnt hear it then removed the water and still no fire. Even if the lightning set the ground on fire none would get burned either...
Could it just be a simple random double strike? I tried testing it and it seems if any when I do hear a rapid dmg given its definitely at random times not consistent. I mean lightning does strike multiple times sometimes in the same bolt. And the best I can repeatedly try and repo this is about 1 in 20ish strikes. typical mobs are only taking 4 strikes to die (thats 20 hearts) with the occasional 3rd hit this was done in water so there is no fire dot possible to conflict with the dmg given.
Sonic you are reporting that fire is the cause of the damage because you are refering to 'fire resistance mobs/players'. Again I cant repo because Ive had pigman standing in 'fire' from lightning when it hits the ground. Only damge I see is 'electric' damage and its not a bug they allways have been killable by lightning, nothing is immune nor ever was, short of a player on create/god mode, or a pig/villager because that creates a zombie pigman/witch.
http://minecraft.gamepedia.com/Lightning
Quote: Entities struck by lightning or standing near a lightning strike are dealt 5 points of damage (except pigs and villagers), NOT including damage from the fire.
Yeah sonic thats why I didnt get why someone jumped to flag the older ticket to this one, because the info is just the same. I know its not a critical thing but for me, I just prefer to give credit to the proper person who takes the time to infact report bugs.
Still happens for 1.7.10 already seen it. Asking someone to update a 2+ year old ticket is not acceptable either. I personally have had blocks broken and then still are physically there to the server but client side they are gone and vise versa. I have not see it on 1.8.x nor have I looked for it I only drops my comment because I was on a the watch list when this was closed. I'll do more forceful testing to get blocks to glitch out possibly this weekend also see if it still happens with 1.8.x but it definitely exists for all versions up to 1.8 And as for a resolution, incomplete is not acceptable either as no fix was created for this problem so there is no resolution, not incomplete or partial but 'none' or 'not applicable'. Passing the buck like that is not cool either, seriously.
okay sweet I'll dig some more into it and get back to yas. Sorry if I was short with yas also, everyone around me getting their heads bit off today with me _
Btw cant add any 1.7.x versions. The problem seems to stop @ 1.8 as destroy and placement block distances changes from 1.7.10 to 1.8. Not sure if this 'solved' the problem or just started to 'mask' it, as I cant repo it on 1.8. or 1.8.1-pre2 the distance from placing a block vs destroying one is not the same anymore. I cant place blocks @ the same distance as the farthest point that I can destroy one now. Offsetting placement about .05m in distance seems to have changed it all, atleast for me. When the server bugged out on block removal or placement, it was always happening when I was placing blocks at the edge of the highlighted range.
Resolved? Ummm yeah how? no fix done, you didnt even 'confirm' it. What version fixed this.... considering I'm using 1.8.1 latest version it is not 'resolved'
if you are going to close a ticket because of a dup maybe you should SAY SO.
still existing........
exactly and its not documented anywhere at all in any shape or form this is 'intended'. quote please!
That would be like saying the arrows stuck in the ground fired by a player vs ones fired by a monster are the same. But yet one you can pick up and the other you cant.
Sorry for the poor analogy, it was early and didnt want to dig more as to why but this is the reason.... but here is the answer
.... arrows stuck in a player are not an 'arrow' anymore but purely visual part of 'living entity'.
reference:
https://bukkit.org/threads/remove-arrows-that-are-stuck-in-players.340290/
http://wiki.vg/Entities#Living_Entity
(apparently still too early...
.)logs? info? screenshots of what happens? using correct version? just downloaded vanilla 1.7.10 and used the 1.7.10 client to log in without problems. More details please.
kind of related, but not really this is totally new and different then 'no rain' due to a specific biome when it supposed to be raining. Also did not exist prior to 1.8.0 I havent checked if this is happening in non-rain biome I will check for that also.
push != pull
Confirmed and still existing in 1.8.3
Yeah I seen that this is marked as WAI but when was this changed? this was never the norm... 1.7.x only noticed it recently that it changed in 1.8 far as I can remember.
turns out this is purely a client issue..... 1.8 client version will cause this using anything after that has no problems (albeit I sworn that I eliminated that possibility of it being client side...)
one of the mods can close this now since its referring to client side issue and infact is a older version client version.
understand that the falling thru the web might be WAI but 2 to (a figure I have yet to maximum calculate) all stacking together in one single block I doubt is WAI. look at the photos, there is 1 single visible block falling when there is infact 2 or more..... that point is the critical part Im pointing out....other then thinking the blocks breaking wasnt WAI either. When gravel falls it doesnt group up into one block is falls all seperate...
Im not talking the stack on the ground after the gravel block broke. Im talking the falling 2+x number of in world blocks of gravel falling becoming one..... as they are falling. did you even look at the photos? like the 1st and 2nd? you dont see 2 blocks of gravel anymore, in the second photo anymore, do you?
nah cant agree on this sorry, stack of 10 blocks of gravel break the bottom they all dont just fly together as one single falling block... that is what is happening... can not fix != WAI
Also dont know why you all keep going on 'items' either, there is no items in question. we are talking BLOCKS.... stack 10 gravel, break the bottom gravel block. Do all the 9 gravel blocks above it all push together as one falling block. No.
This is why I dont nor will ever say WAI. because it is the sole single exception because no-one decided to code falling gravel thru a cobweb to still be located/considered above the cobweb so the rest of the gravel above it does not start falling prematurely.... Im saying all should be falling but not creating one single falling block, it should act like how gravel normally works. bottom block falls to next block then next block above it falls and so on in a domino effect.
yes, I felt this also might fall into the 'wont/cant fix' category... sure isn't WAI.. it only does this because the first falling block of gravel is in fact still in its original position but the next block of gravel above it doesn't see this and so it then starts to fall. Honestly it shouldn't be that difficult to eliminate this and have it act like 'normal' falling gravel. And then the std actions of gravel falling thru cobwebs or torches and the like breaking to an item would still apply also.... it would just do it one by one at least.
well Arisa you been denied again because you are a 'stupid'. you cant split a stack if it is a single 'ITEM' duh. so yet again changes undone....
Torabi there is no stack creation involved, its already created and placed in the middle. then picked back up and tried to split after that.
The solution has already been fixed by ThinkofDeath just Mojang still has refused to implement it.. I mean unless we trying to get quasi-real physics working, the velocity should never go to zero on a turn regardless it should change the thrust vector to the new direction of travel. It is a powered minecart with a fixed force of thrust. This isnt a simulator so dont see why implementing code that fixes the problem still has not been implemented.
it is not a suggested fix unless you know what you doing because obfuscation changes in every version release.. best bet is use the 3rd party server or get alot of people to start upvoting this issue so they might finally implement it. if MCP was kept up to date then this would be possible but since it hasnt been updated since 1.8 it would not be recommended.
not necessarily. 5750 13.12 drivers zero problems only happens sometimes when I change DD and a restart of the client fixes it. imho the issue is something dealing with what is being changed for draw dist. possibly imho fixed buffer size being resized and its not being 'cleared' properly. (since buffers are not GC'd at all) eg. the long time growbuffer error a good indication (but I dont know if that still existing either but I believe it is)
reopen this is not intended anyone who says otherwise should be terminated. buffers are FIXED in size. it might say 'WARN' but it is a error it is telling you the buffer is too small. why you think you still have chunk problems still...
you dont because these guys keep thinking this is normal. AND ITS NOT. buffers are fixed in size.
Well then guess they'll still never fix the glitched graphics issue that is linked to DrawDistance. Yay for buffer overflow being considered normal.
hard to know because there is too many variables to content with since Java runtime args (let alone ingame graphics options like VBO etc) are not static for MC, nor is this saying what thread this is coming from. I could do some testing but I will go and say this. this error and massive visual glitching both have appeared the same time.. (14w snaps and since there after...) simple as that. you should not get warnings that your 'fixed' buffer memory is being resized if it was correct in the first place...
it is not a warning because it is intended... I only bring this up because it STILL exists (let alone the massive visual glitching) even in 15w39b
still existing all the way up to 15w40b and you wonder why you have still performance issues in rendering when you still allow Z texture fighting to continue to happen.
no offense but look at the age of this.... and also pls add the rest of 15w versions because we cant add them users can only add 'current' versions anymore.
IL: only ones that show up are the 3 you see nothing else for 15w* shows up.
Mods and Devs: seriously you need to keep versions up to fix stuff? I'm sorry that is about the biggest cop out I have heard yet. Unless you fix it, its not going to fix itself. and for it now to be 3 years old AND still an open ticket is just unbelievable esp. given the fact we have custom models now for how long. And heck it still not even a officially acknowledged bug....still. Before custom models were implemented I could understand the hesitation of trying to fix it but that is not the case anymore. Hearing that any old versions are not even supported anymore officially means that this and any other ticket should been closed the moment you dont support the last version reported. so sorry will not accept that fact you need to keep versions updated so you know about it.
ps. sorry if I'm being a lil crude and harsh but the truth is know few tickets that code fixes have been given flat out to you and still don't implement them so I can hope you can relate to my frustration as a player.
or they could just have implemented the code that fixed the problem provided by one of 3rd party server devs which in fact was implemented and been fixed in said 3rd party server for over half a year now.
really... so how did you go back in time to post it in 2014? not to mention I also appreciate the poaching, Swekob. I'm done.
Clarify exactly what kind of spawn/respawn are you referring to.
As this is normal, you dont respawn on the world spawn exactly, you spawn in an area? its not a bed spawn where your spawn is exact, worldspawn is randomized and puts you on top of trees sometimes. this only been a thing since like forever?