21:29 < morfin> as i said furnace-door
21:29 < morfin> but test pattern is everywhere
21:29 < Thinkofdeath> yeah I changed it from the server pre-stitching the textures to the client doing it as it needs them
21:29 < Thinkofdeath> I guess that broke something
21:30 < morfin> it looks like when in Source games you're not missing material but missing overlay
21:32 < morfin> what language did you use for that?
21:32 < morfin> on backend
21:32 < Thinkofdeath> the server is bukkit running a plugin (java)
21:32 < Thinkofdeath> the client is java compiled to js
21:32 < morfin> ow
21:32 < morfin> bukkit plugin)
21:33 < morfin> looks like client is sending over 9000 requests chunk
21:33 < Thinkofdeath> one request per a chunk
21:34 < Thinkofdeath> its a work around instead of using websockets because compression isn't supported over them 
21:34 < morfin> hm?
21:34 < morfin> did not know that websockets can't compress
21:35 < Thinkofdeath> well if you do it yourself they can but the thought of doing zlib in javascript put be off :P
21:35 < morfin> lol zlib in JS
21:36 < morfin> https://github.com/imaya/zlib.js
21:36 < morfin> yep
21:38 < morfin> 14.5kb for deflating/inflating is not big deal i think
21:40 < Thinkofdeath> its less of the library size and more of the performance hit it would incur
21:41 < umby24> http://i.imgur.com/7xGcstQ.jpg looks a bit weird but im overall impressed
21:41 < morfin> not that big perfomance hit i think
21:41  * Thinkofdeath reverts the texture changes
21:41 < morfin> that's based on math so not sure 
21:47 < TkTech> umby24: Did you do something to make it brighter? Pitch black for me
21:47 < umby24> everything was black, took a few seconds then all the textures loaded
21:48 < TkTech> I see all the textures, but it's like it has no point of light
21:48 < TkTech> The textures themselves have a bit of brightness, but everything else is black
21:49 < umby24> Odd, but nope, didn't do anything to it
21:49 < Thinkofdeath> i've just reverted the changes, lets see if that fixed it :)
21:49 < TkTech> Much better, no more flickering or texture issues
21:50 < TkTech> And after a couple of steps lighting loaded
21:50 < umby24> ahhhh indeed
21:50 < Thinkofdeath> ah the lighting is because I changed the time on the server
21:51 < Thinkofdeath> i'll have to re-think those changes
21:52 < TkTech> Thinkofdeath: What is this insane thing under the map
21:52 < Thinkofdeath> its an adventure map I just put on the server for testing with
21:53 < Thinkofdeath> that would be all the inner workings :)
21:53 < TkTech> Ah
21:53 < TkTech> 6% battery in 120 seconds ;-(
21:53 < Thinkofdeath> mobile?
21:53 < TkTech> +10/15˚C
21:53 < TkTech> Aye
21:53 < TkTech> WebGL is kinda shitty there
21:54 < Thinkofdeath> yeah
22:04 <+AndrewPH> ajf: as a note, javascript lacks any kind of real sockets as far as I know, so you won't be able to connect to any classic servers without a compatibility proxy.
22:04 < ajf> AndrewPH: That’s the idea.
22:04 <+AndrewPH> okay just making sure
22:04 < ajf> TCP<->WebSocket proxies do exist
22:05 < ajf> I’m using one for development just now against the official Minecraft Classic server
22:13 < ajf> Things that always bothered me: There are several packets whose client-server variant or vice-versa has a “padding” byte because the server-client variant or vice-versa used it for something… and yet the there are two different Set Block packets.
22:13 < ajf> Why.
22:13 < ajf> The Mode byte is useless, the client should just send a 0
22:53 < Drainedsoul> ajf: What are you talking about?
22:53 < ajf> Drainedsoul: Minecraft Classic protocol ;)
--- Day changed mer. août 06 2014
16:41 < Not-29be> [mcprotocol] thinkofdeath pushed 1 commit to master [+1/-0/±54] http://git.io/d3FNgw
16:41 < Not-29be> [mcprotocol] thinkofdeath 6d4c60f - 14w32a
17:10 < Not-29be> [mcprotocol] thinkofdeath pushed 1 commit to master [+1/-1/±2] http://git.io/Lxg7hA
17:10 < Not-29be> [mcprotocol] thinkofdeath bf9928b - Clientbound73 -> UpdateEntityNBT
18:33 < Thinkofdeath> So unless i've missed something armor stands use the new entity nbt packet, why not just use the existing metadata system?
18:34 < Thinkofdeath> unless that is being phased out
19:55 < Drainedsoul> Thinkofdeath: You around?
19:55 < Thinkofdeath> yep
19:56 < Drainedsoul> Could you clarify for me: In the new protocol, is the Data Length field included in the overall length, or excluded?
19:56 < Drainedsoul> I've gotten conflicting answers
19:56 < Thinkofdeath> you mean the data length from the compression?
19:56 < Thinkofdeath> if so then yes
19:57 < Drainedsoul> nice, thanks
19:57 < Drainedsoul> I'll edit the pre-release protocol page to make that clear, is that alright with you?  Since you seem to be the de facto maintainer of that page
19:58 < Thinkofdeath> go for it :)
20:39 < morfin> hey Thinkofdeath
20:39 < morfin> do you really just show chunks loaded on server?
20:42 < morfin> i've found bug in your map-viewer)
20:43 < Thinkofdeath> ?
20:44 < Thinkofdeath> morfin: What bug?
20:45 < morfin> when you go into nowhere everything becomes invisible
20:46 < morfin> i mean not=loaded chunks
20:46 < Thinkofdeath> oh that
20:46 < Thinkofdeath> yeah still need to fix that :P
20:47 < morfin> are you going to show entities?
20:48 < Thinkofdeath> at some point
20:48 < morfin> idk why Minecraft is not using skeletal antimation
20:48 < morfin> *animation and rendering all stuff using code
20:51 < morfin> something like Source is using(you have animations in a model file and just call them)
21:23 < Dinnerbone> We will. We've already turned towards all blocks being defined in a model format, that was 1.8, entities will follow suit in the future too.
21:57 < benbaptist> Isn't the vanilla Minecraft server supposed to remember UUIDs for player usernames when in offline mode? 
21:58 < benbaptist> Why does a server completely forget my identity upon setting a server from online to offline mode? this totally screws up proxy scenarios
22:05 < Thinkofdeath> benbaptist: because you have a different uuid in offline mode
22:05 < Thinkofdeath> the server only gets the correct uuid (normally) from the session server on login
22:06 < Thinkofdeath> that normally was badly placed
22:28 < benbaptist> Thinkofdeath, I know it generates a UUID in offline mode if it doesn't have your real one, but isn't the purpose of usercache.json for preserving your actual UUID upon offline mode, and other caching needs? (interacting with players not online, etc.)
22:29 < Thinkofdeath> benbaptist: nope its there to save on repeated lookups on mojang's api
22:30 < benbaptist> That really sucks that Minecraft won't use it in offline mode. I suppose I could write a script that goes through all of my player files and rename them to their offline-equivilant UUIDs?
22:31 < Thinkofdeath> yes but only online -> offline really
22:31 < Thinkofdeath> the other way is hard since vanilla doesn't save the username in the player.dat
22:31 < Thinkofdeath> (bukkit does)
22:32 < benbaptist> yeah. I'd probably have to rely on using usercache.json and do Mojang API lookups for any player files not in usercache.json
22:32 < Thinkofdeath> for online mode to offline mode, yeah that will work
22:32 < Dinnerbone> Offline-mode is supposed to not involve our authentication in any way, it'd be highly inconsistent to have some players use a name-based-uuid and some players have a uuid which may or may not be a real uuid they may have had at some point in time
22:35 < benbaptist> Ah, that makes sense.
--- Day changed jeu. août 07 2014
17:08 < Not-9d73> [mcprotocol] thinkofdeath pushed 1 commit to master [+0/-0/±56] http://git.io/Datp4g
17:08 < Not-9d73> [mcprotocol] thinkofdeath fb6fed9 - 14w32b
21:18 < shelvacu> I have a strange bug that only seems to pop up after a few hours, but then 'sticks' which causes any clients who connect to crash. I've debugged the client, and apparently a packet24MobSpawn is being sent over with a zeroed mob type. However, the only server right now which is exibiting this behaviour is on a remote headless machine, and the JVM was not started with debug options.
21:18 < shelvacu> I was able to use jsadebugd to do.... something. jinfo and jstack work, but provide no useful information, however I can't get netbeans to connect, it always fails with "handshake failed - connection prematurally closed"
21:19 < shelvacu> and also those are copy-pasted cause I was redirected from #minecraft
21:19 < shelvacu> any ideas?
--- Day changed ven. août 08 2014
04:20 < n___> Hello.
04:43 < n___> When it says the UUID now contains a "-", what does that mean?
04:43 < n___> I've tried at the end and beginning, keep getting invalid string error.
04:59 <+Amaranthus> n___: It means they're in the normal UUID format which includes - separators between the sections
05:00 <+Amaranthus> n___: 123e4567-e89b-12d3-a456-426655440000
06:30 < n___> i see
06:30 < n___> ill have to study this more, thanks amarnthus
16:44 < Not-9d73> [mcprotocol] thinkofdeath pushed 1 commit to master [+0/-0/±13] http://git.io/D0SESA
16:44 < Not-9d73> [mcprotocol] thinkofdeath 7c9ce30 - 14w32c
17:16 < Not-9d73> [mcprotocol] thinkofdeath pushed 1 commit to master [+0/-0/±6] http://git.io/1NAkvQ
17:16 < Not-9d73> [mcprotocol] thinkofdeath a4e5b6a - Map enum fields
17:17 < TkTech> Thinkofdeath: You're the #1 editor of the wiki by number of changes and change deltas now
17:17 < Thinkofdeath> \o/
17:18 < Thinkofdeath> I need a new hobby :P
17:19 < TkTech> But "professional wiki editor in chief" sounds so cool :)
17:19 < Thinkofdeath> lol :)
18:43 < Mathuin> I am finally at the point in my project that I need to worry about block IDs and data IDs and all that.  Is there anyone out there that does it right?  mcedit uses a YAML file IIRC, what about other folks?
18:46 < shoghicp> hmm, for a server?
18:48 < Mathuin> For a terrain generator.
18:49 < shoghicp> well, I just have a class per block to implement all the features of it
18:49 < shoghicp> but for simple things or the generator, it just uses the id/data
18:53 < Mathuin> That is correct.  mcedit lets you say things like 49, or "Obsidian", for simple blocks, and (18, 0) for block and data values for "Oak Leaves".
18:53 < Mathuin> I'm trying to figure out what the best approach is.
18:54 < Mathuin> Unlike mcedit, I don't have to satisfy the arbitrary user of my software, as all of this is internal.
18:57 < shoghicp> well, check if the input exists on a list of block names
18:57 < shoghicp> if not, check if it's a number, then use it
18:58 < Mathuin> What I was thinking was a pairing of tuples with names.  "Obsidian" will return (49, 0), "Oak Leaves" will return (18, 0), etc.
18:59 < shoghicp> yeah, that works :)
18:59 < Mathuin> Then have .SetBlock(string) set the block value and data value for the blocks.
19:00 < Mathuin> Since I'm generating worlds out of whole cloth, stuff like "dirty chunks" and block/sky lighting are things I'm avoiding.
19:00 < Mathuin> So I'm trying to find a good solution that will be useful if someone is crazy enough to want to reuse my code for more interesting projects.
19:02 < shoghicp> yeah, a way to configure the blocks will be good
19:05 < Drainedsoul> pairing objects with names seems more semantic than tuples
19:06 < Mathuin> What do you mean by objects more semantic than tuples?
19:13 < Mathuin> I specifically asked because I planned on implementing my tuples as objects. :-)
19:17 < benbaptist> I don't think I've ever seen a d snapshot before.
19:17 < redstonehelper> there's been an e one
19:18 < benbaptist> Really? Woah. I'm going to see if the latest D fixes most of my protocol errors that I was getting last time I tried it.
19:18 < benbaptist> on my proxy
19:18 < redstonehelper> there's actually been 2 e snapshots
19:21 < benbaptist> dang.
19:21 < Mathuin> So tempting to lift the YAML file from mcedit, but then I'm depending on them to be at the same version as me.  Hrm.
19:21 < benbaptist> also, looks like 14w32d works way better for my proxy. Hooray. On another note, is zlib.decompress() good enough for decompressing packets on Python?
19:22 < benbaptist> reason I ask is, some packets randomly give me a "Error while decompressing data: incorrect header check"
19:23 < benbaptist> or other random errors. But I seem to be parsing the rest of the protocol fine - I have no errors after that.
19:23 < benbaptist> as long as I catch the zlib.decompress function, anyways. but then that results in me dropping packets
21:01 < n___> Hello.
21:17 < Not-9d73> [mcprotocol] thinkofdeath pushed 1 commit to master [+6/-0/±6] http://git.io/1-j0eA
21:17 < Not-9d73> [mcprotocol] thinkofdeath 7bfeba5 - Give names to some of the enums used in the protocol
21:23 < Not-9d73> [mcprotocol] thinkofdeath pushed 1 commit to master [+1/-1/±1] http://git.io/pjbePQ
21:23 < Not-9d73> [mcprotocol] thinkofdeath 7b16d92 - Particles -> Particle (as requested by @yawkat)
21:23 < yawkat> <3
21:23 < Thinkofdeath> :)
21:23  * yawkat adds mcdevs to contrib list, who checks that anyway
21:47 < Not-9d73> [mcprotocol] thinkofdeath pushed 1 commit to master [+6/-0/±6] http://git.io/gTrNaw
21:47 < Not-9d73> [mcprotocol] thinkofdeath 5f094f4 - Add mappings for more enums
22:00 < n___> Hello
22:01 < redstonehelper> n___: you can just ask your question
22:02 < n___> I was busy with my kid.
22:02 < n___> Little dudes being fussy
22:02 < n___> So I'm not really in problem solving mode yet lol.
22:21 < Mathuin> Okay, decided to go with the official names on the gamepedia page, minus the minecraft:
22:21 < Mathuin> And I'll need a setter to tweak the data value for some of these things.
22:23 < Mathuin> Those are just block IDs, though, not block-and-data.
22:24 < Mathuin> Argh!  :-)
22:46 < Paprikachu> is Dinnerbone ever online here?
22:47 < redstonehelper> only when you're not looking
22:47 < Paprikachu> ^
22:47 < Paprikachu> ive had this idea on how to optimize world loading and storage to only use a fraction of the current amount
22:48 < Paprikachu> of data
22:48 < Paprikachu> i think it should be implemented in minecraft :P
22:49 < redstonehelper> /r/minecraftsuggestions, lol
22:49 < Paprikachu> didnt know that existed
22:49 < Paprikachu> does he check that regularly?
22:50 < redstonehelper> I think so
22:50 < redstonehelper> when they have some time they look through there, sometimes implementing stuff like that
22:50 < Paprikachu> i see, sounds good
22:50 < Paprikachu> i might post it there
22:56 < Mathuin> Sanity check: stained glass panes can be any color that stained glass can be, right?
22:56 < Mathuin> What about hardened clay?
22:57 < redstonehelper> yes and yes
22:57 < redstonehelper> same for wool
22:58 < redstonehelper> stained glass, stained glass panes, hardened clay and wool and carpet all have 16 colors
22:58 < redstonehelper> but, glass and glass panes and hardened clay also exist without color
22:58 < Mathuin> Okay, the gamepedia page on data values doesn't mention hardened clay or stained glass panes.
22:59 < Mathuin> The zero value for glass, glass panes, and hardened clay are the default, right?
22:59 < redstonehelper> no, they are separate blocks
22:59 < Mathuin> glass and stained glass are different, got it.
22:59 < redstonehelper> yup
23:00 < Mathuin> "red hardened clay" is "hardened clay" with a data value of 14 for "red"?
23:04 < Mathuin> Ah!  "red stained clay" comes from hardened clay.  Okay.
--- Day changed sam. août 09 2014
00:30 < n___> I'm having trouble understanding how I should assemble the Spawn Player packet.
00:31 < n___> specifically, what to write to it after the player name
00:31 < n___> and before XYZ
00:34 < n___> a var int count of data fields (name, value, sig) 3, then 3 strings?
00:40 < Drainedsoul> is this the snapshot or no?
00:43 < n___> huh?
00:43 < Drainedsoul> are you talking about the current protocol, or the pre-release protocol?
00:43 < n___> current stable
00:45 < Drainedsoul> okay so you see how there's "Data" and "Data Count"?  When you query the session server, you get a bunch of properties.
00:45 < Drainedsoul> for each of those properties you send a "Data", and the "Data Count" is how many "Data" objects you're sending
00:46 < n___> ok cool
00:46 < n___> and the session server I'm assuming is the one players validate against? sorry I'm new to MC development.
00:47 < Thinkofdeath> http://wiki.vg/Protocol_Encryption#Server <-- that one
00:47 < n___> okay cool
00:47 < n___> Time to get to reading :D
00:47 < n___> Thanks a bunch guys.
01:27 < n___> when I'm writing the Data object, is that SlotData?
01:34 < Drainedsoul> for Spawn Player?
01:34 < n___> yes, just write 3 strings in a row for each property? or is there a special data type that contains the 3 fields?
01:36 < Drainedsoul> I don't think I really understand your question.  Each property is three strings, yes.  Whether there's "a special data type" or not is up to you
01:36 < n___> ok, I think I got it.
01:44 < Paprikachu> redstonehelper: http://www.reddit.com/r/minecraftsuggestions/comments/2d10wb/optimization_more_compact_worlds_significantly/
02:26 <+Amaranthus> Paprikachu: Is this your idea?
02:29 < Paprikachu> Amaranth, yes
02:29 <+Amaranth> You really think running chunk generation over again every time we load the chunk is better than the current system?
02:30 <+Amaranth> Worse than that, you have to modify your functions and try to find an optimal representation after every change to the world
02:30 < Paprikachu> no
02:31 < Paprikachu> if a player adds a block, you just add a SetBlock to the list
02:31 <+Amaranth> So now you're storing the history of every edit. This approach no longer has any benefit for disk space, memory usage, bandwidth, or CPU usage
02:32 < Paprikachu> also, you could cache chunks since you have an exact timeline
02:32 < Paprikachu> yes it does
02:32 < Paprikachu> plus you can probably collapse it if you dont care about a full history
02:36 <+Amaranth> If I dig out every block in a chunk not only do you store the functions to generate it originally you have to store a ton of SetBlock functions
02:36 <+Amaranth> Or do some kind of optimization (ie compression) pass
02:36 < Paprikachu> you could certainly do tht
02:36 < Paprikachu> that
02:38 <+Amaranth> Paprikachu: My solution was to make chunk compression not be on the main thread :)
02:38 < Paprikachu> that only works to some degree
02:39 < Paprikachu> if too many people join, you will run out of cpu to use
02:39 <+Amaranth> We also have an in-memory optimization that could be applied to disk and network if Minecraft used it
02:39 < Paprikachu> what kind of optimization?
02:39 <+Amaranth> If one of the arrays is uniform we store the value once and don't have an array
02:39 < Paprikachu> eh?
02:40 < Paprikachu> oh
02:40 <+Amaranth> If every block is air we don't store a byte[4096] of zeros we store a single zero
02:40 < Paprikachu> that works i guess
02:40 <+Amaranth> Same with the data, block light, and sun light nibble arrays
02:41 < Paprikachu> who is "we" btw?
02:41 <+Amaranth> CraftBukkit
02:41 < Paprikachu> ah
02:43 <+Amaranth> I also had something fancier but it only saves a little more RAM in normal usage but is more complicated and has a worst case that uses more RAM
02:43 < Paprikachu> in my previous server i stored the compressed difference to the original chunk on disk
02:44 < Paprikachu> that saved a lot of space
02:44 <+Amaranth> Eh, that's terribly inflexible
02:44 < Paprikachu> it's mainly a bunch of zeroes
02:44 < Paprikachu> can be compressed extremely well
02:45 < Mathuin> Sea level is 62, correct?  Does that mean that the block at (x, 62, z) is air or water?
02:45 <+Amaranth> My fancier approach was a palette/index system. Every unique block (combo of id, ext id, data, blight, and slight) went into to the palette and then you have a 4096 array of indices
02:45 < Mathuin> (assuming the point is at/over an ocean.
02:45 <+Amaranth> You don't get much more out of compressing such a structure, it's already fairly compact
02:46 < Paprikachu> i remember thinking about palette systems, but i scratched that idea
02:46 <+Amaranth> But the system CraftBukkit uses now cuts about 50% off chunk data memory usage while that system cuts 60% off
02:47 <+Amaranth> But it made reads O(1) but twice the work and writes O(n) where n is the number of entries in the palette
02:47 < Paprikachu> whats so inflexible about the diff approach though?
02:47 <+Amaranth> If you change the chunk generation
02:48 < Paprikachu> well, it requires the chunk generator to be present
02:48 < Paprikachu> but then again, i wouldn't ship chunk generators with minecraft anyways
02:48 < Paprikachu> i would seperate them into loadable objects
02:49 <+Amaranth> The only way to make that safe to ship to clients basically ends up with your proposed system
02:49 < Paprikachu> yeah
02:51 <+Amaranth> Having functions for octaves I figure would be too slow but the simple regions might actually be fast enough
02:51 <+Amaranth> But you're trading CPU for disk still, unless the CPU time used is less than it would take to do the compression
02:52 <+Amaranth> Your SetBlock function for storing the diff would be rather large though, since it would have to store the coordinates too
02:53 <+Amaranth> 5 bytes assuming you could fit the function type into 4 bits
02:53 < Paprikachu> uh?
02:54 <+Amaranth> You need to store xyz plus the 3 bytes of block information
02:54 < Paprikachu> when i said storing the difference
02:54 < Paprikachu> i meant an array the same size of the chunk data
02:54 < Paprikachu> so that coords arent needed
02:54 < Paprikachu> to a element-wise -, then run it through compression
02:54 < Paprikachu> *do
02:55 <+Amaranth> So you're not doing anything to reduce the amount of memory chunks use, in fact you're doubling it
02:55 <+Amaranth> Unless you regenerate the diff at save time by generating a fresh copy of the chunk from the functions
02:55 < Paprikachu> i think you are confusing 2 things here
02:55 < Paprikachu> the function approach vs the diff approach
02:56 < Paprikachu> they have nothing to do with each other
02:56 <+Amaranth> Well, really the function approach ends up being a diff approach
02:56 <+Amaranth> Because you have all the functions for the fresh chunk then a bunch of SetBlock functions to modify it
02:56 <+Amaranth> So I'm trying to optimize the diff
02:56 < Paprikachu> i see
02:57 < Paprikachu> yeah well, you can always try to make a more compact representation of the difference
02:57 < Paprikachu> single setblock functions are of course not exactly ideal
02:58 < Paprikachu> you can possibly collapse multiple connected setblocks into a ranged setblock with a timestamp offset + relative timestamps
02:58 < Paprikachu> that way timestamps only take a few bits
02:58 <+Amaranth> I don't see the point of timestamps
02:59 <+Amaranth> We don't need the ability to watch the changes over time
02:59 <+Amaranth> We need the ability to store it as efficiently as possible on disk, in memory, and on the wire
02:59 <+Amaranth> While still having efficient reads and writes
02:59 <+Amaranth> I suppose we really just need different things for each
02:59 < Paprikachu> timestamps shouldnt affect reading/writing at all
03:00 <+Amaranth> No but they are extra data to save
03:00 < Paprikachu> about the other it depends on what you want. sure if you dont need extra data its overhead.
03:00 <+Amaranth> btw with the function approach how could you handle structures?
03:00 < Paprikachu> well, structures have walls and the like
03:00 < Paprikachu> you could represent them as ranged fills
03:01 < Paprikachu> details with setblock
03:01 <+Amaranth> I suppose the savings from the region fills for the majority of the chunk would make up the difference
03:01 < Paprikachu> i wouldnt go for a single structure function because of version dependency
03:01 <+Amaranth> I wouldn't go for a single structure function because of CPU usage
03:01 < Paprikachu> eh?
03:02 <+Amaranth> For the same reason I'd probably only have 3D regions and setblock as my functions
03:02 < Paprikachu> having 100 primitives vs a single structure function shouldnt make a difference
03:03 <+Amaranth> If you have a structure function (or an octave function) you're spending CPU time calculating what the 3D regions or setblocks are instead of just filling a buffer
03:03 < Paprikachu> why would you need to decompose that function
03:03 <+Amaranth> Not literally generating those other functions
03:04 <+Amaranth> I was just giving an example of how it's extra complexity because its not one of those base operations
03:05 < Paprikachu> i dont really understand
03:05 <+Amaranth> btw if you represented the chunk as a 3D interval tree you'd basically be representing it as 3D regions but reads and writes might be fast enough that you wouldn't even need to populate the normal byte buffers and could just use it directly
03:06 < Paprikachu> i've only heard of interval trees, never implemented or used them :D
03:06 <+Amaranth> I don't even know how to do a 3D one or if what I just said is true, it's just a thought
03:07 <+Amaranth> But as far as the functions what I'm saying is a structure function would have to do the work the normal chunk generation today does to figure out where to place the blocks in the world
03:07 <+Amaranth> While the 3d region and setblock functions are just placing the blocks
03:08 < Paprikachu> oh, i see
03:08 < Paprikachu> is it that significant though?
03:08 < Paprikachu> i would assume that it just uses a rng
03:09 < Paprikachu> the input to that rng can be provided to the structure function
03:09 < Paprikachu> s/input/seed
03:09 <+Amaranth> It can be pretty significant, especially if you have to do it every time you load the chunk on the server and every client would have to do every time it receives it
03:09 <+Amaranth> Villages have to look at the world to try to conform to it, for example
03:10 < Paprikachu> i should prob dig into world generation some more
03:12 < Paprikachu> that's actually something i hadn't thought of when i came up with this idea.
03:12 < Paprikachu> that functions don't have to be pure.
03:12 <+Amaranth> World gen as of beta 1.8 actually got pretty complicated
03:13 <+Amaranth> iirc it doesn't actually use noise directly anymore, it uses something much more expensive that looks like regular noise minus the downsides like floating islands and random tiny holes in the ground (vs long windy caves)
03:14 <+Amaranth> Structure generation also happens as a second pass after normal world gen
03:15 <+Amaranth> And iirc it doesn't detect that some chunk should be the edge of a stronghold when the center chunk of the stronghold loads it realizes one should be there and fills it and the surrounding chunks in with the new structure
03:16 <+Amaranth> So a chunk might not have a structure the first time you see it but gain one an arbitrary period of time later (a few ticks if someone is running that way or never if they stop and never go that way again)
03:17 < Paprikachu> hmm
03:17 < Paprikachu> that shouldnt be a problem either though
03:18 < Paprikachu> not sure how i would handle timestamps though in that case
03:18 <+Amaranth> I'm giving you reasons why you should only have 3d regions and setblock for your functions
03:20 < Paprikachu> i thought of the functions more in terms of world edit support
03:20 < Paprikachu> things like replace, overlay, etc
03:20 < Paprikachu> granted, they wouldn't be of much use in vanilla minecraft
03:21 <+Amaranth> Well if you were willing to have setblock be less efficient you could just have 3d regions and not need to store the function type
03:21 <+Amaranth> Oh yeah, you could only do this for block id/data
03:21 <+Amaranth> Lighting would still need to be separate arrays
03:22 < Paprikachu> why is lighting sent anyways
03:22 < Paprikachu> the client can calculate it itself
03:22 < Paprikachu> and i think it does that too
03:23 <+Amaranth> The initial calculation when a chunk is generated is expensive
03:23 < Paprikachu> i wonder if there would be any advantages to implementing chunk generation in native code
03:24 < lwww> Hey guys, there's something thats been bothering me for a while
03:24 < lwww> I'm writting Yet Another C++ Minecraft Bot With Lua Scripting Suport (YACPPMBLSS)
03:25 < lwww> Is encryption only used if the server is in online-mode?
03:25 < Paprikachu> yes
03:25 <+Amaranth> Java performance losses tend to come from Object overhead and death by a thousand cuts from various things that are less efficient than C/C++. Tight loops reading/writing simple arrays and doing basic math on them are what the JIT is good at optimizing
03:25 <+Amaranth> I doubt you'd see much improvement from native code
03:25 < lwww> Thanks, Paprikachu.
03:26 < lwww> I guess I wont have to bother with NaCl for a while. Haha
03:26 < Paprikachu> Amaranth: but c++ gives you guarantees that are important for performance, i.e. arrays being linear in memory.
03:27 < Paprikachu> and no bounds checks
03:27 <+Amaranth> I believe you can count on an array of primitives being linear
03:28 <+Amaranth> And if you write for(int i = 0; i < data.length; i++) { /* do something with data[i] */ } I'm pretty sure the bounds check will be removed, at least in a hot loop
03:28 < Paprikachu> and then theres all the checks for sections existing
03:29 < Paprikachu> afaik, chunk sections are created lazily?
03:29 <+Amaranth> Yeah
03:29 <+Amaranth> And that's a place that's less than ideal, iirc Minecraft worldgen works on the World class
03:30 <+Amaranth> Which means every call to read/write a block involves checking if a chunk is loaded, getting it, then checking if the section in the chunk is loaded, then getting the data from it
03:30 < Paprikachu> yeah
03:30 < Paprikachu> you'd need some kind of range adapter
03:31 < Paprikachu> that checks on creation and then provides unchecked access
03:31 <+Amaranth> The way the Bukkit API works is having you fill in arrays which we then create sections out of
03:32 <+Amaranth> Reading during worldgen is actually really dangerous too
03:32 < Paprikachu> because of threading?
03:33 <+Amaranth> No because you might trigger infinite recursion
03:33 < Paprikachu> huh?
03:34 <+Amaranth> If you're generating a chunk it doesn't exist yet. If the generator accidentally loads a nearby chunk you'll generate another chunk and if your generation is buggy there too...
03:34 <+Amaranth> You might generate the same two chunks back and forth
03:34 <+Amaranth> Or just an infinite line of chunks
03:35 < Paprikachu> mh
03:35 < Paprikachu> makes sense
03:38 < Paprikachu> seems like theres a lot of subbtle things to be careful about with chunk generation
03:46 <+Amaranth> lwww: You might be better off with http://www.cryptopp.com/ instead of NaCl
03:47 < lwww> Yeah, actually NaCl was the first thing that came into my mind when I wrote that line. Anything but OpenSSL (what a shame) is fine by me.
03:48 < Paprikachu> whats wrong with OpenSSL
03:48 <+Amaranth> lwww: NaCl doesn't have the crypto algorithms you'd need
03:48 <+Amaranth> OpenSSL is ugly to use, large, and of these days worrisome
03:48 < lwww> Amaranth, well, out of the list, I guess. I'll give it a try after making some progress with it
03:49 < lwww> Thanks
03:49 < Paprikachu> boost ftw =)
03:49 < lwww> Oh god let's not turn this in another boost discussion
03:49 < lwww> I'll pretend you never said that
03:49 < Paprikachu> whats wrong with boost :P
03:49 <+Amaranth> But OpenSSL is the industry standard still. NSS is the alternative industry standard but is old school 90s shit C++ and used as proof that security code is never readable code
03:50 <+Amaranth> boost has an encryption library?
03:50 < Paprikachu> boost asio has a ssl wrapper
03:50 < Paprikachu> for open sll
03:50 <+Amaranth> Minecraft doesn't use SSL
03:50 < Paprikachu> ssl
03:50 < Paprikachu> mh
03:50 < Paprikachu> right
03:50 < Paprikachu> brain fart
03:51 < lwww> "Too much bloat" and "doesn't follow UNIX filosofy", but this is coming from a 4k intro programmer , so don't worry.
03:51 < lwww> Paprikachu
03:51 < Paprikachu> :P
03:52 < lwww> I just can't get out of that "every bit counts" thinking. I can't even belive I'm allowing myself to use C++, btw
03:52 < Paprikachu> well, c++ is the only sane language ;D
03:54 <+Amaranth> Paprikachu: That's a scary thought
03:54 < Paprikachu> well, c++ isn't perfect either, but it's by far the best
03:55 <+Amaranth> You should learn Rust
03:55 < Paprikachu> that's on my todo list
04:02 <+AndrewPH> no man php is the best
04:03 < Paprikachu> ^
04:11 < lwww> How should I call a class that reads and write data to a buffer? Like: buffer.readInt(); buffer.readByte() etc?
04:11 < lwww> StreamBuffer?
04:11 < Paprikachu> (de)serializer?
04:11 < lwww> Also valid, but what if it does both?
04:12 < Paprikachu> just serializer
04:12 < lwww> Serializes and deserializes?
04:12 < lwww> Can't stand naming stuff. I'll go with Serializer. Thanks, Paprikachu.
04:39 < Drainedsoul> Paprikachu: What ISN'T wrong with OpenSSL?
04:40 < Paprikachu> Drainedsoul: idk, i dont use it directly.
04:40 < Paprikachu> boost asio has a ssl wrapper around open ssl so im using that
04:42 < Drainedsoul> Amaranth: What's insane about C++?
04:42 < Drainedsoul> Paprikachu: I wish I'd never interacted directly with OpenSSL.  It's painful.
04:43 < Drainedsoul> although now I find the whole LibreSSL thing much more amusing, having experienced OpenSSL's shittiness first-hand
04:44 < Paprikachu> im glad ive never used it directly then :)
04:46 < Drainedsoul> lwww: How can you hate boost but not hate the C++ standard library?  I mean large swatches of the C++ standard library were lifted -- almost verbatim -- from boost. O_o
04:46 < Drainedsoul> *swathes
04:46 < lwww> I just don't use iostream, Drainedsoul. The rest is "ok".
04:47 < Drainedsoul> don't use iostream from the standard library, or from boost?
04:47 < lwww> Literally <iostream>
04:47 < Drainedsoul> wat
04:47 < Drainedsoul> you said you DON'T use iostream
04:48 < lwww> And I don't use
04:48 < Drainedsoul> what do you use instead?
04:48 < lwww> Pure classic printf
04:48 < Drainedsoul> lol
04:48 < Paprikachu> i'd use printf if it wasn't... printf
04:48 < Drainedsoul> so you're so worried about speed printing to the console (lol), that you use unsafe printf?
04:49 < Paprikachu> printf looks a lot better
04:49 < Drainedsoul> the idea of being worried about the speed of printing the console, or any intrinsically blocking IO, is laughable
04:49 < lwww> No, I'm worried about my code bloat.
04:49 < Paprikachu> iostreams are ugly
04:49 < Drainedsoul> how are iostreams ugly
04:49 < Paprikachu> <<
04:49 < Paprikachu> >>
04:49 < Drainedsoul> the alternative that isn't that "ugly" is...?
04:49 < Paprikachu> a function call
04:49 < Drainedsoul> << and >> are function calls
04:49 < Drainedsoul> next
04:49 < Paprikachu> they are operators
04:50 < Drainedsoul> they are overloaded operators, which are function calls
04:50 < Paprikachu> great, they are syntactically still not function calls
04:50 < Drainedsoul> neither is a function call LOL
04:50 < Drainedsoul> operator ()
04:50 < Drainedsoul> next
04:50 < Paprikachu> eh
04:50 < Paprikachu> you know what i mean...
04:50 < lwww> iostream creates some global variables (cout itself, as a class) that abuse STL
04:50 < Drainedsoul> does your chagrin for operator overloading prevent you from using functors including lambda expressions
04:51 < lwww> This, not mentioning the unecessary includes, makes iostream unpratical if you care about your executable size.
04:51 < Paprikachu> << and >> are just a bad idea.
04:51 < lwww> ^
04:51 < lwww> this
04:51 < Paprikachu> try formatting in a language independent way with iostreams
04:51 < lwww> Unecessary syntatic sugar
04:51 < Drainedsoul> why are they "just a bad idea".  Things aren't "just bad ideas", they're bad ideas for a reason.  operator << and >> give you terse, type safe, I/O
04:51 < Drainedsoul> what's the alternative
04:51 < Paprikachu> a type safe function call
04:52 < Drainedsoul> which is now excessively verbose
04:52 < Paprikachu> not really
04:52 < Drainedsoul> lwww: Unnecessary includes do NOT increase your executable size.
04:52 < lwww> They do if they are used
04:52 < Drainedsoul> includes just feed information into the compiler.  The compiler is NOT obligated to actually generate code.
04:52 < Paprikachu> safePrintf("% + % = 
04:52 < Paprikachu> oosp
04:52 < Paprikachu> oops
04:52 < Paprikachu> safePrintf("% + % = %", a, b, sum);
04:52 < Drainedsoul> so your issue with iostream is that it generates code to do things?
04:52 < lwww> Which is the case, Drainedsoul. They are used by global objects.
04:53 < Paprikachu> that's very readable
04:53 < Drainedsoul> It also involves string parsing.
04:53 < Paprikachu> and language independent
04:53 < Paprikachu> and strings are externalizable
04:53 < Paprikachu> and its type sae
04:53 < Paprikachu> safe
04:53 < Paprikachu> #next
04:53 < Drainedsoul> sure and if those are the issues you're trying to address, you can go ahead and do it.
04:53 < Drainedsoul> iostreams provide I/O, NOT internationalization
04:53 < Drainedsoul> so your compliant is that iostreams fulfill their function, not random other purposes?
04:53 < lwww> The problem is: it doens't matter if you use cout or anything like that, it will still create our global objects and, therefore, include.
04:54 < Drainedsoul> then don't include iostream unless you're going to use it
04:54 < Drainedsoul> how is this an issue
04:54 < Paprikachu> << is still a pita to use
04:54 < lwww> Finally we got somewhere.
04:54 < Drainedsoul> how is it "a pita to use"?
04:54 < Paprikachu> because it requires me to reorder my code
04:54 < Paprikachu> when i want to change the output
04:54 < lwww> "then don't include iostream unless you're going to use it"
04:54 < lwww> I won't use it. printf is ok
04:54 < Drainedsoul> yeah, but that's different from just NOT using iostream
04:54 < lwww> See? We solved another problem.
04:54 < Drainedsoul> printf is far from okay
04:54 < Paprikachu> with printf style i just change my string.
04:54 < Drainedsoul> printf is not type safe
04:54 < lwww> Guess what, Drainedsoul
04:54 < lwww> memory isn't safe by itself
04:55 < Paprikachu> you keep mentioning type safety like it was a problem
04:55 < Drainedsoul> type safety allows you to reason about what your program does
04:55 < Paprikachu> maybe you can imagine other printfs than standard printf?
04:56 < Drainedsoul> I can imagine functions similar to printf, yes.  I've written ones myself when I needed to solve the problem of externalizing template strings.
04:56 < Drainedsoul> but that's not the problem that iostreams solve
04:56 < Paprikachu> then what problems do they solve? being a useful piece of crap?
04:56 < Paprikachu> *useless
04:56 < Drainedsoul> as the name suggests, they solve the problem of I/O
04:56 < lwww> I see no problem, really
04:56 < lwww> Nothing to be solved, except the ENTERPRISE mentality
04:57 < Drainedsoul> umm, what?
04:57 < Paprikachu> iostreams are a very unintuitive api
04:57 < Paprikachu> not only << and >>
04:57 < Paprikachu> ever tried to implement your own socket stream for example?
04:57 < Drainedsoul> no because when I work with sockets I'm not usually trying to perform formatted I/O
04:58 < Drainedsoul> I just want to move bytes back-and-forth
04:58 < Drainedsoul> more importantly, when I work with sockets, I don't want to block
04:58 < Paprikachu> iostreams also support that.
04:58 < Paprikachu> and socket streams are useful for prototyping.
04:59 < lwww> C++ is totally fine, the only problem is template abuse.
04:59 < Drainedsoul> how is template abuse a problem
04:59 < Drainedsoul> and what do you mean by "template abuse"
04:59 < Drainedsoul> templates allow you to write highly reusable pieces of code.  Are you saying DRY is a problem?
04:59 < lwww> Well, we, again, get in a portability issue.
05:00 < Drainedsoul> how are templates a portability issue.  They're part of standard C++
05:00 < lwww> You got me there.
05:00 < Paprikachu> people writing code for MSVC are a portability issue
05:00 < Drainedsoul> ^
05:01 < lwww> I guess I just don't like seeing my exectable going over 64k for printing messages.
05:02 < lwww> just for*
05:02 < Drainedsoul> why does it matter.  Is 64K the bottleneck?
05:03 < Drainedsoul> I find it difficult to believe that executable size is a bottleneck.  Unless the code that's being bloated is being executed in a tight loop and leading to instruction cache misses.  But that has less to do with overall executable size, and more to do with local code structure.
05:04 < lwww> Again, I code 4k demos.
05:04 < lwww> No files, except a single 4k executable.
05:05 < lwww> But yes, you are right. For other cases its perfectly fine.
05:05 < Drainedsoul> that sounds like code golf to me.  I.e. useless in every case except as novelty.
05:06 < lwww> You don't know the scene.
05:06 < lwww> Think 4k is little?
05:06 < lwww> Why not 1k, or even 512b
05:06 < lwww> https://www.youtube.com/watch?v=qQNIKOD6WnY
05:07 < Drainedsoul> I think that, except in extreme cases, code size is irrelevant, and shouldn't be the prime driver behind a decision
05:08 < lwww> We kinda do the opossite. Not because we aren't smart, but it's a way to push yourself into making the best in the smallest possible space.
05:08 < lwww> Check out: scene.net
05:08 < lwww> All the image and sound in that video are procedually generated by the executable.
05:09 < lwww> 1k.
05:13 <+Amaranth> lwww: btw, memory is safe, just not in C++ :P
05:14 < Paprikachu> define safe
05:14 < Paprikachu> :P
05:15 <+Amaranth> No illegal access, no use after free, no buffer overflow, etc
05:15 <+Amaranth> Safe
05:15 < lwww> type safe, Amaranth.
05:15 < Paprikachu> weird, i never have "use after free" errors or buffer overflows
05:15 < Drainedsoul> that's not a problem constrained to C++.  Other languages don't solve the problem so much as they mask it by just barring you from using it directly.
05:15 < lwww> ^
05:16 <+Amaranth> Java solves the problem by controlling memory for you, Rust solves the problem via the type system
05:16 < lwww> it's a way of saying: there is no "type safetyness (is that even a word?!) when you handle low-level"
05:16 < Paprikachu> java leaks resources all over the place :P
05:16 < Drainedsoul> C++ solves the problem through the type system also.  Or were you unaware of std::vector, std::unique_ptr, std::shared_ptr, et cetera
05:16 <+Amaranth> btw printf is type safe in gcc and clang at least, they know what printf is, parse the format string, and complain if you do something wrong
05:17 <+Amaranth> Drainedsoul: You have to do extra things to make the type system keep you safe
05:17 < Drainedsoul> Define "extra things"
05:17 <+Amaranth> You have to use unique_ptr
05:18 < Paprikachu> T* -> unique_ptr<T>
05:18 < Paprikachu> what a struggle :P
05:18 < Drainedsoul> yeah, it's not as though you weren't instantiating the object anyway
05:18 < Drainedsoul> I think if you compare the keystrokes, auto ptr=std::make_unique<Widget>() and auto ptr=new Widget;/delete Widget; come out about the same
05:18 < Drainedsoul> and that's assuming you only need one delete
05:19 < Paprikachu> ^
05:19 <+Amaranth> Drainedsoul: Why am I allocating though? That's inefficient
05:19 < Drainedsoul> sometimes you do need the free store
05:20 < Drainedsoul> Although if your complaint is about unnecessary allocations, you hardly want to be citing Java...
05:21 <+Amaranth> Heh, my ideal looks more like Rust :P
05:21 <+Amaranth> But Java was an example of the language that is memory safe
05:21 <+Amaranth> Although Java does nothing to protect you from data races
05:21 < Paprikachu> does rust have something like reinterpret_cast?
05:21 <+Amaranth> std::transmute, it's unsafe code
05:21 < Paprikachu> what does that mean
05:22 <+Amaranth> You can mark a block as unsafe which turns off all the safety features
05:22 < Paprikachu> mh
05:22 <+Amaranth> For low level things and things not expressible (or not easily expressible) otherwise
05:22 < Paprikachu> does rust have const_cast?
05:22 <+Amaranth> But these areas are clearly marked in your code and you can give them extra attention to ensure you're doing all the right things
05:23 < Drainedsoul> why would you want a language to have const_cast
05:23 <+Amaranth> No, also things are const by default
05:23 < Paprikachu> because it's useful at times.
05:23 < Drainedsoul> const_cast is a gaping wound on C++, a hack because millions of C APIs aren't const correct
05:23 < Drainedsoul> "millions" being an exaggeration, of course
05:23 < Drainedsoul> it's also poorly named
05:23 < Drainedsoul> it should be cv_cast
05:23 < Paprikachu> whatever
05:24 < Paprikachu> having an escape hatch is always good
05:24 < Drainedsoul> even if the escape hatch can easily lead to UB
05:24 <+Amaranth> As far as I'm aware Rust is the only language that gives you memory safety without a GC. Although it doesn't yet guarantee it, there was work on a formal proof but the language was changing too rapidly at the time to be worth finishing
05:24 < Paprikachu> + it can be used to implement non const member functions through const ones
05:24 < Drainedsoul> and allows you to violate your contract with your caller
05:24 < Drainedsoul> if you have to implement non-const member functions through const ones
05:25 < Drainedsoul> use the mutable keyword
05:25 < Paprikachu> so because it can be misused, its a bad feature?
05:25 < Paprikachu> is operator overloading bad because people could add houses?
05:25 < Drainedsoul> I didn't say it was a bad feature.  It's specifically necessary for a wide category of C interop.  If C++ didn't have C interop as a feature, const_cast would be a bad feature.
05:25 < Drainedsoul> It's also poorly named.  Like std::iota.
05:26 <+Amaranth> iirc std::transmute is just a general type system fuckery escape hatch
05:26 < Paprikachu> const_cast isnt that bad of a name
05:26 <+Amaranth> I believe it does const_cast too
05:26 < Paprikachu> sure, cv_cast would be better, but whatever
05:26 < Paprikachu> i agree on std::iota though
05:26 < Paprikachu> whenever i see iota, i'm like: "what the fuck is iota?"
05:26 <+Amaranth> I don't care one iota about what you think about it ;)
05:26 < Drainedsoul> it's also super useful for a lot of things, which I guess compounds that problem
05:27 < Paprikachu> std::move and std::forward are also bad names btw
05:28 < Drainedsoul> well, what's the alternative name to std::move, that captures the INTENT as well, but is as terse?  Given that you use std::move quite a bit in modern C++.
05:28 <+Amaranth> T&& is a weird type, I'm not sure you could come up with a good name for them
05:28 < Drainedsoul> I don't see what's poorly named about std::forward
05:28 < Paprikachu> rvalue_cast
05:28 <+Amaranth> std::move is really just "try to cast to T&&" but T&& isn't rvalue
05:28 < Drainedsoul> which is more than twice as long, and doesn't capture the usual intent as well
05:28 < Paprikachu> fine, xvalue_cast
05:28 < Paprikachu> mister pedantic
05:28 < Drainedsoul> std::move doesn't try to cast to T&&
05:29 < Drainedsoul> it casts to typename std::remove_reference<T>::type &&
05:29 < Paprikachu> std::move is static_cast<T&&>
05:29 < Paprikachu> with a little bit of template dust around it
05:29 <+Amaranth> Oh, did I mix up move and forward? I don't have a lot of experience with C++11 stuff
05:29 <+Amaranth> I read about it and such but I haven't done any C++ stuff since 2011 actually
05:30 < Drainedsoul> I believe std::forward is static_cast<T &&>, but I'd have to consult the standard to be 100% sure about that
05:30 < Paprikachu> forward is conditional
05:30 < Drainedsoul> if move cast to T &&, it could return lvalues
05:30 <+Amaranth> http://isocpp.org/blog/2012/11/universal-references-in-c11-scott-meyers is what I was thinking of
05:30 < Drainedsoul> ...which would defeat the purpose
05:30 < Paprikachu> forward is a conditional std::move
05:30 < Paprikachu> it only std::moves for things that were initially rvalues
05:31 < Paprikachu> i.e. things that were captured by reference collapsing resulting an an rvalue reference
05:31 < Paprikachu> *in
05:31 < Drainedsoul> don't confuse "rvalues" and "rvalue references", they're different things...
05:31 < Paprikachu> im not
05:32 < Drainedsoul> does Rust have generic programming?
05:33 <+Amaranth> Rust has monomorphic traits, hygienic macros, and iirc some sort of compiler plugin super macro I haven't explored much
05:33 < Paprikachu> you have a function template taking T&&. if the argument passed to the function is an rvalue of type U, T is deduced to be U. in this case forward applies std::move because it was initially an rvalue and is not an lvalue.
05:33 < Paprikachu> s/not/now
05:33 < Drainedsoul> is T deduced to U or U &&?
05:33 < Paprikachu> U
05:33 < Drainedsoul> either way refererence collapsing makes it U &&
05:34 < Paprikachu> yeah
05:34 <+Amaranth> So basically rust can do HashMap<K, V> and it generates multiple copies of the HashMap code for each K,V pair you use, just like C++
05:34 <+Amaranth> It doesn't have specialization though so you couldn't do std::vector<bool>
05:34 < Drainedsoul> :(
05:34 < Drainedsoul> but specialization allows for <type_traits>
05:34 < Drainedsoul> :(
05:35 < Paprikachu> now if the argument is an lvalue, T is deduced to be U&. reference collapsing turns U& && into U&. forward is passed a U& and just returns the argument unchanged.
05:35 <+Amaranth> Rust already has them
05:35 <+Amaranth> impl<K: Hash + Eq, V> HashMap<K, V, RandomSipHasher>
05:35 <+Amaranth> So your K type has to implement the Hash and Eq traits
05:36 < Drainedsoul> but your K type has to implement them, you can't just snap them onto some arbitrary K type that doesn't provide them, like you can with std::hash?
05:36 < Drainedsoul> Paprikachu: I think in all cases, std::forward actually just returns static_cast<T &&> though
05:36 <+Amaranth> You can only implement traits for types defined in your crate, iirc
05:37 < Paprikachu> nope
05:37 <+Amaranth> Or was it in your module, one of those
05:37 <+Amaranth> So you can't implement Hash for something that doesn't have it, you'd have to make a newtype wrapper and implement Hash on that
05:38 < Drainedsoul> Paprikachu: How so?  static_cast<T &&> is U & && == U & if T is U &, and is U && if T is U
05:38 < Paprikachu> forward has 2 template arguments
05:39 < Drainedsoul> no it doesn't
05:39 < Paprikachu> it should, let me look it up
05:39 < Drainedsoul> http://en.cppreference.com/w/cpp/utility/forward
05:40 < Paprikachu> mh, that works too
05:41 < Paprikachu> interesting, i never thought about it this way
05:46 <+Amaranth> The other thing Rust can't do that makes me sad is things like std::array<Foo, 10>. Forget what that's called though
05:46 <+Amaranth> The 10 bit, I mean
05:47 < Drainedsoul> non type template parameters?
05:47 <+Amaranth> That particular thing is built in to the language though, [T,..10]
05:47 <+Amaranth> Drainedsoul: Yeah but there is some fancy term for it
05:48 < Drainedsoul> cppreference just calls them "Template non-type arguments"
06:06 < lwww> How bad is it to write: "int ret = *((int*)&m_pBuffer[m_bufferIndex]);" ?
06:08 < lwww> Here is a simple comparison: http://pastebin.com/4PcGm9DP
06:08 < lwww> Ignore the last two lines.
06:08 < lwww> Both works fine
06:09 < lwww> The only problem in doing number 1 is because I will have to hardcode it for 3 types (short, int and long long)
06:09 < lwww> There is a buffer size check before them, so no overflow problem.
06:10 < Paprikachu> the latter is UB
06:11 < lwww> UB?
06:11 < Paprikachu> undefined behaviour
06:12 < lwww> What about just memcpy it?
06:12 < Drainedsoul> I thought you programmed C++
06:13 < lwww> I prefer C
06:13 < Paprikachu> if you memcpy it it's fine
06:13 < Paprikachu> theres nothing wrong with memcpy
06:13 < Drainedsoul> what types are in m_pBuffer?
06:14 < lwww> uint8_t (unsigned char)
06:14 < Drainedsoul> where's the UB then?
06:15 < Paprikachu> reading through that casted pointer.
06:15 < Paprikachu> 1) the buffer is not necessarly properly aligned 2) aliasing
06:15 < Drainedsoul> char * can alias anything
06:16 < Paprikachu> but not int*.
06:16 < Paprikachu> you can read anything through a char*, but you cant read anything through an int*.
06:18 < lwww> So even memcpy(&ret, m_pBuffer + m_bufferIndex, 4) is better? It's kinda strange, since I'm using more operations to do the same thing
06:18 < Drainedsoul> sure, but notwithstanding alignment problems, I don't think there'd be an issue since the compiler can't make assumptions since the pointer is coming from char *, which, like void *, could be aliasing integers anyway
06:18 < Drainedsoul> memcpy is more expressive, though
06:18 < Drainedsoul> how is that "more operations"?
06:19 < lwww> memcpy is a while loop as far as I know
06:19 < Drainedsoul> lol
06:19 < Paprikachu> what do you mean the pointer is coming from char*? m_pBuffer is an array.
06:19 < Drainedsoul> &m_pBuffer[m_bufferIndex] is char *
06:19 < Paprikachu> nevermind
06:20 < Paprikachu> anyways
06:20 < Drainedsoul> lwww: Do you really think the compiler is that stupid?
06:20 < Paprikachu> the standard says what the standard says
06:20 < Paprikachu> it's not allowed, and compilers will warn you
06:20 < lwww> I have my doubts, Drainedsoul.
06:20 < Drainedsoul> lol
06:20 < lwww> GCC compiled without warnings, Paprikachu.
06:21 < Drainedsoul> lwww: http://stackoverflow.com/a/2685541/1007504
06:22 < Drainedsoul> does C have alignas yet?
06:22 < Paprikachu> lwww, fix your compiler options :P
06:22 < lwww> Pedantic time? Oh god no
06:22 < Drainedsoul> are you doing -Werror -Wall -Wpedantic?
06:23 < lwww> Masochism time, guys. Wait a sec
06:23 < Drainedsoul> if your code emits warnings with -Wall -Wpedantic, it should be considered bad code, nine times out of ten
06:23 < Drainedsoul> more like 99 times out of 100
06:24 < lwww> Good thing it doesn't warn syntaticaly bad code.
06:24 < lwww> It would go crazy if it saw what is done behind WinSock
06:24 < Drainedsoul> somehow I don't think WinSock is compiled with GCC, so I don't think -Wall -Wpedantic applies
06:26 <+Amaranth> I always found it amusing that -Wall doesn't actually turn on all the warnings
06:26 < lwww> What the fuck?
06:26 < lwww> "int ret = *((int*)&m_pBuffer[m_bufferIndex]);" gave no warnings
06:26 <+Amaranth> It's just the warnings that are most likely to be ugly/dangerous/broken code without many false positives
06:27 < lwww> ^ like using "/*" inside a comment?
06:27 <+Amaranth> clang has -Weverything which turns on all of them for real
06:27 < Drainedsoul> well some of the warnings are stupid
06:27 < Drainedsoul> I think -Wshadow is the name
06:27 < lwww> I always copy my headers to comments when I'm writting it's functions in the .cpp. So, instead of removing every comment, I just remove the closing */
06:27 < Drainedsoul> but Linus actually has a rant about that one in particular
06:28 < lwww> -Werror=comment is stupid
06:28 <+Amaranth> And gcc and clang have -Wextra which turns on warnings that are not good enough to be in -Wall yet and will either be removed, promoted to -Wall, or dropped to -Weverything in the future
06:28 < Drainedsoul> https://lkml.org/lkml/2006/11/28/239
06:28 < Drainedsoul> lwww: What are you talking about?
06:29 < lwww> Compile with this: /* /* */
06:29 < lwww> error: "/*" within comment [-Werror=comment]
06:29 < lwww> Awesome!
06:29 < Drainedsoul> oh, yeah, I never understood that one
06:29 < Drainedsoul> I mean I can kind of see where it's coming from, but unless there's an orphaned */ in the code, I don't really understand it
06:30 < lwww> Exactly.
12:34 < redstonehelper> is there a way to find out which username(s) belongs to a given mojang account, like email@example.com?
12:44 < Drainedsoul> what's the use case for something like that
12:47 < redstonehelper> just wondering if it exists
12:47 < redstonehelper> I don't think it does though
12:49 < Thinkofdeath> To my knowledge it doesn't exist (at least anywhere public)
21:36 < maciekmm> What's playerlist header/footer packet used for?
21:37 < redstonehelper> nothing in the vanilla server
21:37 < maciekmm> redstonehelper so... what's the purpose of that?
21:38 < redstonehelper> for custom servers
21:39 < maciekmm> redstonehelper like what?
21:40 < redstonehelper> some servers use fake players on the tab list to display stuff
21:40 < redstonehelper> or the ender dragon health bar
21:40 < redstonehelper> that kind of stuff could go in the tab list now
21:41 < maciekmm> ahh okay, how that looks like? 
21:41 < redstonehelper> maciekmm: Thinkofdeat*h took this screenshot http://i.imgur.com/aG1aKkc.png 
21:42 < maciekmm> Ohh, that looks cool
--- Day changed dim. août 10 2014
02:06 < MonsieurApple> how do I change my wiki.vg password?
02:23 < dx> MonsieurApple: go to preferences, link to http://wiki.vg/index.php?title=Special:ChangePassword&returnto=Special%3APreferences
02:24 < MonsieurApple> ah, I missed that change password link. thanks
21:43 < LDX> Am I the only one who reads xbone as X Bone
21:43 < redstonehelper> no
21:44 < LDX> Good
21:45 < eddyb> LDX: how else would you read it?
21:45 < redstonehelper> xbox one
21:45 < LDX> ^
21:45 < eddyb> I figured it out like 0.6s before you typed that
21:45 < eddyb> or before I saw your message
21:46 < LDX> I hate it when people call the xBox One the xbone
21:46 < eddyb> that's messed up. xbox1 is better
21:46 < LDX> Yeah
21:46 < eddyb> even though it still looks derpy
21:47 < LDX> I was going to do something but then my battery started dying so by the time i plugged it in i forgot
21:49 < Flemmard> goldfish :P
21:50 < LDX> Dang, whatever it was was important
21:51 < eddyb> LDX: that reminds me there's a fishplayspokemon
21:51 < LDX> Wow
21:52 < LDX> I think it had something to do with my crush based on the level of importance it had in my mind
21:56 < Flemmard> eh i just read something about this fish plays pokemon lol
21:56 < eddyb> LDX: I'd suggest you crush that thought
22:22 < barneygale> got my protocol library working with 1.8 https://github.com/barneygale/quarry
22:24 < LDX> barneygale: Query is spell query. :P
22:24 < LDX> *spelled
22:24 < barneygale> good one
22:24 < LDX> Im serious
22:25 < barneygale> i'm so sorry
22:27 < LDX> http://en.m.wikipedia.org/wiki/Quarry
22:27 < LDX> http://en.m.wikipedia.org/wiki/Query
22:27 < Fenhl> yes.
22:27 < Fenhl> it's a pun
22:27 < Fenhl> or so I assume 
22:31 < barneygale> it's not a pun on "query"
22:31 < barneygale> it's just a project called quarry
22:31 < barneygale> because i try not to name my projects "mcprotocollib" etc
22:39 < HisShadow> yeah, mcprotocollib is pita to write, but quarry just rolls of your keyboard
--- Day changed lun. août 11 2014
12:19 < eddyb> Thinkofdeath: this was pretty easy to update https://gist.github.com/eddyb/97366dd5f6c1b175c200
12:19 < Thinkofdeath> nice
12:19 < eddyb> Thinkofdeath: and the class "detection" grep commands should work for some time
12:19 < eddyb> the methods I used remained identical
12:22 < Drainedsoul> that function looks like it could use some refactoring
12:22 < eddyb> the main method?
12:22 < Drainedsoul> yes
12:22 < eddyb> idgaf, it's a dirty script in my book
12:23 < eddyb> I don't want to bikeshed the design of a script I'd rather not touch often :)
12:23 < Drainedsoul> well maybe the fact that it needs refactoring is why you'd rather not touch it often.
12:23 < eddyb> Drainedsoul: no, I only need to touch it once per snapshot :)
12:23 < eddyb> more like once per week
12:24 < LambdaSix> Not everything needs to be refactored into EnterpriseGrade.
12:25 < Drainedsoul> there's a difference between "EnterpriseGrade" and large functions with nested loops whose purpose is not obvious
12:26 < LambdaSix> It's querying obfuscated code from the minecraft jar that depends on the current obfuscation-flavour-text of the month, then extracting information from it.
12:27 < Drainedsoul> what's your point?
12:27 < eddyb> there's a main loop
12:27 < LambdaSix> By the look of it, it'll need slight rewriting of the 'new cwz' and 'new ctw' statements if the obfuscation names change.
12:27 < LambdaSix> Point is, I don't write java for a living and I can work out what it's doing.
12:28 < eddyb> LambdaSix: all the comments end with a # classname
12:28 < Drainedsoul> I don't think "I can work out what it's doing" is the rubric by which things should be judged.
12:28 < LambdaSix> Drainedsoul: Why wouldn't it be? Understanding code's function is what programmers do.
12:28 < Drainedsoul> I mean I can work out what legacy VBScript classic ASP code that's HTML/JS/CSS/ASP intermingled does
12:28 < Drainedsoul> that doesn't mean it shouldn't have been written better
12:28 < eddyb> LambdaSix: those are all the class names that need updated
12:29 < LambdaSix> eddyb: Yeah, I gathered as much, I'm guessing those will change arbritrarily on snapshots?
12:29 < eddyb> oc, ctq, cwz, atk and cxa
12:29 < eddyb> LambdaSix: yeah. they are close, though
12:29 < LambdaSix> eddyb: At least java has no support for unicode identifiers..
12:29 < eddyb> the obfuscation is not random at all
12:29 < eddyb> compare to https://gist.github.com/eddyb/d619764a364d9b6b59c8
12:30 < LambdaSix> eddyb: C# obfuscaters have a delightful habit of making nonsense class names that aren't made from printable characters, or are in a hard to produce character set.
12:30 < Thinkofdeath> LambdaSix: http://ideone.com/AGaT3L
12:30 < eddyb> oa -> oc, cst -> ctq, cwc -> cwz, atc -> atk, cwd -> cxa
12:30 < Drainedsoul> http://stackoverflow.com/a/1422681/1007504
12:30 < LambdaSix> Thinkofdeath: Haha, fun.
12:30 < eddyb> between 31a and 32d
12:31 < Drainedsoul> LambdaSix: By the way, the fact that Java has ASCII identifiers is sufficient for it to have "unicode identifiers", since ASCII is a proper subset of Unicode
12:31 < eddyb> Drainedsoul: don't be silly, we're talking XID
12:32 < eddyb> or pedantic
12:32 < eddyb> pendantic? fuck cares
12:33 < LambdaSix> Drainedsoul: C would like to have a word about ASCII == Unicode
12:33 < LambdaSix> :|
12:33 < eddyb> haha
12:33 < Drainedsoul> Did I say ASCII is Unicode?
12:33 < Drainedsoul> did you never take your set theory in college?
12:33 < eddyb> LambdaSix: they said "ASCII identifiers"
12:33 < eddyb> be very careful
12:34 < LambdaSix> Drainedsoul: I dunno, did you get the stick removed from your colon?
12:34 < Drainedsoul> Is that relevant?
12:35 < LambdaSix> Aaaanywaaay, if you care so much for refactoring, rewrite the tool for eddyb.
12:36 < eddyb> I don't want them to!
12:36 < eddyb> I want to get back to my Rust code
12:38 < Thinkofdeath> I might be able to help with cleaning it up using the same tool mcprotocol uses
12:38  * Thinkofdeath gets to work
12:43 < eddyb> cleaning what up?
12:43 < eddyb> silly people :P
17:19 < KnownUnown> remember the bread fence!
17:40 < eddyb> Thinkofdeath: I think I'll dump biomes as well :D
17:42 < eddyb>                throw new Error("Biome \"" + var3.ah + "\" is defined as both ID " + ((arf)o.get(var3.ah)).az + " and " + var3.az);
17:42 < eddyb> thanks, devs :P
17:42 < shoghicp> xD
17:42 < eddyb> now I know the name and the ID :D
17:42 < KnownUnown> arf xD
17:42 < KnownUnown> new data type: arf
17:42 < KnownUnown> woof woof!
17:44 < eddyb> who needs burger :P
17:45 <+sadimusi> eddyb: this is actually pretty much how burger 2.0 was supposed to work
17:45 <+sadimusi> only it updated the class names automatically
17:46 < KnownUnown> umm, then what happened to burger 2.0?
17:47 < eddyb> {Cold Taiga M=ase@7e5065a2, Desert=art@460dab4d, Taiga=asn@19a7b6e3
17:47 < KnownUnown> 0.o
17:47 < eddyb> wish I could just write .map(|biome| (biome.x, biome.y))
17:48 <+sadimusi> KnownUnown: not enough time/motivation and also not enough need for it anymore
17:48 < eddyb> stupid Java
17:48 < KnownUnown> ah
17:52 < eddyb> Hell: 8
17:52 < eddyb> Cold Taiga: 30
17:52 < eddyb> Birch Forest M: 155
17:52 < eddyb> that's nice, I just need to put them in an array, and add more properties than just the name
18:17 < morfin> is that python syntax?
18:18 < morfin> or Ruby hmm
18:22 < umby24> ?
18:23 < morfin> i meant that:  <eddyb> wish I could just write .map(|biome| (biome.x, biome.y))
18:25 < Spurlex> http://stackoverflow.com/questions/25247930/java-classnotfoundexception Anyone got any ideas?
18:36 < redstonehelper> eddyb: I think the minecraft wiki has biome/biome id combinations somewhere
18:38 < eddyb> redstonehelper: not machine-ready
18:39 < redstonehelper> k
18:39 < eddyb> morfin: Rust
18:51 < Thinkofdeath> eddyb: Cool, i'm playing around with your block one atm :)
18:52 < Thinkofdeath> trying to reuse parts of the mcprotocol generator for it, not really turning out much nicer :/
18:53 < m0r13> eddyb: does this maybe help? https://github.com/mapcrafter/mapcrafter/blob/master/src/mapcraftercore/renderer/biomes.h#L61
19:14 < Not-9d73> [mc-autodocs] thinkofdeath pushed 3 commits to master [+142/-139/±101] http://git.io/SfvchA
19:14 < Not-9d73> [mc-autodocs] thinkofdeath 839a482 - Base off the client instead of the server
19:14 < Not-9d73> [mc-autodocs] thinkofdeath 1e520d1 - Move into protocol sub-folder
19:14 < Not-9d73> [mc-autodocs] thinkofdeath cebacc7 - [experimental] Provide information about blocks and items
19:15 < Thinkofdeath> eddyb: ^ I tried :P
19:22 < morfin> wait what?
19:22 < Spurlex> http://stackoverflow.com/questions/25247930/java-classnotfoundexception plz halp
19:29 < TkTech> eddyb: The have been more posts claiming the fish just "just died!" then I can count
19:55 <+AndrewPH> TkTech: you gotta listen to me, I'm an expert on fish
19:55 <+AndrewPH> it is actually dead, you can tell because it isn't floating upside-down
19:55 <+AndrewPH> only dead fish float right-side-up
19:55 < TkTech> Oh my god no, oh fishy!
19:55 <+AndrewPH> grayson!
19:59 <+AndrewPH> grayson?! GRAYSON!! (as spoken like 'JAYYYSON')
20:16 < barneygale> Hi guys. I get a "biz cannot be cast to fv" internal exception from the client if I kick immediately after switching to play mode
20:16 < barneygale> anyone else come across this?
20:17 < Thinkofdeath> yep
20:17 < Thinkofdeath> happens to bungeecord all the time
20:17 < Thinkofdeath> its a race condition in the client
20:17 < barneygale> fun
20:18 < Thinkofdeath> I think it got 'fixed' in bungee by delaying the kick for about 500-1000ms
20:18 < shoghicp> hapened to me too :)
20:18 < shoghicp> happened*
20:18 < shoghicp> yeah, that "fix"
20:19 < barneygale> hah that's fun
20:19 < barneygale> is there any better fix?
20:20 < barneygale> I'm assuming not
20:20 < Thinkofdeath> try and get mojang to fix it? :P
20:20 < barneygale> I said "better" :P
20:20 <+Amaranth> Does the vanilla server trigger it with the whitelist or full server kicks?
20:21 < Thinkofdeath> I don't think so
20:21 <+Amaranth> What do they do differently? Wait up to 50ms to get to those points because ticks?
20:21 < barneygale> I suppose they kick before switching to play?
20:21 < barneygale> That would be a bit weird though
20:21 <+Amaranth> I think they switch to play then do further processing on the main thread so you have to wait for the next tick
20:21 < barneygale> It's fixed in the pre-releases anyway, which is nice
20:22 < Thinkofdeath> oh is it? \o/
20:22 < barneygale> I haven't triggered it yet, and I trigger it 100% in 1.7.10
20:23 < Thinkofdeath> Amaranth: hmm they seem to do it before sending LoginSuccess
20:24 <+Amaranth> So they do kick before switching to play then
20:24 < Thinkofdeath> yep
20:24 < Thinkofdeath> same as bungee by the looks of it :/
20:24  * Thinkofdeath shrugs
20:25 <+Amaranth> If you're sending the packets in the same order the move back to the main thread is the only thing I can think of still
20:26 < Thinkofdeath> i'm not sure on the exact details of the issue tbh
20:26 < Thinkofdeath> it could be happening when the server kicks the player not bungee
20:26 < Thinkofdeath> which would explain the race, its a disconnect straight after switching to PLAY
20:26 < barneygale> My issue with kicking beforehand is the client displays "Failed to connect to the server" above the kick text, whereas in play mode it says "Connection Lost". The former is a bit misleading if you're running a website auth server
20:49 < barneygale> Thinkofdeath: any idea where the bungee patch lives? I can't see it
20:50 < barneygale> s/bungee/spigot/
20:50 < barneygale> well, depends how you look at it :P
20:50 < Thinkofdeath> What spigot patch?
20:50 < Thinkofdeath> Do you mean the bungeecord kick delay I was talking about?
20:50 < barneygale> I meant bungee after all. I half-wrote, half-misremembered what you told me earlier
20:50 < barneygale> Yes
20:51 < Thinkofdeath> https://github.com/SpigotMC/BungeeCord/commit/7347daf20302ed426816c52485a9468c9e94af7f
20:51 < barneygale> ta
20:53 < eddyb> m0r13: no, I won't write another C parser :P
20:57 < barneygale> New player list packet sends UUIDs of online players. Does the client use these for anything?
20:58 < Thinkofdeath> it also sends the skin blobs
20:58 < Thinkofdeath> which are used
20:59 < Thinkofdeath> the uuid in spawn player is used to match up with the player list packet to get the skin
21:00 < Thinkofdeath> if it can't find the entry the player is invisible
21:32 < morfin> and it's avalible only for online-mode servers..
22:47 <+Amaranth> morfin: Skins were the original benefit of paying for an account (back in classic) so it makes sense they'd only work for online mode. It just didn't take any work before to have them work in general.
22:48 <+Amaranth> tldr stop stealing my skin yo
22:50 < Thinkofdeath> Amaranth: Stealing skins? Never! http://i.imgur.com/MaFwISf.png
22:53 < TkTech> Pretty much every skin on the old skin site was "stoleN"
23:03 < morfin> but
23:04 < morfin> now they're using UUID so no skins for pirates )
23:05 < Thinkofdeath> uuid has nothing to do with it
23:06 < morfin> i thought Minecraft already moved to new skins system
23:07 < barneygale> why can't you pirate skins now?
23:07 < morfin> i am not a pirate 
23:07 < Thinkofdeath> barneygale: well you still can for now, just requires more work on their part
23:07 < morfin> just asking because i heard some changes about names are coming
23:08 < morfin> UUID is just token as i know
23:08 < morfin> received from legit server
23:11 < morfin> i hate Minecraft site
23:11 < morfin> it said sent an email and i got nothing :(
--- Day changed mar. août 12 2014
07:43 <+SirCmpwn> anyone remember a while ago when I asked about beta 1.7.3 servers?
07:43 <+SirCmpwn> does anyone still have a copy?
08:12 < dx> SirCmpwn: copy of what? that craftbukkit?
08:12 <+SirCmpwn> dx: got it, nevermind
08:13 < dx> okay
12:24 < ackpacket> Since the client uses it's private key when validating with minecraft.net and generating a has... does this make a proxy for dissecting packets impossible?
12:25 < ackpacket> If the proxy gives the target server it's own private key, then the server will be looking for something different from minecraft.net than what the client actually produced, right?
12:26 < Thinkofdeath> yep
12:26 < ackpacket> I guess the same thing that protects a maliscious mitm keeps out the white hats too =\
12:27 < ackpacket> So how do people dissect the protocol?  Do they turn off encryption altogether?
12:27 < Thinkofdeath> normally, offline mode doesn't encrypt
12:27 < ackpacket> hmm
12:28 < shoghicp> or you can have the user/password in the proxy, too
12:28 < ackpacket> eesh
12:28 < ackpacket> that's doable though
13:10 < cindy_k> These client tabs are beginning to get a bit silly: http://gyazo.com/3afb17e35c932d2e4059468afef2a4ca
--- Log closed mar. août 12 17:52:15 2014
--- Log opened mar. août 12 17:52:43 2014
17:52 -!- Irssi: #mcdevs: Total of 152 nicks [1 ops, 0 halfops, 10 voices, 141 normal]