Sycholic

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?

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.

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. 😞

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.

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.

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.

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

Well then guess they'll still never fix the glitched graphics issue that is linked to DrawDistance. Yay for buffer overflow being considered normal.

you dont because these guys keep thinking this is normal. AND ITS NOT. buffers are fixed in size.

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...

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)

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.

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.

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.

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....

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.

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.

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

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?

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...