Time  Nick        Message
11:19 celeron55   darkrose: https://github.com/darkrose/minetest/commit/fa2d578bdbc91e070d218d21e267808c56347fed
11:19 celeron55   src/guiFormSpecMenu.h:97
11:19 celeron55   why is that
11:23 darkrose    needed for getting variables in string from metadata, I think
11:24 celeron55   and why did you move the implementations of TextDest and IFormSource to there
11:25 darkrose    they were in cpp files, needed them in a header, make sense to put form related things in a form related header
11:26 celeron55   it's horrible style and makes you need to pollute the formspec menu with client.h as a dapendency and so
11:26 celeron55   the header, that is
11:27 celeron55   i think none of the #includes you added to guiFormSpecMenu.h should be needed in the the .h
11:28 celeron55   adding headers to headers is terrible, it bloats up compile times very quickly and i just previously got rid of crap like thta
11:28 celeron55   that*
11:28 celeron55   i will not take any of such in anymore
11:28 celeron55   s/style and/style which/
11:30 celeron55   and i think nothing uses IFormSource::m_p
11:32 celeron55   insted of stuffing the implementations of TextDest and IFormSource into guiFormSpecMenu.h, you should add the necessary things to the interfaces
11:33 celeron55   that way you get rid of the casts all around there too
11:37 celeron55   or you might need to remake the interfaces a bit; i won't study this throughly enough to be able to figure it out
11:37 celeron55   (unless you will stop here)
11:40 darkrose    not doing any more for a bit, got other projects, but can give it a rework when I look at it again
11:42 celeron55   i guess i will rework it then
11:45 celeron55   ugh, nothing is worse than undoing changes inside a large commit
11:46 celeron55   well, needing to cope with crappy code upstream is worse
12:27 Nemo08      hi all
12:30 sfan5       hi
12:46 celeron55   hmm, figured that out; not a long patch
12:46 celeron55   now i am looking at https://github.com/darkrose/minetest/commit/d412ea17462853cdbfe0e267169b8ca50589eacd
12:46 celeron55   i don't think there would need to be anything carried by PlayerSAOs
12:47 celeron55   just a single callback with the player passed as a parameter
12:47 darkrose    yeah, wasn't entirely sure where to store the reference, but figured that way more callbacks could be added easily enough
12:48 celeron55   no callbacks will be added that way; that's a horrible thing to debug
12:48 celeron55   any player can have any callback completely independently of anyone else
12:48 celeron55   it's just... unmanageable
12:49 darkrose    yeah, allowing for different ones depending on permissions, or something
12:49 darkrose    s/ones/callbacks/
12:50 darkrose    if the callback is assign in on_join_player it kind of implies per-player callbacks
12:50 celeron55   no; just a list of callbacks which mind their own business or if there is nothing they should do, they do nothing
12:50 celeron55   just a regular minetest.register_*
12:52 celeron55   they should be called from later registered to earlier registered, and if a later registered on returns true, it'll break the loop
12:52 celeron55   so that mods can redefine behaviour
12:52 celeron55   one*
12:53 celeron55   selectively
12:56 celeron55   if you wonder why i put set_inventory_formspec() in the player object, it is because there isn't really any universal way to have many mods co-operate with it
12:57 celeron55   AND it must be different for different players
12:58 celeron55   or, well, has to have the possibility of being
12:58 darkrose    ok, think I misread / was distracted when you were talking about player_on_receive_fields the other day too
12:58 celeron55   callbacks don't have those properties
12:59 darkrose    hence why It got lumped in with the player object
13:01 celeron55   hmm, what does bp_set do
13:02 celeron55   i see it uses some magic constants as it's value
13:02 celeron55   give me a comment to put near it
13:03 darkrose    / bp_set state of basepos, 0 = not set, 1= set by formspec, 2 = set by size[] element
13:03 celeron55   ...aand what is basepos? 8)
13:04 darkrose    something in IGUIElement I think... base position for the menu
13:05 celeron55   i guess it's something made by me, actually
13:06 darkrose    if bp_set != 2 then there's no size[] element so 1. needs to be calculated (such as in the sign menu) and 2. simple forms automatically get a procedd button (such as the sign menu again)
13:59 celeron55   here's something I added to roadmap: "Implement /give command in builtin rather than game"
13:59 celeron55   if somebody is lacking stuff to do
13:59 VanessaE    good morning
14:41 celeron55   whew
14:42 celeron55   so now there is proper formspec and minetest.register_on_player_receive_fields: https://github.com/celeron55/minetest/commits/master
14:45 celeron55   you can make... umm... a tetris in the inventory view
14:45 VanessaE    heh
14:45 VanessaE    curious - return can use a variable instead of a constant I assume?
14:45 celeron55   anything
14:45 VanessaE    ok.
14:46 celeron55   it's like passing stuff as a parameter to a function
14:46 celeron55   you just pass it downwards
14:47 VanessaE    I'm probably wrong here but likes 1155 to around 1164 (as patched) look like you could trim one or two lines by only setting s.send and then return'ing that variable at the end of the section
14:47 VanessaE    likes/lines.
14:47 celeron55   doesn't matter
14:48 VanessaE    I suppose not - the compiler will optimize it out anyway won't it
14:52 sfan5       how high can the gcc -O vlue go?
14:53 VanessaE    this i why I don't get much into modern languages - the way the computer actually behaves at the CPU level can be wildly different from what I coded.
15:01 celeron55   darkrose: i see you implemented the furnace using a node timer in the node timer commit but you didn't do anything to the ABM implementation?
15:03 celeron55   oh well, that isn't a full implementation anyway... i wonder what it is for
15:04 darkrose    uh, if that wasn't removed it should have been
15:22 celeron55   darkrose: what is this for? like is there a bug report or something? https://github.com/darkrose/minetest/commit/10baf8e1a2f2561655f104ae69eecaa66122ed07
15:24 celeron55   hmm actually i guess that is needed
15:24 darkrose    came from a forum post
15:25 celeron55   actually no
15:25 celeron55   it should be able to loop through, buffering it in parts
15:25 darkrose    and was the simplest way around the issue I could find, without reading the zlib docs
15:25 celeron55   that is not a bugfix, it's a laughable crapfix
15:25 darkrose    it's called "hack it till it works"
15:45 celeron55   i assume the decompress output buffer works if the problem has occurred on the compress output buffer
15:46 celeron55   because the decompress output buffer will will up quicker compared to the amount of compressed data and the size of it is the same
15:46 celeron55   fill*
15:47 VanessaE    Larger buffer sizes would be more efficient, especially for inflate(). If the memory is available, buffers sizes on the order of 128K or 256K bytes should be used.
15:47 VanessaE    ^^^ http://www.zlib.net/zlib_how.html
15:48 celeron55   it does not mean it is acceptable for it to be broken for sizes larger than the size of a buffer
15:49 VanessaE    oh of course not.
15:49 darkrose    celeron55: the problem occurs on inflate, oddly increasing the deflate buffer makes inflate work
15:49 VanessaE    just pointing out what the zlib docs say about it.
16:03 darkrose    problem occurs in mapblock deserialization, immediately following register nodes
16:07 celeron55   what the flying fuck
16:07 celeron55   http://paste.dy.fi/rWF
16:07 celeron55   i made a test.
16:08 celeron55   and yes, the loop goes for(u32 i=0; i<size; i++)
16:09 celeron55   can that even be possible
16:09 celeron55   i don't think so
16:14 celeron55   i must have screwed some signedness or something... eehm
16:15 celeron55   because that follows the repetition in the input data
16:15 celeron55   eh lol
16:15 celeron55   "="
16:15 celeron55   okay, every 0 tests as 0
16:15 celeron55   nice
16:16 darkrose    heh
16:17 celeron55   i should make these tests into a separate binary, but that'll be some other time
16:32 celeron55   http://paste.dy.fi/rbo
16:33 celeron55   the input data is pseudorandom in order to get large amounts of compressed data
16:35 celeron55   here are the sizes for the first one too: http://paste.dy.fi/rwO
16:35 celeron55   that looks... odd
16:36 celeron55   there is also a test for data equality, which passes every time (for the amount of data that it happens to output)
16:38 celeron55   so... wtf happens
16:39 celeron55   50000 - 16384 = 33616
16:39 celeron55   100000 - 98304 = 1696
16:39 celeron55   500000 - 491520 = 8480
16:40 celeron55   the first one is larger than the buffer size, which is 16384, and the two larger ones don't trash even a single buffer of data
16:44 celeron55   https://github.com/celeron55/minetest/commits/zlib_test
16:44 celeron55   eh, nice commit
16:44 celeron55   it's at line 420
16:50 celeron55   http://www.zlib.net/manual.html
16:50 celeron55   ctrl+f "deflate OF"
16:53 darkrose    reading input without producing any output << sounds familiar
16:53 celeron55   "f not all input can be processed (because there is not enough room in the output buffer), next_in and avail_in are updated and processing will resume at this point for the next call of deflate()"
16:53 celeron55   that might be the problem
16:54 celeron55   or... umm... maybe no
16:54 celeron55   +t
16:54 celeron55   it could be that too
16:54 celeron55   or producing output without reading input 8)
16:54 celeron55   the question is, which of these is not handled properly
17:04 darkrose    serialization.cpp 88/89, at the end of input flush is set to get the last data out, but deflate isn't run again because of line 91/92
17:09 sfan5       does minetestserver require irrlicht?
17:09 celeron55   headers, no lib
17:12 sfan5       i'll try to compile it for iphone
17:18 celeron55   hmm, this deflate wrapper seems to be somewhat half-thoguht
17:18 celeron55   thought*
17:18 celeron55   there is stuff in the loop that doesn't even need to be looped
17:18 celeron55   8)
17:18 celeron55   input_i is useless
17:19 sfan5       zlib.net is down
17:19 celeron55   it isn't
17:20 celeron55   ehm, it is
17:20 celeron55   mostly
17:21 jordach     celeron55, can i raise a question?
17:22 darkrose    you just did
17:22 jordach     right
17:23 jordach     the forums spambot reads: "what is the current stable?" 0.3 works, and 0.4 does not, it would be nice to have this fixed
17:24 celeron55   lol
17:24 * celeron55 fixes
17:24 jordach     thanks.
17:24 celeron55   fixed
17:30 celeron55   https://github.com/celeron55/minetest/commits/master
17:37 celeron55   would anyone be interested in making some kind of a test suite for world compatibility?
17:38 celeron55   (no, i don't know how to exactly even attempt such)
17:39 celeron55   but that would be handy as hell when trying to figure out if stuff like https://github.com/darkrose/minetest/commit/140693833b31c29c2ebed586202105044f1f7e2b and https://github.com/darkrose/minetest/commit/7d50ab988993af1ca9b04d11518eb8b4fa46b419 is stable
17:39 sfan5       make a world in 0.3.1 and test if it loads correctly in 0.4.1
17:40 celeron55   and 0.4.1, and test editing the world and test with nodes with every kind of special functionality
17:40 celeron55   it's very laborous by hand
17:40 celeron55   and test with all previous 0.4 versions
17:41 sfan5       i won't do that
17:41 celeron55   by hand the only option is to leave tests out and HOPE it doesn't break
17:41 celeron55   with an automatic tool you could just list them to it and it'd cram through all of it
17:41 celeron55   even if it was slow as hell
17:41 celeron55   eg. compile all tested versions of minetest before testing
17:42 celeron55   some kind of a mix of shell scripts and lua scripts
17:43 celeron55   ehm... and probably requres a C++ patch too
17:44 celeron55   not easy, which is a bad thing
17:44 celeron55   we'll never have easy reliability testing
17:44 celeron55   and version compatibility
17:46 celeron55   i guess i'll have to attempt it
17:47 celeron55   one of the super-fun things here are that the minetest server won't do anything useful (generate or load world) without a client connecting to it 8)
17:48 darkrose    pretty sure someone made a connectbot that could help there
17:48 celeron55   true
17:48 sfan5       write a python script that connects and quits
17:49 celeron55   i guess somebody already has one
17:49 celeron55   link plz
17:50 jordach     celeron55, regarding the bots that attacked minetest.ru 30001, i do suggest asking redcrab, he had bot(s)  joining and leaving
17:51 celeron55   ehm... the fact that his server was flooded by bots means he has the code for the bots?
17:51 celeron55   think. first.
17:54 darkrose    xyz on the forum is running this: http://servers.minetest.ru/ which apparently tracks uptime with a connect bot
17:54 celeron55   hmm... i do have the piece of php too
17:55 celeron55   i need to port it to some other language though, not fun installing php on a laptop for that
17:55 celeron55   8)
17:56 sfan5       what about python?nhttp://pastie.org/4301540
17:56 sfan5       oops
17:56 sfan5       http://pastie.org/4301540
17:57 celeron55   it just needs a bit more stuff though; i don't think the server will place player in the world with that
17:57 celeron55   +a
17:58 sfan5       it won't
17:58 sfan5       but i connects and disconnects
18:00 celeron55   that sends an empty unreliable packet (the "connect packet"), and then properly disconnects... hmm... it'd need to send a TOSERVER_INIT packet too, that'd place a player in the world
18:02 sfan5       how to get the commit hash of a tag from command line?
18:03 darkrose    they all show in `git log'
18:05 sfan5       thats some sort of interactive
18:05 celeron55   i wondered that one time too
18:05 celeron55   didn't figure out a solution because i didn't really need it though
18:05 celeron55   why do you need a hash?
18:06 darkrose    just runs it through $PAGER, can still grep the output
18:06 celeron55   tags and hashes are usually interchangeable anyway
18:06 sfan5       i wanna make a script that downloads all tagges minetest 0.4dev hash sources
18:06 sfan5       *tagged
18:07 celeron55   for i in `git tag`; do git archive $i; done
18:07 celeron55   or something 8)
18:12 sfan5       http://pastie.org/4301621
18:13 sfan5       use with ./script.sh your_minetest_folder zip_output
18:14 darkrose    well, that's simpler than `git log | grep -B 4 tag | grep commit | awk '{print $2}'` to get the tag's hash
18:18 sfan5       lets run this :D http://pastie.org/4301635
18:19 sfan5       rule 1: don't copy paste :/   http://pastie.org/4301640
18:19 sfan5       ok! my computer will be busy for a while
18:27 sfan5       better script: http://pastie.org/4301674
18:41 jin_xi      lol @ last commit, but the same terrible grammar is in the blog post.
18:50 celeron55   crap. well, not anymore!
20:12 VanessaE    c55:  How many node ID's are "reserved" out of whatever the current limit is?  that is, ID values that can't actually be assigned to a node
20:12 VanessaE    (I assume just one, the value 0)
20:22 celeron55   0 is freely used
20:22 VanessaE    ok
20:22 celeron55   there are two values that are "locked"; they are "air" and "ignore"
20:22 VanessaE    yeha, that's what I meant.
20:22 celeron55   they are something like 126 and 127
20:23 celeron55   other than that, doesn't matter
20:23 celeron55   you can start the engine without any solid blocks, just those two, which are built-in 8)
20:24 celeron55   (but the mapgen will screw up and generate "ignore")
20:27 VanessaE    somehow I don't think that would be too useful in practice :-)
20:28 VanessaE    (but then again, one guy on the forums is working on a sort of all-air floating globes game, I forget what it's called)
20:29 VanessaE    oops.  Non-core chitchat.   /me shuts up.
20:38 sfan5       celeron: didn't you want to link my windows builds on the downloads page?
20:41 VanessaE    celeron55: can you increase the "suspiciously large number of items in an area: deleting" limit?
20:45 celeron55   VanessaE: github issue
20:49 celeron55   (like *every* *time*)
20:51 VanessaE    ok, filed.
20:51 VanessaE    sorry, forgot :-)
20:53 sfan5       i asked something and nobody answered: forever alone!
20:54 VanessaE    awww :(
21:18 sfan5       feature request / idea: more image modifiers
21:23 celeron55   install gimp.
21:23 celeron55   fix'd
21:24 VanessaE    although he should have filed that on github also, he was talking about stuff that would only be workable in realtime
21:25 VanessaE    e.g. a sign with text on it, where the text is done via such an image modifier