| Time |
Nick |
Message |
| 00:10 |
|
rsiska joined #minetest-dev |
| 00:36 |
|
ImQ009 joined #minetest-dev |
| 01:02 |
|
hmmmm joined #minetest-dev |
| 02:20 |
|
EvergreenTree joined #minetest-dev |
| 02:36 |
|
Exio4 joined #minetest-dev |
| 04:32 |
|
mrtux joined #minetest-dev |
| 05:34 |
|
Miner_48er joined #minetest-dev |
| 05:59 |
|
grrk-bzzt joined #minetest-dev |
| 06:01 |
|
damiel joined #minetest-dev |
| 06:13 |
|
ImQ009 joined #minetest-dev |
| 06:16 |
xyz |
sfan5: it seems there's no real need to use crystax ndk |
| 06:16 |
xyz |
the official one should work just as fine these days |
| 06:20 |
|
darkrose joined #minetest-dev |
| 06:25 |
sfan5 |
xyz: let me try compiling everything using the official one |
| 06:49 |
RealBadAngel |
looks like im ready with #1117 |
| 06:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/1117 -- Normal maps generation on the fly. by RealBadAngel |
| 06:49 |
RealBadAngel |
any opinions? |
| 06:50 |
|
rsiska joined #minetest-dev |
| 07:00 |
|
Gethiox joined #minetest-dev |
| 07:57 |
|
Gethiox joined #minetest-dev |
| 08:03 |
xyz |
sfan5: even if it doesn't work the preferred approach should be to fix it |
| 08:03 |
xyz |
crystax ndk seems a bit ded |
| 08:06 |
|
Robby joined #minetest-dev |
| 08:29 |
|
xyz|imaginary joined #minetest-dev |
| 08:59 |
|
darkrose joined #minetest-dev |
| 08:59 |
|
darkrose joined #minetest-dev |
| 09:02 |
|
Exio4 joined #minetest-dev |
| 09:32 |
|
Weedy_lappy joined #minetest-dev |
| 10:05 |
|
casimir joined #minetest-dev |
| 10:13 |
|
tomreyn joined #minetest-dev |
| 10:27 |
|
ImQ009 joined #minetest-dev |
| 10:52 |
|
PilzAdam joined #minetest-dev |
| 10:58 |
|
Jordach joined #minetest-dev |
| 11:28 |
|
grrk-bzzt joined #minetest-dev |
| 11:48 |
|
daspork joined #minetest-dev |
| 12:39 |
|
ImQ009 joined #minetest-dev |
| 12:45 |
xyz |
sfan5: so how's it? |
| 12:47 |
xyz |
> Changed the sys/cdefs.h header so that __WCHAR_TYPE__ is 32-bit for API levels less than 9, which means that wchat_t is 32-bit for all API levels. To restore the previous behavior, define the _WCHAR_IS_8BIT boolean variable. (Issue 57267) |
| 12:47 |
xyz |
> from june 2013 original r9 NDK |
| 12:50 |
|
tomreyn joined #minetest-dev |
| 13:46 |
daspork |
re: register_node. When using the nodebox type, is the geometry you specify via node_box:fixed in any way modifiable at runtime or is that what the identifier `fixed` is suppose to represent? |
| 13:46 |
daspork |
If there is documentation on this I would love to be pointed in that direction. |
| 13:50 |
|
werwerwer joined #minetest-dev |
| 13:56 |
|
proller joined #minetest-dev |
| 14:02 |
xyz |
no you can't modify it |
| 14:02 |
xyz |
you can't modify other properties either, they are sent to clients once |
| 14:04 |
daspork |
k. Was making some auto-connect wiring. The connection part is just visual so I wanted to avoid making tons of nodes and doing swapping. |
| 14:05 |
xyz |
this is the only way now |
| 14:06 |
xyz |
some people were working on a way to redefine node properties based on metadata |
| 14:06 |
xyz |
but this was never fully done |
| 14:06 |
RealBadAngel |
nore is workin on it atm |
| 14:07 |
|
hmmmm joined #minetest-dev |
| 14:07 |
RealBadAngel |
and about wireing there are already several mods that does it |
| 14:07 |
daspork |
Cool. When you mention that its sent to the client only once I am less sad about it, and understand. |
| 14:07 |
RealBadAngel |
pipeworks, mesecons, technic |
| 14:08 |
RealBadAngel |
all of them have autoconnecting routines |
| 14:08 |
daspork |
Yeah I looked through those. technic is your RealBadAngel? |
| 14:08 |
RealBadAngel |
kinda, its a teamwork |
| 14:10 |
RealBadAngel |
also autoconnecting of wires could be done as drawtype in the engine |
| 14:10 |
RealBadAngel |
that could save lotsa resources for more advanced mods |
| 14:10 |
daspork |
I have used irrlicht a lot, maybe I should look at it. |
| 14:11 |
RealBadAngel |
in fact it isnt that hard to code, there are already several drawtypes that does that |
| 14:11 |
RealBadAngel |
fences, framed glass for example |
| 14:13 |
RealBadAngel |
check out content_mapblock.cpp on drawtypes |
| 14:15 |
RealBadAngel |
hmmmm, here? |
| 14:15 |
daspork |
yea not a huge deal. just filling sime irrlicht containers |
| 14:16 |
RealBadAngel |
in fact autoconnecting in core should be way easier than in lua |
| 14:16 |
daspork |
When I saw it used cmake and irrlicht I thought "wow something thats getting mature that I might actually be able to help on...." |
| 14:19 |
daspork |
So the question is how generic should the drawtype be to be included. If it was very specific like connecting in six directions and abme to be modified with metadata its a small hack I think |
| 14:19 |
RealBadAngel |
i was thinkin on having defined only connections from center to inner sides of the node |
| 14:20 |
daspork |
The server should not care as I see it. Its only how its drawn to the user so. |
| 14:20 |
RealBadAngel |
and rotate them |
| 14:20 |
RealBadAngel |
then add them to form visual connections |
| 14:21 |
|
iqualfragile joined #minetest-dev |
| 14:22 |
RealBadAngel |
2 situations i can think of are climbable wires, that would need 2 nodeboxes |
| 14:22 |
RealBadAngel |
and 2nd pipelike that would need only one nodebox |
| 14:24 |
RealBadAngel |
well, wires would need also just one, from center of the wall to the edge |
| 14:24 |
RealBadAngel |
pipes on the other hand from center of the cube to the opposite wall |
| 14:25 |
daspork |
Yeah thats a good way to do it. I was kinda doing the IC2 thing and having a middle that gets drawn when nothing is connecting then the connections from the midde to the edges http://i.imgur.com/tGyuhEq.png |
| 14:26 |
RealBadAngel |
ah, to avoid overlay glitches (flickering textures) there should be defined junction and rest of the wire |
| 14:27 |
RealBadAngel |
so like on the picture, center part and the one that will go from it further |
| 14:29 |
RealBadAngel |
in case of single wire going through node junction will remain same size, when 2 or more junction could be scaled up to show the connections |
| 14:32 |
daspork |
and it looks like you register the type in script/cpp_api/s_node.cpp and define the identifier in nodedef.h? |
| 14:42 |
RealBadAngel |
well, lemme find my own commit that added glasslike_framed drawtype |
| 14:45 |
RealBadAngel |
nodedef.cpp + h, content_mapnode.cpp and that script file |
| 14:47 |
RealBadAngel |
https://github.com/minetest/minetest/commit/625a4c2e662f6b69b73a2a828d1b08d72e53ff73 |
| 14:48 |
daspork |
Thanks |
| 14:53 |
RealBadAngel |
hmmmm, http://i.imgur.com/7RdorjD.png look at FPS :) ive made it way faster |
| 15:01 |
sfan5 |
xyz: haven't gotten to try yet |
| 15:02 |
sfan5 |
+a chance |
| 15:05 |
RealBadAngel |
sfan5, have you tried #1117 ? |
| 15:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/1117 -- Normal maps generation on the fly. by RealBadAngel |
| 15:06 |
sfan5 |
not yet |
| 15:06 |
RealBadAngel |
its ready to be pushed, that bumpy effect works great with every texture pack |
| 15:07 |
RealBadAngel |
with default it looks even better than your bumpy tp ;) |
| 15:08 |
RealBadAngel |
http://i.imgur.com/PFYEr1i.jpg |
| 15:08 |
RealBadAngel |
^^ 128x borderlands tp |
| 15:17 |
sfan5 |
<RealBadAngel> with default it looks even better than your bumpy tp ;) |
| 15:17 |
sfan5 |
that could be because I just use flat textures and you use actual bumpmaps |
| 15:17 |
RealBadAngel |
yeah |
| 15:18 |
daspork |
RealBadAngel: I assume the usage of glasslike framed is setting the drawtype and tiles = {"frame.png", "glass.png"}? |
| 15:18 |
RealBadAngel |
daspork, yes |
| 15:18 |
RealBadAngel |
https://github.com/minetest-technic/framedglass/blob/master/init.lua#L39 |
| 15:19 |
sfan5 |
RealBadAngel: heres my code in case you want to take a look: https://gist.github.com/sfan5/9021327 |
| 15:23 |
|
proller joined #minetest-dev |
| 15:23 |
|
PilzAdam joined #minetest-dev |
| 15:35 |
daspork |
Personally I don't care about or want round pipes/wires so I think im just gonna do this real simple. Allow for a thickness and textures maybe. |
| 15:37 |
daspork |
I guess it would also be good to allow it to stick to blocks as an option for something like the red wire in one of those MC mods. |
| 15:37 |
|
proller joined #minetest-dev |
| 15:37 |
daspork |
^ instead of being centered |
| 15:40 |
RealBadAngel |
daspork, if you will read the nodebox def from node definition it will not matter its round, flat or whatever |
| 15:41 |
RealBadAngel |
let the modder decide on the shape |
| 15:42 |
daspork |
I wasnt sure if I should mess with NodeBox. I'd have to think about that. I do see how that drawtype works though. |
| 15:46 |
RealBadAngel |
if you let the modder define 2 things, a junction and a piece of wire, it will become universal for all kind of wires |
| 15:47 |
RealBadAngel |
engine code will have just to rotate them and calculate connections |
| 15:49 |
|
rubenwardy joined #minetest-dev |
| 15:49 |
daspork |
looking at it I can define a drawtype and still use the exising nodebox struct and methods like: https://github.com/minetest/minetest/blob/master/src/mapnode.cpp#L169 to get the geometry etc from the mod |
| 15:51 |
daspork |
thats a question kinda |
| 15:52 |
|
BlockMen joined #minetest-dev |
| 15:56 |
daspork |
or maybe just a nodebox.type.... |
| 16:03 |
|
Exio4 joined #minetest-dev |
| 16:29 |
|
rubenwardy left #minetest-dev |
| 16:34 |
|
Calinou joined #minetest-dev |
| 16:51 |
|
rubenwardy joined #minetest-dev |
| 17:01 |
sfan5 |
xyz: compiles fine with standard android ndk, I think we don't need it anymore |
| 17:10 |
|
proller joined #minetest-dev |
| 17:11 |
|
NakedFury joined #minetest-dev |
| 17:15 |
|
troller joined #minetest-dev |
| 17:15 |
|
proller joined #minetest-dev |
| 17:40 |
|
Zeitgeist_ joined #minetest-dev |
| 17:55 |
|
EvergreenTree joined #minetest-dev |
| 17:55 |
|
EvergreenTree joined #minetest-dev |
| 18:14 |
|
grrk-bzzt joined #minetest-dev |
| 18:36 |
sfan5 |
not this again: E/AndroidRuntime( 7146): java.lang.RuntimeException: Unable to start activity ComponentInfo{net.minetest.minetest/android.app.NativeActivity}: java.lang.IllegalArgumentException: Unable to load native library: /data/app-lib/net.minetest.minetest-1/libminetest.so |
| 18:36 |
sfan5 |
^ xyz, this is what happens when I compile without crystax |
| 18:37 |
sfan5 |
Cannot load library: soinfo_relocate(linker.cpp:976): cannot locate symbol "__mb_sb_limit" referenced by "libminetest.so"... |
| 18:38 |
sfan5 |
this probably means we can't use the official ndk yet |
| 18:40 |
ShadowNinja |
sfan5: Maybe this is helpfull: http://lists.freebsd.org/pipermail/freebsd-ports/2007-November/045017.html |
| 18:40 |
sfan5 |
well |
| 18:40 |
sfan5 |
the general problem is that the bionic libc has bad/none locale support |
| 18:58 |
VanessaE |
sfan5: isn't that the same error I get when I try to run your, xyz's, and stu's builds on my tabs? |
| 18:58 |
VanessaE |
oh wait, compile time. nevermine. |
| 18:58 |
VanessaE |
nevermind, too. |
| 19:02 |
sfan5 |
VanessaE: it is |
| 19:02 |
sfan5 |
anyway |
| 19:03 |
sfan5 |
I have something you can test on your tablet |
| 19:04 |
VanessaE |
sure |
| 19:05 |
sfan5 |
VanessaE: http://sfan5.duckdns.org/dltest |
| 19:05 |
sfan5 |
adb push dltest /data/local/tmp/dltest |
| 19:06 |
sfan5 |
then use adb shell, chmod it to 0775 and run it like this ./dltest <path to libminetest.so> |
| 19:07 |
VanessaE |
hold. |
| 19:13 |
VanessaE |
argh |
| 19:14 |
VanessaE |
how do I get this stupid shell to NOT wrap the lines to 80 chars so I can copy&paste the whole line out |
| 19:14 |
VanessaE |
? |
| 19:14 |
xyz |
sfan5: you sure you built it with correct headers and stuff? |
| 19:14 |
VanessaE |
(that is, the input line) |
| 19:14 |
sfan5 |
xyz: yes |
| 19:14 |
sfan5 |
absolutly |
| 19:15 |
sfan5 |
VanessaE: put http://www.busybox.net/downloads/binaries/latest/busybox-armv7l on your phone and use 'busybox ash' |
| 19:15 |
xyz |
well let me try this then |
| 19:15 |
VanessaE |
already have busybox :) |
| 19:16 |
xyz |
sfan5: what library asks for this symbol btw? |
| 19:16 |
sfan5 |
dunno |
| 19:16 |
sfan5 |
I pasted everything dlerror gave me |
| 19:17 |
sfan5 |
also here are the changes I made for it to compile: http://pastie.org/8742992 |
| 19:17 |
sfan5 |
(to minetest [my fork]) |
| 19:19 |
xyz |
sfan5: right so you're compiling with "make"? can you make clean and pastebin "make VERBOSE=1" output? |
| 19:19 |
sfan5 |
sure |
| 19:19 |
VanessaE |
sfan5: http://pastebin.ubuntu.com/6950521/ |
| 19:19 |
VanessaE |
oops |
| 19:19 |
VanessaE |
forgot to finish the command |
| 19:19 |
VanessaE |
ignore that |
| 19:20 |
VanessaE |
http://pastebin.ubuntu.com/6950524/ |
| 19:20 |
VanessaE |
that's the right now. |
| 19:20 |
VanessaE |
one* |
| 19:20 |
VanessaE |
so it ain't that the lib ain't found -- it's missing a component |
| 19:21 |
sfan5 |
ah |
| 19:21 |
VanessaE |
what moron decided "not found" was equivalent to "is missing a dependency"????? |
| 19:21 |
sfan5 |
your libz seems to be too old |
| 19:21 |
sfan5 |
dunnno |
| 19:21 |
sfan5 |
I hate that error message too |
| 19:21 |
VanessaE |
this is Android 4.1 |
| 19:21 |
sfan5 |
weeeeee- |
| 19:21 |
sfan5 |
guess we need to provice even libz statically to have maximum compatibility |
| 19:22 |
sfan5 |
provide* |
| 19:22 |
xyz |
VanessaE: hey hey, what about my .so? |
| 19:22 |
VanessaE |
watch it require 10x more static libs :) |
| 19:22 |
VanessaE |
xyz: don't have it handy at the moment :P |
| 19:22 |
xyz |
can you install it? |
| 19:22 |
sfan5 |
xyz: I have a guess why it does not work: I compiled curl with libcrystax |
| 19:23 |
sfan5 |
lemme try without curl |
| 19:23 |
xyz |
sfan5: just pastebin make VERBOSE=1 output |
| 19:23 |
xyz |
see |
| 19:23 |
xyz |
I said it's your fault :P |
| 19:24 |
VanessaE |
xyz: sure. |
| 19:24 |
VanessaE |
hold a bit. |
| 19:25 |
sfan5 |
VanessaE: could you follow http://dev.minetest.net/Android ? (if you do ping me before you do the minetest step) |
| 19:26 |
VanessaE |
sfan5: if I can remember to, sure :P |
| 19:26 |
|
Taoki joined #minetest-dev |
| 19:27 |
VanessaE |
root android:/ # /data//local/tmp/dltest /data/data/org.freeminer/lib/libFreeminer.so |
| 19:27 |
VanessaE |
Success |
| 19:28 |
xyz |
yet it doesn't work? |
| 19:28 |
VanessaE |
well I'm trying it now |
| 19:28 |
VanessaE |
it's copying its data right now |
| 19:28 |
xyz |
ah alright |
| 19:28 |
xyz |
that doesn't tell anything though, it'll try to load .so later |
| 19:28 |
sfan5 |
xyz: http://ix.io/ayU |
| 19:28 |
VanessaE |
data copy finished, crash. |
| 19:29 |
VanessaE |
E/AndroidRuntime( 1893): java.lang.RuntimeException: Unable to start activity ComponentInfo{org.freeminer/org.freeminer.MyNativeActivity}: java.lang.IllegalArgumentException: Unable to find native library: Freeminer |
| 19:29 |
xyz |
what about adb lolcat? |
| 19:29 |
xyz |
ah |
| 19:29 |
xyz |
it says unable to find |
| 19:29 |
VanessaE |
but that's *after* it copied its data |
| 19:29 |
xyz |
not unable to load |
| 19:29 |
xyz |
data copy is implemented in java |
| 19:29 |
xyz |
so it's not related really |
| 19:29 |
VanessaE |
oh ok. |
| 19:32 |
xyz |
ugh |
| 19:33 |
VanessaE |
now, what's the difference here between the result I got from your bin versus sfan5's? his just seems to need a static zlib, but why does yours fall down? |
| 19:33 |
xyz |
ok let's debug it |
| 19:35 |
ShadowNinja |
VanessaE: You should probably install a libz shared library... |
| 19:35 |
sfan5 |
ShadowNinja: she has one, but her's is apprently too old |
| 19:35 |
sfan5 |
(or I'm targetting a too-high android version) |
| 19:36 |
ShadowNinja |
Oh, OK. Update then. :-) |
| 19:36 |
VanessaE |
impossible. |
| 19:36 |
xyz |
no that just means your build is fcked |
| 19:36 |
xyz |
accept it |
| 19:36 |
VanessaE |
no updates are available for this device (I checked) |
| 19:36 |
ShadowNinja |
It's rooted, right? |
| 19:36 |
VanessaE |
yup |
| 19:36 |
sfan5 |
xyz: yep, works perfectly http://i.imgur.com/6sjQ9Ln.png |
| 19:36 |
ShadowNinja |
Then it should be doable. |
| 19:36 |
xyz |
sfan5: did you recompile all deps? |
| 19:37 |
sfan5 |
I recompiled those where I used crystax nd |
| 19:37 |
sfan5 |
k |
| 19:37 |
xyz |
no, you should recompile all deps |
| 19:37 |
xyz |
with same compiler version |
| 19:37 |
sfan5 |
wtf |
| 19:37 |
VanessaE |
ShadowNinja: doable, perhaps, but I doubt there's a >4.1 build available for this thing :P |
| 19:37 |
sfan5 |
that won't make any difference |
| 19:37 |
xyz |
and after a make clean |
| 19:37 |
xyz |
what did you use to compile them before? |
| 19:38 |
sfan5 |
normal android ndk |
| 19:38 |
xyz |
what version? what compiler? |
| 19:38 |
sfan5 |
anyway libpng, libjpeg or libbzip2 won't make a difference with localisation broken |
| 19:38 |
sfan5 |
dunno |
| 19:39 |
sfan5 |
those libs I compiled myself won't have any effect on this anyway |
| 19:39 |
xyz |
ok now you're literally making me try this |
| 19:39 |
xyz |
so wait a bit |
| 19:39 |
VanessaE |
lol |
| 19:42 |
sfan5 |
also why does minetest need libbzip2 for? |
| 19:42 |
sfan5 |
-for |
| 19:44 |
xyz |
for irrlicht probably, but irrlicht should include its own |
| 19:45 |
VanessaE |
aren't mapblocks also compressed? |
| 19:45 |
sfan5 |
no |
| 19:45 |
sfan5 |
sqlite has no compress by default |
| 19:45 |
sfan5 |
compression* |
| 19:46 |
sfan5 |
that means you CAN grep for default:dirt in map.sqlite |
| 19:46 |
VanessaE |
huh. ok. |
| 19:46 |
xyz |
we use zlib for that |
| 19:47 |
xyz |
no shit you can't |
| 19:47 |
sfan5 |
the node list is uncompressed IIRC |
| 19:48 |
xyz |
ah, you're probably right |
| 19:48 |
sfan5 |
stefanstefan-pc:~/minetest/worlds/test$ hd map.sqlite | grep default:dirt | head |
| 19:48 |
sfan5 |
00002b90 0c 64 65 66 61 75 6c 74 3a 64 69 72 74 00 01 00 |.default:dirt...| |
| 19:48 |
sfan5 |
000053f0 0c 64 65 66 61 75 6c 74 3a 64 69 72 74 0a 00 00 |.default:dirt...| |
| 19:48 |
sfan5 |
[...] |
| 19:54 |
|
rsiska joined #minetest-dev |
| 20:04 |
|
Miner_48er joined #minetest-dev |
| 20:05 |
EvergreenTree |
VanessaE: Made a better texture for #240 on minetest_game |
| 20:05 |
ShadowBot |
EvergreenTree: Error: ProcessTimeoutError: Process #272 (for String.re) aborted due to timeout. |
| 20:05 |
EvergreenTree |
lol |
| 20:05 |
EvergreenTree |
Shadowbot, you are looking in the wrong git repo |
| 20:05 |
EvergreenTree |
https://github.com/minetest/minetest_game/pull/240 |
| 20:06 |
EvergreenTree |
Anyone willing to merge? |
| 20:09 |
|
Megaf joined #minetest-dev |
| 20:10 |
xyz |
VanessaE: I have a great idea |
| 20:10 |
xyz |
how about you just mail your tablet to some of us? |
| 20:11 |
Jordach |
ehm |
| 20:11 |
xyz |
ok, to one of us |
| 20:11 |
Jordach |
better. |
| 20:11 |
EvergreenTree |
*cough* https://github.com/minetest/minetest_game/pull/240 added a better texture |
| 20:11 |
xyz |
sfan5: I seem to have the same issue with NDK r9c, g++ 4.6 and 4.8 |
| 20:11 |
xyz |
that's RETARDED |
| 20:12 |
xyz |
sfan5: do you have freetype? |
| 20:12 |
sfan5 |
xyz: that's because android's libc sucks |
| 20:12 |
sfan5 |
no |
| 20:13 |
|
domtron joined #minetest-dev |
| 20:13 |
xyz |
why? |
| 20:14 |
sfan5 |
why it sucks? |
| 20:14 |
xyz |
yup |
| 20:14 |
sfan5 |
because it does not support locale stuff completely |
| 20:14 |
sfan5 |
and the bits it does support are supported incorrectly |
| 20:14 |
xyz |
like what locale stuff? |
| 20:14 |
sfan5 |
struct lconv |
| 20:15 |
sfan5 |
aka. the thing you had to do to lua/src/llex.c to make it compile |
| 20:15 |
xyz |
ah |
| 20:15 |
xyz |
that's not a big problem |
| 20:15 |
sfan5 |
a libc does not support locale stuff if workarounds like this need to be done |
| 20:16 |
sfan5 |
s/if/correctly if/ |
| 20:16 |
sfan5 |
applying some workarounds for small things like that in llex.c is not a problem |
| 20:16 |
xyz |
is that stuff standardized? |
| 20:17 |
sfan5 |
but when it comes to bigger things such as real-serious localisation it gets too big to workaround |
| 20:17 |
xyz |
or is that some ganooo crap? |
| 20:17 |
sfan5 |
dunno |
| 20:17 |
xyz |
that could explain |
| 20:17 |
sfan5 |
I'm pretty sure locale stuff is in POSIX |
| 20:18 |
sfan5 |
but don't bet money on that |
| 20:19 |
sfan5 |
THERE! |
| 20:21 |
sfan5 |
xyz: http://pubs.opengroup.org/onlinepubs/9699919799/functions/localeconv.html lconv->decimal_point is POSIX standard |
| 20:21 |
sfan5 |
because android didn't have it we had to comment it out |
| 20:22 |
xyz |
right, found it |
| 20:24 |
xyz |
VanessaE: sorry, for now I'm too lazy to debug this over IRC |
| 20:24 |
EvergreenTree |
Sorry if I'm breaking discussion, but does anyone want to test https://github.com/minetest/minetest_game/pull/240? |
| 20:24 |
EvergreenTree |
*https://github.com/minetest/minetest_game/pull/240 |
| 20:24 |
xyz |
but what I think we should do, is: |
| 20:24 |
* sfan5 |
haz good idea |
| 20:24 |
sfan5 |
use static libc |
| 20:25 |
xyz |
(part of NativeActivity.java that fails https://gist.github.com/xyzz/c1b0991ad9b809adbdf8) |
| 20:25 |
xyz |
so we just need to get ai.applicationInfo.nativeLibraryDir and System.mapLibraryName(libname) outputs from you |
| 20:25 |
xyz |
sfan5: what compiler do you use to compile freetype btw? |
| 20:26 |
sfan5 |
I don't have freetype compiled |
| 20:26 |
xyz |
ah |
| 20:26 |
xyz |
well |
| 20:26 |
xyz |
BE FUCKING PREPARED |
| 20:26 |
sfan5 |
? |
| 20:27 |
sfan5 |
are you wanting to tell me that freetype is a pain in the ass to compile? |
| 20:30 |
xyz |
no it's pretty easy |
| 20:30 |
xyz |
but if you use crystax's gcc 4.6 and compile for armeabi |
| 20:30 |
xyz |
it'll produce invalid output |
| 20:31 |
xyz |
java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "__gnu_thumb1_case_uqi" referenced by "libapplication.so"... |
| 20:31 |
xyz |
you see |
| 20:31 |
xyz |
there's a big switch in cffgload.c |
| 20:31 |
xyz |
like, really big |
| 20:32 |
xyz |
or maybe you won't have this, dunno |
| 20:32 |
EvergreenTree |
Will someone please look at this? And the reason I'm repeating is because No one is paying any attention to me |
| 20:32 |
EvergreenTree |
https://github.com/minetest/minetest_game/pull/240 |
| 20:32 |
xyz |
so have fun |
| 20:33 |
xyz |
but that's not too bad |
| 20:33 |
xyz |
I mean, I had as from crystax ndk segfault on some files |
| 20:34 |
xyz |
[02:02:28] <xyz> https://gist.github.com/xyzz/ba3f39080ce66e8a14d6/raw/5395140ad36ea1fdef3a9023dd1c9d0c8691b567/gistfile1.txt |
| 20:34 |
xyz |
[02:02:46] <xyz> and this is when you realize |
| 20:34 |
xyz |
[02:02:48] <xyz> http://cdn.memegenerator.net/instances/500x/34064327.jpg |
| 20:35 |
xyz |
so it really could be a very good idea to switch away from it |
| 20:35 |
xyz |
because it's fucking ded |
| 20:35 |
sfan5 |
ok, how about a static libc? |
| 20:36 |
sfan5 |
freetype compiled, let me try to use it |
| 20:36 |
|
domtron joined #minetest-dev |
| 20:38 |
sfan5 |
oh awsome! |
| 20:38 |
xyz |
why'd you want to use static libc? |
| 20:38 |
sfan5 |
because we can then use a libc that supports localisation properly |
| 20:38 |
xyz |
(which is bionic) |
| 20:38 |
xyz |
it's just a one line change |
| 20:38 |
EvergreenTree |
It appears that attention is quite difficult to get attention here. Any tips on doing so? :P |
| 20:39 |
sfan5 |
apparently I can't tell cmake where to find freetype |
| 20:39 |
sfan5 |
xyz: one line change? which line? |
| 20:39 |
xyz |
to Lua? you already made that one |
| 20:39 |
sfan5 |
<sfan5> but when it comes to bigger things such as real-serious localisation it gets too big to workaround |
| 20:40 |
xyz |
I don't get the problem |
| 20:40 |
sfan5 |
ok, fix the broken mainemenu for me then |
| 20:40 |
sfan5 |
in one line please |
| 20:40 |
xyz |
how's that related to glibc/bionic issue? |
| 20:41 |
sfan5 |
the crystax ndk adds the stuff bionic does not have (proper locale support) |
| 20:41 |
xyz |
proper locale support? yet we still have to pastch that lua file |
| 20:41 |
sfan5 |
no we don't |
| 20:42 |
xyz |
can you provide a reference on that? |
| 20:42 |
sfan5 |
you are doing something wrong |
| 20:42 |
|
Gethiox joined #minetest-dev |
| 20:42 |
sfan5 |
it compiles just fine for me without patching that line |
| 20:42 |
sfan5 |
and the mainmenu works too |
| 20:42 |
xyz |
interesting |
| 20:43 |
xyz |
ah you probably use crystax/src/locale, right |
| 20:44 |
sfan5 |
no |
| 20:44 |
sfan5 |
not at compile-time |
| 20:44 |
sfan5 |
well yes |
| 20:44 |
sfan5 |
the headers of it |
| 20:44 |
sfan5 |
lua compiles fine for me with 0 percent changes |
| 20:44 |
xyz |
nice |
| 20:45 |
sfan5 |
that is 'proof' that crystax adds proper locale support |
| 20:45 |
xyz |
yup, figured it out |
| 20:45 |
sfan5 |
if we use a static libc we could use one that has full locale support |
| 20:45 |
sfan5 |
such as uclibc |
| 20:46 |
sfan5 |
the first minetestserver builds I made for android had a static uclibc compiled in |
| 20:46 |
sfan5 |
without that the chat did not even work |
| 20:49 |
xyz |
so I just checked |
| 20:49 |
sfan5 |
to sum it up: it would have the benefit of always being able to use the latest android ndk but having full support for locale stuff and other things bionic misses |
| 20:49 |
xyz |
and official NDK 9c provides localeconv as well |
| 20:49 |
sfan5 |
but without decimal_point attr |
| 20:49 |
xyz |
uh? no, it's here |
| 20:50 |
sfan5 |
so it still does not fully comply with the POSIX standard |
| 20:50 |
sfan5 |
explain why it fails to compile then? |
| 20:50 |
xyz |
sources/android/support/src/locale/localeconv.c |
| 20:50 |
sfan5 |
I'm using android-14 as target IIRC |
| 20:50 |
xyz |
let's see |
| 20:51 |
sfan5 |
android-15* |
| 20:55 |
sfan5 |
xyz: http://pastie.org/8743246 |
| 20:57 |
xyz |
uh |
| 20:57 |
xyz |
do you really expect it to work like that? |
| 20:57 |
xyz |
it's defined in sources/android/support so you should include this library |
| 20:58 |
sfan5 |
posix says it should work like this |
| 20:58 |
xyz |
really? |
| 20:58 |
sfan5 |
yes |
| 20:58 |
xyz |
I don't know so I'll believe you |
| 20:58 |
sfan5 |
it says we should include locale.h and not some other file the os provides itself |
| 20:58 |
xyz |
indeed |
| 20:59 |
xyz |
you include locale.h |
| 20:59 |
xyz |
what does posix say about include paths? |
| 20:59 |
sfan5 |
dunno |
| 20:59 |
|
domtron joined #minetest-dev |
| 20:59 |
xyz |
/tmp/ndk-arm/bin/arm-linux-androideabi-gcc -I ~/ndk/android-ndk-r9c/sources/android/support/include/ localeconv_test.c |
| 21:00 |
xyz |
so it's still POSIXey right? if you like this word so much |
| 21:00 |
sfan5 |
changing all includes because android's libc refuses to adhere posix is pointless |
| 21:00 |
xyz |
not all includes |
| 21:00 |
sfan5 |
many* |
| 21:00 |
xyz |
I didn't change your file at all |
| 21:00 |
sfan5 |
you know what I mean |
| 21:00 |
xyz |
no I don't |
| 21:00 |
xyz |
you just add it to include path |
| 21:00 |
xyz |
in one place |
| 21:01 |
sfan5 |
won't work |
| 21:01 |
sfan5 |
we need to compile android's support library and add it too |
| 21:01 |
xyz |
right |
| 21:01 |
sfan5 |
I'm pretty sure it won't link/load then |
| 21:01 |
xyz |
is that a problem? |
| 21:01 |
xyz |
why? |
| 21:01 |
sfan5 |
no that is not a problem |
| 21:01 |
xyz |
why won't it link or load? |
| 21:02 |
sfan5 |
but I don't like how the NDK just ignores any standards |
| 21:02 |
sfan5 |
well |
| 21:02 |
sfan5 |
it would link and maybe load too |
| 21:02 |
sfan5 |
but not work |
| 21:02 |
sfan5 |
android's support library defines decimal_point but because bionic does not have it we would access whatever element comes next in the struct |
| 21:03 |
xyz |
wat |
| 21:04 |
sfan5 |
It makes perfect sense to me |
| 21:04 |
xyz |
you just said some crazy shit and now it makes perfect sense to you |
| 21:04 |
xyz |
wtf |
| 21:04 |
sfan5 |
please tell my what is faulty in my logic |
| 21:06 |
sfan5 |
shall I illustrate with an example? |
| 21:06 |
xyz |
uh no need to act this smart |
| 21:06 |
xyz |
you know how linking works right? |
| 21:06 |
sfan5 |
yes I do |
| 21:06 |
xyz |
so |
| 21:06 |
xyz |
you compile that library which defines lconv, that function and friends |
| 21:06 |
xyz |
and then statically link it |
| 21:06 |
xyz |
and everything works fine |
| 21:07 |
xyz |
in that case |
| 21:07 |
xyz |
or what else do you need? |
| 21:08 |
sfan5 |
I was explaining you why it would not work if we DIDN'T link to the andrid support library |
| 21:08 |
sfan5 |
<sfan5> I'm pretty sure it won't link/load then |
| 21:08 |
sfan5 |
<xyz> why? |
| 21:08 |
xyz |
[01:02:13] <sfan5> it would link and maybe load too |
| 21:08 |
xyz |
[01:02:14] <sfan5> but not work |
| 21:08 |
xyz |
<sfan5> I was explaining you why it would not work if we DIDN'T link to the andrid support library |
| 21:08 |
xyz |
ah I see |
| 21:09 |
xyz |
I guess I missed something here |
| 21:10 |
sfan5 |
well |
| 21:10 |
sfan5 |
using android's library may be a good idea |
| 21:11 |
sfan5 |
but I would prefer to change as little minetest/irrlicht code (includes cmake/make) as possible |
| 21:11 |
sfan5 |
changing as little as possible could be achieved with a static libc compiled in (e.g. uclibc) |
| 21:12 |
sfan5 |
otherwise we'd need to add these include paths at many places |
| 21:12 |
sfan5 |
(this does not mean I'm against using androids' support library) |
| 21:13 |
xyz |
you're only supposed to alter Android.mk |
| 21:13 |
xyz |
but you use cmake right? |
| 21:14 |
xyz |
linking another libc just because of locale stuff seems weird to me |
| 21:15 |
xyz |
(I remember, the r word is prohibited in this channel) |
| 21:15 |
xyz |
anyway, this doesn't solve the problem with fonts |
| 21:15 |
sfan5 |
r word? |
| 21:15 |
sfan5 |
yes I use cmake |
| 21:16 |
xyz |
which is kinda strange since it appears in both irrlicht's internal and freetype renderers |
| 21:16 |
sfan5 |
and I think that is a good idea because future buildsystem changes don't need to be redone in something different |
| 21:16 |
xyz |
maybe |
| 21:18 |
xyz |
maybe it's another irrlicht bug? |
| 21:19 |
sfan5 |
maybe 8) |
| 21:19 |
sfan5 |
uh oh compiling uclibc requires linux kernel headers (what did I expect?) |
| 21:19 |
xyz |
but I already reported two or three and got ignored so I probably won't bother anymore |
| 21:19 |
xyz |
ah |
| 21:19 |
xyz |
well, have fun then |
| 21:19 |
sfan5 |
android-14 is 3.0.1 according to wikipeida |
| 21:19 |
xyz |
like, the one where lighting doesn't work |
| 21:20 |
sfan5 |
wikipedia* |
| 21:20 |
sfan5 |
oh right |
| 21:20 |
xyz |
ugh, you're processing doing (r word) things |
| 21:20 |
sfan5 |
how did you fix lightning? |
| 21:20 |
sfan5 |
[could you please just rell me what you mean by r word?] |
| 21:21 |
xyz |
I just patched it to not use EMT_TRANSPARENT_ALPHA_CHANNEL_REF |
| 21:22 |
sfan5 |
I assume the patch is in your repo |
| 21:22 |
xyz |
yes |
| 21:22 |
sfan5 |
ok, thx |
| 21:22 |
xyz |
sure |
| 21:23 |
xyz |
and then there's a fix to images being mirrored too |
| 21:23 |
xyz |
(why am I always doing all the awful work) |
| 21:24 |
sfan5 |
(because you chose to do things before me) |
| 21:24 |
xyz |
ah, should've close-sourced irrlicht instead :P |
| 21:24 |
sfan5 |
lol |
| 21:26 |
|
BrandonReese joined #minetest-dev |
| 21:26 |
sfan5 |
android's headers are that bad you can't even compile uclibc |
| 21:27 |
sfan5 |
'''' /tmp/android-gcc/sysroot/usr/include/linux/sysctl.h:25:13: error: expected ':', ',', ';', '}' or '__attribute__' before '*' token '''' |
| 21:28 |
sfan5 |
wow, there are even linux headers, I'm surpised |
| 21:28 |
xyz |
wait wait wait |
| 21:28 |
sfan5 |
? |
| 21:28 |
xyz |
you seriously are building it just because of lconv stuff? |
| 21:28 |
sfan5 |
I'm just trying |
| 21:28 |
sfan5 |
+to build it |
| 21:28 |
sfan5 |
just for fun |
| 21:28 |
sfan5 |
to test if it works |
| 21:29 |
xyz |
ok |
| 21:29 |
xyz |
I bet it won't work |
| 21:29 |
xyz |
feel free to waste your time though |
| 21:30 |
sfan5 |
it errors directly on the first * in the file (that is not a comment) |
| 21:31 |
|
proller joined #minetest-dev |
| 21:31 |
|
troller joined #minetest-dev |
| 21:31 |
sfan5 |
I wish I coul use clang |
| 21:31 |
sfan5 |
it would provide a helpful error |
| 21:31 |
xyz |
what's stopping you? |
| 21:32 |
sfan5 |
wait |
| 21:32 |
sfan5 |
you're right |
| 21:33 |
sfan5 |
wat |
| 21:33 |
sfan5 |
why is it using gcc |
| 21:33 |
sfan5 |
ok, I give up |
| 21:38 |
xyz |
sfan5: https://marcansoft.com/transf/meme-gcc.jpg |
| 21:38 |
|
Selat joined #minetest-dev |
| 21:39 |
|
proller joined #minetest-dev |
| 21:39 |
xyz |
that was quick |
| 21:39 |
xyz |
you give up on what exactly? |
| 21:51 |
|
proller joined #minetest-dev |
| 21:52 |
|
blaise joined #minetest-dev |
| 21:52 |
EvergreenTree |
https://github.com/minetest/minetest_game/pull/240 |
| 21:52 |
EvergreenTree |
^ someone look at it? |
| 21:52 |
EvergreenTree |
Aside from VanessaE? |
| 21:53 |
EvergreenTree |
I've been told no one cares by PilzAdam so I don't know if it's weven worth the trouble |
| 21:57 |
EvergreenTree |
Why does minetest_game even exist if no one pays any attention to it? I'm just trying to get noticed here |
| 22:02 |
|
john_minetest joined #minetest-dev |
| 22:04 |
xyz |
dunno |
| 22:05 |
xyz |
let's remove the repo then? |
| 22:11 |
VanessaE |
EvergreenTree: you have to excuse folks in -dev, when there's an ongoing discussion, sometimes other things will tend to be ignored as offtopic relative to it, until some time later on when the other things can be addressed. |
| 22:13 |
EvergreenTree |
Which is basically never it appears |
| 22:13 |
EvergreenTree |
*sigh* |
| 22:13 |
VanessaE |
naw it's just that minetest_game is harder to get things pushed into than core |
| 22:14 |
VanessaE |
because there's only two people who have both the interest AND the commit access to actually push |
| 22:14 |
EvergreenTree |
Which is kind of odd if you think about it |
| 22:14 |
VanessaE |
(and one of those two is...less than interested these days as he has his own project) |
| 22:15 |
EvergreenTree |
You think more caution should be taken when merging something to the engine |
| 22:15 |
EvergreenTree |
instead of minetest_game |
| 22:15 |
EvergreenTree |
I always thought it would be more difficult to merge to core |
| 22:15 |
EvergreenTree |
I guess I was wrong |
| 22:15 |
EvergreenTree |
:P |
| 22:16 |
VanessaE |
there are more people with both commit access, interest, and the skills to code for stuff that goes to core, that's why it's easier to get work done on it. |
| 22:16 |
VanessaE |
s/both// |
| 22:16 |
PilzAdam |
also there is that semi-official freeze of minetest_game |
| 22:16 |
VanessaE |
that too |
| 22:17 |
EvergreenTree |
The reason I don't make pull requests for core is I don't know C |
| 22:17 |
VanessaE |
but it's only frozen in so far as adding some major feature is concerned. |
| 22:17 |
EvergreenTree |
But I still want to contribute, so I try and do stuff on minetset_game |
| 22:17 |
|
proller joined #minetest-dev |
| 22:17 |
VanessaE |
PilzAdam: I think the point of the freeze is to prevent mt_game from breaking compatibility with the existing mods' code base and/or making major gameplay changes. |
| 22:17 |
VanessaE |
isn't it? |
| 22:18 |
PilzAdam |
there are several reasons |
| 22:18 |
|
domtron joined #minetest-dev |
| 22:18 |
VanessaE |
I don't recall anyone agreeing to an absolute moratorium on incremental improvements to the default game. |
| 22:18 |
PilzAdam |
one is that its almost impossible to change stuff without a shitstorm |
| 22:19 |
PilzAdam |
then we want to encourage that more games get created, instead of focusing on one |
| 22:19 |
VanessaE |
yes, and both of those boil down to backwards compatibility with the existing modders' codebases |
| 22:20 |
|
domtron joined #minetest-dev |
| 22:20 |
EvergreenTree |
The problem with not focusing on the default game is that any random newbie who comes on isn't going to know how to install a game, and is going to be turned away by the fact that minetest_game iis boring |
| 22:21 |
EvergreenTree |
so we are going to be stuck with elitists |
| 22:21 |
|
domtron joined #minetest-dev |
| 22:21 |
VanessaE |
asdly, he's right :( |
| 22:21 |
VanessaE |
sadly, too. |
| 22:21 |
PilzAdam |
EvergreenTree, there are 2 ways to fix that: 1) shipping more games with the engine 2) dont ship any games with the engine |
| 22:21 |
VanessaE |
so, drought or deluge? |
| 22:22 |
EvergreenTree |
Not shipping any games with the engine is even worse then having aboring default game |
| 22:22 |
PilzAdam |
how so? |
| 22:22 |
EvergreenTree |
-aboring +a +boring |
| 22:22 |
PilzAdam |
there could be a nice in-game game store or so |
| 22:22 |
EvergreenTree |
The point I just made is the fact that minetest is rarely used as an engine |
| 22:22 |
PilzAdam |
or rather, in-menu |
| 22:22 |
EvergreenTree |
PilzAdam: Then do that |
| 22:23 |
VanessaE |
an in-client "game store" would be a plus |
| 22:23 |
EvergreenTree |
If that's what you want, why haven't you done it yet? |
| 22:23 |
EvergreenTree |
The problem is that there are barely any games |
| 22:23 |
PilzAdam |
I dont have the time currently |
| 22:23 |
EvergreenTree |
that aren't deprecated |
| 22:23 |
EvergreenTree |
by "you" I mean the core devs |
| 22:24 |
VanessaE |
At some point there is a plan to include Nodetopia, right? |
| 22:24 |
PilzAdam |
there are 1) eden, 2) Nodetopia 3) minetest_game 4) OCD 5) Wasteland 6) capture the flag 7) c55's dungeon game |
| 22:25 |
VanessaE |
And BloatTest ;) |
| 22:25 |
PilzAdam |
you finally found a name for your game? |
| 22:25 |
VanessaE |
nope |
| 22:25 |
EvergreenTree |
I thought wasteland was a mod? |
| 22:25 |
VanessaE |
but you figured out which one I was talking about :D |
| 22:25 |
PilzAdam |
well, your game is basically modded minetest_game |
| 22:25 |
VanessaE |
yup |
| 22:26 |
PilzAdam |
while all the other listed games are not based on each other |
| 22:26 |
VanessaE |
it's minetest_game modded about as far as you can logically take it |
| 22:26 |
EvergreenTree |
The problem with not having a default game is that there isn't anything to go off of |
| 22:26 |
EvergreenTree |
there should be a default |
| 22:26 |
PilzAdam |
well, I guess capture the flag is based on mt_game |
| 22:26 |
PilzAdam |
EvergreenTree, thats exactly my point: there cant be _one_ default |
| 22:26 |
EvergreenTree |
Well, It's nice to know that all my efforts on minetest_game have gone to waste |
| 22:27 |
PilzAdam |
if there is one default game then youll face the problems we currently have with mt_game |
| 22:27 |
VanessaE |
I should continue to tune the one I use on 30005 and release the result as "FrenchVanilla" |
| 22:27 |
VanessaE |
:) |
| 22:27 |
EvergreenTree |
I guess I shouldn't even bother with developing minetest if this is the response I'm going to get |
| 22:27 |
VanessaE |
EvergreenTree: one sec.. |
| 22:28 |
VanessaE |
PilzAdam: to be fair, mt_game isn't entirely dead - Sam II did just go in. that part was welcomed by pretty much everyone. the capes thing was decried by a few people (myself included) because it violated standards, but no one opted to remove it |
| 22:28 |
VanessaE |
THAT is the sort of "shitstorm" we need to be wary of. |
| 22:29 |
VanessaE |
not because there are changes, but because we need to be acutely aware of what our users have come to expect as "standard practice" |
| 22:30 |
PilzAdam |
what about finite lava? |
| 22:30 |
PilzAdam |
it didnt break anything |
| 22:30 |
VanessaE |
PilzAdam: most people hated that change. I personally don't care much about it. |
| 22:30 |
PilzAdam |
your theory that its all about mod compatibility is wrong |
| 22:31 |
EvergreenTree |
To be honest: Is adding an animated furnace front to minetest going to cause a "sh*tstorm"? |
| 22:31 |
VanessaE |
ok let's make a guess: |
| 22:31 |
EvergreenTree |
It isn't even a change to the gameplay |
| 22:31 |
VanessaE |
what exactly do you figure is likely to happen should evergreen's animated furnace go in? |
| 22:32 |
VanessaE |
ok, I'll hate evergreen for about a week until I get around to making an appropriate HDX texture to match ;) but that's about it :) |
| 22:32 |
EvergreenTree |
^ that is what should be considered when something is merged to minetest_game |
| 22:32 |
PilzAdam |
when nobody is working on minetest_game (for reasons we just discussed) then also nobody is interested in these little tweaks |
| 22:32 |
EvergreenTree |
VanessaE: lo |
| 22:32 |
PilzAdam |
thats why they mostly get ignored |
| 22:32 |
VanessaE |
but really, this one's so minor that no one's gonna complain about it |
| 22:32 |
EvergreenTree |
*lol |
| 22:33 |
VanessaE |
*throws washcloth down on table* |
| 22:33 |
EvergreenTree |
I'll bet every texture pack creator is going to be mad at me for a little while |
| 22:33 |
EvergreenTree |
:P |
| 22:33 |
VanessaE |
All right. you know what? give ME commit access and I will push it myself. |
| 22:33 |
EvergreenTree |
In fact, I'll have to create a new texture for mt-faithful |
| 22:34 |
VanessaE |
(the washcloth was handy because I'm munching on cheese doodles and avoiding orange finger syndrome :P ) |
| 22:34 |
EvergreenTree |
It isn't that difficult to do |
| 22:34 |
Jordach |
VanessaE for minetest_game maintanence |
| 22:34 |
EvergreenTree |
No one is really in charge of minetest_game atm |
| 22:34 |
EvergreenTree |
Because none of the core devs care about it |
| 22:34 |
VanessaE |
ok maybe not, because the second thing I'd do, Jordach, is revert the capes thing :P |
| 22:35 |
PilzAdam |
didnt I already suggest VanessaE as minetest_game maintainer a while ago? |
| 22:35 |
VanessaE |
and the third thing I'd do is merke Taoki's bugfix to the player model. |
| 22:35 |
PilzAdam |
and didnt she refuse to do it? |
| 22:35 |
EvergreenTree |
Also, texture pack creators don't even really need to do anything |
| 22:35 |
domtron |
is the default "mod" separate from mintest_game? A lot of mods depend on it so it should be improved right? |
| 22:35 |
VanessaE |
PilzAdam: you did and I declined - I didn't want the responsibility at the time. |
| 22:35 |
VanessaE |
domtron: no, it's part of it, but it could be used separately with few changes. |
| 22:36 |
EvergreenTree |
Do you now? It's not very difficult considering the low traffic on it |
| 22:36 |
PilzAdam |
"default" is basically a huge bad design decission |
| 22:36 |
VanessaE |
PilzAdam: see what RealTest did - it split "default" into a bunch of sub-mods. |
| 22:36 |
VanessaE |
real pain in the ass to find anything in THAT game |
| 22:36 |
PilzAdam |
VanessaE, guess what I did in Nodetopia |
| 22:39 |
EvergreenTree |
You |
| 22:39 |
EvergreenTree |
whoops |
| 22:39 |
EvergreenTree |
You're right about that, the name "default" is a bad naming choice |
| 22:40 |
VanessaE |
indeed |
| 22:41 |
VanessaE |
in retrospect it was a bad choice, |
| 22:41 |
VanessaE |
it can be fixed but it'll take time. |
| 22:41 |
EvergreenTree |
Yes |
| 22:41 |
EvergreenTree |
It would be a huge change considering the amount of stuff that relies on the default name |
| 22:41 |
VanessaE |
yesh |
| 22:41 |
VanessaE |
yes |
| 22:42 |
Jordach |
minetest.register_alias is your friend |
| 22:42 |
VanessaE |
that won't help depends.txt |
| 22:42 |
EvergreenTree |
yep |
| 22:43 |
EvergreenTree |
and it still requires mod creators to update their mods |
| 22:43 |
VanessaE |
no need to change the node names (though that's what aliases are for) - the problem is dependency upheaval. |
| 22:43 |
VanessaE |
you just can't do that now, not unless you just want to break EVERYTHING. |
| 22:43 |
VanessaE |
either that or the engine needs to have a compatibility flag |
| 22:43 |
EvergreenTree |
^ that's the problem |
| 22:44 |
Jordach |
VanessaE, my suggested method is to keep the current one, and start over for 0.5.x |
| 22:44 |
EvergreenTree |
aliases won't help in some cases |
| 22:44 |
VanessaE |
if it sees "default" in depends.txt, it automatically searches for libs x, y, z.... |
| 22:44 |
VanessaE |
but that's a bandaid |
| 22:45 |
Jordach |
why don't we just tear down the parchment and tell them to start over if they don't like it, deal with it (there does need some dictatorship around here) |
| 22:45 |
EvergreenTree |
I think it's kind of funny that we were talking about merging #240 30 minutes ago, and now we are talking about changing the name default |
| 22:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/240 -- Creative inventory |
| 22:45 |
VanessaE |
the problem of a dictatorship is....who's the dictator? |
| 22:45 |
EvergreenTree |
ShadowBot: wrong pull |
| 22:45 |
Jordach |
VanessaE, which means there does need to be a maintainer of minetest_game |
| 22:46 |
VanessaE |
Shadowbot is supposed to refer to minetest_game for ID's < 1000 isn't it? |
| 22:46 |
ShadowBot |
VanessaE: Error: Missing ">". You may want to quote your arguments with double quotes in order to prevent extra brackets from being evaluated as nested commands. |
| 22:46 |
VanessaE |
shaddup, bot :P |
| 22:46 |
EvergreenTree |
lol |
| 22:46 |
VanessaE |
EvergreenTree: 240 -> changing default....welcome to -dev. |
| 22:47 |
VanessaE |
but it all goes together, it's all on the same subject: how to properly maintain minetest_game and keep it from becoming stale. |
| 22:48 |
VanessaE |
my 30005 server has inexplicably become very popular lately, and it runs a very-lightly-modded mt_game (only enough stuff added to make administration a breeze, plus a couple of things to keep it interesting, e.g. gloopblocks, snowdrift) |
| 22:48 |
VanessaE |
and it's because of these tablet clients |
| 22:48 |
VanessaE |
so a "simple" game has suddenly become acutely necessary |
| 22:49 |
VanessaE |
which means mt_game can't die. we have to have a simple, default game that is actively maintained. |
| 22:50 |
Jordach |
here's the deal: we have two games: minetest_mini and minetest_mega, mega being the new game, while mini takes the traits of the current mt_game |
| 22:50 |
EvergreenTree |
We tried the multiple games thing before |
| 22:50 |
VanessaE |
Jordach: three - mini (Nodetopia), standard (mt_game), mega (my game, perhaps). |
| 22:50 |
EvergreenTree |
it didn't really work |
| 22:50 |
VanessaE |
EvergreenTree: no, we tried a shanda navara before. |
| 22:50 |
|
domtron joined #minetest-dev |
| 22:50 |
EvergreenTree |
Nodetopia? |
| 22:50 |
EvergreenTree |
Mini? |
| 22:51 |
Jordach |
VanessaE, get the modders involved with your pack first |
| 22:51 |
VanessaE |
EvergreenTree: that thing we did before was an abortion :P |
| 22:51 |
EvergreenTree |
oh right, I was thinking of eden |
| 22:51 |
EvergreenTree |
nodetopia would be perfect for mini |
| 22:51 |
EvergreenTree |
VanessaE: true |
| 22:51 |
PilzAdam |
EvergreenTree, Nodetopia isnt finished at all |
| 22:51 |
EvergreenTree |
By the way, is the new texture better? |
| 22:51 |
EvergreenTree |
PilzAdam: didn't say it was |
| 22:51 |
VanessaE |
it seems better, yeah |
| 22:51 |
EvergreenTree |
but it's still very good for a minimalistic game |
| 22:51 |
Jordach |
i meant mega to be built from the current game, but with simple mobs, farming+, MGV7, technic(?!!), more biomes, actual things to accomplish |
| 22:51 |
VanessaE |
I have not tried it yet, just looked at the pull. |
| 22:52 |
|
domtron joined #minetest-dev |
| 22:52 |
EvergreenTree |
mega shouldn't have mobs simply because they are too buggy, but that's another topic |
| 22:52 |
Jordach |
and probably some bits inbetween to half cool stuff out of THAT game, and some generic survival inbetween the cement |
| 22:53 |
VanessaE |
EvergreenTree: actually mobs are fine if you don't have to deal with a network connection between you and the server process (or you don't care about the bandwidth usage) |
| 22:53 |
VanessaE |
simple mobs is a good mod to use for the purpose |
| 22:53 |
EvergreenTree |
Speaking of changes to minetest_game, shouldn't lava destroy items when thrown into it? |
| 22:53 |
VanessaE |
EvergreenTree: builtin_features does that |
| 22:53 |
VanessaE |
(I think technic also has that option) |
| 22:53 |
EvergreenTree |
Oh, okay |
| 22:54 |
Jordach |
a trash field is more effective for clearing cobble |
| 22:54 |
Jordach |
or just a button to clear cobble in general |
| 22:54 |
VanessaE |
one of the biggest requests from my users was xyz's sethome mod |
| 22:54 |
VanessaE |
so I broke down and installed it |
| 22:54 |
EvergreenTree |
*cough* Trash cans *cough* |
| 22:54 |
VanessaE |
so that one should be slated for inclusion in mt_game |
| 22:54 |
Jordach |
and no: home decor doesn't fit with the mega idea |
| 22:54 |
EvergreenTree |
Maybe as an option? It is kind of cheaty |
| 22:55 |
Jordach |
EvergreenTree, we already have /pulverize |
| 22:55 |
VanessaE |
EvergreenTree: not really cheaty - you can already teleport yourself anyway if you're running in singleplayer. |
| 22:55 |
EvergreenTree |
no, I'm talkingto VanessaE |
| 22:55 |
VanessaE |
/grant singleplayer all ; /teleport (some coords) |
| 22:55 |
EvergreenTree |
VanessaE: I suppose so |
| 22:55 |
VanessaE |
it just gives you a shortcut for it. |
| 22:56 |
EvergreenTree |
But the option should just be there for server creators(I suppose you could just remove the code for it) |
| 22:56 |
EvergreenTree |
most servers run custom games anyway |
| 22:56 |
VanessaE |
for a server operator yeah, you'd just delete the mod if you don't want it. |
| 22:58 |
EvergreenTree |
Back to the topic: Should 240 be merged? |
| 22:58 |
EvergreenTree |
The discussion was fun though |
| 22:59 |
VanessaE |
I'd say yes, it does nothing to change gameplay, and makes the furnaces look a little better. |
| 23:00 |
EvergreenTree |
Anyone else? |
| 23:07 |
EvergreenTree |
Anyone else willing to merge? |
| 23:09 |
EvergreenTree |
I'm starting to wonder if I accomplished anything with this discussion |
| 23:09 |
EvergreenTree |
Because the moment I mention merging something, the discussion stops |
| 23:09 |
EvergreenTree |
:P |
| 23:09 |
VanessaE |
that's just how this channel is :P |
| 23:09 |
* VanessaE |
pokes ShadowNinja |
| 23:10 |
ShadowNinja |
Hmmm? |
| 23:10 |
VanessaE |
ShadowNinja: can we get a merge/no-merge on mt_game pull #240 ? |
| 23:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/240 -- Creative inventory |
| 23:11 |
VanessaE |
and can you fix THAT ^^^^^ also? :P |
| 23:11 |
VanessaE |
(the bot always quotes the wrong pull when the number is < 1000 ) |
| 23:11 |
ShadowNinja |
VanessaE: I switched it on the request of other devs. |
| 23:11 |
VanessaE |
oh, well it's still wrong :P |
| 23:11 |
VanessaE |
https://github.com/minetest/minetest_game/pull/240 <--- that one. |
| 23:11 |
ShadowNinja |
And that pull needs one ore indentation level, I haven't checked the textures. |
| 23:12 |
VanessaE |
oh yes, I see it. |
| 23:12 |
VanessaE |
EvergreenTree: lines 899-908, indent by 1 level. |
| 23:13 |
VanessaE |
(I rarely look at code style when I'm checking a pull, unless it just plain burns my eyes :P ) |
| 23:13 |
EvergreenTree |
oh, right |
| 23:14 |
|
OldCoder joined #minetest-dev |
| 23:15 |
VanessaE |
ShadowNinja: btw, is it just for me that github no longer shows image changes in some pulls? |
| 23:15 |
EvergreenTree |
done |
| 23:16 |
EvergreenTree |
Is it good now? |
| 23:16 |
VanessaE |
no, you need to push 904-908 over to the right, they should be indented past 903 |
| 23:16 |
VanessaE |
well AT 903 |
| 23:17 |
VanessaE |
so just move them over one also. |
| 23:17 |
EvergreenTree |
oh right |
| 23:18 |
EvergreenTree |
Done |
| 23:19 |
ShadowNinja |
Seems good. I'll push it soon of nobody objects. |
| 23:19 |
VanessaE |
I'd move 905-907 over one more level also but this is good enough I think. |
| 23:20 |
EvergreenTree |
Okay, I can do that quickly |
| 23:21 |
EvergreenTree |
done |
| 23:21 |
VanessaE |
that's good. |
| 23:22 |
ShadowNinja |
Don't bother toughing it anymore. I have it prepared locally. |
| 23:22 |
ShadowNinja |
touching* |
| 23:22 |
EvergreenTree |
okay |
| 23:22 |
|
OldCoder joined #minetest-dev |
| 23:23 |
VanessaE |
he can't toughen it up any? well shit. so much for adding rebar to the mortar in the furnace.... |
| 23:23 |
* VanessaE |
ducks |
| 23:23 |
EvergreenTree |
lol |
| 23:42 |
* EvergreenTree |
pokes ShadowNinja |
| 23:44 |
|
OldCoder joined #minetest-dev |
| 23:45 |
EvergreenTree |
Okay, can someone else merge it? |
| 23:45 |
EvergreenTree |
he said he would merge it in 15 minutes |
| 23:45 |
VanessaE |
"patience, young padawan." |
| 23:47 |
EvergreenTree |
Woohoo star wars references |
| 23:47 |
ShadowNinja |
d5fcae0..a5dcf12 master -> master |
| 23:48 |
VanessaE |
http://www.youtube.com/watch?v=81LQnWPVqSI |
| 23:49 |
EvergreenTree |
I also created a mew branch this time |
| 23:49 |
EvergreenTree |
-m +n |
