Time |
Nick |
Message |
01:23 |
|
mrtux joined #minetest-dev |
01:27 |
|
MJaoune joined #minetest-dev |
01:31 |
|
MNJaoune joined #minetest-dev |
01:39 |
|
kahrl joined #minetest-dev |
02:04 |
khonkhortisan |
the simplest ones get merged first https://github.com/minetest/minetest/pull/764 |
03:07 |
|
dexter0 joined #minetest-dev |
03:41 |
|
hmmmm joined #minetest-dev |
04:58 |
|
Taoki[mobile] joined #minetest-dev |
05:57 |
|
dexter0 joined #minetest-dev |
07:06 |
|
Guest83169 joined #minetest-dev |
07:15 |
|
darkrose joined #minetest-dev |
07:15 |
|
darkrose joined #minetest-dev |
07:32 |
|
dexter00 joined #minetest-dev |
07:34 |
|
zweipktf1t joined #minetest-dev |
07:37 |
|
ecube joined #minetest-dev |
07:37 |
|
thexyz_ joined #minetest-dev |
07:38 |
|
ssieb joined #minetest-dev |
07:40 |
|
neko259 joined #minetest-dev |
08:05 |
|
Calinou joined #minetest-dev |
08:26 |
|
EdB joined #minetest-dev |
08:32 |
|
serengeor joined #minetest-dev |
08:38 |
|
Taoki joined #minetest-dev |
09:18 |
|
ImQ009 joined #minetest-dev |
10:21 |
|
Zeg9 joined #minetest-dev |
10:29 |
|
serengeor joined #minetest-dev |
10:56 |
|
PilzAdam joined #minetest-dev |
14:04 |
|
Calinou joined #minetest-dev |
14:09 |
|
Jordach joined #minetest-dev |
14:09 |
|
Jordach joined #minetest-dev |
14:25 |
|
sapier1 joined #minetest-dev |
14:27 |
sapier1 |
does anyone know why it's impossible to link minetest against mingw libz? |
14:29 |
|
Exio joined #minetest-dev |
14:30 |
|
rubenwardy joined #minetest-dev |
14:46 |
sapier1 |
https://github.com/sapier/minetest/tree/ngmm_minizip I've added libarchive support, as well as fixed build on win32 ... win32 builds and links but doesn't work I guess this is due to linker mess created by non mingw libz version |
15:23 |
|
Neological joined #minetest-dev |
15:34 |
ShadowNinja |
sapier1: Why the minizip support? |
15:35 |
sapier1 |
to support users with installing mods |
15:35 |
sapier1 |
no I'm not talking about developers but USERS ;-) |
15:36 |
Jordach |
no more extraction of mods / modpacks |
15:36 |
sapier1 |
exactly and of course no more wrong folders |
15:36 |
ShadowNinja |
Hmmm, will it work with the GitHub archives properly? |
15:37 |
sapier1 |
modmanager included within formspec mainmenu will ... at least in 99.9% |
15:37 |
sapier1 |
it's detecting modname after extracting it |
15:38 |
Exio |
how hard would be to add things like a "info' file in the mods |
15:38 |
sapier1 |
if there is an register command it'll be able to rename the mod automaticaly |
15:39 |
sapier1 |
at least as long as modname is within same line as register :-) I didn't want to write a full parser ... but this is not normal code style ... thus yes if a mod writer intentionally writes unsupported code it will fail |
15:39 |
sapier1 |
exio not that hard but it has to support current mods |
15:40 |
sapier1 |
but I need someone to fix the win32 build as those users are the ones that really need it ;-) |
15:40 |
Exio |
yes, but i mean "if it exists; use it; if not guess it" |
15:41 |
sapier1 |
yes I guess this will be added when moddb is added too as moddb already provides a defined data format |
15:42 |
Exio |
ah |
15:42 |
sapier1 |
still I'm unable to link zlib correctly on win32 |
15:42 |
kahrl |
minetest already links with zlib, why does it fail? |
15:43 |
sapier1 |
it does link but it uses some workarounds and fails on startup |
15:43 |
sapier1 |
if I try to link against mingw libz it doesn't even link |
15:46 |
sapier |
i guess irrlicht lib does use different calling convention than mingw ... but I'm not common to win32 linkage problems so I may be completely wrong |
15:46 |
|
NakedFury joined #minetest-dev |
15:48 |
sapier |
error messages in mingw are "Warning: resolving __unzGetGlobalInfo by linking to __unzGetGlobalInfo@@8" |
15:48 |
sapier |
and some similar things |
15:48 |
kahrl |
check src/serialization.cpp |
15:48 |
sapier |
am I correctly interpreting @@8 as pic/non-pic error? |
15:48 |
kahrl |
it has #ifdef _WIN32 #define ZLIB_WINAPI |
15:49 |
sapier |
I already added this without that it didn't even link |
15:49 |
sapier |
but it's still wrong |
15:50 |
kahrl |
are you sure you are defining it before zlib.h is included? |
15:50 |
sapier |
yes |
15:50 |
kahrl |
checked all header files that are included before it too? |
15:50 |
|
hmmmm joined #minetest-dev |
15:51 |
sapier |
zlib.h is first (non c) header to be included in unzip.c |
15:52 |
kahrl |
and how do you link with it in cmake? |
15:53 |
sapier |
yes kahrl it does link but it's linking wrong things :-) |
15:54 |
kahrl |
can you push your changes somewhere? |
15:55 |
sapier |
btw how to link curl without beeing able to set curl dll in gui? |
15:55 |
sapier |
it's already up on the branch I posted |
15:55 |
kahrl |
oh sorry I was looking at next_gen_main_menu |
15:55 |
sapier |
no the minizip branch |
15:55 |
kahrl |
I see it now |
15:56 |
sapier |
mainmenu won't build on win32 atm I didn't merge the fixes back by now |
15:56 |
|
dysoco joined #minetest-dev |
15:57 |
kahrl |
is there any particular reason to use an external libarchive? |
15:57 |
kahrl |
tar seems simple to enough to just parse it a small routine that calls zlib to decompress |
15:57 |
kahrl |
in* |
15:57 |
kahrl |
-to |
15:58 |
sapier |
libarchive is way to support tar.gz tar.bz2 tar.7z ... it supports zip too but I guess not everyone wants to install libarchive |
15:58 |
sapier |
but it doesn't link correct without libarchive too |
15:58 |
kahrl |
personally I'm not sure if I like adding all these dependencies into minetest |
15:59 |
sapier |
ok plz add libz ;-) |
15:59 |
kahrl |
libz is already used |
15:59 |
sapier |
into minetest ;-) |
16:00 |
sapier |
I'd prefere not to use two different libs but I'm not sure if libarchive license is compatible to minetest |
16:01 |
kahrl |
is it really important that minetest can extract archives that the user downloaded outside of minetest? |
16:01 |
kahrl |
I mean if he does that he can install whatever unzip program is needed |
16:01 |
sapier |
atm this is the only way a user can get a mod ;-) |
16:01 |
sapier |
unzip can't be used on windows |
16:01 |
kahrl |
huh? |
16:02 |
sapier |
and linux users normaly don't need support |
16:02 |
kahrl |
mingw has unzip and there's also 7zip/winzip/winrar/... and explorer can extract zips too |
16:02 |
sapier |
I don't want to write support for whatever gui unzippers are out there |
16:03 |
sapier |
yes but microsoft doesn't give api access to unzip capabilities of explorer |
16:03 |
kahrl |
err, I'm not sure I catch your drift |
16:03 |
kahrl |
what does minetest have to do with it |
16:04 |
sapier |
it's just removing an additional silly error case |
16:04 |
kahrl |
the wrong directory names? |
16:04 |
sapier |
wrong directory names wrong folders |
16:04 |
sapier |
telling a noob where to copy a mod is quite callanging |
16:05 |
kahrl |
noobs can use the included mod manager |
16:05 |
sapier |
yes but the modmanager needs to unzip ;-) |
16:05 |
kahrl |
but only one format, not a hundred |
16:06 |
sapier |
true but it's no difference to support 1 or hundred formats with libarchive |
16:07 |
sapier |
but even if we only support one format (zip) linking is done wrong ;-) |
16:07 |
celeron55_ |
my opinion on the issue is that if it is possible to add support for a single common archive format, no matter what, without additional dependencies, it should be done that way |
16:07 |
celeron55_ |
and it definitely is |
16:07 |
sapier |
so once we fix this error we can still decide if we want to support tar.gz ... |
16:08 |
celeron55_ |
people can easily transition to it and in the future things will be much simpler |
16:08 |
kahrl |
libarchive seems a bit like "mit Kanonen auf Spatzen geschossen" |
16:08 |
kahrl |
what is that in english... |
16:08 |
kahrl |
taking a sledgehammer to crack a nut |
16:08 |
sapier |
no matter if we want zip only support or not linkage is done wrong on windows in any case ;-) |
16:08 |
PilzAdam |
shooting with canons at flies? |
16:09 |
celeron55_ |
if we hint to people that we want to support many formats, then people expect us to do that always in the future, and even expect support for even more formats |
16:09 |
kahrl |
sapier, I will try to write a tiny tar extract function |
16:10 |
kahrl |
but probably not before thursday because I'm busy |
16:10 |
sapier |
ok I'll not include libarchive support in mainmenu ;-P still I need a fix for libz linkage on win32 |
16:10 |
celeron55_ |
linux is cancer in this aspect because it makes dependency management so much easier than other OSes |
16:10 |
sapier |
kahrl a tar extract function is useless without gz support |
16:10 |
kahrl |
zlib does g(un)zip, and minetest already links with it |
16:11 |
sapier |
I don't understand why ppl always reinvent the wheel |
16:11 |
sapier |
either we only support one format so we can live with zip |
16:12 |
sapier |
or we should use a well maintained lib to support tar |
16:12 |
sapier |
libarchive is bsd so maybe we could even include it with minetest but I didn't have a closer look at licenses |
16:12 |
sapier |
btw minizip (the code i added for zip) seems to be included with zlib 1.2.8 |
16:13 |
sapier |
in contrib folder |
16:13 |
kahrl |
I don't like adding too much useless code to minetest because it makes compile times horrible |
16:13 |
kahrl |
and most of libarchive will be useless, such as the compression routines |
16:13 |
sapier |
so plz help me fix the zlib linkage on windows ;-) |
16:13 |
sapier |
no libarchive uses zlib |
16:14 |
kahrl |
I mean the functions that write archive formats |
16:14 |
sapier |
no they're used to extract a tar |
16:14 |
celeron55_ |
8D |
16:14 |
celeron55_ |
-> |
16:14 |
sapier |
libarchive doesn't make a difference if you want to write to a file or disk |
16:15 |
|
BlockMen joined #minetest-dev |
16:16 |
sapier |
no matter kahrl if you disable libarchive support in my branch minetest still will crash on startup due to linker mess |
16:17 |
kahrl |
sapier: can you do a make clean; make VERBOSE=1 and paste the results? |
16:17 |
sapier |
if you can tell me how to get build output on mingw windows console? |
16:18 |
kahrl |
make VERBOSE=1 >output.txt 2>&1 |
16:18 |
sapier |
on windows? |
16:19 |
kahrl |
are you not using msys? |
16:19 |
sapier |
I'll try |
16:19 |
kahrl |
anyway cmd.exe supports redirection too but I'm not sure about the syntax |
16:20 |
sapier |
ok seems to work |
16:20 |
sapier |
but needs some time |
16:25 |
sapier |
is there a size limit on pastebin? :-) |
16:25 |
kahrl |
heh |
16:25 |
sapier |
75% but already 100kb |
16:26 |
kahrl |
pastebin.com has 512kb |
16:27 |
kahrl |
most of the code pastebins probably less |
16:27 |
sapier |
should be enough |
16:30 |
sapier |
ok once again this build was crap |
16:35 |
sapier |
kahrl do you have a win32 build env? |
16:35 |
kahrl |
no |
16:36 |
|
BlockMen left #minetest-dev |
16:36 |
sapier |
:-) I'm not even sure it's not only due to my environment ;-) |
16:36 |
sapier |
it's working on linux |
16:36 |
sapier |
both minizip as well as libarchive variant |
16:36 |
kahrl |
hmm |
16:39 |
|
Miner_48er joined #minetest-dev |
16:39 |
kahrl |
I guess it has to do with the link order, since everything else seems to be okay |
16:40 |
sapier |
grrr clean doesn't work on windows either |
16:40 |
kahrl |
have you tried putting the target_link_libraries for the ARCHIVE_LIBRARY before the one for ZLIB_LIBRARIES |
16:42 |
sapier |
kahrl I try to get it working without libarchive first :-) |
16:42 |
sapier |
it already failes with zlib/minizip source |
16:43 |
sapier |
but this may be related to msys providing it's own libz implementation |
16:59 |
Jordach |
i have noticed that PilzAdam has been unfair in the way he allows pull request merging: http://irc.minetest.ru/minetest/2013-06-09#i_3131063 |
16:59 |
Jordach |
http://irc.minetest.ru/minetest/2013-06-09#i_3131165 |
17:01 |
Jordach |
if he likes something in a certain way, it has a greater chance of a merge, but if it has something he hates, or just simply thinks it doesnt fit, he closes and throws it away |
17:01 |
sapier |
I didn't realize any mobs beeing upsreamed did I miss something? |
17:02 |
Jordach |
sapier, i am sure that PilzAdam will automatically vouch for Simple Mobs |
17:03 |
sapier |
lol ok that'd be adding a really really buggy mob implementation |
17:03 |
Jordach |
(also: if it's his own pull, he'll merge it and say everyone likes it) |
17:03 |
Calinou |
simple mobs are "buggy and slow" |
17:03 |
sapier |
no just buggy because fixing the bugs will make them slow |
17:04 |
Jordach |
no Lua mobs mod will be useful until main routines are actually in core |
17:05 |
Jordach |
sapier, consider main core routines for mobs |
17:05 |
Jordach |
and then expose them |
17:05 |
sapier |
I already did jordach it's just not as easy as it sounds at first |
17:06 |
Jordach |
sapier, even though AI (eg, movement, attacking, projectiles) still need to be in corfe |
17:06 |
Jordach |
core* |
17:06 |
sapier |
to avoid interfering mobs with core they need to be handled in a different thread ... but there's lot of preparations to do so |
17:06 |
sapier |
problem at moving them to core is you'll always loose configurability atm I try to move those things that are really necessary but keep those who don't |
17:08 |
sapier |
and still if you try mobf without agressive mobs you'll see there isn't that much load added with lua either |
17:08 |
Jordach |
sapier, projectile_entity with the same options as a regular entity, with the two extras: on contact - eg, node, player etc |
17:08 |
Jordach |
and node_damage / player_damage |
17:08 |
sapier |
don't see how this would improove anything |
17:09 |
sapier |
atm there are two big cpu hogs environment evaluation and player/mob interaction |
17:10 |
sapier |
moving first one to core will drop configurability almost completely thus different behaviour would be very difficult to implement |
17:10 |
sapier |
second one isn't very easy to optimize (but is way more promising) |
17:10 |
sapier |
still there are some pull requests waiting and optimizing mobs to and they are much more simple |
17:10 |
Jordach |
sapier, most mobs on their own usually just walk about randomly |
17:11 |
sapier |
jordach that's not true |
17:11 |
sapier |
once a player is near them they are supposed to react |
17:11 |
Jordach |
yes |
17:11 |
Jordach |
a chase param would be useful |
17:11 |
Jordach |
"player", would be nearest player under x,y,z |
17:12 |
sapier |
chase isn't enough too as some should run away ;-) |
17:12 |
Jordach |
flee = "player" |
17:12 |
sapier |
while some should avoid this surface others that |
17:12 |
sapier |
you see it's much more complicated ... it's easy to get the 90% cases (that's what simple mobs does) ... the other 10% are hard |
17:13 |
sapier |
first of all the surface detection function needs to be added |
17:13 |
sapier |
next is automatic animation speed adjustment as well as automatic rotation adjustment |
17:14 |
sapier |
both will improve player experience drasticaly as they smoothen mob movement on client |
17:14 |
sapier |
kahrl http://pastebin.com/6MTcpkqs |
17:37 |
kahrl |
sapier: I was confused earlier because I thought the functions that gave errors were zlib functions |
17:38 |
kahrl |
but I think I know what's happening now |
17:38 |
kahrl |
ZLIB_WINAPI is different between where those functions are defined (unzip.c) and where they are used (guiLuaApi.cpp) |
17:38 |
sapier |
hmm easy to test |
17:40 |
sapier |
but sounds reasonable |
17:53 |
sapier |
kahrl the linker errors are gone but it still crashes :-/ |
17:55 |
|
smoke_fumus joined #minetest-dev |
17:55 |
kahrl |
:| must be something unrelated then |
17:56 |
kahrl |
do you have a stacktrace? |
17:56 |
sapier |
#0 0x0334ac73 in ?? () |
17:56 |
sapier |
#1 0x00000000 in ?? () |
17:56 |
kahrl |
helpful |
17:56 |
sapier |
so not really a stack :-) |
17:57 |
sapier |
and this is already a debug build |
17:57 |
sfan5 |
stack corruption? |
17:58 |
sapier |
don't have valgrind on win32 to proof or deny |
17:58 |
kahrl |
where do --verbose output and debug.txt stop? |
17:58 |
sapier |
Irrlicht engine version 1.7.1 |
17:59 |
sapier |
I don't see any debug.txt ... hmm maybe this isn't a debug build as I wanted to have |
18:00 |
kahrl |
release builds create one too |
18:00 |
sapier |
and where? |
18:00 |
Exio |
~/.minetest/! |
18:01 |
sapier |
windows! |
18:01 |
Calinou |
(run in place) |
18:01 |
Calinou |
non run in place, maybe in %appdata% |
18:04 |
sapier |
found at apdata 0 bytes none at run in place |
18:05 |
sapier |
doesn't anyone have a proven to work win32 environment? :-) |
18:05 |
Calinou |
no |
18:06 |
sapier |
funny we support win32 env but there seems to be exactly one environment where build (by accindent) works? |
18:27 |
sapier |
same result running witing gdb in eclipse ... ok not surprising |
18:30 |
|
Anchakor joined #minetest-dev |
18:51 |
sapier |
great ... it's irrlicht 1.7.1 ... once compiling against 1.8 it's working |
18:56 |
dysoco |
Aw, was hoping I could develop from Windows |
18:56 |
dysoco |
I have a Linux box, although lately I haven't been booting it |
18:57 |
sapier |
you can |
18:57 |
sapier |
do it! |
18:57 |
dysoco |
I can then ? |
18:57 |
dysoco |
Or I can boot it? |
18:57 |
sapier |
we need ppl knowing how to build on windows ;-) |
18:57 |
dysoco |
Ah |
18:57 |
dysoco |
developing in Windows is a pain, really |
18:58 |
dysoco |
but a Minetest Visual C++ project wouldn't be that bad... |
18:58 |
thexyz |
sapier: everything is written in readme |
18:58 |
sapier |
I know :-) but if you want to do so you'll have unique knowledge noone else has :-) |
18:58 |
thexyz |
how's that? |
18:59 |
sapier |
no it's not there are still some minor things that will make your build fail |
19:00 |
dysoco |
The info is outdated |
19:00 |
dysoco |
and last time I tried it failed |
19:00 |
thexyz |
okay |
19:00 |
sapier |
that's result of none developing on windows |
19:01 |
sapier |
e.g. irrlicht 1.7.1 build fails without usable error message or debug stack |
20:30 |
|
MJaoune joined #minetest-dev |
20:30 |
|
serengeor joined #minetest-dev |
20:35 |
|
MJaoune left #minetest-dev |
21:03 |
|
emptty1 joined #minetest-dev |
21:11 |
|
mrtux_ joined #minetest-dev |
21:40 |
|
sapier joined #minetest-dev |
21:47 |
sapier |
https://github.com/sapier/minetest/tree/ngmm_minizip this works on windows ... |
21:47 |
sapier |
if you use irrlicht 1.8 and you have to use gettext as well as libarchive from msys |
21:48 |
sapier |
or disable libarchive support |
21:48 |
PilzAdam |
my win builds use Irrlicht 1.7.2 |
21:48 |
sapier |
maybe |
21:48 |
sapier |
I didn't try 1.7.2 |
21:48 |
PilzAdam |
and I dont really want to switch to 1.8 |
21:48 |
sapier |
i can only tell it doesn't run with 1.7.1 |
21:49 |
thexyz |
PilzAdam: that's not the reason to not include it |
21:49 |
sapier |
try with 1.7.2 maybe it's working too |
21:49 |
PilzAdam |
well, I though we support Irrlicht 1.7.* and 1.8 |
21:49 |
PilzAdam |
*thought |
21:50 |
thexyz |
for linux |
21:50 |
sapier |
minetest needs polishing for 1.8 textures are a little bit disorten |
21:50 |
sapier |
at least fullscreen textures |
21:50 |
thexyz |
do you really think one will want us to support <1.8 irrlicht on windows? |
21:52 |
PilzAdam |
well, fix the buildbot in utli/buildbot/ then |
21:52 |
sapier |
is there any reason why we don't use gettext and libz from msys? |
21:53 |
thexyz |
PilzAdam: -irrlicht_version=1.7.2 +irrlicht_version=1.8 |
21:53 |
sapier |
wait |
21:53 |
PilzAdam |
thexyz, last time I checked I needed to more .dlls |
21:53 |
PilzAdam |
*two |
21:53 |
sapier |
no |
21:54 |
sapier |
it's same |
21:54 |
sapier |
but built with 1.8 results in graphics errors |
21:54 |
sapier |
at least in main menu |
21:54 |
PilzAdam |
thexyz, and there are all the checkboxes and input fields that are somehow glitched out |
21:54 |
sapier |
scaling seems to be different in 1.8 |
21:54 |
thexyz |
PilzAdam: really? |
21:54 |
thexyz |
I didn't notice that in official build |
21:55 |
thexyz |
which uses 1.8 |
21:55 |
PilzAdam |
its in the official build too |
21:55 |
sapier |
is official build vs or mingw? |
21:55 |
PilzAdam |
msvc |
21:55 |
thexyz |
how sad |
21:57 |
thexyz |
PilzAdam: is this bug reported? |
21:57 |
PilzAdam |
its known AFAIK |
21:57 |
thexyz |
PilzAdam: issue #? |
21:58 |
PilzAdam |
there is no issue yet |
21:58 |
PilzAdam |
Ill create one |
22:00 |
PilzAdam |
https://github.com/minetest/minetest/issues/765 |
22:04 |
thexyz |
PilzAdam: http://i.imgur.com/Ee3Soye.png |
22:04 |
thexyz |
official 0.4.7 in wine |
22:04 |
sapier |
looks fine ? |
22:04 |
thexyz |
yes |
22:05 |
thexyz |
mine does, at least |
22:05 |
thexyz |
dunno what's wrong with PilzAdam' |
22:05 |
thexyz |
+s |
22:06 |
sapier |
it's disorted for me too thexyz |
22:06 |
PilzAdam |
there is a screenshot at the issue |
22:06 |
|
MJaoune joined #minetest-dev |
22:06 |
sapier |
but it's even worse |
22:07 |
thexyz |
PilzAdam: I see |
22:07 |
sapier |
and I can't compare to 1.7 as 1.7.2 doesn't work for me either |
22:07 |
thexyz |
PilzAdam: but it works fine for me in wine and in windows |
22:08 |
thexyz |
PilzAdam: what's your environment? |
22:08 |
PilzAdam |
its always like that for me with Irrlicht 1.8 in Linux and wine |
22:09 |
PilzAdam |
and with 1.7.2 in wine and 1.7.3 in Linux its normal |
22:10 |
thexyz |
then we should ask others to test it |
22:14 |
thexyz |
especiall windows users |
22:15 |
sapier |
I can only test 1.8 |
22:21 |
|
MNJaoune joined #minetest-dev |
22:22 |
|
Flux1234 joined #minetest-dev |
22:23 |
sapier |
http://imgur.com/Z2LYQ60 |
22:23 |
sapier |
this is what happens for me with 1.8 |
22:25 |
thexyz |
don't see anything wrong apart from the logo |
22:25 |
sapier |
yes this happens to all background textures |
22:26 |
PilzAdam |
selected input field is completly green and checkboxes are grey instead of white |
22:26 |
PilzAdam |
same issue as 765 |
22:26 |
sapier |
I guess this isn't an error but a missing color setting not beeing present in 1.7? |
22:27 |
thexyz |
uhhh? |
22:27 |
sapier |
colors are set by skin |
22:27 |
thexyz |
wait, so you think the one on the right is the correct? |
22:27 |
PilzAdam |
of course |
22:27 |
thexyz |
of course not |
22:28 |
PilzAdam |
it is how it has always been |
22:28 |
sapier |
I guess this is an error :-) |
22:28 |
PilzAdam |
its changed when you migrate to 1.8 |
22:28 |
kahrl |
I prefer them consistent with the other input fields |
22:29 |
thexyz |
ughh |
22:29 |
thexyz |
PilzAdam: you're wrong |
22:30 |
thexyz |
PilzAdam: https://github.com/minetest/minetest/commit/543fc6702f4ae9ad4dbc8289b8c3ed7d8b332cb1 |
22:31 |
sapier |
:-) not a bug but feature |
22:31 |
PilzAdam |
well, then change that |
22:31 |
thexyz |
I've never said it was a bug |
22:31 |
thexyz |
change what? |
22:31 |
thexyz |
it's how it's supposed to be |
22:31 |
thexyz |
PilzAdam: your irrlicht is probably pre-1.8 |
22:31 |
PilzAdam |
I used the official win build |
22:32 |
thexyz |
the official win build is at the left, correct? |
22:32 |
PilzAdam |
yep |
22:32 |
thexyz |
it looks just as it's supposed to look |
22:32 |
thexyz |
see the commit I linked |
22:32 |
PilzAdam |
yea, but it still looks wrong |
22:33 |
thexyz |
fuck |
22:33 |
thexyz |
i'm done with that |
22:33 |
sapier |
:-) I guess we've got a interpretation problem |
22:33 |
thexyz |
good night, all |
22:34 |
sapier |
pilzadam imho the new one is correct as it's consistent it's just a missing feature in 1.7 this can't be fixed there |
22:35 |
PilzAdam |
how is it "more consistent" in 1.8? |
22:35 |
sapier |
input fields are same and highlighting is really "highlighted" the way it was before isn't that obvious |
22:36 |
sapier |
maybe we should add the cursor in new version too I guess it's color is set wrong too |
22:37 |
sapier |
still I wonder what is wrong with that texture in my build :) |
22:40 |
PilzAdam |
sapier, I saw that in some youtube videos of previous MT win builds too, IIRC |
22:41 |
sapier |
strange |
22:41 |
sapier |
i thought it'd be a result of my mainmenu changes but if this can happen without it too ... hmm |
22:46 |
thexyz |
http://forum.minetest.net/viewtopic.php?pid=94144#p94144 |
22:46 |
thexyz |
oh wait, I forgot I'd gone to sleep |
23:00 |
|
celeron55 joined #minetest-dev |
23:50 |
|
Taoki joined #minetest-dev |