Minetest logo

IRC log for #minetest-dev, 2014-10-08

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

All times shown according to UTC.

Time Nick Message
00:09 hmmmm damn
00:15 hmmmm what on earth
00:15 hmmmm paramat, how are you calling calc_lighting?
00:17 hmmmm there are definite problems with calc_lighting... was I drunk when I wrote that or something?  WTF
00:18 hmmmm *did* I write that?
00:22 hmmmm actually, nevermind... all that code makes sense
00:25 hmmmm sorta wonder if this is a problem with mapgens in general
00:25 paramat hmmmm, hi im back, i'll post more details in the issue
00:25 hmmmm could try setting the water level to 47 or 48
00:25 hmmmm and try with mapgen v6 or something
00:26 paramat the water is identical to default water except for texture
00:26 paramat i'll try adding 'sunlight propagates = true' for the water
00:27 hmmmm what setting does water in the default game have to decay sunlight?
00:27 paramat that mapgen has this at the end of the mapgen loop: vm:set_data(data) vm:set_lighting({day=0, night=0}) vm:calc_lighting() vm:write_to_map(data) vm:update_liquids()
00:28 paramat um dunno
00:28 hmmmm the chunk is -80 to 47 inclusive, then the next chunk up is 48 to 127 inclusive,
00:28 hmmmm and this happens for water placed at y=47
00:28 hmmmm is the level of the water = 47?
00:28 paramat not for placed water no
00:29 hmmmm you know what i mean
00:29 paramat the water nodes are at y == 47
00:29 hmmmm like is y=47 the first node of water
00:29 hmmmm and y=48 is air
00:29 paramat yes
00:29 hmmmm okay
00:29 hmmmm here's what I think is happening:
00:29 hmmmm 127 .. 48 turns out to be all LIGHT_SUN
00:29 hmmmm then the next chunk starts getting generated
00:30 hmmmm the overtop is LIGHT_SUN - 1 because it's == to water
00:30 hmmmm because the last node wasn't == LIGHT_SUN, it doesn't bother propogating it downward
00:30 hmmmm see how it continues
00:31 paramat erm i thought overtop would be air
00:31 hmmmm erm, okay, overtop is air
00:32 hmmmm that's true... wait, are you sure that it's not for water that starts at y == 48?
00:32 paramat yes sure, double checked
00:33 hmmmm no idea
00:34 paramat bizarre innit?
00:34 hmmmm well first I need to figure out which attribute controls how the light decays from it
00:34 paramat i shall ponder
00:35 hmmmm because if you look, it doesn't have sunlight_propogates = true nor light_propgates = true
00:36 kahrl hmmmm: paramtype = "light" implies light_propagates = true
00:36 kahrl (but not sunlight_propagates)
00:37 hmmmm did not know that
00:37 kahrl it's a bit weird
00:37 hmmmm aha so that's how water works :)
00:39 hmmmm this is a mystery to me.
00:40 paramat normally water is at y==1, and light is assumed 'underground' below water level
00:40 hmmmm true
00:41 hmmmm well technically it is
00:41 hmmmm er rather, no
00:42 hmmmm that's not how water level is defined, water level is defined to be the height at which anything below that is water
00:42 hmmmm er nope
00:42 hmmmm i was right the first time
00:42 kahrl water & sunlight_propagates interact weirdly in other areas as well, just checked: water source nodes created by mgv6 or minetest.add_node (below open sky) have a light level of 13, whereas 15 when they are created by transformLiquids
00:42 paramat oops i'm probably wrong with that
00:43 kahrl which is why taking water with a bucket, waiting for the water to flow back and then dumping the water back makes the water darker
00:43 kahrl (darker than it was after flowing back)
00:44 hmmmm yeah, but, this has nothing to do with the sunlight not propogating if the overtop is indeed air with param1 == LIGHT_MAX
00:44 paramat i'll try 'sunlight propagates = true' for this freshwater as a potential hacky fix
00:45 hmmmm paramat, is water_level == 47 in your mod?
00:45 paramat it's not set to that, only singlenode is set
00:46 hmmmm hmm
00:46 paramat my code https://github.com/paramat/riverdev/blob/master/init.lua
00:47 paramat and minetest.set_mapgen_params({mgname="singlenode"})
00:47 hmmmm okay
00:48 hmmmm so if indeed y=48 is air, and then y=47 is water, which has sunlight_propogates = false, then it should be that y=48 has param1 == LIGHT_SUN, and y=47 has param1 == 0
00:49 hmmmm then when the sunlight is being spread...
00:49 hmmmm because that's the highest node, it doesn't get the lightval of the neighbor above
00:49 hmmmm which was sun
00:50 hmmmm solution:
00:50 shadowzone joined #minetest-dev
00:50 paramat if i remove 'vm:set_lighting({day=0, night=0})' bug is fixed but everything is fullbright, even caves
00:51 hmmmm swap lines 1063 and 1064 with 1065
00:51 paramat i can try that
00:51 hmmmm in other words, make the first solid node == to LIGHT_SUN
00:52 hmmmm this is going to make water lighter everywhere btw
00:52 hmmmm but it's probably the right thing
00:52 hmmmm i like lighter water tbh
00:53 paramat i'll test that tonight and let you know
00:54 paramat guess my use of water at chunk borders is exposing a bug
00:55 hmmmm fun fact, the original propogateSunlight() has this bug too
00:59 paramat weird how generating the lower chunk first erases the bug
01:04 hmmmm alright, my light implementation is foobar
01:04 hmmmm er actually no it's not
01:05 hmmmm try changing line 1073 to         for (int y = a.MinEdge.Y; y <= a.MaxEdge.Y + 1; y++) {
01:08 paramat okay, as well as the line swap?
01:08 hmmmm no, don't do the line swap
01:08 paramat okay
01:08 paramat spread sunlight across chunk border
01:09 hmmmm welll
01:09 hmmmm what you're really doing is spreading the sunlight down from the overtop
01:10 hmmmm the overtop has sunlight, but the top of your current chunk is a solid material and therefore has light value 0
01:10 hmmmm that's fine or whatever for sunlight propogation, but when you go to actually spread the light, it won't ever get that sunlight from the overtop and remain 0
01:11 paramat line 1073 works upwards, should it work downwards?
01:12 hmmmm no, the spread doesn't matter at all
01:12 hmmmm just the order in which the sunlight is propogated downward
01:12 hmmmm the spread is ordered Z, Y, X for best cache coherency
01:12 TheKingDoof joined #minetest-dev
01:13 paramat okay thanks will test your idea later
01:13 paramat another quick question, people are considering varying the lower limit of desert stone, instead of being constant at water level, is this allowable or considered 'breaking mgv6 maps'?
01:14 paramat i suggested a fixed distance below surface level
01:14 hmmmm it's allowable because it would be a setting that stays at the v6 default
01:14 hmmmm by default
01:14 hmmmm but when people modify it they obviously don't expect things to be consistent with other v6 maps
01:15 paramat ah so it would have to be selectable through a setting, i was thinking hardcode it
01:15 hmmmm mapgen specific setting
01:16 hmmmm mgv6_desert_depth
01:16 hmmmm or something
01:18 paramat okay
01:20 DuDraig joined #minetest-dev
02:10 paramat lol, typical. hmmmm, tried your suggestion and thought it had worked, but now the bug only occurs when generating chunks upwards, the opposite of before *=/. luckily it's not a bug often encountered by players.
02:24 Zeno` joined #minetest-dev
02:24 AllEvil669 joined #minetest-dev
02:26 AllEvil669 Is a chunk's on_generated method called before or after the register_ore method?
02:56 CraigyDavi` joined #minetest-dev
03:00 CraigyDavi`` joined #minetest-dev
03:03 petrusd987 joined #minetest-dev
03:03 petrusd987 Hey guys
03:31 Miner_48er joined #minetest-dev
03:43 paramat eww yes mgv6 with water level 47 has many patches of dark surface water
03:57 hmmmm AllEvil669, after
03:58 hmmmm paramat: mapgen v6 has a lot of problems with chunk boundaries 8)
03:58 hmmmm it's hard to deal with though
04:01 paramat 'swap lines 1063 and 1064, with 1065' < that actually fixes the bug, nice clear bright water too
04:01 hmmmm interesting
04:07 paramat here's a better screenshot of the original bug https://cloud.githubusercontent.com/assets/3686677/4553777/6290e4d0-4ea0-11e4-8859-4ed8bfa529a1.png
04:07 paramat the light fades horizontally along the y = 47 layer
04:17 paramat however im concerned that line swap will make solid (non water) nodes have max light at y = 47, and perhaps cause problems elsewhere
04:26 sol_invictus joined #minetest-dev
04:55 paramat left #minetest-dev
05:07 CraigyDavi` joined #minetest-dev
05:40 Hunterz joined #minetest-dev
06:58 ImQ009 joined #minetest-dev
07:38 Krock joined #minetest-dev
07:42 Ritchie joined #minetest-dev
08:00 Hunterz does areas mod redefine existing area? I would like change for example pos1
08:02 Du_Draig joined #minetest-dev
08:03 Du_Draig joined #minetest-dev
08:09 iqualfragile joined #minetest-dev
08:13 darkrose joined #minetest-dev
08:14 iqualfragile_ joined #minetest-dev
08:20 alexxs joined #minetest-dev
08:22 FR^2 joined #minetest-dev
08:28 ninnghazad joined #minetest-dev
08:35 sfan5 Megaf: tip: I don't want to clone your gist, don't give me the .git link
08:36 Megaf I wasnt sure on whats the correct link to give
08:36 Megaf anyway, Irrlicht itself cant find ogles, when I try to compile one of its examples I get this error sfan5. /usr/bin/ld: cannot find -lGLES_CM
08:37 sfan5 we don't use any of the irrlicht stuff to find open gl es
08:39 ImQ009 joined #minetest-dev
08:51 Amaz joined #minetest-dev
08:53 DuDraig joined #minetest-dev
08:58 sfan5 Megaf: just make it link to libEGL and libGLESv1_CM
08:59 Megaf ok, but would that fix the compiling of Minetest?
09:03 PenguinDad joined #minetest-dev
09:16 iqualfragile joined #minetest-dev
09:19 sfan5 Megaf: as you can see in the output it is missing the EFL functions, the other two are probably from libGLESv1_CM.so
09:19 sfan5 EGL*
09:57 troller joined #minetest-dev
10:15 jin_xi joined #minetest-dev
10:18 PilzAdam joined #minetest-dev
10:18 Megaf sfan5: I have all libs, I really dont understand what do I have to ling to where. http://paste.debian.net/plain/125121
10:45 proller joined #minetest-dev
10:48 deltib joined #minetest-dev
11:01 Megaf Hunterz: That's a question for #Minetest
11:05 ImQ009 joined #minetest-dev
11:08 Hunterz ok
11:11 PilzAdam joined #minetest-dev
11:11 dzho joined #minetest-dev
11:11 Taoki joined #minetest-dev
11:11 hax404_ joined #minetest-dev
11:11 speak joined #minetest-dev
11:16 Anchakor_ joined #minetest-dev
11:24 rickmcfarley joined #minetest-dev
11:27 kilbith joined #minetest-dev
11:27 kilbith Megaf: I switched to raspbian wheezy, and this time opengles is recognized during cmake
11:27 kilbith now I'm compiling...
11:28 Megaf kilbith: cmake can find openglese, but for an unkown reason it crashes on the compilation time
11:29 kilbith we'll see...
11:29 kilbith it's really a pity, raspi can exploit very well MT
12:00 proller joined #minetest-dev
12:46 SudoAptGetPlay joined #minetest-dev
13:01 shadowzone joined #minetest-dev
13:01 shadowzone joined #minetest-dev
13:11 sfan5 Megaf: just having those libs does not help with anything, minetest needs to be linked to those. and what about libEGL.so?
13:13 gravgun joined #minetest-dev
13:14 kilbith sfan5: during cmake, libEGL.so is not mentioned, but rather libGL.so
13:15 sfan5 I'm aware
13:15 kilbith I solved my issue on cmake by switching to wheezie, btw
13:17 kilbith and i don't understand the libGL are needed when you already have the GLES libs installed
13:17 kilbith understand why*
13:17 sfan5 libGL is not needed
13:17 kilbith it's needed, otherwise the cmake refuse to work
13:18 sfan5 Megaf: pass -DCMAKE_EXE_LINKER_FLAGS="-lGLESv1_CM -lEGL" to cmake and try again
13:19 kilbith the cmake says it found the libGL and then after below libglesv2 found
13:19 kilbith but if you don't have the libGL libs, it stops the process
13:20 kilbith Megaf & me got the same thing on it
13:21 Amaz joined #minetest-dev
13:22 kilbith anyhow, it should have a raspi build managed by a dev
13:31 gravgun left #minetest-dev
13:34 proller kilbith, can you make and run irrlicht demo on pi ?
13:34 kilbith I have irrlicht 1.8
13:34 kilbith but make is in process actually
13:36 kilbith I can run MT with OpenGL, but with 1 FPS
13:43 proller if you want to run mt on pi - first learn how ro run one irr demo
13:43 proller i'm about ogles1-2
13:53 kaeza joined #minetest-dev
13:54 ImQ009 joined #minetest-dev
13:59 mos_basik joined #minetest-dev
14:19 alexxss joined #minetest-dev
14:20 petrusd987 joined #minetest-dev
14:20 kilbith joined #minetest-dev
14:27 kilbith sfan5/Megaf: compilation finished (http://paste.debian.net/125173/), but I still have OpenGL and not OpenGLES enabled :(
14:32 SudoAptGetPlay left #minetest-dev
14:36 sfan5 kilbith: you are not using irrlicht open gl es
14:36 sfan5 if you don't use that you can't use opengl es
14:36 kilbith but how can I use irrlicht opengl es so ?
14:36 sfan5 ask Megaf
14:36 sfan5 he knows
14:37 kilbith and you ?
14:37 sfan5 I'm busy
14:37 kilbith :/
14:40 * kilbith asks to google...
14:43 hmmmm joined #minetest-dev
14:46 GrimKriegor joined #minetest-dev
15:09 shadowzone joined #minetest-dev
15:35 Amaz joined #minetest-dev
15:38 Calinou joined #minetest-dev
15:57 Calinou http://minetest.net/ → the screenshot on main page could be redone (new textures, new lighting)
15:57 Calinou better scene too ;)
15:58 Calinou what about a contest?
15:59 kilbith same for the screenshots page plz
16:01 Amaz +1
16:10 petrusd987 joined #minetest-dev
16:17 petrusd987 joined #minetest-dev
16:24 rubenwardy joined #minetest-dev
16:36 Anchakor_ joined #minetest-dev
16:36 kilbith joined #minetest-dev
16:37 kilbith proller, you're my hero \o/
16:37 Amaz kilbith, Why?
16:37 kilbith your script works perfectly with OpenGL ES
16:38 PenguinDad kilbith: what script?
16:38 kilbith http://forum.odroid.com/viewtopic.php?f=91&amp;t=6034
16:38 proller and show something ?
16:39 kilbith I can play perfectly
16:39 proller wow
16:39 proller how many fps
16:39 kilbith OpenGL ES 1.1, not 2.x
16:39 kilbith about 25-30 FPS
16:39 proller or not on pi ?
16:40 kilbith not on my Pi currently, but it will works too
16:40 kilbith x86 actually
16:41 kilbith I really like this FOG on running
17:03 ImQ009 joined #minetest-dev
17:28 AnotherBrick joined #minetest-dev
18:03 sapier joined #minetest-dev
18:04 sapier ShadowNinja did you really test https://github.com/minetest/minetest/commit/741df993ff33832d773536ed571c1a67ed93b5cb ?
18:05 sapier I ask because I already tried to use exactly that code with horrible concurrency issues and major crashes
18:09 ShadowNinja sapier: Yes, I tested it.  It shouldn't have that issue though, Lua runs single-threaded.
18:09 sapier try using same object from different coroutines you'll see what I'm talking about
18:10 sapier the problem ain't actuall concurrency but corountines creating their own stack, objectids can turn invalid in one stack while still beeing in use by another stack
18:11 sapier I wonder what you needed this code for, noone implemets this without actually using it
18:11 SudoAptGetPlay joined #minetest-dev
18:12 ShadowNinja sapier: objectrefGet pushes a reference to the object in a global table, not a copy.
18:12 sapier try it
18:13 sapier in a real example of course!
18:15 ShadowNinja sapier: Do you have some example code?  I'm not sure how to cause this.
18:15 sapier for what I remember I tried to use it for a lua only interim version of async code while map locking didn't work
18:16 sapier let me try to find the code, not sure if I didn't delete it after finding out to be wrong direction
18:19 sapier btw I still don't know what you need that code for, coroutines themselfs are quite heavy things, I never found a usecase where they actually gave any benefit
18:23 sapier Ahh there's the issue why I did abadone it
18:24 Krock Is UTF-8 a target for 0.5.0 or 0.4.11 ?
18:24 sapier objectrefGetOrCreate does create the reference if there ain't an ide and registers it to the Stack where it's been called
18:25 sapier if you call same function from another stack ID is set correct so it's gonna try to get the reference from this stack
18:26 sapier cooroutines seem to use independent lua stacks so you'll try to fetch a invalid reference
18:28 sapier ShadowNinja: can you follow me or explain to me what I may have misinterpreted?
18:30 ShadowNinja sapier: I've seen coroutines used for spreading the generation of a texture over several server steps to prevent locking up the server.  Also, lua_getglobal() should get the global from the main thread.
18:30 VargaD joined #minetest-dev
18:31 ShadowNinja (Or, rather, from the current environment, which is the global environment.
18:31 sapier did you verify this ShadowNinja because for all I've seen creation of a coroutine creates a new global stack element
18:32 sapier and speeding up only works if you have to do really really heavy tasks. I tried to use it for spawning, there I got even less performance
18:32 ShadowNinja sapier: The thread is still attached to the main thread.  You can verify this by noting that you can access globals from coroutines.
18:32 sapier those times where I did last long enough prior crash to get a result :-)
18:33 sapier not the treads are a a problem but the lua stack itself
18:33 kaeza left #minetest-dev
18:33 ShadowNinja sapier: It doesn't increase performance at all, but it gives other things a chance to run in between parts of it's running.
18:34 ShadowNinja It actually decreases performance slightly due to coroutine overhead, but that probably isn't significant.
18:34 sapier that can be done way less heavy with little more work, coroutines are extremely heavy, for most tasks their creation is more overhead then worth it
18:35 sapier still for what I remember coroutines create a completely independent stack including globals
18:35 sapier that's why they're that heavy too ;)
18:37 ShadowNinja sapier: They have their own globals table, but by default it's just a reference to the main globals table.
18:37 sapier http://www.lua.org/pil/9.html "A coroutine is similar to a thread (in the sense of multithreading): a line of execution, with its own stack, its own..."
18:38 ShadowNinja Any objections to https://github.com/minetest/minetest/pull/1726?
18:38 sapier ShadowNinja: I'd not bet on this because I've seen it behave different
18:39 ShadowNinja sapier: Well, I'll assume it works until someone proves otherwise, because I don't know how to break it.
18:40 sapier ohhh I see so we now merge things wrong according to docs until someone provides a crash? and then you're gonna tell "not my fault" as for player object deletion? ;-P
18:41 sapier what's the "real" difference in your commit? I see a lot of style and comment fixes
18:41 ShadowNinja sapier: ...   Can you just check that PR?
18:42 sapier define "that"
18:45 ShadowNinja sapier: https://github.com/minetest/minetest/pull/1726
18:45 sapier some () would be helpfull in there
18:45 sapier 1726
18:45 sapier e.g. around comparisons
18:46 ShadowNinja sapier: It already uses all it needs, more would just get in the way.
18:46 VargaD joined #minetest-dev
18:46 ShadowNinja sapier: Anything else?
18:47 sapier well I'm looking at it for 5 min now trying to match the parts of that operation, may be you can read it that way, good for you but not everyone has that supperior boolean/comparioson overview you have
18:48 ShadowNinja sapier: Seems perfectly clear to me.  Even uses extra indentation for organization.
18:49 sapier yeah that's your problem you assume everything beeing "perfectly clear" to you to be same for others
18:50 sapier most ppl I know use () to separate comparison expressions from boolean parts
18:50 sapier so I can't read your mixed mode code as easy you can
18:51 sapier despite the horrible coding style it seems to be correct
18:51 ShadowNinja sapier: http://pastebin.ubuntu.com/8522500/
18:52 ShadowNinja You want () around every ==, !=, >=, <=, <, >, etc?
18:52 sapier that's almost how I split it, I did move the binary operators at the end of the upper line using brackets to separate them ... but I don't wanna discuss about this if you want to merge it the way you wrote it just do it
18:53 sapier -binary operators + boolean operators
18:54 sapier but I still believe that object reference fix to cause issues
18:54 sapier I don't have time to verify it now, but if I turn out to be correct I'll just revert it without further discussion
18:55 ShadowNinja sapier: No, that's not how things work here.  If you find a way to break it tell me how you broke it so that I can fix it.
18:56 sapier you'll have plenty of time to verify me beeing wrong I provided docs as well as example how it might fail and imho they're quite obvious
18:57 sapier unless you see any other way to fix it except of changing all objects to provide a separate object ID per lua stack ... which is quite complex and error prone
18:59 OldCoder joined #minetest-dev
19:05 sfan5 Calinou: I tried: https://cdn.mediacru.sh/rPtmkATJHCi4.png
19:13 Calinou fsaa = 4 is preferable
19:13 Calinou and mip-map
19:13 Calinou your scene is good
19:13 Calinou seeds and coords?
19:14 Megaf joined #minetest-dev
19:15 sapier who did merge the "change keys" menu button?
19:16 sfan5 Calinou: uh.. lemme find out
19:16 sapier ShadowNinja: minetest.object_refs seems to keep in sync between different coroutines ... hopefully this really means globals table is shared between all coroutines. If there's a way not to do it that way it'll crash
19:17 sapier object_refs ain't a special tin is it?
19:20 ImQ009 joined #minetest-dev
19:20 ShadowNinja sapier: Nope, just a table AFAIK.
19:21 OldCoder joined #minetest-dev
19:22 sapier ok so the error I triggered by using this code is more complex, maybe a race condition between coroutines but at least the coroutines could be more usefull I initialy thought ... still creating them is very very heavy
19:23 sapier http://imgur.com/1JHA4EB whoever merged this, it's time to fix it, having a half visible button is a bug
19:24 sapier and there shouldn't be "Cancel" but "Exit" to be consistent to volume change menu
19:26 Krock why not remove exit to OS? it's possible to click that X on the top right
19:26 sapier once you show me that X in fullscreen mode we can do that ;-)
19:27 Krock ah yes. fulscreen.
19:27 * Krock reverts his commit
19:27 sapier why?
19:27 sapier try moving the buttons up
19:28 sapier reduce button distance? things like that are promising ;-)
19:28 hmmmm hey could somebody test this and tell me if it breaks shit or not?  https://github.com/kwolekr/minetest/commit/be31afb0a0abb644711f39a52520199339fd5cf2
19:29 sapier &gamedef->getNodeDefManager()->resolver :-) seems to be inconsistent within a single line ;-)
19:30 hmmmm yeah i know :/
19:30 hmmmm I'd have to follow the whole interface/implementation thing
19:30 hmmmm still undecided on whether or not I'm just going to throw that into the emergemanager
19:31 sapier no matter where you place it you should keep it consistent
19:31 kilbith joined #minetest-dev
19:32 sapier hard to judge this from reading :(
19:32 sapier mapgen_v6.cpp is debug output only right?
19:32 hmmmm huh?  yeah I guess
19:34 sapier +void                warn_if_field_exists << accidental space (<<< feeling like shadow)
19:34 sapier hmm could be a missing space before too
19:34 hmmmm oh no I did that so it lines up with the rest of them
19:35 ShadowNinja sapier: Works on my computer.
19:35 Calinou <Calinou> 21:34:30: ERROR[main]: ServerError: ...netest/bin/../games/minetest_game/mods/default/trees.lua:147: Deprecated use of default.grow_jungletree
19:35 Calinou <Calinou> why does it error on use of deprecated method? default behaviour is to do nothing
19:35 hmmmm either way, you have a very... interesting... way of declaring function prototypes
19:35 sapier calinou depends on what type of minetest build and configuration you have
19:35 sfan5 Calinou: 1219, 18, 548 seed = 8587654984356395281
19:35 Calinou thanks
19:36 GrimKriegor joined #minetest-dev
19:36 sapier hmmmm: did you talk to me? :-)
19:36 hmmmm maybe
19:37 sapier I was last to sort them not sure if you mean something I took from previous version or some of my changes ;-) what exactly do you mean with "interesting" ;-)
19:38 sapier ah biomedef is done same way as resolver that's where that style originates from :-)
19:38 Calinou “Print Stacks” should be removed from key change menu
19:38 Calinou it's of no use to players
19:38 Calinou only shows some stuff in console
19:39 Calinou the menu can't be exited by pressing Escape
19:39 hmmmm yeah the thing is, if I wanted to follow suit with the rest of the "manager" things, I'd have to create a separate interface and implementation class for each which adds more bloat
19:39 sfan5 at least it doesn't breaks something like the "Disable Camera Updates" key
19:39 hmmmm i don't like that
19:39 Calinou that key should be disabled entirely, sfan5, probably
19:40 Amaz joined #minetest-dev
19:40 sapier on the other hand you may spread pointers of non existent classes throughout minetest. well this is done by using get() functions too ... at best case they would be fetched on each acces but for some locations that's to slow
19:41 sapier best thing would be those classes beeing local only
19:41 * ShadowNinja used that key recently for something.  Only time he's used it though.
20:11 argyle joined #minetest-dev
20:21 proller joined #minetest-dev
20:31 kaeza joined #minetest-dev
20:34 VargaD_ joined #minetest-dev
20:43 shadowzone joined #minetest-dev
20:44 shadowzone joined #minetest-dev
20:51 ShadowNinja joined #minetest-dev
20:59 Miner_48er joined #minetest-dev
21:10 TheKingDoof joined #minetest-dev
21:24 zat joined #minetest-dev
21:24 paramat joined #minetest-dev
21:29 OldCoder joined #minetest-dev
21:35 paramat i agree that very prominent quote at www minetest net is so awkward, especially since it is censored, it should be removed =P
21:55 TheKingDoof joined #minetest-dev
22:21 shmanceloticus joined #minetest-dev
23:03 alexxs joined #minetest-dev
23:06 paramat left #minetest-dev
23:13 CraigyDavi` joined #minetest-dev
23:25 petrusd987 joined #minetest-dev
23:55 petrusd987 joined #minetest-dev

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