2020-03-16 03:03:23 <-- yawkat (~yawkat@cats.coffee) a quitté (Ping timeout: 246 seconds) 2020-03-16 03:06:43 --> yawkat (~yawkat@cats.coffee) a rejoint #mcdevs 2020-03-16 03:35:00 -- Guest35640 est maintenant connu sous le nom SinZ 2020-03-16 06:03:22 --> Me4502 (~quassel@unaffiliated/me4502) a rejoint #mcdevs 2020-03-16 06:11:22 <-- mgrech (~mgrech@194-166-99-28.adsl.highway.telekom.at) a quitté (Ping timeout: 255 seconds) 2020-03-16 06:52:04 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2020-03-16 06:56:04 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 268 seconds) 2020-03-16 06:56:04 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2020-03-16 12:26:20 --> Unarelith (~Quent4234@2a01:cb14:bcd:1000:c9cc:94a9:a59c:ca9c) a rejoint #mcdevs 2020-03-16 12:26:46 <-- Unarelith (~Quent4234@2a01:cb14:bcd:1000:c9cc:94a9:a59c:ca9c) a quitté (Client Quit) 2020-03-16 12:39:55 <-- Defolos (~Defolos@fedora/defolos) a quitté (Read error: Connection reset by peer) 2020-03-16 12:44:43 --> Defolos (~Defolos@fedora/defolos) a rejoint #mcdevs 2020-03-16 14:09:23 <-- Me4502 (~quassel@unaffiliated/me4502) a quitté (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 2020-03-16 14:36:19 <-- Defolos (~Defolos@fedora/defolos) a quitté (Ping timeout: 246 seconds) 2020-03-16 14:38:12 --> Defolos (~Defolos@fedora/defolos) a rejoint #mcdevs 2020-03-16 15:52:38 <-- l4mRh4X0r_ (l4mRh4X0r@pomacium.student.ipv6.utwente.nl) a quitté (Read error: Connection reset by peer) 2020-03-16 16:43:08 --> l4mRh4X0r_ (l4mRh4X0r@pomacium.student.ipv6.utwente.nl) a rejoint #mcdevs 2020-03-16 20:16:43 <-- Akkarin (~Akkarin@hyperion.torchmind.com) a quitté (*.net *.split) 2020-03-16 20:16:54 --> Akkarin (~Akkarin@hyperion.torchmind.com) a rejoint #mcdevs 2020-03-16 22:13:10 <-- tassu4 (~tassu@tassu.me) a quitté (Changing host) 2020-03-16 22:13:10 --> tassu4 (~tassu@wikipedia/majavah) a rejoint #mcdevs 2020-03-16 23:40:50 <-- Defolos (~Defolos@fedora/defolos) a quitté (Ping timeout: 240 seconds) 2020-03-16 23:42:53 --> Defolos (~Defolos@fedora/defolos) a rejoint #mcdevs 2020-03-17 09:12:01 <-- MisterVector (Vector@cpe-172-90-152-76.socal.res.rr.com) a quitté (Ping timeout: 272 seconds) 2020-03-17 09:13:13 --> MisterVector (Vector@cpe-172-90-152-76.socal.res.rr.com) a rejoint #mcdevs 2020-03-17 09:48:38 -- Guest69148 est maintenant connu sous le nom killme 2020-03-17 10:26:00 <-- saper (saper@wikipedia/saper) a quitté (Ping timeout: 256 seconds) 2020-03-17 10:27:14 <-- sudden (~lax@unaffiliated/laxask) a quitté (Ping timeout: 258 seconds) 2020-03-17 10:29:40 --> saper (saper@wikipedia/saper) a rejoint #mcdevs 2020-03-17 10:39:47 --> Me4502 (~quassel@unaffiliated/me4502) a rejoint #mcdevs 2020-03-17 11:14:12 --> sudden (~lax@unaffiliated/laxask) a rejoint #mcdevs 2020-03-17 11:19:58 <-- eQuin0x_ (~eQuin0x_@xy0.powered.by.lunarbnc.net) a quitté (Quit: Bye) 2020-03-17 11:21:00 --> eQuin0x_ (~eQuin0x_@xy0.powered.by.lunarbnc.net) a rejoint #mcdevs 2020-03-17 13:21:57 --> mgrech (~mgrech@194-166-99-28.adsl.highway.telekom.at) a rejoint #mcdevs 2020-03-17 14:14:26 --> vec3 (4b46766e@c-75-70-118-110.hsd1.co.comcast.net) a rejoint #mcdevs 2020-03-17 14:16:07 <-- vec3 (4b46766e@c-75-70-118-110.hsd1.co.comcast.net) a quitté #mcdevs 2020-03-17 14:25:20 <-- Me4502 (~quassel@unaffiliated/me4502) a quitté (Read error: Connection reset by peer) 2020-03-17 15:46:50 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 240 seconds) 2020-03-17 15:54:10 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-17 21:17:09 <-- PolarizedIons (~polarized@unaffiliated/polarizedions) a quitté (Remote host closed the connection) 2020-03-17 21:58:47 <-- _123DMWM (~123DMWM@2601:18d:580:3870:e83f:1099:743f:e43e) a quitté (Ping timeout: 256 seconds) 2020-03-17 21:59:12 --> _123DMWM (~123DMWM@2601:18d:580:3870:f82a:dcc0:3924:c05c) a rejoint #mcdevs 2020-03-17 23:08:57 --> m0r13 (~m0r13@2a01:4f8:201:8174:73:0:b00b:135) a rejoint #mcdevs 2020-03-18 00:30:58 <-- Defolos (~Defolos@fedora/defolos) a quitté (Ping timeout: 256 seconds) 2020-03-18 00:41:01 <-- m0r13 (~m0r13@2a01:4f8:201:8174:73:0:b00b:135) a quitté (Remote host closed the connection) 2020-03-18 00:44:14 --> m0r13 (~m0r13@2a01:4f8:201:8174:73:0:b00b:135) a rejoint #mcdevs 2020-03-18 00:45:35 --> itzkmaf (~kmaf@120.105.6.51.dyn.plus.net) a rejoint #mcdevs 2020-03-18 00:45:51 itzkmaf I officially hate 0x46 2020-03-18 00:46:00 itzkmaf That is all. 2020-03-18 00:46:17 timmyRS ? 2020-03-18 00:46:41 itzkmaf So I have been having issues with lilypad not working 2020-03-18 00:47:05 itzkmaf And it seems the whole reason why is packet 0x46 2020-03-18 00:47:14 timmyRS Entity Velocity? 2020-03-18 00:47:16 itzkmaf The set compression packet in play 2020-03-18 00:47:27 itzkmaf No sorry protocol 47 2020-03-18 00:47:49 itzkmaf It just says on the wiki that it is broken 2020-03-18 00:47:57 itzkmaf And nothing else 2020-03-18 00:47:59 timmyRS Have you figured out why it doesn't work yet? 2020-03-18 00:48:03 itzkmaf Nope 2020-03-18 00:48:43 itzkmaf The only reason I found out was that I have been making a proxy so I can look at the unencrypted packets easier 2020-03-18 00:49:14 itzkmaf And i accidentally left out 0x46 so the vanilla client handled it 2020-03-18 00:49:45 itzkmaf As soon as I implemented it in the proxy instead of letting the client decode it it stopped working 2020-03-18 00:52:09 itzkmaf Im going to look into it tomorrow in more detail as I have to sleep now. I see why they removed it in later versions though as I just don’t understand why it isn’t working 2020-03-18 00:58:24 timmyRS The only thing I can think of is that maybe the packet format is different with this delayed set compression? 2020-03-18 00:58:25 <-- itzkmaf (~kmaf@120.105.6.51.dyn.plus.net) a quitté (Ping timeout: 264 seconds) 2020-03-18 01:39:13 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 264 seconds) 2020-03-18 01:41:02 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-18 01:50:21 --> md_5- (~md_5@mcdevs/trusted/md-5) a rejoint #mcdevs 2020-03-18 01:50:21 -- Mode #mcdevs [+v md_5-] par ChanServ 2020-03-18 01:52:02 <-- md_5 (~md_5@mcdevs/trusted/md-5) a quitté (Ping timeout: 240 seconds) 2020-03-18 02:06:37 --> md_5 (~md_5@mcdevs/trusted/md-5) a rejoint #mcdevs 2020-03-18 02:06:37 -- Mode #mcdevs [+v md_5] par ChanServ 2020-03-18 02:09:00 <-- md_5- (~md_5@mcdevs/trusted/md-5) a quitté (Ping timeout: 256 seconds) 2020-03-18 02:48:50 <-- yawkat (~yawkat@cats.coffee) a quitté (Ping timeout: 246 seconds) 2020-03-18 03:03:36 --> yawkat (~yawkat@cats.coffee) a rejoint #mcdevs 2020-03-18 05:57:21 --> VADemon (~VADemon@2a01:4f8:212:2f1d:88::41) a rejoint #mcdevs 2020-03-18 06:27:03 <-- VADemon (~VADemon@2a01:4f8:212:2f1d:88::41) a quitté (Quit: left4dead) 2020-03-18 06:30:40 <-- mgrech (~mgrech@194-166-99-28.adsl.highway.telekom.at) a quitté (Ping timeout: 246 seconds) 2020-03-18 06:50:37 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2020-03-18 06:52:01 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 246 seconds) 2020-03-18 06:52:01 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2020-03-18 06:52:18 <-- Not (~notifico@ec2-52-3-50-241.compute-1.amazonaws.com) a quitté (Ping timeout: 265 seconds) 2020-03-18 08:03:14 --> Defolos (~Defolos@fedora/defolos) a rejoint #mcdevs 2020-03-18 08:33:49 --> Me4502 (~quassel@unaffiliated/me4502) a rejoint #mcdevs 2020-03-18 14:02:30 --> itzkmaf (~kmaf@120.105.6.51.dyn.plus.net) a rejoint #mcdevs 2020-03-18 14:09:13 <-- itzkmaf (~kmaf@120.105.6.51.dyn.plus.net) a quitté (Ping timeout: 264 seconds) 2020-03-18 14:32:12 --> itzkmaf (~kmaf@120.105.6.51.dyn.plus.net) a rejoint #mcdevs 2020-03-18 14:36:44 <-- itzkmaf (~kmaf@120.105.6.51.dyn.plus.net) a quitté (Ping timeout: 250 seconds) 2020-03-18 14:43:54 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 246 seconds) 2020-03-18 14:44:20 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-18 15:01:33 --> itzkmaf (~kmaf@120.105.6.51.dyn.plus.net) a rejoint #mcdevs 2020-03-18 15:01:56 itzkmaf How does vanilla minecraft handle 0x47 Set Compression 2020-03-18 15:02:13 itzkmaf I know it was removed in 1.9 due to race conditions 2020-03-18 15:03:00 itzkmaf But lilypad servers use it, and I cannot get my client or proxy to work with it, 2020-03-18 15:03:53 timmyRS My current theory is that the packet format might be not as you would expect, have you tried looking at wireshark and making sense of the bytes manually? 2020-03-18 15:04:41 itzkmaf It’s encrypted unless I handle it via my proxy I believe 2020-03-18 15:04:58 itzkmaf Which then cause everything to stop working 2020-03-18 15:06:01 itzkmaf All of the packets on my end are being read correctly with the correct values and everything 2020-03-18 15:06:19 itzkmaf Im wondering if the server is failing to read mine though. 2020-03-18 15:14:21 <-- itzkmaf (~kmaf@120.105.6.51.dyn.plus.net) a quitté (Remote host closed the connection) 2020-03-18 15:17:04 --> itzkmaf (~kmaf@120.105.6.51.dyn.plus.net) a rejoint #mcdevs 2020-03-18 15:17:41 <-- itzkmaf (~kmaf@120.105.6.51.dyn.plus.net) a quitté (Remote host closed the connection) 2020-03-18 15:24:54 <-- Me4502 (~quassel@unaffiliated/me4502) a quitté (Read error: Connection reset by peer) 2020-03-18 15:35:01 --> itzkmaf (~kmaf@120.105.6.51.dyn.plus.net) a rejoint #mcdevs 2020-03-18 15:35:52 <-- itzkmaf (~kmaf@120.105.6.51.dyn.plus.net) a quitté (Remote host closed the connection) 2020-03-18 15:39:49 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 264 seconds) 2020-03-18 15:46:33 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-18 15:50:45 <-- JuniorJPDJ (juniorjp1@gateway/shell/matrix.org/x-svhtuyervdogvipd) a quitté (Ping timeout: 245 seconds) 2020-03-18 16:47:01 caelunsh1 When spawning an item on the client, should the metadata packet be sent before or after Spawn Object? 2020-03-18 16:47:39 caelunsh1 Right now, I'm sending Spawn Object and then Entity Metadata, and the item disappears rapidly on the client 2020-03-18 17:42:26 <-- eQuin0x_ (~eQuin0x_@xy0.powered.by.lunarbnc.net) a quitté (Quit: Bye) 2020-03-18 17:44:06 --> eQuin0x_ (~eQuin0x_@xy0.powered.by.lunarbnc.net) a rejoint #mcdevs 2020-03-18 18:30:20 --> Not-8b5f (~notifico@ec2-52-3-50-241.compute-1.amazonaws.com) a rejoint #mcdevs 2020-03-18 18:30:20 Not-8b5f [minecraft-data] automatic-beyond-belief pushed 1 commit to master [+0/-0/±1] https://git.io/JvXpU 2020-03-18 18:30:21 Not-8b5f [minecraft-data] automatic-beyond-belief cc03368 - Add 20w12a to common/protocolVersions.json 2020-03-18 18:42:17 +pokechu22 After spawn object, but... it's not ideal still 2020-03-18 18:42:54 +pokechu22 Ideally, the data should be in a single packet, because if the item ticks before the metadata is received, it self-destructs. But, that's not the case :| 2020-03-18 18:43:38 +pokechu22 See https://bugs.mojang.com/browse/MC-111978 and https://bugs.mojang.com/browse/MC-11834 (which needs to be tested in 1.15, but I'm pretty sure it's still the case) 2020-03-18 18:43:39 timmyRS So, ideally, you shouldn't flush 2020-03-18 18:44:45 timmyRS Although, couldn't there still be a race condition on the receiving end where it parses the spawn object, ticks, then parses the metadata? 2020-03-18 18:45:33 Not-8b5f [Burger] New data now avaliable for 20w12a: 2020-03-18 18:45:34 Not-8b5f [Burger] Diff from 20w11a: https://pokechu22.github.io/Burger/diff_20w11a_20w12a.html (https://pokechu22.github.io/Burger/diff_20w11a_20w12a.json) 2020-03-18 18:45:36 Not-8b5f [Burger] Full data: https://pokechu22.github.io/Burger/20w12a.html (https://pokechu22.github.io/Burger/20w12a.json) 2020-03-18 18:48:14 +pokechu22 Yes, that's what those bugs are :| 2020-03-18 18:48:25 timmyRS Ouch 2020-03-18 18:50:35 timmyRS Apparently they just removed metadata fields from other packets in 1.15 for consistency... https://wiki.vg/index.php?title=Pre-release_protocol&oldid=15294 2020-03-18 18:52:57 caelunsh1 I tried sending metadata before Spawn Object and it's working fine now—interesting how many bugs the vanilla client has. 2020-03-18 18:54:36 +pokechu22 That really shouldn't work, since I'm pretty sure that would update metadata of an entity that the client doesn't know about and it'd just ignore it. Maybe you've got a bug on the way you're ordering packets? 2020-03-18 19:06:05 +pokechu22 Looks like the blocks topping failed to run. I'll investigate later today but I'm a bit busy; in the mean time, I'm sure a bot will post the changelog sooner or later :P 2020-03-18 19:08:54 timmyRS it actually wasn't released yet when I checked, so my bot is not to blame obviously :P 2020-03-18 19:32:41 KennyTV today's burger diff doesn't display blocks and items, does it? 2020-03-18 19:36:17 +pokechu22 Yep, the blocks topping broke. I'll investigate but it'll be a while before I have time 2020-03-18 19:43:41 timmyRS Sublime Text makes a decent job of making this file useful: https://gist.githubusercontent.com/timmyRS/ab418370cd5d6020acda1fa4e6559d27/raw/f1c12e96f546ec5d6b3ea68d18eeaecf8812ca1e/0001-20w12a.patch 2020-03-18 20:32:04 <-- Defolos (~Defolos@fedora/defolos) a quitté (Ping timeout: 246 seconds) 2020-03-18 21:50:48 --> cheakoirccloud (uid293319@gateway/web/irccloud.com/x-leztjqejuwgrrfse) a rejoint #mcdevs 2020-03-18 22:36:11 --> VADemon (~VADemon@2a01:4f8:212:2f1d:88::41) a rejoint #mcdevs 2020-03-18 23:01:46 --> mgrech (~mgrech@194-166-99-28.adsl.highway.telekom.at) a rejoint #mcdevs 2020-03-18 23:16:10 KennyTV if you want to add the full login changes to wiki vg; always 4 ints, first 2 are representing the most signifcant, then 2 for least significant bits 2020-03-18 23:16:14 KennyTV they can be read as follows: https://github.com/ViaVersion/ViaVersion/commit/a7ab4153efddf6ca1e4dd2b5243a8ad7bcdb991a#diff-4b11cc1badde91cc8382438c50676514R14-R41 2020-03-18 23:36:14 +pokechu22 Makes sense given what they mentioned in the changelog, though I'm still not sure why they didn't just use the existing writeUUID code (/ didn't change the writeUUID code to use the 4 ints) 2020-03-19 02:37:57 --> RoboMWM_ (~RoboMWM@tf.robomwm.com) a rejoint #mcdevs 2020-03-19 02:39:14 <-- RoboMWM (~RoboMWM@tf.robomwm.com) a quitté (Ping timeout: 240 seconds) 2020-03-19 02:39:15 -- RoboMWM_ est maintenant connu sous le nom RoboMWM 2020-03-19 02:41:23 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 246 seconds) 2020-03-19 02:43:40 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-19 03:32:25 <-- dexter0 (~dexter0@2601:647:4500:700:7c:10ff:fe00:70b) a quitté (Ping timeout: 240 seconds) 2020-03-19 03:36:22 <-- cheakoirccloud (uid293319@gateway/web/irccloud.com/x-leztjqejuwgrrfse) a quitté (Quit: Connection closed for inactivity) 2020-03-19 03:50:59 <-- VADemon (~VADemon@2a01:4f8:212:2f1d:88::41) a quitté (Quit: left4dead) 2020-03-19 05:40:36 timmyRS Doesn't this basically just mean that UUIDs are treated as an unsigned 16-bit integer, so I could just send my internal UUID representation over the network? 2020-03-19 05:43:16 +pokechu22 128-bit, I think, but yeah. It's just that they already had a different way of treating them like that 2020-03-19 05:43:50 timmyRS I meant to say 16-byte 2020-03-19 05:44:30 timmyRS I was just looking to avoid writing that weird shifting code and writeInt calls when I could just add the raw bytes of my internal format... 2020-03-19 05:47:46 +pokechu22 Yeah, you should totally be able to 2020-03-19 06:09:56 --> dexter0 (~dexter0@c-73-222-1-210.hsd1.ca.comcast.net) a rejoint #mcdevs 2020-03-19 06:35:34 timmyRS Erg, wait, my writeUUID function is exactly that, so it's the same format? 2020-03-19 06:49:25 +pokechu22 I think so, just differently internally? I haven't confirmed it though 2020-03-19 07:57:23 --> Defolos (~Defolos@fedora/defolos) a rejoint #mcdevs 2020-03-19 08:05:37 <-- bildramer (~bildramer@p200300CF371C8D007F67408D92F33914.dip0.t-ipconnect.de) a quitté (Remote host closed the connection) 2020-03-19 08:06:02 --> bildramer (~bildramer@p200300CF371C8D007F67408D92F33914.dip0.t-ipconnect.de) a rejoint #mcdevs 2020-03-19 08:19:25 <-- mgrech (~mgrech@194-166-99-28.adsl.highway.telekom.at) a quitté (Ping timeout: 264 seconds) 2020-03-19 08:55:57 MiniDigger btw, I asked for why it was changed to 4 ints (and not two longs): slicedlime told me for better combat with scoreboards and stuff 2020-03-19 11:46:59 <-- eQuin0x_ (~eQuin0x_@xy0.powered.by.lunarbnc.net) a quitté (Write error: Connection reset by peer) 2020-03-19 12:21:32 --> eQuin0x_ (~eQuin0x_@xy0.powered.by.lunarbnc.net) a rejoint #mcdevs 2020-03-19 12:53:56 --> Me4502 (~quassel@unaffiliated/me4502) a rejoint #mcdevs 2020-03-19 14:08:16 --> mgrech (~mgrech@194-166-99-28.adsl.highway.telekom.at) a rejoint #mcdevs 2020-03-19 14:12:38 <-- Me4502 (~quassel@unaffiliated/me4502) a quitté (Read error: Connection reset by peer) 2020-03-19 14:20:47 <-- _123DMWM (~123DMWM@2601:18d:580:3870:f82a:dcc0:3924:c05c) a quitté (Read error: Connection reset by peer) 2020-03-19 14:21:12 --> _123DMWM (~123DMWM@2601:18d:580:3870:bd59:2063:56da:8315) a rejoint #mcdevs 2020-03-19 14:48:59 <-- Andrio (Andrio@questers-rest.andriocelos.net) a quitté (Remote host closed the connection) 2020-03-19 14:50:38 --> Andrio (Andrio@questers-rest.andriocelos.net) a rejoint #mcdevs 2020-03-19 15:09:43 <-- niceplace (~nplace@192.71.244.92) a quitté (Ping timeout: 260 seconds) 2020-03-19 15:15:47 --> niceplace (~nplace@86.106.136.94) a rejoint #mcdevs 2020-03-19 15:47:43 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 250 seconds) 2020-03-19 16:00:14 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-19 20:04:26 +pokechu22 Looks like the change that broke burger is that block light levels now use a lambda that gets the block state, instead of being passed a light level directly, because sea pickles have varying light levels depending on their state 2020-03-19 20:06:10 +pokechu22 ... and they added some new functions in the block creation code for e.g. logs 2020-03-19 21:00:00 <-- SpaceManiac (~SpaceMani@c-73-116-110-236.hsd1.ca.comcast.net) a quitté (Read error: Connection reset by peer) 2020-03-19 21:02:35 --> SpaceManiac (~SpaceMani@2601:200:4400:103::1034) a rejoint #mcdevs 2020-03-19 21:02:36 -- Mode #mcdevs [+v SpaceManiac] par ChanServ 2020-03-19 21:07:35 <-- SpaceManiac (~SpaceMani@2601:200:4400:103::1034) a quitté (Ping timeout: 256 seconds) 2020-03-19 21:09:16 --> SpaceManiac (~SpaceMani@2601:200:4400:103::1034) a rejoint #mcdevs 2020-03-19 21:09:16 -- Mode #mcdevs [+v SpaceManiac] par ChanServ 2020-03-19 21:43:01 Not-8b5f [Burger] Pokechu22 pushed 1 commit to master [+0/-0/±1] https://git.io/Jv1xU 2020-03-19 21:43:02 Not-8b5f [Burger] Amund211 fdff962 - Add six as an install requirement 2020-03-19 23:52:35 <-- eQuin0x_ (~eQuin0x_@xy0.powered.by.lunarbnc.net) a quitté (Ping timeout: 246 seconds) 2020-03-20 00:32:25 +pokechu22 I've fixed the blocks topping in 20w12a (https://github.com/mcdevs/Burger/compare/fdff962aeb1a...77f268a2f253) and updated https://pokechu22.github.io/Burger/diff_20w11a_20w12a.html and https://pokechu22.github.io/Burger/20w12a.html -- although now hardness information about stairs and slabs is missing. 2020-03-20 01:10:09 --> Dadido3_ (~quassel@p200300D9DF23B800C900C0E461E3EF7B.dip0.t-ipconnect.de) a rejoint #mcdevs 2020-03-20 01:12:45 <-- Dadido3 (~quassel@p200300D9DF23B8000DF4655D33DAD1EE.dip0.t-ipconnect.de) a quitté (Ping timeout: 240 seconds) 2020-03-20 02:31:29 bswartz pokechu22: Are you able to extract things like block hardness in an automated way? 2020-03-20 02:32:17 +pokechu22 Burger tries to extract it, yeah, but it's not always possible 2020-03-20 02:32:45 bswartz Still that's really cool 2020-03-20 02:33:04 bswartz Are you able to extract things like hitboxes? 2020-03-20 02:34:46 +pokechu22 I don't currently do that for blocks, and I think it would be pretty hard nowadays since some hitboxes are complicated shapes. But I do extract entity sizes at least 2020-03-20 02:35:06 bswartz Yeah a lot of blocks have crazy shapes 2020-03-20 02:35:17 bswartz I've hand coded like half of them, and I ran out of energy for the other half 2020-03-20 02:36:15 bswartz The most insane ones are the bells, lecterns, and grindstones 2020-03-20 02:38:15 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 265 seconds) 2020-03-20 02:40:01 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-20 05:14:24 <-- mgrech (~mgrech@194-166-99-28.adsl.highway.telekom.at) a quitté (Quit: mgrech) 2020-03-20 05:17:59 --> mgrech (~mgrech@194-166-99-28.adsl.highway.telekom.at) a rejoint #mcdevs 2020-03-20 06:07:30 <-- mgrech (~mgrech@194-166-99-28.adsl.highway.telekom.at) a quitté (Ping timeout: 250 seconds) 2020-03-20 06:46:44 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2020-03-20 06:49:01 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 246 seconds) 2020-03-20 06:49:02 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2020-03-20 07:17:32 --> eQuin0x_ (~eQuin0x_@xy0.powered.by.lunarbnc.net) a rejoint #mcdevs 2020-03-20 08:02:54 <-- gabizou (~gabizou@69.147.207.130) a quitté (Ping timeout: 256 seconds) 2020-03-20 08:03:10 --> gabizou (~gabizou@69.147.207.130) a rejoint #mcdevs 2020-03-20 08:27:04 --> mgrech (~mgrech@194-166-99-28.adsl.highway.telekom.at) a rejoint #mcdevs 2020-03-20 08:28:10 --> JuniorJPDJ (juniorjp1@gateway/shell/matrix.org/x-siapzpjndqceauqb) a rejoint #mcdevs 2020-03-20 08:35:16 <-- mgrech (~mgrech@194-166-99-28.adsl.highway.telekom.at) a quitté (Ping timeout: 250 seconds) 2020-03-20 09:33:25 --> Jw2476 (925a12f1@241.18.90.146.dyn.plus.net) a rejoint #mcdevs 2020-03-20 09:34:35 Jw2476 Hey, I've just got my server all the way through the authentication procedure, and sent LoginSuccess, but after that Minecraft goes Joining World... What packets does it expect to make the player spawn 2020-03-20 09:35:08 Jw2476 Ignore me I've just found it 2020-03-20 09:35:10 <-- Jw2476 (925a12f1@241.18.90.146.dyn.plus.net) a quitté (Remote host closed the connection) 2020-03-20 09:40:35 <-- eQuin0x_ (~eQuin0x_@xy0.powered.by.lunarbnc.net) a quitté (Ping timeout: 246 seconds) 2020-03-20 09:54:06 --> eQuin0x_ (~eQuin0x_@xy0.powered.by.lunarbnc.net) a rejoint #mcdevs 2020-03-20 09:58:39 <-- jkdhn (jack@jkdhn.me) a quitté (Ping timeout: 258 seconds) 2020-03-20 10:16:23 --> jkdhn (jack@jkdhn.me) a rejoint #mcdevs 2020-03-20 11:32:07 --> Me4502 (~quassel@unaffiliated/me4502) a rejoint #mcdevs 2020-03-20 12:39:26 <-- eQuin0x_ (~eQuin0x_@xy0.powered.by.lunarbnc.net) a quitté (Quit: Bye) 2020-03-20 12:42:26 --> eQuin0x_ (~eQuin0x_@xy0.powered.by.lunarbnc.net) a rejoint #mcdevs 2020-03-20 14:46:10 <-- Me4502 (~quassel@unaffiliated/me4502) a quitté (Read error: Connection reset by peer) 2020-03-20 15:44:13 --> VADemon (~VADemon@2a01:4f8:212:2f1d:88::41) a rejoint #mcdevs 2020-03-20 15:47:54 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 240 seconds) 2020-03-20 15:50:12 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-20 16:19:09 --> mgrech (~mgrech@194-166-99-28.adsl.highway.telekom.at) a rejoint #mcdevs 2020-03-20 17:00:46 <-- MiniDigger (~MiniDigge@electroniccat.smells.minidigger.me) a quitté (Quit: The Lounge - https://thelounge.chat) 2020-03-20 17:01:15 --> MiniDigger (~MiniDigge@electroniccat.smells.minidigger.me) a rejoint #mcdevs 2020-03-20 17:55:21 --> Jw2476 (925a12f1@241.18.90.146.dyn.plus.net) a rejoint #mcdevs 2020-03-20 17:57:52 Jw2476 on the JoinGame packet, how does one just a sha256sum into a Long to send to the client, sha sums have letters in which throws an error 2020-03-20 18:00:01 +pokechu22 The sha sum is a hex string, but hex strings are just a way of representing bytes 2020-03-20 18:00:35 +pokechu22 You should also be able to get the data as bytes from whatever library you're using to compute the sha256sum 2020-03-20 18:00:53 Jw2476 ok thank you 2020-03-20 18:04:02 <-- charims_ (~quassel@wsip-24-234-28-130.lv.lv.cox.net) a quitté (Ping timeout: 240 seconds) 2020-03-20 18:05:55 --> charims (~quassel@wsip-24-234-28-130.lv.lv.cox.net) a rejoint #mcdevs 2020-03-20 18:08:15 <-- Jw2476 (925a12f1@241.18.90.146.dyn.plus.net) a quitté #mcdevs 2020-03-20 18:45:24 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 250 seconds) 2020-03-20 19:27:55 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-20 19:37:20 <-- VADemon (~VADemon@2a01:4f8:212:2f1d:88::41) a quitté (Ping timeout: 246 seconds) 2020-03-20 19:42:44 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 256 seconds) 2020-03-20 19:44:26 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-20 21:27:46 <-- charims (~quassel@wsip-24-234-28-130.lv.lv.cox.net) a quitté (Read error: Connection reset by peer) 2020-03-20 21:29:04 --> charims (~quassel@wsip-24-234-28-130.lv.lv.cox.net) a rejoint #mcdevs 2020-03-21 00:23:13 --> eQuin0x__ (~eQuin0x_@xy0.powered.by.lunarbnc.net) a rejoint #mcdevs 2020-03-21 00:23:27 <-- m0r13 (~m0r13@2a01:4f8:201:8174:73:0:b00b:135) a quitté (Ping timeout: 246 seconds) 2020-03-21 00:25:27 <-- md_5 (~md_5@mcdevs/trusted/md-5) a quitté (Ping timeout: 246 seconds) 2020-03-21 00:25:28 --> md_5- (~md_5@mcdevs/trusted/md-5) a rejoint #mcdevs 2020-03-21 00:25:30 -- Mode #mcdevs [+v md_5-] par ChanServ 2020-03-21 00:25:31 --> m0r13 (~m0r13@2a01:4f8:201:8174:73:0:b00b:135) a rejoint #mcdevs 2020-03-21 00:25:38 <-- eQuin0x_ (~eQuin0x_@xy0.powered.by.lunarbnc.net) a quitté (Read error: Connection reset by peer) 2020-03-21 00:31:16 <-- Defolos (~Defolos@fedora/defolos) a quitté (Ping timeout: 246 seconds) 2020-03-21 00:33:18 --> Defolos (~Defolos@fedora/defolos) a rejoint #mcdevs 2020-03-21 01:02:53 --> redrield (~kaitlyn@hnmron6104w-lp140-01-65-95-197-0.dsl.bell.ca) a rejoint #mcdevs 2020-03-21 01:04:06 redrield is EntityEffect supposed to be sent once when the effect is added, or should it be sent periodically? 2020-03-21 01:05:26 +pokechu22 I think once it's added and once it's removed, but I'll double check 2020-03-21 01:06:30 +pokechu22 I know from servers running at less than full speed that the client won't remove a potion effect when it's expired until the server tells it to; it'll just display as 00:00 2020-03-21 02:09:06 redrield So to be clear, send once with the duration, then when the server has counted down the remaining time to 0, send again with duration 0? 2020-03-21 02:42:44 +pokechu22 Yep. 2020-03-21 02:46:04 +pokechu22 Oh, actually, looks like it also updates it every 600 ticks (rather, when the remaining duration is equal to 0 mod 600) i.e. 30 seconds. But I'm guessing that's just to deal with the two timers getting desync'd and isn't strictly necessary 2020-03-21 03:21:04 <-- yawkat (~yawkat@cats.coffee) a quitté (Ping timeout: 250 seconds) 2020-03-21 03:31:36 --> yawkat (~yawkat@cats.coffee) a rejoint #mcdevs 2020-03-21 03:36:54 <-- charims (~quassel@wsip-24-234-28-130.lv.lv.cox.net) a quitté (Ping timeout: 240 seconds) 2020-03-21 03:38:14 --> charims (~quassel@wsip-24-234-28-130.lv.lv.cox.net) a rejoint #mcdevs 2020-03-21 03:38:35 <-- kev009 (~kev009@ip72-222-200-117.ph.ph.cox.net) a quitté (Quit: Konversation terminated!) 2020-03-21 03:43:42 --> kev009 (~kev009@ip72-222-200-117.ph.ph.cox.net) a rejoint #mcdevs 2020-03-21 03:43:42 -- Mode #mcdevs [+v kev009] par ChanServ 2020-03-21 04:05:28 <-- redrield (~kaitlyn@hnmron6104w-lp140-01-65-95-197-0.dsl.bell.ca) a quitté (Quit: WeeChat 2.7.1) 2020-03-21 04:55:06 <-- mgrech (~mgrech@194-166-99-28.adsl.highway.telekom.at) a quitté (Ping timeout: 250 seconds) 2020-03-21 05:04:59 --> Me4502 (~quassel@unaffiliated/me4502) a rejoint #mcdevs 2020-03-21 05:28:54 --> VADemon (~VADemon@2a01:4f8:212:2f1d:88::41) a rejoint #mcdevs 2020-03-21 05:50:21 --> mgrech (~mgrech@194.166.99.28) a rejoint #mcdevs 2020-03-21 06:19:32 <-- mgrech (~mgrech@194.166.99.28) a quitté (Quit: mgrech) 2020-03-21 07:16:54 <-- kev009 (~kev009@ip72-222-200-117.ph.ph.cox.net) a quitté (Ping timeout: 240 seconds) 2020-03-21 07:21:47 <-- VADemon (~VADemon@2a01:4f8:212:2f1d:88::41) a quitté (Quit: left4dead) 2020-03-21 08:16:31 <-- eQuin0x__ (~eQuin0x_@xy0.powered.by.lunarbnc.net) a quitté (Quit: Bye) 2020-03-21 08:37:04 <-- _123DMWM (~123DMWM@2601:18d:580:3870:bd59:2063:56da:8315) a quitté (Ping timeout: 246 seconds) 2020-03-21 08:39:34 --> _123DMWM (~123DMWM@c-73-60-129-142.hsd1.ma.comcast.net) a rejoint #mcdevs 2020-03-21 08:48:41 <-- _123DMWM (~123DMWM@c-73-60-129-142.hsd1.ma.comcast.net) a quitté (Ping timeout: 246 seconds) 2020-03-21 08:49:17 --> _123DMWM (~123DMWM@c-73-60-129-142.hsd1.ma.comcast.net) a rejoint #mcdevs 2020-03-21 09:14:52 <-- SpaceManiac (~SpaceMani@2601:200:4400:103::1034) a quitté (Remote host closed the connection) 2020-03-21 09:15:08 --> SpaceManiac (~SpaceMani@2601:200:4400:103::1048) a rejoint #mcdevs 2020-03-21 09:15:08 -- Mode #mcdevs [+v SpaceManiac] par ChanServ 2020-03-21 13:34:14 --> mgrech (~mgrech@194-166-99-28.adsl.highway.telekom.at) a rejoint #mcdevs 2020-03-21 13:45:41 --> VADemon (~VADemon@2a01:4f8:212:2f1d:88::41) a rejoint #mcdevs 2020-03-21 14:10:10 <-- Me4502 (~quassel@unaffiliated/me4502) a quitté (Read error: Connection reset by peer) 2020-03-21 16:34:07 <-- VADemon (~VADemon@2a01:4f8:212:2f1d:88::41) a quitté (Read error: Connection reset by peer) 2020-03-21 17:24:34 --> kev009 (~kev009@ip72-222-200-117.ph.ph.cox.net) a rejoint #mcdevs 2020-03-21 17:24:35 -- Mode #mcdevs [+v kev009] par ChanServ 2020-03-21 19:38:54 --> enpycfr (~enpycfr@253.248.92.92.rev.sfr.net) a rejoint #mcdevs 2020-03-21 19:49:23 <-- enpycfr (~enpycfr@253.248.92.92.rev.sfr.net) a quitté (Quit: Leaving) 2020-03-21 20:10:55 <-- jkdhn (jack@jkdhn.me) a quitté (Quit: Disconnected) 2020-03-21 20:13:16 --> jkdhn (jack@jkdhn.me) a rejoint #mcdevs 2020-03-21 21:01:52 <-- Andrio (Andrio@questers-rest.andriocelos.net) a quitté (Ping timeout: 246 seconds) 2020-03-21 21:22:28 --> Andrio (Andrio@questers-rest.andriocelos.net) a rejoint #mcdevs 2020-03-21 23:07:23 <-- peterix-w (~peterix@quassel.woboq.com) a quitté (Quit: No Ping reply in 180 seconds.) 2020-03-21 23:08:39 --> peterix (quassel@quassel.woboq.de) a rejoint #mcdevs 2020-03-22 01:37:12 Disconsented for varint, varlong has anyone worked out a way to get the number of bytes needed to encoded without encoding it? 2020-03-22 02:38:23 +pokechu22 The easiest way to do that is to basically copy the encode method and just count bytes instead of encoding it. But it's basically just if it's larger than 2^7, 2 bytes, 2^14, 3 bytes, etc (more or less; signed values need to be considered too) 2020-03-22 02:54:00 mgrech Disconsented: you can do it using clz 2020-03-22 02:54:40 mgrech https://github.com/mgrech/vitamine/blob/master/source/proxyd/serialize.hpp#L22 2020-03-22 03:12:10 Disconsented Thanks ^_^ 2020-03-22 03:21:49 <-- yawkat (~yawkat@cats.coffee) a quitté (Ping timeout: 264 seconds) 2020-03-22 03:26:18 Disconsented I went with the switch/match idea, quicker to write 2020-03-22 03:34:04 --> Me4502 (~quassel@unaffiliated/me4502) a rejoint #mcdevs 2020-03-22 03:36:33 --> yawkat (~yawkat@cats.coffee) a rejoint #mcdevs 2020-03-22 05:03:58 <-- matthewprenger (~matthewpr@136.33.220.153) a quitté (Quit: matthewprenger) 2020-03-22 05:11:34 --> matthewprenger (~matthewpr@136.33.220.153) a rejoint #mcdevs 2020-03-22 05:42:41 <-- thekinrar (~thekinrar@cpc115984-dals23-2-0-cust217.20-2.cable.virginm.net) a quitté (Quit: Leaving) 2020-03-22 07:03:46 <-- mgrech (~mgrech@194-166-99-28.adsl.highway.telekom.at) a quitté (Ping timeout: 250 seconds) 2020-03-22 14:10:51 <-- Me4502 (~quassel@unaffiliated/me4502) a quitté (Read error: Connection reset by peer) 2020-03-22 15:25:03 --> mgrech (~mgrech@194.166.99.28) a rejoint #mcdevs 2020-03-22 16:48:36 <-- KennyTV (~KennyTV@static.162.124.47.78.clients.your-server.de) a quitté (Quit: o>) 2020-03-22 16:49:13 --> KennyTV (~KennyTV@static.162.124.47.78.clients.your-server.de) a rejoint #mcdevs 2020-03-22 17:56:57 <-- KennyTV (~KennyTV@static.162.124.47.78.clients.your-server.de) a quitté (Quit: o>) 2020-03-22 17:57:28 --> KennyTV (~KennyTV@static.162.124.47.78.clients.your-server.de) a rejoint #mcdevs 2020-03-22 20:25:17 <-- balrog (~balrog@unaffiliated/balrog) a quitté (Quit: Bye) 2020-03-22 20:29:34 --> balrog (~balrog@unaffiliated/balrog) a rejoint #mcdevs 2020-03-22 20:54:32 <-- SupaHam (~SupaHam@supaham.com) a quitté (Read error: No route to host) 2020-03-22 20:54:53 --> SupaHam (~SupaHam@supaham.com) a rejoint #mcdevs 2020-03-22 20:55:24 <-- SupaHam (~SupaHam@supaham.com) a quitté (Client Quit) 2020-03-22 20:57:00 --> SupaHam (~SupaHam@supaham.com) a rejoint #mcdevs 2020-03-22 21:01:46 <-- Andrio (Andrio@questers-rest.andriocelos.net) a quitté (Ping timeout: 246 seconds) 2020-03-22 21:06:42 --> Andrio (Andrio@questers-rest.andriocelos.net) a rejoint #mcdevs 2020-03-22 21:13:02 <-- SpaceManiac (~SpaceMani@2601:200:4400:103::1048) a quitté (Ping timeout: 246 seconds) 2020-03-22 21:17:39 --> SpaceManiac (~SpaceMani@2601:200:4400:103::1054) a rejoint #mcdevs 2020-03-22 21:17:39 -- Mode #mcdevs [+v SpaceManiac] par ChanServ 2020-03-22 22:06:54 <-- yawkat (~yawkat@cats.coffee) a quitté (Ping timeout: 240 seconds) 2020-03-22 23:44:28 --> redrield (~kaitlyn@hnmron6104w-lp140-01-65-95-197-0.dsl.bell.ca) a rejoint #mcdevs 2020-03-22 23:45:33 redrield Having a problem with trying to use EntityEffect, using protocol version 404 (1.13.2), I send a packet that seems to correctly encode the duration of the effect in seconds (0x5a, 120 seconds), but the client displays the effect with around 5 seconds, and then simply displays at 0:00 until the packet is re-sent with the new remaining duration, at which point the cycle repeats 2020-03-22 23:47:38 timmyRS I think the duration is provided in ticks? So, 90 ticks would equal 4,5 seconds. 2020-03-22 23:49:10 timmyRS Although according to the wiki, it's seconds. 2020-03-22 23:49:20 timmyRS Also, how does 0x5a equal 120 seconds for you? 2020-03-22 23:52:03 redrield 0x5a = 120_10 2020-03-22 23:52:14 redrield Based on the description from the wiki I assumed that duration was encoded as seconds on the wire 2020-03-22 23:52:37 redrield https://0x0.st/iaJn.png 2020-03-22 23:53:04 timmyRS Yes, but in my hexadecimal system 0x5a is 90 2020-03-22 23:53:34 redrield Right, sorry it was sent on one of the refresh packets as that when there were 90 seconds left 2020-03-22 23:54:01 timmyRS Could you provide a dump of the entire entity effect packetß 2020-03-22 23:55:29 redrield 07 00 53 00 01 00 5a 02 2020-03-22 23:55:40 redrield I can throw together a wireshark pcap if you need 2020-03-22 23:56:23 timmyRS Nah, that's fine 2020-03-22 23:57:21 timmyRS What's the 00 doing there? 2020-03-22 23:57:51 timmyRS Oh, compressed? 2020-03-22 23:58:31 redrield Compression threshold is higher than for this packet, but it is enabled 2020-03-22 23:59:17 timmyRS Hm, that packet looks fine though 2020-03-23 00:00:56 redrield ok it is actually encoded as ticks on the wie 2020-03-23 00:01:04 redrield wire* 2020-03-23 00:06:30 --> yawkat (~yawkat@cats.coffee) a rejoint #mcdevs 2020-03-23 00:08:23 timmyRS I've just tested this with 1.8 up to 1.15.2 and it's always in ticks. Guess I'll update the Protocol page. 2020-03-23 00:57:37 <-- Defolos (~Defolos@fedora/defolos) a quitté (Quit: leaving) 2020-03-23 01:02:22 --> Defolos (~Defolos@fedora/defolos) a rejoint #mcdevs 2020-03-23 01:04:45 <-- kashike (kashike@unaffiliated/kashike) a quitté (Ping timeout: 240 seconds) 2020-03-23 01:08:21 --> kashike (kashike@unaffiliated/kashike) a rejoint #mcdevs 2020-03-23 01:25:58 <-- redrield (~kaitlyn@hnmron6104w-lp140-01-65-95-197-0.dsl.bell.ca) a quitté (Quit: WeeChat 2.7.1) 2020-03-23 01:29:24 <-- Defolos (~Defolos@fedora/defolos) a quitté (Ping timeout: 256 seconds) 2020-03-23 06:09:53 x10A94 Does the Window Confirmation packet not reset the inventory state on the client? 2020-03-23 06:10:24 x10A94 like, do I have to manually set all the affected slots back 2020-03-23 06:12:03 +pokechu22 If accepted is false in it? I think the server also needs to send the affected slot back, but I'm not 100% sure 2020-03-23 06:12:43 x10A94 How can I reset the slot that's currently on the cursor? 2020-03-23 06:12:50 x10A94 (working with raw packets here) 2020-03-23 06:14:02 +pokechu22 It's slot -1 2020-03-23 06:14:36 +pokechu22 Err, -1 for both inventory AND slot, according to https://wiki.vg/Protocol#Set_Slot 2020-03-23 06:15:02 x10A94 oh I see 2020-03-23 06:15:14 x10A94 god this is gonna be silly 2020-03-23 06:16:47 <-- AndrewPH (~Butts@2606:db00:0:62e::b) a quitté (Ping timeout: 240 seconds) 2020-03-23 06:18:06 +pokechu22 Looks like it actually resyncs all slots if it also rejects the transaction, not just the affected ones 2020-03-23 06:18:38 x10A94 well, that might be easier for me 2020-03-23 06:19:25 x10A94 I guess the Window Confirm packet is otherwise useless, then 2020-03-23 06:19:26 +pokechu22 It also only does it right after the confirm transaction packet is sent, and then doesn't send any further confirm transaction packets until the client confirms it's caught up 2020-03-23 06:20:32 x10A94 I only want to do the bare minimum to keep the inventory in check 2020-03-23 06:20:43 x10A94 because it's immutable by definition 2020-03-23 06:22:41 +pokechu22 If the client's not supposed to make any changes, you probably don't even need to mess with confirm transaction; you can just set it back. Confirm transaction is more for handling the inventory changing (e.g. from another player) while the player didn't know about that, to my understanding 2020-03-23 06:23:25 x10A94 yeah that seems reasonable 2020-03-23 06:27:31 +pokechu22 In fact, for players in spectator mode (for which inventories are immutable), clicking a slot just results in it resending all the items, without a confirm transaction packet, so that's probably the way to go 2020-03-23 06:28:38 x10A94 I wonder why there isn't a rule for the player to lock the inventory 2020-03-23 06:28:54 x10A94 like, using serverside tricks for spectator players seems.. weird 2020-03-23 06:29:36 x10A94 Also a nice consequence of using a tickless server is that the inventory correction is actually instant 2020-03-23 06:29:46 x10A94 at least when at a low enough ping 2020-03-23 06:44:51 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2020-03-23 06:45:03 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 250 seconds) 2020-03-23 06:45:03 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2020-03-23 07:09:59 -- tassu4 est maintenant connu sous le nom tassu 2020-03-23 08:00:09 --> Defolos (~Defolos@fedora/defolos) a rejoint #mcdevs 2020-03-23 12:06:49 <-- Defolos (~Defolos@fedora/defolos) a quitté (Ping timeout: 264 seconds) 2020-03-23 12:08:38 --> Defolos (~Defolos@fedora/defolos) a rejoint #mcdevs 2020-03-23 16:26:18 bswartz x10A94: "Tickless" server? What is that? 2020-03-23 16:26:46 MiniDigger a server implementation without a main tick look I would say 2020-03-23 16:27:51 bswartz How would such a server cope with misbehaving clients? 2020-03-23 16:33:42 MiniDigger I wouldn't be able to tell, I cant read rust :D 2020-03-23 16:40:38 Defolos tickless server, where did you find that? 2020-03-23 16:41:03 MiniDigger you dont find it 2020-03-23 16:41:04 bswartz Defolos: scroll up 6 lines 2020-03-23 16:41:05 MiniDigger you write it 2020-03-23 16:43:32 Defolos bswartz: I guess I wasn't online at the time, just see you asking x10A94 about a tickless server 2020-03-23 16:47:14 bswartz I would just worry about the potential for a malicious client to send movement updates at >20Hz 2020-03-23 16:47:59 MiniDigger well, you can do packet limiting, you can do throttling (only one packet per 50ms with a bit of jitter or smth) 2020-03-23 16:48:40 bswartz Yeah but that gets complex to manage with multiple clients experiencing different amounts of lag 2020-03-23 16:53:24 bswartz There's a tradeoff between allowing clients to manipulate the flow of time vs. causing annoying teleport artifacts for clients experiencing legitimately significant congestion 2020-03-23 17:25:08 <-- imharvol (~imharvol@92.176.208.85) a quitté (Quit: WeeChat 2.3) 2020-03-23 17:57:43 +pokechu22 I'd assume that it'd be used for something like hub servers where correct movement doesn't really matter that much 2020-03-23 17:58:00 +pokechu22 Defolos: The messages you missed can be found in https://logs.rom1504.fr/parts2/201.txt 2020-03-23 18:03:24 Defolos pokechu22: thanks! Didn't know this channel is logged 2020-03-23 19:02:23 --> RealRph (~rph@139.28.40.44) a rejoint #mcdevs 2020-03-23 19:03:07 RealRph What needs to be done in addition to the player location packet for chunks to actually be shown? 2020-03-23 19:03:29 RealRph I am sending chunk data packets and the player position packet but for some erason the game still shows "Waiting for chunk..." 2020-03-23 19:03:51 RealRph The waiting for chunk message goes away when I use the direct palette instead of the more efficient indirect one, however I still don't see any blocks 2020-03-23 19:05:33 +pokechu22 The game doesn't render a chunk unless the chunk's neighbors exist IIRC, so you'll need to send at least a 3x3 chunk area (however, you should see block outlines and they should show up in F3 if you look at them) 2020-03-23 19:07:23 +pokechu22 "Waiting for chunk" probably means the game didn't like your chunk data packet and it didn't add the chunk... but I'd expect that to result in a disconnect message, actually 2020-03-23 19:07:36 RealRph I wish there was an easy way to attach a debugger to the game itself 2020-03-23 19:07:47 RealRph I fiddled with visualVM but the heap dumps don't make sense without mappings 2020-03-23 19:08:28 RealRph oh I just noticed 2020-03-23 19:08:33 RealRph multiMC has a console built in...... 2020-03-23 19:08:45 RealRph And this: java.lang.RuntimeException: VarInt too big 2020-03-23 19:08:47 RealRph is the error. 2020-03-23 19:08:52 RealRph Now I need to find which varint that is 2020-03-23 19:09:58 +pokechu22 The official launcher also has a console (though I think it's hidden by default), and the game outputs the same stuff into .minecraft/logs, for reference. Though multimc is still a fine way to go about it 2020-03-23 19:10:11 RealRph I never got the official launcher to work on linux 2020-03-23 19:10:31 RealRph And multimc (at least for me) is a reliable way to launch the game, which is what it should do 2020-03-23 19:10:43 RealRph And I think it shouldn't impact anything besides the startup and file management, right? 2020-03-23 19:11:19 +pokechu22 Yeah, everything should be fine; the multimc dev even works for mojang nowadays IIRC 2020-03-23 19:11:36 RealRph Also, is there a way to get more information about the error 2020-03-23 19:11:40 RealRph like at what byte offset it happened 2020-03-23 19:12:01 RealRph Seems like it only appears with chunks in the indirect palette mode 2020-03-23 19:12:11 +pokechu22 https://wiki.vg/Debugging should give you a stacktrace, but no byte offsets unfortunately 2020-03-23 19:12:43 +pokechu22 Which MC version are you targetting? 2020-03-23 19:12:58 RealRph 1.15.2 2020-03-23 19:13:21 RealRph Direct palette mode shows the chunk but no blocks in it 2020-03-23 19:15:57 bswartz RealRph: Did you send a Update View Position? 2020-03-23 19:16:16 RealRph Yes 2020-03-23 19:16:19 +pokechu22 If one works and the other doesn't, I'm guessing that you've got the format wrong, and it's reading light data for the "number of block entities" varint 2020-03-23 19:16:31 RealRph Is there light data included in the chunk data packet? 2020-03-23 19:16:39 RealRph AFAIK its a separate thing? 2020-03-23 19:16:42 +pokechu22 ... oh, right 2020-03-23 19:16:46 bswartz Light got moved to a different packet in recent versions 2020-03-23 19:17:02 RealRph Does update view positions do varints or normal ints 2020-03-23 19:17:18 bswartz VarInts 2020-03-23 19:17:32 RealRph So if player is at X: 60, Y: 80, Z: 60 2020-03-23 19:17:42 RealRph Sending just 2 bytes, 0x0303 should be enough 2020-03-23 19:18:00 bswartz Yes 2020-03-23 19:18:22 RealRph in my previous server experiments I didn't send that packet and chunks worked, just didn't render past 1 cube section 2020-03-23 19:18:30 +pokechu22 Well, it's still possible that it's reading block data for the number of block entities, especially since in an indirect palette you're more likely to have the highest bit set 2020-03-23 19:18:53 RealRph the last few dozen of my bytes are just zeros 2020-03-23 19:20:25 RealRph It could also be that something's wrong with my map read routine, not the chunk packet generation routine 2020-03-23 19:21:18 +pokechu22 Could you post a hexdump of one of your chunk packets (using the indirect palette)? 2020-03-23 19:21:27 RealRph indirect palette? 2020-03-23 19:21:29 RealRph wait a second 2020-03-23 19:22:01 +pokechu22 Well, whichever one gives VarInt too big -- I assume that's the indirect palette one? 2020-03-23 19:22:05 RealRph yes 2020-03-23 19:22:28 RealRph huh, this one gives a different error 2020-03-23 19:22:34 RealRph ow I get java.lang.ArrayIndexOutOfBoundsException: 16 2020-03-23 19:22:37 RealRph now* 2020-03-23 19:22:42 RealRph However, its still with indirect palette 2020-03-23 19:24:33 RealRph https://gist.github.com/rphsoftware/7e39d3448b07664d7ee100d46cd47719 here is the gist 2020-03-23 19:24:48 RealRph this is full packet body, no packet header 2020-03-23 19:26:51 +pokechu22 Huh, 0x84 for the biome, so flower forest? Interesting 2020-03-23 19:26:56 RealRph yes 2020-03-23 19:26:59 RealRph I am reading a region file 2020-03-23 19:27:06 RealRph The biome is intentional 2020-03-23 19:27:19 RealRph and, according to the documentation, biomes are just big endian ints 2020-03-23 19:29:24 bswartz RealRph: You have packet compression working? 2020-03-23 19:29:33 RealRph yes actually 2020-03-23 19:29:42 RealRph as a test, I have compression threshold set to 0 2020-03-23 19:29:45 RealRph and keepalive is working 2020-03-23 19:30:03 bswartz A packet this large should be compressed 2020-03-23 19:30:14 RealRph it gets compressed in the netcode 2020-03-23 19:30:33 bswartz You're confident that's not buggy? 2020-03-23 19:30:43 RealRph Well I found an issue 2020-03-23 19:30:50 RealRph in my map loader code 2020-03-23 19:31:09 RealRph and in the code that matches block IDs to registry IDs 2020-03-23 19:31:18 RealRph err, block names 2020-03-23 19:36:56 bswartz You might want to test with generated test chunks -- some kind of simple pattern of dirt and stone 2020-03-23 19:37:06 RealRph Yea, I will try that 2020-03-23 19:37:12 RealRph I might have flown too close to the sun with this one 2020-03-23 19:43:41 <-- _123DMWM (~123DMWM@c-73-60-129-142.hsd1.ma.comcast.net) a quitté (Read error: Connection reset by peer) 2020-03-23 19:45:04 RealRph ok at least my packed array implementation seems to work 2020-03-23 19:45:35 +pokechu22 Hm. Looking at your packet, everything seems good until the first chunk section; I get the size of the data array at 00001144 as f4 60 => 12404 which looks right, and a block count short of 10 00 => 4096, which is also good. 2020-03-23 19:46:50 +pokechu22 Bits per block is 0e (=> 14) which seems fine, but then it's a direct palette (which has no fields), so the next value is 00 for data array length, which seems wrong. (21 01 after that also looks odd) 2020-03-23 19:47:37 RealRph you just made me realise my stupidity 2020-03-23 19:47:45 RealRph i forgot to include data array length 2020-03-23 19:48:06 RealRph I Will see if that does it 2020-03-23 19:55:59 RealRph I found the bug 2020-03-23 19:56:04 RealRph it was incredibly stupid (from me) 2020-03-23 19:56:18 bswartz +1 for debugging 2020-03-23 19:56:31 RealRph Honestly, if it wasn't for you, I probably wouldn't have found it 2020-03-23 19:56:35 RealRph I appreciate the help 2020-03-23 19:57:51 RealRph just one more little question 2020-03-23 19:58:01 RealRph https://imgur.com/a/hoDhYUW do you know why the part under the cube part is missing? 2020-03-23 19:58:08 RealRph (I can only see the "cube" I'm in 2020-03-23 19:59:35 bswartz Sorry I don't. I do 100% client work and I'm not familiar with the issues faced when writing a server 2020-03-23 20:00:07 RealRph ah 2020-03-23 20:00:25 RealRph I tried to resolve this by sending the update view position packet but its not doing anything 2020-03-23 20:00:42 RealRph I will try fixing it myself and stick around here 2020-03-23 20:00:50 bswartz View distance maybe? 2020-03-23 20:01:13 RealRph is view distance sent in chunks or blocks 2020-03-23 20:01:25 +pokechu22 Are the blocks under the cube solid there? 2020-03-23 20:01:31 +pokechu22 View distance is in chunks 2020-03-23 20:01:36 RealRph yes, the blcoks are solid 2020-03-23 20:01:38 RealRph when I fly closer, they appear 2020-03-23 20:01:39 bswartz View distance is chunks 2020-03-23 20:03:22 bswartz Did you send light data for the chunk? 2020-03-23 20:03:26 RealRph no 2020-03-23 20:03:30 RealRph is it necessary to render correctly? 2020-03-23 20:03:55 bswartz Client might consider the chunk not fully loaded with no light info, I'm not sure though 2020-03-23 20:04:17 +pokechu22 There are some rather stupid culling issues I've been investigating lately (https://imgur.com/a/9TTgZ5q) but I feel like that's probably not it (those ones involve walls fully blocking off chunks; I doubt it's the same thing though maybe chunks that weren't rendered due to not existing act the same way?) 2020-03-23 20:05:07 bswartz And did you send the neighboring chunks too? pokechu22 mentioned that the client won't render a chunk if the neighboring chunks isn't also loaded 2020-03-23 20:05:13 RealRph I have 2020-03-23 20:05:26 bswartz That makes sense because client can't update light info without neighboring chunks 2020-03-23 20:05:29 RealRph Let me quickly upload a video of how it looks 2020-03-23 20:06:02 bswartz I recommend sending a light update packet for each loaded chunk, even if the data is garbage 2020-03-23 20:06:08 bswartz See if that makes the client happier 2020-03-23 20:06:22 RealRph What about the heightmaps? 2020-03-23 20:06:33 RealRph from looking at my packets myself, I think I send a correct one 2020-03-23 20:06:38 RealRph https://www.youtube.com/watch?v=Z4xRL0d0WjI&feature=youtu.be here's a video of the bug 2020-03-23 20:07:54 bswartz I don't know the purpose of heightmaps. It's new in 1.14.0 2020-03-23 20:09:13 RealRph ohhhh 2020-03-23 20:09:15 RealRph I think I got it 2020-03-23 20:09:19 +pokechu22 It might still be related to having very few chunks loaded; what happens if you send a 5x5 or something? 2020-03-23 20:09:35 RealRph I sent 5x5 2020-03-23 20:09:37 RealRph and it actually works 2020-03-23 20:11:55 bswartz pokechu22: Do you know why height maps were added in 1.14? 2020-03-23 20:12:03 RealRph because this server I'm writing is just supposed to be for map previews, I think I should generate "edge" chunks just filled with barrier blocks 2020-03-23 20:12:12 +pokechu22 I think it's something to do with sky lighting 2020-03-23 20:12:26 +pokechu22 but I'm not 100% sure 2020-03-23 20:12:45 RealRph also, the client seems to do some lighting by itself, without the server intervenion 2020-03-23 20:13:19 bswartz RealRph: Yes server only sends light at chunk load time -- after that the client is responsible for updating light maps 2020-03-23 20:13:47 +pokechu22 The client handles lighting on block changes (e.g. placing a torch), though the server is supposed to send light updates for very large changes IIRC (changes where it'd use a chunk update packet with full chunk set to false) 2020-03-23 20:14:15 RealRph in this project I don't need accurate light thankfully 2020-03-23 20:14:23 bswartz That's important because the client can't compute light maps until neighboring chunks are loaded, so for chunks at the edge of the world, the server's light map information is needed 2020-03-23 20:14:43 RealRph in case of edges of the world, would sending just empty chunks work as well? 2020-03-23 20:15:24 bswartz I don't see why not 2020-03-23 20:15:37 +pokechu22 You should be able to load the light data from the saved map as well 2020-03-23 20:18:54 bswartz Yes, calculating light maps is expensive, so caching those maps is worth it 2020-03-23 20:20:31 x10A94 Doesn't the client hide chunks that border unloaded ones? 2020-03-23 20:21:05 x10A94 Also, has anyone ever done GPU-accelerated light calculations 2020-03-23 20:22:59 bswartz x10A94: It's not *that* expensive. Just expensive enough that it's worth avoiding repeating the calculations when nothing has changed 2020-03-23 20:26:30 x10A94 fair 2020-03-23 20:28:58 chibill I never did get the server I was working on sending chunks properly. Sort of want to write a 1.15.2 client now. 2020-03-23 20:33:30 chibill I haven’t touched MC programming in a while any suggestions on where to get started? 2020-03-23 20:33:58 bswartz chibill: http://wiki.vg 2020-03-23 20:35:52 bswartz chibill: Not much has changed since 1.13. There was a huge change between 1.12.2 and 1.13 that involved clients having to rewrite tons of code 2020-03-23 20:36:25 chibill I have watched wiki.vg a lot. Love watching it during snapshots. 2020-03-23 20:37:54 chibill I will be back working on this in an hour. Got to sit and watch my online class in 20min. 2020-03-23 21:03:07 RealRph in either case, my server project has a lot of work to do still 2020-03-23 21:03:19 RealRph currently the main inefficiency comes from pre-generating all chunk data packets before starting 2020-03-23 21:03:25 RealRph and then just sending them from a lookup table 2020-03-23 21:06:55 chibill I think I am going to go with using quarry again as a base to write my client. (Used it as a base for the server I tried to write.) 2020-03-23 21:07:09 RealRph I am writing everything from scratch using just the golang standard library 2020-03-23 21:07:14 RealRph and wiki.vg, of course :P 2020-03-23 21:08:24 chibill ah. I have tired from scratch in python. Its annoying xD 2020-03-23 21:08:45 RealRph I went with go mainly because of the relative simplicity of multithreading 2020-03-23 21:10:13 chibill Nice. MC and Multithreading doesn't always get along. 2020-03-23 21:11:52 RealRph a sufficient number of mutexes and locks fixed all isuses eventually 2020-03-23 21:15:02 bswartz I would rewrite my code in golang if I had the time 2020-03-23 21:15:29 bswartz I wrote my code in Java first and learned Golang later -- too late to rewrite it now :-( 2020-03-23 21:15:53 RealRph hey, no language is bad 2020-03-23 21:15:56 RealRph if it does the job, its good 2020-03-23 21:16:08 bswartz Uh, that's false 2020-03-23 21:16:19 RealRph Hmmm 2020-03-23 21:16:22 bswartz There are plenty of bad languages 2020-03-23 21:16:28 RealRph I mean, I always had the impression that what matters is how you use the language 2020-03-23 21:16:39 RealRph You can write fast and efficient javascript and slow and bloated assembly 2020-03-23 21:16:41 bswartz It's true that languages tend to have niches where they perform well 2020-03-23 21:17:37 bswartz But there's a tendency to use languages for purposes they were not designed for, and that's always a disaster 2020-03-23 21:24:09 RealRph What's the legal situation of the registry.json files by the way? 2020-03-23 21:24:24 RealRph Can I distribute them or do I need to include information how to get them manually 2020-03-23 21:26:23 +pokechu22 I think it's probably fine, but I'm not a lawyer. You should probably make it possible for the user to supply their own, though 2020-03-23 21:26:40 RealRph This being an open source project, I think for now I will just put info in the readme 2020-03-23 21:59:05 RealRph well anyway, I put the base of this code on github 2020-03-23 21:59:07 RealRph https://github.com/rphsoftware/scaffoldingMC 2020-03-23 22:18:17 --> _123DMWM (~123DMWM@2601:18d:580:3870:d86a:2d31:45ff:f38d) a rejoint #mcdevs 2020-03-23 22:37:53 x10A94 How should I encode OptChat in the entity metadata format? 2020-03-23 22:38:34 +pokechu22 Boolean, and then chat (which is just a string with some rules on it) if the boolean is true 2020-03-23 22:38:50 x10A94 hm, I wonder what I'm doing wrong 2020-03-23 22:40:33 x10A94 https://i.selic.re/cG7CVIl7.txt < here's a dump of the entity metadata field, can you see anything weird here? It's just skin parts and a custom name, but it seems to fail with "Unknown serializer type 97" 2020-03-23 22:42:49 x10A94 it feels like instead of length 11, it seems to grab length 3. 2020-03-23 22:46:26 x10A94 using a string of length 3 spits out some weird OOB error. 2020-03-23 22:46:45 +pokechu22 I think you might have the type and index backwards? It looks like you've got index 5 and type 2, but probably want index 2 and type 5 (type 2 is float, 4 bytes, so the next thing would be 0x6e for the index and 0x61 for the type, and 0x61 is 97) 2020-03-23 22:47:15 +pokechu22 Oh, right, I should note I converted to hex for myself. 0x6e is 110 2020-03-23 22:47:31 x10A94 OH 2020-03-23 22:47:44 x10A94 the table is worded a bit weirdly 2020-03-23 22:47:54 x10A94 I thought "see the table below" referred to the one immediately below 2020-03-23 22:47:56 x10A94 that makes sense 2020-03-23 22:49:55 x10A94 it works except it doesn't 2020-03-23 22:50:13 x10A94 is that how I properly set custom names to players? 2020-03-23 22:50:19 +pokechu22 The type should be in the table immediately below, yeah 2020-03-23 22:52:17 +pokechu22 You've got the order right for the first one (assuming you wanted to set index 16 -- for players, skin flags -- as a byte to value 127 (all parts enabled)). It's just the one after that that's backwards 2020-03-23 22:52:56 x10A94 yeah, I got the client to eat it, but it doesn't seem to show the player with a custom name 2020-03-23 22:53:56 x10A94 even once I set the custom name visible flag 2020-03-23 22:54:22 +pokechu22 I think players are a special case, since they already have a name visible... 2020-03-23 22:54:43 +pokechu22 I think you use https://wiki.vg/Protocol#Player_Info for that? 2020-03-23 22:54:57 x10A94 only works in the tab menu 2020-03-23 22:55:17 x10A94 I could _spawn_ it with a custom name, but I'm sure that can screw some things up. 2020-03-23 22:56:00 +pokechu22 I'm pretty sure there is a way to do it, but I'm not sure what it is, then 2020-03-23 23:00:14 x10A94 https://i.selic.re/O1lcnV0u.png < ah, damn it. 2020-03-23 23:00:21 x10A94 I would have really wanted newlines to work. 2020-03-23 23:01:15 +pokechu22 I think you can get a second line with scoreboards, actually... but I'm not sure what part of them does it 2020-03-23 23:01:37 x10A94 yeah I tried a while back and it seemed to be very rigid, unless they changed it now 2020-03-23 23:02:06 x10A94 ergh, there's also a 16 char length limit on usernames so that's not gonna work 2020-03-23 23:02:27 x10A94 Oh wait scoreboards can do prefixes 2020-03-23 23:02:33 x10A94 I sure hope that's easy to set up! 2020-03-23 23:09:27 x10A94 Varints are the same as bytes for the first 128 values, right 2020-03-23 23:10:24 +pokechu22 Yes, for 0 through 127 2020-03-23 23:10:30 x10A94 the minecraft protocol _almost_ maps to rust's data model except for a few bruh moments like arrays that are randomly prefixed by shorts instead of varints 2020-03-23 23:23:37 MiniDigger RealRph, fyi, I asked Helen (java community manager for java servers) if it's ok to distribute the data generator files and she said she thinks it's ok 2020-03-23 23:24:06 MiniDigger https://irc.minidigger.me/uploads/e3186e16b68e3c51/Screenshot_20200323-232353.png 2020-03-23 23:24:49 MiniDigger That obviously not legal binding, but she generally knows her stuff 2020-03-23 23:36:39 RealRph I mean in case it's not fine, hopefully they will warn me before taking action like DMCAing a github repo, right? 2020-03-24 00:07:43 chibill They should I would think. 2020-03-24 00:14:37 <-- Defolos (~Defolos@fedora/defolos) a quitté (Remote host closed the connection) 2020-03-24 00:18:14 --> Defolos (~Defolos@fedora/defolos) a rejoint #mcdevs 2020-03-24 00:26:51 <-- Dadido3_ (~quassel@p200300D9DF23B800C900C0E461E3EF7B.dip0.t-ipconnect.de) a quitté (Read error: Connection reset by peer) 2020-03-24 00:27:35 <-- bildramer (~bildramer@p200300CF371C8D007F67408D92F33914.dip0.t-ipconnect.de) a quitté (Remote host closed the connection) 2020-03-24 00:28:51 --> Dadido3 (~quassel@p200300D9DF23B800C900C0E461E3EF7B.dip0.t-ipconnect.de) a rejoint #mcdevs 2020-03-24 00:30:08 --> bildramer (~bildramer@p200300CF371C8D007F67408D92F33914.dip0.t-ipconnect.de) a rejoint #mcdevs 2020-03-24 00:31:30 RealRph So, does anyone have an idea what the formula is for negative region files? I want to get a chunk relative to the start of the region file but adapting the formula from wiki.vg does not produce good results (chunks are in wrong order) 2020-03-24 00:32:57 --> AndrewPH (~Butts@72.9.147.61) a rejoint #mcdevs 2020-03-24 00:32:57 -- Mode #mcdevs [+v AndrewPH] par ChanServ 2020-03-24 00:34:25 <-- Defolos (~Defolos@fedora/defolos) a quitté (Ping timeout: 264 seconds) 2020-03-24 00:36:23 x10A94 RealRph: use euclidian division. You can also try using `x >> 5` if your language doesn't mess that one up too 2020-03-24 00:36:44 +pokechu22 https://dinnerbone.com/minecraft/tools/coordinates/ is a tool that should be useful to check what should happen 2020-03-24 00:37:11 RealRph I think I got it 2020-03-24 00:53:13 RealRph I noticed some odd behaviour 2020-03-24 00:53:15 RealRph in the client 2020-03-24 00:53:27 RealRph It doesn't happen when I put a 100ms delay between sending each chunk 2020-03-24 00:53:39 RealRph but when I just blast it with chunks, it sometimes throws this error in console: io.netty.handler.codec.DecoderException: LongArray with size 9130 is bigger than allowed 1291 2020-03-24 00:53:44 RealRph it doesn't seem to actually impact reading chunk data 2020-03-24 00:53:47 RealRph it's just weird 2020-03-24 01:36:27 --> NickG365_ (~NickG365@2607:5300:60:6e29:472:6425:3733:0) a rejoint #mcdevs 2020-03-24 01:37:45 <-- NickG365 (~NickG365@2607:5300:60:6e29:472:6425:3733:0) a quitté (Ping timeout: 240 seconds) 2020-03-24 01:37:46 -- NickG365_ est maintenant connu sous le nom NickG365 2020-03-24 01:37:55 bswartz RealRph: You need to log exactly what you're sending, before and after compression, and decode your own packets 2020-03-24 01:38:05 bswartz I suspect you have some kind of compression or framing problems 2020-03-24 01:38:32 RealRph probably framing problems 2020-03-24 01:39:18 RealRph and the issue only happens sometimes not always 2020-03-24 01:39:32 RealRph probably an extreme edge case 2020-03-24 01:39:34 bswartz Buffer your packets and only send whole packets 2020-03-24 01:39:49 RealRph that's what I do 2020-03-24 01:40:09 RealRph I compress and encrypt the entire packet before writing it to the socket 2020-03-24 01:40:31 RealRph and during that time I also lock the session so no other thread can do the same (thus ruining the encryption state) 2020-03-24 01:44:00 bswartz RealRph: Are you properly flushing your compressor? 2020-03-24 01:44:27 RealRph I re-initialise it every packet 2020-03-24 01:44:34 RealRph Its highly inefficient but does the job for now 2020-03-24 01:44:59 bswartz I mean are you draining all the compressed data out at the end? 2020-03-24 01:45:11 bswartz Compressors always buffer data 2020-03-24 01:50:56 RealRph I have disabled compression and the issue still appears when I send too many chunks 2020-03-24 01:51:24 RealRph it seems the game just does something weird when you send chunks too fast/chunks out of render distance 2020-03-24 01:52:53 RealRph could be issues with framing 2020-03-24 01:53:31 RealRph I should look at wireshark to debug this further 2020-03-24 01:53:32 bswartz Wait are you sending light updates between each chunk data? 2020-03-24 01:53:36 RealRph I am not 2020-03-24 01:53:44 bswartz I think that's what notchian server does 2020-03-24 01:53:56 RealRph when I do it slowly, it works 2020-03-24 01:54:05 RealRph When I do it too fast, the game starts to break 2020-03-24 01:54:05 bswartz Can't explain that 2020-03-24 01:54:29 RealRph I pre-generate the chunk data packets so I guess the game was never designed to receive data this soon 2020-03-24 01:54:33 bswartz Maybe you have buffering problems somewhere where buffers get overwritten 2020-03-24 01:54:38 RealRph because the server has some delays 2020-03-24 01:54:38 RealRph or taht 2020-03-24 01:54:56 RealRph However, sending a packet locks the whole thread until its done sending 2020-03-24 01:55:43 bswartz Yeah but if sending packets quickly causes problems, that smells like a queueing or buffering problem. Are you using nonblocking I/O? 2020-03-24 01:55:59 RealRph nope 2020-03-24 01:56:08 RealRph in go, writing to a TCP connection hangs the whole thread until the writing is done. 2020-03-24 01:56:11 bswartz Ring buffer in software? 2020-03-24 01:56:41 RealRph I will look at this in wireshark 2020-03-24 01:56:42 bswartz Actually it blocks just the goroutine 2020-03-24 01:56:57 RealRph well yeah, but I have it so there is 1 goroutine per connection 2020-03-24 01:56:59 bswartz The thread underneath the gorouting will go find other work to do if I/O would block 2020-03-24 01:57:11 RealRph so the goroutine gets locked 2020-03-24 01:57:12 bswartz s/gorouting/goroutine/ 2020-03-24 01:57:20 RealRph and no work regarding that connection gets done 2020-03-24 02:01:34 RealRph ok I got closer to the issue 2020-03-24 02:05:25 RealRph I will investigate more tomorrow, could either be something that's my fault or a potential bug report 2020-03-24 02:08:33 <-- RealRph (~rph@139.28.40.44) a quitté (Quit: Leaving) 2020-03-24 03:26:33 x10A94 I've sent an 8x8 set of chunks in a single write before so it's unlikely to be the game's issue 2020-03-24 03:30:23 bswartz x10A94: He left the channel but I agree 2020-03-24 03:30:50 bswartz It has to be an issue in his code, not the client 2020-03-24 03:30:51 x10A94 which is why I didn't ping him, I just wanted to share my experience with others here 2020-03-24 03:31:12 bswartz x10A94: Do you know if light update packets are essential for the client to display the chunks? 2020-03-24 03:31:24 x10A94 No, I've never sent them 2020-03-24 03:31:40 x10A94 the client will have occasional light issues, but it will display everything properly 2020-03-24 03:31:53 x10A94 I will always use night vision so it's not an issue for me 2020-03-24 03:32:15 bswartz Light Update didn't become a separate packet until 1.15.0 2020-03-24 03:32:23 bswartz Do you test with 1.15.0+ ? 2020-03-24 03:34:19 x10A94 yes, I use 1.15.2 only 2020-03-24 03:34:28 bswartz Interesting 2020-03-24 03:34:29 x10A94 Also, it used to be in 1.14 2020-03-24 03:34:55 x10A94 Speaking of light: does the client recalculate skylight in the end dimension? I want to place blocks efficiently. 2020-03-24 03:35:47 bswartz There is no skylight in the end or the nether. Just the regular world 2020-03-24 03:35:53 x10A94 okay, nice 2020-03-24 03:36:20 x10A94 Mostly this is for animating large structures 2020-03-24 03:36:47 x10A94 Sending whole chunks would be a bit too much when you're broadcasting to 4k players 2020-03-24 03:37:02 bswartz You can send chunk sections 2020-03-24 03:37:13 bswartz Just 16x16x16 blocks at a time 2020-03-24 03:37:56 x10A94 that's still a bit too rich. 2020-03-24 03:38:06 x10A94 even with compression 2020-03-24 03:38:16 bswartz The palette could make each block just a few bits 2020-03-24 03:38:37 bswartz Maybe 2K bytes with a 4 bit palette -- before compression 2020-03-24 03:38:38 x10A94 yeah but it bottoms out at 4 bits 2020-03-24 03:39:11 bswartz Cheaper than a huge number of block updates 2020-03-24 03:39:35 x10A94 Are Multi Block Updates not efficient? 2020-03-24 03:40:21 x10A94 side note: can you emulate piston movement without the actual piston block 2020-03-24 03:41:08 x10A94 being able to move blocks without the use of entities would be neat 2020-03-24 03:42:27 bswartz For a multi block update you have to send the x/y/z coords of each block you want to update 2020-03-24 03:42:56 bswartz All those x/y/z coords quickly dominate the amount of data you send 2020-03-24 03:43:19 x10A94 that is a good point 2020-03-24 03:43:24 bswartz Also you can't palettize block updates 2020-03-24 03:43:26 x10A94 I'll run some tests 2020-03-24 03:43:57 x10A94 I'm less concerned about bandwidth and more concerned about client perf 2020-03-24 03:44:09 bswartz If all the blocks you want to update fall into a 16x16x16 block or a small number of those, it's likely faster to send chunk data 2020-03-24 03:44:43 bswartz Client perf scales though -- 4k clients have 4k as much compute power as 1 client 2020-03-24 03:44:51 bswartz Your network bandwidth does not scale 2020-03-24 03:45:37 x10A94 Yes, but I can scale down my animation. 2020-03-24 03:46:16 x10A94 And/or switch to a more network-efficient method only when necessary, at the expense of client lag. 2020-03-24 03:47:28 x10A94 For example, my player updates use a broadcast channel. If some client falls behind, they won't receive all of the missed changes, only the last few ones. 2020-03-24 03:48:09 x10A94 (granted, you'll need to be very far behind for the packet buffer to be that full, but it was basically free to implement) 2020-03-24 03:48:33 timmyRS We're still taking about Minecraft which uses TCP, so no one will ever fall behind? 2020-03-24 03:48:51 x10A94 timmyRS: talking about network lag 2020-03-24 03:49:15 timmyRS Are you implementing TCP yourself? 2020-03-24 03:49:54 x10A94 No, but I can tell when the client is lagging sufficiently badly to stop sending even more data to it. Whether that helps or not, I'm not sure; I'd have to do more tests on a flimsy connection. 2020-03-24 04:07:25 <-- mgrech (~mgrech@194.166.99.28) a quitté (Ping timeout: 264 seconds) 2020-03-24 05:05:12 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Ping timeout: 256 seconds) 2020-03-24 06:19:06 <-- ddevault (znc@sourcehut/staff/ddevault) a quitté (Quit: Why do I even put this quit message in if I never quit) 2020-03-24 06:22:16 --> ddevault (znc@sourcehut/staff/ddevault) a rejoint #mcdevs 2020-03-24 06:22:16 -- Mode #mcdevs [+v ddevault] par ChanServ 2020-03-24 06:41:46 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2020-03-24 06:44:12 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 250 seconds) 2020-03-24 06:44:12 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2020-03-24 07:28:47 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 07:50:38 <-- kev009 (~kev009@ip72-222-200-117.ph.ph.cox.net) a quitté (Ping timeout: 246 seconds) 2020-03-24 07:51:11 <-- Meeeh (~Meeeh@206.ip-51-68-140.eu) a quitté (Quit: ZNC - https://znc.in) 2020-03-24 08:04:20 --> Defolos (~Defolos@fedora/defolos) a rejoint #mcdevs 2020-03-24 08:21:36 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 08:23:35 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 08:32:54 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 08:34:05 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 08:42:19 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 08:43:36 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 08:55:41 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 08:57:37 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 08:59:46 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 09:06:26 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 09:09:58 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 09:12:07 <-- SpaceManiac (~SpaceMani@2601:200:4400:103::1054) a quitté (Ping timeout: 246 seconds) 2020-03-24 09:12:39 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 09:17:11 --> SpaceManiac (~SpaceMani@c-73-116-110-236.hsd1.ca.comcast.net) a rejoint #mcdevs 2020-03-24 09:17:12 -- Mode #mcdevs [+v SpaceManiac] par ChanServ 2020-03-24 09:22:01 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 09:23:40 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 11:07:24 --> Me4502 (~quassel@unaffiliated/me4502) a rejoint #mcdevs 2020-03-24 11:08:31 <-- Me4502 (~quassel@unaffiliated/me4502) a quitté (Client Quit) 2020-03-24 12:54:24 <-- balrog (~balrog@unaffiliated/balrog) a quitté (Ping timeout: 256 seconds) 2020-03-24 12:56:37 --> balrog (~balrog@unaffiliated/balrog) a rejoint #mcdevs 2020-03-24 13:44:01 --> mgrech (~mgrech@194-166-99-28.adsl.highway.telekom.at) a rejoint #mcdevs 2020-03-24 15:15:59 --> RealRph (~rph@139.28.40.44) a rejoint #mcdevs 2020-03-24 15:20:02 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 256 seconds) 2020-03-24 15:27:16 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-24 15:56:39 bswartz RealRph: While you were gone we agreed there is no way the client cares how fast you send it chunks. Any timing issues exist on your server side 2020-03-24 15:57:10 RealRph okay, I will look at the network traffic in wireshark to see what happens 2020-03-24 15:57:16 RealRph it seems to happen when my server sends a keepalive 2020-03-24 17:53:24 <-- RealRph (~rph@139.28.40.44) a quitté (Remote host closed the connection) 2020-03-24 18:45:01 <-- gabizou (~gabizou@69.147.207.130) a quitté (*.net *.split) 2020-03-24 18:45:01 <-- niceplace (~nplace@86.106.136.94) a quitté (*.net *.split) 2020-03-24 18:45:30 --> niceplace (~nplace@86.106.136.94) a rejoint #mcdevs 2020-03-24 18:47:23 --> gabizou (~gabizou@69.147.207.130) a rejoint #mcdevs 2020-03-24 19:06:54 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 240 seconds) 2020-03-24 19:09:11 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-24 20:06:31 <-- Pyker (~pyker@hexagon.pyker.net) a quitté (Remote host closed the connection) 2020-03-24 20:06:56 --> Pyker (~pyker@hexagon.pyker.net) a rejoint #mcdevs 2020-03-24 20:26:14 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 20:28:19 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 20:41:54 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 240 seconds) 2020-03-24 20:44:04 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-24 21:43:14 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 240 seconds) 2020-03-24 21:44:21 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-24 21:47:29 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 21:49:58 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 22:13:21 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 22:15:30 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 22:47:44 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 22:49:32 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 22:53:06 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 22:55:34 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 23:09:55 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 23:12:06 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 23:21:30 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 23:22:06 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 23:27:13 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Ping timeout: 264 seconds) 2020-03-24 23:28:58 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 23:37:18 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 23:40:40 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 23:49:18 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 23:50:40 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-24 23:54:34 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-24 23:57:14 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-25 00:24:32 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Ping timeout: 256 seconds) 2020-03-25 00:27:33 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-25 00:37:36 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-25 00:38:23 <-- Defolos (~Defolos@fedora/defolos) a quitté (Ping timeout: 250 seconds) 2020-03-25 00:39:45 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-25 02:22:25 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 264 seconds) 2020-03-25 02:33:58 --> redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2020-03-25 03:16:14 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Ping timeout: 256 seconds) 2020-03-25 03:27:14 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-25 03:32:57 <-- Dadido3 (~quassel@p200300D9DF23B800C900C0E461E3EF7B.dip0.t-ipconnect.de) a quitté (Ping timeout: 260 seconds) 2020-03-25 03:34:38 --> Dadido3 (~quassel@p200300D9DF0E57002CB6EAE4BE670D26.dip0.t-ipconnect.de) a rejoint #mcdevs 2020-03-25 03:36:59 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-25 03:39:31 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-25 03:44:52 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-25 03:46:03 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-25 05:37:17 <-- MisterVector (Vector@cpe-172-90-152-76.socal.res.rr.com) a quitté (Read error: Connection reset by peer) 2020-03-25 05:38:37 --> MisterVector (Vector@cpe-172-90-152-76.socal.res.rr.com) a rejoint #mcdevs 2020-03-25 06:04:05 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2020-03-25 06:06:49 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 264 seconds) 2020-03-25 06:06:49 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2020-03-25 06:22:01 <-- ashka (~postmaste@pdpc/supporter/active/ashka) a quitté (Ping timeout: 268 seconds) 2020-03-25 06:29:00 --> kev009 (~kev009@ip72-222-200-117.ph.ph.cox.net) a rejoint #mcdevs 2020-03-25 06:29:00 -- Mode #mcdevs [+v kev009] par ChanServ 2020-03-25 07:45:14 <-- kev009 (~kev009@ip72-222-200-117.ph.ph.cox.net) a quitté (Ping timeout: 240 seconds) 2020-03-25 07:47:42 --> ashka (~postmaste@baptiste-huve.fr) a rejoint #mcdevs 2020-03-25 07:47:42 <-- ashka (~postmaste@baptiste-huve.fr) a quitté (Changing host) 2020-03-25 07:47:42 --> ashka (~postmaste@pdpc/supporter/active/ashka) a rejoint #mcdevs 2020-03-25 07:49:27 --> Defolos (~Defolos@fedora/defolos) a rejoint #mcdevs 2020-03-25 08:18:49 -- md_5- est maintenant connu sous le nom md_5 2020-03-25 12:43:26 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-25 12:45:58 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-25 15:54:56 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 246 seconds) 2020-03-25 15:57:12 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-25 17:46:58 <-- wvffle1 (wvfflematr@gateway/shell/matrix.org/x-zctikejvddnujdjc) a quitté (Ping timeout: 256 seconds) 2020-03-25 17:51:05 --> wvffle1 (wvfflematr@gateway/shell/matrix.org/x-spqmwptnbddtsfio) a rejoint #mcdevs 2020-03-25 18:40:20 Not-8b5f [minecraft-data] automatic-beyond-belief pushed 1 commit to master [+0/-0/±1] https://git.io/JvSKX 2020-03-25 18:40:22 Not-8b5f [minecraft-data] automatic-beyond-belief 6fb8804 - Add 20w13a to common/protocolVersions.json 2020-03-25 18:46:58 Not-8b5f [Burger] New data now avaliable for 20w13a: 2020-03-25 18:47:00 Not-8b5f [Burger] Diff from 20w12a: https://pokechu22.github.io/Burger/diff_20w12a_20w13a.html (https://pokechu22.github.io/Burger/diff_20w12a_20w13a.json) 2020-03-25 18:47:01 Not-8b5f [Burger] Full data: https://pokechu22.github.io/Burger/20w13a.html (https://pokechu22.github.io/Burger/20w13a.json) 2020-03-25 18:50:38 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 246 seconds) 2020-03-25 19:26:40 --> redrield (~kaitlyn@hnmron6104w-lp140-01-65-95-197-0.dsl.bell.ca) a rejoint #mcdevs 2020-03-25 19:43:01 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-25 19:57:24 KennyTV shouldn't this be animal with burger? https://i.imgur.com/85R4ith.png 2020-03-25 20:02:57 +pokechu22 It should be, but animal is an abstract class, and thus it doesn't have anything to name it with. Note the abstract parent giving it a boolean; that's ageable I think. 2020-03-25 20:03:22 KennyTV yeah, alright 2020-03-25 20:03:40 +pokechu22 I could identify animal by it being, say, the parent of sheep, but it'd be a little hacky. I'll see how that goes, though, because the current behavior is pretty confusing 2020-03-25 20:22:20 redrield Where are speed/slowness status effects actually processed & have their effects applied to the movement of the entity? 2020-03-25 20:23:20 +pokechu22 It's handled by the attributes system (see Entity Properties packet, though I think for potion effects it happens clientside). Not sure exactly where it happens from that though. 2020-03-25 20:31:25 redrield So for applying movement status effects, at the start entity properties is sent specifying the new base movement speed given the potion, entity effect is sent which adds the display to the HUD, and resent periodically to sync timers, then at the end packets are sent to remove the display and reset the properties? 2020-03-25 20:32:59 +pokechu22 I'm not sure. I don't know if you need to use Entity Properties to do it or if it happens automatically with Entity Effect 2020-03-25 20:33:18 redrield it certainly doesn't from what I can tell, so im assuming Entity Properties is necessary 2020-03-25 20:33:21 redrield I'll play around with it, the 2020-03-25 20:33:23 redrield then* 2020-03-25 20:36:40 <-- SpaceManiac (~SpaceMani@c-73-116-110-236.hsd1.ca.comcast.net) a quitté (Quit: ZNC - http://znc.in) 2020-03-25 20:44:15 --> SpaceManiac (~SpaceMani@c-73-116-110-236.hsd1.ca.comcast.net) a rejoint #mcdevs 2020-03-25 20:44:16 -- Mode #mcdevs [+v SpaceManiac] par ChanServ 2020-03-25 21:26:32 +pokechu22 Implemented: https://github.com/mcdevs/Burger/compare/77f268a...ab86f3e - I'll regenerate past versions now (major releases, and all the 1.16 snapshots) 2020-03-25 21:50:20 --> Kodoque (~Kodoque@2a01cb000f0e570044f9e17d440229fa.ipv6.abo.wanadoo.fr) a rejoint #mcdevs 2020-03-25 21:54:39 KennyTV sweet, thanks 2020-03-25 21:57:49 <-- caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a quitté (Ping timeout: 264 seconds) 2020-03-25 21:59:42 --> caelunsh1 (~caelum@75-169-54-15.slkc.qwest.net) a rejoint #mcdevs 2020-03-25 22:13:12 <-- redrield (~kaitlyn@hnmron6104w-lp140-01-65-95-197-0.dsl.bell.ca) a quitté (Quit: WeeChat 2.7.1) 2020-03-25 22:13:40 +pokechu22 OK, they should be updated now 2020-03-25 22:23:41 <-- Kodoque (~Kodoque@2a01cb000f0e570044f9e17d440229fa.ipv6.abo.wanadoo.fr) a quitté (Quit: Leaving) 2020-03-25 22:54:31 --> christolis (~Thunderbi@adsl-115.176.58.128.tellas.gr) a rejoint #mcdevs 2020-03-25 23:30:13 <-- christolis (~Thunderbi@adsl-115.176.58.128.tellas.gr) a quitté (Ping timeout: 264 seconds) 2020-03-25 23:53:48 --> christolis (~Thunderbi@adsl-115.176.58.128.tellas.gr) a rejoint #mcdevs 2020-03-26 00:10:03 <-- christolis (~Thunderbi@adsl-115.176.58.128.tellas.gr) a quitté (Quit: christolis) 2020-03-26 00:10:25 --> christolis (~Thunderbi@adsl-115.176.58.128.tellas.gr) a rejoint #mcdevs 2020-03-26 00:27:42 <-- _123DMWM (~123DMWM@2601:18d:580:3870:d86a:2d31:45ff:f38d) a quitté (Ping timeout: 260 seconds) 2020-03-26 00:30:00 --> _123DMWM (~123DMWM@c-73-60-129-142.hsd1.ma.comcast.net) a rejoint #mcdevs 2020-03-26 00:54:54 <-- Defolos (~Defolos@fedora/defolos) a quitté (Ping timeout: 240 seconds) 2020-03-26 01:51:13 <-- _123DMWM (~123DMWM@c-73-60-129-142.hsd1.ma.comcast.net) a quitté (Ping timeout: 264 seconds) 2020-03-26 01:51:23 --> _123DMWM (~123DMWM@2601:18d:580:3870:3469:d454:6965:8253) a rejoint #mcdevs 2020-03-26 01:52:30 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2020-03-26 01:53:24 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 256 seconds) 2020-03-26 01:53:25 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2020-03-26 01:56:54 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Ping timeout: 240 seconds) 2020-03-26 03:20:37 <-- MisterVector (Vector@cpe-172-90-152-76.socal.res.rr.com) a quitté 2020-03-26 04:20:00 x10A94 What's "combat event" used for? 2020-03-26 04:28:43 --> Dadido3_ (~quassel@p54826FC2.dip0.t-ipconnect.de) a rejoint #mcdevs 2020-03-26 04:28:46 <-- Dadido3 (~quassel@p200300D9DF0E57002CB6EAE4BE670D26.dip0.t-ipconnect.de) a quitté (Ping timeout: 246 seconds) 2020-03-26 04:43:54 +pokechu22 I think death messages (including the message on the game over screen), and maybe more general combat state tracking that goes into death messages (e.g. "hit the ground too hard while fighting playername"), but I'm not sure 2020-03-26 04:49:30 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-26 04:50:00 +pokechu22 Looks like the client *only* uses it for the game over screen, but it's sent for other things in the combat state tracker 2020-03-26 04:53:38 x10A94 oh, interesting, so if I send this packet it'll show the death screen? 2020-03-26 04:54:35 +pokechu22 Yeah. 2020-03-26 04:54:41 x10A94 oh neat 2020-03-26 04:56:11 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Ping timeout: 250 seconds) 2020-03-26 05:01:26 +pokechu22 Looks like it was added some time in 1.8 (14w04a), and they did some stuff in multiple cases in that snapshot, but I guess since then it became less used? This is the first time I've ever looked into it 2020-03-26 05:02:54 x10A94 hmm 2020-03-26 05:03:07 x10A94 doesn't seem to do anything 2020-03-26 05:03:15 x10A94 do I have to kill the player with something else? 2020-03-26 05:04:19 +pokechu22 At least in 1.15, you need to have the player ID set to the client player, and the event set to entity died 2020-03-26 05:05:09 x10A94 they're both 0 (the ID of the player), but it doesn't seem to do much 2020-03-26 05:05:24 timmyRS I think you still need to update the health to 0 so the respawn screen shows, and the combat event is just so you see a message like "tried to swim in lava while fleeing from Herobrine." 2020-03-26 05:05:39 x10A94 oh wait, killing the player is literally setting health to 0? 2020-03-26 05:05:51 x10A94 and I'm here trying to search for the packet to do so. 2020-03-26 05:06:20 +pokechu22 I think so, but the code also seems to display a game over screen on this packet... the game over screen is kinda weird 2020-03-26 05:06:31 x10A94 well, the code is broken then lol 2020-03-26 05:06:37 x10A94 because it doesn't do much 2020-03-26 05:06:55 timmyRS Maybe the code at that point is just to update the text on the game over screen? 2020-03-26 05:07:12 x10A94 what's the order of packets? 2020-03-26 05:07:52 timmyRS Intuitively, I'd say the health gets updated first, but I don't know for a fact. 2020-03-26 05:08:18 x10A94 https://i.selic.re/4c3MENip.png < UH 2020-03-26 05:08:24 x10A94 it didn't show the game over screen 2020-03-26 05:08:28 x10A94 but it played the animation 2020-03-26 05:09:22 timmyRS Is "Enable respawn screen" true in your join game packet? 2020-03-26 05:09:30 x10A94 good question 2020-03-26 05:10:14 x10A94 Oh yeah, huh. Wonder why I set that. Still, that was quite eerie. 2020-03-26 05:10:27 x10A94 The screen just zooms in and rotates slowly and you can't move. 2020-03-26 05:10:28 +pokechu22 ... oh. I see what this was added for; it was added in 1.8 to do twitch stream metadata stuff 2020-03-26 05:10:33 x10A94 w 2020-03-26 05:10:51 x10A94 what would it even be used for 2020-03-26 05:11:35 x10A94 https://i.selic.re/txSH7doD.png < hey look it works 2020-03-26 05:11:40 x10A94 looks like the order doesn't matter 2020-03-26 05:12:32 +pokechu22 I've got no idea; I guess it could go into twitch chat? The whole twitch streaming functoinality is defunct now. 2020-03-26 05:13:20 x10A94 well, in either case, it works and that's all that matter 2020-03-26 05:13:22 x10A94 s 2020-03-26 05:14:06 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-26 05:15:49 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-26 05:17:08 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-26 05:17:26 x10A94 https://i.selic.re/cu0FkrjB.png < doom mode (setting a player's health back to full after they died) 2020-03-26 05:17:45 +pokechu22 Looks like the packet was later retrofitted to display the respawn screen in 1.9, which removed the twitch broadcasting functionality. Huh. 2020-03-26 05:18:33 x10A94 Is there any way to get rid of the respawn screen without resending chunks? 2020-03-26 05:18:42 +pokechu22 Hmmm, wait, is *that* what triggers the arm not rotating around you and everything? I've been wondering about that for some time 2020-03-26 05:19:14 x10A94 In this case, yes. 2020-03-26 05:20:32 +pokechu22 I don't think there is any way; the respawn packet unloads chunks and you need to resend them, and I think that's the only way to clear the death screen. You can vote for https://bugs.mojang.com/browse/MC-4890 though 2020-03-26 05:20:39 x10A94 ergh 2020-03-26 05:21:41 --> wvffle_ (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-26 05:21:49 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Ping timeout: 264 seconds) 2020-03-26 05:25:49 x10A94 hah I can open an inventory but it instantly closes clientside 2020-03-26 05:27:15 +pokechu22 Looks like I was looking at 1.14.2 instead of 1.15.2; the packet doesn't display the death screen if the the show death screen setting is false (instead, it immediately sends the client status packet that's used when the respawn button is clicked) 2020-03-26 05:28:01 +pokechu22 Did you set the player's health above 0? It looks like the client closes GUIs if its health is below 0, but you might be able to avoid that if it's raised after the fact 2020-03-26 05:28:20 x10A94 I set it to 20, yes 2020-03-26 05:28:43 x10A94 in the inventory, you are still dead 2020-03-26 05:28:43 <-- wvffle_ (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Ping timeout: 260 seconds) 2020-03-26 05:29:00 x10A94 I think this is one of those weird edge case things, like spectators without noclip 2020-03-26 05:29:57 timmyRS You need to also update the player list item for them to have noclip 2020-03-26 05:30:36 x10A94 yeah, it's just weird that the behaviour is governed by several separate things 2020-03-26 05:31:19 x10A94 I think it is super great that noclip is separate because sometimes you _want_ spectator mode without noclip, but it should be a player ability really 2020-03-26 05:31:26 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-26 05:31:34 x10A94 because then you can use noclip on creative players 2020-03-26 05:31:48 x10A94 and I mean you can right now, but it is rather broken 2020-03-26 05:32:07 +pokechu22 ... huh. For some reason, the combat event packet is set up so that netty errors with it are skipped for death ones. That's odd... I didn't even know that was a thing 2020-03-26 05:32:38 x10A94 Well, not json parsing errors 2020-03-26 05:33:28 <-- wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a quitté (Read error: Connection reset by peer) 2020-03-26 05:35:13 +pokechu22 Oh, actually, that might make sense. The chat and nbt query response packets also do that; if one of those are sent, it's ignored instead of causing a disconnect I think. Looks like that was added circa 1.13? 2020-03-26 05:35:56 x10A94 Under which circumstances can that happen? 2020-03-26 05:36:10 x10A94 It's weird that it's only tolerable to these errors. 2020-03-26 05:36:41 +pokechu22 It happens on the server side, not the client side, actually 2020-03-26 05:37:11 --> wvffle (~wvffle@host-46-175-47-49.wtvk.pl) a rejoint #mcdevs 2020-03-26 05:37:15 x10A94 oh, interesting 2020-03-26 05:37:37 timmyRS My god, creative with noclip is actually kind of cool. Only middle-clicking blocks doesn't work, which I guess is because my server is ignoring some packet? 2020-03-26 05:38:04 x10A94 Does it still show darkness when you're inside the block? 2020-03-26 05:38:13 timmyRS Oh, you also can't switch between slots :/ 2020-03-26 05:38:27 timmyRS Yeah, it's darkness inside of blocks 2020-03-26 05:38:46 timmyRS but, that's as expected, right? 2020-03-26 05:38:51 x10A94 yeah I really hope they address this because it's so inconvenient to switch between creative and spectator 2020-03-26 05:38:57 x10A94 I wanna just use noclip in creative 2020-03-26 05:40:00 +pokechu22 F3+N? That's pretty convenient 2020-03-26 05:40:45 timmyRS I think this is already pretty cool, if the server maybe handled block placements while you're inside of a block in a different way, this would be very usable. Stop being greedy :P 2020-03-26 05:40:45 x10A94 it spams everyone and will not let you fill 1x1x1 holes 2020-03-26 05:41:21 x10A94 I mean yeah exactly, I don't want much more lol 2020-03-26 05:41:44 x10A94 it's already mostly implemented anyway 2020-03-26 05:42:17 timmyRS Also, how does F3+N decide that I have no permissions? 2020-03-26 05:42:30 x10A94 op level 2020-03-26 05:42:33 x10A94 which is clientside 2020-03-26 05:42:36 +pokechu22 Op permission level... I think either entity metadata, or some more cursed entity status based thing? 2020-03-26 05:43:01 x10A94 who knows at this point 2020-03-26 05:43:02 +pokechu22 Ah, yes, this: https://wiki.vg/Entity_statuses#Player 2020-03-26 05:44:52 x10A94 so wait 2020-03-26 05:45:03 --> MisterVector (Vector@cpe-172-90-152-76.socal.res.rr.com) a rejoint #mcdevs 2020-03-26 05:45:06 x10A94 do I use an entity status or entity metadata if I wanna kill a shown player 2020-03-26 05:46:48 x10A94 Or is it a matter of just what packet is smaller and they do the same thing? 2020-03-26 05:47:22 x10A94 https://i.selic.re/hXGpDGFY.png < what? why? why is this serverside? why does the client care? 2020-03-26 05:48:00 timmyRS Someone at mojang didn't want the squid to get dizzy 2020-03-26 05:48:37 x10A94 it's like.. I'm sure there's a good reason for this but I would have absolutely zero idea what it is 2020-03-26 05:49:01 +pokechu22 It's probably some stupid thing that somehow contributed to resolving flying squids... maybe. At least I haven't seen any flying squids lately :D 2020-03-26 05:49:20 x10A94 flying squids were the best part of this game hands down 2020-03-26 05:49:27 +pokechu22 Aye 2020-03-26 05:49:53 +pokechu22 Anyways, looks like the skipping sending of erroneous chat packets instead of kicking was https://bugs.mojang.com/browse/MC-129814 -- at least, 1.13-pre6 matches my findings 2020-03-26 05:50:10 x10A94 I have an idea that this was the same thing as the flying boat glitch, where the relative move packet would desync over time 2020-03-26 05:50:14 timmyRS Oh my god, Entity statues are still IDs that just counted up over the versions... Thank you, benevolent Mojang Gods! 2020-03-26 05:50:28 x10A94 wait why is that good 2020-03-26 05:50:29 +pokechu22 Oh no, they're better than that :D 2020-03-26 05:50:52 +pokechu22 They're IDs that pretend to be unique per entity, but actually aren't; I think they're just making up those IDs as they go along :D 2020-03-26 05:50:59 timmyRS Well, all other IDs all get shifted over the different versions... 2020-03-26 05:51:39 +pokechu22 The ones that get shifted over at least are in registries so they can be found via data generators now 2020-03-26 05:51:50 timmyRS I still haven't got a solid solution for keeping track of the entity metadata indexes 2020-03-26 05:52:19 x10A94 I wish packets had a registry too so I could just autogenerate my implementation 2020-03-26 05:52:38 x10A94 well they do via minecraft-data but that's by the community, not mojang 2020-03-26 05:52:51 x10A94 and I don't agree with some of the names in there 2020-03-26 05:58:00 timmyRS The protocol.json in minecraft-data is quite impressive, but none of the fields in packets have names, only types, so you can't really do much more than "the second boolean in join game" 2020-03-26 06:04:29 --> redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs 2020-03-26 06:05:57 <-- redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 250 seconds) 2020-03-26 06:05:57 -- redstonehelper_ est maintenant connu sous le nom redstonehelper 2020-03-26 06:08:41 x10A94 timmyRS: iirc, though, it has some weird conditional structs instead of tagged enums 2020-03-26 06:12:53 +pokechu22 ... oh, that's interesting. 1.13-pre6 added the failsafe for chat messages (and, if it fails to send the message, you get a different warning message, see https://pokechu22.github.io/Burger/diff_1.13-pre5_1.13-pre6.html#language for it), but the death version happened later 2020-03-26 06:17:02 +pokechu22 Specifically, 18w31a, and you get a unique "killed by even more magic" message: https://pokechu22.github.io/Burger/diff_18w30b_18w31a.html#language 2020-03-26 06:17:47 x10A94 oh wow 2020-03-26 06:17:51 x10A94 that's very obscure 2020-03-26 06:18:18 x10A94 What's the exact scenario? A mob name that's ~= 32767 chars? 2020-03-26 06:19:07 +pokechu22 A mob that's named that, or getting killed by a player with a weapon whose description goes above that, or something like that 2020-03-26 06:19:13 x10A94 i c