Time  Nick     Message
01:11 hmmmm    hmmm
01:12 hmmmm    you know, the whole "here's the default, just change it if it's not default" paradigm is out the window now that i have to allocate all noiseparams
01:21 hmmmm    alright, i guess proller had the right idea
01:22 hmmmm    i won't even do that though
01:23 hmmmm    if i just leave it as null, that'll be fine.. if it crashes, then it's clearly an internal problem, not a problem with the way i made the interface
01:25 hmmmm    the whole point of having the default defined constants for noiseparams was:  here are the initial, default values for this mapgen.  great, try getting the values from map metadata, okay, then try getting them from the config, and so on
01:26 hmmmm    honestly, the entire mapgen parameter system is fucked.  it's totally overcomplicated for what it is
01:26 hmmmm    but before i start calling it crap, how can i do it better?
01:27 hmmmm    make more assumptions?
01:33 hmmmm    i can simplify things somewhat and clean up bad code by making defaults for the Settings when the map metadata is read
01:35 hmmmm    set all the defaults to an empty string so 1). it doesn't throw a stupid exception, preventing the rest of the metadata from being read, and 2). i'd be able to tell which settings need to be fetched from the config at least
01:36 hmmmm    but what i really want the default to be is the contents of the global config
01:37 hmmmm    map metadata has the highest precedence, then config, then defaults, so it'd make sense to write the defaults, write the config, then write the map metadata
01:38 hmmmm    i guess the reason why i read the config only after the metadata fails is to prevent duplicate work
01:39 hmmmm    and then on top of all this nonsense, i still have to handle the fixed seed specially
01:50 hmmmm    you know, it'd probably be better if i just expand Settings to do what i want it to do
01:51 hmmmm    getNoEx()
20:35 sfan5    can I commit a fix for the uk translation? its annoying that I need to fix it myself before making a win32 build
20:36 PilzAdam link?
20:36 sfan5    well, I don't have a link
20:36 sfan5    i'll just add "\n" to the entry that causes the problem
20:37 sfan5    add = prepend
20:37 PilzAdam seems good then
20:37 sfan5    ok
20:37 Jordach  when did we have a united kingdom translation
20:38 sfan5    https://github.com/minetest/minetest/commit/f9b5771274f662ed12c209c3f1b563eb29d99ca7
20:39 sfan5    that translation contains russian things, but whatever
20:39 sapier   uk translation with russian entrys?
20:39 sfan5    yeah
20:40 sfan5    look at it: https://github.com/minetest/minetest/blob/master/po/uk/minetest.po
20:40 sapier   sounds wrong to me ... isn't anyone else puzzled too?
20:40 PilzAdam sfan5, seems to work fine
21:05 sapier   does anyone have an idea how to portably call unzip from within minetest?
21:06 Calinou  os.execute()?
21:06 sapier   portably ;-)
21:06 sapier   "unzip" most likely isn't available on windows ;)
21:07 PilzAdam who cares about windows ;-)
21:07 sapier   I do as I want to improve usability of minetest
21:08 sapier   I already managed to create a ingame mod manager fixing common mod problems on it's own but this isn't very usefull if those users most likely to do those mistakes can't use it
21:10 sapier   e.g. mod having wrong dirname
21:44 PilzAdam any objections to this: https://github.com/Warr1024/minetest/commit/4c2459852968f4564688fe356407367c791de67e
21:44 PilzAdam I have tested it and it works fine
22:10 tucebrin i need assistance
22:12 PilzAdam tucebrin, note that this channel is for core development only; go to #minetest for anything else
22:12 tucebrin may i pm you?
22:12 tucebrin its just a simple thing
22:12 PilzAdam sure
22:31 kahrl    sapier: include the minizip source (adjusted as needed)
23:09 sapier   looks reasonable kahrl ... I guess I have to add some filesystem handling support to core in order to get mod/game whatever management done in a portable way
23:14 sapier   https://github.com/sapier/minetest/tree/next_gen_main_menu prototype mod and game manager , enable by setting "main_menu_game_mgr" and "main_menu_mod_mgr" in minetest.conf to 1
23:15 sapier   I'm going to move the filesystem functions to core, it's way more portable than doing this in lua
23:18 Warr1024 Would changing the server-side FOV to 180 really have a significant impact on bandwidth?
23:18 Warr1024 I thought that the blocks sent to the client were rate-limited somehow...
23:18 sapier   as you say "somehow" ;-)
23:18 Warr1024 ...so that would mean that you'd get wider near-terrain faster, and it'd take a bit longer to get far terrain...?
23:19 sapier   as far as I know player fov is used to determine wich blocks to send ... but I'm not sure if this is the only limitation
23:19 Warr1024 I guess it doesn't seem right to leave it locked in at 72 and have a 72-degree swath in the middle of your vision get loaded, and have to turn your head to get the rest.
23:19 Warr1024 sapier: the server doesn't know the player's FOV, it uses a hard-coded 72-degrees.
23:20 sapier   ok maybe 72 degrees have been a evaluated value ... maybe they were just some number set when programming ... who knows ;-)
23:20 Warr1024 I started the work on adding a TOSERVER_FOV packet to the proto, so the server would know each player's REAL FOV, and send the correct blocks.
23:21 Warr1024 that would be a more optimized solution, but it's significantly more code, and complexity, added than the fixed 180 solution.
23:21 sapier   how do you protect server from malicious clients?
23:21 hmmmm    erm
23:21 sapier   e.g. player fov 360
23:21 Warr1024 well, clients can't specify an FOV more than 170 degrees, actually.
23:21 hmmmm    probably not a good idea to do that
23:21 Warr1024 do which?
23:22 hmmmm    _i_ have plans to rip that entire FOV thing out and just send everything in a D-sized radius
23:22 Warr1024 yeah, I like that idea...
23:22 hmmmm    there'd have to be a loading screen though
23:22 Warr1024 even though you're sending blocks behind the client, it's pretty easy for them to just whip their head around...
23:23 hmmmm    so that first radius of blocks is completely loaded when the client actually starts to play
23:23 Warr1024 ah, I see
23:23 hmmmm    every time the player moves and crosses a block boundary, the blocks in the new radius that weren't sent are then sent
23:23 sapier   do we know how performance is effected by a change like that?
23:23 hmmmm    so the edge of the radius keeps getting updated this way
23:23 hmmmm    it shouldn't matter in theory
23:23 sapier   maybe it's even a improvement .. I just don't have any idea ;-)
23:23 hmmmm    the performance is going to be roughly the same
23:24 hmmmm    you're still sending the same amount of blocks in the same timeframe
23:24 hmmmm    just in a different order
23:24 hmmmm    as for setting the FOV wider, well
23:24 hmmmm    having the server know any sort of FOV is a bad idea
23:24 Warr1024 if network bandwidth is an issue, then the better solution is probably bandwidth limiting and better traffic prioritization, instead of trying to limit FOV server-side.
23:25 sapier   I assume latency is more an issue than bandwidth
23:25 hmmmm    perhaps you should check out https://github.com/minetest/minetest/commits/client_requests_blocks_2
23:25 Exio     sapier: actually, it is both
23:25 hmmmm    should also see an increase in performance if TCP is used to transfer blocks
23:25 Exio     as sending stuff is very slow
23:25 sapier   oh :-) I remember your connection is quite slow exio
23:25 hmmmm    the main bottleneck in singleplayer at least is the mesh making
23:26 hmmmm    so even though the client might receive the blocks fast enough and all, it can't make the meshes for them fast enough
23:26 Warr1024 hmmmm: yeah, that's a pain point for me on my Atom n450 :-)
23:27 Exio     i'd actually like the "client_requests" way for that
23:27 Warr1024 so the idea is to have the client tell the server what blocks it needs instead of having the server use the player position tracking data and sending them unsolicited?
23:28 sapier   I don't think this is a good idea warr1024
23:29 Warr1024 which idea isn't good?
23:30 Exio     limiting that server-sidely
23:30 sapier   allowing client to request data ... this way you need a client to guess whats required and server needs to do same thing to protect itself
23:30 Exio     but allowing the clients to request "how many" do they way
23:30 Exio     s/way/want/
23:30 Warr1024 ok, well, that makes sense if the blocks client-side are stale and only the server knows they've changed...
23:31 Warr1024 yeah, sorry, I'm late to the party, so to speak, and am still learning the internals.
23:31 Exio     sapier: moving stuff to the client seems something what needs "to be done"
23:31 sapier   no problem ... we all are ;-) except maybe celeron ;-) but I assume not even he knows every single detail
23:31 hmmmm    the reason why that's "something to be done" is because the FOV check is cpu intensive
23:32 hmmmm    if we remove the FOV check completely, then we don't need the client to request the blocks anymore
23:32 Exio     why not?
23:32 hmmmm    why would you?
23:33 Exio     i'm not saying the client requesting the blocks
23:33 Warr1024 I guess all the client needs to do is ACK/NAK whether it successfully received the blocks, and the server can just decide and prioritize the blocks to send to the player.
23:33 sapier   a client never will know what blocks have been changed by other players ... server still needs to be able to override clients requests to speedup display of changes
23:33 Exio     but "limiting" the radius
23:33 hmmmm    you can move it to the client if you'd like, but like sapier said, if you'd like to protect against abuse you're going to have to duplicate drawing up a list of which blocks that the client needs anyway
23:33 Warr1024 Exio: you're saying have the client send its draw range to the server so the server doesn't waste time sending blocks to the client that won't be immediately drawable?
23:34 Exio     exactly
23:34 Exio     what will be the point of having a radius of 15 mapblocks in memory in a netbook if it can barely render some near ones?
23:34 Exio     s/will/would/
23:34 Warr1024 you could do that, but if the server prioritizes near blocks first anyway, it doesn't necessarily hurt to send them, as you might need them later...
23:35 Warr1024 after all, that's less the server will have to send once you start walking.
23:35 sapier   I don't think having them in memory is a problem ... loading and transfering most likely are the critical paths
23:35 Exio     as there is no client-side prediction for most of stuff, you need to wait (atm) for the whole world to load to be able to do stuff
23:35 Exio     like using a bucket
23:35 Exio     the whole world around*
23:36 Warr1024 yeah, the process of emerging a new player is tricky for me on my netbook.
23:36 Warr1024 I noticed that my player sprite enters the world, and its controls are uninitialized, almost immediately
23:36 sapier   you'll always need to wait for server ;-= prediction just fools user to not recognize he's waiting ,-)
23:36 Warr1024 but it can take up to half a minute to load item visuals, during which time I'm exposed and vulnerable...
23:37 Exio     nah, not that
23:37 Warr1024 I was thinking I should file a bug about it, since IIRC one of the other devs said that we should probably change that sequence.
23:37 PilzAdam if I want to delte all meshes in MeshUpdateThread::m_queue_out should I create a destrcutor in MeshUpdateThread or loop through m_mesh_update_thread.m_queue_out in ~Client() and delte it there?
23:37 PilzAdam *delete
23:38 Exio     sapier: if you want to play an online game
23:38 Exio     you do NOT want to see the lag
23:38 sapier   I theory the one creating the mesh is responsible for deleting it
23:39 Exio     i mean, being able to identify it, yes
23:39 Exio     but affecting the gameplay thanks "to that"?
23:40 sapier   exio I'm completely with you about hiding the lag but there's a tradeoff when moving to client ... if you move to much you either open up far more ways for a client to crash your server or need to do doublecalculations
23:41 Exio     both sides needs to share stuff
23:42 sapier   sharing between multiple partners is one of the big (in general) unsolved issues of computer sciences ;-)
23:42 Exio     or you will end with a quake3 where you can't play with more than 150 ms of latency without getting a shitty gameplay, or a game where for cheating you just comment safety-checks
23:42 Exio     s/needs/need/
23:42 Warr1024 The amount of stuff NOT happening on the client was actually one of the things I really liked about minetest as compared to certain other mine* games.
23:43 Exio     sapier: i mean the server and the client
23:43 Exio     you can't let the client "manage alone" the movement, as you can't let the server alone do that
23:43 Exio     you need to do some stuff in the client and server
23:43 Warr1024 I hate when client-side prediction tells me that something happened that the server rejected, and I get rewinds...
23:43 sapier   it's not only server <-> client it's server <-> n* clients
23:45 Exio     sapier: hmm, "you open X door", when you right click - some code runs on the client(for example), and it changes "door:closed" to "door:open" with some other code for doing that in reverse
23:45 Exio     if the packets are sent in order(?) the player would open it, join in the house, and then close the door
23:46 sapier   and what happens if some other player in right same moment does same?
23:46 Exio     that would be like a race-condition, actually in MC if you open a door what got open by other player it "keeps open" (iirc)
23:46 Exio     didn't try for a while
23:47 Exio     (or gets toggled, i can't recall atm)
23:47 sapier   difficult to handle in consistent way with prediction
23:47 Exio     what do you suggest for that, making the client wait "always" for the server?
23:48 Exio     for some of that stuff, i mean
23:48 sapier   I don't want to suggest something at current point of discussion I just point at the issues I recognize
23:49 sapier   I want to finish some of my open tasks prior starting a new one ;-)
23:49 Exio     i actually would prefer a race-condition-based client-side prediction more than a based-on-server-response
23:59 PilzAdam anything against this: https://github.com/PilzAdam/minetest/commit/9397b5de083fabe2e93c55de5bf90e5c75bbe9c1 ?