Time  Nick         Message
10:05 RealBadAngel https://github.com/minetest/minetest/pull/1617
10:05 RealBadAngel ^^ node highlighting for testing
10:06 RealBadAngel use config to enable/disable selectionboxes and highlighting
10:06 RealBadAngel it affects only nodes
10:07 RealBadAngel speed of the effect is 3.0 by default
10:25 Zeno`        I'll test this shortly. I like the idea :)
11:10 Kekun        hi
11:12 Kekun        I am developper and I'm new to minetest, I may want (with two friend dev) to help to its development
11:13 Kekun        I am still trying to get how minetest is organised as a community and as a software, and I wanted to take the temperature of the project dircetly from IRC, so here I am =)
11:14 Kekun        as far as I understand, minetest is a game engine written in C++, and games can be built around it using its Lua API?
11:19 mberends     yes, see http://dev.minetest.net
16:52 VanessaE     hmmmm: with minecraft/mojang being bought out by Microsoft, seems the call for larger worlds in Minetest, so as to handle Minecraft refugees ;-) has been renewed.
16:53 VanessaE     nore had a good start on making that a reality.  perhaps his code needs to be revisted.
16:53 VanessaE     revisited*
16:54 hmmmm        larger worlds are not happening.  worlds are large enough.
16:54 Calinou      not really
16:54 hmmmm        yes really.
16:54 Calinou      we should eventually find a way to make them larger
16:54 Calinou      you're basically saying “IPv4 has enough addresses” but in Minetest :P
16:54 hmmmm        there's a really obvious way to make them larger.  there's just no reason to and tons of rework required along with disadvantages
16:55 hmmmm        IPv4 does have enough addresses
16:55 VanessaE     define "really obvious"
16:55 hmmmm        VanessaE:  change over to v3s32.
16:55 VanessaE     oh.
16:55 Calinou      <hmmmm> IPv4 does have enough addresses
16:55 VanessaE     well I assumed something like that
16:55 Calinou      not without NAT
16:55 Calinou      not with the explosion of mobile stuff
16:55 Calinou      NAT is a plague, should just die
16:55 hmmmm        Calinou:  right, and with NAT things are pretty okay
16:55 VanessaE     but that will break things like node hash position I guess
16:55 Calinou      no, because people need to forward ports in a silly way
16:55 hmmmm        VanessaE:  LOTS of shit is going to be broken and not backwards compatible
16:55 Calinou      you can't host a service on the same port on more than 1 machine on the same network, too
16:56 hmmmm        like I said... there's no reason to make worlds larger than they are.
16:56 hmmmm        it's only a perceived limitation.
16:56 Calinou      sustainability is a reason
16:56 VanessaE     hmmmm: it needs to happen.
16:56 Calinou      some people want to keep their worlds for years
16:56 hmmmm        this can last years
16:56 VanessaE     we're about to get flooded with Minecraft refugees
16:56 VanessaE     and they will want this
16:56 hmmmm        so?
16:56 VanessaE     we should be prepated to handle it.
16:56 Calinou      large servers may eventually get their world filled
16:56 Calinou      their only solutions are resetting the world, which will anger many users
16:56 hmmmm        you're acting like this is just some kind of simple change
16:57 hmmmm        no.  it will break ALL reverse compatibility.
16:57 VanessaE     I am aware that it is not a simple change
16:57 hmmmm        and it will make data structures much larger, it will make things slower
16:57 hmmmm        basically, nasty.
16:58 Calinou      <VanessaE> we're about to get flooded with Minecraft refugees
16:58 Calinou      let BlockMen handle it ;)
16:58 VanessaE     haha
16:58 VanessaE     from a game standpoint, sure
16:58 Calinou      try not to turn Minetest into Minecraft either, it needs to keep its own philosophy and folklore
16:58 Calinou      but larger worlds won't do that
16:58 Calinou      (if they say there's not enough horizontal space: answer by saying there's too much vertical space :D)
16:59 hmmmm        the best I'll do is add 8 bits onto the X and Z components.
16:59 VanessaE     hmmmm: that's perfectly fine
16:59 VanessaE     if used properly that gives us a HELL of a lot more space
16:59 Calinou      why not Y either? (out of curiosity… because you won't end up with a perfect cube space)
16:59 Calinou      not a real problem, but just wondering
16:59 hmmmm        Calinou, because it's completley unnecessary and would necessitate the data structures used to double in size.
16:59 Calinou      OK
16:59 VanessaE     Calinou: meh, who needs thounsands of km or vertical?
17:00 hmmmm        john_minetest:  practically none.  :P
17:00 Calinou      VanessaE, no one, really :P
17:00 hmmmm        these are just irrational folk
17:00 Calinou      not really
17:01 Calinou      the current size we have is good for having several dimensions, really deep mines, really high buildings that can't be seen from ground, etc
17:01 hmmmm        I won't advocate taking away Y space but it's perfectly doable
17:01 hmmmm        we can donate those to the X and Z components
17:01 Calinou      this may break worlds
17:01 VanessaE     we have WAY too much Y space but I see no reason to cut it down.
17:01 VanessaE     (doing so would accomplish nothing)
17:01 hmmmm        if we were to cut Y space, it'd have to be in groups of 2 bits
17:02 hmmmm        so just trimming it by one notch would make it 14 bits
17:02 Calinou      eg. if you change from 32768 to 16384, you'll cut the bottom and top parts of the world
17:02 sfan5        that actually sounds like a doable idea
17:02 hmmmm        which would reduce the max height to 8192
17:02 hmmmm        and the max depth would be -8191
17:02 hmmmm        err, 8191, -8192
17:02 Calinou      what about X/Z?
17:02 hmmmm        and then we'd be able to double the max size of X and Z
17:02 Calinou      ah
17:02 hmmmm        1.6 million in each direction
17:02 sfan5        I think -16384 would be better
17:02 VanessaE     that's perfectly fine on a new world.
17:03 Calinou      15 bits is not possible, hmmmm said
17:03 sfan5        for y cutting
17:03 sfan5        no?
17:03 Krock        interesting idea to moving bits around to get more X, Z space... but that's not needed.
17:03 hmmmm        basically it's not worth it
17:03 sfan5        hm, right
17:03 hmmmm        Y will stay the same
17:03 hmmmm        again
17:03 Calinou      what about writing a converter of some sort?
17:03 VanessaE     john_minetest: "compress out" all the intervening air or stone_with_* :)
17:03 hmmmm        this is only if we are actually expanding minetest
17:04 hmmmm        this is how we would do it
17:04 VanessaE     hmmmm: then it needs done.
17:04 hmmmm        it doesn't need to be done by any means.
17:04 hmmmm        it's just some false perception.
17:04 Krock        Y U no happy with 2 bytes for each dimension?
17:04 VanessaE     I don't need it myself, I'm thinking of the future.
17:04 sfan5        adding just 1 bit would double the size of each coord. component
17:05 hmmmm        it's an incentive to build even less efficiently
17:05 hmmmm        do you realize how many hours you'd have to run in a single direction from the origin in order to get to the other side of the world?
17:05 Krock        bytes are easier to handle than bits. better let it how it is
17:06 VanessaE     hmmmm: not everyone walks/runs to get around the map
17:06 VanessaE     are you aware of the sheer number of "how do I teleport" requests I get?
17:06 hmmmm        yeah, they're teleporting around.
17:06 hmmmm        that is the ONLY, I repeat, the ONLY reason why they say there's not enough
17:06 hmmmm        if you removed teleporting you'd get no more complaints, I guarantee it
17:07 VanessaE     I don't allow teleports on my servers - if people want they, they can use travelnet booths
17:07 VanessaE     but guess what, people have managed to expand outward pretty quickly even without teleport
17:07 Calinou      <hmmmm> do you realize how many hours you'd have to run in a single direction from the origin in order to get to the other side of the world?
17:07 Calinou      suddenly, fast move ;)
17:07 Calinou      despite it being unrealistic, people use it out of boredom, but also because default walking speed is too slow
17:08 hmmmm        walking speed is too slow, blocks are too small as well
17:08 VanessaE     don't go changing the apparent block size
17:08 Krock        ehm. blocks could be smaller in my view
17:08 VanessaE     they're big enough as it is
17:08 hmmmm        they could be variable
17:09 hmmmm        or it could be an option.
17:09 hmmmm        "node_scaling"
17:09 hmmmm        or something in the config file
17:09 hmmmm        boom
17:09 VanessaE     hmmmm: visual_scale
17:09 Krock        ^ milestone 0.4.12
17:09 hmmmm        there ya go
17:09 VanessaE     if a node needs to be resized, it should use that field.
17:09 VanessaE     and we honestly just don't need that right now
17:11 hmmmm        there are so many things that need work on minetest
17:11 hmmmm        but nobody has the time
17:11 hmmmm        getting minetest to where it should be is a full time job in itself
17:11 VanessaE     hmmmm: I think a significant part of it is apathy (not you)
17:12 Krock        john_minetest, I disagree.
17:12 Krock        it was even worse
17:13 Krock        Can happen on the best OS if the drivers don't work how they should
17:14 sfan5        john_minetest: thats some problem with irrlicht
17:15 sfan5        thats new
17:16 Calinou      john_minetest, Carbone has carts + boats + hovers, that's at least 3 kinds of vehicles :P
17:16 sfan5        ignore the warning
17:17 sfan5        why are you not using luajit?
17:18 VanessaE     it works better with.
17:18 VanessaE     luajit speeds things up greatly.
17:18 VanessaE     3-100x is the current claim.  look to the lower end of that range for realistic figures.
17:19 sfan5        you don't
17:20 sfan5        you just install it
17:20 VanessaE     just install luajit and its dev package and recompile
18:55 kahrl        Adding anything less than 16 bits to a position component would mean a couple additional bitops on each position component read/write
18:55 kahrl        Much slower than simply adding 16 bits
19:14 hmmmm        kahrl, bitops are pretty fast, and I'm not sure what the impact of having an extra and/shift instruction is going to be vs. the size increase per vector
19:16 kahrl        yeah, it depends on the size of the cache I guess
23:24 RealBadAngel https://github.com/minetest/minetest/pull/1617/
23:24 RealBadAngel hmmmm, kahrl, ShadowNinja, celeron55 can you test it?
23:50 ShadowNinja  Tested, it's harder to see during the day, and at night it's too bright.
23:51 ShadowNinja  speed = 100 helps :-P
23:51 VanessaE     haha
23:51 RealBadAngel thats why speed is a variable
23:52 RealBadAngel most of folks wanted it slower
23:52 RealBadAngel but some wants it flashing like crazy
23:52 RealBadAngel do what you want with the setting
23:52 RealBadAngel 3.0 is fine for default
23:54 VanessaE     RealBadAngel: maybe it would be a good idea to allow the user to set the brightness limits?
23:54 RealBadAngel yes, and let them choose between sin and cos
23:54 ShadowNinja  RealBadAngel: I think it should do something like `light += highlight_brightness` instead of `light = highlight_brightness` so that it's darker at night.
23:55 RealBadAngel no it cannot be done that way
23:55 ShadowNinja  :-|
23:55 RealBadAngel light is not constant
23:56 RealBadAngel and we do disable the lighting for the node to get our effect
23:56 RealBadAngel and its not brightness at all
23:57 RealBadAngel its ambience light