| Time |
Nick |
Message |
| 00:49 |
|
proller joined #minetest-dev |
| 01:26 |
|
AllegedlyDead joined #minetest-dev |
| 01:34 |
|
Neological joined #minetest-dev |
| 02:32 |
|
AllegedlyDead joined #minetest-dev |
| 02:54 |
|
salamanderrake joined #minetest-dev |
| 03:12 |
VanessaE |
could I talk someone into making a quick fix for this bug where water is opaque no matter what, if bumpmapping is in use? |
| 03:13 |
VanessaE |
s/quick/"quick"/ |
| 04:57 |
|
neko259 joined #minetest-dev |
| 06:13 |
|
darkrose joined #minetest-dev |
| 07:06 |
|
Neological joined #minetest-dev |
| 07:17 |
kahrl |
can I merge #891: Add backtrace to error function? |
| 07:19 |
VanessaE |
backtrace for engine crashes, not Lua I assume? |
| 07:19 |
kahrl |
backtrace when something in lua calls error() |
| 07:19 |
VanessaE |
(as if Lua really had much to backtrace anyway :P ) |
| 07:20 |
VanessaE |
hm |
| 07:23 |
kahrl |
it isn't the best way (prints to stderr instead of a log stream, order of printed messages is a bit weird) but much better than nothing, and doing it differently would be complicated |
| 07:25 |
kahrl |
by order I mean in some situations it prints "stack traceback:\n <backtrace>\n ERROR[main]: <error message>\n ERROR[main]: stack traceback: <nothing>" |
| 07:43 |
|
celeron55 joined #minetest-dev |
| 08:41 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 08:48 |
|
darkrose joined #minetest-dev |
| 08:50 |
|
sapier joined #minetest-dev |
| 08:53 |
sapier |
kahrl do you understand what the transform does and how it should be handled correctly? I admit I don't have any idea and just used it as it seemd to be correct to me |
| 08:54 |
kahrl |
I know how OpenGL matrices are used and I assume irrlicht's setTransform is vaguely similar |
| 08:57 |
kahrl |
well looks like it is: setTransform (the COpenGLDriver implementation) is a thin wrapper around glLoadMatrixf :D |
| 08:57 |
sapier |
ok I move that line as I guess worst thing to happen is setting transform twice (if anaglyph is enabled) ... but I guess this happens anyway |
| 08:58 |
|
Taoki joined #minetest-dev |
| 08:59 |
kahrl |
if nothing is drawn with it it most drivers should simply ignore it and not do something expensive on the GPU |
| 08:59 |
kahrl |
... I hope |
| 09:00 |
kahrl |
-it |
| 09:01 |
sapier |
ok it still works that way |
| 09:05 |
sapier |
ok fixed |
| 09:06 |
sapier |
btw does anyon hafe a rift to create support for it? |
| 09:06 |
sapier |
-f+v |
| 09:14 |
kahrl |
this guy had some ideas about it http://irc.minetest.ru/minetest-dev/2013-03-03#i_2909005 |
| 09:16 |
|
Taoki joined #minetest-dev |
| 09:16 |
sapier |
I assume he's right mouse isn't really necessary anymore at least not for movement direction ... rift would require separating dig target from eye target |
| 09:17 |
sapier |
we could make mouse to be dig target if we don't want to drop it completely |
| 09:17 |
VanessaE |
on re-read of that thread, I feel a tad stupid :P |
| 09:17 |
sapier |
and of course ui needs to be redone completely ... a fixed set of icons on screen would be strange |
| 09:18 |
sapier |
I'm not sure if I did know about rift in march ;-) |
| 09:19 |
sapier |
but i assume a first step would be support for 3d-tv's I already tried to find any code that does this but I have know idea how to get a video signal to do that |
| 09:20 |
kahrl |
you would likely have to plug something like http://vire.io/ into irrlicht |
| 09:21 |
|
Calinou joined #minetest-dev |
| 09:21 |
sapier |
something like yes but anaglyph mode already renders two pictures I guess rift'd be even more easy than 3d tv as you just have to display pictures side by side |
| 09:22 |
sapier |
still I don't have a rift to test that asumption :-) |
| 09:22 |
sapier |
talking about side by side don't 3d-tv's use side by side images too? |
| 09:22 |
sapier |
no it can't be that simple |
| 09:23 |
VanessaE |
sometimes side-by-side, sometimes one-above-the-other, sometimes checkerboard pixels, and sometimes frame-by-frame |
| 09:23 |
VanessaE |
I believe all four formats are in use |
| 09:23 |
kahrl |
actually vireio can't be used because it is GPL |
| 09:23 |
VanessaE |
I guess frame-sequential/frame-by-frame is the common one? |
| 09:24 |
kahrl |
I wonder how all those commericial games are using a GPL library? |
| 09:25 |
kahrl |
-i |
| 09:25 |
sapier |
I haven't read everything but I read something like "d3d" there ;-) |
| 09:25 |
Calinou |
it's not like people don't violate the GPL |
| 09:27 |
sapier |
the're only violating it if they're linked against it |
| 09:28 |
sapier |
glibc for example has a special statement in their headers using them is not violation of gpl so you can link proprietary applications against glibc without violation |
| 09:36 |
|
PilzAdam joined #minetest-dev |
| 09:38 |
|
iqualfragile joined #minetest-dev |
| 09:44 |
|
AllegedlyDead joined #minetest-dev |
| 09:48 |
kahrl |
sapier, I'm kind of stuck on converting the mod manager to httpfetch |
| 09:48 |
kahrl |
the current code is quite reliant on synchronous fetches |
| 09:49 |
kahrl |
I could probably redo those parts so that they using async fetches, but I don't want to invest that much time as you were going to redo those parts anyway if I recall |
| 09:50 |
kahrl |
s/using/use, I can't type today :/ |
| 10:08 |
sapier |
I already thought about that isse there's no easy way to switch ... my idea was placing dummy elements on opening modmanager and use a signal to update the data as they come availible ... similar to what I used for favourite list in my async branch |
| 10:08 |
|
proller joined #minetest-dev |
| 10:13 |
PilzAdam |
kahrl, I guess #891 is good |
| 10:18 |
kahrl |
PilzAdam: pushing it |
| 10:23 |
kahrl |
sapier: that sounds a bit difficult but is probably the only sane way of doing it |
| 10:27 |
kahrl |
sapier: what do you think about caching the full list of mods? |
| 10:28 |
sapier |
imho we should only cache while we're within modmanager, this way you could reload the list by leaving it e.g. if you wanna try your just uploaded mod |
| 10:29 |
sapier |
but runtime caching would be fine for most ppl too ... just don't do something like "1-day caching" |
| 10:29 |
kahrl |
what's wrong with 1-day caching? |
| 10:29 |
kahrl |
you could perhaps assign F5 to redownload the whole list |
| 10:30 |
|
Jordach joined #minetest-dev |
| 10:30 |
sapier |
then you have to find a way to evaluate F5 and when do you want to download on minetest start? |
| 10:31 |
sapier |
I guess it's not tha slow we can't update once per minetest startup ppl do want to install new mods if they open up the modmanager why show them an outdated list? |
| 10:32 |
sapier |
and of course only download the list if someone really opens the modmanager |
| 10:32 |
sapier |
imho a programm shouldn't do online communication if it's not really necessary |
| 10:33 |
kahrl |
well obviously |
| 10:33 |
kahrl |
btw, the menu in master downloads the serverlist even when not started on the client tab ;) |
| 10:33 |
sapier |
what? |
| 10:34 |
sapier |
if public server list is not enabled too? |
| 10:34 |
kahrl |
only if that is enabled |
| 10:35 |
sapier |
ok ... at least ... but it shouldn't do that too |
| 10:35 |
kahrl |
I fixed it in httpfetch |
| 10:36 |
sapier |
good :-) we don't need to give more information to nsa than they already have ;-) |
| 10:36 |
kahrl |
hehe |
| 10:36 |
kahrl |
I made the serverlist fetch async in httpfetch, using a slightly different approach than yours |
| 10:37 |
kahrl |
it parses the whole thing in lua using engine.parse_json |
| 10:37 |
sapier |
I already thought so ;-) |
| 10:38 |
sapier |
I still don't like json ;-) but thats subjective ;-) |
| 10:38 |
proller |
https://github.com/proller/minetest/compare/master...huge_cave |
| 10:38 |
proller |
https://github.com/minetest/minetest/pull/899/files |
| 10:38 |
sapier |
hmm subjective isn't a correct english word is it? |
| 10:38 |
proller |
https://github.com/minetest/minetest/pull/897/files |
| 10:39 |
kahrl |
I don't really either but the serverlist uses it, don't see a reason to change it |
| 10:39 |
proller |
what is better tha json ? |
| 10:39 |
sapier |
I wasn't suggesting to do so ;-) |
| 10:40 |
sapier |
:-) proller I can't read json it's even more diffucult than xml |
| 10:40 |
sapier |
yes xml has a lot of redundancy but that's probably the reason why it's more easy to read |
| 10:40 |
|
n4x joined #minetest-dev |
| 10:40 |
proller |
try to read formatted json |
| 10:41 |
sapier |
already tried it's still less readable to me |
| 10:41 |
kahrl |
this is subjective as well but json always seems easier to work with from code than xml (html, dom) |
| 10:42 |
kahrl |
the downside is that json afaik doesn't have stuff like xpath to walk complicated structures |
| 10:42 |
sapier |
I assume that's even objective as xml has that strange attribute thing |
| 10:43 |
sapier |
as far as I understand jsons primary target was create something with as less redundancy as possible |
| 10:43 |
sapier |
while xml was designed to be as universal as possible |
| 10:44 |
kahrl |
text formats are redundant by definition |
| 10:45 |
proller |
want to commit ^^^^ |
| 10:45 |
kahrl |
representing an integer as text takes more bytes than the equivalent in binary |
| 10:45 |
sapier |
only if you ignore portability ... if portability is an issue ascii can't be avoided |
| 10:45 |
kahrl |
and, for something like the server list, both json and xml repeat the key names in every record |
| 10:46 |
sapier |
of course :-) as the list is for minetest only and we already have that http header feature I don't have any idea why we didn't use a binary format for transmission |
| 10:48 |
|
celeron55 joined #minetest-dev |
| 10:49 |
kahrl |
ah yeah http headers, I guess we could cache the mod list and send the date of the cached mod list to the mmdb server |
| 10:49 |
kahrl |
or a sha1 of it |
| 10:49 |
sapier |
don't make it that compex if not really required ;-) |
| 10:50 |
kahrl |
true :) |
| 10:50 |
kahrl |
brb |
| 10:52 |
|
jojoa1997 joined #minetest-dev |
| 10:56 |
|
iqualfragile joined #minetest-dev |
| 11:01 |
sapier |
is there a way to look for "air" with find_node_near? |
| 11:02 |
PilzAdam |
yes, find_node_near(..., {"air"}) |
| 11:03 |
sapier |
strange this results to nil at locations where should be air |
| 11:05 |
sapier |
local air_around = minetest.find_node_near(pos, 3, { "air" } ) |
| 11:05 |
sapier |
#air_around is 0 |
| 11:06 |
sapier |
there's plenty of air around that pos ;-) |
| 11:06 |
PilzAdam |
well, air_around is a position |
| 11:06 |
sapier |
a single one? |
| 11:06 |
PilzAdam |
yes |
| 11:06 |
PilzAdam |
minetest.find_nodes_in_area returns an array of positions |
| 11:07 |
sapier |
ok so wrong asumption still it should be 1 not 0 |
| 11:07 |
PilzAdam |
(note the plural of node) |
| 11:07 |
sapier |
a position is still a table with x y and z value isn't it? |
| 11:07 |
PilzAdam |
a position doesnt contain any fields that are indexed by integers, so #pos is 0 |
| 11:08 |
sapier |
hmm thought it'd return count of elements not honoring what way they are in there but didn't try that ... ok no need to check I'm gonna use the correct function ;-) |
| 11:09 |
|
troller joined #minetest-dev |
| 11:09 |
|
jojoa1997 joined #minetest-dev |
| 12:07 |
sapier |
is there a way to get position lighting information from a voxelmanip object? |
| 12:14 |
|
proller__ joined #minetest-dev |
| 12:24 |
|
Zeg9 joined #minetest-dev |
| 12:55 |
kahrl |
sapier, nope |
| 12:59 |
sapier |
:-/ can this be added? |
| 12:59 |
PilzAdam |
not really |
| 12:59 |
PilzAdam |
vmanip only handles param0 |
| 13:01 |
sapier |
for some spawning algorithms I need information about light levels around a position calling get light multiple times per node is a exp3 function |
| 13:02 |
sapier |
it'd be easy to validate a position if I just could fetch whole map information once and check within that data |
| 13:03 |
PilzAdam |
maybe cache it in your mod? |
| 13:03 |
sapier |
cache full map in mod? not really usefull isn't it? ;-) |
| 13:04 |
proller__ |
i want to make not linear light spread -> cone spread, is any objections ? |
| 13:04 |
proller__ |
linear->cone |
| 13:05 |
sapier |
same cone for sunlight as well as other sources? |
| 13:09 |
proller__ |
yes, look not only on top light, but sometimes up-left,up-right...., |
| 13:09 |
proller__ |
now without it float islands produce dark buggy area under it |
| 13:10 |
proller__ |
sapier, other sources have max radius |
| 13:10 |
sapier |
let's have a try but usually cones of sunlight and other sources are quite different so not sure how it's gonna look like if you use same for everything |
| 13:12 |
sapier |
to be really correct we're missing ambient light |
| 13:12 |
sapier |
I guess that's what often is discussed by "real lighting" |
| 13:13 |
proller__ |
real must be 3d with sun/moon position |
| 13:13 |
kahrl |
proller__, how would cone spread work algorithmically? |
| 13:20 |
|
Zeitgeist_ joined #minetest-dev |
| 13:21 |
proller__ |
look to up-left or up-right or up-front or up-back every N, if N==1 -> 45deg spread, if N 10+ -> small degree spread, if 0 - linear as now |
| 13:21 |
proller__ |
but need to try.. |
| 13:21 |
kahrl |
let's say N==1 |
| 13:22 |
kahrl |
wouldn't all caves be lit? |
| 13:23 |
proller__ |
need to try |
| 13:23 |
proller__ |
it can be lighter only if exists hole with sunlight |
| 13:24 |
|
proller__ joined #minetest-dev |
| 13:37 |
|
proller joined #minetest-dev |
| 13:43 |
|
SpeedProg joined #minetest-dev |
| 13:49 |
|
celeron55 joined #minetest-dev |
| 14:14 |
|
proller joined #minetest-dev |
| 14:59 |
|
Taoki[mobile] joined #minetest-dev |
| 15:00 |
|
jojoa1997 joined #minetest-dev |
| 15:05 |
|
celeron55 joined #minetest-dev |
| 15:24 |
|
troller joined #minetest-dev |
| 15:35 |
ShadowNinja |
VoxelArea:iter/iterp would be a lot more usefull to me if they aditionally returned the current x, y, and z coordinates. |
| 15:35 |
ShadowNinja |
Asuming this is doable without slowing it down a lot. |
| 15:57 |
|
hmmmm joined #minetest-dev |
| 16:16 |
|
SpeedProg1 joined #minetest-dev |
| 16:39 |
|
iqualfragile joined #minetest-dev |
| 17:00 |
|
Ritchie joined #minetest-dev |
| 17:01 |
|
celeron55 joined #minetest-dev |
| 17:14 |
|
celeron55 joined #minetest-dev |
| 17:26 |
|
neko259 joined #minetest-dev |
| 17:31 |
troller |
i found 4+ places with light spreading... |
| 17:39 |
|
troller joined #minetest-dev |
| 18:04 |
|
Miner_48er joined #minetest-dev |
| 18:17 |
|
sapier1 joined #minetest-dev |
| 18:48 |
|
proller joined #minetest-dev |
| 19:03 |
|
Taoki joined #minetest-dev |
| 19:57 |
|
salamanderrake joined #minetest-dev |
| 20:22 |
|
smoke_fumus joined #minetest-dev |
| 21:03 |
PilzAdam |
any comments on https://github.com/minetest/minetest/pull/900 ? |
| 21:11 |
|
OWNSyouAll_DESK1 joined #minetest-dev |
| 21:37 |
kahrl |
PilzAdam: you're violating the naming conventions quite a lot there :P |
| 21:37 |
kahrl |
as in conventions from the surrounding code |
| 21:37 |
PilzAdam |
I follow the general conventions |
| 21:38 |
kahrl |
s/set_hotbar_*/hud_set_hotbar_... |
| 21:38 |
kahrl |
you don't need new protocol messages, just reuse TOCLIENT_HUD_SET_PARAM |
| 21:39 |
kahrl |
I made that one generic intentionally |
| 21:40 |
kahrl |
finally, hud.cpp seems to use names_with_underscores everywhere not camelCaseNames |
| 21:40 |
PilzAdam |
our code style guidelines say that we use camelCase, though |
| 21:41 |
kahrl |
having different conventions in a single class is terrible |
| 21:45 |
kahrl |
hrm where do the guidelines say anything about camelCase and underscore_names for members and local variables? |
| 21:49 |
PilzAdam |
thoght it was there |
| 21:49 |
PilzAdam |
*thought |
| 22:00 |
PilzAdam |
ok, updated |
| 22:05 |
kahrl |
for l_set_hotbar_*image you only added "hud_" in the comment |
| 22:09 |
kahrl |
the rest looks good |
| 22:14 |
PilzAdam |
ok, do I miss anything else? |
| 22:15 |
kahrl |
I don't think so |
| 22:17 |
PilzAdam |
I merge it then |
| 22:18 |
kahrl |
okidoki |
| 22:23 |
PilzAdam |
btw, Pilztest has hotbar images now ;-) |
| 22:24 |
PilzAdam |
now I need to wait for BlockMen to finish his background support for formspecs |
| 22:30 |
PilzAdam |
also a way to remove the "Leftclick: Move all items..." thing would be nice, it just doesnt fit in a 5×1 formspec |
| 22:31 |
sapier1 |
https://github.com/minetest/minetest/pull/890 what about this one? kahrl the tooltip causes a crash because it's not grabbed thus removed too soon on exception |
| 22:32 |
sapier1 |
only parent grabs the tooltip but the parent is cleant up prior the menu on a exceptin this the m_tooltip_element->remove() L130 causes a crash |
| 22:32 |
sapier1 |
at least sometimes ;-) that's why minetest happens to quit completely on some lua errors |
| 22:34 |
kahrl |
deleting the parent before the menu sounds like a great idea ;) |
| 22:35 |
sapier1 |
that's done by exception handling |
| 22:35 |
sapier1 |
it's not parent of the menu but parent of the tooltip |
| 22:35 |
kahrl |
parent of the tooltip = root GUI element so it's a parent of the formspec menu as well |
| 22:35 |
sapier1 |
menu and tooltip are child of same parent |
| 22:36 |
sapier1 |
parent cleans up his childs sometimes the tooltip is deleted firs sometimes the menu ;-) |
| 22:36 |
kahrl |
well to be precise guiroot's parent is the root GUI element (which is != guiroot) and the formspec menu's parent is guiroot |
| 22:37 |
sapier1 |
not exactly sure what order ;-) still doesn'tz change the fact that menu has a pointer to a element not grabbed by itself thus can't be sure it's still there ;) |
| 22:38 |
kahrl |
are there other things like the tooltip element? |
| 22:38 |
sapier1 |
as far as I know anything else is child of menu ... but I haven't done a closer investigation |
| 22:39 |
sapier1 |
maybe within other gui parts not beeing formspec |
| 22:42 |
kahrl |
I guess let's merge it then |
| 22:43 |
sapier1 |
a second core dev should give ok ;-) pilzadam? |
| 22:43 |
kahrl |
of course ;) |
| 22:44 |
PilzAdam |
yea, do it |
| 22:48 |
kahrl |
woohoo down to 1 less than 70 pull requests again |
| 22:48 |
proller |
https://github.com/minetest/minetest/pull/897/files |
| 22:49 |
sapier1 |
I gues I could find something to add ;-) ... maybe I'm gonna have a closer look to our object saving issues |
| 22:49 |
proller |
https://github.com/minetest/minetest/pull/899/files |
| 22:49 |
proller |
https://github.com/proller/minetest/compare/master...huge_cave |
| 22:53 |
kahrl |
did somebody test #893 with 3d glasses? |
| 22:53 |
kahrl |
if so I'm ok with merging it |
| 22:54 |
sapier1 |
I did but I guess you already knew that |
| 22:54 |
kahrl |
I didn't |
| 22:54 |
sapier1 |
:-) you don't realize that bug without 3d glasses |
| 22:55 |
sapier1 |
anaglyph glasses of course |
| 22:56 |
kahrl |
PilzAdam: you ok with merging it too? |
| 22:57 |
PilzAdam |
yes, seems good |
| 22:59 |
sapier1 |
https://github.com/minetest/minetest/pull/889 might be a problem too |
| 23:00 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 23:00 |
sapier1 |
I don't have an idea how the nils came in there too but the error report is quite obvious |
| 23:01 |
kahrl |
I just wonder if the fix is enough |
| 23:01 |
kahrl |
isn't there a lot of code that assumes the entries of the worldlist are tables and not nil? |
| 23:01 |
sapier1 |
I guess there's never shouldn't be nils there but I'm not sure where to start looking for that root cause |
| 23:04 |
kahrl |
we could add a lua_pushnil in l_get_worlds to see what needs needs to be fixed |
| 23:04 |
kahrl |
s/needs/else |
| 23:04 |
sapier1 |
still a compare function should handle nil a little bit more sane ;-) |
| 23:04 |
sapier1 |
yes but somehow the nil must be result of current code |
| 23:05 |
sapier1 |
no idea how this might happen |
| 23:05 |
kahrl |
true... I don't even get how any element of a table can be nil |
| 23:05 |
kahrl |
I thought lua deletes those immediately |
| 23:05 |
kahrl |
maybe it's a bug in table.sort? |
| 23:06 |
sapier1 |
maybe but that's a builtin isn't it? |
| 23:06 |
kahrl |
it's implemented in ltablib.c |
| 23:07 |
sapier1 |
if someone uses system lua it's gonna happen again even if we fix it ... but yes it'd be better to exactly know the root cause |
| 23:09 |
kahrl |
it's probably not a bug in table.sort |
| 23:09 |
sapier1 |
but? |
| 23:09 |
kahrl |
but table.sort(t) uses the equivalent of #t to find the size of the table |
| 23:09 |
sapier1 |
I don't get it by now ;-) |
| 23:09 |
kahrl |
so if t = {[1] = "a", [3] = "b"} it would call the comparator with nil for the element at position 2 |
| 23:10 |
sapier1 |
ok so nil is perfectly fine |
| 23:10 |
sapier1 |
still I have no ide what to return both could be wrong if one of the elements is nil |
| 23:12 |
sapier1 |
is there any convention what to return in that case? |
| 23:13 |
kahrl |
dunno |
| 23:13 |
kahrl |
I guess it's a case of GIGO so doesn't matter |
| 23:16 |
kahrl |
actually, http://stackoverflow.com/questions/2102710/treating-nils-in-sort-function |
| 23:16 |
kahrl |
it appears that table.sort raises an error if the compare function gives suspicious outputs |
| 23:17 |
sapier1 |
hmm so we should at least handle the case one nil the other not nil better than in my suggestion |
| 23:19 |
kahrl |
if it always returns false it might be fine, actually |
| 23:19 |
kahrl |
see the answer at that link: "comp(a,b) must imply not comp(b,a)" |
| 23:19 |
sapier1 |
no if one isn't nil it should return different values |
| 23:20 |
sapier1 |
e.g comp(nil,a) == false then comp(a,nil) has to be true |
| 23:20 |
kahrl |
no |
| 23:20 |
kahrl |
only if comp(nil,a) == true then comp(a,nil) has to be false |
| 23:20 |
kahrl |
truth tables ;) |
| 23:21 |
sapier1 |
are you sure the single direction is intentionaly or by error ;-) |
| 23:21 |
kahrl |
it has to accept comp(a,b) == comp(b,a) == false, for the case when a and b are considered equal |
| 23:21 |
sapier1 |
hmm you're right |
| 23:22 |
|
jojoa1997 joined #minetest-dev |
| 23:22 |
sapier1 |
still we could make sort sort all nills to a side too ;-) |
| 23:23 |
sapier1 |
if we sort them to upper values we make tables smaller ;-) |
| 23:23 |
kahrl |
what I'm not sure about is whether comp(a,b) == false and comp(b,a) == false and comp(b,c) == true must imply comp(a,c) == true |
| 23:23 |
sapier1 |
I'd define nil is always bigger than any other value |
| 23:24 |
sapier1 |
except nil of course |
| 23:24 |
kahrl |
yeah that sounds fine |
| 23:25 |
|
OWNSyouAll_DESKT joined #minetest-dev |
| 23:27 |
|
djdduty joined #minetest-dev |
| 23:28 |
sapier1 |
ok if I didn't mix up directions now all nil should be sorted to the upper end of table |
| 23:29 |
sapier1 |
I know the first added line is redundant but I think it's more readable |
| 23:29 |
kahrl |
you can remove the comment about badly sorted list |
| 23:31 |
kahrl |
perhaps add there "fixes issue #857" in case somebody wonders what the bug is |
| 23:32 |
kahrl |
the comparison seems fine |
| 23:32 |
sapier1 |
"fixes issue #857 (crash due to sorting nil in worldlist)" I don't like numbers only |
| 23:32 |
kahrl |
yeah that's good |
| 23:35 |
sapier1 |
ok added |
| 23:41 |
kahrl |
I'm ok with merging it, anyone else? |
| 23:41 |
sapier1 |
the compare function was originaly written by pa maybe he should have a look at it too |
| 23:42 |
sapier1 |
at least I think so .. but it could've been thexyz too |
| 23:42 |
PilzAdam |
it was me |
| 23:42 |
PilzAdam |
ä |
| 23:42 |
sapier1 |
ok so my memory was correct |
| 23:42 |
PilzAdam |
oops |
| 23:42 |
PilzAdam |
#889 seems fine |
| 23:43 |
sapier1 |
we still don't know why this happens for some ppl only |
| 23:43 |
kahrl |
I'll merge it then |
| 23:44 |
kahrl |
sapier1, maybe something weird like world paths with certain unicode characters |
| 23:45 |
sapier1 |
I thought same direction I guess we'll have to live without knowing ;-) |
