#BlameMojang

  • The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
Lethosos said:
Opening the thread back up, this time for 1.9: Given some of the new mechanics coming out, what's your opinion about 1.9?

Sent from my Puzzle Box of Yogg-Saron using Tapatalk 2
Click to expand...
I'm really looking forward to Dual Wield. No, I don't care about balance, realism, or game-breaking-ness, I'm just really excited about dual wielding.
I just wish that you could do weapons in your offhand, which apparently you can't. >.<
That's why there's modding, right? :P
"Anything you can do, we can do better (exceptanythinghavingtodowithrenderingpleaseno)"
 
Type1Ninja said:
I'm really looking forward to Dual Wield. No, I don't care about balance, realism, or game-breaking-ness, I'm just really excited about dual wielding.
I just wish that you could do weapons in your offhand, which apparently you can't. >.<
That's why there's modding, right? :p
"Anything you can do, we can do better (exceptanythinghavingtodowithrenderingpleaseno)"
Click to expand...

Yeah... imagine wielding a sword in your right hand and steak in the left... :) OK, so I am hungry.
 
  • Like
Reactions: Type1Ninja
OreCruncher said:
Yeah... imagine wielding a sword in your right hand and steak in the left... :) OK, so I am hungry.
Click to expand...
Nah, I just want to hold swords in both hands. What's that? That wouldn't be helpful because entities can only take so many hits in a certain time period? Too bad! I want it anyway! XD
 
Type1Ninja said:
Nah, I just want to hold swords in both hands. What's that? That wouldn't be helpful because entities can only take so many hits in a certain time period? Too bad! I want it anyway! XD
Click to expand...
Well in this case it'd still help against multiple enemies at once

I'm just gonna see how badly it will break mods :P
 
  • Like
Reactions: Type1Ninja
I'm sure 1.9 will have good stuff in it, I can't think of a major release that didn't. It's always fun to see what they add, and equally fun to pull it apart to see what's changed underneath. I don't think any of it will be particularly mindblowing, but I won't entirely dismiss the possibility. I generally look forward to the major releases regardless.

I'm not worried about the internals. There's always adequate ways to deal with it. 1.8 improved various things internally, and yes this includes rendering, since threaded chunk generation was a long time coming. It was just how you used all the stuff that they put on top of those rendering changes which ended up being a sticking point for modded Minecraft. It didn't have to be, and I'll honestly never understand why it did.

The only concerning part to me is that 1.8 was a buggy release, there's no two ways about it. If it made it to release in that state, and has gone this long with several of the bugs, then it's not unreasonable to think that 1.9 might carry over what's broken with 1.8 as well as any new problems on top of it. I found one of the bugs that bothered me in particular, and the other major one of note I at least know how to disable (at the cost of performance), so I feel a little better about it now than I might have a month ago. But I guess we'll see.
 
  • Like
Reactions: Lethosos, Celestialphoenix, Type1Ninja and 1 other person
In Minecraft 1.8, packet handling was made multithreaded, packets are handled in a networking thread separate from the Server and Client threads.
This introduces concurrency issues when you want to access things such as worlds or entities from a packet handling method. For this reason, addScheduledTask methods have been added which allows you to add Callables to a queue, and these Callables get processed every tick in the Client or Server thread, so they can opeate thread-safely.

Rather than doing your stuff directly in the packet handling method, you would enqueue a Callable which does it, which will get executed synchronously at the next tick.

Now, how does Mojang utilize this meachanism for their own packets? Take a look at PacketThreadUtil:
Java: 
if (!p_180031_2_.isCallingFromMinecraftThread())
{
    p_180031_2_.addScheduledTask(new Runnable()
    {
        private static final String __OBFID = "CL_00002305";
        public void run()
        {
            p_180031_0_.processPacket(p_180031_1_);
        }
    });
    throw ThreadQuickExitException.field_179886_a;
}
Yup, that's right. It checks if the packet handling method is called from the correct thread, if not it enqueues it and throws a "ThreadQuickExitException" to terminate further processing of the packet...blergh

Mojang please, Java is not Ruby :p
 
Last edited:
  • Like
Reactions: Type1Ninja
ljfa said:
In Minecraft 1.8, packet handling was made multithreaded, packets are handled in a networking thread separate from the Server and Client threads.
This introduces concurrency issues when you want to access things such as worlds or entities from a packet handling method. For this reason, addScheduledTask methods have been added which allows you to add Callables to a queue, and these Callables get processed every tick in the Client or Server thread, so they can opeate thread-safely.

Rather than doing your stuff directly in the packet handling method, you would enqueue a Callable which does it, which will get executed synchronously at the next tick.

Now, how does Mojang utilize this meachanism for their own packets? Take a look at PacketThreadUtil:
Java: 
if (!p_180031_2_.isCallingFromMinecraftThread())
{
    p_180031_2_.addScheduledTask(new Runnable()
    {
        private static final String __OBFID = "CL_00002305";
        public void run()
        {
            p_180031_0_.processPacket(p_180031_1_);
        }
    });
    throw ThreadQuickExitException.field_179886_a;
}
Yup, that's right. It checks if the packet handling method is called from the correct thread, if not it enqueues it and throws a "ThreadQuickExitException" to terminate further processing of the packet...blergh

Mojang please, Java is not Ruby :p
Click to expand...
GG...that's just...ewww
 
ljfa said:
In Minecraft 1.8, packet handling was made multithreaded, packets are handled in a networking thread separate from the Server and Client threads.
This introduces concurrency issues when you want to access things such as worlds or entities from a packet handling method. For this reason, addScheduledTask methods have been added which allows you to add Callables to a queue, and these Callables get processed every tick in the Client or Server thread, so they can opeate thread-safely.

Rather than doing your stuff directly in the packet handling method, you would enqueue a Callable which does it, which will get executed synchronously at the next tick.

Now, how does Mojang utilize this meachanism for their own packets? Take a look at PacketThreadUtil:
Java: 
if (!p_180031_2_.isCallingFromMinecraftThread())
{
    p_180031_2_.addScheduledTask(new Runnable()
    {
        private static final String __OBFID = "CL_00002305";
        public void run()
        {
            p_180031_0_.processPacket(p_180031_1_);
        }
    });
    throw ThreadQuickExitException.field_179886_a;
}
Yup, that's right. It checks if the packet handling method is called from the correct thread, if not it enqueues it and throws a "ThreadQuickExitException" to terminate further processing of the packet...blergh

Mojang please, Java is not Ruby :p
Click to expand...
I don't really mess with packets very often, but that's just grimy.
 
I believe I said something about the network thread somewhere once before, I can't remember. It gave me grief initially as well.

This also contributes to the floaty mobs of 1.8 since it's just one more delay that the animation goes through before reaching the player, on top of the 3+ frames of smoothing that gets applied to that motion when received.
 
  • Like
Reactions: SatanicSanta and Type1Ninja
RavynousHunter said:
Always wondered why creepers and crap floated around in 1.8 when I watched my girlfriend play. Good god...
Click to expand...

It's a combination of that as well as them removing the client-side movement for most mobs. So now the process is [client hit mob] -> [send packet to server] -> [server processes packet, applies movement] -> [entity manager detects change in entity values, sends position/velocity packets] -> [network thread receives, passes it into the main client thread] -> [main client thread processes packet, sets up movement] -> [movement applied over 3+ frames to smooth it out].

And now keep in mind that the resulting movement is not all sent in a single packet, but throughout the time period of the entity rising and falling after being hit, since the entity's values keep changing on the server so it updates the client basically using the last four steps over and over.

In contrast, pre-1.8 handles all movement on both the client and server at the same time, which gives you a quick response on the client, and is also why you might see stutter sometimes as the incoming server-side packets are also still being applied and perhaps slightly out of sync.

This is also why my patch literally just removes the check in the entity movement code as to whether it's running on a server or not, restoring 1.7's behavior.
 
  • Like
Reactions: RavynousHunter and Type1Ninja
You must log in or register to reply here.
Top Bottom