Whenever I drop multiple stacks, the second they merge the disappear from my screen...

If I walk over the spot where I dropped them they pop back into my inventory but I cant see them at all before that

what about using the 16-bit number instead of the 8-bit? the extra padding would ensure correct function, and even allow an increased max stack size. (idk what it's called in Java, but in C++ it's called char or short)

URLs:
https://docs.oracle.com/javase/7/docs/api/allclasses-noframe.html
https://msdn.microsoft.com/en-us/library/exx3b86w.aspx
https://msdn.microsoft.com/en-us/library/x9h8tsay.aspx
https://msdn.microsoft.com/en-us/library/ybs77ex4.aspx

isn't there a byte value that goes from 0 to 255? I don't know why you'd want to check for negative Item counts.

A (signed) byte ranges from -128 to 127, Java doesn't have an unsigned byte type.

I can't because that's what vanilla uses for the stack size in packets...

I can't reproduce it. Dropped 9 stacks of items on the ground, they grouped up and stayed there until I picked them up. Any other mods, what version of forge? Upload fml-client-latest.log to gist.

Its a variation(and by that I mean updated as much as possible) version of crackpack. The bug took place also in the orginal(v2) version of crackpack current available on the AT launcher

Can't upload to Gist, file gets truncated...so heres a dropbox link https://dl.dropboxusercontent.com/u/47556333/fml-client-latest.log

If you want to see it in action I can upload a video?

Its any dropped item over 2 stacks worth, I literally dropped some items(coal) one by one to see when they went poof and its the second it hits 128 that the stop rendering in. I'll try to get the video up shortly

Nothing out of the ordinary in the log file. Surely, a video might not be bad. Curious though, does it happen for any dropped item or only full stacks?

I imagine that some other mod might be canceling the spawn event on the client only, causing the items to not show up at all on the client, while still being there on the server side.
If that is the case, creating a separate instance of the pack to find the mod doing it would be the best thing to do. Take roughly half the mods, try to run it, then again with the second half of the mods. When the bug doesn't happen move/trash the "safe" mods and continue that for a few times.

When in F3, does the entity count stay the same or does it go down when you get to 128 or above?

Entity count goes up when the first stack drops and the second stack but when they both combine it goes back to the same number before the stacks had been dropped

Video of it in action, excuse the choppy framrate iunno where that came from

https://www.youtube.com/watch?v=sNdw5LfvvEg&feature=youtu.be

Tried it on TCP 2.0.3.0, couldn't reproduce it.

The client shouldn't be affected, because Stackie operates on the server side. Other than the stack size tweaks (doors stackable to 64 etc) it changes nothing.

My guess is that some other mod that's not in the pack tries to do something to the dropped items, possibly "fancier" renderer or something. I'd suggest testing it against all mods that are not (the same) in the latest TCP.
You should try reproducing the bug on the latest TCP, if it doesn't happen you'll have to check which of your updated/added mods might be causing it.

There are no new mods in the updated version(in fact there are less mods so there should be less to conflict with...), I also replicated the glitch as I said in the original TCP 2.0.3.0. I however cannot replicate the glitch in singleplayer, only on the server I am playing on.

Missed the part about "the original TCP also has the bug". You didn't mention that it was on the server however. I'll look into it.

I'll try and see if I can catch some of the others on the server to try and replicate it to see if its because of the server or because of some random setting on my computer

... great. I'll have to revert that addition. An EnitityItem can only have 127 items at once because it's stored in a byte (which can store values from -128 to 127).

Only reason it works it because the memory value uses an integer which can store way more items. Once you unload the chunks you'll be left with 127 items, in the best case scenario.

Oh. That is bad.