#BlameMojang

[Type1Ninja]

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

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?
"Anything you can do, we can do better (exceptanythinghavingtodowithrenderingpleaseno)"

 

[ljfa]

Rendering should be better in 1.9. After all Mojang does seem to listen to modders.

 

[lenscas]

Rendering should be better in 1.9. After all Mojang does seem to listen to modders.

Is that sarcasm or not?

 

[ljfa]

Is that sarcasm or not?

No, I'm being serious. From what I heard, they improved the model format because of that. Still not the best thing though :/

 

[lenscas]

No, I'm being serious. From what I heard, they improved the model format because of that. Still not the best thing though :/

Lets hope then, its not like we can do much anyway

 

[OreCruncher]

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?
"Anything you can do, we can do better (exceptanythinghavingtodowithrenderingpleaseno)"

Yeah... imagine wielding a sword in your right hand and steak in the left... OK, so I am hungry.

 

[Celestialphoenix]

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?

The new skeleton animation looks cool.

Lets hope then, its not like we can do much anyway

Apart from developing our own APIs to aid in our modding.

 

[lenscas]

The new skeleton animation looks cool.


Apart from developing our own APIs to aid in our modding.

yea.... like people have done that to make 1.8 easier, unless I overlooked something >_>

 

[Type1Ninja]

Yeah... imagine wielding a sword in your right hand and steak in the left... OK, so I am hungry.

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

 

[ljfa]

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

Well in this case it'd still help against multiple enemies at once

I'm just gonna see how badly it will break mods

 

[FyberOptic]

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.

 

[ljfa]

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:

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

 

[RavynousHunter]

That makes absolutely no effing sense, but whatever. I've come to expect that from Mojang.

 

[Reika]

One more reason for all of us to stay in 1.7.10.

 

[Strikingwolf]

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:

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

GG...that's just...ewww

 

[SatanicSanta]

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:

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

I don't really mess with packets very often, but that's just grimy.

 

[ljfa]

I don't really mess with packets very often, but that's just grimy.

Well fortunately you don't have to for your own packets, it's just that vanilla packets are doing it this way.
There are easier ways to abstract this.

 

[FyberOptic]

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.

 

[RavynousHunter]

Always wondered why creepers and crap floated around in 1.8 when I watched my girlfriend play. Good god...

 

[FyberOptic]

Always wondered why creepers and crap floated around in 1.8 when I watched my girlfriend play. Good god...

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.