2018-04-17 00:48:13	yyvwPpI7BO_	const tempBuffer = Buffer.alloc(8);
2018-04-17 00:48:18	yyvwPpI7BO_	tempBuffer.writeDoubleBE(undefined, 0);
2018-04-17 00:48:24	yyvwPpI7BO_	set the buffer to
2018-04-17 00:48:30	yyvwPpI7BO_	<Buffer 7f f8 00 00 00 00 00 00>
2018-04-17 00:48:52	bueddl	Nan = Undefined
2018-04-17 00:49:10	yyvwPpI7BO_	no
2018-04-17 00:49:17	yyvwPpI7BO_	NaN != undefined
2018-04-17 00:49:19	pokechu22	NaN != NaN
2018-04-17 00:49:25	pokechu22	NaN !== NaN
2018-04-17 00:49:25	bueddl	exactly
2018-04-17 00:49:47	yyvwPpI7BO_	But node converts undefined to NaN and that to 7f f8 00 00 00 00 00 00 for some reason
2018-04-17 00:49:52	yyvwPpI7BO_	This is so dumb
2018-04-17 00:49:56	pokechu22	I don't fully know JS's coercion rules (just that they're kinda horrible) but I'd have thought undefined would go to 0, yeah
2018-04-17 00:50:29	yyvwPpI7BO_	This has nothing to do with JS coercion as NaN != undefined
2018-04-17 00:50:32	Hafydd	I think that "undefined" is represented by some JS engines as one of the possible invalid float values.
2018-04-17 00:50:41	bueddl	but that is the  IEEE774  encoding for NaN
2018-04-17 00:51:08	yyvwPpI7BO_	I still think that that should throw an error
2018-04-17 00:51:29	pokechu22	There's a lot of things in JS that probably should throw an error :/
2018-04-17 00:51:31	yyvwPpI7BO_	undefined is not a value you can express in a floating point number
2018-04-17 00:51:50	pokechu22	Looks like `Number(undefined)` gives NaN
2018-04-17 00:51:52	yyvwPpI7BO_	So why does Node just happily write NaN instead
2018-04-17 00:51:59	bueddl	since I did not start working to port my "server" to 1.13 pre-release - I am struggling with the description of the global palette for the pre-release. does this mean that I would have to encode 8 for a grass block with snowy=false?
2018-04-17 00:52:05	pokechu22	though `Number(null)` gives 0 .-.
2018-04-17 00:52:38	yyvwPpI7BO_	There are a lot of these dumb conversion rules
2018-04-17 00:53:00	yyvwPpI7BO_	I think you just have to learn to avoid using stuff like that as a JS dev
2018-04-17 00:53:10	pokechu22	Yeah, looks like grass is currently 8 for snowy=false
2018-04-17 00:53:29	bueddl	ok, and is it sill 13 bits for bits per block?
2018-04-17 00:53:31	pokechu22	There's a data export thingy on the server now, that probably should be mentioned on the article since I think it's a bit nicer than what burger gives
2018-04-17 00:54:29	yyvwPpI7BO_	Oh well then, I'm going to sleep now
2018-04-17 00:54:40	pokechu22	Max ID for structure block is 8411 so 14 bits per block now
2018-04-17 00:54:45	bueddl	gn8 yyvwPpI7BO_ 
2018-04-17 00:54:47	yyvwPpI7BO_	Enjoying my 4 and a half hours of sleep 
2018-04-17 00:54:51	yyvwPpI7BO_	bye everyone
2018-04-17 00:54:56	yyvwPpI7BO_	thanks for the help today
2018-04-17 00:54:57	pokechu22	Night
2018-04-17 00:55:35	bueddl	thanks pokechu22. is it always as easy as this? as long as my "bits per block" field is sufficient to encode all numbers I can take it?
2018-04-17 00:56:30	pokechu22	A little bit more complicated because of some weird stuff the client does -- but the bits per block value the client uses is the one that's large enough to encode all the numbers, yeah
2018-04-17 00:57:07	bueddl	awesome, thanks
2018-04-17 00:57:54	pokechu22	It was 13 until a couple of weeks ago -- I guess some of the newer blocks from the aquatic content pushed it over
2018-04-17 00:59:13	bueddl	is the assumption correct, that due to the linear assignment if a block gets added another attribute the whole list (after that particular block) will change? so major incompatibilities between versions?
2018-04-17 00:59:40	<--	yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a quitté (Ping timeout: 264 seconds)
2018-04-17 00:59:49	pokechu22	Yep, things shift a fair but unfortunately :/
2018-04-17 01:00:28	bueddl	well that is a drawback, but it is better than a fixed encoding with no way for inline extensions (like more attributes) I think
2018-04-17 01:05:05	bueddl	btw, I noticed that the payload of the ping packet changed from a timestamp to numbers such as 01d7000000000000. is there any meaning associated with it? just curious
2018-04-17 01:05:22	pokechu22	Not 100% sure
2018-04-17 01:06:48	bueddl	it's not continuously increasing with runtime, so it is also nothing that is relative to client startup (what I thought of at first)
2018-04-17 01:07:26	pokechu22	Just checked how to get the data -- if you run `java -cp minecraft_server.18w15a.jar net.minecraft.data.Main --reports` then it'll give you a nice report file with all of the different block states (among other things)
2018-04-17 01:07:34	bueddl	well wait
2018-04-17 01:07:34	bueddl	it is
2018-04-17 01:07:37	bueddl	isn't it?
2018-04-17 01:07:44	bueddl	I must have overlooked this before
2018-04-17 01:08:02	pokechu22	The value should be increasing, I'd think...
2018-04-17 01:08:03	bueddl	yes, seems continiously increasing ... 
2018-04-17 01:08:12	bueddl	I was just dumb before
2018-04-17 01:08:49	pokechu22	Ping packet, or keep-alive?
2018-04-17 01:08:57	bueddl	ping
2018-04-17 01:10:25	pokechu22	Yeah, looks like it should just be a system time, odd
2018-04-17 01:10:58	bueddl	ok :D thanks for looking that up
2018-04-17 01:11:23	bueddl	I was just curious why that changed. I didn't come up with a good reasons yet
2018-04-17 01:12:42	pokechu22	Might have changed because it's a system time determined by LWJGL (not Java's currentTimeMillis) and that might have changed from LWJGL2 to LWJGL3
2018-04-17 01:13:22	bueddl	that would make sense, yes. might be it
2018-04-17 01:19:29	bueddl	well, I am heading off now for today. thanks again for your help :)
2018-04-17 01:20:10	pokechu22	Cya
2018-04-17 01:20:22	<--	bueddl (~bueddl@ip-84-118-89-34.unity-media.net) a quitté (Quit: Leaving)
2018-04-17 01:25:38	-->	protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs
2018-04-17 01:37:30	<--	justJanne (~justJanne@lithium.kuschku.de) a quitté (Remote host closed the connection)
2018-04-17 01:37:44	-->	justJanne (~justJanne@lithium.kuschku.de) a rejoint #mcdevs
2018-04-17 01:37:44	<--	justJanne (~justJanne@lithium.kuschku.de) a quitté (Client Quit)
2018-04-17 01:38:01	-->	justJanne (~justJanne@lithium.kuschku.de) a rejoint #mcdevs
2018-04-17 02:00:05	<--	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 240 seconds)
2018-04-17 02:00:53	-->	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs
2018-04-17 02:09:58	-->	itsme__ (~textual@x590efe59.dyn.telefonica.de) a rejoint #mcdevs
2018-04-17 02:10:00	<--	yangm97 (yangm97mat@gateway/shell/matrix.org/x-dpeushkxhaiqkbpl) a quitté (Ping timeout: 240 seconds)
2018-04-17 02:10:13	<--	Moep[m] (moepmatrix@gateway/shell/matrix.org/x-hmwozxsdsimgnazn) a quitté (Ping timeout: 256 seconds)
2018-04-17 02:11:33	<--	itsme__ (~textual@x590efe59.dyn.telefonica.de) a quitté (Client Quit)
2018-04-17 02:11:41	<--	itsme (~textual@x590efe59.dyn.telefonica.de) a quitté (Ping timeout: 264 seconds)
2018-04-17 03:07:50	<--	protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2)
2018-04-17 03:14:27	<--	Akaibu (uid118096@gateway/web/irccloud.com/x-cukufcovugggurmp) a quitté (Quit: Connection closed for inactivity)
2018-04-17 03:24:42	<--	McLive (~McLive@2a05:bec0:20:1::9) a quitté (Ping timeout: 256 seconds)
2018-04-17 03:27:39	-->	McLive (~McLive@2a05:bec0:20:1::9) a rejoint #mcdevs
2018-04-17 05:03:27	-->	protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs
2018-04-17 05:09:17	<--	millerti (~millerti@cpe-66-24-91-119.stny.res.rr.com) a quitté (Ping timeout: 264 seconds)
2018-04-17 06:04:16	<--	XorBoole (~XorBoole@45.55.68.177) a quitté (Ping timeout: 256 seconds)
2018-04-17 06:04:16	<--	electronicboy (~electroni@atlas.valaria.pw) a quitté (Remote host closed the connection)
2018-04-17 06:05:29	-->	electronicboy (~electroni@atlas.valaria.pw) a rejoint #mcdevs
2018-04-17 06:06:15	-->	XorBoole (~XorBoole@45.55.68.177) a rejoint #mcdevs
2018-04-17 06:16:54	-->	someone_stole_my (~mrkirby15@mrkirby153.com) a rejoint #mcdevs
2018-04-17 06:17:59	<--	mrkirby153 (~mrkirby15@mrkirby153.com) a quitté (Ping timeout: 266 seconds)
2018-04-17 06:43:05	-->	kashike_ (kashike@unaffiliated/kashike) a rejoint #mcdevs
2018-04-17 06:45:33	<--	kashike (kashike@unaffiliated/kashike) a quitté (Ping timeout: 256 seconds)
2018-04-17 06:50:12	<--	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 240 seconds)
2018-04-17 06:51:25	pokechu22	OK, got around to checking entity statuses -- and interestingly, none seem to have been added so far, though I did discover a few that were added back in 1.12 that weren't on the wiki (and that the witch one didn't get moved when the article was separated)
2018-04-17 06:51:36	-->	redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs
2018-04-17 06:53:00	pokechu22	I'll do entity metadata later.
2018-04-17 06:53:23	--	redstonehelper_ est maintenant connu sous le nom redstonehelper
2018-04-17 07:33:55	-->	Moep[m] (moepmatrix@gateway/shell/matrix.org/x-mwwzatjtfragtitb) a rejoint #mcdevs
2018-04-17 07:35:41	-->	yangm97 (yangm97mat@gateway/shell/matrix.org/x-uaedtghtjobsihaj) a rejoint #mcdevs
2018-04-17 09:23:14	kashike_	pokechu22: good; that stuff is so dumb
2018-04-17 11:09:13	<--	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 256 seconds)
2018-04-17 11:16:51	-->	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs
2018-04-17 11:27:35	<--	kev009 (~kev009@ip72-222-200-59.ph.ph.cox.net) a quitté (Ping timeout: 240 seconds)
2018-04-17 11:41:17	-->	bueddl (~bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-17 13:00:27	-->	bueddl_ (~bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-17 13:00:44	<--	bueddl_ (~bueddl@ip-84-118-89-34.unity-media.net) a quitté (Client Quit)
2018-04-17 13:01:10	<--	bueddl (~bueddl@ip-84-118-89-34.unity-media.net) a quitté (Quit: Leaving)
2018-04-17 13:01:19	-->	Bueddl (~bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-17 13:07:31	-->	C4K3_ (~C4K3@0127801301.0.fullrate.ninja) a rejoint #mcdevs
2018-04-17 13:11:25	<--	C4K3 (~C4K3@0127801301.0.fullrate.ninja) a quitté (Ping timeout: 276 seconds)
2018-04-17 13:12:28	<--	Bueddl (~bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 240 seconds)
2018-04-17 13:51:39	-->	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a rejoint #mcdevs
2018-04-17 14:20:40	<--	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a quitté (Read error: Connection reset by peer)
2018-04-17 14:26:28	-->	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a rejoint #mcdevs
2018-04-17 14:44:14	<--	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a quitté (Read error: Connection reset by peer)
2018-04-17 15:27:14	-->	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a rejoint #mcdevs
2018-04-17 15:31:01	<--	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a quitté (Read error: Connection reset by peer)
2018-04-17 15:51:44	-->	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a rejoint #mcdevs
2018-04-17 16:00:10	<--	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a quitté (Read error: Connection reset by peer)
2018-04-17 16:12:46	<--	hansihe (sid106603@gateway/web/irccloud.com/x-vfdibignikromcmn) a quitté (Ping timeout: 276 seconds)
2018-04-17 16:13:50	-->	hansihe (sid106603@gateway/web/irccloud.com/x-ksyiobfhlzpdwxkk) a rejoint #mcdevs
2018-04-17 16:25:36	-->	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a rejoint #mcdevs
2018-04-17 16:30:31	<--	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a quitté (Read error: Connection reset by peer)
2018-04-17 16:56:59	-->	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a rejoint #mcdevs
2018-04-17 16:58:22	-->	OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a rejoint #mcdevs
2018-04-17 17:03:52	<--	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a quitté (Read error: Connection reset by peer)
2018-04-17 17:23:22	-->	yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a rejoint #mcdevs
2018-04-17 17:55:36	-->	Tachyon_ (~Tachyon_@95.76.184.120) a rejoint #mcdevs
2018-04-17 17:55:56	Tachyon_	is there a uptodate library for manipulating game files ?
2018-04-17 17:57:27	pokechu22	NBTExplorer (and I think thus substrate.dll which is C#) has been updated to support the long array tag (which existed before, but is now used in 1.13), but I don't think it's been updated for any of the other higher-level changes
2018-04-17 17:59:23	yyvwPpI7BO_	Yea NBTExplorer worked great when I wrote a map viewer from 1.13
2018-04-17 17:59:41	Tachyon_	I was thinking more about reading entities from regions
2018-04-17 18:00:47	pokechu22	NBTExplorer/substrate can parse region files I think, but it won't do anything more than give you the NBT for each chunk.  That should be enough to read entities though
2018-04-17 18:01:40	yyvwPpI7BO_	Or you can just parse the data yourself, chunk data is really easy to extract
2018-04-17 18:02:17	Tachyon_	nbt for each chunk is acceptable
2018-04-17 18:02:42	Tachyon_	I can do it myself, but I though letțs see if it's has been already done in a manner I can use
2018-04-17 18:03:27	yyvwPpI7BO_	Of course, you don't need to reinvent the wheel
2018-04-17 18:03:34	yyvwPpI7BO_	I just did it for fun
2018-04-17 18:03:50	Tachyon_	I actually already did it, but that's another story
2018-04-17 18:04:05	yyvwPpI7BO_	Oh okay
2018-04-17 18:05:21	Tachyon_	thank you for help
2018-04-17 18:06:50	yyvwPpI7BO_	Oh well I'm new to all of this
2018-04-17 18:07:01	yyvwPpI7BO_	I'm trying to learn as well
2018-04-17 19:55:17	-->	NathanWolf (~nathan@216-235-101-HCC-80.hcc.net) a rejoint #mcdevs
2018-04-17 20:00:33	NathanWolf	Looking at the pre-release protocol wiki for particles, are there any plans to change entity_effect and ambient_entity_effect to use data similar to dust? 
2018-04-17 20:00:43	NathanWolf	I notice they are still colorable, but via the old offset x,y,z method. 
2018-04-17 20:00:58	NathanWolf	For that matter, any plans on allowing colorable note or firework_spark particles? Thanks for your time!
2018-04-17 20:01:21	yyvwPpI7BO_	That would be really useful
2018-04-17 20:03:03	pokechu22	Is `minecraft:splash` also the same way?
2018-04-17 20:04:00	pokechu22	That definitely sounds like something would be good; I'd also think that means that it'd have a proper parser for use in /particle
2018-04-17 20:07:12	yyvwPpI7BO_	I'm just sitting here, reading through the chunk format and asking myself if it's even worth for now to implement chunk palettes
2018-04-17 20:07:53	yyvwPpI7BO_	Is there a reason why Bits Per Blocks can't be smaller than 4?
2018-04-17 20:12:57	pokechu22	I think it's because resizing is a bit expensive so if it resized a bunch when it was less than 4 that'd be unnecessary
2018-04-17 20:13:28	yyvwPpI7BO_	Okay
2018-04-17 20:13:31	NathanWolf	pokechu, yeah it took me a while to figure out how to even spawn colored dust with the command :)
2018-04-17 20:14:08	NathanWolf	The parser is there and works, but it is a little odd how different it is for some types. A json data block would be really intuitive, if I'm asking for the world, but I guess that'd have backwards-compat issues
2018-04-17 20:14:43	pokechu22	Well, it does indicate what you're supposed to do with it sort of (though I think in the first snapshot it didn't)
2018-04-17 20:14:46	NathanWolf	Mostly I would just love the ability to tint any of the particles, or at least the ones that are colored in-game (not sure about splash?)
2018-04-17 20:15:06	NathanWolf	mm... definite "sort of" for the colors, like I don't think it had tooltips for the 4 parameters that go after "dust"
2018-04-17 20:15:50	NathanWolf	and it's weird (to me, anyway) that they get put right in between the particle type and the other parameters
2018-04-17 20:15:56	NathanWolf	but shrug, I'm not too fussed about the command
2018-04-17 20:16:33	NathanWolf	Just seems like at least the entity_effect particles should've followed suit, it felt odd that they still use the old sort-of-hacky method
2018-04-17 20:16:37	pokechu22	Hm, I thought it did specify what they were... oh, wait, I'm thinking of `/give item{params}`, /particle does `/particle dust bla bla blah` right?  Though actually I'd think it would give you context above, not 100% sure
2018-04-17 20:16:47	pokechu22	Right, to me it feels like entity_effect not being adjusted is a bug
2018-04-17 20:16:56	pokechu22	or could be treated like one :D
2018-04-17 20:17:07	pokechu22	`splash` is for splash potions, right?  Not 100% sure
2018-04-17 20:17:10	NathanWolf	I only ask because I'm crazy excited about this. I mean being able to spawn colored particles with count + xyz offset (and a new scale parameter, to boot) is a complete game-changer for my custom effects.
2018-04-17 20:17:17	NathanWolf	oh no I think splash is water splashing :)
2018-04-17 20:17:23	NathanWolf	splash potions use entity_effect
2018-04-17 20:19:24	pokechu22	Don't they have a different "x" like particle?
2018-04-17 20:19:45	NathanWolf	uh do they? Honestly I don't use splash potions much
2018-04-17 20:20:15	NathanWolf	huh, so they do. Is that new?
2018-04-17 20:21:03	NathanWolf	the particle formerly known as "splash" was just water splashing, I'm like 90% sure
2018-04-17 20:21:23	NathanWolf	this one looks kind of like a colored crit or... something new?
2018-04-17 20:22:36	pokechu22	Yeah, colored crit is probably the splash potion effect.  It's been like that for a while I think
2018-04-17 20:22:48	pokechu22	(I want to say since potions were introduced, but I'm not 100% sure)
2018-04-17 20:23:36	NathanWolf	huh, well.. that's news to me! And yes I'd love a colorable version of that one too then :D
2018-04-17 20:23:56	NathanWolf	These sorts of things are just amazing for personalization and customizing (particularly magic spell fx...)
2018-04-17 20:26:31	pokechu22	Ah, yeah, and it does look like the parameters for particles in /particle don't have names :/
2018-04-17 20:45:26	-->	Bueddl (~bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-17 20:46:35	<--	Bueddl (~bueddl@ip-84-118-89-34.unity-media.net) a quitté (Client Quit)
2018-04-17 22:49:18	<--	protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2)
2018-04-17 22:55:34	<--	Tachyon_ (~Tachyon_@95.76.184.120) a quitté (Quit: Leaving)
2018-04-17 23:35:17	-->	bueddl (~bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-18 00:02:32	-->	protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs
2018-04-18 00:21:15	yyvwPpI7BO_	Can somebody tell me how block data works in chunk sections in 1.13?
2018-04-18 00:27:01	pokechu22	Sorta the same way it already does, just a different global palette.  Check the section on the global palette on the pre page
2018-04-18 00:29:15	yyvwPpI7BO_	Is the global palette https://pokechu22.github.io/Burger/18w15a.json[0].blocks.ordered_blocks?
2018-04-18 00:29:33	yyvwPpI7BO_	And how many bits does each block use?
2018-04-18 00:29:55	pokechu22	No, that's... something else.  Hard to explain exactly.  I'd recommand using vanilla's data generator and looking at that
2018-04-18 00:30:05	pokechu22	Right now 14
2018-04-18 00:30:58	yyvwPpI7BO_	Is just using as many bits as are needed to address the entire palette?
2018-04-18 00:31:02	yyvwPpI7BO_	Or why is it 14 exactly?
2018-04-18 00:32:47	pokechu22	The highest entry in the global palette is currently 8411 (structure_block[mode=data]) -- in binary 10000011011011 which is 14 bits
2018-04-18 00:35:43	yyvwPpI7BO_	Okay, so just Math.ceil(Math.log2(globalPaletteLength))
2018-04-18 00:36:28	pokechu22	Yeah
2018-04-18 00:46:05	yyvwPpI7BO_	I'm trying to send some chunk data to the client with a stone block at 0/0/0 but somehow managed to place a noteblock at 3/0/0
2018-04-18 00:46:10	yyvwPpI7BO_	This is going to be fun
2018-04-18 00:46:40	bueddl	you have to take the state ids not the block ids from the website
2018-04-18 00:46:58	bueddl	at least I did that wrong. so maybe that is your error too
2018-04-18 00:47:27	yyvwPpI7BO_	I think I just did something wrong with the bit I flipped
2018-04-18 00:47:34	bueddl	not the numeric id I meant
2018-04-18 00:48:08	yyvwPpI7BO_	The noteblock that was placed has the id 256 according to the exported blocks.json from the vanilla server
2018-04-18 00:48:08	bueddl	well then just wait until they need 16 bit. it will be a lot easier then (just joking :D)
2018-04-18 00:48:28	yyvwPpI7BO_	For sure it will be
2018-04-18 00:49:00	yyvwPpI7BO_	But seeing as 256 is a multiple of 2 I think I set the wrong bit to one
2018-04-18 00:49:08	yyvwPpI7BO_	I'll try around a bit
2018-04-18 00:49:37	pokechu22	Yeah, sorry, frankly the burger link is a bit misleading since it doesn't actually include all state IDs
2018-04-18 00:49:41	pokechu22	just a range of them
2018-04-18 00:51:31	yyvwPpI7BO_	Oh no I know exactly what went wrong
2018-04-18 00:51:39	yyvwPpI7BO_	I used the wrong endianess
2018-04-18 00:51:53	yyvwPpI7BO_	This is going to be a nightmare
2018-04-18 00:52:01	bueddl	:'D
2018-04-18 00:52:02	yyvwPpI7BO_	JavaScript doesn't have longs
2018-04-18 00:52:19	timmyRS	Seems like an issue with your language choice ;)
2018-04-18 00:52:41	bueddl	haha, correct. :D
2018-04-18 00:53:08	bueddl	there are libraries for js that support 64-bit ints. but a library for a simple int. uff...
2018-04-18 00:53:21	yyvwPpI7BO_	dont worry there's a stage 3 proposal for big ints
2018-04-18 00:53:33	yyvwPpI7BO_	I'll just wait 2 or 3 years and continue working then
2018-04-18 00:53:42	bueddl	:D
2018-04-18 00:54:26	bueddl	my life in a nutshell - I am a c++ dev btw. we always wait for the next language release :D
2018-04-18 00:55:35	<--	bueddl (~bueddl@ip-84-118-89-34.unity-media.net) a quitté (Remote host closed the connection)
2018-04-18 01:01:13	pokechu22	Well, a library for a larger integer is more sane than a library for checking if a number is even, and a separate library for it it's odd, and separate libraries for like 16 different colors
2018-04-18 01:01:44	yyvwPpI7BO_	This is bad
2018-04-18 01:02:06	yyvwPpI7BO_	I wanted to write the server without using any external libraries
2018-04-18 01:03:12	kashike_	not a very good idea - libraries are very helpful :p
2018-04-18 01:03:32	yyvwPpI7BO_	Just as an extra challenge
2018-04-18 01:03:36	pokechu22	Hm, let's see how mineflayer does it
2018-04-18 01:05:17	pokechu22	It's looking like an array with 2 ints...
2018-04-18 01:06:49	yyvwPpI7BO_	I think I'll just use a node buffer and swap every 8 bytes with Buffer.swap64()
2018-04-18 01:07:26	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-18 01:10:11	yyvwPpI7BO_	It looks like not a lot of packets use longs anyways
2018-04-18 01:13:59	kashike_	vanilla: 10 usages of readLong, 11 usages of writeLong
2018-04-18 01:15:49	yyvwPpI7BO_	Yeah but there are some uses like keep alive packets where it's not actually important that it's a long integer
2018-04-18 01:16:21	yyvwPpI7BO_	Where I can just 8 byte large Buffers instead
2018-04-18 01:41:07	--	kashike_ est maintenant connu sous le nom kashike
2018-04-18 01:59:47	<--	yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a quitté (Ping timeout: 246 seconds)
2018-04-18 03:04:01	-->	Ya_ALLAH_Ya_Muhm (~Ya_ALLAH_@37.237.65.227) a rejoint #mcdevs
2018-04-18 03:04:02	<--	Ya_ALLAH_Ya_Muhm (~Ya_ALLAH_@37.237.65.227) a quitté #mcdevs
2018-04-18 04:12:28	<--	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: Connection reset by peer)
2018-04-18 04:14:22	-->	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs
2018-04-18 06:29:38	yawkat	Any clue what this is about? https://blog.avast.com/minecraft-players-exposed-to-malicious-code-in-modified-skins
2018-04-18 06:30:29	yawkat	Minecraft just does imageio right? Is the article just FUD (code is never executed) or is there a bug in the libpng it uses to load skins?
2018-04-18 06:30:36	pokechu22	Code is never executed
2018-04-18 06:31:06	yawkat	Are you certain? The article doesn't make it sound that way but it's light on details
2018-04-18 06:31:36	pokechu22	Yeah.  You can rename the file (it's named without an extension) but otherwise it's just not executed, just text at the end of a file
2018-04-18 06:31:50	yawkat	Ah okay, thanks
2018-04-18 06:34:39	pokechu22	Oh, right, the official statement, though this isn't super interesting from a dev perspective and is more about other issues with the article and derivative articles:
2018-04-18 06:34:42	pokechu22	“Mojang has addressed this issue and put additional measures in place to prevent the sharing of malicious content on our service. We encourage players to report any suspicious activity to feedback.minecraft.net”
2018-04-18 06:34:44	pokechu22	+The affected skins were not official Minecraft skins, and were generated by third parties.
2018-04-18 06:34:46	pokechu22	+The affected skins did not affect any of the Bedrock versions as these versions do not call that API
2018-04-18 06:34:48	pokechu22	+The affected skins were never available on the in-game Store in any version of Minecraft
2018-04-18 06:53:03	-->	Epsilon232 (~Epsilon23@c27-253-66-142.thoms4.vic.optusnet.com.au) a rejoint #mcdevs
2018-04-18 07:00:37	-->	redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs
2018-04-18 07:04:06	<--	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 268 seconds)
2018-04-18 07:04:06	--	redstonehelper_ est maintenant connu sous le nom redstonehelper
2018-04-18 07:11:14	Epsilon232	Hey guys, I was wondering if I could just get some info on "Chunk Data", does the "Palette Length" refer too the size of the pallet in varints, or bytes?
2018-04-18 07:11:15	Epsilon232	http://wiki.vg/Chunk_Format
2018-04-18 07:13:53	kashike	Epsilon232: it literally says right beside it
2018-04-18 07:15:43	Epsilon232	I know the Palette Length is a varint, but is it saything that "this is how many varints are in the palette array?
2018-04-18 07:24:27	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 268 seconds)
2018-04-18 07:25:18	-->	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-18 07:31:00	Bueddl	It says it right there Epsilon232: "Length of the following array. " Not "size in bytes...". It ist btw always the length/itemcount for heterogenous arrays in the whole protocol.
2018-04-18 07:33:49	Epsilon232	ok, thanks.
2018-04-18 07:42:53	<--	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 264 seconds)
2018-04-18 07:44:57	-->	Bueddl (~Bueddl@x52716250.dyn.telefonica.de) a rejoint #mcdevs
2018-04-18 07:49:05	<--	SpaceManiac (~SpaceMani@c-67-172-123-140.hsd1.ca.comcast.net) a quitté (Ping timeout: 240 seconds)
2018-04-18 07:51:34	pokechu22	That is a fair point though, I don't think it's clearly specified in data types, will do that
2018-04-18 07:51:45	-->	SpaceManiac (~SpaceMani@c-67-172-123-140.hsd1.ca.comcast.net) a rejoint #mcdevs
2018-04-18 07:51:46	--	Mode #mcdevs [+v SpaceManiac] par ChanServ
2018-04-18 07:52:37	pokechu22	Or, well, the phrasing "Number of elements in the following array" would probably be better.
2018-04-18 07:54:47	pokechu22	Ah, looks like "Length" is only used in a few other places (and all of them are byte arrays) at least on the main protocol.  Will change for chunk data...
2018-04-18 07:54:56	Epsilon232	I think it is fair enought to assume that when talking about the size of an array its refering to num of elements, but "Number of elements in the following array" would be clear.
2018-04-18 08:05:14	pokechu22	Alright, I think I've fixed most of the cases -- turns out there were a lot on the pre-release page but not elsewhere (since I've recently been working on that one I thought there were a lot more on the main articles)
2018-04-18 08:11:26	<--	Bueddl (~Bueddl@x52716250.dyn.telefonica.de) a quitté (Ping timeout: 260 seconds)
2018-04-18 08:15:43	-->	Bueddl (~Bueddl@wl-29-232.fh-friedberg.de) a rejoint #mcdevs
2018-04-18 08:17:39	<--	Bueddl (~Bueddl@wl-29-232.fh-friedberg.de) a quitté (Read error: Connection reset by peer)
2018-04-18 08:26:37	MiniDigger	pokechu22, where did you get the official statement from? 
2018-04-18 08:27:38	pokechu22	Helen (community manager) posted it in an internal mojira channel, which is where I got it.  I'm pretty sure it's also been given elsewhere but I'm not entirely sure where
2018-04-18 08:28:56	pokechu22	Not exactly the best source for citing :/
2018-04-18 08:30:44	MiniDigger	was about to say :D
2018-04-18 08:33:58	-->	electroniccat (~electroni@atlas.valaria.pw) a rejoint #mcdevs
2018-04-18 08:34:28	<--	electronicboy (~electroni@atlas.valaria.pw) a quitté (Ping timeout: 240 seconds)
2018-04-18 09:56:35	<--	SpaceManiac (~SpaceMani@c-67-172-123-140.hsd1.ca.comcast.net) a quitté (Ping timeout: 256 seconds)
2018-04-18 10:13:55	-->	Black_Hole (~BlackHole@p200300E753E57300B5E5B015E6228CBC.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-18 10:17:09	<--	Black-Hole (~BlackHole@p200300E753E57300BD8FBB01ADE2BD52.dip0.t-ipconnect.de) a quitté (Ping timeout: 245 seconds)
2018-04-18 11:02:22	-->	kev009 (~kev009@ip72-222-200-117.ph.ph.cox.net) a rejoint #mcdevs
2018-04-18 11:02:22	--	Mode #mcdevs [+v kev009] par ChanServ
2018-04-18 11:37:36	<--	kev009 (~kev009@ip72-222-200-117.ph.ph.cox.net) a quitté (Ping timeout: 256 seconds)
2018-04-18 11:43:13	-->	kev009 (~kev009@ip72-222-200-117.ph.ph.cox.net) a rejoint #mcdevs
2018-04-18 11:43:13	--	Mode #mcdevs [+v kev009] par ChanServ
2018-04-18 11:47:22	-->	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a rejoint #mcdevs
2018-04-18 11:55:41	<--	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a quitté (Remote host closed the connection)
2018-04-18 11:58:50	-->	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a rejoint #mcdevs
2018-04-18 12:33:17	<--	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a quitté (Read error: Connection reset by peer)
2018-04-18 12:35:44	-->	Bueddl (~Bueddl@wl-29-240.fh-friedberg.de) a rejoint #mcdevs
2018-04-18 12:38:05	<--	Bueddl (~Bueddl@wl-29-240.fh-friedberg.de) a quitté (Read error: Connection reset by peer)
2018-04-18 12:38:51	-->	Bueddl (~Bueddl@wl-29-232.fh-friedberg.de) a rejoint #mcdevs
2018-04-18 12:41:05	<--	Bueddl (~Bueddl@wl-29-232.fh-friedberg.de) a quitté (Read error: Connection reset by peer)
2018-04-18 13:12:22	-->	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a rejoint #mcdevs
2018-04-18 13:36:04	<--	Epsilon232 (~Epsilon23@c27-253-66-142.thoms4.vic.optusnet.com.au) a quitté (Quit: Leaving)
2018-04-18 14:01:00	<--	MrGr33n (~None@BSN-142-194-111.static.siol.net) a quitté (Read error: Connection reset by peer)
2018-04-18 16:58:01	<--	Bueddl (~bueddl@wl-29-232.fh-friedberg.de) a quitté (Read error: Connection reset by peer)
2018-04-18 16:59:48	-->	Bueddl (~Bueddl@wl-29-232.fh-friedberg.de) a rejoint #mcdevs
2018-04-18 17:02:05	<--	Bueddl (~Bueddl@wl-29-232.fh-friedberg.de) a quitté (Read error: Connection reset by peer)
2018-04-18 17:03:04	-->	Bueddl (~Bueddl@x2f7ff6f.dyn.telefonica.de) a rejoint #mcdevs
2018-04-18 17:17:08	-->	yyvwPpI7BO (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a rejoint #mcdevs
2018-04-18 17:17:25	<--	yyvwPpI7BO (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a quitté (Client Quit)
2018-04-18 17:17:56	-->	yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a rejoint #mcdevs
2018-04-18 17:25:35	<--	Yamakaja (~yamakaja@vps.pub.yamakaja.me) a quitté (Ping timeout: 240 seconds)
2018-04-18 17:34:25	<--	NathanWolf (~nathan@216-235-101-HCC-80.hcc.net) a quitté (Quit: NathanWolf)
2018-04-18 17:49:13	<--	Bueddl (~Bueddl@x2f7ff6f.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-18 18:05:09	-->	SpaceManiac (~SpaceMani@c-67-172-123-140.hsd1.ca.comcast.net) a rejoint #mcdevs
2018-04-18 18:05:10	--	Mode #mcdevs [+v SpaceManiac] par ChanServ
2018-04-18 18:07:32	-->	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-18 18:14:09	-->	Bueddl_ (~bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-18 18:15:24	<--	Bueddl_ (~bueddl@ip-84-118-89-34.unity-media.net) a quitté (Client Quit)
2018-04-18 18:32:55	<--	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 276 seconds)
2018-04-18 18:34:18	-->	NathanWolf (~nathan@168.212.239.66) a rejoint #mcdevs
2018-04-18 18:34:48	<--	NathanWolf (~nathan@168.212.239.66) a quitté (Client Quit)
2018-04-18 18:40:07	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-18 18:55:13	yyvwPpI7BO_	Oh my god I think i finally got chunks to work
2018-04-18 18:56:27	pokechu22	Nice :D
2018-04-18 18:56:36	yyvwPpI7BO_	https://cdn.discordapp.com/attachments/341336648275066880/436207148117262336/unknown.png
2018-04-18 18:57:08	yyvwPpI7BO_	It's just dummy data for now, but at least it finally looks like I want
2018-04-18 18:57:54	pokechu22	... oh, that's your resource pack, I thought that was some pretty elaborate dummy data at first
2018-04-18 18:58:16	yyvwPpI7BO_	Oh no it's just a weird resource pack
2018-04-18 18:58:23	yyvwPpI7BO_	I don't even know why I made that
2018-04-18 18:59:37	-->	Yamakaja (~yamakaja@vps.pub.yamakaja.me) a rejoint #mcdevs
2018-04-18 19:15:16	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 260 seconds)
2018-04-18 19:16:35	-->	Bueddl (~Bueddl@x2f7ff6f.dyn.telefonica.de) a rejoint #mcdevs
2018-04-18 19:44:26	<--	Bueddl (~Bueddl@x2f7ff6f.dyn.telefonica.de) a quitté (Ping timeout: 260 seconds)
2018-04-18 19:45:39	-->	Bueddl (~Bueddl@x2f7ff62.dyn.telefonica.de) a rejoint #mcdevs
2018-04-18 20:05:54	<--	Bueddl (~Bueddl@x2f7ff62.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-18 20:13:30	-->	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-18 20:33:24	-->	Tluszcz (~Tluszcz@78.31.142.126.rybnet.pl) a rejoint #mcdevs
2018-04-18 20:34:27	<--	Tluszcz (~Tluszcz@78.31.142.126.rybnet.pl) a quitté (Quit: Leaving)
2018-04-18 20:39:20	<--	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 268 seconds)
2018-04-18 20:39:50	-->	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-18 20:44:31	<--	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 260 seconds)
2018-04-18 20:48:55	-->	Bueddl (~Bueddl@x2f7ff62.dyn.telefonica.de) a rejoint #mcdevs
2018-04-18 20:51:05	<--	Bueddl (~Bueddl@x2f7ff62.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-18 21:00:27	-->	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-18 21:17:34	<--	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 268 seconds)
2018-04-18 21:19:13	-->	Bueddl (~Bueddl@x2f7ff62.dyn.telefonica.de) a rejoint #mcdevs
2018-04-18 21:34:25	pokechu22	Official and actually citable statement on the skin issue: https://minecraft.net/en-us/article/minecraft-java-edition-skins-issue-update
2018-04-18 21:36:16	yyvwPpI7BO_	I don't understand this
2018-04-18 21:36:39	yyvwPpI7BO_	So the harmful code was just written as source code in the image metadata?
2018-04-18 21:37:22	yyvwPpI7BO_	How would a normal player even be able to execute that?
2018-04-18 21:37:36	MiniDigger	not even that. you would just open the file in notepad and end stuff to the end of the file
2018-04-18 21:37:49	MiniDigger	a player could execute it by renaming the file to a bat. 
2018-04-18 21:38:18	yyvwPpI7BO_	But just adding stuff at the end would make the image invalid, wouldn't it?
2018-04-18 21:38:31	MiniDigger	nope
2018-04-18 21:38:47	MiniDigger	no idea how png works, but apparently thats valid.
2018-04-18 21:38:57	yyvwPpI7BO_	Oh wow
2018-04-18 21:39:11	yyvwPpI7BO_	I thought that would only maybe work with bmp
2018-04-18 21:39:48	yyvwPpI7BO_	But even then, the .bat wouldn't be executable because of all the image data at the start of the file
2018-04-18 21:40:10	yyvwPpI7BO_	Or am I seeing this wrong?
2018-04-18 21:40:28	pokechu22	Yeah, it wouldn't be executable
2018-04-18 21:40:40	yyvwPpI7BO_	This is completely stupid
2018-04-18 21:40:43	pokechu22	Or, well, maybe it would, batch is kinda lenient... but it still is unlikely
2018-04-18 21:40:45	pokechu22	Yeah
2018-04-18 21:40:49	<--	bildramer (~bildramer@p2E514D92.dip0.t-ipconnect.de) a quitté (Remote host closed the connection)
2018-04-18 21:41:11	pokechu22	But they've officially announced that it's stupid, so that's an improvement over speculation
2018-04-18 21:41:31	yyvwPpI7BO_	This is like complaining that word documents you download can contain batch code that you could copy paste in your console and execute
2018-04-18 21:41:36	-->	bildramer (~bildramer@p200300ED83CE14006C4FA047B528025F.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-18 21:43:27	yyvwPpI7BO_	But I'm glad to hear there is no actual exploit
2018-04-18 21:55:30	MiniDigger	it could be executable, you just get errors for the first lines but still execute your payload
2018-04-18 21:56:23	yyvwPpI7BO_	But you still need to rename your file
2018-04-18 21:56:49	yyvwPpI7BO_	And this could also apply to every single other image on the internet
2018-04-18 22:00:44	MiniDigger	imagine a youtube tutorial telling you to get free capes if you rename this random file in your skin folder and click on it
2018-04-18 22:00:55	MiniDigger	surely it can't be a virus, its included in minecraft!
2018-04-18 22:01:10	yyvwPpI7BO_	That's a good point
2018-04-18 22:01:17	yyvwPpI7BO_	Didn't think of that
2018-04-18 22:01:32	MiniDigger	social engineering is a really nice attack vector
2018-04-18 22:02:50	pokechu22	Well, such a video could just as easily tell you to run the commands yourself, or download a mod that runs said commands, or whatever
2018-04-18 22:03:00	MiniDigger	sure
2018-04-18 22:03:15	MiniDigger	but you are less suspicious if its a file that is already on your pc
2018-04-18 22:03:27	yyvwPpI7BO_	I'm just wondering if it's possible to create a skin that's a valid image and a virus at the same time
2018-04-18 22:03:32	MiniDigger	"its mojangs internal secret debug dev tool"
2018-04-18 22:04:19	yyvwPpI7BO_	And circumvent the new security measures
2018-04-18 22:05:44	pokechu22	I mean... to my understanding, the new measures are to reencode the image.  You could probably create an image that does have ASCII content in it too... but you could also create a screenshot of the commands; in both cases the user has to run it themselves
2018-04-18 22:08:12	yyvwPpI7BO_	Oh well, it even if there's still a problem and this was a problem in the first place, I doubt anyone will still do anything with this
2018-04-18 22:08:34	pokechu22	An interesting counterpoint, though: if you go onto facebook and then open your browser console, it'll print a big warning about pasting stuff into the browser console (with a link to https://www.facebook.com/selfxss)
2018-04-18 22:08:42	pokechu22	I remember it being styled before but now it's ASCII art, odd
2018-04-18 22:09:12	pokechu22	You can take measures to prevent the user doing stupid things to themselves, but it can only go so far
2018-04-18 22:10:25	yyvwPpI7BO_	The Minecraft playerbase is pretty young though, so Mojang should everything they can do to protect players
2018-04-18 22:12:18	pokechu22	On an unrelated note: what's the deal with the "Jordan Older fan club. 
2018-04-18 22:12:32	pokechu22	"?  That's what all of the spam's been lately, and it doesn't make sense to me :/
2018-04-18 22:13:16	yyvwPpI7BO_	What spam?
2018-04-18 22:13:45	pokechu22	wiki.vg unfortunately gets attacked with spam a fair bit; tktech cleans it up but sometimes it sits there for a while -- see http://wiki.vg/Special:RecentChanges
2018-04-18 22:14:46	yyvwPpI7BO_	That's pretty weird
2018-04-18 22:16:33	yyvwPpI7BO_	Searching for it on Google also gives no good results
2018-04-18 22:16:44	tktech	It's incredibly annoying to stop, and it's all humans in mumbai so challenges don't really work
2018-04-18 22:17:59	yyvwPpI7BO_	To me it looks like only user pages are changed
2018-04-18 22:18:15	tktech	Usually yes, they want it to go unnoticed.
2018-04-18 22:18:23	pokechu22	Yeah, they're not attacking main articles (except in one case when they put it onto a talk page I think?)
2018-04-18 22:18:36	yyvwPpI7BO_	That's a very interesting approach
2018-04-18 22:18:37	<--	Bueddl (~Bueddl@x2f7ff62.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-18 22:18:54	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-18 22:19:06	yyvwPpI7BO_	Why even bother with spamming the wiki if it's only on user pages that nobody sees anyways
2018-04-18 22:19:17	pokechu22	Search engines see them I think
2018-04-18 22:19:21	tktech	It's not for humans
2018-04-18 22:19:24	tktech	It's never for humans
2018-04-18 22:19:30	pokechu22	We could add https://en.wikipedia.org/wiki/Noindex -- but I'm not sure if they would stop even if it's useless
2018-04-18 22:19:38	tktech	Most wiki and site spam doesn't give a hoot about humans
2018-04-18 22:20:06	tktech	Point is to boost a site's term relevance then link to an external site
2018-04-18 22:20:41	pokechu22	Apparently wikipedia does that using https://www.mediawiki.org/wiki/Manual:$wgNamespaceRobotPolicies
2018-04-18 22:20:43	tktech	When someone searches for that term on google even if the site that was spammed (wiki.vg in this case) never shows up
2018-04-18 22:20:44	yyvwPpI7BO_	So a form of SEO
2018-04-18 22:20:58	tktech	Google knows X # of sites link to site Y with term Z
2018-04-18 22:21:03	tktech	So site Y gets a boost
2018-04-18 22:21:36	yyvwPpI7BO_	Ah okay, I see
2018-04-18 22:21:41	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Read error: Connection reset by peer)
2018-04-18 22:21:53	-->	Bueddl (~Bueddl@x2f7ff62.dyn.telefonica.de) a rejoint #mcdevs
2018-04-18 22:21:57	tktech	pokechu22, they're already always nofollow 
2018-04-18 22:21:59	yyvwPpI7BO_	Of course smaller wikis are a perfect target for that
2018-04-18 22:22:05	pokechu22	Oh, huh
2018-04-18 22:22:14	tktech	The spam has absolutely no value to them
2018-04-18 22:22:15	<--	Bueddl (~Bueddl@x2f7ff62.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-18 22:22:47	tktech	But a bot finds it, then a window pops up on a Mumbai warehouse desktop and the guy gets paid 1/2 a US penny to fill it in
2018-04-18 22:23:20	yyvwPpI7BO_	Wait but when I search for "Jordan Older fan club" https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=11&cad=rja&uact=8&ved=0ahUKEwimkdGY08TaAhVHVRQKHQh2C-wQFghUMAo&url=http%3A%2F%2Fwiki.vg%2FUser%3ADanteYabsley&usg=AOvVaw075D8BZ1-OPmvag4PLRHEi is on the first page of the results
2018-04-18 22:23:40	tktech	Yes?
2018-04-18 22:23:51	yyvwPpI7BO_	It is
2018-04-18 22:24:04	tktech	Sorry what's your point?
2018-04-18 22:24:29	yyvwPpI7BO_	But shouldn't it not be visible with your settings?
2018-04-18 22:24:35	yyvwPpI7BO_	Or have I misunderstood?
2018-04-18 22:24:40	-->	Bueddl (~Bueddl@x2f7ff62.dyn.telefonica.de) a rejoint #mcdevs
2018-04-18 22:24:54	tktech	nofollow means the links they make to their site are not followed.
2018-04-18 22:25:03	tktech	It has nothing to do with what google indexes on wiki.vg.
2018-04-18 22:25:09	pokechu22	There's also `noindex` which at least supposedly means that it won't index it either
2018-04-18 22:25:28	yyvwPpI7BO_	Oh, sorry, I thought Google just wouldn't index it at all
2018-04-18 22:25:31	tktech	Yeah that doesn't actually work in reality.
2018-04-18 22:26:41	<--	Bueddl (~Bueddl@x2f7ff62.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-18 22:27:23	yyvwPpI7BO_	I've found another wiki on the third page of google that has a very similar user page
2018-04-18 22:27:46	yyvwPpI7BO_	So it seems like they're targeting a few different sites
2018-04-18 22:28:06	tktech	> But a bot finds it, then a window pops up on a Mumbai warehouse desktop and the guy gets paid 1/2 a US penny to fill it in
2018-04-18 22:29:33	pokechu22	We could completely restrict registration (or require posting in IRC or something) but that would also harm actual users
2018-04-18 22:32:46	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-18 23:26:29	+ammar2	<yyvwPpI7BO_> But just adding stuff at the end would make the image invalid, wouldn't it?
2018-04-18 23:26:41	+ammar2	actually for most image formats, you can have junk at the end and they still stay valid
2018-04-18 23:26:44	+ammar2	jpg, jif, png etc
2018-04-18 23:27:01	+ammar2	the headers usually encode how many blocks of data to expect
2018-04-18 23:27:11	+ammar2	and most parsers just read data based on the sizes specified in the header
2018-04-18 23:27:35	yyvwPpI7BO_	That does make sense
2018-04-18 23:31:59	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 240 seconds)
2018-04-18 23:33:01	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-18 23:38:59	-->	bueddl_ (~bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-19 00:00:03	<--	EW8GU (admin@ho.by) a quitté (Ping timeout: 256 seconds)
2018-04-19 00:02:17	-->	EW8GU (admin@ho.by) a rejoint #mcdevs
2018-04-19 00:12:05	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 240 seconds)
2018-04-19 00:12:44	-->	Bueddl (~Bueddl@x2f7ff62.dyn.telefonica.de) a rejoint #mcdevs
2018-04-19 00:28:34	<--	bueddl_ (~bueddl@ip-84-118-89-34.unity-media.net) a quitté (Quit: Leaving)
2018-04-19 00:30:39	<--	Bueddl (~Bueddl@x2f7ff62.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-19 00:32:58	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-19 01:01:14	<--	protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2)
2018-04-19 02:44:04	<--	yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a quitté (Ping timeout: 264 seconds)
2018-04-19 04:08:00	-->	protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs
2018-04-19 06:59:23	<--	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: No route to host)
2018-04-19 06:59:51	-->	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs
2018-04-19 07:19:11	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 260 seconds)
2018-04-19 07:19:45	-->	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-19 07:32:33	star	Are the current minecraft textures under any license?
2018-04-19 07:32:45	star	Or they under the same license you buy the game with??
2018-04-19 07:32:56	star	glad my keyboard decided to include that double question mark
2018-04-19 07:35:19	Andrio	They would be copyrighted.
2018-04-19 07:36:26	<--	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 265 seconds)
2018-04-19 07:38:35	-->	Bueddl (~Bueddl@x52716335.dyn.telefonica.de) a rejoint #mcdevs
2018-04-19 07:43:01	<--	Bueddl (~Bueddl@x52716335.dyn.telefonica.de) a quitté (Ping timeout: 256 seconds)
2018-04-19 07:43:06	star	just wanted to make sure
2018-04-19 07:43:58	-->	Bueddl (~Bueddl@x2f7fc9f.dyn.telefonica.de) a rejoint #mcdevs
2018-04-19 07:51:31	<--	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: No route to host)
2018-04-19 07:52:45	-->	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs
2018-04-19 08:01:22	<--	Bueddl (~Bueddl@x2f7fc9f.dyn.telefonica.de) a quitté (Ping timeout: 268 seconds)
2018-04-19 08:05:19	-->	Bueddl (~Bueddl@wl-29-232.fh-friedberg.de) a rejoint #mcdevs
2018-04-19 08:07:32	<--	Bueddl (~Bueddl@wl-29-232.fh-friedberg.de) a quitté (Read error: Connection reset by peer)
2018-04-19 09:57:22	<--	_123DMWM (~123DMWM@me.123dmwm.tk) a quitté (Ping timeout: 255 seconds)
2018-04-19 09:57:32	-->	yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a rejoint #mcdevs
2018-04-19 10:00:21	-->	_123DMWM (~123DMWM@me.123dmwm.tk) a rejoint #mcdevs
2018-04-19 10:18:17	<--	yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a quitté (Ping timeout: 256 seconds)
2018-04-19 10:50:14	<--	NickG365 (~NickG365@cortex.starlabs.theflash.rocks) a quitté (Ping timeout: 260 seconds)
2018-04-19 10:53:33	-->	NickG365 (~NickG365@cortex.starlabs.theflash.rocks) a rejoint #mcdevs
2018-04-19 11:36:26	-->	Bueddl (~Bueddl@x2f7ffb9.dyn.telefonica.de) a rejoint #mcdevs
2018-04-19 12:01:10	<--	Bueddl (~Bueddl@x2f7ffb9.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-19 12:01:23	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-19 12:06:11	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 260 seconds)
2018-04-19 12:09:42	-->	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-19 12:11:56	<--	EW8GU (admin@ho.by) a quitté (Ping timeout: 265 seconds)
2018-04-19 12:26:05	<--	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 264 seconds)
2018-04-19 12:28:14	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-19 12:42:47	-->	begin_end (admin@ho.by) a rejoint #mcdevs
2018-04-19 13:57:17	<--	OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a quitté (Ping timeout: 264 seconds)
2018-04-19 13:58:33	<--	KnownUnown (KnownUnown@die.in.firrre.com) a quitté (Remote host closed the connection)
2018-04-19 14:04:22	-->	KnownUnown (KnownUnown@die.in.firrre.com) a rejoint #mcdevs
2018-04-19 14:17:44	-->	bueddl_ (~bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-19 14:49:09	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 248 seconds)
2018-04-19 14:49:48	-->	Bueddl (~Bueddl@x52716255.dyn.telefonica.de) a rejoint #mcdevs
2018-04-19 15:08:53	<--	Bueddl (~Bueddl@x52716255.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-19 15:12:19	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-19 15:43:29	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 264 seconds)
2018-04-19 15:51:13	-->	Bueddl (~Bueddl@x527162e3.dyn.telefonica.de) a rejoint #mcdevs
2018-04-19 16:21:16	-->	lunanoko (~lunanoko@a80-101-239-73.adsl.xs4all.nl) a rejoint #mcdevs
2018-04-19 16:43:51	<--	Bueddl (~Bueddl@x527162e3.dyn.telefonica.de) a quitté (Ping timeout: 260 seconds)
2018-04-19 16:44:39	-->	Bueddl (~Bueddl@x527162e3.dyn.telefonica.de) a rejoint #mcdevs
2018-04-19 16:53:41	<--	Bueddl (~Bueddl@x527162e3.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-19 16:54:05	-->	Bueddl (~Bueddl@x52716294.dyn.telefonica.de) a rejoint #mcdevs
2018-04-19 17:00:53	<--	Bueddl (~Bueddl@x52716294.dyn.telefonica.de) a quitté (Ping timeout: 264 seconds)
2018-04-19 17:01:04	-->	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-19 17:24:21	<--	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 248 seconds)
2018-04-19 17:27:06	-->	Bueddl (~Bueddl@x52716a42.dyn.telefonica.de) a rejoint #mcdevs
2018-04-19 17:29:18	PolarizedIons	Just as a heads up, https://minecraft.net/article/minecraft-snapshot-18w16a was released, Botched is borked and didn't announce 
2018-04-19 17:35:35	<--	Bueddl (~Bueddl@x52716a42.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-19 17:40:10	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-19 18:13:29	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 263 seconds)
2018-04-19 18:15:20	-->	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-19 18:22:29	pokechu22	This is slightly incorrect, but
2018-04-19 18:24:12	Not-10ef	[Burger] New data now avaliable for 18w16a:
2018-04-19 18:24:13	Not-10ef	[Burger] Diff from 18w15a: http://pokechu22.github.io/Burger/diff_18w15a_18w16a.html (http://pokechu22.github.io/Burger/diff_18w15a_18w16a.json)
2018-04-19 18:24:15	Not-10ef	[Burger] Full data: http://pokechu22.github.io/Burger/18w16a.html (http://pokechu22.github.io/Burger/18w16a.json)
2018-04-19 18:24:23	pokechu22	(biomes have changed, they now use a translation string for their name; also some other changes to them may have broken other parts of my code so I don't think the other biome data is right)
2018-04-19 18:34:46	-->	yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a rejoint #mcdevs
2018-04-19 18:58:50	<--	lunanoko (~lunanoko@a80-101-239-73.adsl.xs4all.nl) a quitté (Read error: No route to host)
2018-04-19 18:59:08	yyvwPpI7BO_	I have a problem with chunk loading and unloading, can anyone help me?
2018-04-19 19:00:03	yyvwPpI7BO_	Right now I'm trying to send only the surrounding few chunks to the player and I've worked out the logic and I'm pretty sure the chunks are being sent
2018-04-19 19:01:20	yyvwPpI7BO_	But for some reason some chunks I unload still get rendered on the client side even though they are unloaded and all blocks aren't solid anymore
2018-04-19 19:01:54	-->	lunanoko (~lunanoko@a80-101-239-73.adsl.xs4all.nl) a rejoint #mcdevs
2018-04-19 19:02:22	yyvwPpI7BO_	And the exact opposite also sometimes happens where the block collision is loaded fine after I send a chunk but nothing gets rendered except the outline when looking at blocks
2018-04-19 19:03:01	<--	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 248 seconds)
2018-04-19 19:03:08	yyvwPpI7BO_	And both of those things only happen sometimes, other times loading/unloading works just fine
2018-04-19 19:05:47	-->	Bueddl (~Bueddl@x52716aa3.dyn.telefonica.de) a rejoint #mcdevs
2018-04-19 19:13:33	pokechu22	This is weird.  And you're not the only custom server that's run into that, I remember others also having issues with chunks they sent not rendering...
2018-04-19 19:14:01	yyvwPpI7BO_	They are there on the client side
2018-04-19 19:14:06	pokechu22	What does pressing F3+A do?
2018-04-19 19:14:29	timmyRS	Doesn't it reload all chunks?
2018-04-19 19:14:43	timmyRS	As in re-render
2018-04-19 19:14:46	yyvwPpI7BO_	Yeah that does the trick
2018-04-19 19:15:10	yyvwPpI7BO_	After F3+A the chunks are displayed correctly
2018-04-19 19:15:11	pokechu22	Yeah.  Just curious if it would also work for those weird ones that are supposed to be unloaded
2018-04-19 19:15:20	yyvwPpI7BO_	I mean they are unloaded
2018-04-19 19:15:35	pokechu22	Ah, actually, I think it might keep the rendered version of a chunk around when it's unloaded if it's within your render distance (though I'm not completely sure)
2018-04-19 19:15:42	yyvwPpI7BO_	They are not there anymore and not included in the multiplayer chunk cache
2018-04-19 19:16:04	pokechu22	Ok, yeah, it's actually unloaded from the game, just not the separate rendered chunk thingy
2018-04-19 19:16:47	pokechu22	The newly loaded ones are weirder, but I think it might also do that if surrounding chunks aren't loaded?  If it's right at the edge of what's been sent, I mean?
2018-04-19 19:19:03	pokechu22	Hm... though I'm not sure why it'd need to do that now.  Before, it might be needed so that fences know if they're connected to surrounding blocks, but with the flattening that's sent
2018-04-19 19:20:44	yyvwPpI7BO_	The problem is that it's not consistent at all
2018-04-19 19:21:00	yyvwPpI7BO_	Sometimes the chunks start/stop rendering what I get closer
2018-04-19 19:21:05	yyvwPpI7BO_	Sometimes they don't
2018-04-19 19:21:59	pokechu22	Yeah... I feel like this is something I've been wanting to look into for ages, unless I've already looked into it .-.
2018-04-19 19:22:02	yyvwPpI7BO_	Sometimes looking away and then looking back at the chunks fixes it and sometimes it just doesn't
2018-04-19 19:22:17	pokechu22	Rendering is weird
2018-04-19 19:22:28	yyvwPpI7BO_	Is there a packet that forces the client to redraw a chunk
2018-04-19 19:22:30	yyvwPpI7BO_	?
2018-04-19 19:26:14	pokechu22	No, but I'd think it'd render it when it gets it... though I think that actually rendering a chunk to a model happens on a separate thread (THIS IS POSSIBLY NOT THE CASE THOUGH)
2018-04-19 19:26:20	pokechu22	Do you have VBOs on or off?
2018-04-19 19:29:16	yyvwPpI7BO_	On, I think it improves performance, doesn't it?
2018-04-19 19:30:52	pokechu22	Yeah, generally, though I think that it does that by basically rendering chunks into a model and then telling the graphics card to render the model, instead of rendering chunks directly -- which might be the reason they take longer to draw.  Not 100% sure.
2018-04-19 19:31:04	pokechu22	(though that doesn't explain why they take so long to "undraw")
2018-04-19 19:31:13	yyvwPpI7BO_	Disabling VBOs doesn't help
2018-04-19 19:31:21	yyvwPpI7BO_	Still the same problem
2018-04-19 19:32:29	pokechu22	k, in that case you'll probably want to keep them on
2018-04-19 19:32:35	<--	Bueddl (~Bueddl@x52716aa3.dyn.telefonica.de) a quitté (Ping timeout: 240 seconds)
2018-04-19 19:33:30	pokechu22	Are you sending like a square of chunks in the map and letting the player move about that?  Or are you sending chunks near the player and sending/removing them as they move?
2018-04-19 19:34:08	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-19 19:35:57	yyvwPpI7BO_	Right now every time the server receives a player movement packet it checks if the player moves in a new chunk and if he does, then the server loads the chunk the player moves to as well as the 4 surrounding chunks and unloads the unneeded chunks
2018-04-19 19:37:00	yyvwPpI7BO_	So more or less just a render distance of 1 chunk
2018-04-19 19:39:02	pokechu22	Ah, render distance of 1 chunk, yeah that might run into the issue of not having enough surrounding data; try upping it to 2 or 3 and see whether that works
2018-04-19 19:48:18	-->	MrGr33n (~None@BSN-142-194-111.static.siol.net) a rejoint #mcdevs
2018-04-19 19:52:48	yyvwPpI7BO_	Now this is even worse
2018-04-19 19:52:51	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 260 seconds)
2018-04-19 19:52:57	yyvwPpI7BO_	I set the render distance to 5
2018-04-19 19:53:15	yyvwPpI7BO_	And the problems are still occuring
2018-04-19 19:53:48	yyvwPpI7BO_	And for some reason only chunks within a render distance of 4 are rendering at all
2018-04-19 19:53:55	yyvwPpI7BO_	Even with F3+A
2018-04-19 19:54:20	yyvwPpI7BO_	The outter most chunks only render after receiving a block update
2018-04-19 19:54:48	<--	mbaxter (~mbax@mcblockit/staff/mbaxter) a quitté #mcdevs
2018-04-19 19:55:57	pokechu22	Yeah, to my understanding that's how it works, it doesn't render the outermost ones for some reason I think
2018-04-19 19:56:55	yyvwPpI7BO_	Okay
2018-04-19 19:57:39	yyvwPpI7BO_	But old unloaded chunk are still don't stop rendering until pressing F3+A
2018-04-19 19:59:12	-->	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-19 19:59:15	pokechu22	Weird, but possibly how it's supposed to work -- going to compare with a vanilla server with view-distance=2 and the client render distance set to something larger
2018-04-19 20:07:07	-->	millerti (~millerti@149.125.248.79) a rejoint #mcdevs
2018-04-19 20:07:57	pokechu22	Yeah, works that way in vanilla, the unloaded chunks stay rendered until F3+A (or the view distance changes)
2018-04-19 20:08:27	pokechu22	They should probably also stop rendering if they go out of your render distance
2018-04-19 20:37:43	yyvwPpI7BO_	So I've tested some more andone thing left that I don't understand
2018-04-19 20:38:06	yyvwPpI7BO_	Wow that was barely english
2018-04-19 20:38:50	yyvwPpI7BO_	If the outermost chunks are not rendered by the client then there's not chunk missing before the fog kicks in
2018-04-19 20:39:32	yyvwPpI7BO_	So should I send chunks as if the clients render distance is one higher than what they sent?
2018-04-19 20:39:38	pokechu22	Hm... it's possible that the fog starts a bit earlier?  And I know that from the side of the view you can usually see a missing chunk
2018-04-19 20:40:09	pokechu22	The notchian server actually ignores the render distance the client sent and just uses the one in server.properties, for some reason
2018-04-19 20:40:09	yyvwPpI7BO_	Yea, one chunk is missing
2018-04-19 20:40:39	pokechu22	But, try one more and see how well that works
2018-04-19 20:40:50	pokechu22	Rendering isn't exactly my thing so I don't know all the rules around it
2018-04-19 20:40:59	yyvwPpI7BO_	For example if the client says 10 chunk view distance I have to send the chunks for 11 view distance so there are no chunks missing before the fog wall
2018-04-19 20:41:07	yyvwPpI7BO_	It's just a bit weird
2018-04-19 20:41:44	yyvwPpI7BO_	Because technically the client has all the chunks it needs but because the outermost chunks are not rendered there are gaps
2018-04-19 20:43:15	pokechu22	Yeah, the whole non-rendered chunk thing doesn't exactly make sense to me, it's just the observed behavior :/
2018-04-19 20:44:00	yyvwPpI7BO_	But I guess it's not really possible to get any more information on why it works that way
2018-04-19 20:44:53	pokechu22	I mean, I could look at the code in MCP (it's not a new issue for the snapshots; it happened in 1.12 and earlier)... but I don't know enough about how rendering works to actually find the relevant stuff
2018-04-19 20:46:04	yyvwPpI7BO_	I don't really know anything about OpenGL and the like so I can't really do anything either
2018-04-19 20:47:05	yyvwPpI7BO_	On the positive side I'm impressed that the server actually manages to keep up with 10 chunks render distance
2018-04-19 20:47:18	yyvwPpI7BO_	I thought that it would be way too slow with the whole node.js single thread stuff
2018-04-19 20:51:42	<--	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 256 seconds)
2018-04-19 20:53:34	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-19 21:18:00	bueddl_	wait until chunk generation kicks in :D
2018-04-19 21:18:27	yyvwPpI7BO_	That's going to be a nightmare
2018-04-19 21:18:46	yyvwPpI7BO_	I think I need to do chunk generation in another process
2018-04-19 21:19:01	yyvwPpI7BO_	But node doesn't have shared memory yet
2018-04-19 21:19:35	yyvwPpI7BO_	Oh well I'll see what I can do when I get there
2018-04-19 21:20:02	bueddl_	well, it would not solve the entire problem to do it in another process, but yes I agree, this will become a performance nightmare :D
2018-04-19 21:20:54	yyvwPpI7BO_	But it's not really an option to do it in the main server process as it would block I/O
2018-04-19 21:21:45	bueddl_	indeed yes
2018-04-19 21:22:49	yyvwPpI7BO_	And node doesn't have threads or something like that, so another process is the only option I think
2018-04-19 21:23:21	bueddl_	hmm
2018-04-19 21:23:30	bueddl_	seems like...
2018-04-19 21:24:15	bueddl_	if you got a solution that works for you, would be very cool if you could share the idea. Doesn't help me with my implementation as I am using a different language but this is interesting :D
2018-04-19 21:24:24	yyvwPpI7BO_	I mean there are some third party implementations but they are a pain to use
2018-04-19 21:25:06	yyvwPpI7BO_	It will be difficult because I can't imagine that sending around giant buffers of chunk data with IPC is going to be very fast
2018-04-19 21:25:06	Aikar	yeah youll need to use a worker process and xfer buffers
2018-04-19 21:25:23	Aikar	sure it would be, its just IO work which node is pretty good at
2018-04-19 21:25:44	Aikar	and between processes is just a standard stream
2018-04-19 21:26:14	<--	protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2)
2018-04-19 21:26:22	yyvwPpI7BO_	We'll see, I'm going to implement it and then it will be obvious if the performance is good enough
2018-04-19 21:26:24	Aikar	serialization is the primary concern, so you may want to open your own IPC channel so it doesnt get JSON serializeds
2018-04-19 21:26:39	Aikar	and work off raw buffers
2018-04-19 21:27:10	yyvwPpI7BO_	Do buffers get serialized to JSON when you send it via IPC?
2018-04-19 21:27:12	Aikar	so your trying to write an mc server in node?
2018-04-19 21:27:18	yyvwPpI7BO_	Yea
2018-04-19 21:27:19	Aikar	if you use the built in IPC mechanism, yes
2018-04-19 21:27:24	Aikar	which is why i said open your own stream
2018-04-19 21:27:49	Aikar	you can open a stream, pass the file descriptor down to the child using the built in IPC
2018-04-19 21:27:59	Aikar	so the child can write directly to the FD
2018-04-19 21:29:52	Aikar	https://www.npmjs.com/package/webworker-threads or use this
2018-04-19 21:31:16	Aikar	actually id hope that the built in IPC would be smart enough to handle Buffers
2018-04-19 21:31:22	Aikar	worth a check
2018-04-19 21:34:02	yyvwPpI7BO_	Have you used the webworker-threads package before?
2018-04-19 21:34:06	yyvwPpI7BO_	Which option would you recommend?
2018-04-19 21:37:20	Aikar	nah i havent used it. seems like a potentially good api though as its built on the spec
2018-04-19 21:37:28	Aikar	has 10k installs in last week
2018-04-19 21:37:30	Aikar	so its actively used
2018-04-19 21:38:06	Aikar	note the ntoe about native modules
2018-04-19 21:38:17	Aikar	you cant use native modules if you use this
2018-04-19 21:38:21	Aikar	in the workers at least
2018-04-19 21:39:01	yyvwPpI7BO_	So far I'm not using any modules except the ones node provides so that should be fine
2018-04-19 21:39:52	yyvwPpI7BO_	I think I'll try using a child process first and if that doesn't work I can try the package
2018-04-19 21:39:57	Aikar	honestly, id say just use child_process.fork() for now, optimize later
2018-04-19 21:41:05	yyvwPpI7BO_	Yea right, I think I'm thinking to much about this considering my server can barely send chunks to clients right now
2018-04-19 21:41:28	Aikar	well, https://github.com/nodejs/node/blob/master/lib/internal/child_process.js#L696
2018-04-19 21:41:38	Aikar	looks like CP does always JSON.stringify :/
2018-04-19 21:41:48	Aikar	so if you wanna safe on serialization, you will need to manage your own IPC stream
2018-04-19 21:42:00	Aikar	save*
2018-04-19 21:42:19	+ammar2	build it in erlang
2018-04-19 21:42:31	+ammar2	there was one guy who was trying to do that here, I wonder where they went
2018-04-19 21:42:50	Aikar	AMMAR! I miss you
2018-04-19 21:43:02	Aikar	when you coming back to see me :P
2018-04-19 21:43:28	yyvwPpI7BO_	What the hell is erlang
2018-04-19 21:44:08	+ammar2	its a really really concurrent language, very good IPC
2018-04-19 21:44:21	+ammar2	Aikar: unless you've moved to the pacific northwest, its going to be hard :D
2018-04-19 21:45:36	yyvwPpI7BO_	Wait is it a widely used language?
2018-04-19 21:45:39	Aikar	ammar2: I've built a framework for node to do event driven development :P kind of inspired by erlang, just less magical code hopping. but goal is easy distributed consumers
2018-04-19 21:45:51	Aikar	im currently waiting on my boss to get legal approval to open source it
2018-04-19 21:46:03	+ammar2	yyvwPpI7BO_: it used to be, its kinda old
2018-04-19 21:46:08	+ammar2	it was really big in telecommunications
2018-04-19 21:46:14	+ammar2	right now the biggest user of it is probably whatsapp
2018-04-19 21:46:23	Aikar	erlang/otp was designed for distributed apps
2018-04-19 21:46:35	+ammar2	it ran a lot of the old switching infrastructure for old landline telephones
2018-04-19 21:46:55	Aikar	ive built a framework for node to achieve that too. but not exactly applicable in the context of a minecraft server
2018-04-19 21:47:54	Aikar	yyvwPpI7BO_: any reason your wanting to do this in node? honestly, node isnt a strong contender for this :/ the main benefit is an event driven design for a plugin api.  but node is designed for IO intensive apps, which an MC server is not
2018-04-19 21:48:02	Aikar	node is not good for cpu intensive stuff
2018-04-19 21:50:10	bueddl_	agree... but we'll see :D
2018-04-19 21:51:13	+ammar2	hold on, you're not the guy we've been talking to 
2018-04-19 21:51:17	+ammar2	concerned face
2018-04-19 21:51:24	Aikar	yeah i checked if he changed his name lol
2018-04-19 21:51:32	Aikar	as i have name changes hidden
2018-04-19 21:51:48	bueddl_	:D no, I am not but we were talking before about th eperformance thing
2018-04-19 21:52:18	bueddl_	sorry guys :D
2018-04-19 21:52:41	Aikar	everyone keeps starting their own idea of rewriting the server, cue XKCD Standards ._.
2018-04-19 21:52:47	bueddl_	I just did not say anything for a few minutes as I do not know about the IPC caps of node xD 
2018-04-19 21:53:01	Aikar	if everyone who started their own project all worked on one project, one might actually get vanilla complete :P
2018-04-19 21:53:10	<--	yosafbridge (~yosafbrid@68.ip-149-56-14.net) a quitté (Quit: Leaving)
2018-04-19 21:53:15	+ammar2	hahaha probably not
2018-04-19 21:53:17	+ammar2	that's so much work
2018-04-19 21:53:32	+ammar2	maybe you'd get one that's vanilla complete for like one or two versions
2018-04-19 21:53:41	+ammar2	but actively maintaining a third party server that's feature complete is bleh
2018-04-19 21:53:49	bueddl_	I had a similar discussion related to trackmania gameserver. well, everybody agreed and noone wanted to drop their own project :'D
2018-04-19 21:53:54	tktech	That's not how software development works regardless.
2018-04-19 21:54:28	tktech	Throwing more people at a project does not decrease the time to finish it.
2018-04-19 21:54:37	bueddl_	yeah, correct
2018-04-19 21:55:12	+ammar2	true, but I don't think a team of one reaches full saturation as far as making a 3rd party server goes
2018-04-19 21:55:22	tktech	At the start? Sure it does.
2018-04-19 21:55:53	tktech	You almost always want a project to start either alone or with a benevolent dictator
2018-04-19 21:56:12	+ammar2	yeah I agree, I'm more referring to implementing all the vanilla features
2018-04-19 21:56:38	<--	kev009 (~kev009@ip72-222-200-117.ph.ph.cox.net) a quitté (Remote host closed the connection)
2018-04-19 21:56:40	+ammar2	like one person plans out the basic architecture and then tacking on all the features like redstone/mobs etc you can have multiple people
2018-04-19 21:57:07	+ammar2	I think that's kind of the route glowstone took
2018-04-19 21:57:35	+ammar2	space.maniac worked out a lot of the initial setup stuff
2018-04-19 21:57:42	+ammar2	and now it has a bunch of contributors trying to make it feature complete
2018-04-19 21:58:02	-->	yosafbridge (~yosafbrid@68.ip-149-56-14.net) a rejoint #mcdevs
2018-04-19 21:59:41	-->	kev009 (~kev009@ip72-222-200-117.ph.ph.cox.net) a rejoint #mcdevs
2018-04-19 21:59:41	--	Mode #mcdevs [+v kev009] par ChanServ
2018-04-19 22:17:39	Aikar	that was kind of my point. glowstone is now at a point it needs many people working on different things
2018-04-19 22:18:24	Aikar	there are many projects that need help
2018-04-19 22:19:44	<--	millerti (~millerti@149.125.248.79) a quitté (Read error: Connection reset by peer)
2018-04-19 22:20:45	Aikar	paper welcomes any help even still ;) and we have quite a few core team members
2018-04-19 22:21:04	Aikar	totally agree more people doesnt help at start of projects
2018-04-19 22:21:41	Aikar	but there are some like glowstone and sponge that are past that point
2018-04-19 22:23:03	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 256 seconds)
2018-04-19 22:23:19	-->	Bueddl (~Bueddl@x527162ae.dyn.telefonica.de) a rejoint #mcdevs
2018-04-19 22:25:19	<--	Bueddl (~Bueddl@x527162ae.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-19 22:26:16	-->	Bueddl (~Bueddl@x527162ae.dyn.telefonica.de) a rejoint #mcdevs
2018-04-19 22:30:36	<--	Bueddl (~Bueddl@x527162ae.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-19 22:33:29	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-19 22:35:43	yyvwPpI7BO_	Aikar: Oh yea sorry for not answering, I was busy
2018-04-19 22:36:02	yyvwPpI7BO_	I chose node.js because I'm somewhat familiar with it
2018-04-19 22:39:08	yyvwPpI7BO_	My problem is that I know the syntax for a few different languages but I don't really know how to effectively use them
2018-04-19 22:40:10	yyvwPpI7BO_	For example in Java I technically know how to do most things but it's never the "correct" way to do it
2018-04-19 22:50:18	<--	lunanoko (~lunanoko@a80-101-239-73.adsl.xs4all.nl) a quitté (Read error: Connection reset by peer)
2018-04-19 22:59:31	<--	justJanne (~justJanne@lithium.kuschku.de) a quitté (Remote host closed the connection)
2018-04-19 22:59:46	-->	justJanne (~justJanne@lithium.kuschku.de) a rejoint #mcdevs
2018-04-19 23:12:49	-->	protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs
2018-04-19 23:21:12	-->	Dadido3_ (~quassel@p200300EF43C5E100C92C4BF4398B22B5.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-19 23:24:15	<--	Dadido3 (~quassel@p200300EF43C5E1004D1D1A1606CD1E31.dip0.t-ipconnect.de) a quitté (Ping timeout: 265 seconds)
2018-04-20 00:02:03	rom1504	so fix it
2018-04-20 00:36:03	<--	bueddl_ (~bueddl@ip-84-118-89-34.unity-media.net) a quitté (Quit: Leaving)
2018-04-20 00:59:30	yyvwPpI7BO_	Difficult if you don't know the better way
2018-04-20 01:23:01	<--	justJanne (~justJanne@lithium.kuschku.de) a quitté (Quit: So, if you care to find me, look to the western sky. As someone told me lately, everyone deserves a chance to fly.)
2018-04-20 01:23:14	-->	justJanne (~justJanne@lithium.kuschku.de) a rejoint #mcdevs
2018-04-20 01:52:36	<--	yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a quitté (Ping timeout: 256 seconds)
2018-04-20 01:58:33	Aikar	in a community full of java devs to ask for assistance :P
2018-04-20 02:29:41	<--	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 264 seconds)
2018-04-20 02:41:59	-->	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs
2018-04-20 04:57:40	<--	MisterVector (Vector@cpe-66-74-178-84.socal.res.rr.com) a quitté
2018-04-20 04:59:08	-->	AlphaBlend (~AlphaBlen@cpe-66-74-178-84.socal.res.rr.com) a rejoint #mcdevs
2018-04-20 06:26:12	-->	redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs
2018-04-20 06:29:34	<--	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 256 seconds)
2018-04-20 06:29:34	--	redstonehelper_ est maintenant connu sous le nom redstonehelper
2018-04-20 08:39:36	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Read error: Connection reset by peer)
2018-04-20 08:39:47	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-20 08:42:06	-->	bueddl_ (~bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-20 09:06:13	<--	ryantheleach (~ryanthele@108.61.213.128) a quitté (Ping timeout: 240 seconds)
2018-04-20 09:08:42	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 264 seconds)
2018-04-20 09:11:04	-->	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-20 09:14:55	-->	ryantheleach (~ryanthele@108.61.213.128) a rejoint #mcdevs
2018-04-20 09:26:56	<--	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 256 seconds)
2018-04-20 09:29:19	-->	Bueddl (~Bueddl@x5271624d.dyn.telefonica.de) a rejoint #mcdevs
2018-04-20 09:56:11	-->	lunanoko (~lunanoko@62.140.132.13) a rejoint #mcdevs
2018-04-20 10:11:28	<--	lunanoko (~lunanoko@62.140.132.13) a quitté (Quit: Entering my slumber...)
2018-04-20 10:24:11	-->	lunanoko (~lunanoko@D9640AEA.static.ziggozakelijk.nl) a rejoint #mcdevs
2018-04-20 11:24:50	<--	Bueddl (~Bueddl@x5271624d.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-20 11:27:39	-->	Bueddl (~Bueddl@x52716234.dyn.telefonica.de) a rejoint #mcdevs
2018-04-20 12:04:32	<--	bildramer (~bildramer@p200300ED83CE14006C4FA047B528025F.dip0.t-ipconnect.de) a quitté (Ping timeout: 265 seconds)
2018-04-20 12:05:10	-->	bildramer (~bildramer@p2E514D92.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-20 12:16:35	<--	Bueddl (~Bueddl@x52716234.dyn.telefonica.de) a quitté (Ping timeout: 240 seconds)
2018-04-20 12:17:19	-->	Bueddl (~Bueddl@x52716234.dyn.telefonica.de) a rejoint #mcdevs
2018-04-20 12:37:21	-->	redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs
2018-04-20 12:38:35	<--	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 240 seconds)
2018-04-20 12:38:35	--	redstonehelper_ est maintenant connu sous le nom redstonehelper
2018-04-20 12:43:15	<--	Bueddl (~Bueddl@x52716234.dyn.telefonica.de) a quitté (Ping timeout: 256 seconds)
2018-04-20 12:48:06	-->	Bueddl (~Bueddl@x52716234.dyn.telefonica.de) a rejoint #mcdevs
2018-04-20 12:52:21	<--	Bueddl (~Bueddl@x52716234.dyn.telefonica.de) a quitté (Ping timeout: 248 seconds)
2018-04-20 12:59:53	-->	Bueddl (~Bueddl@x2f7fea2.dyn.telefonica.de) a rejoint #mcdevs
2018-04-20 13:18:08	<--	Bueddl (~Bueddl@x2f7fea2.dyn.telefonica.de) a quitté (Ping timeout: 256 seconds)
2018-04-20 13:18:28	-->	Bueddl (~Bueddl@x2f7fea2.dyn.telefonica.de) a rejoint #mcdevs
2018-04-20 13:32:47	<--	Bueddl (~Bueddl@x2f7fea2.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-20 13:38:19	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-20 13:39:59	<--	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a quitté (Read error: Connection reset by peer)
2018-04-20 13:40:04	-->	redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs
2018-04-20 13:41:40	--	C4K3_ est maintenant connu sous le nom C4K3
2018-04-20 13:58:58	<--	protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2)
2018-04-20 14:16:45	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 256 seconds)
2018-04-20 14:17:29	-->	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-20 14:24:05	<--	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 248 seconds)
2018-04-20 14:25:03	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-20 15:03:17	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 264 seconds)
2018-04-20 15:03:43	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-20 15:08:12	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 256 seconds)
2018-04-20 15:08:48	-->	Bueddl (~Bueddl@x2f7fea2.dyn.telefonica.de) a rejoint #mcdevs
2018-04-20 15:14:36	<--	gamingrobot (sid10990@gateway/web/irccloud.com/x-okzqvdfqptwzrocb) a quitté
2018-04-20 15:14:53	-->	gamingrobot (sid10990@gateway/web/irccloud.com/x-rlqrnncubmjtfghq) a rejoint #mcdevs
2018-04-20 15:20:53	<--	Brandon15811 (sid13052@gateway/web/irccloud.com/x-evjhqiylqwwgdyxo) a quitté
2018-04-20 15:21:10	-->	Brandon15811 (sid13052@gateway/web/irccloud.com/x-hztxncsrhbxzqhgz) a rejoint #mcdevs
2018-04-20 15:33:21	<--	Jeebiss (sid25046@gateway/web/irccloud.com/x-baahzwchqiznpfsy) a quitté
2018-04-20 15:33:39	-->	Jeebiss (sid25046@gateway/web/irccloud.com/x-cutykuoddylzxuff) a rejoint #mcdevs
2018-04-20 15:37:52	-->	protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs
2018-04-20 15:49:26	<--	Bueddl (~Bueddl@x2f7fea2.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-20 15:51:13	<--	mooman219 (sid42260@gateway/web/irccloud.com/x-btwiwyhuwrucaxzm) a quitté
2018-04-20 15:51:29	<--	lunanoko (~lunanoko@D9640AEA.static.ziggozakelijk.nl) a quitté (Read error: Connection reset by peer)
2018-04-20 15:51:30	-->	mooman219 (sid42260@gateway/web/irccloud.com/x-etcyigskkzergytb) a rejoint #mcdevs
2018-04-20 15:51:33	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-20 15:52:31	-->	lunanoko (~lunanoko@D9640AEA.static.ziggozakelijk.nl) a rejoint #mcdevs
2018-04-20 17:29:30	<--	lunanoko (~lunanoko@D9640AEA.static.ziggozakelijk.nl) a quitté (Quit: Entering my slumber...)
2018-04-20 18:32:19	-->	lunanoko (~lunanoko@62.140.132.13) a rejoint #mcdevs
2018-04-20 18:32:20	<--	MrGr33n (~None@BSN-142-194-111.static.siol.net) a quitté (Read error: Connection reset by peer)
2018-04-20 18:32:26	<--	lunanoko (~lunanoko@62.140.132.13) a quitté (Client Quit)
2018-04-20 18:33:47	-->	MrGr33n (~None@BSN-142-194-111.static.siol.net) a rejoint #mcdevs
2018-04-20 20:52:44	-->	yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a rejoint #mcdevs
2018-04-20 20:57:31	<--	bildramer (~bildramer@p2E514D92.dip0.t-ipconnect.de) a quitté (Remote host closed the connection)
2018-04-20 20:58:18	-->	bildramer (~bildramer@p200300ED83CE1400282929B23C187A53.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-20 21:03:17	<--	Yamakaja (~yamakaja@vps.pub.yamakaja.me) a quitté (Ping timeout: 264 seconds)
2018-04-20 22:09:41	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 248 seconds)
2018-04-20 22:11:39	--	iczero est maintenant connu sous le nom RuBisCO
2018-04-20 22:12:37	-->	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-20 22:23:23	-->	Yamakaja (~yamakaja@vps.pub.yamakaja.me) a rejoint #mcdevs
2018-04-20 23:58:11	-->	OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a rejoint #mcdevs
2018-04-21 00:46:27	--	RuBisCO est maintenant connu sous le nom iczezro
2018-04-21 00:46:28	--	iczezro est maintenant connu sous le nom iczero
2018-04-21 00:55:50	<--	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 256 seconds)
2018-04-21 00:58:16	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-21 01:04:43	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 240 seconds)
2018-04-21 01:16:40	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-21 02:27:27	<--	yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a quitté (Ping timeout: 260 seconds)
2018-04-21 03:21:21	<--	bueddl_ (~bueddl@ip-84-118-89-34.unity-media.net) a quitté (Remote host closed the connection)
2018-04-21 06:21:57	<--	SpaceManiac (~SpaceMani@c-67-172-123-140.hsd1.ca.comcast.net) a quitté (Ping timeout: 260 seconds)
2018-04-21 06:24:32	-->	redstonehelper (~redstoneh@unaffiliated/redstonehelper) a rejoint #mcdevs
2018-04-21 06:28:04	<--	redstonehelper_ (~redstoneh@unaffiliated/redstonehelper) a quitté (Ping timeout: 276 seconds)
2018-04-21 06:57:55	-->	SpaceManiac (~SpaceMani@2601:200:4480:142a:385d:b901:bd3:4106) a rejoint #mcdevs
2018-04-21 06:57:55	--	Mode #mcdevs [+v SpaceManiac] par ChanServ
2018-04-21 07:19:01	<--	OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a quitté (Ping timeout: 248 seconds)
2018-04-21 08:05:01	-->	Amplificatoraw (~owmigif@111.67.92.230) a rejoint #mcdevs
2018-04-21 08:05:04	Amplificatoraw	https://www.youtube.com/user/l0de/live IS POPPIN HOT RIGHT NOW STILL GOING!! CALL 315-505-4666. IRC.EFNET.ORG #lrh
2018-04-21 08:05:04	Amplificatoraw	https://www.youtube.com/user/l0de/live IS POPPIN HOT RIGHT NOW STILL GOING!! CALL 315-505-4666. IRC.EFNET.ORG #lrh
2018-04-21 08:05:05	Amplificatoraw	https://www.youtube.com/user/l0de/live IS POPPIN HOT RIGHT NOW STILL GOING!! CALL 315-505-4666. IRC.EFNET.ORG #lrh
2018-04-21 08:05:09	Amplificatoraw	SpaceManiac redstonehelper Bueddl Yamakaja bildramer MrGr33n mooman219 protryon Jeebiss Brandon15811 gamingrobot ryantheleach AlphaBlend justJanne Dadido3_ kev009 yosafbridge KnownUnown begin_end NickG365 _123DMWM Black_Hole electroniccat hansihe C4K3 yangm97 Moep[m] kashike someone_stole_my XorBoole McLive DemonWav ScruffyRules Zachoz clj md_5 WizardCM __0x277F fl4sh_ Morrolan ShaRose peterix chibill Byteflux Fador |Blaze| ashka Krenair GunfighterJ 
2018-04-21 08:05:09	<--	Amplificatoraw (~owmigif@111.67.92.230) a quitté (Client Quit)
2018-04-21 08:44:05	<--	star (~star@c-76-16-146-255.hsd1.il.comcast.net) a quitté (Read error: Connection reset by peer)
2018-04-21 08:55:24	Proximyst	lmfao whats with these lode guys
2018-04-21 09:23:29	electroniccat	What can you say, they love a nice lo... nvm
2018-04-21 09:25:59	Proximyst	shane.
2018-04-21 09:26:00	Proximyst	no.
2018-04-21 11:38:54	-->	yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a rejoint #mcdevs
2018-04-21 12:26:52	<--	bildramer (~bildramer@p200300ED83CE1400282929B23C187A53.dip0.t-ipconnect.de) a quitté (Ping timeout: 276 seconds)
2018-04-21 12:27:08	-->	bildramer (~bildramer@p200300ED83CE1400D0F55A40657F20ED.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-21 12:33:50	<--	bildramer (~bildramer@p200300ED83CE1400D0F55A40657F20ED.dip0.t-ipconnect.de) a quitté (Ping timeout: 256 seconds)
2018-04-21 12:34:38	-->	bildramer (~bildramer@p2E514D92.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-21 13:54:54	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 264 seconds)
2018-04-21 13:59:08	-->	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-21 14:20:53	<--	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 248 seconds)
2018-04-21 14:31:16	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-21 14:35:30	-->	star (~star@c-76-16-146-255.hsd1.il.comcast.net) a rejoint #mcdevs
2018-04-21 16:14:45	<--	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a quitté (Ping timeout: 265 seconds)
2018-04-21 16:15:17	-->	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-21 16:26:43	<--	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 240 seconds)
2018-04-21 16:35:23	-->	Bueddl (~Bueddl@x527163aa.dyn.telefonica.de) a rejoint #mcdevs
2018-04-21 16:40:12	-->	itsme_ (~textual@x590f8066.dyn.telefonica.de) a rejoint #mcdevs
2018-04-21 16:47:33	<--	Bueddl (~Bueddl@x527163aa.dyn.telefonica.de) a quitté (Ping timeout: 248 seconds)
2018-04-21 16:49:03	-->	Bueddl (~Bueddl@x52716317.dyn.telefonica.de) a rejoint #mcdevs
2018-04-21 16:50:14	-->	iso2013 (~iso2013@2601:281:c503:9186:410f:44d8:ca53:1c47) a rejoint #mcdevs
2018-04-21 17:07:17	<--	Bueddl (~Bueddl@x52716317.dyn.telefonica.de) a quitté (Ping timeout: 248 seconds)
2018-04-21 17:40:29	<--	Yamakaja (~yamakaja@vps.pub.yamakaja.me) a quitté (Ping timeout: 264 seconds)
2018-04-21 17:44:04	-->	Bueddl (~Bueddl@x5271620c.dyn.telefonica.de) a rejoint #mcdevs
2018-04-21 17:51:15	-->	winger_sendon (~winger@27.114.131.54) a rejoint #mcdevs
2018-04-21 17:52:39	winger_sendon	There's no serverbound disconnect packet. So the server doesn't distinguish between timeouts, network errors or real disconnects. Hmm, interesting..
2018-04-21 17:53:32	Andrio	It does distinguish timeouts, doesn't it?
2018-04-21 17:54:05	<--	Bueddl (~Bueddl@x5271620c.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-21 17:54:11	-->	Bueddl (~Bueddl@x2f7fd16.dyn.telefonica.de) a rejoint #mcdevs
2018-04-21 17:57:19	-->	Yamakaja (~yamakaja@vps.pub.yamakaja.me) a rejoint #mcdevs
2018-04-21 17:58:35	winger_sendon	Ohh, I guess it checks for the kind of errors too then. My bad
2018-04-21 18:03:30	<--	Bueddl (~Bueddl@x2f7fd16.dyn.telefonica.de) a quitté (Read error: Connection reset by peer)
2018-04-21 18:09:20	-->	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-21 18:24:51	<--	Bueddl (~Bueddl@ip-84-118-89-34.unity-media.net) a quitté (Ping timeout: 256 seconds)
2018-04-21 18:32:06	-->	Bueddl (~Bueddl@p5B3F7204.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-21 18:34:37	<--	MrGr33n (~None@BSN-142-194-111.static.siol.net) a quitté (Read error: Connection reset by peer)
2018-04-21 18:38:33	-->	winger_sendon_ (~winger@27.114.131.54) a rejoint #mcdevs
2018-04-21 18:49:21	-->	MrGr33n (~None@BSN-142-194-111.static.siol.net) a rejoint #mcdevs
2018-04-21 19:02:46	<--	MrGr33n (~None@BSN-142-194-111.static.siol.net) a quitté (Read error: Connection reset by peer)
2018-04-21 19:30:26	-->	MrGr33n (~None@BSN-142-194-111.static.siol.net) a rejoint #mcdevs
2018-04-21 19:31:02	<--	MrGr33n (~None@BSN-142-194-111.static.siol.net) a quitté (Read error: Connection reset by peer)
2018-04-21 19:31:57	-->	MrGr33n (~None@BSN-142-194-111.static.siol.net) a rejoint #mcdevs
2018-04-21 20:09:58	-->	bueddl_ (~bueddl@ip-84-118-89-34.unity-media.net) a rejoint #mcdevs
2018-04-21 20:53:21	yyvwPpI7BO_	I'm having a bit of trouble with sending multiple sections in a chunk correctly
2018-04-21 20:53:34	yyvwPpI7BO_	Sending a single section works fine however more than that cause the client to disconnect with the error message that the packet was 18 bytes too long
2018-04-21 20:53:46	yyvwPpI7BO_	I've calculated the exact byte size the packet should have as per my understanding of the chunk data packet structure and my code outputs a packet of this exact length
2018-04-21 20:53:54	yyvwPpI7BO_	So I must have misunderstood how the packet works in general I think
2018-04-21 20:54:02	yyvwPpI7BO_	And I would like to request some help as I'm stuck right now
2018-04-21 20:56:34	pokechu22	Always 18 bytes too long, no matter how many sections you send?  Or an extra 18 bytes for each section?
2018-04-21 20:56:59	yyvwPpI7BO_	Oh yea I should have clarified that, it's 18 bytes too long with 2 sections
2018-04-21 20:57:12	yyvwPpI7BO_	Give me a second, I'll try it with more
2018-04-21 20:59:27	yyvwPpI7BO_	With 3 sections it's 15 too many
2018-04-21 20:59:58	pokechu22	o.o
2018-04-21 21:00:15	yyvwPpI7BO_	4 section is a bad packet id
2018-04-21 21:00:26	yyvwPpI7BO_	and 5 sections is 22 extra bytes
2018-04-21 21:00:27	<--	bildramer (~bildramer@p2E514D92.dip0.t-ipconnect.de) a quitté (Ping timeout: 260 seconds)
2018-04-21 21:00:28	yyvwPpI7BO_	what
2018-04-21 21:00:32	pokechu22	wut
2018-04-21 21:00:49	protryon	probably some overwriting if i were to guess
2018-04-21 21:00:56	pokechu22	Is there a chance you're sending the data at the start of the packet (chunk x and z, among other things) with each section?
2018-04-21 21:00:57	protryon	are you using a stream or an array?
2018-04-21 21:01:11	protryon	if its an array, could be some indexing issues
2018-04-21 21:01:27	yyvwPpI7BO_	I'm stiching together Buffer objects
2018-04-21 21:01:37	pokechu22	They're using node.js IIRC
2018-04-21 21:01:41	protryon	aye
2018-04-21 21:01:47	protryon	check your indexing and format
2018-04-21 21:01:54	-->	bildramer (~bildramer@p2E514D92.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-21 21:01:59	protryon	doing a hex dump and going over is the best way imo
2018-04-21 21:02:04	yyvwPpI7BO_	With Buffer.concat, so that shouldn't really happen, should it?
2018-04-21 21:02:13	protryon	i see
2018-04-21 21:02:31	yyvwPpI7BO_	The packet is 20KB long o.o
2018-04-21 21:02:36	yyvwPpI7BO_	Manual hex review yay
2018-04-21 21:02:42	protryon	perhaps your header is misconfigured to deal with the sizes of the sections
2018-04-21 21:03:00	protryon	or like poke said, sending the data with each section
2018-04-21 21:03:11	protryon	but yea u can manual hex 20 kb easy
2018-04-21 21:03:27	protryon	use the goto function
2018-04-21 21:04:29	yyvwPpI7BO_	Okay, I'll see
2018-04-21 21:04:36	yyvwPpI7BO_	what I can find
2018-04-21 21:04:47	protryon	compare to expected output
2018-04-21 21:09:29	<--	winger_sendon (~winger@27.114.131.54) a quitté (Quit: Leaving)
2018-04-21 21:09:30	<--	winger_sendon_ (~winger@27.114.131.54) a quitté (Quit: Leaving)
2018-04-21 21:17:03	yyvwPpI7BO_	Oh well I know what went wrong
2018-04-21 21:18:10	yyvwPpI7BO_	My VarInt creation code had this line: if(int > 0) tempArray[0] |= 0b10000000;
2018-04-21 21:18:21	yyvwPpI7BO_	When it should have been: if(int > 0) tempArray[tempArray.length - 1] |= 0b10000000;
2018-04-21 21:18:29	pokechu22	:D
2018-04-21 21:18:49	pokechu22	I can see how that could also maybe lead to bad packets for very large ones
2018-04-21 21:18:53	yyvwPpI7BO_	And the reason why one section worked was because the numbers were small enough for 14 bits
2018-04-21 21:18:59	protryon	ye
2018-04-21 21:19:09	yyvwPpI7BO_	this code only stops working with 15 bits and more
2018-04-21 21:19:19	yyvwPpI7BO_	I'm so dumb
2018-04-21 21:19:27	pokechu22	At least it's tempArray and not buffer
2018-04-21 21:19:39	pokechu22	Though if it were buffer, that'd be a bit more obvious
2018-04-21 21:19:57	yyvwPpI7BO_	That would be too easy
2018-04-21 21:25:54	yyvwPpI7BO_	My next problem is that sending chunks to the client always causes a lag spike
2018-04-21 21:26:12	yyvwPpI7BO_	Is that just my potato PC or am I doing something wrong?
2018-04-21 21:28:15	pokechu22	It's possible that the client is recalculating the lighting in them or something
2018-04-21 21:28:43	pokechu22	If you haven't implemented lighting on the server, then the lighting might be wrong; usually the client ignores it until something triggers an update thoguh
2018-04-21 21:28:56	pokechu22	Otherwise it could just be your PC being a potato though
2018-04-21 21:29:46	pokechu22	Oh, also, if you haven't implemented the palette, note that the client won't do it for you; it'll store the uncompressed representation there too which may increase lag a bit (but I wouldn't think it'd cause a spike)
2018-04-21 21:30:04	<--	itsme_ (~textual@x590f8066.dyn.telefonica.de) a quitté (Quit: Textual IRC Client: www.textualapp.com)
2018-04-21 21:30:11	yyvwPpI7BO_	Okay
2018-04-21 21:32:21	yyvwPpI7BO_	I was just wondering because right now with vsync half of my frames render in 33ms and the other half in 17ms, but every time I cross a chunk border (which is what triggers sending new chunks) the frame time spikes to 66ms or higher
2018-04-21 21:32:43	yyvwPpI7BO_	Just wanted to confirm that that's just my PC
2018-04-21 21:33:59	protryon	when u cross a chunk border, it renders more chunks depending on your render distance
2018-04-21 21:34:08	protryon	and unloads some as directed by the server
2018-04-21 21:36:27	yyvwPpI7BO_	Do normal servers handle chunk loading/unloading the same way?
2018-04-21 21:39:08	pokechu22	Yeah, they send chunks when the client loads them
2018-04-21 21:39:32	yyvwPpI7BO_	I mean if they do it every time the client crosses a chunk border
2018-04-21 21:39:53	pokechu22	I think craftbukkit and derivatives do chunk loading from players async, which has a side effect of not sending all the chunks instantly but instead more or less 1 at a time
2018-04-21 21:40:01	pokechu22	but yeah, they do it when they cross a chunk border more or less
2018-04-21 21:40:24	protryon	yep
2018-04-21 21:40:26	yyvwPpI7BO_	Okay, so my implementation should be fine for now?
2018-04-21 21:40:52	pokechu22	Yeah
2018-04-21 21:40:58	yyvwPpI7BO_	Nice
2018-04-21 21:52:47	yyvwPpI7BO_	Maybe saving chunks as JSON wasn't the best idea
2018-04-21 21:52:56	protryon	no probably not
2018-04-21 21:53:02	yyvwPpI7BO_	250MB for 500 chunks seems a bit excessive
2018-04-21 21:53:06	pokechu22	Yeah... that's pretty unwise
2018-04-21 21:53:13	protryon	the stock format is pretty good and has the advantage of being cross compatible with other serversd
2018-04-21 21:53:53	pokechu22	Yeah, I'd recommend the stock one... though I don't think the 1.13 version for it is fully documented yet
2018-04-21 21:54:05	protryon	oh its changed?
2018-04-21 21:54:20	protryon	i havent dabbled in MC since 1.11
2018-04-21 21:54:23	pokechu22	Yeah, they've got a palette on the disk format now (like with the network format), and a ton of other stuff
2018-04-21 21:54:42	pokechu22	No more metadata, due to the flattening :D  Just block states, which are in that palette
2018-04-21 21:54:58	yyvwPpI7BO_	I've already implemented my own version of a anvil file parser, so I think that should be fine
2018-04-21 21:55:40	yyvwPpI7BO_	Even if I don't use the exact format I'll probably still save the chunks as NBT because JSON doesn't really cut it
2018-04-21 21:56:02	protryon	ye
2018-04-21 21:56:06	protryon	im not complaining about that
2018-04-21 21:56:09	pokechu22	The raw structure of the file didn't change (it's still the compressed NBT in that container format), it's just the contents of the NBT that's different now
2018-04-21 21:56:09	yyvwPpI7BO_	But it was only meant to be temporary anyways
2018-04-21 21:56:11	protryon	the palette > gzip
2018-04-21 21:56:43	protryon	what kinda server ya working on yyvw?
2018-04-21 21:57:00	yyvwPpI7BO_	Uhm
2018-04-21 21:57:09	yyvwPpI7BO_	Just a very simple one
2018-04-21 21:57:28	yyvwPpI7BO_	Right now it's barely enough to get the client ingame without crashing
2018-04-21 21:57:45	protryon	aye
2018-04-21 21:57:52	yyvwPpI7BO_	More or less just a challenge for myself
2018-04-21 21:57:59	yyvwPpI7BO_	To see if I could do that
2018-04-21 21:58:13	yyvwPpI7BO_	Because I'm not really all that good at programming
2018-04-21 21:59:09	yyvwPpI7BO_	And I really should have chosen a better name than random letters and numbers
2018-04-21 21:59:21	protryon	yea
2018-04-21 22:00:17	yyvwPpI7BO_	To be fair I thought I would only ask one question and then leave again but as it turns out I'm too dumb to write my server by myself :D
2018-04-21 22:04:13	yyvwPpI7BO_	But I have to say that writing the server has been really interesting so far
2018-04-21 22:06:55	yyvwPpI7BO_	So thanks for all of the help with my problems
2018-04-21 22:07:59	pokechu22	Yeah, it's a neat project
2018-04-22 01:01:41	<--	Thinkofname (~Think@ns3091419.ip-5-135-185.eu) a quitté (Quit: Leaving)
2018-04-22 01:02:42	-->	Thinkofname (~Think@ns3091419.ip-5-135-185.eu) a rejoint #mcdevs
2018-04-22 01:02:52	--	Mode #mcdevs [+v Thinkofname] par ChanServ
2018-04-22 01:20:28	<--	bueddl_ (~bueddl@ip-84-118-89-34.unity-media.net) a quitté (Remote host closed the connection)
2018-04-22 02:02:17	<--	protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a quitté (Quit: WeeChat 1.7-rc2)
2018-04-22 03:06:49	<--	balrog (~balrog@unaffiliated/balrog) a quitté (Quit: Bye)
2018-04-22 03:10:41	-->	balrog (~balrog@unaffiliated/balrog) a rejoint #mcdevs
2018-04-22 03:37:54	-->	protryon (~protryon@c-67-180-93-98.hsd1.ca.comcast.net) a rejoint #mcdevs
2018-04-22 04:23:34	<--	yyvwPpI7BO_ (~yyvwPpI7B@188-167-251-231.dynamic.chello.sk) a quitté (Ping timeout: 256 seconds)
2018-04-22 05:37:29	<--	balrog (~balrog@unaffiliated/balrog) a quitté (Ping timeout: 264 seconds)
2018-04-22 05:45:20	<--	iso2013 (~iso2013@2601:281:c503:9186:410f:44d8:ca53:1c47) a quitté (Quit: Bye :))
2018-04-22 05:47:36	-->	iso2013 (~iso2013@2601:281:c503:9186:410f:44d8:ca53:1c47) a rejoint #mcdevs
2018-04-22 05:57:22	-->	balrog (~balrog@unaffiliated/balrog) a rejoint #mcdevs
2018-04-22 06:09:13	<--	iso2013 (~iso2013@2601:281:c503:9186:410f:44d8:ca53:1c47) a quitté (Quit: Bye :))
2018-04-22 07:04:52	-->	OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a rejoint #mcdevs
2018-04-22 07:29:09	<--	OkAlt (~OkAlt@S0106f0f2498160d3.lb.shawcable.net) a quitté (Ping timeout: 248 seconds)
2018-04-22 07:31:44	<--	MrGr33n (~None@BSN-142-194-111.static.siol.net) a quitté (Remote host closed the connection)
2018-04-22 07:32:09	-->	MrGr33n (~None@BSN-142-194-111.static.siol.net) a rejoint #mcdevs
2018-04-22 08:52:15	<--	bildramer (~bildramer@p2E514D92.dip0.t-ipconnect.de) a quitté (Remote host closed the connection)
2018-04-22 08:53:02	-->	bildramer (~bildramer@p200300ED83CE14007891143D8C2796B8.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-22 09:34:22	<--	bildramer (~bildramer@p200300ED83CE14007891143D8C2796B8.dip0.t-ipconnect.de) a quitté (Ping timeout: 276 seconds)
2018-04-22 09:34:58	-->	bildramer (~bildramer@p2E514D92.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-22 12:08:11	<--	bildramer (~bildramer@p2E514D92.dip0.t-ipconnect.de) a quitté (Remote host closed the connection)
2018-04-22 12:08:55	-->	bildramer (~bildramer@p200300ED83CE14008DE4F7E9857DEBFA.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-22 12:45:19	<--	begin_end (admin@ho.by) a quitté (Ping timeout: 256 seconds)
2018-04-22 12:48:07	-->	begin_end (admin@ho.by) a rejoint #mcdevs
2018-04-22 13:05:37	<--	bildramer (~bildramer@p200300ED83CE14008DE4F7E9857DEBFA.dip0.t-ipconnect.de) a quitté (Ping timeout: 276 seconds)
2018-04-22 13:08:13	-->	bildramer (~bildramer@p200300ED83CE140004CE97675CB5EE0F.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-22 13:08:37	-->	bildramer1 (~bildramer@p200300ED83CE1400D57E3E2707E1BF35.dip0.t-ipconnect.de) a rejoint #mcdevs
2018-04-22 13:13:25	<--	bildramer (~bildramer@p200300ED83CE140004CE97675CB5EE0F.dip0.t-ipconnect.de) a quitté (Ping timeout: 276 seconds)
2018-04-22 13:30:35	-->	Mr_Gr33n (~None@BSN-142-194-111.static.siol.net) a rejoint #mcdevs
2018-04-22 13:34:30	<--	MrGr33n (~None@BSN-142-194-111.static.siol.net) a quitté (Ping timeout: 256 seconds)