Minetest logo

IRC log for #minetest-dev, 2015-11-07

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:52 cib joined #minetest-dev
01:06 SaphirePhenux_ joined #minetest-dev
01:17 paramat joined #minetest-dev
01:53 Player2 joined #minetest-dev
02:26 cib0 joined #minetest-dev
02:36 paramat left #minetest-dev
02:45 JohnnyComeL8ly joined #minetest-dev
03:02 Supertan1er2 joined #minetest-dev
03:12 cib0 joined #minetest-dev
04:03 sloantothebone joined #minetest-dev
04:05 ShadowNinja joined #minetest-dev
04:06 Guest56314 joined #minetest-dev
05:14 paramat joined #minetest-dev
05:46 ace joined #minetest-dev
06:04 paramat Default/mapgen: Tune biome points for improved disribution #720 https://github.com/minetest/minetest_game/pull/720
06:04 paramat left #minetest-dev
06:07 CraigyDavi joined #minetest-dev
06:34 gtown joined #minetest-dev
06:49 DFeniks joined #minetest-dev
07:01 Hunterz joined #minetest-dev
08:16 RealBadAngel joined #minetest-dev
08:19 nrzkt joined #minetest-dev
08:20 sloantothebone joined #minetest-dev
08:29 hmmmm PTAL https://github.com/kwolekr/minetest/commit​/e96f7e662f1917979da3eff87077d199c3484223
08:40 hmmmm new version: https://github.com/kwolekr/minetest/commit​/d52b6d9a15451dd0a0b00f84f7d70a5a6639f3b7
08:43 hmmmm paramat: looks nice
08:46 eeew joined #minetest-dev
08:49 ShadowNinja hmmmm: Why not just use get_content_id instead of the constants?  Also >globally scoped< a file local will do fine.
08:51 ShadowNinja GTG now though, I'll look at it closer later if it isn't merged by then.
08:55 hmmmm because constants don't hurt and they're a lot easier to reference than "the result of minetest.get_content_id("ignore")"
09:00 Krock joined #minetest-dev
09:11 jin_xi joined #minetest-dev
09:29 Megaf_ joined #minetest-dev
09:39 Calinou joined #minetest-dev
10:18 PilzAdam joined #minetest-dev
10:20 FR^2 joined #minetest-dev
10:39 blaze joined #minetest-dev
10:44 celeron55 i've been working on the FarMesh successor for a few days now
10:45 proller joined #minetest-dev
10:45 celeron55 i think this is turning out just fine
10:46 celeron55 oh... actually, more like a week
10:47 celeron55 well, this better be good or i'm totally wasting my time
10:53 Calinou does it work with all C++ mapgens?
10:53 Calinou ie. v5, v6, V7
10:58 deltib joined #minetest-dev
11:07 celeron55 yeah, but all of those make very boring landscapes at large scale
11:07 celeron55 and lua mapgens are too slow
11:07 celeron55 however, the recent built-in watershed is quite good for this
11:07 celeron55 that's what i'm using for testing
11:13 celeron55 i mean, what i'm doing is enabling the server to efficiently transfer huge areas at low resolution and the client to efficiently render huge areas at low resolution; there's no special mapgen interface at least yet
11:14 PilzAdam would it be possible that Lua mapgens supply extra hooks to generate data for clients necessary to use farmesh?
11:15 celeron55 of course but i'm focusing on the client side and the protocol
11:15 celeron55 if someone is interested on that side, they can do it later
11:34 zupoman joined #minetest-dev
11:34 zupoman joined #minetest-dev
11:34 crazyR just a quick thought.. the thought of changing the formspecs has been brought up a fair few times. but no one really want to do it due to the amount of work involved.. and due to how many changes would be required by mods etc... I understand this next suggestion doesnt really solve that issue currently but what if we added an object based formspec api in a similar fasion to smart formspcs.... that way future changes to the formspecs would be
11:34 crazyR easier to acheive.. in terms of not having to wait so long for mods to update there mods....
11:35 crazyR especially if each method used a table of variables instead of defining them ie fs_object:button(def)  --do what ever end
11:40 Hunterz thanks for addng server console :-)
11:43 sloantothebone joined #minetest-dev
12:20 celeron55 i wonder if map transfers should be prioritized globally or whether each client should get equal transfer budget
12:20 gregorycu joined #minetest-dev
12:20 celeron55 currently they are prioritized globally
12:23 celeron55 what that causes is that when a new client comes in or a client is running or flying around, it gets full transfer capacity due to the nearby blocks being transferred and pushes back other clients as needed
12:23 celeron55 i guess it makes a better experience
12:24 celeron55 but there's a problem when trying to implement that when making a protocol that allows any client to request any block
12:25 celeron55 because the server can't trust them to give any absolute priority to their blocks
12:25 celeron55 someone could just increase it and get all the bandwidth for however far areas they want
12:27 celeron55 i think i'll just give equal priority to every client and hope that it's fine for low-bandwidth servers
12:33 sloantothebone_ joined #minetest-dev
12:35 BlockMen joined #minetest-dev
12:35 Darcidride_ joined #minetest-dev
12:39 BlockMen is "looks good" equal to "+1"?
12:40 sloantothebone_ joined #minetest-dev
12:41 celeron55 i think it was decided that it isn't
12:42 BlockMen ok, can someone check #3288 then?
12:42 BlockMen https://github.com/minetest/minetest/pull/3288
12:47 celeron55 i guess those essentially mean +1 though; we _really_ need to define what all these mean
12:47 sloantothebone_ joined #minetest-dev
12:48 gregorycu Why isn't this a first class concept in github?
12:48 celeron55 i have no idea; it's indeed a bit lacking
12:48 BlockMen IMO we should use something like "good to merge", that would be clear
12:48 celeron55 BlockMen: when does this sound play in practice?
12:49 BlockMen whenever the client does not allow to place a node, e.g. where you are standing
12:49 BlockMen the serverside is not touched
12:50 celeron55 i know that; so the question is when does the client know that a node can't be placed
12:52 BlockMen when nodePlacementPrediction returns false, see https://github.com/minetest/minet​est/blob/master/src/game.cpp#L889
12:53 gregorycu celeron55: How do you feel about splitting up the algo that decides what blocks to draw, vs what blocks the server should send?
12:53 celeron55 looks like it's only a few special cases; 1) the mapblock where the node is being placed isn't loaded, 2) the node being pointed is not buildable_to, 3) the node being placed is attached_node and the pointed node is not walkable, 4) the node is being placed where the player is standing
12:53 kilbith joined #minetest-dev
12:54 BlockMen celeron55, the other cases can be done by mods
12:55 celeron55 does it make sense that the sound is defined by the node being placed and not by something else
12:55 gregorycu You think the pointed-to node?
12:56 gregorycu (As an example)
12:56 celeron55 what kind of sound is that even
12:56 BlockMen its equivalent to the place sound (which is also defined by the node going to be placed)
12:57 BlockMen i would use some "error" sound, but you dont have to use it. it is just adding the ability to get feedback (as requested)
12:58 gregorycu Could an alternative idea for the ability to play an arbitrary sound at any stage? And users can hook node placement failure and do whatever they want (which may include a sound)
12:58 celeron55 ok that makes sense; i can imagine that for example just a lower or higher pitch variant of the normal sound would make sense
13:01 ElectronLibre joined #minetest-dev
13:01 celeron55 that isn't going to fit in a 23-line patch
13:03 cib0 joined #minetest-dev
13:14 kilbith left #minetest-dev
13:20 gregorycu Given that the current frustrum culling is a bit buggy, why doesn't minetest just use the built in frustum culling that's part of irrlicht?
13:21 celeron55 because minetest does other things alongside it that irrlicht doesn't do
13:22 celeron55 and there might be some specialization in it anyway; irrlicht is not a boxel engine
13:23 celeron55 for one, minetest doesn't update the list of blocks to be rendered on every frame, and it does software occlusion culling
13:23 celeron55 i mean, this is not a thing that is just there "because random" like many things are
13:24 gregorycu I figured that a reason is that the server uses exactly the same logic to determine what to send
13:24 gregorycu Wasn't sure if that was the end of it
13:24 celeron55 the server doesn't know the client's FOV
13:24 celeron55 that's an issue
13:24 celeron55 i'm probably removing that particular piece of code though; now stop asking so that i can code
13:25 Calinou fov = 170
13:25 Calinou 8)
13:25 celeron55 nothing progresses when we just talk here
13:25 gregorycu Are you redoing the server side stuff? Or also the client side frustum
13:25 celeron55 go fix a bug
13:25 gregorycu I am
13:25 celeron55 no you aren't; you are talking!
13:26 gregorycu I'd prefer to talk before starting dev, rather than after and get "why the hell did you do that"
13:27 celeron55 well don't touch that now, it's pretty close to what i'm wiggling around currently
13:28 gregorycu Ok, I'll do something else
13:41 o_O joined #minetest-dev
13:45 Fixer joined #minetest-dev
13:58 ElectronLibre joined #minetest-dev
14:17 BlockMen mergin now #3288
14:21 gregorycu_ joined #minetest-dev
14:22 jin_xi joined #minetest-dev
14:24 zat joined #minetest-dev
14:25 gregorycu joined #minetest-dev
14:34 kaeza joined #minetest-dev
15:18 rubenwardy joined #minetest-dev
15:20 Taoki joined #minetest-dev
15:54 est31 joined #minetest-dev
16:02 est31 about the client requesting blocks from the server principle vs. the server deciding what to send. In the setup with the client asking, we can't really implement any occlusion culling. If there was, it would be slowed down by the factor (network ping time) * (viewing range). Because, the client doesn't know whether the block ahead of it is transparent or has non-transparent holes. So it has to wait for the server to send the block, and only once
16:02 est31 its there, it can decide whether to request the block behind it, or whether to decide the block behind it is occluded, and not request anything.
16:03 est31 I know that ppl like PilzAdam want the client to request them, but I think the use cases can be solved by changing the protocol at other points.
16:04 est31 just my 2 cents.
16:22 hmmmm joined #minetest-dev
16:39 celeron55 http://i.imgur.com/8UfG4Sy.jpg
16:39 celeron55 this may not be the prettiest forest renderer...
16:39 celeron55 ...but that fog stops at 1000 nodes
16:40 nrzkt strange leaves :p
16:41 celeron55 wait, no; 800 nodes
16:50 hmmmm thought you were working on client side modding
16:51 Calinou would it be possible to have transparent water?
16:52 celeron55 joined #minetest-dev
16:56 hmmmm I advocate not having client request blocks
16:56 hmmmm I used to from a design standpoint, but practicality ultimately wins here
16:56 hmmmm the server has nearly all of the information it needs
17:00 hmmmm merged https://github.com/minetest/minetest/commi​t/f9e394a4669e667fcef8992946458c769b4e2770
17:00 hmmmm hopefully people can get off my back now
17:03 celeron55 i'm effectively making a client-requests-blocks system now though; it's fine
17:03 hmmmm well
17:03 celeron55 the server doesn't have much time to do any fancy occlusion culling or stuff like that anyway
17:04 hmmmm i wanted to modify the current system so that it lowers the priority of blocks that are completely transparent
17:04 hmmmm i hope this could become accomodated somehow
17:06 celeron55 it doesn't really matter who invokes the server to check if a block is transparent, the server itself or the client
17:06 celeron55 this is a non-concern
17:09 celeron55 of course i'll change it if it doesn't work, but it seems to work
17:12 DFeniks joined #minetest-dev
17:16 celeron55 there are good and bad sides in both solutions actually
17:17 celeron55 practically thinking, that is
17:17 celeron55 it comes from the fact that the algorithm needs information from both the server and the client, no matter which one it is running on
17:18 celeron55 and that information includes more from the client side than just a position
17:18 celeron55 or just the things that would be sent anyway
17:23 PilzAdam joined #minetest-dev
17:36 celeron55 here's a watershed mountain: http://i.imgur.com/DIsRLbl.jpg
17:39 rubenwardy that's cool
17:39 rubenwardy what's the bottleneck now, stopping you looking further? Mapgen?
17:39 Krock Fancy stuff
17:40 celeron55 mapgen mostly; it doesn't trigger mapgen yet at all
17:41 rubenwardy I see
17:41 celeron55 of course generating that far is very slow especially as transfer is symmetrical to all directions in true minetest fashion
17:41 celeron55 and transferring and mesh generation that far does take minutes
17:42 rubenwardy even at a lower LOD?
17:42 celeron55 or, well i suppose the bottleneck in loading time is the server that doesn't save anything on disk to speed up loading
17:42 celeron55 that is the best LOD; worse isn't faster in practice
17:42 celeron55 it's going to be static because nothing else makes any sense
17:43 rubenwardy does the server send the whole block and the client lowers the res, or is the lower res done on the server?
17:43 celeron55 the server generates the low-resolution blocks
17:43 rubenwardy awesome
17:43 celeron55 they are called FarBlocks and their size is 8x8x8 MapBlocks
17:44 celeron55 that again is probably the only size that makes sense
17:44 PilzAdam joined #minetest-dev
17:51 Calinou doesn't it generate a lot of load on server-side?
17:51 celeron55 yes
17:51 celeron55 a lot of load and lagginess with my current implementation that isn't intended for real use
17:52 celeron55 it probably needs caching
17:52 hmmmm you're really good at making quick prototypes of advanced features but you never polish those features
17:53 hmmmm and they remain very slow or have some kind of subtle bug
17:53 hmmmm please, deliver a whole product
17:55 celeron55 we'll see
17:55 hmmmm as I've said before, anybody can code but not everybody can make a solid, well-designed, flexible implementation of a feature
17:56 hmmmm i don't mean any offense to RBA, but look at him as an example of this
17:56 hmmmm he codes all these flashy things, pushes them half-assed and as-is, and then expects the rest of us to polish the turd
17:56 celeron55 lol
17:56 celeron55 that is an offence to me though
17:56 celeron55 offense*
17:57 hmmmm meanwhile he walks away with all the internet praise
17:58 celeron55 why are you telling this to me when i am showing an alpha version?
17:58 celeron55 you can trust me for sure
17:59 celeron55 there are people you shouldn't trust; i find it silly and annoying that you consider me one
17:59 celeron55 it's like you'll tear this whole project apart if i push something upstream without your precious permission first
18:00 hmmmm it's not *my* permission, I just happen to be around a lot of the time
18:00 celeron55 i appreciate the quality control, but you don't have to remind me of it all the time
18:00 celeron55 i get it
18:00 celeron55 do you get it that i get it?
18:01 hmmmm ok mister "I need smart pointers because my code keeps segfaulting on me"
18:01 celeron55 even if i push something half-assed, i do it with the full knowledge that it will make people miserable
18:01 celeron55 there are people who will push shit without understanding what it causes
18:02 hmmmm i try my best to prevent this from happening but it's inevitable sometimes
18:03 hmmmm we should get back to coding
18:04 celeron55 well, i've coded for 9 hours straight already so i kind of need a break already 8)
18:04 hmmmm that is admirable focus
18:06 celeron55 admirable lack of real work
18:09 celeron55 this is hard as fuck compared to anything though
18:09 celeron55 hmmmm: can you tell me how all the server's things are currently supposed to be locked these days?
18:09 celeron55 because it's one thing that has changed a lot
18:10 hmmmm conlock is sort of an obsolete thing i believe since those operations are totally encapsulated in connection.cpp
18:10 hmmmm envlock needs to be practically everywhere and it already is
18:10 hmmmm scriptlock is only active inside of the on_foobar() callbacks, from SCRIPTAPI_PRECHECKHEADER to the end of the scope it's defined in
18:11 hmmmm envlock always needs to be locked before scriptlock
18:11 rubenwardy joined #minetest-dev
18:11 hmmmm and that's it
18:13 A_noob joined #minetest-dev
18:13 celeron55 i suppose the best way to generate something on the server side from map data is to grab a big chunk into a VoxelManipulator and throw it into a worker thread
18:13 hmmmm huh?
18:14 hmmmm in any case, I hope you're not going to bring back map generation in the serverthread...
18:14 celeron55 WTF :D
18:14 hmmmm remember that?
18:14 celeron55 this is already absurd
18:14 hmmmm generateBlock()
18:14 celeron55 stop it
18:14 celeron55 stop it!
18:14 hmmmm anyway
18:15 hmmmm what are you doing with generating now?
18:15 hmmmm it might be a good idea to throw it into an EmergeThread and then resume what you're doing upon emerge completion
18:15 celeron55 i need to generate low-resolution map data (FarBlocks) from the high-resolution normal map data (MapBlocks); and that is done in chunks of 8x8x8 MapBlocks
18:16 celeron55 and uses a special algorithm that does tricks to figure out how to best represent the map in low resolution
18:16 hmmmm and these FarBlocks are not being stored on disk, right?
18:16 celeron55 i don't intend to, but i don'ẗ know what people end up wanting
18:17 hmmmm well
18:17 celeron55 that would allow quite glorious resumption of singleplayer games, but it's out of scope for me at the moment
18:17 hmmmm I am pretty sure this operation will need to be done completely under envlock
18:17 hmmmm since you're accessing 512 mapblocks in a single operation
18:18 hmmmm how slow is the actual downscaling algorithm?
18:18 hmmmm what is the downscaling algorithm, first of all
18:19 celeron55 well it's not exactly blazing fast as it needs to figure out how to scale down 2097152 nodes
18:19 celeron55 it doesn't read all of them but some
18:20 celeron55 i guess essentially it's as slow as a fast map generator
18:21 hmmmm the result from your algorithm represents an 8x8x8 chunk of mapblocks but that doesn't mean it actually needs to downscale all the nodes
18:22 hmmmm this is just going to operate on each of the 6 faces of this region, right?
18:22 hmmmm so really the worst case should be (8 * 16)^3
18:22 hmmmm * 6
18:23 hmmmm errm i mean (8*16)^2 * 6
18:23 celeron55 it operates on volumes but is mostly interested in figuring out how the topside of each 4x4x4 chunk of nodes looks like
18:24 hmmmm my concern is that this sounds really heavyweight and we're going to be spending a lot more server time than necessary on this operation
18:24 celeron55 currently it iterates through one Y column, finding a surface and then based on that data it guesses something
18:24 celeron55 it needs more to lessen the prominence of tree trunks and other thin objects
18:25 celeron55 anyway, the value you are looking for is a few hundred milliseconds
18:25 hmmmm and whether it's copying 512 mapblocks to a voxelmanipulator and doing lockless operations or whatever, i suspect a significant amount of time will be spent slowing everything else down
18:27 celeron55 i'm not going to do it synchronously if i can avoid it
18:27 celeron55 but the prerequisite to that is being able to copy 8x8x8 MapBlocks with considerably less time than that
18:27 celeron55 i guess adding this to be done inside emergethread as it loads and generates stuff would work fine
18:27 celeron55 it can be done incrementally one mapblock at a time as the data is kept around as a cache anyway
18:28 hmmmm that actually sounds fine to me
18:28 hmmmm the emergethread is pretty much the perfect place to add this
18:29 celeron55 one thing that isn't wise is generating this from the 512 mapblocks when the client asks it or the server decides to send it for some other reason, even if the data was cached in the mapblocks itself
18:29 celeron55 or, at least i suppose si
18:29 celeron55 so*
18:30 technics joined #minetest-dev
18:30 celeron55 a parallel FarMap/FarSector/FarBlock thing is probably wisest as then all the data is in exactly organized in the format that has to be sent to the client; it's then just a matter of doing one lookup and telling the networkings to throw it on the wire
18:31 hmmmm omit the FarSector perhaps
18:31 hmmmm MapSector is a relic of the past.  it does not make sense to have this data structure in modern minetest.
18:33 celeron55 well, i suppose so
18:33 celeron55 it would be a good place to do some Y-wise optimization but as we kind of try to avoid those, it's useless
18:47 celeron55 funnily enough one of the slowest things FarMap has to do is rendering fill-ins for the transition from MapBlocks to FarBlocks
18:48 celeron55 essentially MapBlock meshes with FarBlock mesh content; very small meshes but just as many as there are MapBlocks which slows it down
18:48 celeron55 i need to test whether 4x4x4 would be better than 8x8x8 due to that; but i don't really like the idea
18:53 celeron55 well, i think it'll be fine; maybe i'll restrict MapBlock rendering to 2x2x2 MapBlock chunks to get rid of the unnecessarily small things
18:53 hmmmm why does this matter?
18:53 hmmmm just make it a config option and let other people tune it for you
18:55 celeron55 it matters because if i can determine that something isn't needed at all, there doesn't need to be an option for it
18:55 celeron55 of course this whole thing is optional to begin with because i'm sure some people will absolutely hate it
18:55 celeron55 personally i already absolutely love it
19:05 Fixer joined #minetest-dev
19:09 celeron55 it's like a large part of buildat was actually useful after all, as this is one of the features that i originally made for it
19:09 celeron55 (while this doesn't use much of the same code at all)
19:09 celeron55 it's the same concept and same tricks
19:30 Fixer left #minetest-dev
19:30 Fixer joined #minetest-dev
20:11 RealBadAngel joined #minetest-dev
20:19 celeron55 actually; it looks like 4x4x4 is simply not faster at all when rendering the kind of distances that i want to render
20:20 celeron55 it's because while the mini-mapblock count goes radically down, the bulk FarBlock count goes even more radically up
20:21 celeron55 and that's not good 8)
20:46 celeron55 so
20:46 celeron55 what's up with all these setting locations now
20:47 celeron55 where's a script that i can use to update minetest.conf.example from builtin/settingtypes.txt or the other way around
20:48 celeron55 not under util/ at least; i would have hoped to find one
20:52 PilzAdam celeron55, that is still TODO
20:53 PilzAdam look at the bottom of settings.lua
20:53 PilzAdam in builtin/mainmenu
20:55 PilzAdam I guess maybe we can just run tab_settings.lua from a shell script, and it generates minetest.conf.example if it detects that core is nil
20:55 celeron55 also the simple settings menu should still be available
20:56 PilzAdam yeah, I asked on the forums and most people would like to keep the old one
20:56 PilzAdam although I think that we should reconsider which exact settings it should contain
20:56 DFeniks joined #minetest-dev
20:56 celeron55 yeah the content of it was quite random
20:56 celeron55 but it would be better as-is than to have nothing
20:59 kaeza joined #minetest-dev
21:12 hmmmm advanced button
21:12 kaeza greetings. having this issue since about a while ago: https://gist.github.com/kaeza/8b2d457c36cd52020501
21:12 kaeza can somebody with MinGW32 (sfan5) test?
21:14 kaeza also, some warnings in case somebody cares: https://gist.github.com/kaeza/dec0af3158da63aa2c5d
21:38 JohannesG joined #minetest-dev
21:45 ElectronLibre left #minetest-dev
21:51 rubenwardy joined #minetest-dev
21:53 kaeza can somebody recommend a good (preferably open source) RTS?
21:54 kaeza I'd settle for some crappy turn-based RPG
21:55 kaeza but pls no Nethack or Battle for Wesnoth
21:55 kaeza oops wrong chan
21:55 kaeza sorry
22:00 Fixer joined #minetest-dev
23:20 paramat joined #minetest-dev
23:20 paramat so good to see new farmesh
23:21 paramat i tend to create huge structures so it will be very usable
23:22 paramat reading logs..
23:24 paramat hmmmmm good vm docs, i learn a lot from this

| Channels | #minetest-dev index | Today | | Google Search | Plaintext