Time  Nick         Message
02:43 Splizard     Hello I have a question regarding minetest networking. Is there any plan to implement player movement calculated by the server?
02:48 Splizard     The reason I ask is that the current way if things, player lag can badly affect the game. I don't have too much experience with c++ but I have some experience in game networking and I am able to write up some psudo-code to fix this if the devs are interested.
04:36 IceCraft     mornin`
09:23 ironzorg     hoi
09:23 ironzorg     10:57:17: ERROR[main]: generate_shader(): failed to generate "bumpmaps_solids", addHighLevelShaderMaterial failed.
09:23 ironzorg     do I have to look into the code to fix this ?
09:23 ironzorg     I tried enable_shaders = {1,2}
09:34 sfan5        ironzorg: thats pretty normal
09:34 sfan5        the bumpmap shaders seem to be some sort of non portable
09:34 * sfan5      is now afk
09:35 sfan5        ^ not an automatic script
09:35 celeron55    >since he told proller to push it although 3 other core devs are against it
09:35 celeron55    eh
09:36 celeron55    if you're against something, tell it clearly; and nobody noticed anything bad in the code the way it was now revealed
09:37 celeron55    anyway that should be fixed
09:40 celeron55    there are reasons why i'm trying to be extra careful with everything that involves the map and versions, but apparently that wasn't enough 8)
09:40 celeron55    oh also
09:40 celeron55    it's not my responsibility to make sure that contributors listen to core devs
09:41 celeron55    if everyone disagrees with me and i'm too dumb to see it (if somebody thinks that is what happened), then the contributor is supposed to see it
09:43 Exio4        celeron55: proller saw 'everybody' was against it and was looking for someone to say yes
09:44 celeron55    i see that the reason why this went bad is because before we haven't ever added anything to mapblocks in such a way that they aren't saved to disk but are transferred over network
09:45 celeron55    and the versioning doesn't take that into account
09:46 celeron55    hmm
09:47 celeron55    so as far as i can see, this will not break network compatibility
09:48 celeron55    because the server keeps track of which clients support which map serialization format and serializes accordingly
09:48 celeron55    so this breaks disk compatibility because of a backwards-compatible network addition was made 8)
09:48 celeron55    5/5
09:50 celeron55    this can be fixed though
09:51 celeron55    via two things
09:51 celeron55    first, map version 26 will be declared the same as 25 and saved versions will be 25 until version 27 is made
09:52 celeron55    second, an additional separately versioned mapblock over-network data will be transferred with mapblocks to newer clients
09:52 celeron55    in where the weather stuff goes
09:53 celeron55    and all future things that are similar to it
09:54 celeron55    do people think that is needed? it's needed if it is desired to either solve this incompatibility now, or solve future incompatibilities similar to this
09:57 celeron55    (i can code it, but won't if people think we should rather keep it simpler like now)
10:01 celeron55    (also if people think that proller's stuff is really not wanted, then the whole thing can be reverted (and v26 declared same as 25); however, for that to happen, people will actually need to say it rather than mumble something close to it)
10:23 celeron55    (this is the commit for reference: https://github.com/minetest/minetest/commit/3aedfac9685c2d9ae8bac5a5b7e72e527f22c08d)
10:26 ironzorg     (somebody likes LSIP)
10:26 ironzorg     LISP
10:26 ironzorg     I ruined my joke
10:43 Exio4        the next step is rewriting minetest in haskell
10:46 Exio4        ironzorg: what is the error itself?
10:47 ironzorg     what ?
10:50 Exio4        the shader(s) problem
10:51 Exio4        RealBadAngel: https://github.com/EXio4/minetest/commit/c1d4467a132c1ee5673dcbc774421aca571d168e
10:51 Exio4        i hope he looks at it later
10:55 ironzorg     Exio4: that's the error
10:55 Exio4        ironzorg: er, it should said something before
10:56 ironzorg     yea wait
10:56 ironzorg     http://codepad.org/epw7vPeL
10:56 ironzorg     linux amd64
10:58 Exio4        what gpu? what driver?
10:58 Exio4        well, move this to #minetest, this is getting converted into support
11:05 RealBadAngel ironzorg, your video drivers doesnt support opengl, propably youre using open ones. please install propertiary drivers for your GPU
11:06 ironzorg     yea that' what I thought
11:06 ironzorg     I have an integrated chipset…
11:06 Calinou      RealBadAngel: WTF?
11:06 Calinou      the open source drivers do support OpenGL
11:06 Calinou      also, intel doesn't even have a proprietary driver for their recent (non-crappy) IGPs
11:07 ironzorg     obviously it supports opengl yes
11:09 RealBadAngel Calinou, open drivers support for opengl one can stick deep in the ... ;)
11:09 Calinou      not at all
11:09 Calinou      they follow standards, but aren't permissive, unlike nvidia's impelemntation
11:09 Calinou      if you follow the standards it'll work
11:09 Calinou      but sadly, people believe creating headaches for code correctness is better than saving time
11:10 RealBadAngel on my box they do work, yes
11:10 RealBadAngel generating 5-6fps
11:10 Calinou      nvidia doesn't want an open source driver
11:10 Calinou      so nouveau sucks
11:10 RealBadAngel while with propertiary i do get 40+ fps
11:11 Calinou      AMD actually supports their OSS driver
11:11 ironzorg     just for the records, minetest runs flawlessly with the oss drivers I have
11:11 ironzorg     just can't get glsl to work
11:12 Calinou      old intel IGP then
11:12 ironzorg     yes
11:12 Calinou      back when they were crappy :P
11:13 Jordach      when did intel make something good
11:13 Calinou      their CPUs, and recent IGPs
14:04 celeron55    intel never makes anything but good
14:05 celeron55    speed is only one measurement and often irrelevant
14:34 proller      im trying to make clouds upper than 120, to 1000 - and they shart cutting on ~2000 range from me
14:34 Calinou      far clip
14:35 proller      maybe increase clipping to 3000-4000? or maybe it possible to adjust only for clouds ?
14:35 Calinou      try 500 instead of 1000
14:35 proller      no, only 300 works good
14:36 proller      with 500 clipping works too
14:36 proller      with 300 its hidden in fog
14:36 proller      visible with 500
15:11 sapier       https://github.com/minetest/minetest/pull/640 I know I asked this yesterdays but except of pilzadam noone responded
15:12 sapier       and of course this one too: https://github.com/minetest/minetest/pull/418
15:15 * proller    +1 for 640
15:16 proller      +#include <math.h>
15:16 proller      dont
15:16 sapier       no?
15:16 sapier       why?
15:17 proller      or yes with #include "util/mathconstants.h"
15:17 proller      or only #include "util/mathconstants.h"
15:17 proller      because MSVshit doesnt know about M_PI
15:18 sapier       ok I'll fix it
15:19 ShadowNinja  sapier: I think it would be better to search down. That would make hitting caves less likely. But doesn't the mapgen have a height map?
15:19 * proller    +1 for 418
15:19 proller      height map doesnt work on float islands
15:20 ShadowNinja  Ok, is there already a height map function?
15:20 proller      and on your buildings
15:21 sapier       spawning mobs requires to know surface this is done in lua atm and causes lots of load thus I made this fct quite some time ago ... long before any heightmap was added ... I'm not sure if heighmap would be an exact replacement
15:21 ShadowNinja  +1 for 418
15:22 proller      no sense to use heightmap after mapgen, height may be changed by player, trees, liquid
15:27 sapier       ok I removed math.h the other one was already there
15:33 sfan5        what about lowering the default player count to 32?
15:36 sapier       for what reason?
15:37 sfan5        Do you think a default limit of 100 makes much sense?
15:37 sapier       does 32 make more sense? ;-)
15:37 sfan5        yes, its lower
15:37 sapier       and you think lower is better?
15:37 sfan5        and it won't limit anyone
15:37 sfan5        you can change it anyway
15:38 sapier       yes but you still haven't told any reason except you feel 32 is better
15:39 sfan5        because possible (d)dos script for servers (which can work using a spoofed IP) -> see scrollback of #minetest
15:39 sapier       and minetest should be capable of handling way more than 100 players as mobs have about same performace impact (not exactly same of course)... so 100 or 500 doesn't make much difference
15:40 sapier       ok I'll have a look at #minetest but I don't think this really fixes any problem ... imho it's more like hiding a problem
15:41 sapier       btw "to stop (d)dos attacks" would've been the reason I was asking for at first ;-)
15:44 sfan5        you don't even need the second D of ddos to get a minetest server unuseable
15:57 Jordach      most servers DoS themselves with < 13 users
15:58 proller      /usr: write failed, filesystem is full
15:58 proller      cause to crash 8)
16:04 celeron55    oh god, it's that encryption discussion yet again on #minetest
16:04 sfan5        yet again?
16:04 celeron55    all of that has been talked through in here at least twice
16:04 sfan5        and the conclusion was ?
16:05 celeron55    it always results in that doing it non-properly is worthless, and doing it properly is so much work that it's not going to happen in near future; it will possibly be included in a far-future protocol rewrite
16:06 celeron55    anyway, DoS resistance should be improved if the server is so vulnerable to it
16:06 celeron55    (there are many ways for doing that)
16:06 sfan5        define non-properly and properly or link a discussion please
16:08 sfan5        max conns from an IP is worthless against the attack we already had because DoS-ing can be done with a spoofed IP
16:10 RealBadAngel celeron55, kahrl: were there any particular reason to pick SMhesh instead of IMesh?
16:12 celeron55    RealBadAngel: probably some additional method in SMesh
16:12 celeron55    sfan5: i can't really find a proper one
16:12 RealBadAngel im askin because i need methods that use IMesh
16:13 RealBadAngel SMesh is simplified from what i have read in docs
16:14 celeron55    sfan5: but anyway, for example encryption isn't that useful unless you can verify the peer you're connected to is what it says it is
16:14 celeron55    i'm all in for more security, but i think it's worthless to do it for the current protocol
16:15 celeron55    (also there are library issues)
16:15 RealBadAngel celeron55, i need to convert all the meshes ingame with this: http://irrlicht.sourceforge.net/docu/classirr_1_1scene_1_1_i_mesh_manipulator.html#ab849bd2c83b206de1e5da19ce3481e35
16:15 celeron55    SMesh implements the IMesh interface
16:15 celeron55    afaik
16:15 RealBadAngel so it shall work?
16:16 celeron55    oh, that outputs IMesh though
16:16 celeron55    so it won't
16:16 RealBadAngel i need it because it provides tangent space
16:16 celeron55    oh well, i guess you'll need to find out whether the SMesh pointers can be degraded to IMesh
16:16 RealBadAngel both tangent and binormal
16:17 RealBadAngel and those are vital to any advanced effects
16:17 celeron55    by the way, nobody commented anything to what i said at the morning about the map backwards compatibility that proller committed
16:17 RealBadAngel can you quote urself?
16:18 celeron55    this day's and yesterday evening's log
16:18 celeron55    it's long
16:18 RealBadAngel im workin on night shifts so i was afk for sure, please point me to logs
16:18 celeron55    http://irc.minetest.ru/minetest-dev/2013-07-30#i_3226568 http://irc.minetest.ru/minetest-dev/2013-07-31
16:19 RealBadAngel ty
16:27 sfan5        celeron55: so public key auth would need to be added too, that would increase the number of libs Minetest depends on
16:29 celeron55    well any encryption will increase
16:29 celeron55    the first step would be to find a suitable library that does something that is wanted
16:29 sfan5        openssl, polarssl, libtomcrypt
16:30 celeron55    as for what i've looked, libtomcrypt seems best out of those
16:30 sfan5        I've used libtomcrypt too(for small things); works pretty well
16:31 celeron55    sapier is most familiar with openssl i guess; i'm most familiar with crypto++ (due to work), but crypto++ is probably not really what we want here
16:33 sfan5        I guess RSA is the only choice for Public key auth, what about the block cipher for data encryption?
16:34 celeron55    dunno; something that happens to work easily
16:35 sfan5        AES and XTEA are the ones that work simple (RC4 too, but isn't too secure)
16:35 sfan5        s/simple/good/
16:35 PilzAdam     celeron55, the problem with proller's code is not that nobody wants this features, but rather that its currently too unfinished to judge it
16:36 PilzAdam     celeron55, the last thing that was pushed "too early" were finite liquids, and now nobody cares to fix them since they are already upstream
16:36 celeron55    sfan5: try making a branch that does some tiny thing with some crypto library that is also bundled in the source for easy building on windows; that way somebody can start working from there if we can approve it as a base
16:36 proller_     https://github.com/proller/minetest/commit/5038bc00564913b2db5f1839ad52083c7e08414c
16:37 proller_     celeron55, liquids per map, upper clouds ^^
16:37 celeron55    PilzAdam: i agree
16:37 celeron55    PilzAdam: it's problematic because we also really can't just do nothing
16:37 proller_     PilzAdam, i'm ix luquids
16:37 PilzAdam     proller_ tends to pop up with little features/tweaks, and nobody can see what he tries to accomplish at the end
16:38 celeron55    we need to have something larger going on because, well, people like that and in the end we're just trying to do something people will like
16:38 sfan5        celeron55: I'll do that.. ..after I have understood libtomcrypts build system
16:38 PilzAdam     I already suggested this a few times: I think it would be best if proller_ just works in his own fork for a while, until we can actually see the end result
16:38 celeron55    i agree with that too; i really think proller should write down what he wants to accomplish in the long term
16:38 celeron55    that way other people can judge his solutions
16:39 celeron55    (and improve them)
16:39 proller_     and "nobody wants"-  its false. many peoles want it and use it
16:39 celeron55    you should document that too; who uses it and for what reasons
16:40 proller_     i think about write to wiki..
16:40 celeron55    PilzAdam: i agree that that would solve some problems
16:40 celeron55    also, i think most larger features were developed like that
16:41 proller_     PilzAdam, long forks is too hard to keep updated
16:42 proller_     and nobody will agree to merge huge fork
16:42 celeron55    yes they will, if you've worked with them and they have know from the start (the documentation) what it's for
16:43 celeron55    of course depending that they agree to it from the start
16:43 proller_     in next steps i want to fix liquid visuals and make it 63 levels for smoooth flowing
16:44 celeron55    the only thing i know about what you're trying to do is that you want some kind of dwarf fortressy water physics with somewhat improved visuals, but all the details are completely unknown
16:44 proller_     and maybe make one liquid block "water" and "lava" with levels and infinity flag
16:44 PilzAdam     celeron55, your solution to mapblock version seems good to me
16:45 proller_     celeron55, maybe like this (it ideas, not all is true for implement) https://forum.minetest.net/viewtopic.php?id=4618
16:45 celeron55    PilzAdam: so you think separating the only-over-network data would be best?
16:46 PilzAdam     yep
16:47 celeron55    do you or proller want to do that or do i have to (i would rather work on something else i'm working on... as usual 8))
16:48 PilzAdam     proller_ said yesterday that he wants to fix it
16:49 proller_     i can maybe in weekend
16:51 Exio4        revert the weather commit now then
16:51 celeron55    Exio4: you can't do that, you'll break stuff because of... "laws of versions"
16:51 celeron55    (as opposed to laws of physics)
16:52 Exio4        hm
16:52 proller_     sipler to make try-catch
16:52 celeron55    basically it should work when made with these two principles: 1) the disk data should be saved with format number 25, and 26 should be loaded like 25; serialization.h should read "26: Same as 25. This should be never written on disk."; 2) the network data should be versioned according to the protocol version
16:52 celeron55    s/the network data/the additional network data/
16:53 celeron55    of course 26 could be simply reverted, but then some maps will be broken quite unrepairably
16:54 celeron55    as people use git head while they shouldn't
16:55 Exio4        good job proller!
16:56 proller_     its by design
16:57 proller_     celeron55, maybe make supported version = current+1 ?
16:57 Exio4        ehm
16:57 celeron55    lol no
16:57 proller_     and increase by 2 when really incompatible changes ?
16:57 Exio4        nice way to workaround the things proller_
16:57 celeron55    you can't do it like that; if one wants to do it like that, then something like each 10 being incompatible would work, kind of, but not really
16:58 celeron55    and that still leves you with only 10 versions between breakage
16:58 RealBadAngel https://github.com/minetest/minetest/pull/688 this seems to be ready to merge
16:58 celeron55    the whole thing could support major, minor and patch versions, but that gets awfully complicated
16:59 proller_     .. 100 ! 8)
16:59 celeron55    we're best off with what we have, but simply by not inducing on-disk format version changes from network changes, like i suggested and what pilzadam agreed to
17:00 proller_     will try to fix faster...
17:01 RealBadAngel celeron55, according to talks you have mentioned earlier. imho from time to time major chages will break compability no matter what. taking care of backwards compability (extra code) sometimes can bring more harm than good
17:02 RealBadAngel introducing such big change as weather imho shall bump minetest version
17:02 Exio4        http://irc.minetest.ru/minetest-dev/2013-07-27#i_3220738
17:03 RealBadAngel theres still 031 alive
17:03 celeron55    RealBadAngel: we don't do backwards compatibility in on-disk changes
17:03 celeron55    because of exactly that
17:03 celeron55    as for network we can afford it... but the framework we currently have kind of struggles with it and various people tend to not be familiar enough with it...
17:03 RealBadAngel so lets make new border line, new version
17:04 celeron55    there doesn't need to be any "border lines"
17:04 celeron55    it's nonsense
17:04 RealBadAngel at least with naming at informing the players
17:05 RealBadAngel "like from now on.."
17:05 celeron55    we can do that in any case as we have regular releases
17:05 RealBadAngel but we still are stuck to rollin model
17:06 proller_     now network backward compat is broken by nodeboxes
17:06 RealBadAngel lets make at least monthly realease plan
17:07 Exio4        that would suck
17:07 RealBadAngel why do you think so?
17:08 Exio4        1 month is nothing in terms of time
17:08 celeron55    any kind of versioning or release plans only sound to me like "endless hurry and endless hastily broken compatibilities"
17:08 RealBadAngel but short enough for any developer to plan when to push the changes
17:08 celeron55    you can propose something though
17:09 RealBadAngel now many code seems to be "on hold"
17:09 RealBadAngel waiting for xmas
17:10 PilzAdam     RealBadAngel, a fixed release plan would get even more pull request rejected
17:10 RealBadAngel ofc
17:10 PilzAdam     since we have at least 1 week feature freeze before a release
17:10 RealBadAngel that should effect with more better quality pulls
17:10 celeron55    if you're so interested and concerned, start arranging the merging of those then :P
17:11 celeron55    it's awful work and that's why it doesn't happen, not because of missing schedules or something
17:11 Exio4        1 month, 3 weeks bugfix the features of the first week
17:11 RealBadAngel celeron55, i got some patches on my mind, i will rebase them and fix
17:12 RealBadAngel wielded light, remove craft recipe to name just two of them
17:12 celeron55    btw, i think minetest should move to a specification-driven map format
17:12 RealBadAngel sometimes good idea is worth more than the code
17:12 celeron55    that would get rid of mishaps like this proller's one
17:13 proller_     first try but not tested https://github.com/proller/minetest/compare/ver
17:13 celeron55    it's really important to not fuck up stuff saved on disks so it's worth the effort
17:13 RealBadAngel setting standards is always a good solution
17:13 celeron55    otoh, we don't need it work network, because network incompatibilities are just momentary and don't "fuck up" things
17:13 celeron55    for network*
17:14 RealBadAngel btw i do have (solved) a big problem
17:14 RealBadAngel i dont know if you gonna like the solution
17:14 Exio4        what problem?
17:15 RealBadAngel Irrlicht is not capable to pass attribute variable to shader (material) instance
17:15 celeron55    proller_: that didn't even come to my mind; quickly thinking it looks like a fine first fix
17:15 RealBadAngel theres no fuckin legal way to do it
17:15 celeron55    PilzAdam: check proller's code ^
17:15 RealBadAngel i solved it with creating short image (texture) files
17:16 RealBadAngel and passing them to shaders
17:16 PilzAdam     proller_, can you still read maps that have version 26?
17:16 RealBadAngel 2-3 pixels wide images, that hold boolean values for shaders, or the tangent space vectors
17:17 sfan5        RealBadAngel: that solution should get the hackiest solution award ;)
17:17 RealBadAngel haha i know
17:17 RealBadAngel but theres no other way
17:18 RealBadAngel theres no problem to send to shaders global variables
17:18 sfan5        git cloning minetest/minetest takes f***king long with a connection of 6 KiB/s
17:18 RealBadAngel but i do need to send variables for every tile shaded
17:19 proller_     PilzAdam, yes, max check by highest
17:19 RealBadAngel especially its tangent space vector
17:19 proller_     25%] Building CXX object     my cpu too busy now 8(
17:19 PilzAdam     proller_, can old clients connect to new servers?
17:19 celeron55    (i really like it that PilzAdam "gets" things like these immediately and asks the exact right questions)
17:19 RealBadAngel by now im using solution to calculate tangent in vertex shader
17:20 proller_     PilzAdam, no, its broken by nodebox (not me)
17:20 PilzAdam     celeron55, umm.. thx
17:20 PilzAdam     :-)
17:20 celeron55    the mapblock serialization format is agreed by the server and client
17:20 RealBadAngel but its not perfect, on some angles it produces weird artifacts
17:20 celeron55    the server will use whatever the highest is that they support
17:20 PilzAdam     ah
17:20 RealBadAngel 2nd, it takes GPU time
17:20 PilzAdam     proller_, its good then
17:20 celeron55    however i don't know of this nodebox thing, what's it all about?
17:21 RealBadAngel new drawtype
17:21 celeron55    i've been hearing it but i don't know of anything like that
17:21 proller_     celeron55, old 0.4.7 cannot connect to new git servers now 8(
17:21 celeron55    why?
17:21 proller_     ym server is empty because of it
17:21 celeron55    it will be fixed as long as i know why the hell
17:22 RealBadAngel ah ah, theres a patch to fix bumpmapping for irrlicht 1.8
17:22 PilzAdam     I dont know about such a change... ?
17:22 RealBadAngel i recommend merging it
17:22 PilzAdam     RealBadAngel, I recommend you include that in your branch
17:22 RealBadAngel no
17:22 * VanessaE   peeks in
17:23 RealBadAngel its not related to my code
17:23 PilzAdam     proller_, can you point to the commit?
17:23 RealBadAngel its engine fix
17:23 PilzAdam     (the one that broke the compatibility)
17:23 RealBadAngel hi VanessaE
17:23 VanessaE     celeron55: protocol change to support the vector-ized node count
17:23 VanessaE     plus something else, I forget what
17:24 celeron55    oh it's the "Leveled nodebox" one?
17:24 RealBadAngel https://github.com/EXio4/minetest/commit/c1d4467a132c1ee5673dcbc774421aca571d168e
17:24 celeron55    9733dd
17:24 RealBadAngel this is Exio4's one
17:24 proller_     PilzAdam, no, its players complaints
17:24 celeron55    proller_: ?
17:25 celeron55    stop being so cryptic
17:25 VanessaE     (112dbba7c and 46d1d70e4 to be more specific)
17:25 proller_     9733dd dont bump any versions
17:27 PilzAdam     9733dd is included in the bump to protocol version 21, and it shouldnt be a problem if this drawtype is not used
17:27 proller_     celeron55, something earlies
17:27 celeron55    oh... ehm... well i'm assuming then that after proller merges the small fix that he showed, there are no important problems
17:28 RealBadAngel PilzAdam, its not only bumpmapping related, its about the shaders at all
17:28 PilzAdam     RealBadAngel, merge it then
17:29 RealBadAngel so i will tommorow
17:29 RealBadAngel now im goin to take a short nap before night shift
17:29 RealBadAngel cya folks
17:30 proller_     http://s018.radikal.ru/i503/1307/0b/52af4f0ace2f.png
17:30 celeron55    proller_: keep in mind that this version 26 that you use for the additional network data is a special privilege and it should be gotten rid of in the long-term, probably roughly like i've suggested
17:31 celeron55    the map version shouldn't be used for the same purpose in the future and it would be best if you get rid of it's usage there (it requires some actual design though)
17:32 celeron55    proller_: ...whaaat
17:32 proller_     celeron55, small chsnges via try-catch
17:32 proller_     ?
17:32 proller_     celeron55, its error from 0.4.7
17:33 PilzAdam     RealBadAngel, tested Exio4's patch and it works
17:34 celeron55    proller_: how is this possible
17:34 celeron55    proller_: the version has not changed since a year ago
17:34 celeron55    something probably offsets the data and it reads the wrong byte
17:35 celeron55    hmm, yes
17:35 proller_     strange
17:35 celeron55    it's not strange at all
17:35 celeron55    this happens only if the new nodeboxes are used, right?
17:36 proller_     snow now using it
17:36 proller_     on my server, yes
17:36 celeron55    so does a server run by default so that they aren't used?
17:36 proller_     snow now generating only from mod
17:37 proller_     but possible to place in creative
17:39 celeron55    the problem here is that the nodebox serialization format does not contain a length field
17:40 celeron55    so the offset gets fucked up if the type is unknown
17:40 celeron55    however, this lacks a thing that will make it work, which is included in ContentFeatures::serialize
17:41 celeron55    notice it? 8) it's the u16 protocol_version in the parameter
17:41 celeron55    simly do not send the client the NODEBOX_LEVELED type if the protocol version is older than which supports it
17:41 celeron55    simply*
17:42 PilzAdam     i.e. < 21
17:42 celeron55    has 21 been used in some released version of minetest?
17:42 PilzAdam     no, 20 is the one that was released as 0.4.7
17:43 celeron55    if so, then it should be incremented to 22 and 22 be declared to support NODEBOX_LEVELED
17:43 celeron55    then that's good
17:43 PilzAdam     21 is already meant to support the leveled nodebox (see clientserver.h)
17:43 celeron55    it should be said there more clearly
17:45 celeron55    also notice the "(0.4.0, 0.4.1)" in the file? that convention seemed to have been dropped at the same time as it was invented, but that'd be a good way to keep track of if a protocol version is still under work or if it's "locked"
17:45 celeron55    and yes, i know all of this sounds excessively complicated
17:45 celeron55    ...it's kind of simple once one gets used to it; it's just hard to explain all the practical laws behind versioning 8)
17:46 PilzAdam     oh, never saw the release versions in there
17:46 celeron55    basically limiting accepted version is not the key; the key is rising versions at the correct times and doing stuff that matters based on the rises
17:47 celeron55    also if the versions were marked in there, we could easily determine which versions we can drop support for
17:47 proller_     celeron55, its need to switch NodeBox version to 2 ?
17:48 PilzAdam     proller_, yes, you check the protocol version of the client and send the old or new version according to it
17:48 celeron55    proller_: that version in there is kind of redundant... but yes, it's a good idea because it is there
17:50 celeron55    we should change all of our serialization formats to some kind of binary key-value storage which easily supports missing fields with default values
17:50 proller_     json ! 8)
17:50 celeron55    it would make all this that we're talking about irrelevant
17:51 celeron55    but i'm too lazy and focused on other things to do that
17:52 celeron55    or, well
17:52 celeron55    i actually have such a one implemented, but i'm not too positive about people liking it as-is
17:55 celeron55    please somebody get interested 8)?
17:55 celeron55    it's here: https://github.com/celeron55/minetest/blob/meta_set_nodedef_2/src/util/template_serialize.h https://github.com/celeron55/minetest/blob/meta_set_nodedef_2/src/util/template_serialize.cpp
17:56 celeron55    with a usage example here: https://github.com/celeron55/minetest/blob/meta_set_nodedef_2/src/nodedef.cpp#L327
17:57 celeron55    it includes storing the lengths of stuff so for example this unknwon nodebox length stuff would be a complete non-issue with it
18:01 celeron55    because of the key-value storage, it has inherent cross-version compatibility and simply will not stop working as long as default values are fine... and due to that template "traits" pattern, it's also fairly compact to use
18:01 PilzAdam     that seems actually pretty good
18:02 celeron55    the downside is that the keys and value lengths and value types take some space... but it tries to squeeze them reasonably tight
18:02 PilzAdam     I wonder how insane it would be to release 0.5.0 with this without backwards compatibility
18:03 celeron55    completely fine
18:03 proller_     +1
18:03 celeron55    the only problem in version incompatibility is if it happens all the time
18:03 Exio4        there should be a small 'list' of things that could be done that can break backward compatibility
18:03 Exio4        so it is, that serializing protocol + other changes that "would need it"
18:03 celeron55    this could be basically a once-in-project-lifetime thing
18:04 sapier       no even if we use tlv we are not 100% safe to version incompatibilities
18:05 sapier       data transmission is safe yes but client can still be incompatible e,g, due to new required values
18:05 celeron55    yes, if something is *actually* required, of course it won't then work
18:05 sapier       but its a big improvement
18:05 celeron55    but 99% of the time minetest doesn't actually need almost anything
18:06 sapier       we could even do as dirty things as sending data in different formats dependent on client version ;-)
18:07 celeron55    we do that all the time currently
18:07 kahrl        what's dirty about it?
18:10 sapier       really ? I though we just send some parameters or not
18:11 VanessaE     aw shit
18:11 sapier       I meant really different e.g. send cmd x for client version y and a for version b
18:11 VanessaE     something in latest git is busted - can't connect to any server (nothing happens when clicking "connect" or pressing enter)
18:11 VanessaE     (the list works, though)
18:12 VanessaE     </offtopic>
18:12 sapier       I didn't do anything you didn't already tes
18:12 sapier       t
18:12 proller_     second try but not tested! https://github.com/proller/minetest/compare/ver
18:12 VanessaE     odd.
18:13 Exio4        you can always blame proller_ for that! :>
18:13 sapier       and what I did didn't solve your problem :-) not sure if anyone already did discover the problem it solved :-)
18:13 sapier       yes it's "blame proller" week
18:13 sapier       ;-) just kiddinh
18:14 proller_     8(.. but building n server...
18:16 proller_     bad try
18:16 VanessaE     sapier: took out that last commit of yours and that fixed it.
18:17 proller_     or not.. can somebody to connect with 0.4.7 to "Sky" server ?
18:17 sapier       didn't that happen yesterday too??
18:17 VanessaE     I never thought to try it with the IP address already present (I was typing it in for each try)
18:18 sapier       ok so most likely it was broken yesterday too
18:18 VanessaE     I'm now at clean git HEAD, with the vbo, hard-coded-value-of-e, and max registered nodes = 0x7fff patches added.
18:18 VanessaE     and it works fine there.
18:19 sapier       ok I understand what happens you don't have anything in serverlist selected am I right?
18:19 VanessaE     correct.
18:20 sapier       in this case nothing is started :-)
18:20 celeron55    < sapier> I meant really different e.g. send cmd x for client version y and a for version b
18:20 VanessaE     that explains it :)
18:20 sapier       I guess I missed that usecase
18:20 celeron55    oh that, i'm not sure if we do that at all
18:20 sapier       celeron I don't thing we do that atm and thats what I meant with dirty
18:38 proller_     https://github.com/proller/minetest/compare/ver - old client now connects to me !
18:38 proller_     but something wrong with snow
18:39 kahrl        Exio4: started the list you talked about http://dev.minetest.net/TODO#Big_protocol_changes
18:40 sapier       https://github.com/minetest/minetest/pull/846 VanessaE could you try? it at least fixes the problem singleplayer overwriting the address field ... if you didn't connect to server it still will be reset
18:41 VanessaE     checking..
18:46 celeron55    proller_: well, you could send a regular nodebox that is similar to a leveled nodebox of some height to the client
18:47 celeron55    but whatever, not that important
18:48 VanessaE     sapier: that seems to be good now
18:48 proller_     celeron55, if (version == 1)type = NODEBOX_FIXED   ?
18:49 celeron55    also, making new #defines like that isn't really useful
18:49 sapier       but I don't understand why it didn't work at all for you with previous version looking at code a second time it should've worked
18:49 sapier       it == connecting
18:49 Exio4        i don't understand one thing, couldn't the leveled nodebox be "server-side"?
18:49 celeron55    they can only break things accidentally as it's important to keep the same code identical over versions
18:51 celeron55    hmm........
18:51 Exio4        what was the problem with request_blocks, or why it didn't get merged?
18:51 celeron55    what does this leveled nodebox even actually do?
18:51 celeron55    now that i think of it, why isn't it a new node drawtype?
18:51 proller_     its like regular nodebox, but height gets from param2
18:52 Exio4        i don't see why it needs to be a 'new' nodebox now that proller_ documented it...
18:53 sapier       so you could create a nodebox being 20 blocks high?
18:53 celeron55    proller_: but why is it a "nodebox"?
18:53 celeron55    why isn't it a regular node
18:53 celeron55    i mean, a new drawtype
18:53 celeron55    nodebox is just a drawtype like many other drawtypes
18:54 celeron55    who even approved this thing
18:54 PilzAdam     probably proller just saying "will commit!" and nobody shouting "NO!"?
18:55 proller_     you can define custom nodebox and grow it with param=1
18:55 proller_     param2++
18:55 celeron55    why would you do that?
18:55 proller_     hmmmm, approve
18:55 proller_     for making growing snow
18:55 celeron55    but snow is just a block with height
18:55 celeron55    no need to have anything fancy in it
18:55 proller_     and later maybe liquids
18:56 celeron55    same for them
18:56 proller_     now snow can grow
18:56 celeron55    ...holy hell
18:56 proller_     how to increase height without it ?
18:56 celeron55    by making a drawtype that uses height and shows up a node with that height, but all other sides normal
18:56 Exio4        did he? i don't see him "aproving it"
18:57 kahrl        celeron55: although that wouldn't affect collision handling
18:57 kahrl        which I presume is the intention
18:58 celeron55    is that not doable otherwise?
18:58 celeron55    i mean, the system is quite borked if you have to do odd things in the network protocol in order to have the client do something in collision detection
18:58 kahrl        the collision code could check the drawtype, but there's no precedent for that
18:59 sapier       I don't think that'd be a big change
18:59 celeron55    you just need to modify MapNode::getNodeBoxes
18:59 celeron55    it's like two lines of code
19:00 kahrl        there he goes :P
19:00 celeron55    holy shit this was a crap implementation, unless people want to make growing chairs or something
19:01 sapier       alice in wonderland mod ;-)
19:01 celeron55    so is there any reason why we wouldn't change this to a sane implementation that uses a drawtype?
19:02 sapier       +1 for separate drawtype it's much more simple and reduces complexity while keeping all intended features (as far as I understand)
19:03 celeron55    it does that by a whole lot
19:03 celeron55    (at least i haven't heard any feature that it wouldn't keep)
19:04 sfan5        yay! libtomcrypt built correctly
19:05 celeron55    maybe proller_ should do that for exercise 8)
19:05 proller_     growing chair is good too 8)
19:05 proller_     maybe plants
19:05 PilzAdam     yea, leveled should become an own drawtype
19:05 sfan5        I guess the server should have RSA keys, right?
19:06 sapier       a security lib not beeing updated for almost a year?
19:07 kahrl        sapier: could mean that it is secure and has always been :)
19:07 celeron55    hmm
19:07 sapier       could but most likely it means "it's broken and unsafe"
19:07 * celeron55  is still looking into this leveled thing
19:07 sapier       last official version is from 2007 ...
19:08 celeron55    proller_: how does this leveled nodebox achieve the collision thing?
19:08 sapier       official sipport for gcc2.95 and vc6 ... sfan are you sure it's worth working at it?
19:08 celeron55    oh now i see it
19:08 celeron55    okay so
19:09 celeron55    i think we'll keep this; it's actually quite lightweight and not worth all this trouble to remove and is kind of sane for... maybe something
19:10 celeron55    proller_: just finish the compatibility thing to be good and we're set
19:10 proller_     90% done
19:11 proller_     why i recieve version==6 ?
19:11 proller_     where it defined&
19:12 celeron55    sfan5, sapier: wait, what; the last official version is from 2007 and even in the git repo they have commits after that like "prevent double-free" and "prevent access to NULL pointer"
19:12 celeron55    8D
19:13 * sfan5      has downloaded 1.17
19:13 kaeza        why?
19:13 kaeza        dereferencing null pointers is fun
19:13 celeron55    but! the latest commits in git are only 10 months old
19:14 celeron55    the git version might be good; what does sapier think? 8)
19:14 celeron55    https://github.com/libtom/libtomcrypt
19:15 sapier       I know did you have a look what has been fixed? Does anyone know if this library is actively used or just sitting around beeing dead?
19:16 PilzAdam     I dont get why people are always talking about security, this is a game and not a web browser
19:17 sapier       that's what home automation and heating control system creators said too :-) ... imho if we add a crypto lib we should add a good one
19:17 VanessaE     PilzAdam: a hacker doesn't care if it's a game server or webserver behind a particular port, all they care about is "can I exploit that and get root on this box?".
19:17 sapier       we shouldn't claim to add security while we don't actually do it
19:17 PilzAdam     VanessaE, we dont need encrypton to prevent that
19:17 sapier       last significant fixes of tomcrypt are 2 years old
19:18 sapier       imho this is a dead project not very usefull if you really want to add security
19:18 PilzAdam     the encryption is for people who are so paranoid that they think the user data on a Minetest server is worth to protect
19:19 sapier       I don't like to do it but I'm with pilzadam as noone really wants to add full security it's better to not add anything
19:19 sfan5        celeron55: where does the JTHREAD_INCLUDE_DIR var come from in src/CMakeLists.txt ?
19:20 celeron55    from find_package(Jthread REQUIRED), which calls stuff in cmake/Modules/FindJthread.cmake
19:20 sfan5        hm, ok
19:21 celeron55    sfan5: anyway, as you can see from this discussion, there's much consideration to be done
19:21 sfan5        I need some ideas on how to encrypt the connection
19:22 sapier       there's only one safe way ;-) server certificates and tls ;-)
19:22 kahrl        sapier: one time pad
19:22 kahrl        ;P
19:22 sapier       ok ok next level of paranoia ;-)
19:23 celeron55    in any case we should define where the users might expect security and then address that
19:23 PilzAdam     if peopel are really that paranoid then there is always localhost.... or is that insecure too?!
19:23 celeron55    not encrypt random things and then not care what help that is even of
19:24 sapier       pilzadam we had a case in company where spys used elecromagnetic waves transmitted by devices to gain information ...
19:24 celeron55    wireless keyboards, anyone? 8)
19:24 sapier       that's why our windows are metall shielded now and cellulars don't work anymore
19:25 celeron55    does sapier work in some kind of military it department
19:25 sapier       no just industrial security ;-)
19:25 sapier       and I'm by far not most paranoid one ;-)
19:26 PilzAdam     anyone wanna host a Minetest server in a nuclear blat-proof faraday bunker?
19:26 PilzAdam     *blast
19:26 celeron55    with no internet connection, of course
19:27 PilzAdam     of course
19:27 PilzAdam     RSA encrypted localhost connection only
19:27 celeron55    the players are let in naked, to play on terminals in the chamber
19:27 sapier       :-) and of course no doors as internal attackers are more common than external ones
19:27 celeron55    or actually outside the chamber, with an another chamber over that
19:28 sapier       naked? guys could we plz increase waf before setting up this ?
19:29 celeron55    no
19:29 nalkri       waf?
19:29 celeron55    8D
19:29 sapier       lets get serious again .. if we want to add security we need to look at full picture first ... not worth adding steel front doors while backdoor is paper
19:30 celeron55    kahrl: btw, that's a good addition to the wiki
19:30 sapier       and I guess the only thing worth defending is users password
19:31 celeron55    probably; all the other things can be defended by aiming for easy wiki-like reverts
19:31 PilzAdam     celeron55, funny that you say it in the exact same moment I started to read it :-)
19:31 sapier       but we could print a big fat warning instead of defending the password too ;)
19:31 celeron55    well yes, maybe
19:32 celeron55    it really depends on how much trouble it is
19:32 celeron55    an another thing that maybe could be wished to be defended is the chat on servers
19:32 sapier       defending password could be as easy as using a strong hash algorithm with a lot of salt on client side
19:32 PilzAdam     "Make the client request mapblocks" cant this be done based on the protocol version of the client?
19:33 celeron55    one guy once asked here or somewhere that it would be good to have encrypted chat because... he lived in a country where the government doesn't like almost anything that people talk about
19:33 sapier       defending chat is more difficult
19:33 sfan5        could we get back on the topic how security and encryption should be done
19:33 kahrl        PilzAdam: most of the points can. but it would involve lots of checks in different places
19:33 kaeza        celeron55, arsdragonfly, from... China
19:34 proller_     celeron55, http://msgpack.org/
19:35 sapier       imho following prioritys should be used for deciding for a security lib: license compatibiliry; active development + security fixes; at least some projects using it; ease of use
19:36 celeron55    proller_: that's quite an over-marketed and half-designed thing IMO
19:36 celeron55    proller_: but could be good; not sure
19:36 celeron55    proller_: there are certain things that make it suboptimal in certain uses, while minetest probably isn't one of those uses
19:37 PilzAdam     kahrl, I think that exactly this list should be the goal for 0.5.0, and nothing else
19:37 celeron55    proller_: the single biggest benefit would be easier compatibility with external programs
19:38 proller_     but its probably better than reimplementing wheel
19:38 proller_     and better than json and others for internal protocol
19:39 celeron55    json shouldn't come even to mind when thinking about this; it's not suitable at all
19:39 proller_     yes, it for example
19:39 celeron55    does msgpack support maps with integers as keys?
19:40 celeron55    we can't afford string keys because they are too wasteful
19:40 proller_     http://wiki.msgpack.org/display/MSGPACK/Format+specification#Formatspecification-Maps
19:41 celeron55    our data is basically generally like four bytes, so if there's something like "post_effect_color" along with it, that defeats the purpose altogether
19:41 celeron55    so we want to just enum all those keys and use the ids
19:41 sfan5        what I got now: https://github.com/sfan5/minetest/tree/security
19:41 kahrl        proller_: though that stores type information for each key
19:41 kahrl        wasteful when we know all keys are integers from the beginning
19:43 celeron55    well it's not too bad, really
19:43 sapier       so we really need to fight for any single byte? we're using ethernet or wlan not zigbee
19:44 proller_     if we want to support 1000+ players pr server - yes
19:44 celeron55    it's going to be on on-disk data too and pretty much everything
19:44 celeron55    it's a matter of whether to, well, double or triple the data size compared to current
19:44 sapier       ok ok didn't think about on disk data ... but for those access methods are even more important
19:44 celeron55    8)
19:45 celeron55    well it's not going to double; more like 150% of current; but all that adds to it
19:45 kahrl        there's the fact that loading a mapblock from disk is already slower than running the mapgen, unless that changed recently
19:45 celeron55    the bottleneck to that isn't speed
19:45 celeron55    i mean, bulk sped
19:45 celeron55    +e
19:46 sapier       if this is true we need to find more smart caching/preloading methods
19:46 celeron55    also, i still think that the loading is slow most likely because of *writing* is slow, and that *might* be slow because we run sqlite in synchronous mode... i and nobody else has still tested that i think
19:46 celeron55    MT writes a mapblock always after loading it to update the timestamp, IIRC
19:47 kahrl        the timestamp could be changed into a separate column
19:47 sapier       hmm don't modern os support multiple (non overlapping) file accesses?
19:48 celeron55    someone try PRAGMA synchronous=OFF
19:49 celeron55    kahrl: but otoh we can't stick to sqlite either
19:49 proller_     pray=on 8)
19:50 celeron55    it breaks with huge worlds (for some reason) and large servers currently, or at least back in some time ago use leveldb
19:50 celeron55    i don't know if the leveldb patches are still up to date though; does anyone have up-to-date info on this?
19:51 celeron55    gah, there's so much stuff going on
19:51 celeron55    or, more like not going on
19:52 celeron55    i feel minetest should be split to smaller parts with well-defined interfaces so development could be more distributed
19:52 celeron55    but that's a lot of work too *toolazy*
19:52 celeron55    or not lazy but wanting to do other things, as always
19:52 celeron55    hell, i just talk here by myself, i'm out ->
19:53 PilzAdam     celeron55, everyone wants that the leveldb pull request gets merged but its really out of date, like 0.4.4 or so
19:53 celeron55    i have only one comment to everything asked from me today from now on: yeah just handle it somehow
19:53 kahrl        I thought about the splitting thing, but like everything uses g_settings, while it's managed by the most top level piece of code
19:53 kahrl        and issues like that
19:55 proller_     compat 95% done..
19:55 celeron55    if someone feels like all this is too clogged up and you can't do anything because of that, we could have a "minetest reworked" branch that addresses all the technical issues on a framework level and rearranges the existing code to that
19:56 celeron55    but only one, please
19:56 kahrl        suddenly: all the pull requests marked "rebase needed" :D
19:57 celeron55    well, once again, you can do incompatible stuff as long as it's good in the long term
19:58 celeron55    i hate days like these when i just write n+9001 lines and nothing actually happens, not to minetest and not to anything else
19:59 celeron55    i guess i at least learn to write english a bit better... but it probably sums up negative because of all the headache other people get
19:59 celeron55    8D
20:00 celeron55    i mean, what's the problem with all this; the more i try to address things, the more things pop up
20:00 celeron55    it never ends
20:00 celeron55    it's insane
20:01 kahrl        indeed and I guess that's why nobody has the courage to start such a "minetest reworked" branch
20:02 celeron55    the work behind, and the work yet to be done is pretty intense
20:03 sapier       I'm used to rebase all of my pull requests at least 5 times until someone finaly decides to add them ;-P
20:03 celeron55    people tend to start minecraft clones, and even kind of minetest clones, but they all are in C# or Java 8D
20:03 celeron55    what's up with that too
20:04 kahrl        except the one that is written in x86 assembly and bootable
20:08 celeron55    i would really like to start a remake of minetest with all the knowledge i've learned, but i don't want to code most of it by myself
20:08 celeron55    that's what's stopping me from even starting
20:09 celeron55    and really, the gains would come after so long time... for like a year it would be greatly inferior from everyone's standpoint
20:09 celeron55    assuming everyone worked on it
20:10 celeron55    so, really that's why we should be happy that we have this acceptably working blob of code called "minetest"; because nobody in hell is going to do that all again
20:10 celeron55    :-D
20:12 sapier       I don't think so ... we shouldn't be happy but only thankfull and keep improving it to get it to something we can be happy with in some distant future ;-)
20:13 celeron55    after the year, it would be 100% awesome though
20:13 sapier       and after one and a half year you'd know what you could have done even better ;-)
20:14 celeron55    remaking something too early is a common begninner's mistake
20:14 celeron55    and yes, we can learn even more from working on current minetest
20:14 celeron55    it's really hard to tell when you've learned enough for a remake to be reasonable
20:14 sapier       minetest is still far from feature stable so I guess it's not time for a remake
20:15 celeron55    that's one reasonable way to see it
20:15 sapier       e.g. the client side lua ... threaded lua mods
20:16 sapier       we don't have any experience how to do this right
20:16 sapier       we just think that could solve some issues ... most likely it will fix them but who knows what sideeffects will occur
20:18 celeron55    there are some things like versioning and formats that could be gotten much more right from the start
20:18 celeron55    but we don't really know whether something would work much better than eg. irrlicht
20:19 celeron55    and what you said about client-side lua and whatever
20:20 celeron55    in many senses it would be just "an another attempt", more like a sibling than a child 8)
20:20 celeron55    there's more material to learn from in the internet about these though
20:21 sapier       and imho versioning things could be done without rewriting ... yes it's gonna break compatibility ... but why not use that first and second number in versioning scheme ? ;-)
20:21 celeron55    but there's also a lot more technologies... for example there is a voxel module to unity3d, in which many games are made these days
20:21 sapier       unity3d as in ubuntu unity?
20:22 celeron55    no
20:22 sapier       puuuh :-)
20:22 celeron55    they were started at the same time so they happen to have same names because they didn't know of each other 8)
20:24 celeron55    that's more from the "indie game world" than the "free and open source world" that people working on minetest are more involved in
20:24 sapier       I don't understand why irrlicht is considered that bad? yes the gui isn't as perfect as e.g. gtk or qt but it's a 3d engine not a gui toolkit
20:24 celeron55    as a 3d engine it's kind of lagging behind in technology
20:25 celeron55    but whatever, it works
20:25 celeron55    much of minetest's cross-platform usefullness is due to it
20:25 sapier       ok ... but we're not even using full irrlicht feature set as far as I know ;-)
20:26 sapier       but I'm not a 3d developer maybe rba would be more skilled to tell about it
20:32 celeron55    minetest is by a large margin the most used program that uses irrlicht
20:33 celeron55    nothing can beat it in that, like probably ever
20:35 Akien        Hi minetest devs :) I don't mean to interrupt but I'd like to have some advice about a compilation issue with minetest 0.4.7 on Mageia 3 (I'm looking at updating Mageia's minetest package, we're currently shipping 0.4.3).
20:35 Akien        I run in this kind of issue: BUILD/minetest-0.4.7/src/util/serialize.h:32:32: error: 'u64' has not been declared. Looking at your issue tracker, it seems this kind of issue was already reported and fixed, so I was thinking it might be a well-known problem with an easy fix on my side?
20:36 PilzAdam     Akien, it happens if you use a pre-release 1.8 of Irrlicht
20:37 celeron55    you'll need to patch it yourself
20:38 celeron55    see irrlichttypes.h
20:38 celeron55    that's where irrlicht 1.8 is checked for (the issue is that you have an early version of 1.8 that does not define u64, while minetest only defines it if you aren't using irrlicht 1.8)
20:40 celeron55    for example just comment out the outer #if/#endif where it checks for it
20:41 celeron55    ...or alternatively package the actual release version of irrlicht 1.8, which work
20:41 celeron55    +s
20:42 Akien        Thanks for the advice. I'll see with our irrlicht maintainer that we package the release version of irrlicht, we currently have the 4094 revision.
20:43 celeron55    hmm, i wonder what it should be
20:44 Akien        I'll try to check on irrlicht SVN if 4094 was prior to the release.
20:45 Akien        But I guess so, if not I don't think we would have bothered to package a development snapshop when an official release is available.
20:46 celeron55    http://irrlicht.svn.sourceforge.net/viewvc/irrlicht/tags/release-1.8/
20:46 celeron55    this says 4374
20:47 celeron55    but i'm not sure if it's a correct number
20:50 Akien        Well it probably means the trunk rev was around 4370 to 4373
20:50 Akien        So Mageia's package is outdated, I'll update it with the upstream tarball then.
20:51 celeron55    i recall there was something similar in fedora sometime
20:51 celeron55    that's an RPM-based distribution too so it could be related
21:11 proller      seems ready - https://github.com/proller/minetest/compare/ver
21:13 proller      "sky" server up with this code
21:22 proller      but need 1 more %
21:42 Akien        celeron55, PilzAdam: Packaging the 1.8 release of irrlicht fixed the u64 issue, thanks :)
21:42 Akien        Now I'm running into: https://github.com/minetest/minetest_game/issues/132 but sadly the fix is not described on the ticket
21:45 PilzAdam     Akien, the jthread libary in the Minetest source is modified, you have to use it
21:45 Akien        Ah indeed in our latest package we patched minetest to use the system jthread
21:45 Akien        I'll remove the patch then.
21:46 celeron55    oh hell, that hasn't been renamed yet or fixed in the cmake scripts?
21:46 celeron55    the jthread in minetest is currently our own fork of it... without a modified name
21:47 celeron55    what the hell guys, why does this FindJthread.cmake still try to use the system jthread?
21:47 celeron55    hmmmm?
22:13 proller      ready ! - https://github.com/proller/minetest/compare/ver
22:19 Akien        Seems I'm having an issue with the use of the shared jthread library over the static one:
22:19 Akien        Linking CXX shared library libjthread.so
22:19 Akien        CMakeFiles/jthread.dir/pthread/jthread.cpp.o: In function `JThread::Start()':
22:19 Akien        /home/akien/Contribution/Checkout/minetest/SOURCES/minetest-0.4.7/src/jthread/pthread/jthread.cpp:82: undefined reference to `pthread_create'
22:19 Akien        CMakeFiles/jthread.dir/pthread/jthread.cpp.o: In function `JThread::Kill()':
22:19 Akien        /home/akien/Contribution/Checkout/minetest/SOURCES/minetest-0.4.7/src/jthread/pthread/jthread.cpp:122: undefined reference to `pthread_cancel
22:30 Akien        Time to call it a day - I'll look at it tomorrow. Thanks for your help :)
22:47 proller      tested! ! - https://github.com/proller/minetest/compare/ver
22:48 proller      save to disk and old clients works!
22:53 proller      commit?
23:14 Exio4        wait for other devs
23:16 proller      Exio4, can you test ?
23:16 proller      but already saved in 26 format will only works in current version
23:27 Exio4        proller: not really