12:03 < Flemmard> used to it :)
12:04 < AnotherOne> lol
12:04 < AnotherOne> h4rdc0r3 1337 sk001
12:04 < Flemmard> ?
12:04 < dx> derp
12:05 < Flemmard> no, school that teaches you 'good' uses of things
12:05 < AnotherOne> ur lucky then
12:07 < Flemmard> but i must admit that a good IDE is just awesome compared to a sole editor .. but there isnt much GOOD ide's :P
12:07 < AnotherOne> visual studio?
12:07 < Flemmard> yeah .. must admit that's like the better ide .. but eh
12:07 < AnotherOne> but its built-in web browser sux
12:08 < Flemmard> dunno, if i use VS it's for C++ so no need for web browser lol
12:09 < AnotherOne> sometimes it is useful to open two tabs and switch betweeen them
12:09 < AnotherOne> one for code, other for hints
12:09 < dx> i never bothered with IDEs but i mostly code python so there's not much else IDEs can offer that i don't have vim plugins for already
12:09 < Flemmard> yeah sure
12:09 < AnotherOne> geany?
12:09 < AnotherOne> i love it
12:11 < dx> meh
12:12 < dx> from a quick look at the feature list i can already do everything
12:19 -!- XAMPP-8 [~XAMPP8@199.254.116.104] has joined #mcdevs
12:19 < Grum> < dx> [13:03:08] ...well now we know that grum doesn't care, but that doesn't mean we're going to give up <-- what? :/ ... gosh get that head out of the ground
12:20 < Not-001> [wiki] Edit by Shoghicp to Pocket Edition Program List -> http://tinyurl.com/p7njsqx
12:21 < dx> Grum: you replied to everything we said as "low priority"
12:22 < Grum> which it is?
12:22 < dx> exactly.
12:22 < Grum> i also said i agreed with them being issues?
12:23 < Grum> not sure how that translates to: 'doesnt carae'
12:23 < dx> issues that you can't care about right now
12:23 < Grum> -a; i guess for you the fact that it doesnt get 'fixed' (because its not broken right now) indicates not caring?
12:23 < SinZ> low priority generally means never going to get done
12:24 < eddyb> no, it generally means "low priority"
12:24 < dx> 'not broken'? i guess you mean "not completely dysfunctional to the point of not allowing to start a basic server", but we think it's broken in a different way
12:25 < dx> actually you did agree that it's broken in a different way, in a low-priority way
12:25 < Grum> the protocol is not designed, that is what i call broken
12:25 -!- Calinou [~Calinou@unaffiliated/calinou] has joined #mcdevs
12:25 < Grum> but to fix that (and thus the little side-issue of not having easy-chunkable data) there is a whole ton of work to be done
12:26 -!- umby24|offline [~umby24@cpe-66-69-92-104.satx.res.rr.com] has quit [Ping timeout: 256 seconds]
12:26 < Grum> also its kinda of a non-issue; as it only involves playing a server *or* a client, and that is going to be the least of your probles
12:27 < Grum> you can only make 'transparant' proxies (ones that just hand over data) without having to rip into the server or client
12:27 < dx> http://screencloud.net/v/ljtw this improves the situation for every single person in this channel, breaks as much backwards compatibility as any other packet change, actually helps to improve backwards compatibility in the future, and reduces the processing required by filtering proxies such as bungee
12:27 -!- umby24|offline [~umby24@cpe-66-69-92-104.satx.res.rr.com] has joined #mcdevs
12:30 < Grum> actually this breaks backwards compatibility for every single packet
12:30 < dx> yes
12:30 < Grum> also there are no gains at all from our pov
12:31 < dx> but there are gains in making spawner minecarts and other mapmaker features that sethbling likes
12:31 < Grum> actually, apparently there are, one 'gain' would be able to do something you couldn't do before
12:32 < dx> also note that adding a single field to a single packet also breaks every other packet
12:32 < dx> hm?
12:32 < dx> with this change you could actually hope to have basic interoperability between minor protocol changes
12:34 < Grum> and what would use that?
12:35 < dx> release 1.6.0, notice a bugfix requires changing a single packet, release 1.6.1 and let 1.6.0 clients connect to new servers ignoring a single packet
12:36 < Grum> maybe we dont want to let clients do that? O.o
12:36 < Grum> (which is the reason for protocol-version-changes)
12:37 < dx> i'm pretty sure it's more often about incompatible packet definitions, since, as i said, without this length header, any change breaks the interpretation of the stream from the point a changed packet is received
12:38 < Grum> not really
12:39 < Grum> we even up the protocol if we'd send new types of entities over them
12:39 < Grum> in theory fully compatible, however if you were to receive such a packet you'd crash
12:40 < dx> okay... you don't care about this header for vanilla server <-> vanilla client communication. do you care about us? do you care about bungee, which seems to cover 15% of the active SMP users?
12:41 < dx> is there ANY reason not to do this?
12:41 < dx> the last time i asked last year or so i got as reply that adding a few bytes per packet would be too expensive
12:42 < dx> it's obvious this doesn't matter since >JSON
12:42 < Grum> nah we actually discussed the json impact
12:42 < Grum> we had another solution before
12:42 < Grum> but it was horrible to code
12:42 < Grum> json was a quick fix
12:42 < Grum> and the impact not too severe
12:42 < dx> oh? could you give some details on this discussion and the previous solution?
12:43 < Grum> the issue we were solving was that the server shouldn't need to have all the locales of the client
12:43 <+md_5> if the issue is priority - why not higher more developers?
12:43 < eddyb> *hire
12:43 < Grum> because with resourcepacks we give the ability to add custom languages
12:43 <+md_5> *hire
12:44 <+md_5> then you can have people working on different things, they can rebase periodically with master, and eventually merge with master.
12:44 < eddyb> custom item names?
12:44 < Grum> those people ideally work from stockholm
12:45 <+md_5> you really think there are no java game developers in sweden?
12:45 < Grum> anyhow; the problem is that the server sends localized strings out to the client
12:45 < Grum> which obviously is stupid
12:45 < Grum> but how do you do it properly?
12:45 < Grum> we ended up needing a nested structure of localizations
12:45 < Grum> we realized that the whole chatformatting was also done rather .... stupidly horrific
12:45 < dx> sprintf(field 1 of the packet, ...more fields...) :D
12:45 < eddyb> silly dx
12:45 < dx> wait that's printf
12:46 <+md_5> no... I'm with dx
12:46 < Grum> md_5: i've told carl often enough we need more
12:46 < Grum> and with how dx is doing it there is no trivial way of doing nested structures
12:46 < Grum> obviously we could device a way to send a Map<String, String|Map<String,....>> to the other side
12:47 <+md_5> why do you need nested translations o.O give me an example
12:47 < Grum> but json was a 30 minute implementation that was 1) clean, 2 not horrific
12:47 < dx> i know sprintf-like templates are limited, but do we really need nested structures enough to justify json?
12:47 < Grum> md_5: giving an item to a player?
12:47 <+md_5> so.. you are worried about 30min implementation, but then spend god knows how long on stuff like oculus rift support ?
12:47 < Grum> item, player and the whole sentence are different localizable items
12:48 < Grum> md_5: we spend 0 time on it?
12:48 <+md_5> so then fence them off
12:48 < dx> (remember that json is trendy too!)
12:48 < Grum> 'hence them off' ?
12:48 < Grum> *f
12:48 < Grum> we've played maybe 30 minutes with oculus rift in tf2 O.o
12:48 <+md_5> send an array of String's, each with their own translate data
12:49 < Grum> doesnt nest trivially
12:49 < dx> what's the template used to give an item to a player?
12:49 < Grum> you can make some serializable nestable structure that is smaller than json, obviously
12:49 < Grum> dx: no idea, but problable: "Gave %s to %s"
12:50 < Grum> the first thing i said when nathan said json was 'what about the size'
12:50 < dx> and the first %s needs to be 'translated' twice?
12:50 < Grum> then we decided to just use it as a first implementation, see how bad it would get
12:50 < Grum> (it wasnt too bad)
12:50 < Grum> dx: no? the whole thing is a translation
12:51 < Grum> and the itemname / playername are also translatable items
12:51 < ShaRose> Grum curious, would there be that big a size decrease if you used NBT over json for the chat messages?
12:51 < Grum> nbt is horrible
12:51 < Grum> it has an uttersly shit interface
12:51 < dx> grum already said he won't use NBT because of the implementation
12:51 < Grum> we discarded it right from the bat for that reason
12:51 < ShaRose> fair enough
12:51 < Grum> *of the bat
12:51 < SinZ> Grum: question, why does the server need to know if the client wants to see capes or not?
12:52 < dx> emphasis in implementation and API
12:52 < Grum> SinZ: no idea
12:52 < Grum> dx: both are crap
12:52 < dx> Grum: yes
12:52 < Grum> NBT is highly unfriendly yo use
12:52 < ShaRose> whenever I used nbt I just saw it as a packed KV
12:52 <+md_5> 11 line translation:
12:52 <+md_5> http://paste.md-5.net/dovukopoda.java
12:52 < SinZ> then why does the server get told about the clients setting of ShowCapes
12:52 < Grum> not enough md_5
12:52 < ShaRose> SinZ because the client can turn off his cape for everyone in the server
12:53 <+md_5> I fail to see a use case that doesnt cover Grum, can you provide one?
12:53 < Grum> SinZ: we dont have a 'show capes' setting afaik? O.o
12:53 < Grum> md_5: add more attributes to the text?
12:53 <+md_5> attributes as in color codes?
12:53 < Grum> like color, style, name it
12:53 < dx> fixing § isn't hard
12:53 <+md_5> just use the existing section sign system
12:53 < SinZ> http://wiki.vg/Protocol#Client_Settings_.280xCC.29
12:53 < Grum> links to other things
12:53 < dav1d> I like my NBT implementation, I would even say it's api is cool
12:53 < dav1d> cool like: 8)
12:53 < dx> lol
12:54 <+md_5> you know what
12:54 < Grum> md_5: the section system is horrible
12:54 <+md_5> If I were mojang, screw json
12:54 <+md_5> lets use ObjectOutputStream
12:54 <+md_5> amiright
12:54 < Grum> because of the $r doing a 'fullon clear'
12:54 < SinZ> 0xCC has quite a few settings that server doesn't need to know
12:54 < Grum> so if you want to send a red string, and someone inserts a colored name ... it fucks up
12:54 <+md_5> thats just a matter of fixing the parser
12:54 < dx> object.. output stream? that sounds scary
12:54 < ShaRose> md_5 totally
12:55 < ShaRose> oh oh does java have an xml output stream
12:55 < ShaRose> use that
12:55 <+md_5> you could write a 20 line method to tokenize it back into a format the same as what your json goes to
12:55 < Grum> md_5: errrrm yeah to doing it right with a nested structure
12:55 < eddyb> ShaRose: XML is worse than JSON
12:55 < SinZ> ^
12:55 < ShaRose> the joke
12:55 <+md_5> (for non java programmers)
12:55 < Grum> md_5: and spend 3-4 hours writing unittests for it?
12:55 < dx> Grum: you could just make the § stack
12:55 -!- Yoshi2 [~chatzilla@xdsl-87-78-41-206.netcologne.de] has quit [Ping timeout: 240 seconds]
12:55 < dav1d> I think someone was kidding...
12:55 < ShaRose> went right over your heads didn't it
12:55 < Grum> nah lets not, json is rather proven :P
12:55 < Grum> dx: again not a trivial change
12:55 <+md_5> ObjectOutputstream is a 0 documented, java specific object serialization format
12:55 < Grum> (you havent seen the fucked up font code o.O)
12:55 < ShaRose> object output stream is also bloated output afaik
12:55 <+md_5> as far as I know there is no non java implementation to read produced objects
12:55 < Grum> md_5: also non-standard
12:56 < Grum> far more non-standard than json
12:56 < Grum> so what is really the issue here?
12:56 < eddyb> Grum: if this wasn't Java, it would be trivial to come up with a format similar to JSON but more specialized
12:56 < dx> Grum: can we donate a stacked § parsing library?
12:56 <+md_5> it was a joke, demonstrating that (I) perceive its usefuleness / application to the task to be on the same level as json
12:56  * SinZ looks at the code required to reproduce java-like sha1 hashs
12:56 < Grum> packet too big? we'll run it to zlib.inflate if you care too much
12:56 < ShaRose> eddyb you can do it in java just fine
12:56 <+md_5> eddyb java has no bearing on this
12:56 < dav1d> I only wonder what my client should display when a player joins
12:56 < Grum> dx: nope, we're getting rid of it
12:56 < eddyb> Grum: but you wouldn't be gaining too much out of it
12:57 < eddyb> md_5: java makes it bloated, see his comments above
12:57 < dav1d> Yo sorry dawg I have no translation for it! Using: Dinnerbone
12:57 <+md_5> <Grum> packet too big? we'll run it to zlib.inflate if you care too much          <-- even worse, then we have to add compress/decompress cycles.
12:57 < dav1d> ^ sorry for the highlight db
12:57 < Grum> md_5: then what is the problem?
12:57 <+md_5> eddyb uh no, just the specific serialization I was talking about
12:57 < dx> Grum: you're getting rid of it because it has bugs, and you don't want to fix bugs, and you also don't want other developers to help you fix it bugs. got it
12:57 < dx> *its bugs
12:57 <+md_5> https://gist.github.com/Dinnerbone/5631634
12:57 -!- Yoshi2 [~chatzilla@xdsl-87-78-128-46.netcologne.de] has joined #mcdevs
12:57 < Grum> dx: no we're getting rid of it because its a horrible way of doing things
12:57 <+md_5> I think all our issues are covered there
12:57 < ShaRose> pretty sure Grum said that earlier
12:57 < ShaRose> a few times
12:58 <+md_5> has someone actually benchmarked this json format, I want to see how long it takes to do 250 average sized messages a second
12:58 < dx> Grum: you might not like it, but there's nearly zero processing involved in taking a formatted string from a bukkit plugin config and sending it with a few vars replaced
12:58 < SinZ> heh, someone converted dinnerbros system to WoW UI escape sequences
12:58 < Grum> also seriously, on what server are the amount of outgoing chat-messages THAT high that this is actually ever showing up in ANY profiling?
12:58 < SinZ> https://gist.github.com/NickG365/5647684
12:59 < ShaRose> Grum I always wondered that too
12:59 < dx> Grum: md_5 wrote bungee...
12:59 <+md_5> Grum 2000 player servers spring to mind
12:59 < Grum> we actually considered using the blizzard formatting
12:59 <+md_5> 2000 players produce a lot of chat
12:59 < dav1d> md_5: why do you have to decode every chat message in bungee?
12:59 < eddyb> Grum: hmm, is there any chance of you using a lighter, yet still JSON-based format? or it doesn't itch you to have "translate" in it :P?
12:59 <+md_5> dav1d in case a user sends a command that bungee needs to decode
12:59 < dx> dav1d: i'm guessing inter-server commands
12:59 < Grum> the packets from the client will not be 'encoded' in json o.O
12:59 <+md_5> dav1d and for the API
12:59 < dav1d> oh commands
12:59 < dav1d> right
12:59 < Grum> its just plain text the user can send
12:59 < Grum> nothing more
13:00 < dav1d> omg
13:00 < Grum> anyhow; we actually had the wow-style option stuff as idea first
13:00 < Grum> the problem is, you cannot nest it
13:00 < dav1d> Grum: so two different formats for the same thing?
13:00 <+md_5> doesnt matter, I still have to parse it for the API hooks
13:00 < dav1d> one server->client (json) and client->server (plain?)
13:00 < Grum> not without writing a fully fledged parser for it .... i dont want to waste that time
13:00 <+md_5> (server to client chat)
13:00 < dx> Grum: we can
13:00 <+md_5> if time is such an issue, get people to help. 
13:01 < Grum> dav1d: no? this is 100% purely for server->client messages
13:01 < dav1d> Grum: https://github.com/Dav1dde/BraLa/blob/master/brala/gfx/text.d#L90 this parses a § message
13:01 <+md_5> this channel largely consists of unpaid professionals with a strong interest in Minecraft reverse engineering....
13:01 < eddyb> Grum: could you add optional formatted client->server message? which can be disabled/filtered :D
13:01 < Grum> dx: sure you can, feel free to, but why would we use it? :/
13:01 < dav1d> that is 30 lines of code
13:01 < Grum> eddyb: nope
13:01 <+md_5> dav1d work more on brala, so much potential
13:01 < dx> Grum: because json fucks everyone
13:01 < Grum> why?
13:01 <+md_5> gone a bit stale recently
13:01 < dav1d> yeah :(
13:02 < Grum> nope that code is broken dav1d
13:02 < Grum> wouldn't pass any unittest
13:02 < dav1d> Grum: for what input?
13:02 < eddyb> dav1d: you're kidding me. guess how many lines of code my implementation had?
13:02 < eddyb> dav1d: one
13:02 < Grum> dav1d: invalid input
13:02  * md_5 thinks back to when notch wanted to open source minecraft
13:02 < dav1d> Grum: well I tested it with a few strangly formatted chat lines it worked
13:03 < dx> md_5: his plans of open sourcing when sales went down (lol), or the plan to make a mod api with pseudo open source?
13:03 < Grum> dav1d: try it with the section symbol as the last char on the line
13:03 < Grum> try it with a 
13:03 < Grum> 'l' following it
13:03 < Grum> both instantly break it
13:03 < Grum> the section stuff is just enough for 'single depth complexity'
13:03 <+md_5> Grum again, they can be fixed with minimal effort
13:03 < Grum> we need more than that sadl
13:03 < dx> Grum: also, "why?", what do you think our rants in the gist are for?
13:04 < Grum> dx: for no reason?
13:04 < dx> Grum: got it
13:04 < dav1d> I'll note that down
13:04 < Grum> we're fixing a problem with our solution
13:04 < dav1d> thanks :P
13:04 < Grum> we're not just doing it 'because its funny to use json'
13:04 < Grum> sure we can use another serialization than json
13:04 < ShaRose> to be honest, I also think complaining about json is trivial
13:04 < Grum> but we'll be using json SO MUCH MORE in the future
13:04 < Grum> you better get used to it
13:05 < ShaRose> if you guys want something better, write a binary packed format that's powerful enough for mojang with a nice api and implementation, and give it to them :P
13:05 <+md_5> ShaRose already exists
13:05 <+md_5> bson
13:05  * ShaRose googles
13:05 <+md_5> its basically just NBT but with an actual spec and widly used
13:05 <+md_5> MongoDB uses it
13:05 < eddyb> dav1d: x = x.replace(/\xa7([0-9a-f])([^\xa7]*)/g, function(a, c, t) {return t?'<b style=color:#'+wc.chatColors[c]+'>'+t+'</b>':'';});
13:05 < dav1d> what me upsets is more that the client needs the translation files
13:05 < ShaRose> oooo, sounds neat
13:06 < dav1d> eddyb: yeah I've seen that one :P
13:06 < eddyb> dav1d: where?
13:06 < ShaRose> but them protocol buffers might also work for it in some cases, so
13:06 < dav1d> no idea, but when I implemented the parser I've seen it somewhere
13:06 < SinZ> eddyb: with this json system, client needs translation files
13:06 < Dinnerbone> It is not the servers responsability to know how to translate things for the client. The client can have hundreds of languages all kept up to date on an hourly basis if it wants; the server cannot do this.
13:06 < eddyb> SinZ: and?
13:06 < dx> oh hey it's dinnerbro
13:07 < Dinnerbone> Perhaps one day the server can suggest translations for things that won't exist (mods), but it cannot ever translate things straight out for the client. That's just stupid and inefficient.
13:07 < SinZ> eddyb: the language files can't be distributed afaik
13:07 < Grum> they will be soon o.O
13:07 < eddyb> SinZ: why are you saying this?
13:07 < Grum> you can just dump them in a resourcepack
13:07 < dav1d> Dinnerbone: yeah that's right, but I can't simply use your translation file (your as in mojangs)
13:07 < Grum> and they'll be loaded
13:07 < eddyb> SinZ: what did I do/say wrong? I don't get it :/
13:07 < Grum> dav1d: you can? we'll be shipping the client with enUS?
13:08 < Grum> and the server too
13:08 < Grum> because it has chatlog and a gui
13:08 < dav1d> Grum: but under which license?
13:08 < dx> Grum: you'll change the licensing terms of the translations?
13:08 <+md_5> Grum licensing...
13:08 < dav1d> ^ haha
13:08 < Grum> dav1d: whatever the fuck.txt
13:08 < dx> er... WTFPL?
13:08 < dav1d> Grum: so public domain?
13:08 <+md_5> <Grum> and the server too                           <--- I thought the point of this whole commit was that the server didnt need translations
13:08 < Grum> i mean seriously?
13:08 < Grum> is THAT the issue?
13:08 < eddyb> Grum: use this http://blog.izs.me/post/48281002063/free-as-in-hugs-licence
13:08 < Dinnerbone> And if you guys are really so concerned with efficiency or performance, tell me this: Which is more slow, sending "use multiplayer.player.joined with 'XXX'" to everybody, or looping through every player and turning this into a longer translation for their own language?
13:08 < Grum> md_5: not need *ALL* translations
13:08 <+md_5> Grum need a lawyer to sign off on that
13:08 < Grum> the server's log is a client 
13:08 < Grum> so that needs enUS (or at least one)
13:09 < Grum> md_5: leave it nicely in the grey area
13:09 < dav1d> Grum: honestly, yes. I don't like to steal stuff
13:09 <+md_5> eddyb use CDL: https://github.com/supertunaman/cdl/blob/master/COPYING
13:09 < dx> licensing is the issue for custom clients, yes
13:09 < dx> json being too complex to parse compared to plaintext is the issue for proxies
13:09 < SinZ> couldn't the custom clients just download from assets server?
13:10 <+md_5> Dinnerbone dunno, lets benchmark that with the memory and cpu overhead of gson decodes
13:10 < Dinnerbone> md_5, encodes* this is all serverside.
13:10 < dav1d> SinZ: that's basically the same as distributing it, isn't it?
13:10 <+md_5> s/de/en
13:10 < Grum> not sure how it is stealing
13:10 < dav1d> SinZ: a workaround would be loading it from the .minecraft folder (as I do for the terrain.png (1.4))
13:10 < Grum> enUS is rather publicly available on crowdin
13:10 < Dinnerbone> dx, if you're parsing chat messages on a proxy (why?), would a parsable format not be infinitely better?
13:10 < dav1d> Grum: wrong term
13:10 < SinZ> dav1d: downloading it on the end-users location from their servers isn't redist afaik
13:11 < Grum> yup
13:11 < Grum> you are perfectly happy to just fetch enUS stuff from our servers
13:11 < ShaRose> alternative: mojang hosts all the language packs on the website. on load, much like how the client grabs sound resources, the server grabs en_US or whatever the local language is from the site and loads it.
13:11 < SinZ> ShaRose: they DO
13:11 < Dinnerbone> It does this.
13:11 < Grum> it IS on Minecraft.Resources afaik
13:11 < dx> Dinnerbone: some proxies intercept proxy-level commands
13:11 < ShaRose> til
13:11 < dav1d> this is good!
13:11 < Grum> dx: there is no command from the client that is in json
13:11 < ShaRose> wait so why the hell do we care
13:11 < Dinnerbone> dx, from client or from server?
13:11 < Dinnerbone> Client never sends json
13:12 <+md_5> Dinnerbone both
13:12 < Grum> why would a server SEND a command in json?
13:12 < ShaRose> mojang is here, they said they don't give a shit
13:12 <+md_5> not command, chat in general
13:12 < ShaRose> how is this an issue
13:12 < Grum> i mean, if it knows it is a command .... :p
13:12 < Grum> md_5: why would you ever intercept outgoing chat from a server and then parse that as a command? O.o
13:12 < Dinnerbone> From the server: you're going to trust that all messages will be in a certain format, one language, so you can parse it hopefully with no problems? Vs having something you can parse trivially with absolutely no room for error?
13:12 < Grum> oh and isn't featureful-enough for what we want to do?
13:12 < Dinnerbone> You guys have bigger problems to worry about here
13:13 < SinZ> http://s3.amazonaws.com/Minecraft.Resources/lang/en_GB.lang
13:13 < Grum> enUS
13:13 <+md_5> say my proxy is connected to a 300 player server. 1 user sends a chat message. That message now has to be decoded 300 times.......
13:13 <+md_5> next I'm gonna have to store messages in a cace
13:13 <+md_5> cache
13:13 < Grum> no?
13:13 < Grum> because that proxy only gets it once?
13:13 <+md_5> Grum no... because the server sends it to each player
13:13 <+md_5> and each player is on the proxy
13:13 < Grum> yes, and those all have their own cpu? O.o
13:14 <+md_5> lolwat
13:14 < Dinnerbone> Why is your proxy parsing server->client text?
13:14 < ShaRose> why do you need to decode it from server to client for your proxy
13:14 < dav1d> ^
13:14 <+md_5> Dinnerbone api hooks, chat filtering for channels
13:14 < Grum> why would you do that based on chat?
13:14 < Grum> use the blank-data-packet 250 for it
13:14 < Dinnerbone> You shouldn't be doing this on chat, but it just so happens that this would incredibly incredibly simple to do with json and not hacky!
13:15 < Grum> yeah, maybe you can add the channel to the root of the json structure
13:15 < dx> simple but not efficient
13:15 < Grum> zomg insta-simple-filtering
13:15 < Grum> no, if you want to do it efficient
13:15 < Grum> tell the server to not send you those packets in the first place
13:15 < Dinnerbone> Efficient is not: server having to loop through every player and have to translate text for them and then send them a personalized packet
13:15 < Grum> if you filter on the client, you are going to do the filtering inefficiently on the client
13:15 <+md_5> regardless, to fulfil my api spec of the server to client message event, I have to parse every packet and fire an event
13:15 < Grum> then your api spec is broken?
13:16 < Grum> this is like peopel claiming ontick-hooks are good
13:16 < Grum> if you need that, you are doing something wrong
13:16 <+md_5> how is a server to client message event broken.....
13:16 < Grum> you can also just decode it lazily
13:16 <+md_5> say I want a bungee sided swear filter
13:16 <+md_5> actually nevermind that
13:16 < dx> get 100 messages per second, decode lazily. fun.
13:16 < Grum> what server do you get 100 messages per second? O.o
13:16 <+md_5> dx server to client is more than 100 a second...
13:17 <+md_5> lets do some back of envelope maths
13:17 < Grum> i mean even on irc you dont get that :p
13:17 < Grum> you have different problems
13:17 < ShaRose> Grum well apparently he's decoding a message for server to client for every client
13:17 <+md_5> um
13:17 < ShaRose> :P
13:17 < Grum> i'm in >50 channels and do not get 100messages/second O.o
13:17 <+md_5> this ircd is definately sending more than 100 lines a second
13:17 < ShaRose> so 100 per second is easy if you have a few hundred players
13:17 <+md_5> Grum but the IRCD does send more than that
13:17 < ShaRose> Grum I'm in like 90 and I don't hit that
13:17 < ShaRose> except for like a netsplit
13:17 < dav1d> Grum: but the server sends out more than that and he parses everything the server sends
13:17 <+md_5> ShaRose but the IRCD is sending more than that
13:17 <+md_5> so
13:17 < dx> think of irc network, not irc servers or irc channels
13:17 < Grum> md_5: so now you are complaining about json encoding cost?
13:17 <+md_5> 300 users
13:17 < ShaRose> yeah, because it has like 60k users
13:18 <+md_5> Grum we always were? check the gist
13:18 < dx> Grum: we were complaining about json decoding cost from the beginning
13:18 <+md_5> 3. Far more expensive to decode/encode
13:18 < Grum> i still dont see how you will get 100 unique messages/second though :p
13:18 <+md_5> they arent unique
13:18 <+md_5> some are the same
13:18 < ShaRose> then cache the result
13:18 < Grum> most are the same :p
13:18 <+md_5> but you honestly expect me to now cache it
13:18 < dx> they have to be parsed anyway
13:18 < Grum> parsing is a droplet in the ocean
13:19 < Grum> (as it only happens on the client)
13:19 < dx> he has to parse the ocean
13:19 <+md_5> 1 message a second = 300 messages sent by the server
13:19 < ShaRose> just do a checksum or if you want to hash the message, you can't say that's not light enough?
13:19 <+md_5> messagesIAmWorriedAbout = messagesASecond * playerCount
13:19 < Grum> md_5: yeah so you just pre-calculate the payload before you send? O.o
13:19 < Dinnerbone> I'm still curious why you do this on a proxy and not the server.
13:19 < Grum> as it'll be identical to all players anyhow
13:19 < SinZ> Dinnerbone: proxy is proxying >1 servers at once
13:19 <+md_5> Dinnerbone to provide event hooks. I dont actually manipulate the messages myself, but plugins might
13:20 < ShaRose> just do a kv store with a short key lifetime
13:20 <+md_5> ShaRose thats what I will end up doing
13:20 < ShaRose> why didn't you do this 'beforehand' is my question
13:20 < Grum> i'm sorry, because you chose an inefficient approach we cannot implement a sane system?
13:21 < Grum> logic failure right there
13:21 < ShaRose> as I see it right now
13:21 < ShaRose> implementing the cache feature will probably lower your resource usage even on top of json
13:21 < ShaRose> :P
13:22 <+md_5> ShaRose uh no
13:22 <+md_5> not at all
13:22 <+md_5> it would increase it because the cache would never be read from...
13:22 <+md_5> just written to
13:22 <+md_5> therefore redundant
13:22 < ShaRose> say what now
13:22 < Grum> you do realize you can just lazily decode and cache the messages right?
13:22 < Grum> if you want to keep this inefficient way of doing things :
13:22 <+md_5> there is no point having a cache if I dont need to to decode
13:22 < ShaRose> I don't think that word means what you think it means
13:23 < ShaRose> the idea is map the checksum of the message with the manipulated result
13:23  * md_5 head desk
13:23 < ShaRose> with a timeout of say half a second
13:23 < SinZ> I think race conditions will break that
13:24 < ShaRose> check it, decode it, check again and insert result with locking
13:24 <+md_5> ShaRose yes, that will be more efficient when json is used. You said it would be more efficient even when json isnt used
13:24 <+md_5> which makes no sense
13:25 <+md_5> anyway, as the saying goes
13:25 <+md_5> fuck it I'm out
13:25 <+md_5> <CafeBabe> [BungeeCord] md-5 pushed 1 new commit to master: http://git.io/F_QgyQ
13:25 <+md_5> <CafeBabe> BungeeCord/master 8e34e03 md_5: Remove chat event firing when we get a message from server to client, as Mojang has decided to completely break this in the next major Minecraft release.
13:25 < dx> welp.
13:25 < ShaRose> what I said was cache + json would use less than no cache + section
13:26 <+md_5> ShaRose which is a false statement
13:26 < ShaRose> so you are saying that parsing section is faster than a table lookup
13:26 <+md_5> I dont parse the section
13:26 <+md_5> so yes
13:26 <+md_5> not parsing anything is def faster than a table lookup
13:27 <+md_5> <awkward silence>
13:27 < Grum> right, so we'll not be *not* doing json because you have some weird proxy :P
13:28 <+md_5> this is not about my proxy
13:28 <+md_5> its about use cases
13:28 <+md_5> and potential impacts
13:28 <+md_5> I think a lot of the discussion in the gist still stands tue
13:28 <+md_5> true
13:28 < dx> bandwidth usage is still a big issue for a lot of server admins
13:28 < Grum> the impact is absolutely next to nothing for any normal usecases
13:28 < Grum> yeah and chunks are about 1000x bigger than a chatmessage
13:28 < Grum> and we're sending far too many of those
13:29 < dx> as i said, i've heard of server admins that filtered the traffic to remove mob head movements
13:29 < Not-001> [fCraft] fragmer * r1988 3 files : Initial import of FemtoCraft's map generator (VanillaMapGenerator.cs) and supporting functions (PerlinNoise.cs)
13:29 < Grum> so just NOT sending one of those can have us send 1000 messages
13:29 <+md_5> hurry up meme generator
13:29 < dx> sigh
13:30 < Grum> anyone running a mc server already has to cope with stupidly high bandwidth
13:30 < Grum> also something we cannot fix trivially (or maybe even ever)
13:30 <+md_5> its lovely to know you have so much pride in the quality of your product
13:31 < Grum> its not my product O.o
13:31 < Grum> if it was it wouldnt be this dubious =)
13:31 < dav1d> yay for new git! https://github.com/git/git/blob/v1.8.3-rc0/Documentation/RelNotes/1.8.3.txt#L135-L137
13:31 <+md_5> page is super slow, but here you go ShaRose , dx http://memegenerator.net/instance/38188275
13:31 < dx> Grum: you say that adding a packet length header is too complex, you don't seem to want to use bson for some reason, you do state that you dislike NBT because the implementation is terrible and you don't want to fix it, but you have no problem suggesting optimizing chunk sending to justify sending chat packets that are ten times bigger
13:31 < Grum> its not complex at all, it just gives no gain at all
13:31 < Grum> we can use bson but do you see a proper java implementation? i dont (also json wil ldo fine for now)
13:32 < dx> every time you say "no gain at all" i read it as "i don't care about #mcdevs"
13:32 < Grum> i rather just stop using nbt in general, its horrific
13:32 <+md_5> it gives gain to US, which is clearly not as valuable as the gain other things give to sethbling
13:33 < Grum> and the chatmessages arent 'significant' in any way size-wise to the rest of the things in the protocol; and thus that is no reason to not do the json change
13:33 < Grum> md_5: it gives nothing extra to you, just less work
13:33 < dx> Grum: you said you were planning to use json in many other places too, though
13:34 < Grum> yup
13:34 < Grum> all the places actually
13:35 < eddyb> guys, I think I've improved DB's format. it's still JSON, but for his examples, I get around 2/3 the size
13:36 < dx> Grum: also https://github.com/mongodb/mongo-java-driver/tree/master/src/main/org/bson
13:36 -!- Calinou [~Calinou@unaffiliated/calinou] has quit [Quit: Excess Flood]
13:36 < dx> apache license 2.0, i believe that's acceptable right?
13:36 < eddyb> wait, hmm, this damn nesting screwed with me again
13:36  * Grum looks for a clean and well tested mvn artifact
13:38 < Grum> i should add that gson is just that
13:39 < eddyb> gaaah I wanted to be smart with array recursivity and it bit me back
13:40 < Grum> good, and that is the reason we didnt just implement it
13:40 < Grum> i mean, we're not completely retarded >.>
13:40 < dx> 'not completely' is a good way to put it :3
13:40 < eddyb> this should be easier to parse, once I get the converter working for the demo
13:40 < dx> (sorry)
13:41 < Grum> dx: the arguments are just not good
13:42 < dx> 'it would make the work of #mcdevs much easier' is not a good argument
13:42 < dx> got it.
13:42 < Grum> nope its not
13:42 < Grum> sorry :(
13:43 < Grum> we'll get around to fixing the protocol and one of the things will be adding lenght for each packet
13:43 < dx> 'it would give sethbling enough nbt variables to make videos for a few extra weeks' is a good argument
13:44 <+md_5> Can see why tahg had creative differences
13:45 <+md_5> "Well get around then do it" why not do it now.....
13:45 < eddyb> Grum: https://gist.github.com/eddyb/5652486
13:45 < Grum> because as i've explained more than i care for, it breaks everything for *no* reason
13:45 < AnotherOne> did anything made here go to official minecraft code?
13:45 < Grum> you will just free up a couple of cpu cycles because of the change
13:45 < Grum> which is *NOT* a good reason to do it
13:46 <+md_5> "chat.type.chat
13:46 <+md_5> Its chat.type.text
13:46 < AnotherOne> wat
13:46 <+md_5> Dinners gist is wrong
13:46 < Grum> AnotherOne: yes
13:46 < AnotherOne> what was it?
13:46 < Grum> its just an example md_5, examples cannot really 'be wrong' :P
13:46 <+md_5> A few things do
13:47 <+md_5> When the mojangstas are in a good mood
13:47 < dx> *cough* the whole idea can be *cough*
13:47 < eddyb> Grum: 442 for mine, 601 for DB's, when stringified with no extra spaces. it should be easier to use, I would think
13:47 < Grum> o.O
13:47 < dav1d> AnotherOne: Gru*m works at mojang btw
13:47 < Grum> ohnoes, some extra "'s :(
13:48 < Grum> whateverwill we do :(
13:48 < AnotherOne> dav1d: i know:)
13:48 < dav1d> kk
13:48 < Grum> on the ~1.5mb of mapdata we send to people, noway that is significant
13:48 -!- r04r|away is now known as r04r
13:49 < dx> doing trivial optimizations to chat packets doesn't matter, refactoring chunk sending is totally trivial
13:49 < dx> damn used 'trivial' twice
13:49 < eddyb> Grum: hmm? I thought this structure fit better with your need for nesting. feel free to throw it away :)
13:49 < Grum> its exactly the same as json :/
13:49 < Grum> except that json has a proven (and not slow) parser
13:49 < eddyb> it *is* JSON
13:49 < dx> er yeah it is
13:50 < dx> he's just suggesting an alternate structure
13:50 < Grum> its not?
13:50 < Grum> well
13:50 < Grum> i guess it is
13:50 <+md_5> It is
13:50 < dx> did you click the wrong link or what
13:50 < Grum> and then you need a lot of horrible array-prodding
13:50 <+md_5> Look closely
13:50 < dx> it's json that uses lists instead of objects with named attributes
13:50 < eddyb> Grum: I feel like this is easier to handle than based on the presence of certain keys on objects
13:50 < Grum> actually those are positional attributes
13:51 < Grum> which are .... horrible
13:51 < dx> Grum: only the first attribute has special meaning
13:51 < Grum> so you are saying you can convey and random k=>v map to index-based stuff without having either gaps or lots of 'magic' while parsing?
13:52 < Grum> this would actually make it worse when you aprse it
13:52 < Grum> *parse it; because you need more external context to understand it
13:52 < dx> uhm
13:52 < dx> what
13:52 < eddyb> you wanted nesting, I gave you nesting. at least I tried. here's the converter: https://gist.github.com/eddyb/5652486#file-converter-js
13:53 < Grum> there is more than just italic ... bold, underline, links to other things
13:54 < Grum> i mean, the json is pretty self explanatory
13:54 < eddyb> and each gets a prefix
13:54 <+md_5> Links are just text
13:54 < Not-001> [BraLa] Dav1dde pushed 1 commit to master [+0/-5/±4] http://git.io/HC69fQ
13:54 < Not-001> [BraLa] Dav1dde 40682ea - kill awesomium with fire
13:54 <+md_5> Which you match with aregex
13:54 < eddyb> I used c(olor), i(talic), t(ranslate), you can add any number of "functions"
13:54 < Grum> different links md_5
13:55 < Grum> things that would show a tooltip for example
13:55 <+md_5> What kind of links....
13:55 < Grum> or open a gui
13:55 < Grum> or name it
13:55 < eddyb> ['l', 'whatever', ...]
13:55 < eddyb> as opposed to {color: 'green', link: 'foobar', using: [...]}
13:56 < Grum> why would that be better?
13:56 < Grum> because you us a single character?
13:56 < eddyb> that and the way it nests
13:56 -!- yorick [~yorick@oftn/member/yorick] has joined #mcdevs
13:57 < eddyb> I guess I'm falling into the Haskell sin, despite not using it
13:57 < dx> doing array[0] array[1] is more efficient than doing hash table access, too
13:57 < Grum> yeah also gives far more horrible code
13:58 < Grum> i mean, if these couple of bytes will end up being THAT much of difference we can always optimize it alter
13:58 < Grum> *later
13:59 < dx> i can write a trivial parser myself for eddyb's format, too
13:59 < Grum> sure you can
13:59 < dx> without a single hash table
13:59 < Grum> not sure how that matters
13:59 < Grum> you can write code for all the things
13:59 < dx> emphasis in trivial
13:59 <+md_5> Which means you can too
14:00 < dav1d> I have to agree with grum, blub[0] with rather magical indices is definitly worse than blub["font"]
14:00 < Grum> dx: go start and write a library that is properly tested
14:00 < Grum> oh also easy to use obviously
14:00 < dx> Grum: library for what
14:00 <+md_5> We ate giving you hints, go consider them and don't just retort unit test. 100 heads are better than one
14:01 < Grum> dx: to do thos?
14:01 < Grum> (ths
14:01 < Grum> gah *this
14:01 < Grum> md_5: as i said before, the *FIRST* thing i said when dinnerbone said json was: 'size might be too big' (and he'll probably just confirm it)
14:01 < Grum> but really its premature optimization
14:01 < dx> Grum: define "this", i just talked about an efficient parser that supports this subset of json
14:02 < Grum> why would we want to use a subset-parser of json?
14:02 < dx> you don't
14:02 < Grum> we have perfectly working json libs
14:02 < eddyb> Rust/Scala/ES6 mashup: html = (x) =>match(x) {['c', color, ...rest] => '<span style=color:'+color+'>'+rest.map(html).join('')+'</span>'; ['t', name, ...args] => translate(name).format(...args);};
14:02 -!- umby24|offline [~umby24@cpe-66-69-92-104.satx.res.rr.com] has quit [Ping timeout: 256 seconds]
14:02 < Grum> meh. /me flags this as premature optimization
14:02 < dx> i just said that if i had a client i could have more efficient parsing of a greater amount of messages with that
14:02 < dx> it is NOT something for you
14:03 < eddyb> err, ...args.map(html); although maybe pointless example
14:03 < dav1d> and who parses the html? :P
14:03 < dav1d> s/who/what/
14:03 < dx> he did say ES6
14:03 < eddyb> dav1d: I could create DOM nodes or use jQuery, but I'm lazy
14:04 < dav1d> eddyb: na I mean in a client :P
14:04 < eddyb> Grum: it's the best of both JSON and XML :-). ok, I'm done now :P
14:04 < eddyb> dav1d: there you would probably just change the style as you're doing this
14:04 < dav1d> eddyb: that wasn't serious
14:04 < dav1d> *I wasn't
14:05 -!- umby24|offline [~umby24@cpe-66-69-92-104.satx.res.rr.com] has joined #mcdevs
14:05 < dx> (my window manager broke, using irc from a 80x25 tty is fun)
14:05 <+md_5> Reboot
14:06 < eddyb> aboot
14:06 < dx> i'm just staying in this tty to debug the issue
14:06 <+md_5> What wm?
14:07 < dx> "qtile", written in python, i just use it for the fun of being part of the development
14:07 <+md_5> Doesn't sound pretty, what distro?
14:07 < dx> arch linux
14:08 < dx> it's actually rather mature/stable now, but i've been using it for a long time
14:09 -!- umby24|offline [~umby24@cpe-66-69-92-104.satx.res.rr.com] has quit [Ping timeout: 256 seconds]
14:10 < dav1d> :D http://www.youtube.com/watch?v=r_8om4dsEmw
14:12 -!- umby24|offline [~umby24@cpe-66-69-92-104.satx.res.rr.com] has joined #mcdevs
14:14 < eddyb> https://www.youtube.com/watch?v=WD6tTOcq0Vo better
14:20 < dx> okay done, fixed a bug \o/
14:20 < dx> dav1d: oh hey, that talk, i love it.
14:24 < Not-001> [fCraft] fragmer * r1989 6 files : Converted VanillaMapGen to the new architecture, and hooked it up to AddWorldPopup
14:24 < dx> dav1d: "help qtile grow exponentially" :D
14:24 < dav1d> dx: that was the best thing^^
14:24 < dav1d> we only need two of you :D
14:24 < dx> (actually i think we had like 20 total users back then)
14:25 < dx> now there's something like 400 stars on github, i couldn't believe it when i saw that
14:27 < dx> also i gave a lightning talk about qtile in a local pycon, but it sucked compared to this one :D
14:27 < dx> (before the one in this video)
14:35 < Not-001> [fCraft] fragmer * r1990 2 files : "Preview mode" dropdown is now functional on AddWorldPopup
14:45 -!- XAMPP_8 [~XAMPP8@199.254.116.104] has joined #mcdevs
14:45 -!- XAMPP_8 [~XAMPP8@199.254.116.104] has quit [Client Quit]
14:46  * dx cough
14:46 < dx> can someone remind me what the "infinicraft" protocol was supposed to be?
14:47 < dx> i wanted to read about it earlier but it seems the few docs about it got nuked
14:47 -!- XAMPP-8 [~XAMPP8@199.254.116.104] has quit [Ping timeout: 245 seconds]
14:51 < Yoshi2> hm, wasn't infinicraft a server framework where clusters of servers formed a single server? That protocol would probably have been used for interactions between the servers in the cluster
14:51 < Yoshi2> I think there was a project like that, but I don't remember it very well
14:53 < Not-001> [fCraft] fragmer * r1991 2 files : Improved progress reporting during generation for FlatMapGen and VanillaMapGen. Neither is cancelable yet.
15:04 -!- TomyLobo [~TomyLobo@91-66-112-147-dynip.superkabel.de] has joined #mcdevs
15:11 -!- AnotherOne [~kvirc@ip123-187.telenet.dn.ua] has quit [Ping timeout: 246 seconds]
15:12 -!- cathode [~cathode@c-76-105-184-52.hsd1.or.comcast.net] has joined #mcdevs
15:16 -!- AnotherOne [~kvirc@ip123-187.telenet.dn.ua] has joined #mcdevs
15:21 -!- SpaceManiac [~SpaceMani@r74-192-152-131.gtwncmta01.grtntx.tl.dh.suddenlink.net] has quit [Ping timeout: 245 seconds]
15:23 -!- SpaceManiac [~SpaceMani@r74-192-152-131.gtwncmta01.grtntx.tl.dh.suddenlink.net] has joined #mcdevs
15:23 -!- mode/#mcdevs [+v SpaceManiac] by ChanServ
15:24 -!- Zachoz is now known as Zachoz|Away
15:28 -!- redu [~redu@31.185.255.248] has quit [Quit: leaving]
16:21 -!- Exio [~x@trekweb/user/nax] has quit [Quit: doing stuff(tm)]
16:22 < AnotherOne> i have a strange problem
16:23 < AnotherOne> after some time of being logged in to server, it sends 0x0D and disconnects me wothout 0xFF
16:24 < AnotherOne> it is bukkit server
16:25 -!- umby24|offline [~umby24@cpe-66-69-92-104.satx.res.rr.com] has quit [Ping timeout: 256 seconds]
16:26 < dx> can vanilla clients use it normally? if so, you're parsing it wrong
16:27 < dx> this wouldn't be a problem if we had packet length headers, but you don't care about that stuff
16:27 -!- umby24|offline [~umby24@cpe-66-69-92-104.satx.res.rr.com] has joined #mcdevs
16:27 < AnotherOne> i do care:)
16:28 < dx> herp
16:30 < AnotherOne> that server kicks anyone who hasn't type /login in N seconds
16:30 < AnotherOne> but in that case client must get 0xFF
16:31 < dx> do you get just the 0x0D byte? or does it have a full player position payload?
16:32 < AnotherOne> full
16:32 < dx> do the contents make sense?
16:33 < AnotherOne> yes
16:33 < AnotherOne> the same position that is sent on auth
16:35 < AnotherOne> and this packet is sent after random period of time
16:35 < AnotherOne> every time different
16:35 < AnotherOne> oh
16:36 < AnotherOne> server does kick me
16:37 <+ammar2> are you doing the keep alive processing
16:38 < AnotherOne> sure
16:44 < Grum> <dx> this wouldn't be a problem if we had packet length headers, but you don't care about that stuff <-- you know you could jsut parse it right ;)
16:45 < Grum> i mean, write a unittest orso ;)
16:47 -!- mbaxter [~mbaxter@mcblockit/staff/mbaxter] has joined #mcdevs
16:49 < dx> i never heard of mcblockit before
16:49 < Grum> you clearly must not care for it!
16:49 <+ammar2> it was like the next and better mcbans
16:49 <+ammar2> then everyone abandoned ship
16:49 < dx> :(
16:49 < Not-001> [Miners] Wallbraker pushed 8 commits to master [+7/-2/±10] http://git.io/ZAu73Q
16:49 < Not-001> [Miners] Wallbraker 355b0eb - charge: Split the charge include module into sub modules
16:49 < Not-001> [Miners] Wallbraker e0b47ce - game: Keep reference to mouse and keyboard in app
16:49 < Not-001> [Miners] Wallbraker e2be31d - game: Minor fixes for Car
16:49 < Not-001> [Miners] Wallbraker 34b17d3 - game: Rework primtive actors a bit
16:49 < Not-001> [Miners] Wallbraker 1e617b7 - game: Rework static actors a bit
16:49 < Not-001> [Miners] Wallbraker e2ff07b - test: Remove nonsensical tests
16:50 < Not-001> [Miners] Wallbraker 2dbcf51 - test: Stop using SDL calls directly
16:50 < Not-001> [Miners] Wallbraker 6efcd15 - test: Simplify Game a bit
16:50 < dx> now mbaxter will think this channel is 99% notifico spam
16:50 -!- Calinou [~Calinou@unaffiliated/calinou] has joined #mcdevs
16:50 < mbaxter> Yup.
16:50 < mbaxter> What a mess
16:50 < dx> lol
16:50 -!- zh32 is now known as zh32|away
16:50 -!- zh32|away is now known as zh32
16:51 < mbaxter> Yeah, mcblockit was a cute idea founded by a bunch of mcbans staffers fired in a witchhunt.
16:51 < dx> fun
16:51 < mbaxter> I coded the plugin for them as a challenge, and before I was done (which was like two weeks) they'd all abandoned ship
16:51 < mbaxter> But I got a shiny host thing out of it :P
16:51 < dx> 'unaffiliated' is so boring
16:52 < mbaxter> Indeed.
16:52 <+pdelvo> I like my cloak :D
16:52 < Calinou> unaffiliated master race
16:53 < Calinou> for trolls, by trolls
16:53 < dx> pdelvo: nice :D
16:53 < Calinou> inb4 PDPC
16:53 < Calinou> lol trusted
16:54 < dx> i could ask for one of a project in which i was a core dev a few years ago.. but meh
16:54 < dx> my friend who started that project has a "grandpa" cloak for it
16:56 -!- barneygale [~barneygal@cpc22-sotn11-2-0-cust170.15-1.cable.virginmedia.com] has joined #mcdevs
16:58 < mbaxter> Late for the conversation, but I'm not sure I see it answered in the gist: 
16:59 < mbaxter> mid-message color changes would be handled by a critical mass of nesting?
17:00 < Grum> yeah
17:00 < Grum> because currently $r wipes the whole stack
17:02 < mbaxter> Exciting.
17:02 < Grum> not really
17:03 < mbaxter> Well, it was either 'exciting' or 'user-readable is useless for packets'
17:03 < Grum> anyhow that was not the reason for the change
17:03 < Grum> nor is readability :p
17:06 < mbaxter> If it were, I'd have petitioned for xml :P
17:06 < Grum> xml is juk :(
17:06 < AnotherOne> how to do unaffiliated?
17:07 < dx> join #freenudes, ask for it
17:08 < dav1d> xd
17:08 < dx> xd
17:08 < Yoshi2> now everything makes sence
17:09 < Yoshi2> freenode, freenudes
17:09 < Yoshi2> it's all related
17:09 < dx> actually my favorite feature of this network is that you can set channel redirects
17:09 < dx> so if anyone cared to keep that channel alive, you could tell people to join #freenudes and appear in #freenode
17:09 < Grum> i bet they implemented it by making a proxy that parses all chat!
17:09 < dx> uhm..
17:10 -!- Exio [exio4@trekweb/user/nax] has joined #mcdevs
17:11 < dx> Grum: well the ircd software is open source, the protocol is designed to be scalable and it's trivial to add features, so there's no need to do that kind of stuff if the feature didn't exist already
17:12 < dav1d> dx: I think that was related to md_5 
17:12 < Grum> =)
17:12 < dx> dav1d: =)
17:14 < dx> according to this command freenode is handling 76 thousand users at this moment
17:15 < dx> over 27 servers
17:15 < dx> being able to link ircds is a great feature, don't you think?
17:16 < Grum> not relaly
17:16 < Grum> they could just make a server that holds >1500 people ;)
17:16  * mbaxter read that as not relay, which was oddly relevant.
17:16 < dx> this server does have 6680 users connected, actually
17:16 < Grum> not bad :)
17:17 < dx> the fact that chat messages are plaintext and require almost no processing helps
17:17 < Grum> i wonder how many are bots :p
17:17 < mbaxter> all but five
17:17 < Grum> not really, the server is not reading the messages at all :p
17:17 < Grum> well only until the first ':'
17:17 < dx> yeah, they extract that information and broadcast it to the other servers
17:18 -!- redu [redu@31.185.255.248] has joined #mcdevs
17:19 < dx> i'm sure that those channels with 1000+ users generate a good amount of bandwidth for every message sent
17:19 < dx> good thing it's just plaintext limited to 400 eight bit characters
17:19 < Grum> i guess it should compress the data ;)
17:19 < Grum> and chunk it per 2-3 seconds :P
17:20 <+ammar2> don't forget threading, more threading will decrease the cpu :P
17:20 < Grum> oh yes!
17:21 <+AndrewPH> I hope they add a modding api to it
17:21 <+AndrewPH> so that we can make pvp ircds
17:22 < Grum> nah just release the source~!
17:22 < mbaxter> Ah, so this is #mccirclejerk
17:22 <+AndrewPH> hungergames ircd
17:22 <+AndrewPH> mbaxter: that's my favorite mcdonalds thing
17:22 < dx> mbaxter: i have no idea what you're talking about, this is just plain offtopic about irc servers
17:22 < mbaxter> Ew.
17:23 < mbaxter> dx: gosh, you're right. 
17:23 < dx> we do talk about completely unrelated stuff sometimes
17:23 < Grum> unacceptable
17:23 < Grum> ban everything
17:25  * ammar2 sets mode +b *!*@*
17:26 < dx> backup channel in case everyone gets banned: #craft.net
17:27 <+clonejo> dx: don't you think that's a bad choice :P
17:27 < dx> clonejo: :D
17:27 < mbaxter> ammar2: Best way to terrify a channel is to throw a control character into *!*@* and actually ban that.
17:28 -!- redu [redu@31.185.255.248] has quit []
17:28 -!- eddyb [~eddy@unaffiliated/eddyb] has quit [Ping timeout: 246 seconds]
17:28 < dx> mbaxter: oh hey it actually works in freenode, nice
17:29 < mbaxter> Then another op will unban *!*@* and probably clear the ban list :P
17:29 -!- eddyb [~eddy@unaffiliated/eddyb] has joined #mcdevs
17:32 < Not-001> [Miners] Wallbraker pushed 1 commit to master [+3/-3/±24] http://git.io/akMLrg
17:32 < Not-001> [Miners] Wallbraker 9c768f3 - charge: s/Runner/Scene/g
17:38 < AnotherOne> i have butthurt
17:38 < dx> the topic still says "publicly logged" but i've never heard about the location of these public logs
17:39 < eddyb> maybe it's a ruse :P
17:40 < dav1d> feepbot probably
17:40 < dav1d> but no idea where feep puts the logs if he even logs
17:40 < dx> it was something about being required to put it on the topic but without deciding how to publish it, IIRC
17:41 < dav1d> BraLa <3
17:41 < dx> hm?
17:41 < dav1d> 500 fps in a jungle looking at a desert
17:41 < dav1d> minecraft: ~80-100fps
17:43 < dx> lol, don't compare at this stage
17:43 < dx> i'm sure you're doing less stuff
17:43 < dav1d> yeah of course :)
17:44 < dav1d> btw I had smooth lighting disabled in minecraft
17:48 <+pdelvo> whats the name of your gpu?
17:48 < mbaxter> bob
17:49 < Yoshi2> my gpu is also called bob, maybe yours and mine could be friends, mbaxter :D
17:49 <+AndrewPH> mine's is boob
17:50 < dx> mine is richard
17:50 <+pdelvo> stop making fun of me! :D
17:51 <+AndrewPH> never!
17:51 <+pdelvo> I just noticed that minecraft without mipmap & aa & antisotropic filtering looks like crap :/
17:52 < dav1d> pdelvo: gtx 560ti
17:52 <+pdelvo> ah ok
17:53 < dav1d> ah yeah I think I have mipmaps enabled, but with anisotropic filtering it looks strange
17:54 <+pdelvo> I got a gtx 660ti. I think mipmap without aa & antisotropic filtering looks strange
17:55 <+pdelvo> btx have you ever tried a 8x8 texture pack? it looks like you are in a mini world
17:55 < dx> ..mini?
17:55 < dx> it makes things seem smaller?
17:55 <+pdelvo> jeah
17:57 <+pdelvo> it looks very funny: http://pdelvo.de/mini.png
17:57 < dav1d> I used a 8x8 in brala for a long time
17:58 < dav1d> didnt look too bad
17:58 <+pdelvo> are item frames working in brala?
17:58 < dav1d> no entity
17:58 < dav1d> if I had time :(
17:59 <+pdelvo> it would be interesting how they are performing in brala. the performance in minecraft is horrible
17:59 < dav1d> not sure how I would draw them
17:59 < AnotherOne> what is brala?
17:59 <+pdelvo> we have got a shop on a server with item frames. if you are in it it laggs crazy
18:00 < dav1d> AnotherOne: my client
18:00 < AnotherOne> how long are you developing it?
18:01 < Calinou> \o/ actual desktop users
18:01 < Calinou> dav1d and pdelvo 
18:01 -!- zh32 is now known as zh32|away
18:01 < dav1d> Calinou: :D
18:01 < Calinou> *60ti sucks at high details though
18:01 -!- zh32|away is now known as zh32
18:01 < Calinou> the 660ti
18:01 < dav1d> AnotherOne: not sure, maybe 1 year?
18:01 < AnotherOne> hehe
18:01 < dav1d> I had huge gaps inbetween
18:01 < dav1d> e.g. last ~6 month I didn't touch much code
18:02 <+pdelvo> Im upgrading my gpu to a gtx 780 which is (after the titan) the most powerful single gpu card avialable. maybe I can play minecraft without laggs in that shop
18:02 -!- Not-001 [~notifico@198.199.82.216] has quit [Remote host closed the connection]
18:02 <+pdelvo> but maybe not
18:02 < AnotherOne> now i dont worry about amount of time this takes
18:02 < Yoshi2> buying the most powerful gpu to play minecraft without lag? That is what I call dedicated
18:02 -!- _eddyb_ [~eddy@unaffiliated/eddyb] has joined #mcdevs
18:03 <+pdelvo> no im not buying it just for minecraft :D
18:03 -!- eddyb [~eddy@unaffiliated/eddyb] has quit [Killed (rajaniemi.freenode.net (Nickname regained by services))]
18:03 -!- _eddyb_ is now known as eddyb
18:03 < dav1d> pdelvo: for what then?
18:03 < dav1d> you could donate me your "old" one :P
18:03 < Yoshi2> ah, okay
18:03 <+pdelvo> And the titan is actually about 10% faster (and costs 300€ more)
18:04 -!- lianj_ [~lianj@ip-17-145-34-193.static.contabo.net] has joined #mcdevs
18:04 -!- lianj_ [~lianj@ip-17-145-34-193.static.contabo.net] has quit [Changing host]
18:04 -!- lianj_ [~lianj@subtle/user/lianj] has joined #mcdevs
18:04 <+pdelvo> metro, tomb raider, crysis
18:04 < dav1d> woot
18:04 < dav1d> I bet they would even run on my 560ti smootly
18:04 < dav1d> *smoothly
18:05 <+pdelvo> I can play them smoothy too, but not at the settings I would like to
18:05 <+pdelvo> I got a evga 660ti and they exchange my old card for the difference to the 780
18:10 < dav1d> ah yeah forgot to mention, brala runs a 128x128 while minecraft uses a 16x16
18:10 < dav1d> but brala loves heating up the GPU xD
18:10 < dav1d> 70° already
18:11 <+pdelvo> do you know furmark? this is heating up your gpu :D
18:11 < dav1d> then the vent jumps in
18:11 < dav1d> the benchmark? yeah
18:11 < Calinou> never got more than 60°C on my ref 570
18:11 < dav1d> but never tried it
18:11 < Calinou> you're in a room with 30°C ambient temp?
18:11 < Calinou> ._.
18:11 < dav1d> Calinou: ~20
18:11 <+AndrewPH> my 8800gts idles at 70c
18:12 < Calinou> dry thermal paste, or heatsink isn't fixed properly, AndrewPH 
18:12 <+AndrewPH> Calinou: and it maxes at 80c
18:12 <+AndrewPH> usually
18:12 < dav1d> when the vent makes my room vibrate it sstarts cooling down again
18:12 <+AndrewPH> (bad airflow through my case lol)
18:13 < dav1d> you mean no airflow lol
18:13 <+pdelvo> my one goes up to 60° at minecraft. in furmark up to 80 (it is overclocked). but 80 isnt a bad temerature for a gpu.
18:14 <+AndrewPH> dav1d: there's airflow
18:14 <+AndrewPH> it's just bad
18:14 <+AndrewPH> to top it off, my card barely fits in there
18:14 <+AndrewPH> almost no air can get out from under it
18:14 <+AndrewPH> (so I leave my case cracked open a bit)
18:16 -!- Flemmard` [~flemmard@master.virtuousrom.com] has joined #mcdevs
18:17 -!- Netsplit *.net <-> *.split quits: edlothiol, Eric12, Flemmard, lianj, Caius, sjl
18:17 -!- redu [redu@31.185.255.248] has joined #mcdevs
18:18 < AnotherOne> it works!
18:18 -!- Flemmard` [~flemmard@master.virtuousrom.com] has quit [Changing host]
18:18 -!- Flemmard` [~flemmard@unaffiliated/flemmard] has joined #mcdevs
18:18 < dav1d> nice
18:18 < dav1d> (whatever works)
18:18 < AnotherOne> yes:)
18:19 < AnotherOne> the problem is horrible code
18:19 < AnotherOne> refactoring rules
18:19 -!- Not-002 [~notifico@198.199.82.216] has joined #mcdevs
18:19 < Not-002> [BraLa] Dav1dde pushed 4 commits to master [+1/-1/±13] http://git.io/p5B0Fg
18:19 < Not-002> [BraLa] Dav1dde ff7a1d0 - minor performance improvements
18:19 < Not-002> [BraLa] Dav1dde dab25c1 - fixed possible segfault when closing brala too early
18:19 < Not-002> [BraLa] Dav1dde c31536e - -1 segfaults, happened in Chunk dtor
18:19 < Not-002> [BraLa] Dav1dde 223fc8a - speed up tessellation
18:19 < dav1d> and I got rid of a segfault!
18:20 < dx> AnotherOne and dav1d confirmed to be the same person
18:20 < dx> which means both of you are pbunny
18:20 < AnotherOne> hahahahaha:D
18:20 < dav1d> dx: I agree! threeeeeeeeeeaaaaaaaaaaads!!!!!
18:20 < AnotherOne> what about you?
18:20 -!- Flemmard` is now known as Flemmard
18:20 < dx> i'm not pbunny, i love java
18:20 < dav1d> BraLa uses 5 threads in total, but is scaleable!
18:20 < dav1d> you can configure it at runtime to use 20 threads if you want!
18:20 < AnotherOne> f**k threads
18:21 < dav1d> they got rid of two essential problems for me :)
18:21 < AnotherOne> it is said "think portals"
18:21 < AnotherOne> i say "think threads"
18:21 < dx> also who the fuck added that fucking censorship fuck
18:21 < dx> god fucking damn it
18:21 -!- sjl [~sjl@li136-50.members.linode.com] has joined #mcdevs
18:21 <+ammar2> dx: so brave
18:21 < AnotherOne> once i learned to think threads, debugging became much easier
18:22 < dx> ammar2: fuck you
18:22 < AnotherOne> wtf dx
18:22 < Yoshi2> once you use threads, you never go back
18:22 < dx> you typo'd, it's wt*
18:22 < AnotherOne> you are such a nice person
18:22 < dx> lol
18:23 < AnotherOne> no no no
18:23 < AnotherOne> correct censorship is fu*ck
18:23 < dx> hahah
18:24 < Yoshi2> fustarck
18:24 < AnotherOne> Yoshi2: threads are nice
18:25 < Yoshi2> yes, they are
18:25 < dx> wait
18:25 < dx> fuck
18:25 < AnotherOne> "never go back" means "you cant go back to childhood"
18:25 < dx> is this "fuck" censored? if it's not i'm going to feel very dumb.
18:25 <+ammar2> it is
18:25 < dx> oh okay
18:26 < AnotherOne> nice little childhood of single-threaded console apps and compile-time erroes
18:26 < AnotherOne> errors*
18:27 < jast> depends on what kind of threads you're talking about
18:28 < jast> native threads don't scale terribly well if you have several of them
18:28 < jast> even green threads often have similar problems
18:29 < jast> they're really only good if they're lightweight enough so you can have hundreds of thousands of 'em
18:29 < jast> then you "only" have the problem of inter-thread communication left
18:31 < AnotherOne> ^
18:31 < AnotherOne> thread hell
18:32 < jast> the sanest thing is message passing, but that's hard to optimize (which you'll need if you have a LOT of communication)
18:32 < AnotherOne> message passing is nice
18:33 < jast> and messing with other kinds of thread synchronization is Very Hard(tm)
18:33  * AnotherOne looks at system clock
18:33 < jast> conditions look viable, too, I suppose
18:33 < AnotherOne> it is refactoring time
18:34 < jast> I suppose message passing (Erlang style) is pretty much the same thing as conditions, only with some data attached to the condition
18:34 < dav1d> ha! close your eyes and pray
18:34 < dav1d> it works for me!
18:34 < jast> condition *variable*, actually, I suppose
18:34 < dav1d> when looking through my code I realized that I had a few threaded accesses to a hash map
18:35 < dav1d> it worked!
18:35 < jast> I never remember these words
18:35 < AnotherOne> dx are you here?
18:35 < dav1d> well access is not the problem but mutating it
18:35 < AnotherOne> this chat is too boring without your swearing
18:35 < jast> dav1d: yeah, and then suddenly unexplainable error. well, tough luck, right? :)
18:35 < dav1d> jast: that's why I got rid of it :P
18:35 < AnotherOne> suddenly unexplainable error
18:35 < AnotherOne> :D lolololo
18:36 < dav1d> well unfortunatly there are still 1-2 of suck lookups, but whatever
18:36 < jast> another great way to get unexplainable error is to use callbacks nested in complex ways
18:36 < dav1d> I use D, I am used to random shit happening
18:36 < dav1d> jast: https://github.com/Dav1dde/BraLa/blob/master/brala/dine/chunk.d#L104
18:36 < dav1d> jast: where is the bug?
18:36 < dav1d> segfaults when the GC calls the dtor
18:37 < dav1d> is clib.free not threadsafe and segfaults? I doubt that...
18:37 < dav1d> but it does nothing else
18:38 < jast> what's the difference between 'private static ~this()' and '~this()'?
18:38 -!- edlothiol [~edlothiol@95-91-255-238-dynip.superkabel.de] has joined #mcdevs
18:38 -!- Caius [~Caius@about/apple/macbookpro/Caius] has joined #mcdevs