2018-04-05 09:58:41 --> Guest50842 (~xandaros@185.35.77.23) a rejoint #mcdevs 2018-04-05 09:58:50 <-- Guest50842 (~xandaros@185.35.77.23) a quitté (Client Quit) 2018-04-05 09:59:33 --> Xandaros_ (~xandaros@185.35.77.23) a rejoint #mcdevs 2018-04-05 10:01:11 <-- Xandaros_ (~xandaros@185.35.77.23) a quitté (Changing host) 2018-04-05 10:01:11 --> Xandaros_ (~xandaros@unaffiliated/xandaros) a rejoint #mcdevs 2018-04-05 10:01:29 -- Xandaros_ est maintenant connu sous le nom Xandaros 2018-04-05 10:06:37 <-- Xandaros (~xandaros@unaffiliated/xandaros) a quitté (Quit: WeeChat 1.9.1) 2018-04-05 10:07:18 --> Guest24766 (~xandaros@185.35.77.23) a rejoint #mcdevs 2018-04-05 10:07:37 <-- Guest24766 (~xandaros@185.35.77.23) a quitté (Changing host) 2018-04-05 10:07:37 --> Guest24766 (~xandaros@unaffiliated/xandaros) a rejoint #mcdevs 2018-04-05 10:07:54 -- Guest24766 est maintenant connu sous le nom Xandaros 2018-04-05 10:10:55 <-- Brandon15811 (sid13052@gateway/web/irccloud.com/x-fcougtpsszoqyrai) a quitté (Read error: Connection reset by peer) 2018-04-05 10:11:39 <-- Pyker (pyker@pyker.net) a quitté (Quit: Quit) 2018-04-05 10:12:30 --> Brandon15811 (sid13052@gateway/web/irccloud.com/x-evjhqiylqwwgdyxo) a rejoint #mcdevs 2018-04-05 10:12:51 <-- fl4sh__ (~fl4sh@trinity.jsje.de) a quitté (Ping timeout: 264 seconds) 2018-04-05 10:13:02 <-- mrkirby153 (~mrkirby15@mrkirby153.com) a quitté (Ping timeout: 276 seconds) 2018-04-05 10:13:41 <-- Deaygo_ (Deaygo@i.let.this.bloody.dropbear.in) a quitté (Ping timeout: 276 seconds) 2018-04-05 10:14:18 --> mrkirby153 (~mrkirby15@mrkirby153.com) a rejoint #mcdevs 2018-04-05 10:14:20 <-- AndrewPH (Butts@omega.classicube.net) a quitté (Ping timeout: 276 seconds) 2018-04-05 10:15:07 --> fl4sh_ (~fl4sh@dock.jsje.de) a rejoint #mcdevs 2018-04-05 10:15:11 --> Pyker (pyker@pyker.net) a rejoint #mcdevs 2018-04-05 10:15:26 --> AndrewPH (Butts@omega.classicube.net) a rejoint #mcdevs 2018-04-05 10:15:35 --> Deaygo (Deaygo@i.let.this.bloody.dropbear.in) a rejoint #mcdevs 2018-04-05 10:15:40 -- Mode #mcdevs [+v AndrewPH] par ChanServ 2018-04-05 10:16:03 <-- Thinkofname (~Think@ns3091419.ip-5-135-185.eu) a quitté (Ping timeout: 240 seconds) 2018-04-05 10:20:37 --> Thinkofname (~Think@ns3091419.ip-5-135-185.eu) a rejoint #mcdevs 2018-04-05 10:20:38 -- Mode #mcdevs [+v Thinkofname] par ChanServ 2018-04-05 10:26:41 <-- andreymal (~chatmovil@2a01:4f8:c17:335f::2) a quitté (Ping timeout: 276 seconds) 2018-04-05 10:32:54 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: Connection reset by peer) 2018-04-05 10:36:08 --> redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-05 11:37:17 --> NickG365_ (~NickG365@cortex.starlabs.theflash.rocks) a rejoint #mcdevs 2018-04-05 11:38:52 <-- NickG365 (~NickG365@cortex.starlabs.theflash.rocks) a quitté (Ping timeout: 256 seconds) 2018-04-05 11:38:52 -- NickG365_ est maintenant connu sous le nom NickG365 2018-04-05 14:25:41 -- ThomasMonroe_ est maintenant connu sous le nom ThomasMonroe 2018-04-05 15:08:14 --> andreymal (~chatmovil@2a01:4f8:c17:335f::2) a rejoint #mcdevs 2018-04-05 15:14:44 <-- justJanne (~justJanne@lithium.kuschku.de) a quitté (Ping timeout: 252 seconds) 2018-04-05 15:18:15 --> justJanne (~justJanne@lithium.kuschku.de) a rejoint #mcdevs 2018-04-05 15:29:33 <-- Tuxel (~tux@84.200.81.170) a quitté (Remote host closed the connection) 2018-04-05 16:04:39 <-- justJanne (~justJanne@lithium.kuschku.de) a quitté (Quit: So, if you care to find me, look to the western sky. As someone told me lately, everyone deserves a chance to fly.) 2018-04-05 16:05:18 --> justJanne (~justJanne@lithium.kuschku.de) a rejoint #mcdevs 2018-04-05 16:14:30 --> Tuxel (~tux@mail.tuxelcode.de) a rejoint #mcdevs 2018-04-05 17:01:24 Botched [VERSION] Minecraft Snapshot 18w14b has been released! 2018-04-05 18:12:30 Not-10ef [Burger] New data now avaliable for 18w14b: 2018-04-05 18:12:31 Not-10ef [Burger] Diff from 18w14a: http://pokechu22.github.io/Burger/diff_18w14a_18w14b.html (http://pokechu22.github.io/Burger/diff_18w14a_18w14b.json) 2018-04-05 18:12:33 Not-10ef [Burger] Full data: http://pokechu22.github.io/Burger/18w14b.html (http://pokechu22.github.io/Burger/18w14b.json) 2018-04-05 18:59:56 --> itsme_ (~textual@x4dbd9fe9.dyn.telefonica.de) a rejoint #mcdevs 2018-04-05 19:26:39 <-- NathanWolf (~nathan@216-235-101-HCC-80.hcc.net) a quitté (Quit: NathanWolf) 2018-04-05 20:33:12 --> Brejic (~Laars@162-231-45-138.lightspeed.mmphtn.sbcglobal.net) a rejoint #mcdevs 2018-04-05 20:36:56 --> Brejick (~brejic@162-231-45-138.lightspeed.mmphtn.sbcglobal.net) a rejoint #mcdevs 2018-04-05 20:38:01 <-- Brejick (~brejic@162-231-45-138.lightspeed.mmphtn.sbcglobal.net) a quitté (Client Quit) 2018-04-05 20:39:38 --> Brejick (~brejic@162-231-45-138.lightspeed.mmphtn.sbcglobal.net) a rejoint #mcdevs 2018-04-05 20:40:03 <-- Brejic (~Laars@162-231-45-138.lightspeed.mmphtn.sbcglobal.net) a quitté (Ping timeout: 240 seconds) 2018-04-05 21:50:06 <-- itsme_ (~textual@x4dbd9fe9.dyn.telefonica.de) a quitté (Quit: Textual IRC Client: www.textualapp.com) 2018-04-06 00:42:21 <-- Amaranth (~Amaranth@ubuntu/member/Amaranth) a quitté (Remote host closed the connection) 2018-04-06 01:01:49 <-- Thinkofname (~Think@ns3091419.ip-5-135-185.eu) a quitté (Quit: Leaving) 2018-04-06 01:04:10 --> Thinkofname (~Think@2001:41d0:8:c217::1) a rejoint #mcdevs 2018-04-06 01:04:10 -- Mode #mcdevs [+v Thinkofname] par ChanServ 2018-04-06 01:35:21 <-- Thinkofname (~Think@2001:41d0:8:c217::1) a quitté (Ping timeout: 265 seconds) 2018-04-06 01:44:31 --> Thinkofname (~Think@ns3091419.ip-5-135-185.eu) a rejoint #mcdevs 2018-04-06 01:44:32 -- Mode #mcdevs [+v Thinkofname] par ChanServ 2018-04-06 02:09:40 --> Amaranth (~Amaranth@ubuntu/member/Amaranth) a rejoint #mcdevs 2018-04-06 02:09:40 -- Mode #mcdevs [+v Amaranth] par ChanServ 2018-04-06 02:43:37 -- r04r est maintenant connu sous le nom xXx_retards_xXx 2018-04-06 02:51:18 <-- Brejick (~brejic@162-231-45-138.lightspeed.mmphtn.sbcglobal.net) a quitté (Quit: Quit) 2018-04-06 03:25:19 --> protryon_ (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-06 03:25:19 <-- protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Read error: Connection reset by peer) 2018-04-06 06:07:50 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-06 06:11:09 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 260 seconds) 2018-04-06 06:11:09 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2018-04-06 07:33:47 <-- angal (angal@gateway/shell/panicbnc/x-kuhvqrytqhsktzen) a quitté (Ping timeout: 245 seconds) 2018-04-06 09:01:05 --> angal (angal@gateway/shell/panicbnc/x-mhkuuknrjsbpdgcj) a rejoint #mcdevs 2018-04-06 10:38:45 --> itsme_ (~textual@x4dbd9fe9.dyn.telefonica.de) a rejoint #mcdevs 2018-04-06 10:38:45 <-- protryon_ (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Read error: Connection reset by peer) 2018-04-06 10:39:36 --> protryon_ (~protryon@2601:647:ca00:ab50:a3e8:71b:c02f:e125) a rejoint #mcdevs 2018-04-06 10:48:07 <-- justJanne (~justJanne@lithium.kuschku.de) a quitté (Ping timeout: 260 seconds) 2018-04-06 10:59:18 --> justJanne (~justJanne@lithium.kuschku.de) a rejoint #mcdevs 2018-04-06 12:04:08 <-- itsme_ (~textual@x4dbd9fe9.dyn.telefonica.de) a quitté (Quit: Textual IRC Client: www.textualapp.com) 2018-04-06 12:40:41 <-- SpaceManiac (~SpaceMani@2601:200:4400:61a::1279) a quitté (Ping timeout: 255 seconds) 2018-04-06 12:45:28 --> SpaceManiac (~SpaceMani@2601:200:4400:61a::1290) a rejoint #mcdevs 2018-04-06 12:45:29 -- Mode #mcdevs [+v SpaceManiac] par ChanServ 2018-04-06 14:30:19 <-- KnownUnown (KnownUnown@die.in.firrre.com) a quitté (Remote host closed the connection) 2018-04-06 15:44:43 --> KnownUnown (KnownUnown@die.in.firrre.com) a rejoint #mcdevs 2018-04-06 15:53:56 <-- Black-Hole (~BlackHole@p200300E753E573004D760847D8559EB8.dip0.t-ipconnect.de) a quitté (Read error: Connection reset by peer) 2018-04-06 16:54:04 --> winger_sendon (~winger@27.114.186.23) a rejoint #mcdevs 2018-04-06 17:05:48 --> Black-Hole (~BlackHole@p200300E753E573001550BB8DC0B1B770.dip0.t-ipconnect.de) a rejoint #mcdevs 2018-04-06 17:47:00 winger_sendon 1.8.0 didn't use section pallets at all? That's like 196 KB for a single full chunk and 80 MB for 400 chunks. :/// 2018-04-06 17:47:15 winger_sendon I'm using this link http://wiki.vg/index.php?title=Chunk_Format&oldid=6136 2018-04-06 17:49:08 winger_sendon Am I getting this wrong? 2018-04-06 17:49:33 --> NathanWolf (~nathan@216-235-101-HCC-80.hcc.net) a rejoint #mcdevs 2018-04-06 18:00:06 pokechu22 Yeah, it didn't, the chunk format's improved a fair bit in the past years. There's still empty chunk sections, so you can save some bandwidth that way, though 2018-04-06 18:05:20 winger_sendon Thanks 2018-04-06 18:08:26 <-- Black-Hole (~BlackHole@p200300E753E573001550BB8DC0B1B770.dip0.t-ipconnect.de) a quitté (Read error: Connection reset by peer) 2018-04-06 18:46:36 <-- winger_sendon (~winger@27.114.186.23) a quitté (Quit: Leaving) 2018-04-06 20:50:18 <-- andreymal (~chatmovil@2a01:4f8:c17:335f::2) a quitté #mcdevs 2018-04-06 20:52:09 --> andreymal (~chatmovil@2a01:4f8:c17:335f::2) a rejoint #mcdevs 2018-04-06 23:46:18 -- xXx_retards_xXx est maintenant connu sous le nom r04r 2018-04-06 23:56:41 NathanWolf I'm trying to get a jump up updating my RP to 1.13 - I am using a trick (of sorts) to remodel unbreakable tools while leaving the normal breakable tools alone. This trick no longer seems to work, though, I get the purple+black boxes for the breakable versions 2018-04-06 23:56:51 NathanWolf Would anyone happen to know offhand how I can make this work in 1.13? 2018-04-06 23:57:20 NathanWolf Here is an example of one of my items- the "trick" is the last line at the end with {"damaged": 1", "damage": 0} that catches normal items 2018-04-06 23:57:22 NathanWolf https://github.com/elBukkit/MagicPlugin/blob/master/Magic/src/resource-pack/default/assets/minecraft/models/item/wooden_hoe.json 2018-04-06 23:57:29 NathanWolf Thanks for any help! 2018-04-06 23:57:29 --> Black-Hole (~BlackHole@p200300E753E57300D5E9CBB664C3200A.dip0.t-ipconnect.de) a rejoint #mcdevs 2018-04-06 23:59:35 <-- EW8GU (admin@ho.by) a quitté (Ping timeout: 276 seconds) 2018-04-06 23:59:49 NathanWolf oh... uh sorry I think I just answered my own question! Simply had to change wood_hoe to wooden_hoe per the great flattening/name-fixing. Nevermind (I think), sorry! 2018-04-07 00:01:25 --> EW8GU (admin@86.57.137.25) a rejoint #mcdevs 2018-04-07 00:05:27 <-- angal (angal@gateway/shell/panicbnc/x-mhkuuknrjsbpdgcj) a quitté (Ping timeout: 245 seconds) 2018-04-07 00:06:07 PolarizedIons NathanWolf: no worries, happens to the best of people :) 2018-04-07 00:06:13 NathanWolf :D 2018-04-07 00:06:30 NathanWolf I'm just glad that's all it took.. RP seems to work great in 1.13 now :) 2018-04-07 00:14:16 --> Dadido3 (~quassel@p200300EF43C49E00D9365C1919C68AD7.dip0.t-ipconnect.de) a rejoint #mcdevs 2018-04-07 00:17:59 <-- Dadido3_ (~quassel@p2E5ECBBA.dip0.t-ipconnect.de) a quitté (Ping timeout: 268 seconds) 2018-04-07 00:20:41 --> angal (angal@gateway/shell/panicbnc/x-sjnpwmiprvcmreqe) a rejoint #mcdevs 2018-04-07 02:24:11 <-- gabizou (~gabizou@irc.spongepowered.org) a quitté (Ping timeout: 240 seconds) 2018-04-07 02:26:22 --> gabizou (~gabizou@irc.spongepowered.org) a rejoint #mcdevs 2018-04-07 05:19:53 <-- NathanWolf (~nathan@216-235-101-HCC-80.hcc.net) a quitté (Quit: NathanWolf) 2018-04-07 05:32:06 --> NathanWolf (~nathan@216-235-101-HCC-80.hcc.net) a rejoint #mcdevs 2018-04-07 06:52:01 +Amaranth Don't forget everything goes through zlib too 2018-04-07 06:52:12 +Amaranth So it's not really 196KB for a single chunk 2018-04-07 10:43:00 --> itsme (~textual@x5ce399eb.dyn.telefonica.de) a rejoint #mcdevs 2018-04-07 13:28:44 --> itsme__ (~textual@x4dbe83f4.dyn.telefonica.de) a rejoint #mcdevs 2018-04-07 13:29:51 <-- itsme (~textual@x5ce399eb.dyn.telefonica.de) a quitté (Ping timeout: 256 seconds) 2018-04-07 15:16:55 --> itsme (~textual@195.60.77.52) a rejoint #mcdevs 2018-04-07 15:19:18 <-- itsme__ (~textual@x4dbe83f4.dyn.telefonica.de) a quitté (Ping timeout: 265 seconds) 2018-04-07 15:48:11 <-- humerusj (~humerusj@unaffiliated/humerusj) a quitté (Ping timeout: 240 seconds) 2018-04-07 15:51:18 --> humerusj (~humerusj@unaffiliated/humerusj) a rejoint #mcdevs 2018-04-07 15:56:23 <-- humerusj (~humerusj@unaffiliated/humerusj) a quitté (Ping timeout: 276 seconds) 2018-04-07 15:56:49 --> humerusj (~humerusj@unaffiliated/humerusj) a rejoint #mcdevs 2018-04-07 16:23:43 <-- NathanWolf (~nathan@216-235-101-HCC-80.hcc.net) a quitté (Quit: NathanWolf) 2018-04-07 17:07:39 --> C4K3_ (~C4K3@0127801301.0.fullrate.ninja) a rejoint #mcdevs 2018-04-07 17:11:03 <-- C4K3 (~C4K3@0127801301.0.fullrate.ninja) a quitté (Ping timeout: 256 seconds) 2018-04-07 18:10:03 <-- C4K3_ (~C4K3@0127801301.0.fullrate.ninja) a quitté (Quit: leaving) 2018-04-07 18:10:16 --> C4K3 (~C4K3@0127801301.0.fullrate.ninja) a rejoint #mcdevs 2018-04-07 18:24:39 <-- willies952002_ (~willies95@irc.domnian.com) a quitté (Ping timeout: 260 seconds) 2018-04-07 18:26:09 --> willies952002 (~willies95@irc.domnian.com) a rejoint #mcdevs 2018-04-07 19:06:28 --> winger_sendon (~winger@123.176.15.215) a rejoint #mcdevs 2018-04-07 19:10:33 winger_sendon Does the mojang server load chunks from files in the main thread? I have looked at the decompiled code and it seems like it uses another thread for saving, but loads from the main thread. Wouldn't it slow down the main loop? :/ 2018-04-07 19:12:24 Mustek to be fair, chat used to go over the same thread as well 2018-04-07 19:12:33 Mustek so every time the game lagged, chat would just lag too 2018-04-07 19:16:33 <-- C4K3 (~C4K3@0127801301.0.fullrate.ninja) a quitté (Read error: Connection reset by peer) 2018-04-07 19:25:45 --> C4K3 (~C4K3@0127801301.0.fullrate.ninja) a rejoint #mcdevs 2018-04-07 19:51:30 MiniDigger Iirc some chunk loads and sync and some are async. For example, when you teleport it will load chunks sync, if you fly around they will be loaded async 2018-04-07 19:52:01 --> stellarwind (~stellarwi@p200300C8A74C9400F0D4672A14133E7E.dip0.t-ipconnect.de) a rejoint #mcdevs 2018-04-07 19:52:26 pokechu22 World generation is also sync (at least until 1.13) 2018-04-07 20:22:02 <-- stellarwind (~stellarwi@p200300C8A74C9400F0D4672A14133E7E.dip0.t-ipconnect.de) a quitté (Quit: Leaving) 2018-04-07 20:24:51 <-- star (~star@c-76-16-146-255.hsd1.il.comcast.net) a quitté (Read error: Connection reset by peer) 2018-04-07 21:18:18 --> star (~star@c-76-16-146-255.hsd1.il.comcast.net) a rejoint #mcdevs 2018-04-07 21:38:02 <-- winger_sendon (~winger@123.176.15.215) a quitté (Quit: Leaving) 2018-04-07 22:39:11 <-- willies952002 (~willies95@irc.domnian.com) a quitté (Ping timeout: 240 seconds) 2018-04-07 22:40:10 --> willies952002 (~willies95@irc.domnian.com) a rejoint #mcdevs 2018-04-08 00:40:44 <-- itsme (~textual@195.60.77.52) a quitté (Quit: Textual IRC Client: www.textualapp.com) 2018-04-08 00:41:23 <-- SpaceManiac (~SpaceMani@2601:200:4400:61a::1290) a quitté (Ping timeout: 260 seconds) 2018-04-08 00:42:40 <-- C4K3 (~C4K3@0127801301.0.fullrate.ninja) a quitté (Quit: leaving) 2018-04-08 00:45:19 --> SpaceManiac (~SpaceMani@2601:200:4400:61a::129e) a rejoint #mcdevs 2018-04-08 00:45:20 -- Mode #mcdevs [+v SpaceManiac] par ChanServ 2018-04-08 00:55:48 --> C4K3 (~C4K3@0127801301.0.fullrate.ninja) a rejoint #mcdevs 2018-04-08 02:16:14 Hafydd Troll or genuine question? https://github.com/ammaraskar/pyCraft/issues/85 2018-04-08 02:16:51 +ammar2 genuine question, probably someone really young 2018-04-08 02:16:59 +ammar2 I'll probably point them to some programming resources 2018-04-08 02:17:09 Hafydd If they're really young, they chose an interesting username. 2018-04-08 02:17:26 pokechu22 Tons of stuff like that also happens on MCC 2018-04-08 02:19:23 timmyRS Troll or not, it wouldn't hurt to reply with the proper resources in case anyone in the future has the same question. 2018-04-08 02:31:32 Hafydd True. 2018-04-08 04:14:17 <-- protryon_ (~protryon@2601:647:ca00:ab50:a3e8:71b:c02f:e125) a quitté (Quit: WeeChat 1.7-rc2) 2018-04-08 07:44:48 --> barneygale_ (~barneygal@90.197.160.47) a rejoint #mcdevs 2018-04-08 07:57:49 <-- barneygale_ (~barneygal@90.197.160.47) a quitté (Ping timeout: 260 seconds) 2018-04-08 08:33:02 --> protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-08 08:39:09 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: Connection reset by peer) 2018-04-08 08:39:24 --> redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-08 08:42:57 <-- OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a quitté (Ping timeout: 268 seconds) 2018-04-08 10:43:36 <-- SpaceManiac (~SpaceMani@2601:200:4400:61a::129e) a quitté (Ping timeout: 256 seconds) 2018-04-08 10:43:37 <-- protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Read error: Connection reset by peer) 2018-04-08 10:44:20 --> protryon (~protryon@2601:647:ca00:ab50:a3e8:71b:c02f:e125) a rejoint #mcdevs 2018-04-08 10:50:20 --> SpaceManiac (~SpaceMani@c-67-172-123-140.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-08 10:50:21 -- Mode #mcdevs [+v SpaceManiac] par ChanServ 2018-04-08 11:01:06 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: No route to host) 2018-04-08 11:02:46 --> redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-08 13:29:17 <-- Pyker (pyker@pyker.net) a quitté (Ping timeout: 255 seconds) 2018-04-08 13:29:17 <-- simon816 (~simon816@ec2-52-43-110-46.us-west-2.compute.amazonaws.com) a quitté (Ping timeout: 255 seconds) 2018-04-08 13:29:35 --> Pyker (pyker@pyker.net) a rejoint #mcdevs 2018-04-08 13:32:44 --> simon816 (~simon816@ec2-52-43-110-46.us-west-2.compute.amazonaws.com) a rejoint #mcdevs 2018-04-08 15:01:26 +Amaranth Mustek: Chat still goes over the main thread 2018-04-08 15:01:40 +Amaranth They changed it back, too many bugs they didn't want to try to deal with 2018-04-08 15:02:20 +Amaranth MiniDigger: That's CraftBukkit 2018-04-08 15:04:18 +Amaranth For chat after we did put in all that work to get chat to be thread safe even with plugins we kept it off the main thread in CraftBukkit 2018-04-08 15:05:48 MiniDigger Ah, thanks for clearing that up 2018-04-08 15:06:06 +Amaranth Mojang still does all chunk loads on the main thread at least as of 1.12 2018-04-08 15:06:59 +Amaranth But between me, Wolvereness, Aikar, ammar2, and blood basically every form of modded Minecraft has async chunk loading 2018-04-08 15:42:05 MiniDigger That's why I thought it was vanilla, I never knew anything else ^^ 2018-04-08 16:34:59 rom1504 Hafydd: why would it be a troll ? afaik pycraft is not even meant to be used for that, it's a low level lib 2018-04-08 16:35:40 rom1504 https://github.com/ammaraskar/pyCraft/tree/master/docs no high level examples there 2018-04-08 16:36:14 rom1504 in python there's only https://github.com/SpockBotMC/SpockBot 2018-04-08 16:39:39 --> barneygale_ (~barneygal@90.197.160.47) a rejoint #mcdevs 2018-04-08 19:34:39 <-- barneygale_ (~barneygal@90.197.160.47) a quitté (Remote host closed the connection) 2018-04-08 20:05:15 <-- simon816 (~simon816@ec2-52-43-110-46.us-west-2.compute.amazonaws.com) a quitté (Ping timeout: 260 seconds) 2018-04-08 20:07:34 --> Jan1902 (~quassel@2a02:2028:506:bf01:fd55:329d:caf8:259) a rejoint #mcdevs 2018-04-08 20:07:54 --> simon816 (~simon816@ec2-52-43-110-46.us-west-2.compute.amazonaws.com) a rejoint #mcdevs 2018-04-08 20:10:10 --> ScruffyRules_ (~Scruff@2001:19f0:5800:8483:5400:ff:fe06:49ea) a rejoint #mcdevs 2018-04-08 20:10:47 <-- ScruffyRules (~Scruff@2001:19f0:5800:8483:5400:ff:fe06:49ea) a quitté (*.net *.split) 2018-04-08 20:10:47 -- ScruffyRules_ est maintenant connu sous le nom ScruffyRules 2018-04-08 20:11:27 Jan1902 Just got back into MC Client/Server development, having some serious problems right now handling packets while trying to buffer up incoming data and then disecting it into packets, is there anybody here who could help me with my (probably pretty amature) problem ? 2018-04-08 21:08:45 +ammar2 sure, explain your problem more specifically 2018-04-08 21:19:29 Jan1902 Ive tried creating a server once, without any problems, now when creating a client, i ran into some problems, handling incomin data, i got told that i had to buffer the data and then read this buffer packet by packet simultaniously, because a tcp packet of data doesnt always exactly equate to one minecraft packet, but when trying this i get some really strange behaviour because of some mistake in my code, and im not even sure if 2018-04-08 21:19:29 Jan1902 the way i do it, is the way to go 2018-04-08 21:27:56 Jan1902 Now this is the way, i decided to go with: https://hastebin.com/damocewebe.cs 2018-04-08 21:27:56 Jan1902 The only really important parts are EndRead and HandleData 2018-04-08 21:30:23 +ammar2 hmm, right now you have a hard limit of 4096 bytes and your code is a bit hard to follow. You're right in that a tcp packet doesn't correspond to one minecraft packet, but you can treat the tcp stream like a file essentially 2018-04-08 21:30:54 +ammar2 so you should be doing something like reading the header, which tells you the size and then just read the appropriate number of bytes after 2018-04-08 21:32:15 +ammar2 the only "trick" is that in most languages when you do a socket.read(n), it can return less than n bytes. However java has some APIs that will block and read exactly the amount of bytes requested 2018-04-08 21:33:14 +ammar2 oh you're using C#, it also probably has a similar api 2018-04-08 21:33:42 Jan1902 well right now im just always reading a fixed amount of bytes at a time into a big Buffer to read from lateron, to not have to worry about how many packets are in a tcp packet, after that i read from this buffer as normal, reading the entire packet and more if the buffer contains another full packet 2018-04-08 21:34:01 Jan1902 But a more primitive way might be the way to go 2018-04-08 21:36:01 +ammar2 right, it'd definitely help to abstract it out into another function that reads exactly n bytes 2018-04-08 21:36:11 +ammar2 then you wouldn't have to worry about seeking in the large 4096 buffer 2018-04-08 21:39:12 <-- Jan1902 (~quassel@2a02:2028:506:bf01:fd55:329d:caf8:259) a quitté (Remote host closed the connection) 2018-04-08 21:39:26 --> Jan1902 (~quassel@2a02:2028:506:bf01:fd55:329d:caf8:259) a rejoint #mcdevs 2018-04-08 21:41:03 Jan1902 well thats not what im exactly doing, the 4096 byte buffer is temporary, right after reading to that buffer, i copy the amount of bytes that were actually read into another byte[], that is then added to the big "mainbuffer" 2018-04-08 21:45:01 +ammar2 oh I see. It still imposes a 4096 size limit on a single packet, which chunk packets will likely burn through really fast 2018-04-08 21:58:50 Jan1902 That might actually be the reason to why my client breaks shortly after connecting, but i just tried implementing a more primitive way, and ima try this, if it doesnt work i might come back to this and try a bigger buffer :) 2018-04-08 22:27:07 Jan1902 I think i just created a working version using this primitive method: https://hastebin.com/izalaxelih.cs thanks for your help :) 2018-04-09 00:10:04 Jan1902 Quick question: is there any condition or so for the Player Look to work, does it have to be sent frequently or so ? Ive tried sending Player Look, but it rotates the player to yaw and pitch 0, no matter what values i insert 2018-04-09 00:14:18 pokechu22 Should always work, are you sure you're sending the numbers correctly? 2018-04-09 00:14:53 <-- protryon (~protryon@2601:647:ca00:ab50:a3e8:71b:c02f:e125) a quitté (Quit: WeeChat 1.7-rc2) 2018-04-09 00:22:04 Jan1902 Pretty sure actually, and as far as i understood the floats used by minecraft are just standard floats, so im using c#'s BinaryWriter to write values, including floats, which should work just fine 2018-04-09 00:23:51 pokechu22 It's possible that there's an endian issue... but I'm not sure, don't know quite how C# does it 2018-04-09 00:24:01 pokechu22 I'd think for floats, probably not... 2018-04-09 00:28:45 Jan1902 Havent really payd attention to endianess at all for now and it didnt cause any problems till now 2018-04-09 00:35:49 Jan1902 But it might actually be an issue with the endianess, because the doubles im receiving from the server in the PlayerPositionAndRotation packet are also not proper numbers 2018-04-09 00:36:02 pokechu22 Yeah, probably endianness then 2018-04-09 00:36:25 Jan1902 This is gonna be a pain to fix, i think 2018-04-09 00:41:40 Jan1902 Well, tried using an inofficial implementation of a BigEndian BinaryReader and Writer but unfortunately this didnt change anything 2018-04-09 02:25:22 <-- Jan1902 (~quassel@2a02:2028:506:bf01:fd55:329d:caf8:259) a quitté (Remote host closed the connection) 2018-04-09 04:21:27 --> protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-09 07:23:50 <-- protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2) 2018-04-09 07:46:28 --> protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-09 08:19:33 <-- yawkat (~yawkat@cats.coffee) a quitté (Ping timeout: 260 seconds) 2018-04-09 08:21:07 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: Connection reset by peer) 2018-04-09 08:21:13 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-09 08:32:11 --> OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a rejoint #mcdevs 2018-04-09 08:38:04 --> yawkat (~yawkat@cats.coffee) a rejoint #mcdevs 2018-04-09 08:43:22 <-- protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2) 2018-04-09 09:13:17 --> protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-09 09:42:33 <-- OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a quitté (Ping timeout: 240 seconds) 2018-04-09 11:07:05 <-- yawkat (~yawkat@cats.coffee) a quitté (Ping timeout: 255 seconds) 2018-04-09 11:20:44 --> yawkat (~yawkat@cats.coffee) a rejoint #mcdevs 2018-04-09 12:26:43 --> itsme_ (~textual@x4dbdc6d1.dyn.telefonica.de) a rejoint #mcdevs 2018-04-09 13:25:25 --> itsme__ (~textual@x4dbef981.dyn.telefonica.de) a rejoint #mcdevs 2018-04-09 13:27:29 <-- itsme_ (~textual@x4dbdc6d1.dyn.telefonica.de) a quitté (Ping timeout: 255 seconds) 2018-04-09 13:30:11 <-- redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: No route to host) 2018-04-09 13:31:15 --> redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-09 14:01:31 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: Connection reset by peer) 2018-04-09 14:05:09 --> redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-09 14:35:20 <-- itsme__ (~textual@x4dbef981.dyn.telefonica.de) a quitté (Quit: My Mac Pro has gone to sleep. ZZZzzz…) 2018-04-09 15:43:07 --> itsme_ (~textual@x4dbef981.dyn.telefonica.de) a rejoint #mcdevs 2018-04-09 16:16:05 --> GeorgH93 (~GeorgH93@pD9FEB139.dip0.t-ipconnect.de) a rejoint #mcdevs 2018-04-09 17:42:58 <-- Dykam (~Dykam@37.139.10.7) a quitté (Remote host closed the connection) 2018-04-09 17:55:17 --> Dykam (~Dykam@37.139.10.7) a rejoint #mcdevs 2018-04-09 18:03:25 --> Jan1902 (~quassel@2a02:2028:70f:301:9c5a:176a:47c9:1c99) a rejoint #mcdevs 2018-04-09 18:04:50 Jan1902 Does anyone else have an Idea to why the Receiving and Sending of floats and doubles might be working incorrectly using c#'s BinaryReader/Writer aswell as a BigEndian version? 2018-04-09 18:06:09 pokechu22 Hm, hold on, I actually know another client in C# and I can check the implementation 2018-04-09 18:06:52 Jan1902 Okay, that would be nice of you, or otherwhise just send me a link so i can have look at it myself :) 2018-04-09 18:08:46 pokechu22 https://github.com/ORelio/Minecraft-Console-Client/blob/master/MinecraftClient/Protocol/Handlers/Protocol18.cs#L1313-L1323 -- looks like they use BitConverter.GetBytes, and then reverse the array 2018-04-09 18:12:58 Jan1902 That seems quite easy, ill give that a shot 2018-04-09 18:20:07 Jan1902 This seems to work just fine, so it definetely was a problem with the endianess but what confuses me is why the BigEndianBinaryWriter didnt work 2018-04-09 18:43:22 <-- itsme_ (~textual@x4dbef981.dyn.telefonica.de) a quitté (Quit: Textual IRC Client: www.textualapp.com) 2018-04-09 19:02:48 <-- GeorgH93 (~GeorgH93@pD9FEB139.dip0.t-ipconnect.de) a quitté (Quit: Leaving) 2018-04-09 19:49:29 Aikar Grum: speaking of vanilla not having async chunk loading... isnt it about time it finally gets it. 2018-04-09 19:53:37 --> winger_sendon (~winger@123.176.14.29) a rejoint #mcdevs 2018-04-09 20:16:46 <-- Jan1902 (~quassel@2a02:2028:70f:301:9c5a:176a:47c9:1c99) a quitté (Remote host closed the connection) 2018-04-09 20:44:09 <-- winger_sendon (~winger@123.176.14.29) a quitté (Quit: Leaving) 2018-04-09 21:16:45 --> itsme_ (~textual@x4dbef981.dyn.telefonica.de) a rejoint #mcdevs 2018-04-09 21:18:53 <-- protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2) 2018-04-09 21:37:11 <-- Dadido3 (~quassel@p200300EF43C49E00D9365C1919C68AD7.dip0.t-ipconnect.de) a quitté (Read error: Connection reset by peer) 2018-04-09 21:38:24 --> Dadido3 (~quassel@p200300EF43C49E00C92C4BF4398B22B5.dip0.t-ipconnect.de) a rejoint #mcdevs 2018-04-09 21:38:32 <-- itsme_ (~textual@x4dbef981.dyn.telefonica.de) a quitté (Quit: Textual IRC Client: www.textualapp.com) 2018-04-09 21:43:57 <-- minecrell_ (~minecrell@irc.minecrell.net) a quitté (Ping timeout: 240 seconds) 2018-04-09 21:45:19 --> minecrell (~minecrell@irc.minecrell.net) a rejoint #mcdevs 2018-04-09 21:49:42 <-- minecrell (~minecrell@irc.minecrell.net) a quitté (Ping timeout: 255 seconds) 2018-04-09 21:49:55 --> minecrell (~minecrell@irc.minecrell.net) a rejoint #mcdevs 2018-04-09 23:44:06 --> protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-09 23:58:03 <-- EW8GU (admin@86.57.137.25) a quitté (Ping timeout: 240 seconds) 2018-04-10 00:01:28 --> EW8GU (admin@ho.by) a rejoint #mcdevs 2018-04-10 01:38:37 <-- protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2) 2018-04-10 02:09:01 <-- justJanne (~justJanne@lithium.kuschku.de) a quitté (Quit: So, if you care to find me, look to the western sky. As someone told me lately, everyone deserves a chance to fly.) 2018-04-10 02:09:35 --> justJanne (~justJanne@lithium.kuschku.de) a rejoint #mcdevs 2018-04-10 02:11:35 <-- justJanne (~justJanne@lithium.kuschku.de) a quitté (Remote host closed the connection) 2018-04-10 02:11:46 --> justJanne (~justJanne@lithium.kuschku.de) a rejoint #mcdevs 2018-04-10 02:27:27 --> protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-10 03:42:59 --> Black_Hole (~BlackHole@p200300E753E57300486CFED3952883F1.dip0.t-ipconnect.de) a rejoint #mcdevs 2018-04-10 03:46:13 <-- Black-Hole (~BlackHole@p200300E753E57300D5E9CBB664C3200A.dip0.t-ipconnect.de) a quitté (Ping timeout: 260 seconds) 2018-04-10 05:31:02 --> YukonAppleGeek (~Yukon@sfo01.yukon.io) a rejoint #mcdevs 2018-04-10 05:47:12 <-- YukonAppleGeek (~Yukon@sfo01.yukon.io) a quitté (Quit: ZNC - http://znc.in) 2018-04-10 05:47:33 --> YukonAppleGeek (~Yukon@sfo01.yukon.io) a rejoint #mcdevs 2018-04-10 06:02:53 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-10 06:06:03 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 255 seconds) 2018-04-10 06:06:03 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2018-04-10 07:00:04 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-10 07:03:23 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 260 seconds) 2018-04-10 07:03:23 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2018-04-10 08:57:48 --> OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a rejoint #mcdevs 2018-04-10 09:38:39 <-- ScruffyRules (~Scruff@2001:19f0:5800:8483:5400:ff:fe06:49ea) a quitté (*.net *.split) 2018-04-10 09:38:40 <-- Zachoz (~Zachoz@2001:19f0:5800:8483:5400:ff:fe06:49ea) a quitté (*.net *.split) 2018-04-10 09:39:26 --> Zachoz (~Zachoz@2001:19f0:5800:8483:5400:ff:fe06:49ea) a rejoint #mcdevs 2018-04-10 09:39:56 --> ScruffyRules (~Scruff@2001:19f0:5800:8483:5400:ff:fe06:49ea) a rejoint #mcdevs 2018-04-10 10:18:33 --> itsme_ (~textual@x4dbef981.dyn.telefonica.de) a rejoint #mcdevs 2018-04-10 11:29:55 <-- itsme_ (~textual@x4dbef981.dyn.telefonica.de) a quitté (Quit: My Mac Pro has gone to sleep. ZZZzzz…) 2018-04-10 11:51:17 --> itsme_ (~textual@x4dbef981.dyn.telefonica.de) a rejoint #mcdevs 2018-04-10 12:14:32 <-- itsme_ (~textual@x4dbef981.dyn.telefonica.de) a quitté (Quit: My Mac Pro has gone to sleep. ZZZzzz…) 2018-04-10 12:37:51 --> itsme_ (~textual@x4dbef981.dyn.telefonica.de) a rejoint #mcdevs 2018-04-10 13:02:50 <-- itsme_ (~textual@x4dbef981.dyn.telefonica.de) a quitté (Quit: Textual IRC Client: www.textualapp.com) 2018-04-10 15:01:24 +Amaranth Aikar: I think their goal was to get async generation at the same time 2018-04-10 15:01:41 +Amaranth If you have that too the code gets simpler for the chunk loading part 2018-04-10 16:30:02 <-- _MylesC (sid163914@gateway/web/irccloud.com/x-nojcicxtwixvcinx) a quitté (Quit: ~) 2018-04-10 16:30:14 --> _MylesC (sid163914@gateway/web/irccloud.com/x-qdzakjozfpjlkjqe) a rejoint #mcdevs 2018-04-10 20:30:35 <-- AlphaBlend (Vector@cpe-66-74-178-84.socal.res.rr.com) a quitté (Ping timeout: 256 seconds) 2018-04-10 20:30:57 --> AlphaBlend (Vector@cpe-66-74-178-84.socal.res.rr.com) a rejoint #mcdevs 2018-04-10 20:54:08 <-- justJanne (~justJanne@lithium.kuschku.de) a quitté (Quit: So, if you care to find me, look to the western sky. As someone told me lately, everyone deserves a chance to fly.) 2018-04-10 20:55:29 --> justJanne (~justJanne@lithium.kuschku.de) a rejoint #mcdevs 2018-04-10 21:01:03 +Grum Aikar: what vanilla feature needs async chunkloading? 2018-04-10 21:01:29 Aikar the "help the server not lag" feature 2018-04-10 21:01:36 <-- Prf_Jakob (jakob@volt/developer/jakob) a quitté (Remote host closed the connection) 2018-04-10 21:01:58 Aikar disk io on main hurts 2018-04-10 21:09:16 <-- protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2) 2018-04-10 21:13:02 +Grum yes except all chunks requested have to be there *now* 2018-04-10 21:27:31 +ammar2 not when a player is moving around 2018-04-10 21:27:40 +ammar2 not for all definitions of "now" anyway 2018-04-10 21:27:48 +ammar2 network means they'll receive it at a delay anyway 2018-04-10 21:30:39 +Grum yup players moving around is a decent reason 2018-04-10 21:31:07 +Grum that and generating an area when you start the server 2018-04-10 21:31:38 +ammar2 generating an area, sure 2018-04-10 21:32:00 +ammar2 but when you're walking around and the server has to send a chunk that's view-radius chunks away, there isn't particularly a need to have it now 2018-04-10 21:35:25 pokechu22 Yeah, but what about redstone going between chunk borders -- for timing to make sense, that needs to be loaded sync 2018-04-10 21:35:39 pokechu22 Otherwise the behavior isn't deterministic 2018-04-10 21:36:26 +ammar2 meh, redstone on chunk borders is already horribly painful 2018-04-10 21:36:43 +ammar2 and craftbukkit had async chunk loading for the last 2-3 years of its life and there were no major complaints 2018-04-10 21:37:09 pokechu22 I feel like it's more stable nowadays but I'm not 100% sure 2018-04-10 21:39:28 pokechu22 Also, I do remember people complaining about redstone in craftbukkit a lot back then -- but I don't remember the details 2018-04-10 21:40:13 +ammar2 in craftbukkit? craftbukkit tried to maintain vanilla behavior at all costs pretty much 2018-04-10 21:40:16 +ammar2 maybe you're thinking of spigot 2018-04-10 21:40:35 pokechu22 Years back, I don't fully remember the details... 2018-04-10 21:40:35 +ammar2 pokechu22: https://bugs.mojang.com/browse/MC-711? this is still open 2018-04-10 21:41:19 pokechu22 Just cases of things that worked in vanilla not working in craftbukkit -- but I think this was like 5 years ago, or back in beta? 2018-04-10 21:41:20 +ammar2 redstone across chunks is buggy anyway, it seems weird to sacrifice some form of determinism there for a rather substantial performance benefit 2018-04-10 21:42:10 pokechu22 Aha, found it! 2018-04-10 21:42:21 pokechu22 Err, well, not the same "it" I was thinking of... but... 2018-04-10 21:43:07 pokechu22 https://hub.spigotmc.org/stash/projects/SPIGOT/repos/craftbukkit/commits/24143ef6a16bc8e079c8fdc950895a954a98273e - the craftbukkit implementation (yours?) actually did async loading for players, but sync loading for world stuff and plugins 2018-04-10 21:43:43 +ammar2 yeah, player loading is really the only viable target 2018-04-10 21:44:22 +ammar2 you can't do it for plugins and the world requesting chunks without examining every load path 2018-04-10 21:44:29 +ammar2 and seeing if its viable to be done on a callback 2018-04-10 21:44:41 +ammar2 which is way too much work in terms of the craftbukkit changes involved 2018-04-10 21:45:25 pokechu22 Right, and if it was done sync for e.g. redstone/other such things (pistons?) that wouldn't cause any issues 2018-04-10 21:45:45 +ammar2 well redstone updates never cause a chunk load anyway 2018-04-10 21:45:57 +ammar2 pistons, maybe, I don't remember 2018-04-10 21:46:25 pokechu22 If a piston were pushing into an unloaded chunk, it'd only make sense if it loaded it -- and I think redstone is able to go into unloaded chunks for a while. But I'll confess I don't know the details of it 2018-04-10 21:46:53 +ammar2 redstone updates definitely check if the chunk is loaded before calling getChunk which causes the load 2018-04-10 21:46:58 +ammar2 from what I recall 2018-04-10 21:47:07 +ammar2 its been a while since I've looked at the code 2018-04-10 21:47:17 +ammar2 pistons, water flow, new features idk about those 2018-04-10 21:48:51 pokechu22 Wiki says for 1.3.1 (https://minecraft.gamepedia.com/1.3.1#Fixes): "Fixed redstone updates not propagating through unloaded chunks." -- which I'd assume means redstone loads chunks 2018-04-10 21:49:22 pokechu22 and there's all this mess with lazy chunks and stuff 2018-04-10 21:52:42 +ammar2 what is a lazy chunk 2018-04-10 22:02:44 pokechu22 Not 100% sure of the details, but it's a chunk that processes blocks but not entities, and I think there's a 2-chunk margin around the view distance that is lazy 2018-04-10 22:04:14 --> protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-10 22:48:16 --> Prf_Jakob (jakob@void-network.org) a rejoint #mcdevs 2018-04-10 22:49:43 <-- Prf_Jakob (jakob@void-network.org) a quitté (Changing host) 2018-04-10 22:49:43 --> Prf_Jakob (jakob@volt/developer/jakob) a rejoint #mcdevs 2018-04-10 22:49:43 -- Mode #mcdevs [+v Prf_Jakob] par ChanServ 2018-04-10 23:05:38 Aikar yup players moving around is a decent reason - this is the only case we enact Async Chunk loading atm in non vanilla implementations, and covers reducing hits from a majority of loads. a teleport yeah will trigger a sync load, but the entire radius around them can then be async. 2018-04-10 23:07:56 Aikar and ammar2 i think you misinterpreted grum (unless I did), i think he was agreeing that moving + preloading spawn are actually valid places to async it. 2018-04-10 23:08:09 +ammar2 oh I see 2018-04-10 23:08:31 +ammar2 yeah that was probably what he was going for now that I re-read it 2018-04-10 23:08:32 Aikar give the player isnt able to move so fast (hax) into a pending load chunk 2018-04-10 23:08:43 Aikar but CB's impl at least takes care of that sill 2018-04-10 23:08:50 Aikar still* 2018-04-10 23:08:54 +ammar2 heh even with like max speed flying it loads fast enough that it doesn't matter 2018-04-10 23:09:00 +ammar2 not sure about hax tho 2018-04-10 23:09:15 pokechu22 Well, there are cases with complex weird redstone things that can do it -- but then the chunk would be loaded from the machine, I'd think 2018-04-10 23:09:29 Aikar pokechu22: yep that does happen in CB+ 2018-04-10 23:10:06 Aikar everything is by default sync, player chunk map is the only thing that explicitly sets the "you can load async, tell me here when ready" approach 2018-04-10 23:10:53 Aikar and if the async load comes in, and somethings already triggered a sync load before the async finished, the async one is discarded 2018-04-10 23:11:08 pokechu22 Was just about to ask about that 2018-04-10 23:11:30 Aikar its worked perfectly fine for years 2018-04-10 23:11:37 +Amaranth ammar2: CraftBukkit breaks redstone across chunk boundaries 2018-04-10 23:12:02 +Amaranth Because when vanilla switched to block updates being able to load chunks it caused runaway chunk leaks we couldn't figure out 2018-04-10 23:12:07 Aikar Amaranth: you mean into unloaded chunks right? 2018-04-10 23:12:21 +Amaranth So we flipped that toggle back to false, added a chunk GC, and never went back to figure it out :D 2018-04-10 23:12:23 +Amaranth Yeah 2018-04-10 23:12:44 Aikar Amaranth: the toggle was completely removed in 1.9 iirc 2018-04-10 23:12:51 +Amaranth Huh 2018-04-10 23:12:57 Aikar so now lots of things do trigger chunk loads 2018-04-10 23:13:10 Aikar weve been battling that left and right in paper to stop unnecessary ones 2018-04-10 23:13:14 +Amaranth In any case anything other than a player walking around would trigger a sync chunk load so if that system otherwise worked CB wouldn't break it 2018-04-10 23:13:34 Aikar ie fire in the nether is a big source of the nether staying loaded 2018-04-10 23:13:51 +Amaranth Ah, you're missing the "stop ticking chunks in empty worlds" flag 2018-04-10 23:14:17 Aikar even if it wasnt empty, an idle region should still be able to unload 2018-04-10 23:14:20 +Amaranth We also forced that to always tick because plugins loading chunks in empty worlds would leak them since unloading happens in a future tick 2018-04-10 23:14:44 +Amaranth Well sure but if it didn't tick you wouldn't get it to keep spreading and it'd only cost RAM 2018-04-10 23:14:49 Aikar it does still unload all chunks in empty worlds, but fire was triggering the "I'm still in use" flag 2018-04-10 23:15:02 pokechu22 Ah, yeah, fire in the nether is an interesting one 2018-04-10 23:15:12 +Amaranth aka vanilla probably has the same bug with since it doesn't tick empty worlds and has a chunk GC it'll clean it up eventually 2018-04-10 23:15:17 Aikar ah, yeah i dont think paper/spigot has anything to stop ticking, i thought you meant the unload chunks in empty world setting 2018-04-10 23:15:37 Aikar actually thats not even a setting ,thats forced 2018-04-10 23:15:37 pokechu22 https://bugs.mojang.com/browse/MC-119994 -- does affect vanilla 2018-04-10 23:16:01 +Amaranth mikeprimm flipped that flag to always tick because otherwise dynmap loaded every chunk in a world and they stayed loaded 2018-04-10 23:16:22 Aikar https://github.com/PaperMC/Paper/blob/master/Spigot-Server-Patches/0271-Prevent-Frosted-Ice-from-loading-holding-chunks.patch frosted ice also been causing the issue 2018-04-10 23:16:23 +Amaranth The real solution is plugin chunk load/unload should reset the vanilla timer for how many ticks to keep ticking an empty world 2018-04-10 23:16:41 +Amaranth Since vanilla already ticks like 100 ticks after the last player leaves to ensure things get cleaned up 2018-04-10 23:18:45 Aikar you keep saying empty world :P but thats not good enough for servers that arent empty lol 2018-04-10 23:19:08 Aikar best solution is patches like ^ to keep them from being tripped in first place 2018-04-10 23:19:48 Aikar redstone i can see being a bit better to allow it to load chunks, but fire, ice, etc... 2018-04-10 23:19:59 +Amaranth Well if players are running around in the nether chunk load from them should trump the little bit you get from fire and such before chunk GC goes and cleans it up 2018-04-10 23:20:01 Aikar but it is bad on performance 2018-04-10 23:20:23 +Amaranth Or at least it would if all chunk load was sync or async 2018-04-10 23:20:24 Aikar the issue is that chunks stay loaded that the players arent even anywhere near anymore 2018-04-10 23:20:42 +Amaranth Them staying loaded is weird and should be looked at 2018-04-10 23:20:43 Aikar so as they explore nether, chunks load, then the fire keeps them held loaded 2018-04-10 23:20:50 +Amaranth Oh, I guess you disabled the autosave too 2018-04-10 23:21:01 Aikar https://github.com/PaperMC/Paper/blob/master/Spigot-Server-Patches/0115-Prevent-Fire-from-loading-chunks.patch solves the nether issue 2018-04-10 23:21:02 +Amaranth Since it tends to make large servers hiccup every 45 seconds or whatever 2018-04-10 23:21:10 Aikar i fixed auto save in paper 2018-04-10 23:21:13 +Amaranth The autosave is where the chunk GC lives too 2018-04-10 23:21:14 Aikar its now super smooth 2018-04-10 23:21:23 Aikar its all super incremental now 2018-04-10 23:21:32 +Amaranth Preventing fire from loading chunks break vanilla behavior though :D 2018-04-10 23:21:48 Aikar a buggy behavior 2018-04-10 23:22:14 +Amaranth Pretty sure I've seen "chunk loader" machines that abuse fire, water, and so on 2018-04-10 23:22:30 Aikar well my server is vanilla-ish, my players have never complained lol 2018-04-10 23:22:48 +Amaranth So first verify if vanilla does _exactly_ the same thing because I have a feeling it doesn't 2018-04-10 23:22:51 Aikar https://github.com/PaperMC/Paper/blob/master/Spigot-Server-Patches/0153-Auto-Save-Improvements.patch this is my auto save fixes 2018-04-10 23:23:16 +Amaranth Then perhaps add a toggle to let people trade vanilla behavior for performance 2018-04-10 23:23:43 +Amaranth Note that half your bugs in this area probably came from me trying to do the same thing you're doing now 2018-04-10 23:24:08 Aikar are you talking about the fire, or auto save? 2018-04-10 23:24:10 +Amaranth When vanilla didn't intentionally allow blocks to load chunks I went around trying to stop the server from _ever_ letting blocks load chunks 2018-04-10 23:24:34 Aikar i cant recall a single bug report on "fire isnt loading chunks when i want it to" 2018-04-10 23:24:40 Aikar its really not something people do 2018-04-10 23:24:53 +Amaranth iirc in the end I removed most of that because it caused billions of HashMap lookups 2018-04-10 23:24:59 pokechu22 I don't think I've seen intentional chunk loaders with fire -- only with hoppers 2018-04-10 23:25:00 Aikar and satisfying one fringe players use case at the detriment to everyone else on the server is bad 2018-04-10 23:25:27 +Amaranth Of course checking if neighbor chunks are loaded is faster in CB than back then 2018-04-10 23:25:56 Aikar Amaranth: my fixes are using a modified version of getType that does getChunkIfLoaded, so it was always going to do that hashmap look up from the chunk map, but the difference is that it doesnt then go load the chunk if missing 2018-04-10 23:25:58 +Amaranth Ah but you aren't looking at neighbor chunks, you're going from BlockPos to lookup 2018-04-10 23:26:11 Aikar getType -> getTypeIfLoaded 2018-04-10 23:27:21 +Amaranth I've always found it sad how much of MineCraft lives in World 2018-04-10 23:27:46 +Amaranth World should exist as a means to communicate things/actions moving from one Chunk to another 2018-04-10 23:28:00 +Amaranth That'd make things a lot more efficient here too :P 2018-04-10 23:28:57 Aikar i wish entities and such ticked by chunks too, im sure cpu cache effeciency would be improved keeping working 1 chunk at a time 2018-04-10 23:30:51 Aikar btw wanted to note grum, that I and many others have explicitly licensed our patches MIT - https://github.com/PaperMC/Paper/blob/master/LICENSE.md - i know this is all legally grey in first place, but hopefully that keeps it super clean for mojang to just port any work weve done back to vanilla w/o any legal questions. 2018-04-10 23:31:36 Aikar im all for my work being put directly in vanilla, less for us to maintain heh 2018-04-10 23:35:55 pokechu22 Oh, and I feel the need to comment on this: "and satisfying one fringe players use case at the detriment to everyone else on the server is bad" is a somewhat bad mentality, as it does lead to less emergent behavior -- it's fine when it's optional, but breaking behaviors that previously worked (e.g. with chunkloading/spawn chunks) for everyone is not great. To take it to an (illogical) extreme, you could have 2018-04-10 23:35:57 pokechu22 a very high performance server that doesn't let people place/break blocks and only gives a superflat world without entities -- no lag, but not super interesting 2018-04-10 23:36:37 Aikar i didnt mean breaking spawn chunks, but chunks that SHOULD be able to unload with no activity in them, but one player wants to use a bug to force keep them open 2018-04-10 23:37:42 Aikar its also unrealistic to try to support abusive bugs. what happens when 50 players all want to use the bug and melts your server. 2018-04-10 23:37:53 pokechu22 Defining "bug" and "mechanic" (e.g. loading with fire/loading with hoppers) is hard though -- in this case, I definitely agree fire's a problem, but other things it varies 2018-04-10 23:39:03 pokechu22 I'll note that you might not have gotten complaints about some such changes, because the players who might have been affected don't actually use paper (either sticking with strictly vanilla or craftbukkit). And that's probably fine 2018-04-10 23:39:33 Aikar hoppers i can agree when not abused can be useful, if they have a clear temporary workload 2018-04-10 23:40:20 Aikar but in those cases, as they move towards the hopper, the chunks load, and by time they see the end of the pipeline, everythings there 2018-04-10 23:40:45 Aikar but if its not, they just have to wait for stuff to finish moving 2018-04-10 23:40:54 Aikar its really not a big deal 2018-04-10 23:41:15 Aikar i dont think hoppers load chunks on my server, nor have i got complaints there. and trust me, people build all kinds of item sorters and farms 2018-04-10 23:41:43 Aikar and i have a low view distance 2018-04-10 23:42:13 Aikar i think players more expect a hopper that disappears into nothing to not be doing anything 2018-04-10 23:42:34 Aikar its reasonable for them to expect 'if you want your hopper to do work, you need to be near it to keep it loaded' 2018-04-10 23:42:39 pokechu22 Yeah, I feel like this would be something I might be able to debate better if I knew more about it -- I don't know much about chunk loading and mechanics 2018-04-10 23:42:54 pokechu22 (the hopper chunk loading was actually about using hoppers to keep chunks loaded so a farm in them runs -- but I don't know if that still works or how it worked) 2018-04-10 23:43:25 Aikar outside of servers that go into like 2-3 view distance, you generally dont even need to hold chunks open 2018-04-10 23:43:39 Aikar outside of super large iron golem farms 2018-04-10 23:44:14 Aikar and thats going into what i consider abusive. you have to set limits. if you let people keep going bigger, then you gotta let everyone go bigger, and then your stuck supporting a workload you cant handle 2018-04-10 23:44:40 Aikar players having limits set to view distance is very reasonable 2018-04-10 23:45:43 Aikar sure its easy to be unlimited in what you do in an SP/3 player server where its just you or your local group suffering from performance issues 2018-04-10 23:45:56 Aikar but in a multiplayer context, i cant allow 1 player to cause harm to the rest of the players 2018-04-10 23:46:52 Aikar its unfair when 1 persons desire of larger farm causes lag issues to everyone else making their time playing the game unfun. 2018-04-10 23:47:07 pokechu22 Maybe the issue is that in the case I'm thinking of, _all_ the players plan to have large farms, and probably chose the server host and stuff with that in mind 2018-04-10 23:47:53 pokechu22 If it's just one player doing stuff, then that's different for sure 2018-04-10 23:48:08 Aikar in my case, farmers are not the majority 2018-04-10 23:48:14 Aikar but, they are the majority users of the cpu 2018-04-10 23:49:18 Aikar i have a pretty open play style, where its base survival elements + a plot world w/ economy. so some players choose to make large farms in survival, then take the goods back to town (plots) to sell. 2018-04-11 02:33:06 <-- C4K3 (~C4K3@0127801301.0.fullrate.ninja) a quitté (Ping timeout: 265 seconds) 2018-04-11 02:39:39 --> C4K3 (~C4K3@0127801301.0.fullrate.ninja) a rejoint #mcdevs 2018-04-11 03:17:49 --> opekktar_ (~opekktar@ip124.67-202-83.static.steadfastdns.net) a rejoint #mcdevs 2018-04-11 03:29:20 <-- opekktar_ (~opekktar@ip124.67-202-83.static.steadfastdns.net) a quitté (Remote host closed the connection) 2018-04-11 03:54:52 <-- justJanne (~justJanne@lithium.kuschku.de) a quitté (Quit: So, if you care to find me, look to the western sky. As someone told me lately, everyone deserves a chance to fly.) 2018-04-11 03:55:05 --> justJanne (~justJanne@lithium.kuschku.de) a rejoint #mcdevs 2018-04-11 03:55:17 <-- justJanne (~justJanne@lithium.kuschku.de) a quitté (Client Quit) 2018-04-11 04:04:33 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 255 seconds) 2018-04-11 04:15:10 --> justJanne (~justJanne@lithium.kuschku.de) a rejoint #mcdevs 2018-04-11 04:18:41 <-- justJanne (~justJanne@lithium.kuschku.de) a quitté (Client Quit) 2018-04-11 04:18:52 --> justJanne (~justJanne@lithium.kuschku.de) a rejoint #mcdevs 2018-04-11 04:22:25 --> redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-11 05:15:34 --> Dadido3_ (~quassel@p200300EF43C49E00A1A735855C5CE8D1.dip0.t-ipconnect.de) a rejoint #mcdevs 2018-04-11 05:17:28 <-- Dadido3 (~quassel@p200300EF43C49E00C92C4BF4398B22B5.dip0.t-ipconnect.de) a quitté (Ping timeout: 260 seconds) 2018-04-11 06:04:36 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-11 06:08:13 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 260 seconds) 2018-04-11 06:08:13 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2018-04-11 10:51:05 --> itsme (~textual@x4e303f8a.dyn.telefonica.de) a rejoint #mcdevs 2018-04-11 11:46:04 <-- itsme (~textual@x4e303f8a.dyn.telefonica.de) a quitté (Quit: Textual IRC Client: www.textualapp.com) 2018-04-11 14:23:54 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: Connection reset by peer) 2018-04-11 14:25:30 --> redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-11 16:25:12 <-- Fador (fador@hentai.fi) a quitté (Quit: Server migration ->) 2018-04-11 16:26:15 --> Jan1902 (~quassel@2a02:2028:574:1201:9986:6fde:b071:1fee) a rejoint #mcdevs 2018-04-11 16:33:17 Jan1902 Just started doing Encryption for my Client, and now i got confused about the Generation of the Hash by the Client, since the Documentation says, youre supposed to hash the Server Id string from the request packet, which is empty, as mentioned at the corresponding packet documentation, is there a reason to this ? 2018-04-11 16:50:56 --> GingerGeek (~Zed@droplet.gingergeek.co.uk) a rejoint #mcdevs 2018-04-11 16:50:56 <-- GingerGeek (~Zed@droplet.gingergeek.co.uk) a quitté (Changing host) 2018-04-11 16:50:56 --> GingerGeek (~Zed@unaffiliated/gingergeek) a rejoint #mcdevs 2018-04-11 17:06:57 --> Fador (fador@hentai.fi) a rejoint #mcdevs 2018-04-11 17:06:57 -- Mode #mcdevs [+v Fador] par ChanServ 2018-04-11 18:13:28 pokechu22 Apparently there's a snapshot and Botched missed it :/ 2018-04-11 18:13:53 pokechu22 I think the server ID was used for something back years ago (but I don't know much about protocol encryption) 2018-04-11 18:22:32 Not-10ef [Burger] New data now avaliable for 18w15a: 2018-04-11 18:22:33 Not-10ef [Burger] Diff from 18w14b: http://pokechu22.github.io/Burger/diff_18w14b_18w15a.html (http://pokechu22.github.io/Burger/diff_18w14b_18w15a.json) 2018-04-11 18:22:35 Not-10ef [Burger] Full data: http://pokechu22.github.io/Burger/18w15a.html (http://pokechu22.github.io/Burger/18w15a.json) 2018-04-11 18:22:49 pokechu22 (really need to fix up numeric IDs in diffs, it's definitely a mess) 2018-04-11 18:39:12 Jan1902 Okay then, thanks :) 2018-04-11 18:39:18 <-- Jan1902 (~quassel@2a02:2028:574:1201:9986:6fde:b071:1fee) a quitté (Remote host closed the connection) 2018-04-11 19:50:06 --> itsme (~textual@x590f24b1.dyn.telefonica.de) a rejoint #mcdevs 2018-04-11 21:56:08 <-- Anna (~Anna@borealis.voxelstorm.com) a quitté (Quit: Reconnecting) 2018-04-11 21:56:15 --> Anna (~Anna@borealis.voxelstorm.com) a rejoint #mcdevs 2018-04-11 22:05:47 --> Jan1902 (~quassel@2a02:2028:574:1201:51ee:df2:6c86:8c42) a rejoint #mcdevs 2018-04-11 22:22:12 --> MasterGberry_ (sid92636@gateway/web/irccloud.com/x-vnlyifcmwzbhgook) a rejoint #mcdevs 2018-04-11 22:22:31 --> hansihe_ (sid106603@gateway/web/irccloud.com/x-vfdibignikromcmn) a rejoint #mcdevs 2018-04-11 22:23:52 --> I9hdkill_ (~quassel@2001:41d0:d:1cb7::) a rejoint #mcdevs 2018-04-11 22:28:13 --> Grum_ (~grum@irc.grum.nl) a rejoint #mcdevs 2018-04-11 22:28:13 -- Mode #mcdevs [+v Grum_] par ChanServ 2018-04-11 22:28:43 --> GunfighterJ_ (gunfighter@2607:5300:60:34b:d::43) a rejoint #mcdevs 2018-04-11 22:29:40 <-- I9hdkill (~quassel@2001:41d0:d:1cb7::) a quitté (*.net *.split) 2018-04-11 22:29:40 <-- GunfighterJ (gunfighter@2607:5300:60:34b:d::43) a quitté (*.net *.split) 2018-04-11 22:29:40 <-- hansihe (sid106603@gateway/web/irccloud.com/x-ypmpnfcihgwoneau) a quitté (*.net *.split) 2018-04-11 22:29:40 <-- MasterGberry (sid92636@gateway/web/irccloud.com/x-ydkprreypcbgcblc) a quitté (*.net *.split) 2018-04-11 22:29:41 <-- Grum (~grum@irc.grum.nl) a quitté (*.net *.split) 2018-04-11 22:29:41 -- GunfighterJ_ est maintenant connu sous le nom GunfighterJ 2018-04-11 22:29:47 -- MasterGberry_ est maintenant connu sous le nom MasterGberry 2018-04-11 22:30:07 -- Grum_ est maintenant connu sous le nom Grum 2018-04-11 22:30:11 -- hansihe_ est maintenant connu sous le nom hansihe 2018-04-11 22:45:19 --> winger_sendon (~winger@123.176.14.112) a rejoint #mcdevs 2018-04-12 00:21:15 <-- andreymal (~chatmovil@2a01:4f8:c17:335f::2) a quitté #mcdevs 2018-04-12 00:58:10 <-- Jan1902 (~quassel@2a02:2028:574:1201:51ee:df2:6c86:8c42) a quitté (Remote host closed the connection) 2018-04-12 01:15:51 <-- winger_sendon (~winger@123.176.14.112) a quitté (Quit: Leaving) 2018-04-12 01:58:28 <-- itsme (~textual@x590f24b1.dyn.telefonica.de) a quitté (Quit: Textual IRC Client: www.textualapp.com) 2018-04-12 02:44:51 <-- OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a quitté (Read error: Connection reset by peer) 2018-04-12 02:45:36 --> OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a rejoint #mcdevs 2018-04-12 04:26:57 tktech pokechu22, if I can suggest a change to the .craftitem class, add "word-wrap: break-word;" and remove line-height: 30px; 2018-04-12 04:27:56 tktech https://i.imgur.com/OAafmdD.png vs https://i.imgur.com/f5tZ6pF.png 2018-04-12 04:28:59 pokechu22 There was originally supposed to be a sprite there, and then the numeric ID... but yeah, with the text ID there, that's probably for the best... will try it out 2018-04-12 04:31:43 Not-10ef [BurgerVitrine] Pokechu22 pushed 1 commit to master [+0/-0/±1] https://git.io/vxAMd 2018-04-12 04:31:45 Not-10ef [BurgerVitrine] Pokechu22 68bbb70 - Use word wrapping on .craftitem Per tktech's suggestion 2018-04-12 05:09:22 <-- Krenair (~alex@wikimedia/Krenair) a quitté (Ping timeout: 246 seconds) 2018-04-12 05:11:27 --> Krenair (~alex@znc.alexmonk.uk) a rejoint #mcdevs 2018-04-12 05:11:27 <-- Krenair (~alex@znc.alexmonk.uk) a quitté (Changing host) 2018-04-12 05:11:27 --> Krenair (~alex@wikimedia/Krenair) a rejoint #mcdevs 2018-04-12 06:00:58 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: Connection reset by peer) 2018-04-12 06:02:36 --> redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-12 06:03:58 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-12 06:08:03 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 265 seconds) 2018-04-12 06:09:35 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2018-04-12 08:04:12 <-- ashka (~postmaste@pdpc/supporter/active/ashka) a quitté (Ping timeout: 240 seconds) 2018-04-12 08:05:02 --> ashka (~postmaste@62-210-251-94.rev.poneytelecom.eu) a rejoint #mcdevs 2018-04-12 08:05:02 <-- ashka (~postmaste@62-210-251-94.rev.poneytelecom.eu) a quitté (Changing host) 2018-04-12 08:05:02 --> ashka (~postmaste@pdpc/supporter/active/ashka) a rejoint #mcdevs 2018-04-12 08:23:44 MiniDigger it should just ignore numeric id changes in the diff and instead add a line stating that ids have been shifted or smth 2018-04-12 09:12:09 <-- |Blaze|_ (~scott@184.70.189.74) a quitté (Ping timeout: 276 seconds) 2018-04-12 09:15:48 --> |Blaze| (~scott@184.70.189.74) a rejoint #mcdevs 2018-04-12 09:24:04 kashike +1 2018-04-12 09:43:41 <-- protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Ping timeout: 268 seconds) 2018-04-12 09:46:14 --> protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-12 10:18:15 <-- Fador (fador@hentai.fi) a quitté (Quit: Reboot) 2018-04-12 10:20:19 --> Fador (fador@hentai.fi) a rejoint #mcdevs 2018-04-12 10:20:20 -- Mode #mcdevs [+v Fador] par ChanServ 2018-04-12 11:06:33 <-- OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a quitté (Ping timeout: 256 seconds) 2018-04-12 12:20:56 <-- AlphaBlend (Vector@cpe-66-74-178-84.socal.res.rr.com) a quitté 2018-04-12 12:25:33 --> AlphaBlend (~AlphaBlen@cpe-66-74-178-84.socal.res.rr.com) a rejoint #mcdevs 2018-04-12 12:52:50 <-- AlphaBlend (~AlphaBlen@cpe-66-74-178-84.socal.res.rr.com) a quitté 2018-04-12 12:53:11 --> AlphaBlend (Vector@cpe-66-74-178-84.socal.res.rr.com) a rejoint #mcdevs 2018-04-12 12:54:58 -- AlphaBlend est maintenant connu sous le nom MisterVector 2018-04-12 12:55:28 <-- MisterVector (Vector@cpe-66-74-178-84.socal.res.rr.com) a quitté (Client Quit) 2018-04-12 12:55:44 --> AlphaBlend (Vector@cpe-66-74-178-84.socal.res.rr.com) a rejoint #mcdevs 2018-04-12 13:10:36 -- AlphaBlend est maintenant connu sous le nom MisterVector 2018-04-12 16:28:53 --> Jan1902 (~quassel@2a02:2028:56c:3901:4468:5b04:4228:fc09) a rejoint #mcdevs 2018-04-12 16:30:44 <-- Jan1902 (~quassel@2a02:2028:56c:3901:4468:5b04:4228:fc09) a quitté (Remote host closed the connection) 2018-04-12 16:57:23 --> NathanWolf (~nathan@216-235-101-HCC-80.hcc.net) a rejoint #mcdevs 2018-04-12 21:14:31 <-- protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2) 2018-04-12 23:05:35 --> protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-12 23:22:04 --> Dadido3 (~quassel@p200300EF43C5E1004D1D1A1606CD1E31.dip0.t-ipconnect.de) a rejoint #mcdevs 2018-04-12 23:22:52 <-- Dadido3_ (~quassel@p200300EF43C49E00A1A735855C5CE8D1.dip0.t-ipconnect.de) a quitté (Ping timeout: 265 seconds) 2018-04-13 00:00:14 <-- EW8GU (admin@ho.by) a quitté (Ping timeout: 268 seconds) 2018-04-13 00:02:09 --> EW8GU (admin@ho.by) a rejoint #mcdevs 2018-04-13 00:18:40 <-- Byteflux (~byte@byteflux.net) a quitté (Remote host closed the connection) 2018-04-13 00:24:38 --> Byteflux (~byte@byteflux.net) a rejoint #mcdevs 2018-04-13 00:32:00 <-- peterix (~peterix@quassel.woboq.com) a quitté (Ping timeout: 256 seconds) 2018-04-13 00:35:44 --> Jan1902 (~quassel@2a02:2028:56c:3901:a0b2:ac1a:e665:2bf8) a rejoint #mcdevs 2018-04-13 00:36:35 Jan1902 So, does anyone have further knowledge on the previously mentioned part of the documentation regarding the encryption hash generated by the client, and what goes into this ? 2018-04-13 00:40:01 <-- Jan1902 (~quassel@2a02:2028:56c:3901:a0b2:ac1a:e665:2bf8) a quitté (Remote host closed the connection) 2018-04-13 01:15:28 <-- KnownUnown (KnownUnown@die.in.firrre.com) a quitté (Remote host closed the connection) 2018-04-13 01:50:21 --> mdkyd (~xfqvxz@119.82.228.130) a rejoint #mcdevs 2018-04-13 01:52:23 <-- mdkyd (~xfqvxz@119.82.228.130) a quitté (Remote host closed the connection) 2018-04-13 02:26:23 <-- chibill (~chibill@2602:306:ce43:b390:3008:eeff:fe67:2b44) a quitté (Quit: ZNC 1.6.5+deb1 - http://znc.in) 2018-04-13 02:33:23 --> chibill (~chibill@108-228-59-57.lightspeed.cicril.sbcglobal.net) a rejoint #mcdevs 2018-04-13 03:37:05 --> KnownUnown (KnownUnown@die.in.firrre.com) a rejoint #mcdevs 2018-04-13 03:41:51 --> peterix (~peterix@quassel.woboq.com) a rejoint #mcdevs 2018-04-13 05:44:04 --> annadane502 (~eilvj@177.67.111.254.niqturbo.net.br) a rejoint #mcdevs 2018-04-13 05:46:08 <-- annadane502 (~eilvj@177.67.111.254.niqturbo.net.br) a quitté (Remote host closed the connection) 2018-04-13 06:00:31 --> leviyatan4QAOLL (~lojfntsh@200.223.216.114) a rejoint #mcdevs 2018-04-13 06:02:26 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-13 06:03:18 <-- leviyatan4QAOLL (~lojfntsh@200.223.216.114) a quitté (K-Lined) 2018-04-13 06:05:40 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 264 seconds) 2018-04-13 06:05:40 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2018-04-13 07:01:36 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-13 07:04:56 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 265 seconds) 2018-04-13 07:04:56 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2018-04-13 07:18:44 <-- NathanWolf (~nathan@216-235-101-HCC-80.hcc.net) a quitté (Quit: NathanWolf) 2018-04-13 07:33:01 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: No route to host) 2018-04-13 07:33:08 --> redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-13 07:42:52 <-- WizardCM (~WizardCM@dsl-58-6-81-236.sa.westnet.com.au) a quitté (Quit: Oh noes it broke!) 2018-04-13 07:43:34 --> WizardCM (~WizardCM@dsl-58-6-81-236.sa.westnet.com.au) a rejoint #mcdevs 2018-04-13 07:43:55 <-- McLive (~McLive@2a05:bec0:20:1::9) a quitté (Ping timeout: 256 seconds) 2018-04-13 07:45:04 <-- DemonWav (~DemonWav@unaffiliated/demonwav) a quitté (Remote host closed the connection) 2018-04-13 07:45:45 --> McLive (~McLive@2a05:bec0:20:1::9) a rejoint #mcdevs 2018-04-13 07:46:33 --> DemonWav (~DemonWav@unaffiliated/demonwav) a rejoint #mcdevs 2018-04-13 08:33:22 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: Connection reset by peer) 2018-04-13 08:34:03 --> redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-13 09:50:53 <-- ShaRose (ShaRose@i.am.sharo.se) a quitté (Ping timeout: 245 seconds) 2018-04-13 09:51:42 --> ShaRose (ShaRose@i.am.sharo.se) a rejoint #mcdevs 2018-04-13 10:35:50 --> OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a rejoint #mcdevs 2018-04-13 12:54:14 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: Connection reset by peer) 2018-04-13 12:54:43 --> redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-13 13:19:49 C4K3 Jan1902: Just don't ignore the server id string, then your code will work whether the server sends it or not 2018-04-13 13:20:40 <-- OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a quitté (Ping timeout: 264 seconds) 2018-04-13 13:22:53 <-- fl4sh_ (~fl4sh@dock.jsje.de) a quitté (Ping timeout: 276 seconds) 2018-04-13 13:28:10 --> fl4sh_ (~fl4sh@trinity.jsje.de) a rejoint #mcdevs 2018-04-13 14:01:49 <-- Morrolan (morrolan@znc.morrolan.ch) a quitté (Quit: Goodbye) 2018-04-13 14:02:06 --> Morrolan (morrolan@znc.morrolan.ch) a rejoint #mcdevs 2018-04-13 14:10:36 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: No route to host) 2018-04-13 14:10:54 --> redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-13 17:03:24 <-- C4K3 (~C4K3@0127801301.0.fullrate.ninja) a quitté (Quit: leaving) 2018-04-13 17:03:39 --> C4K3 (~C4K3@0127801301.0.fullrate.ninja) a rejoint #mcdevs 2018-04-13 17:11:26 --> NathanWolf (~nathan@216-235-101-HCC-80.hcc.net) a rejoint #mcdevs 2018-04-13 17:11:40 <-- fl4sh_ (~fl4sh@trinity.jsje.de) a quitté (Ping timeout: 264 seconds) 2018-04-13 17:14:05 --> fl4sh_ (~fl4sh@dock.jsje.de) a rejoint #mcdevs 2018-04-13 17:55:33 --> Jan1902 (~quassel@2a02:2028:847:8401:eddf:2857:d659:9724) a rejoint #mcdevs 2018-04-13 17:57:20 pokechu22 "11:18:42 C4K3 | Jan1902: Just don't ignore the server id string, then your code will work whether the server sends it or not" 2018-04-13 17:59:23 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-13 18:01:05 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 260 seconds) 2018-04-13 18:01:05 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2018-04-13 18:26:04 <-- __0x277F (~Hex@four.out.of.five.doctors.recommend.hex.lc) a quitté (Ping timeout: 264 seconds) 2018-04-13 18:26:21 --> __0x277F (~Hex@four.out.of.five.doctors.recommend.hex.lc) a rejoint #mcdevs 2018-04-13 18:31:33 Jan1902 Okay, different question, I dont quite get the explanation of creating the Hash and the Symetric Encryption, did i understand it right, that you have to first base64 encode the public key, then add the end and start strings, pem/rsa decode the result, and then use this key to AES encrypt the shared secret and verify token ? 2018-04-13 18:33:46 timmyRS I don't think you base64 encode anything 2018-04-13 18:34:26 Jan1902 Well it says, in case you dont find a good way to load a der key, you can base64 encode it and add the start and termination strings 2018-04-13 18:38:42 Jan1902 But im note quit sure, on whether i understoud that correctly 2018-04-13 19:40:05 <-- protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2) 2018-04-13 19:40:21 +ammar2 Jan1902: that's only if your crypto library doesn't support loading a DER key 2018-04-13 19:40:23 +ammar2 most do 2018-04-13 20:22:42 <-- _123DMWM (~123DMWM@me.123dmwm.tk) a quitté (Ping timeout: 240 seconds) 2018-04-13 20:22:47 Jan1902 I cant even seem to find anything about "DER" unfortunately, and im extremely new to encryption of every type, the only thing i can find is pem and rsa 2018-04-13 20:26:06 timmyRS DER is not a type of encryption, it's a form in which to store your keys 2018-04-13 20:26:50 timmyRS That shouldn't concern you too much, tho, because the Minecraft server is supposed to create a random 1024-bit RSA keypair at every startup 2018-04-13 20:29:21 --> _123DMWM (~123DMWM@me.123dmwm.tk) a rejoint #mcdevs 2018-04-13 20:39:27 --> UUID00 (~UUID00@BSN-142-194-111.static.siol.net) a rejoint #mcdevs 2018-04-13 20:43:07 Jan1902 okay 2018-04-13 21:06:00 <-- _123DMWM (~123DMWM@me.123dmwm.tk) a quitté (Read error: Connection reset by peer) 2018-04-13 21:10:48 --> _123DMWM (~123DMWM@me.123dmwm.tk) a rejoint #mcdevs 2018-04-13 21:29:41 Jan1902 But the Public key sent from the server is 162 bytes long, according to my client, so something must be working not quite right i guess 2018-04-13 21:30:30 +ammar2 that's fine 2018-04-13 21:30:44 +ammar2 the key is supposed to be 128 bytes, plus some additional data for the asn1 encoding 2018-04-13 21:30:58 +ammar2 so 162 is a valid number for the size 2018-04-13 21:31:24 Jan1902 Okay, so i have to decrypt the sent public key first, to then use it to encrypt the other two values, that are then sent back to the server ? 2018-04-13 21:31:38 <-- UUID00 (~UUID00@BSN-142-194-111.static.siol.net) a quitté (Quit: Leaving) 2018-04-13 21:32:00 --> MrGr33n (~None@BSN-142-194-111.static.siol.net) a rejoint #mcdevs 2018-04-13 21:32:10 +ammar2 you don't decrypt the sent public key, you just load it with whatever crypto library you're using 2018-04-13 21:32:19 +ammar2 and then yes, you use it to encrypt the provided values and send them back 2018-04-13 21:33:37 Jan1902 Well, i have no idea how to properly load keys then, and also what exactly do you mean by crypto library, is c#'s builtin crypto stuff enogugh? 2018-04-13 21:33:49 +ammar2 it should be, yeah 2018-04-13 21:34:18 +ammar2 take a look at this, its an existing project in C# https://github.com/SirCmpwn/Craft.Net/blob/master/source/Craft.Net.Common/Cryptography.cs 2018-04-13 21:34:33 +ammar2 oh wait jesus that looks complicated as hell for no reason 2018-04-13 21:34:51 +ammar2 https://stackoverflow.com/questions/42175485/load-asn-1-der-encoded-rsa-keypair-in-c-sharp 2018-04-13 21:35:09 Jan1902 I just found exactly that post myself haha, though thanks 2018-04-13 21:38:45 <-- Jan1902 (~quassel@2a02:2028:847:8401:eddf:2857:d659:9724) a quitté (Remote host closed the connection) 2018-04-13 22:23:01 --> protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-14 01:10:56 --> OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a rejoint #mcdevs 2018-04-14 02:07:06 <-- NathanWolf (~nathan@216-235-101-HCC-80.hcc.net) a quitté (Quit: NathanWolf) 2018-04-14 03:58:59 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: Connection reset by peer) 2018-04-14 03:59:42 --> redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-14 04:03:34 <-- WizardCM (~WizardCM@dsl-58-6-81-236.sa.westnet.com.au) a quitté (Ping timeout: 240 seconds) 2018-04-14 04:08:10 --> WizardCM (~WizardCM@dsl-58-6-81-236.sa.westnet.com.au) a rejoint #mcdevs 2018-04-14 05:58:37 <-- protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2) 2018-04-14 06:46:59 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-14 06:50:04 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 240 seconds) 2018-04-14 06:50:04 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2018-04-14 07:46:41 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Quit: redstonehelper) 2018-04-14 07:59:00 --> protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-14 10:11:59 <-- _123DMWM (~123DMWM@me.123dmwm.tk) a quitté (Remote host closed the connection) 2018-04-14 10:17:03 --> _123DMWM (~123DMWM@me.123dmwm.tk) a rejoint #mcdevs 2018-04-14 10:25:58 <-- _123DMWM (~123DMWM@me.123dmwm.tk) a quitté (Quit: ZNC 1.6.5 - http://znc.in) 2018-04-14 14:19:57 --> bueddl (~bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs 2018-04-14 15:42:50 --> _123DMWM (~123DMWM@me.123dmwm.tk) a rejoint #mcdevs 2018-04-14 15:51:16 <-- md_5 (~md_5@mcdevs/trusted/md-5) a quitté (Ping timeout: 264 seconds) 2018-04-14 15:52:00 --> md_5 (~md_5@mcdevs/trusted/md-5) a rejoint #mcdevs 2018-04-14 15:52:00 -- Mode #mcdevs [+v md_5] par ChanServ 2018-04-14 19:10:44 --> maxspie (~maxspie@x5ce7be3f.dyn.telefonica.de) a rejoint #mcdevs 2018-04-14 19:11:41 <-- maxspie (~maxspie@x5ce7be3f.dyn.telefonica.de) a quitté (Quit: Going offline, see ya! (www.adiirc.com)) 2018-04-14 19:12:06 --> maxspie (~maxspie@x5ce7be3f.dyn.telefonica.de) a rejoint #mcdevs 2018-04-14 19:13:01 <-- maxspie (~maxspie@x5ce7be3f.dyn.telefonica.de) a quitté (Remote host closed the connection) 2018-04-14 19:13:08 --> maxspie (~maxspie@x5ce7be3f.dyn.telefonica.de) a rejoint #mcdevs 2018-04-14 19:13:16 <-- maxspie (~maxspie@x5ce7be3f.dyn.telefonica.de) a quitté (Remote host closed the connection) 2018-04-14 19:13:23 --> maxspie (~maxspie@x5ce7be3f.dyn.telefonica.de) a rejoint #mcdevs 2018-04-14 19:13:41 <-- maxspie (~maxspie@x5ce7be3f.dyn.telefonica.de) a quitté (Remote host closed the connection) 2018-04-14 21:22:57 --> maxspie (~maxspie@x5ce7be3f.dyn.telefonica.de) a rejoint #mcdevs 2018-04-14 21:23:07 <-- maxspie (~maxspie@x5ce7be3f.dyn.telefonica.de) a quitté (Remote host closed the connection) 2018-04-14 21:32:53 --> yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a rejoint #mcdevs 2018-04-14 21:38:19 yyvwPpI7BO_ Hey I'm writing a server for Java Edition and have a question about the login protocol 2018-04-14 21:38:39 Proximyst Yeah? 2018-04-14 21:38:49 --> maxspie (~maxspie@x5ce7be3f.dyn.telefonica.de) a rejoint #mcdevs 2018-04-14 21:39:07 yyvwPpI7BO_ Most of the time after I receive a Handshake packet from the client with State=2 no Login Start packet follows 2018-04-14 21:39:18 yyvwPpI7BO_ It only works after 3 or 4 tries 2018-04-14 21:39:51 yyvwPpI7BO_ Is this the fault of my server or is there something I didn't see in the specification 2018-04-14 21:40:07 timmyRS How are you delimiting packets? 2018-04-14 21:41:04 yyvwPpI7BO_ I'm not doing anything myself, I'm using node.js and the included net TCP server 2018-04-14 21:41:09 Proximyst That's unusual. Most definitely your server; you should try to rather log and every byte of all packets on a connection while that is happening (i.e. everything goes through a proxy handler first then it goes to the actual packet handling) 2018-04-14 21:41:59 yyvwPpI7BO_ Yea the server doesn't receive the packet at all even if I strip the entire logic and just log all incoming packets 2018-04-14 21:42:22 timmyRS Well if you use the built-in TCP server, it's very likely that the handshake and login start packets are sent within the same TCP packet 2018-04-14 21:42:27 timmyRS Did you try logging every single byte? 2018-04-14 21:44:12 Proximyst Actually, does the client accept more than 1 packet in the same ByteBuf? 2018-04-14 21:44:21 Proximyst I'd imagine it does, but gotta be sure 2018-04-14 21:44:56 yyvwPpI7BO_ Ah multiple packets can be merged? 2018-04-14 21:45:09 yyvwPpI7BO_ I'll see if that's the case, thanks for the pointer 2018-04-14 21:46:02 Proximyst It'd only make sense. You specify the length of what it should read at the start, then comes any data 2018-04-14 21:46:19 Proximyst When you've read n bytes, you know a new packet is next or the buffer is empty 2018-04-14 21:46:26 timmyRS Packets can also be split into multiple TCP packets 2018-04-14 21:46:36 <-- maxspie (~maxspie@x5ce7be3f.dyn.telefonica.de) a quitté (Quit: Going offline, see ya! (www.adiirc.com)) 2018-04-14 21:46:53 --> maxspie (~maxspie@x5ce7be3f.dyn.telefonica.de) a rejoint #mcdevs 2018-04-14 21:48:19 <-- maxspie (~maxspie@x5ce7be3f.dyn.telefonica.de) a quitté (Client Quit) 2018-04-14 21:48:35 --> maxspie (~maxspie@x5ce7be3f.dyn.telefonica.de) a rejoint #mcdevs 2018-04-14 21:48:43 <-- maxspie (~maxspie@x5ce7be3f.dyn.telefonica.de) a quitté #mcdevs 2018-04-14 21:54:40 yyvwPpI7BO_ Ah yes that's exactly the case 2018-04-14 21:54:58 yyvwPpI7BO_ Sometimes the buffer just contains multiple packets at the same time 2018-04-14 21:55:44 timmyRS You'll just have to write a custom wrapper class 2018-04-14 21:55:55 timmyRS or, since you're using javascript, a custom wrapper function with subfunctions :P 2018-04-14 21:56:40 yyvwPpI7BO_ That's what ES6 is for 2018-04-14 21:57:36 yyvwPpI7BO_ Then I'll do that, thanks for the help 2018-04-14 22:26:47 rom1504 yyvwPpI7BO_: have you considered using node-minecraft-protocol ? 2018-04-14 22:28:09 yyvwPpI7BO_ I'm not writing it for any serious reason, it's not a learning experience for me 2018-04-14 22:28:21 yyvwPpI7BO_ So using the module would defeat the purpose :) 2018-04-14 22:28:38 yyvwPpI7BO_ it's just a learning experience i mean of course 2018-04-14 22:30:48 yyvwPpI7BO_ Wait how do you ping people 2018-04-14 22:31:07 yyvwPpI7BO_ Don't laugh, this is my first time using IRC 2018-04-14 22:32:31 rom1504 ok 2018-04-14 22:32:43 pokechu22 You ping people just by saying their name 2018-04-14 22:33:39 rom1504 but then just keep in mind you are not writing a server, you are writing a minecraft parser/deserializer 2018-04-14 22:33:52 rom1504 it's unlikely you'll then have time to also write the server 2018-04-14 22:34:14 rom1504 just make sure to choose the abstraction level you want to learn 2018-04-14 22:34:23 rom1504 learn serialization is interesting though 2018-04-14 22:34:28 rom1504 *learning 2018-04-14 22:36:07 yyvwPpI7BO_ I mean if I can connect to it with my client, that's a server right? 2018-04-14 22:36:20 yyvwPpI7BO_ So far I've managed to get in game 2018-04-14 22:36:54 yyvwPpI7BO_ My client is just floating around in the void, but that's something at least 2018-04-14 22:37:47 pokechu22 Well, that's progress for sure, the challenging part is implementing chunks 2018-04-14 22:39:32 yyvwPpI7BO_ Of course, but considering I started to work on this 3 hours ago I'm quite satisfied 2018-04-14 22:40:08 yyvwPpI7BO_ And now that I don't need to try to connect 4 times every time until it works development should be much faster 2018-04-14 23:54:57 <-- protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2) 2018-04-15 00:52:11 <-- clonejo (~clonejo@shakik3.shakik.de) a quitté (Quit: WeeChat 2.0.1) 2018-04-15 00:52:24 --> clj (~clonejo@shakik3.shakik.de) a rejoint #mcdevs 2018-04-15 01:24:49 --> protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-15 02:12:16 <-- yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a quitté (Ping timeout: 264 seconds) 2018-04-15 02:44:38 <-- bueddl (~bueddl@ip-84-118-89-34.unity-media.net) a quitté (Remote host closed the connection) 2018-04-15 06:30:58 <-- protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2) 2018-04-15 08:19:38 --> protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-15 11:32:32 --> yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a rejoint #mcdevs 2018-04-15 14:23:27 --> bueddl (~bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs 2018-04-15 17:00:36 rom1504 yyvwPpI7BO_: yeah that's a tcp server even 2018-04-15 17:00:52 rom1504 implementing a minecraft server is a bit more complex 2018-04-15 17:01:10 rom1504 but anyway, feel free 2018-04-15 17:01:22 rom1504 I advise you to use node streams 2018-04-15 17:01:50 yyvwPpI7BO_ for what exactly? 2018-04-15 17:02:26 rom1504 each layer of the protocol : splitting, compression, encryption, parsing 2018-04-15 17:02:34 rom1504 transform streams are pretty good 2018-04-15 17:10:43 yyvwPpI7BO_ I've never really done anything with streams before but they do look very useful for encryption and compression 2018-04-15 17:11:32 yyvwPpI7BO_ But I think I won't bother with either for now as they're not required as far as I understand 2018-04-15 17:12:18 bueddl true. as long as the server does not requests either of both, the client won't initiate them 2018-04-15 17:12:54 yyvwPpI7BO_ Yeah, I just skipped the encryption and compression packets and the client seems to connect just fine 2018-04-15 17:13:20 bueddl I did the same when I started developing my server. Never had a problem with that 2018-04-15 17:14:37 yyvwPpI7BO_ I doubt my server will ever go anywhere as I tend to lose interest in most projects pretty quickly 2018-04-15 17:14:49 yyvwPpI7BO_ So I'll just focus on the necessary things first 2018-04-15 17:15:16 yyvwPpI7BO_ Sending some valid chunks to the client would be next 2018-04-15 17:15:24 yyvwPpI7BO_ Let's see how that goes 2018-04-15 17:16:40 bueddl this was also the exact same order I started developing. Next after sending chunks (only sending, the real chunk implementation was weeks after that) was to allow for player movement. 2018-04-15 17:17:23 yyvwPpI7BO_ Yeah I think just sending some simple chunk data will be the best start 2018-04-15 17:17:44 yyvwPpI7BO_ Implementing real world generation will probably take quite a bit of time 2018-04-15 17:18:02 bueddl it will :D 2018-04-15 17:18:32 yyvwPpI7BO_ Is there some documentation on how Minecraft generates its worlds? 2018-04-15 17:18:55 yyvwPpI7BO_ I mean programs like AMIDST replicate it perfectly 2018-04-15 17:20:17 bueddl I don't know. Would be interested in this too. A friend of mine used to work on that. 2018-04-15 17:21:42 yyvwPpI7BO_ I'll look into it later, now I gotta figure out why my server crashes randomly without an error 2018-04-15 17:21:44 yyvwPpI7BO_ -_- 2018-04-15 17:22:25 bueddl good luck :) 2018-04-15 17:22:35 timmyRS The wonders of NodeJS 2018-04-15 17:22:51 timmyRS Or just Javascript in general 2018-04-15 17:22:55 bueddl indeed :D 2018-04-15 17:23:12 yyvwPpI7BO_ Eh JavaScript has improved a lot in the last few years 2018-04-15 17:23:32 bueddl it has. still not my favorite language for some good reason :D 2018-04-15 17:24:54 timmyRS I use it as well, but it's more like there's no alternative rather than it actually being good. 2018-04-15 17:25:10 timmyRS I certainly would never run Javascript on a server (so, no NodeJS in this house) 2018-04-15 17:25:23 bueddl yep, me too 2018-04-15 17:25:28 yyvwPpI7BO_ A lot of people still don't like it but I really enjoy modern JS 2018-04-15 17:26:53 yyvwPpI7BO_ Older versions are terrible, but as the last users of Internet Explorer die of old age there will soon no longer be any reason to use it 2018-04-15 18:13:34 <-- Zachoz (~Zachoz@2001:19f0:5800:8483:5400:ff:fe06:49ea) a quitté (Ping timeout: 265 seconds) 2018-04-15 18:13:47 --> Zachoz (~Zachoz@2001:19f0:5800:8483:5400:ff:fe06:49ea) a rejoint #mcdevs 2018-04-15 18:15:30 <-- ScruffyRules (~Scruff@2001:19f0:5800:8483:5400:ff:fe06:49ea) a quitté (Ping timeout: 265 seconds) 2018-04-15 18:15:47 --> ScruffyRules (~Scruff@2001:19f0:5800:8483:5400:ff:fe06:49ea) a rejoint #mcdevs 2018-04-15 18:52:53 MiniDigger I just wait till wasm is stable so we all can stop using js ^^ 2018-04-15 18:54:23 timmyRS Isn't wasm just js? 2018-04-15 18:54:30 MiniDigger No 2018-04-15 18:54:49 MiniDigger You basically can compile any language to run in a browser and use browser apis 2018-04-15 18:55:22 MiniDigger In theory it will also be much faster 2018-04-15 18:55:27 timmyRS Intriguing 2018-04-15 19:00:32 yyvwPpI7BO_ WebAssembly won't replace JavaScript, I'm pretty sure about that 2018-04-15 19:23:23 --> progwml6 (~progwml6@pool-173-54-58-71.nwrknj.fios.verizon.net) a rejoint #mcdevs 2018-04-15 19:23:41 <-- progwml6 (~progwml6@pool-173-54-58-71.nwrknj.fios.verizon.net) a quitté (Client Quit) 2018-04-15 20:41:14 <-- DemonWav (~DemonWav@unaffiliated/demonwav) a quitté (Remote host closed the connection) 2018-04-15 20:59:25 --> DemonWav (~DemonWav@unaffiliated/demonwav) a rejoint #mcdevs 2018-04-15 21:01:37 <-- DemonWav (~DemonWav@unaffiliated/demonwav) a quitté (Remote host closed the connection) 2018-04-15 21:02:09 --> DemonWav (~DemonWav@unaffiliated/demonwav) a rejoint #mcdevs 2018-04-15 23:51:16 <-- yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a quitté (Ping timeout: 256 seconds) 2018-04-15 23:58:45 <-- EW8GU (admin@ho.by) a quitté (Ping timeout: 268 seconds) 2018-04-16 00:02:10 --> EW8GU (admin@ho.by) a rejoint #mcdevs 2018-04-16 00:08:06 --> yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a rejoint #mcdevs 2018-04-16 00:11:10 --> redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-16 01:06:55 <-- protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2) 2018-04-16 01:07:49 <-- yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a quitté (Ping timeout: 268 seconds) 2018-04-16 02:11:42 <-- bueddl (~bueddl@ip-84-118-89-34.unity-media.net) a quitté (Quit: Leaving) 2018-04-16 03:04:37 --> protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-16 06:43:50 pokechu22 o.o new plugin channels, not sure when they were introduced: MC|DebugStructures MC|DebugCaves MC|DebugWorldGenAttempt -- haven't looked into them yet though 2018-04-16 06:46:04 kashike with the world gen changes iirc, pokechu22 - some of them can't be used do to channel name length limit 2018-04-16 06:46:08 timmyRS Just a wild, totally random guess: Maybe it is even more debugging? :D 2018-04-16 06:46:09 kashike due to* 2018-04-16 06:46:20 pokechu22 Yeah, I love the ones that have super long names and can't be used :D 2018-04-16 06:47:14 pokechu22 I've been going through a lot of bugs (mostly memory leaks now) and figuring out if/when they were fixed and I spotted this when checking https://bugs.mojang.com/browse/MC-121884 2018-04-16 06:48:53 pokechu22 They restructured the client plugin channel handler, and now it's a bit neater (though also somewhat strange) and doesn't leak anymore. The server handler wasn't changed though... (though it still doesn't leak, but it still handles it in a different place) 2018-04-16 07:16:06 pokechu22 Well, documented the structure, but I haven't looked into the actual meanings of them yet (and won't tonight) 2018-04-16 07:18:21 pokechu22 There's also definitely new entities (and thus entity metadata and wonderful entity statuses) 2018-04-16 10:53:07 --> bueddl (~bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs 2018-04-16 11:02:05 <-- Yamakaja (~yamakaja@195.201.91.89) a quitté (Quit: Bai bai) 2018-04-16 11:18:42 --> Yamakaja (~yamakaja@vps.pub.yamakaja.me) a rejoint #mcdevs 2018-04-16 12:32:04 <-- Yamakaja (~yamakaja@vps.pub.yamakaja.me) a quitté (Quit: Bai bai) 2018-04-16 12:52:30 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: Connection reset by peer) 2018-04-16 12:54:07 --> redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2018-04-16 13:26:39 --> Yamakaja (~yamakaja@vps.pub.yamakaja.me) a rejoint #mcdevs 2018-04-16 13:39:04 -- MiniDigger est maintenant connu sous le nom MiniDigger` 2018-04-16 13:41:58 -- MiniDigger` est maintenant connu sous le nom MiniDigger 2018-04-16 13:54:15 -- MiniDigger est maintenant connu sous le nom MiniDigger` 2018-04-16 13:54:28 -- MiniDigger` est maintenant connu sous le nom MiniDigger 2018-04-16 15:32:04 <-- OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a quitté (Ping timeout: 264 seconds) 2018-04-16 16:22:29 --> itsme (~textual@x590efe59.dyn.telefonica.de) a rejoint #mcdevs 2018-04-16 18:10:15 <-- itsme (~textual@x590efe59.dyn.telefonica.de) a quitté (Quit: Textual IRC Client: www.textualapp.com) 2018-04-16 18:23:40 --> yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a rejoint #mcdevs 2018-04-16 18:42:53 --> Black-Hole (~BlackHole@p200300E753E57300BD8FBB01ADE2BD52.dip0.t-ipconnect.de) a rejoint #mcdevs 2018-04-16 18:45:27 --> millerti (~millerti@cpe-66-24-91-119.stny.res.rr.com) a rejoint #mcdevs 2018-04-16 18:45:29 <-- Black_Hole (~BlackHole@p200300E753E57300486CFED3952883F1.dip0.t-ipconnect.de) a quitté (Ping timeout: 245 seconds) 2018-04-16 19:15:47 --> Akaibu (uid118096@gateway/web/irccloud.com/x-cukufcovugggurmp) a rejoint #mcdevs 2018-04-16 19:55:39 <-- mbaxter (~mbax@mcblockit/staff/mbaxter) a quitté (Quit: muahahahahahaha) 2018-04-16 20:57:53 --> mbaxter (~mbax@kitten.institute) a rejoint #mcdevs 2018-04-16 20:57:54 <-- mbaxter (~mbax@kitten.institute) a quitté (Changing host) 2018-04-16 20:57:54 --> mbaxter (~mbax@mcblockit/staff/mbaxter) a rejoint #mcdevs 2018-04-16 21:01:26 --> itsme (~textual@x590efe59.dyn.telefonica.de) a rejoint #mcdevs 2018-04-16 21:29:38 timmyRS I feel like I made a huge mistake trying to write a custom Minecraft server with cross-version compatibility. 2018-04-16 21:29:55 timmyRS 1.13 support sounds like it will be quite the piece of work. 2018-04-16 21:30:04 yyvwPpI7BO_ That does sound really annoying to write 2018-04-16 21:30:10 yyvwPpI7BO_ Which versions are compatible? 2018-04-16 21:30:21 timmyRS 1.8 to 1.12.2 as of now 2018-04-16 21:30:34 timmyRS I was thinking 1.7 but no one uses that anymore and it's like a different protocol entirely to me 2018-04-16 21:30:46 yyvwPpI7BO_ So all of those versions are working right now? 2018-04-16 21:30:52 timmyRS Yes 2018-04-16 21:31:07 yyvwPpI7BO_ Nice 2018-04-16 21:31:52 yyvwPpI7BO_ I personally won't bother with stuff like that right now, 1.13 compatibility should be enough for now 2018-04-16 21:32:15 timmyRS you're writing a server for an unreleased version? 2018-04-16 21:32:17 timmyRS that must be hell 2018-04-16 21:32:25 timmyRS protocol changes every week, yay! 2018-04-16 21:32:55 yyvwPpI7BO_ Right now my server is only compatible with 18w15a 2018-04-16 21:33:34 yyvwPpI7BO_ I thought that most changes that will happen to the protocol are already implemented 2018-04-16 21:34:24 timmyRS Who knows 2018-04-16 21:34:53 yyvwPpI7BO_ Well we'll see 2018-04-16 21:35:40 yyvwPpI7BO_ Right now I'm frustrated enough with regular development 2018-04-16 21:36:04 yyvwPpI7BO_ I don't wanna think about rewriting my entire server :D 2018-04-16 21:36:35 yyvwPpI7BO_ How much did the protocol change between 1.8 and 1.12.2? 2018-04-16 21:37:26 timmyRS Entities are like entirely different 2018-04-16 21:38:02 timmyRS Packet IDs changed, obviously 2018-04-16 21:38:16 timmyRS Packets like Boss Bar were added 2018-04-16 21:40:08 yyvwPpI7BO_ Well changing the packet IDs between versions and handling packets that exist in one version but not the others doesn't sound TOO bad 2018-04-16 21:40:18 yyvwPpI7BO_ But handling packets that changed completely between versions seems like a real pain 2018-04-16 21:41:26 timmyRS I abstracted away some packets, so I write all the ifs and elses ones and then call that 2018-04-16 21:41:29 <-- itsme (~textual@x590efe59.dyn.telefonica.de) a quitté (Quit: Textual IRC Client: www.textualapp.com) 2018-04-16 21:41:44 timmyRS once* 2018-04-16 21:42:11 yyvwPpI7BO_ Still seems like a real pain 2018-04-16 21:42:21 yyvwPpI7BO_ And 1.13 is not going to make it any better 2018-04-16 21:43:34 timmyRS ‮It's going to be horrible 2018-04-16 21:45:22 yyvwPpI7BO_ Something I really dislike is the organization of the Pre-release protocol page and how only changes are listed and I have to switch constantly between that site and the regular Protocol site to get all of the information 2018-04-16 21:45:42 yyvwPpI7BO_ I'm really mildly annoyed 2018-04-16 21:46:06 timmyRS Burger Vitrine might help you 2018-04-16 21:47:44 timmyRS Well, all I found was the Github for Burger: https://github.com/mcdevs/Burger/ 2018-04-16 21:47:46 yyvwPpI7BO_ What is that? 2018-04-16 21:47:49 timmyRS Seems like b.wiki.vg is down 2018-04-16 21:52:15 yyvwPpI7BO_ Doesn't work for me either 2018-04-16 21:53:00 timmyRS pokechu22, y b.wiki.vg no work 2018-04-16 22:07:44 bueddl that is the thing I like about the wiki yyvwPpI7BO_ . If I am interested in "updating" my server to a more recent protocol, I can quickly watch all the deltas to the stable protocol. That is nice somehow for update work. 2018-04-16 22:08:59 timmyRS but not nice for him, as he wants to write a server exclusively for that snapshot 2018-04-16 22:09:57 yyvwPpI7BO_ Maybe having both would be nice 2018-04-16 22:10:18 bueddl yeah, I understand that. But I personally think more people are interested in implementing a stable version and go with deltas from then on (from one stable to the next by the pre-releast protocol). But that is just my opinion :) 2018-04-16 22:11:19 yyvwPpI7BO_ That is correct most likely 2018-04-16 22:11:42 bueddl having both would be nice but would not fit good in a wiki structure imo 2018-04-16 22:12:21 bueddl more like sth to either view a particular version or to compare from one older to one selected newer. but that needed more page logic than a wiki can and should provide I think :D 2018-04-16 22:12:44 yyvwPpI7BO_ I guess 2018-04-16 22:12:45 timmyRS well, the current Pre-Protocol could be moved to "Protocol Changelog" and then Pre-Protocol could actually be the protocol page for a snapshot 2018-04-16 22:13:30 bueddl I imagine that would be a lot more work to do. as fo rnow they keep updating one article until a release and then merge and start from zero for the pre-release page 2018-04-16 22:14:02 bueddl maybe there is an easy solution. I am not very familiar with wiki systems 2018-04-16 22:16:33 <-- protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2) 2018-04-16 22:34:05 yyvwPpI7BO_ Splitting them seems like a good idea but I can see if it's too much work 2018-04-16 23:03:21 pokechu22 I don't actually run b.wiki.vg 2018-04-16 23:03:56 pokechu22 It's the older site, newer stuff is on pokechu22.github.io/Burger/.html 2018-04-16 23:04:40 timmyRS yyvwPpI7BO_, http://pokechu22.github.io/Burger/18w15a.html might help you then 2018-04-16 23:04:52 pokechu22 There is the protocol history article, but that's usually only updated on full versions 2018-04-16 23:06:39 yyvwPpI7BO_ Oh wow that's a lot of useful information 2018-04-16 23:06:41 yyvwPpI7BO_ Thanks 2018-04-16 23:07:51 pokechu22 I'm working on changing it so that I can generate diffs between arbitrary versions clientside using JS (but I don't know JS that well) 2018-04-16 23:08:18 yyvwPpI7BO_ That sounds good 2018-04-16 23:12:56 bueddl awesome. I was about to do the same thing pokechu22 . but if you are already on it, that is awesome! 2018-04-16 23:27:08 yyvwPpI7BO_ That's weird, sometimes when I force quit my server or the client times out the Minecraft client just crashes with a Null Pointer Exception 2018-04-16 23:44:38 --> itsme (~textual@x590efe59.dyn.telefonica.de) a rejoint #mcdevs 2018-04-16 23:44:41 --> protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs 2018-04-16 23:46:07 <-- protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Client Quit) 2018-04-16 23:50:50 yyvwPpI7BO_ Okay for some reason the client sends a Player Position And Look packet with x, y and z all being NaN 2018-04-16 23:52:00 yyvwPpI7BO_ I receive 3 doubles like I should, but they are all "7f f8 00 00 00 00 00 00" 2018-04-16 23:52:43 yyvwPpI7BO_ And that's NaN when I interpret it as a Double 2018-04-16 23:53:23 bueddl it is. also it seems you did not forget to "flip" the bytes , because of the endianess. so... 2018-04-16 23:53:24 bueddl hmm 2018-04-16 23:53:47 yyvwPpI7BO_ no, in little endian it's just 3.143e-319 2018-04-16 23:53:54 bueddl jep 2018-04-16 23:53:58 yyvwPpI7BO_ That's not right either I'd say 2018-04-16 23:54:15 bueddl and taht does not make much sense, it is that close to zero. 2018-04-16 23:54:22 bueddl but you did take care of the endianess? 2018-04-16 23:54:55 yyvwPpI7BO_ The Buffer methods of node.js provide BE and LE reading functions 2018-04-16 23:55:05 bueddl well, ok then 2018-04-16 23:55:10 yyvwPpI7BO_ And I've used BE everywhere 2018-04-16 23:55:24 yyvwPpI7BO_ And it worked just fine on Ints so far 2018-04-16 23:56:08 bueddl hmm, is there anything "interesting" happening before? 2018-04-16 23:56:32 yyvwPpI7BO_ Not really 2018-04-16 23:57:21 bueddl I got a few client-crashes with the most recent pre-release as well. didn't care much about it yet as I do not even have a "complete" server for 1.12 :D 2018-04-16 23:57:22 yyvwPpI7BO_ Happens after the login sequence 2018-04-16 23:57:43 yyvwPpI7BO_ Directly when the client joins the game 2018-04-16 23:58:12 bueddl yeah, that was when I got a crash as well. but I did not have a look (yet) why I got the crash 2018-04-16 23:58:24 pokechu22 Can you post the crash report? 2018-04-16 23:58:46 yyvwPpI7BO_ It doesn't crash 2018-04-16 23:58:57 pokechu22 Oh, using crash as in disconnect? 2018-04-16 23:58:58 yyvwPpI7BO_ But here is my server log if it helps you 2018-04-16 23:59:09 yyvwPpI7BO_ No, the client doesn't care 2018-04-16 23:59:16 yyvwPpI7BO_ It sends invalid data 2018-04-16 23:59:24 yyvwPpI7BO_ For me at least 2018-04-16 23:59:25 yyvwPpI7BO_ https://pastebin.com/0VUdczmR 2018-04-17 00:00:33 bueddl oh, ok well then these might be unrelated problems 2018-04-17 00:01:02 yyvwPpI7BO_ Maybe 2018-04-17 00:01:39 yyvwPpI7BO_ The things at the bottom are just debug logs of the packet data buffer and the values if the buffer is interpreted as per the documentation 2018-04-17 00:01:50 yyvwPpI7BO_ Not in that order 2018-04-17 00:10:18 yyvwPpI7BO_ What a weird error 2018-04-17 00:10:38 yyvwPpI7BO_ How should I proceed then? Just ignore it? 2018-04-17 00:11:31 bueddl did you test more pre-release versions or only the most recent? (18w15a I think) 2018-04-17 00:11:43 yyvwPpI7BO_ Just the most recent 2018-04-17 00:11:48 bueddl if not you could try others versions. the latest releases did not make much difference for the basic protocol parts 2018-04-17 00:11:58 yyvwPpI7BO_ Okay then, I'll try that 2018-04-17 00:12:23 bueddl keep me updated. it's a very interesting problem :D 2018-04-17 00:13:04 yyvwPpI7BO_ I'll try 18w14b first, let's see 2018-04-17 00:14:41 yyvwPpI7BO_ Okay 18w14b does exactly the same, I'll try one that's a bit older 2018-04-17 00:21:16 yyvwPpI7BO_ 18w10d, 18w07c and 18w03b all behave the same 2018-04-17 00:21:30 yyvwPpI7BO_ 17w50a doesn't work with the current protocol anymore 2018-04-17 00:21:31 bueddl strange 2018-04-17 00:22:17 bueddl it would involve some work, but maybe you should try with 1.12.2 , if you use only basic stuff, it is not much more work than changing the packetids 2018-04-17 00:22:51 bueddl if it happens then I think it might be your server (altough there is also a change that u are having a bug that was not discovered yet) 2018-04-17 00:23:32 bueddl chance 2018-04-17 00:28:03 yyvwPpI7BO_ I have an older version lying around that is compatible with 1.12.2 2018-04-17 00:28:22 yyvwPpI7BO_ I've started it again and it doesn't receive the same packet 2018-04-17 00:28:33 yyvwPpI7BO_ This seems to be new in 1.13 2018-04-17 00:29:44 yyvwPpI7BO_ I just hope that I'm not missing anything obvious, I mean if the packet ID is 0x0E it should be this packet, right? http://wiki.vg/Protocol#Player_Position_And_Look_.28serverbound.29 2018-04-17 00:30:05 yyvwPpI7BO_ The length and general structure match, but the data doesn't make any sense 2018-04-17 00:31:44 bueddl yes 2018-04-17 00:33:33 bueddl the packetid for the clientbound position and look packet changed, but not the one that is serverbound 2018-04-17 00:33:56 yyvwPpI7BO_ And neither did the structure 2018-04-17 00:36:04 bueddl hmm, strange 2018-04-17 00:36:18 bueddl it does happen right after login? no other packets involved? 2018-04-17 00:40:32 yyvwPpI7BO_ After the login sequence the client sends a few packets, the server receives client settings, the client brand and a packet to verify the initial position and look packet 2018-04-17 00:40:44 bueddl I tried with my server and 18w15a and it worked without problems, hmm 2018-04-17 00:41:03 yyvwPpI7BO_ And then after that the client sends its own position and look 2018-04-17 00:41:28 bueddl I receive them too and get the proper position I "teleported" the client to 2018-04-17 00:41:54 yyvwPpI7BO_ Okay maybe I send the NaNs there in the first place 2018-04-17 00:42:10 bueddl might be, yes 2018-04-17 00:42:10 yyvwPpI7BO_ But why does the client update its own position to where it already is 2018-04-17 00:43:10 bueddl after your clientbound player-position-and-look packet? 2018-04-17 00:43:21 yyvwPpI7BO_ Yes 2018-04-17 00:45:50 pokechu22 When the client receives a player pos look packet, it sends a confirm teleport and then its own player pos look immediately after (in both 1.12 and the snapshots) 2018-04-17 00:46:20 yyvwPpI7BO_ Okay then 2018-04-17 00:46:27 bueddl correct, but why thr 3 NaNs then?:D did you check if you send NaN yyvwPpI7BO_ ? 2018-04-17 00:46:33 yyvwPpI7BO_ Nevermind it was my mistake 2018-04-17 00:46:43 yyvwPpI7BO_ I sent 3 undefineds 2018-04-17 00:46:49 bueddl :D 2018-04-17 00:46:57 yyvwPpI7BO_ I'm so dumb 2018-04-17 00:48:04 yyvwPpI7BO_ Oh my god I'm so mad 2018-04-17 00:48:11 yyvwPpI7BO_ why does