| 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&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 |
