| Time |
Nick |
Message |
| 00:11 |
|
BlockMen left #minetest-dev |
| 00:23 |
|
Splizard joined #minetest-dev |
| 00:23 |
|
iqualfragile joined #minetest-dev |
| 00:36 |
|
iqualfragile_ joined #minetest-dev |
| 00:42 |
|
kahrl joined #minetest-dev |
| 01:28 |
|
smoke_fumus joined #minetest-dev |
| 04:41 |
|
neko259 joined #minetest-dev |
| 05:56 |
|
RealBadAngel joined #minetest-dev |
| 06:14 |
|
darkrose joined #minetest-dev |
| 06:42 |
celeron55 |
proller: no no no |
| 06:42 |
celeron55 |
no |
| 06:42 |
celeron55 |
and no |
| 06:43 |
celeron55 |
half of that doesn't make any sense |
| 06:46 |
celeron55 |
or not half but... some |
| 06:46 |
celeron55 |
the addition of ", used for client-server transfer" to serialization.h is, like, poisonous |
| 06:47 |
celeron55 |
it's wrong documentation; version 26 is a HACK you're doing, not something that will be endorsed in the long term |
| 06:49 |
celeron55 |
then, why do you do "int version = protocol_version >= 21 ? 2 : 1;" in NodeBox::serialize()? |
| 06:49 |
celeron55 |
oh, actually that's right |
| 06:49 |
* celeron55 |
is waking up |
| 06:51 |
celeron55 |
ugh |
| 06:54 |
celeron55 |
i really want serialize.h to read "26: Never written; read the same as 25", and have SER_FMT_VER_HIGHEST to be changed to SER_FMT_VER_HIGHEST_READ and SER_FMT_VER_DISK to be changed to SER_FMT_VER_HIGHEST_WRITE... and then add MapBlock::serializeNetworkSpecific() which will be added separately to the TOCLIENT_BLOCKDATA packet |
| 06:54 |
celeron55 |
it's not clean otherwise |
| 06:55 |
celeron55 |
and remove everything you have ever added to MapBlock::serialize/deSerialize |
| 06:55 |
|
Taoki[laptop] joined #minetest-dev |
| 07:07 |
|
nalkri joined #minetest-dev |
| 07:08 |
hmmmmm |
why did this mess happen in the first place |
| 07:09 |
hmmmmm |
am i mistaken, or is what this is accomplishing completely trivial |
| 07:09 |
hmmmmm |
i have no clue why you can't just have one mapblock serialization version for both disk and network |
| 07:10 |
hmmmmm |
er, rather, why this isn't handled in the same manner as things that are already not transferred over the network |
| 07:11 |
|
Akien joined #minetest-dev |
| 07:23 |
celeron55 |
hmmmmm: you're not being too clear about how you think it should be made |
| 07:23 |
celeron55 |
what are those "things that are already not transferred over the network"? |
| 07:24 |
celeron55 |
this is a thing that *is* transferred over the network, but *not* saved on disk; which didn't yet exist and because of that proller did it terribly and nobody didn't notice why it was wrong |
| 07:25 |
hmmmmm |
maybe i should read up on some past conversations in case i missed something |
| 07:25 |
celeron55 |
(also that patchset combines fixes for two completely separate things) |
| 07:25 |
celeron55 |
hmmmmm: i want you to do a thing ASAP, by the way |
| 07:25 |
celeron55 |
hmmmmm: you need to rename your fork of jthread NOW |
| 07:26 |
hmmmmm |
but this is beside the point, why isn't the entire mapblock version at 26 |
| 07:26 |
celeron55 |
it's causing real packaging problems |
| 07:26 |
hmmmmm |
on some odd linux distros... it should be enough to just disable searching for the system copy |
| 07:26 |
hmmmmm |
do you actually want me to *rename* it? how do i even go about that |
| 07:27 |
celeron55 |
odd linux distros? hell, all linux distros provide their own version of jthread |
| 07:27 |
celeron55 |
it's not odd in any way |
| 07:27 |
hmmmmm |
i don't recall mainstream distros having problems with this |
| 07:27 |
celeron55 |
you have to rename it because libraries are searched by name |
| 07:27 |
hmmmmm |
just this one that nobody's ever heard of |
| 07:27 |
hmmmmm |
and that was a long time ago but nobody seemed concerned about it for quite a while |
| 07:28 |
hmmmmm |
so tell me exactly what i'd need to do here (i'm not too knowledgable with cmake) |
| 07:28 |
celeron55 |
isn't it enough for you that having a different library with the same name is just totally wrong? |
| 07:29 |
celeron55 |
well me neither |
| 07:29 |
hmmmmm |
i'm guessing here but, first i'd need to remove cmake/Modules/FindJthread.cmake |
| 07:29 |
hmmmmm |
who is the one who originally did the cmake build system anyway? |
| 07:30 |
celeron55 |
me, altough it contains more lines by others than me |
| 07:30 |
hmmmmm |
alright hold on a minute, i don't see what's wrong with just having it always use the project version |
| 07:30 |
hmmmmm |
i'd omit the majority of FindJthread.cmake |
| 07:31 |
hmmmmm |
just leave those three statements after ELSE(JTHREAD_FOUND) |
| 07:31 |
hmmmmm |
that would fix it, sure, but it's not really a complete solution |
| 07:31 |
celeron55 |
umm |
| 07:31 |
hmmmmm |
renaming stuff is a lot of work you know |
| 07:31 |
celeron55 |
so does that fix the linker getting the global jthread via -ljthread? |
| 07:32 |
celeron55 |
also, does that make cmake not use a global FindJthread if such exist? |
| 07:32 |
hmmmmm |
it does?? well shit |
| 07:32 |
celeron55 |
i don't know |
| 07:32 |
hmmmmm |
i'd rather look it up and be sure though |
| 07:33 |
hmmmmm |
but nevermind this |
| 07:33 |
hmmmmm |
i wouldn't do something as hacky as that, renaming it would be the proper thing |
| 07:34 |
celeron55 |
i'd like to have Akien now here trying stuff out |
| 07:34 |
celeron55 |
maybe he comes if we wait a bit |
| 07:34 |
hmmmmm |
akien?? |
| 07:34 |
hmmmmm |
oh, i guess he was the most recent person to complain about this |
| 07:34 |
celeron55 |
that's who complained about it last evening |
| 07:34 |
hmmmmm |
sorry, haven't been keeping up with things |
| 07:35 |
hmmmmm |
you realize i won't be able to actually test this myself, right? |
| 07:35 |
celeron55 |
yes, and me neither |
| 07:36 |
celeron55 |
let's wait for Akien, i don't like and don't expect anyone else to like doing unnecessary work... |
| 07:37 |
celeron55 |
it could be that this can be solved in some very simple way but we can't know unless it can be tested |
| 07:37 |
hmmmmm |
i guess this is just three cases actually: me, whose os doesn't have a jthread package in the first place, someone on linux who has it available but uses the project version instead, and then someone who has the actual jthread globally installed |
| 07:37 |
hmmmmm |
well like i said |
| 07:37 |
hmmmmm |
the very simple way would be to futz with the FindJthread.cmake file |
| 07:37 |
kahrl |
if we are going to spend so much time on this issue, why don't we get rid of all the modification and make it possible to use the system jthread again? |
| 07:37 |
hmmmmm |
because jthread is just shit |
| 07:37 |
celeron55 |
because the system jthread is so featureless |
| 07:38 |
hmmmmm |
everything i added to jthread is completely necessary |
| 07:38 |
kahrl |
the modifications can be moved to porting.h |
| 07:38 |
hmmmmm |
the IsSameThread? |
| 07:38 |
celeron55 |
no they can't because they are private stuff in the classes |
| 07:38 |
hmmmmm |
the semaphore stuff? |
| 07:38 |
kahrl |
oh, IsSameThread isn't even needed, see threadid_t in threads.h |
| 07:39 |
hmmmmm |
erm |
| 07:39 |
hmmmmm |
i don't recall all the exact details about this, but i did it this way for a specific reason |
| 07:39 |
hmmmmm |
it's almost 4 am so i'd rather not get into it right now |
| 07:48 |
Akien |
celeron55, hmmmmm: I'm there now :) |
| 07:48 |
Akien |
Just read the backlog |
| 07:49 |
|
RealBadAngel joined #minetest-dev |
| 07:49 |
celeron55 |
do you have the non-building setup at hand now? |
| 07:50 |
Akien |
Yep |
| 07:50 |
celeron55 |
so, i want to know a few things before continuing |
| 07:50 |
celeron55 |
do you have a global jthread installed? |
| 07:51 |
Akien |
I do, |
| 07:51 |
Akien |
And it's dev headers |
| 07:51 |
celeron55 |
have you modified minetest's cmake/Modules/FindJthread.cmake? |
| 07:52 |
celeron55 |
or any of the other build scripts |
| 07:52 |
Akien |
Currently I'm trying to build a clean release of minetest 0.4.7 and minetest-game 0.4.7 |
| 07:53 |
Akien |
I removed our patches for 0.4.3 to have it use the system jthread |
| 07:53 |
Akien |
If I try to build simply with cmake && make -j2, it works ok. |
| 07:53 |
Akien |
My problem happens when using the shared library instead of the static one. |
| 07:53 |
celeron55 |
and the errors you pasted yesterday are what you get now? |
| 07:54 |
celeron55 |
oh, what works? |
| 07:54 |
Akien |
I mean, if I build a local copy for me with a simple cmake it works. But to package for Mageia, I have to follow some specific policies, such as IINM using shared libraries instead of static ones. |
| 07:55 |
Akien |
So I try to configure with "-DBUILD_SHARED_LIBS:BOOL=ON" in the cmake instruction (among others, flags and so on) |
| 07:56 |
Akien |
Then the errors occur |
| 07:56 |
celeron55 |
okay, and that will attempt to build our fork of jthread as a shared library; the problem you ran before you left yesterday was the fact that our jthread's build system is broken in the first place for a shared build |
| 07:56 |
celeron55 |
if those errors are fixed, you are going to stumble upon the problem that it's a different library with the same name as what you already have in the system |
| 07:57 |
Akien |
Well I guess if it's bundled in the minetest data directory, it should not interfere with the system jthread, would it? |
| 07:57 |
celeron55 |
our request for everyone has been that simply don't try to build it as a shared library, it's not useful as such |
| 07:58 |
celeron55 |
if you build it as a shared library, of course it will (cmake will install it in a global location) |
| 07:59 |
celeron55 |
so yeah, kahrl: what do you think? |
| 07:59 |
kahrl |
uhh, I'm not even sure anymore |
| 07:59 |
kahrl |
I don't see the private things you were talking about |
| 08:00 |
Akien |
I'll check the policy with some advanced Mageia packagers, it might be that including it as a static library is the way to do it. |
| 08:00 |
|
Calinou joined #minetest-dev |
| 08:01 |
celeron55 |
Akien: well, we now know the exact issue and we'll try to get it addressed sometime; as for now, you know what to do |
| 08:02 |
celeron55 |
kahrl: modifying jthread was a bad idea right from the start... but i'm not going to start reworking it |
| 08:03 |
celeron55 |
if you're right about there being nothing to stop it, it's probably quite a little work |
| 08:03 |
kahrl |
I'm doing it right now |
| 08:03 |
kahrl |
it's not that bad actually |
| 08:07 |
celeron55 |
i wonder why there isn't an issue with lua... oh heh, we have conveniently forced a static build in it's cmake configuration |
| 08:08 |
celeron55 |
distro zealots can't cause it to break with their silly flags |
| 08:08 |
celeron55 |
:-D |
| 08:09 |
celeron55 |
we could add a single keyword in jthread's scripts and nobody would ever complain again |
| 08:11 |
celeron55 |
all this jthread stuff could really just be considered to be a bug in minetest's build system |
| 08:50 |
|
darkrose joined #minetest-dev |
| 08:54 |
|
nalkri joined #minetest-dev |
| 09:00 |
|
jin_xi joined #minetest-dev |
| 09:13 |
sfan5 |
Can someone verify that this builds correctly? https://github.com/sfan5/minetest/tree/security |
| 09:22 |
Akien |
I patched (locally) minetest-0.4.7 as follows to fix the locale path on UNIX: |
| 09:22 |
Akien |
- set(LOCALEDIR "${CMAKE_INSTALL_PREFIX}/share/${PROJECT_NAME}/locale") |
| 09:22 |
Akien |
+ set(LOCALEDIR "${CMAKE_INSTALL_PREFIX}/share/locale") |
| 09:23 |
Akien |
I don't know if it's Mageia specific or if most modern distros use the same policy, but all locales go in /usr/share/locale/<language_code>/<name>.mo |
| 09:24 |
Akien |
(I forgot to say it was in minetest-0.4.7/CMakeLists.txt |
| 09:24 |
|
proller joined #minetest-dev |
| 09:47 |
|
celeron55 joined #minetest-dev |
| 09:52 |
Akien |
Building with static libraries, minetest works great. |
| 09:53 |
Akien |
You all did awesome work, I'm impressed :) |
| 09:53 |
Akien |
With all visual effects disabled (my laptop is reaaaaally old), minetest runs really smoothly compared to minecraft. |
| 10:04 |
kahrl |
so I reverted all custom changes to jthread |
| 10:04 |
kahrl |
https://github.com/kahrl/minetest/commit/681d6df31b672a92cd3e1618668279ad93a6cddc |
| 10:05 |
kahrl |
replaced the IsSameThread based implementation of getCurrentMapgen with a TLS based solution |
| 10:05 |
celeron55 |
you should leave in "// CriticalSection is way faster than the alternative" |
| 10:05 |
celeron55 |
otherwise nobody understands why the #define is there (it's not in the jthread distribution either) |
| 10:05 |
kahrl |
I'll do that |
| 10:06 |
kahrl |
should I update jthread to 1.3.1? |
| 10:06 |
celeron55 |
or, actually |
| 10:06 |
celeron55 |
a better alternative would be to define JMUTEX_CRITICALSECTION in cmake |
| 10:06 |
kahrl |
I would put that comment in jthreadconfig.h then |
| 10:07 |
celeron55 |
umm |
| 10:07 |
kahrl |
another question is whether the revert of the _WIN32_WINNT change breaks the win32 build |
| 10:07 |
celeron55 |
can you make sure that both versions of jthread are supported? |
| 10:07 |
celeron55 |
because, like, we're likely to see both |
| 10:07 |
kahrl |
let me see |
| 10:08 |
kahrl |
the biggest change in 1.3.1 is that is uses a namespace jthread |
| 10:08 |
celeron55 |
yes; i haven't looked more than that |
| 10:09 |
kahrl |
"using namespace jthread;" should work with both, right? |
| 10:09 |
|
Jordach joined #minetest-dev |
| 10:09 |
celeron55 |
i'd guess so |
| 10:09 |
celeron55 |
Akien: what is the patch that you have used that makes minetest use system jthread? |
| 10:11 |
celeron55 |
because 0.4.3 should already do that by itself; you having a patch means that it's broken |
| 10:13 |
Akien |
celeron55: http://svnweb.mageia.org/packages/cauldron/minetest/current/SOURCES/minetest-0.4.3-jthread.patch?view=markup |
| 10:14 |
celeron55 |
oh, so it's just about supporting jthread 1.3 |
| 10:14 |
Akien |
I did not create it though, yesterday was the first time I looked at minetest's source |
| 10:15 |
Akien |
Yes we use jthread 1.3.1 |
| 10:15 |
|
EdB joined #minetest-dev |
| 10:15 |
|
PilzAdam joined #minetest-dev |
| 10:16 |
|
kahrl_ joined #minetest-dev |
| 10:34 |
|
EdB joined #minetest-dev |
| 10:39 |
PilzAdam |
kahrl_, your jthread patch does not build with mingw: /home/adam/Minetest/win32/minetest/src/porting.cpp:174: error: ‘OpenThread’ was not declared in this scope |
| 10:40 |
|
nalkri joined #minetest-dev |
| 10:43 |
kahrl_ |
ah, glad you caught that |
| 10:43 |
kahrl_ |
must be because of the _WIN32_WINNT thing? |
| 10:43 |
PilzAdam |
I think so |
| 10:43 |
celeron55 |
just throw that in porting.h i think |
| 10:44 |
celeron55 |
...or maybe threads.h? 8) |
| 10:44 |
kahrl_ |
I've already changed it so the only jthread includes are in threads.h and util/thread.h |
| 10:44 |
kahrl_ |
so yeah I'll do it in threads.h |
| 10:45 |
kahrl_ |
pushed https://github.com/kahrl/minetest/commit/779272c6f4d2db21d7e25aea16352fb701c810b4 |
| 10:47 |
kahrl_ |
bbiab |
| 10:51 |
PilzAdam |
that builds correctly |
| 11:03 |
|
iqualfragile joined #minetest-dev |
| 11:34 |
|
Calinou joined #minetest-dev |
| 11:53 |
|
Taoki[mobile] joined #minetest-dev |
| 12:00 |
kahrl_ |
other than the namespace change I don't see anything in jthread 1.3.1 that we would have to do something about |
| 12:01 |
kahrl_ |
(except that JMUTEX_CRITICALSECTION is now called JTHREAD_CONFIG_JMUTEXCRITICALSECTION) |
| 12:01 |
celeron55 |
i still wonder why jthread doesn't default to using that |
| 12:02 |
celeron55 |
oh now i remember |
| 12:02 |
celeron55 |
or, well... the functional difference in addition to some process/thread stuff (which doesn't generally matter) is that JMUTEX_CRITICALSECTION is a recursive mutex |
| 12:03 |
celeron55 |
compared to the alternative, it's faster by an order of magnitude though |
| 12:03 |
celeron55 |
(while still slower than pthread) |
| 12:24 |
sfan5 |
celeron55: any comments? http://pastie.org/pastes/8196563/text |
| 12:25 |
sfan5 |
wait.. |
| 12:25 |
sfan5 |
forgot the "[Man-in-the-Middle is also no possible]" thing |
| 12:25 |
sfan5 |
*forget |
| 12:26 |
PilzAdam |
how is man-in-the-middle not possible here? |
| 12:27 |
sfan5 |
..I already revoked my statement of it not being possible |
| 12:36 |
proller |
celeron55, like this ? https://github.com/proller/minetest/compare/ver |
| 12:36 |
* sfan5 |
thinks celer*n55 is away |
| 12:47 |
kahrl_ |
updated jthread to 1.3.1: https://github.com/kahrl/minetest/commit/c1e64cf3f91c5e226eca8c1b82771ad0778a2a30 |
| 12:47 |
kahrl_ |
all the headers and sources are straight from jthread-1.3.1.tar.gz |
| 12:47 |
kahrl_ |
CMakeLists.txt is modified a little |
| 12:55 |
PilzAdam |
kahrl_, tested with gcc and mingw |
| 12:58 |
kahrl_ |
I tried it with jthread 1.3.1 installed by gentoo's portage, compiles and works |
| 12:58 |
kahrl_ |
(once I pass -D JTHREAD_INCLUDE_DIR=/usr/include/jthread to cmake) |
| 13:00 |
kahrl_ |
PilzAdam: does it set JTHREAD_WIN32_CRITICALSECTION=ON in jthreadconfig.h? |
| 13:02 |
kahrl_ |
err, I mean "#define JTHREAD_CONFIG_JMUTEXCRITICALSECTION" |
| 13:02 |
PilzAdam |
JTHREAD_WIN32_CRITICALSECTION:BOOL=ON |
| 13:03 |
PilzAdam |
yea, it sets it |
| 13:03 |
kahrl_ |
ok good |
| 13:13 |
|
BlockMen joined #minetest-dev |
| 13:17 |
|
Taoki[mobile] joined #minetest-dev |
| 13:19 |
|
Akien joined #minetest-dev |
| 13:37 |
kahrl_ |
should I add search paths to FindJthread.cmake, so that it automatically finds the system jthread on gentoo (and other distros that don't put jthread.h into /usr/include)? |
| 13:37 |
kahrl_ |
like https://gist.github.com/kahrl/6131384 |
| 13:38 |
Akien |
kahrl_: /usr/include/jthread/ should work on Mageia (and at least on Fedora I think) |
| 13:39 |
Akien |
In most modern distros actually |
| 13:39 |
Akien |
s/In/On/ |
| 13:40 |
kahrl_ |
well, the build system of jthread puts it into <prefix>/include/jthread by default |
| 14:07 |
|
iqualfragile joined #minetest-dev |
| 14:29 |
|
NakedFury joined #minetest-dev |
| 14:37 |
proller |
melting-freezing cause new ice have lower light than before |
| 14:46 |
|
AllegedlyDead joined #minetest-dev |
| 14:48 |
BlockMen |
warum ist in nodedef.cpp#L218 drowning = true ? |
| 14:48 |
BlockMen |
ups..wrong window^^ |
| 14:53 |
sfan5 |
BlockMen: <german> damit man ohne noclip in blöcken "ertrinkt" (soweit ich weiß)</german> |
| 14:55 |
RealBadAngel |
about drowning, we shall allow this attribute for airlike nodes too |
| 14:56 |
RealBadAngel |
not only liquids |
| 14:56 |
RealBadAngel |
this will allow to create outer space |
| 14:57 |
sfan5 |
you mean outer 0x20 |
| 14:58 |
RealBadAngel |
i mean worlds without air |
| 14:58 |
RealBadAngel |
thus no breathable atmosphere |
| 14:59 |
RealBadAngel |
look at paramat's worlds |
| 15:01 |
RealBadAngel |
this with my latest patch could allow space suits |
| 15:08 |
BlockMen |
RealBadAngel, working on that (too) :P |
| 15:10 |
proller |
RealBadAngel, and underwater suits ? |
| 15:11 |
proller |
and now possible to make cold-hot damage and wear ? |
| 15:13 |
RealBadAngel |
underwater are already possible |
| 15:13 |
RealBadAngel |
i will add one to technic |
| 15:14 |
RealBadAngel |
i made one for testing the patch out of flashlight code |
| 15:15 |
RealBadAngel |
i just put there check if breath is less than 5 and set it to 10 again |
| 15:15 |
RealBadAngel |
so, piece of cake |
| 15:16 |
RealBadAngel |
one thing that should be changed is just if check. it looks now for liquid and drowning attribute |
| 15:17 |
RealBadAngel |
it shall be changed to check only for drowning |
| 15:17 |
RealBadAngel |
and then let other than liquids nodes carry that attribute |
| 15:18 |
RealBadAngel |
also at the very same place suffocation shall be added |
| 15:19 |
RealBadAngel |
we do already check node |
| 15:20 |
RealBadAngel |
so if solid, suffocate, if liquid or airlike without breathable attribute -> drowning |
| 15:26 |
BlockMen |
RealBadAngel, plz wait before patching, im changing drowning atm (that you can modify damage of drowning) |
| 15:27 |
RealBadAngel |
that was just the ideas |
| 15:27 |
RealBadAngel |
im too busy with shaders atm to work on anything else |
| 15:27 |
RealBadAngel |
i plan to finish the current stage of shaders changes this weekend |
| 15:28 |
RealBadAngel |
then i will go for technic coding for a week |
| 15:28 |
BlockMen |
ok. im nearly done with that, is it ok when i do that with the supported node types too then? |
| 15:29 |
RealBadAngel |
imho you shall drop function in_liquid or something like this |
| 15:30 |
RealBadAngel |
and just check for drowning attribute |
| 15:30 |
RealBadAngel |
this alone will allow to create void or atmospheres |
| 15:30 |
RealBadAngel |
or even poisonous gases on swamps |
| 15:31 |
RealBadAngel |
for example |
| 15:32 |
jin_xi |
miasma |
| 15:33 |
RealBadAngel |
wut? |
| 15:33 |
|
rubenwardy joined #minetest-dev |
| 15:34 |
BlockMen |
RBA, atm all nodes have drowning attribute, so that needs to be changed then too |
| 15:37 |
RealBadAngel |
its good then |
| 15:37 |
RealBadAngel |
just the check has to be changed |
| 15:37 |
RealBadAngel |
i mean check if it is a luquid |
| 15:37 |
RealBadAngel |
*liquid |
| 15:40 |
|
Calinou joined #minetest-dev |
| 15:40 |
RealBadAngel |
https://github.com/minetest/minetest/blob/master/src/environment.cpp#L2245 |
| 15:50 |
|
Calinou joined #minetest-dev |
| 16:07 |
|
Matrixiumn joined #minetest-dev |
| 16:08 |
|
Matrixiumn joined #minetest-dev |
| 16:15 |
|
proller joined #minetest-dev |
| 16:16 |
RealBadAngel |
ok, folks i think i can spread the news by now |
| 16:17 |
RealBadAngel |
i just got a confirmation |
| 16:17 |
RealBadAngel |
next month on biggest polish PC gaming magazine CD Action, there will be review of our game |
| 16:18 |
RealBadAngel |
we need to prepare stable releases for cover CD for the magazine |
| 16:18 |
Jordach |
we need 0.4.8 NOW. |
| 16:18 |
RealBadAngel |
because game is gonna be shipped with the magazine |
| 16:19 |
RealBadAngel |
we need all the possible and rock solid builds for this |
| 16:20 |
RealBadAngel |
that means 30k of copies and possible new users |
| 16:20 |
proller |
ups |
| 16:21 |
|
hmmmm joined #minetest-dev |
| 16:21 |
proller |
push to topic |
| 16:21 |
proller |
with dates |
| 16:22 |
Jordach |
RealBadAngel, we will need a windows installer |
| 16:22 |
sfan5 |
RealBadAngel: we have a polish translation, right? |
| 16:22 |
sfan5 |
Jordach: we have one |
| 16:22 |
RealBadAngel |
yup i made one |
| 16:23 |
RealBadAngel |
but the installer would be nice |
| 16:23 |
RealBadAngel |
lets make it kiss as much as possible |
| 16:23 |
sfan5 |
SFX? |
| 16:24 |
RealBadAngel |
dunno, im not familiar with installers |
| 16:24 |
* sfan5 |
can make SFX packages |
| 16:24 |
RealBadAngel |
so you have been chosen as a volunteer ;) |
| 16:25 |
sfan5 |
but I'm not the guy who's familiar with GUI programming on Windows |
| 16:25 |
sfan5 |
bah, I need a static zlib for windows |
| 16:25 |
RealBadAngel |
we do have circa 2 weeks to the deadline |
| 16:25 |
Jordach |
sfan5, NULLSOFT installer |
| 16:26 |
sfan5 |
Jordach: not simple enough |
| 16:26 |
Jordach |
or use ruben's script |
| 16:26 |
RealBadAngel |
we have to send proper and checked code before 14th this month |
| 16:26 |
Jordach |
we have 13 days |
| 16:26 |
RealBadAngel |
then all the content goes to make cover dvd's |
| 16:27 |
|
hmmmm joined #minetest-dev |
| 16:27 |
RealBadAngel |
we cannot cross this line |
| 16:27 |
Jordach |
this looks like a good time to merge Sam II |
| 16:27 |
RealBadAngel |
if we do, we will be delayed by month |
| 16:27 |
RealBadAngel |
Jordach, technic_game waits for it |
| 16:28 |
Jordach |
starting git |
| 16:28 |
proller |
and two pulls for mobs |
| 16:28 |
proller |
AND MY VERSION COMPAT BUGFIX |
| 16:28 |
proller |
after celeron55 agreed |
| 16:29 |
RealBadAngel |
hmmmm, have you read the news? |
| 16:30 |
Jordach |
RealBadAngel, i dont have push to technic_game |
| 16:30 |
RealBadAngel |
ooops, lemme fix that :) |
| 16:30 |
Jordach |
wait |
| 16:30 |
Jordach |
i do |
| 16:33 |
celeron55 |
it's a semi feature-freeze then |
| 16:35 |
hmmmm |
oh no oh no |
| 16:35 |
hmmmm |
karhl don't use TLS! |
| 16:35 |
celeron55 |
RealBadAngel: what kind of stuff have you even told to them? |
| 16:35 |
celeron55 |
i hope it's more about community and open source than shaders and bumpmapping |
| 16:35 |
hmmmm |
karhl, that's C++11 |
| 16:36 |
Jordach |
celeron55, i have a texture fix waiting for merge (minetest_game #184) |
| 16:36 |
RealBadAngel |
i told them about free game |
| 16:36 |
celeron55 |
Jordach: find someone else to deal with that |
| 16:36 |
RealBadAngel |
mc like |
| 16:37 |
Jordach |
celeron55, like PilzAdam will ever do that |
| 16:37 |
RealBadAngel |
guy have tested it on his own and liked the project |
| 16:37 |
celeron55 |
Jordach: i have more important things on my list now |
| 16:37 |
celeron55 |
like unbreaking proller's code |
| 16:37 |
RealBadAngel |
so he heared my voice and agreed to make a rewiev |
| 16:39 |
celeron55 |
proller: it's still wrong |
| 16:39 |
celeron55 |
proller: MapBlock::deSerializeNetworkSpecific should work according to the protocol version, not map version |
| 16:39 |
RealBadAngel |
celeron55, shaders etc are just my playground, same as v7 for hmm or game for PA |
| 16:39 |
RealBadAngel |
i dont differ the whole project by our playgrounds at all |
| 16:40 |
RealBadAngel |
it is our hobby and we all do our best for it |
| 16:40 |
RealBadAngel |
thats it |
| 16:42 |
RealBadAngel |
my gf sittin next to me is playin mt at the moment |
| 16:42 |
RealBadAngel |
and shes screamin when i get the shaders patch done |
| 16:43 |
RealBadAngel |
my friends in Berlin also demands updated game |
| 16:44 |
RealBadAngel |
i think im doing good for the community |
| 16:48 |
sfan5 |
celeron55: you have a comment about my kinda proposal for protocol encryption? |
| 16:50 |
celeron55 |
sfan5: what's the point of it? |
| 16:50 |
sfan5 |
the point of encryption? |
| 16:51 |
hmmmm |
nevermind about that last concern of mine, i didn't read the patch completely |
| 16:51 |
celeron55 |
the actual question still is more like "whether to do it or not" than "how to do it" |
| 16:51 |
celeron55 |
i don't care about implementation until i know what it's for and who needs it |
| 16:52 |
RealBadAngel |
celeron55, i shall read your comments as cons to the idea of magazine rewievin our project? |
| 16:52 |
hmmmm |
from what i understand, sfan5 is afraid of somebody MITMing his traffic and converting messages to saying "heil hitler", iirc it's highly illegal to praise anything related to the nazi party in germany |
| 16:52 |
celeron55 |
RealBadAngel: i have said no cons or pros about it |
| 16:52 |
RealBadAngel |
so decide please |
| 16:53 |
hmmmm |
although it's totally possible somebody else could do that with HTTP or something |
| 16:53 |
sfan5 |
hmmmm: thats not my personal concern but could be other peoples concern |
| 16:53 |
celeron55 |
RealBadAngel: well, i already said the main concern i had |
| 16:53 |
RealBadAngel |
your name is going to be printed in 30k copies |
| 16:53 |
sfan5 |
anyway, I was more asking whether anyone sees any big mistake in that proposal |
| 16:53 |
hmmmm |
that shouldn't be a concern at all, first off the internet is fairly anonymous and your privacy's not going to get F'd over something as trivial as that |
| 16:54 |
hmmmm |
second, if that were actually to get you in trouble and go to a trial they'd merely need to check some hops closer to your own and see you're innocent |
| 16:54 |
RealBadAngel |
celeron55, u have said if i will be making a review |
| 16:54 |
RealBadAngel |
thats wrong |
| 16:54 |
hmmmm |
third, this is a ridiculous, contrieved scenario which will never and has never happened in real life |
| 16:55 |
RealBadAngel |
guy from the magazine will judge us |
| 16:55 |
hmmmm |
I vote against encryption |
| 16:55 |
hmmmm |
it's just.... really not necessary |
| 16:55 |
RealBadAngel |
so pointing shaders stuff was meaningless |
| 16:56 |
sfan5 |
hmmmm: it could be optional |
| 16:56 |
celeron55 |
RealBadAngel: well, articles about stuff generally have some "point" in them; i just wonder what that point will be about minetest |
| 16:56 |
hmmmm |
yes, but nevermind the fact you're adding all this extra stuff in that nobody's using but yourself |
| 16:56 |
RealBadAngel |
he will judge You, me, hmm and everybody else for the job done |
| 16:56 |
Calinou |
there is encryption in xonotic: noone uses it |
| 16:56 |
celeron55 |
i vote for encryption to be considered when the protocol is redesigned more thoroughly |
| 16:57 |
celeron55 |
which will happen... ehm... well, nobody knows, but probably some year |
| 16:57 |
hmmmm |
i bet xontonic also uses SRP for logon because of some paranoid security fear |
| 16:57 |
RealBadAngel |
celeron55, i have no idea what will be the point, but one thing im sure it will be good for us |
| 16:57 |
hmmmm |
as for the magazine thing, i personally don't like publicity so i'd rather stay out of it |
| 16:58 |
Calinou |
publicity is always a good thing |
| 16:58 |
RealBadAngel |
:) |
| 16:58 |
hmmmm |
i really wonder if minetest needs more contributors or not too, i mean too many cooks :/ |
| 16:58 |
Calinou |
we don't have enough already |
| 16:58 |
BlockMen |
celeron55, what you think about my pull on template? |
| 16:58 |
RealBadAngel |
it means bigger community |
| 16:58 |
RealBadAngel |
and thats good |
| 17:00 |
hmmmm |
as for the threading thing, i'm not sure why karhl chose that route; jthread never did anything, so forking it off imo would be the smarter thing to do |
| 17:00 |
hmmmm |
merely for organizational purposes |
| 17:01 |
hmmmm |
i personally can't see any benefit at all to using a system jthread library |
| 17:01 |
hmmmm |
ever, in any case |
| 17:02 |
celeron55 |
well, none of this matters other than the fact that after what kahrl did, it works on everything directly again and it makes people happy |
| 17:02 |
hmmmm |
when i first modified it, it was my intent to force it to use the project version always and/or rename it, but I didn't want to screw around with the build system at that time and nobody seemed to have a problem |
| 17:03 |
PilzAdam |
so, we have a feature freeze now because of a random magazine bringing an article about Minetest? |
| 17:03 |
sfan5 |
kind of |
| 17:03 |
hmmmm |
i'd say we have a feature freeze because this nonsense has gone on long enough |
| 17:03 |
celeron55 |
PilzAdam: that needs to be considered now, i think |
| 17:03 |
hmmmm |
0.4.8 should've been out two months ago |
| 17:03 |
celeron55 |
do we want to put out a version? |
| 17:03 |
hmmmm |
but |
| 17:04 |
hmmmm |
we're not releasing anything until the weather bullshit gets fixed 100% |
| 17:04 |
|
sapier1 joined #minetest-dev |
| 17:04 |
PilzAdam |
I think weather should be reverted for 0.4.8 |
| 17:04 |
hmmmm |
yeah, probably. |
| 17:04 |
celeron55 |
the compatibility issue is going to get fixed tomorrow as proller comes along again fixes the last thing that i noticed |
| 17:04 |
hmmmm |
if you want 0.4.8 out quick |
| 17:04 |
celeron55 |
+and |
| 17:04 |
hmmmm |
well tomorrow is good |
| 17:05 |
hmmmm |
having a different version for the network is nonsensical though, i hope by fix you mean move everything to 26 |
| 17:05 |
PilzAdam |
a feature freeze now would mean that RealBadAngel's shader code has to wait |
| 17:05 |
hmmmm |
grrrr |
| 17:06 |
celeron55 |
hmmmm: i can assure you the fix is sane in all imaginable ways; don't worry about it |
| 17:06 |
RealBadAngel |
i wanted to push it this weekend |
| 17:06 |
RealBadAngel |
but it can wait |
| 17:06 |
RealBadAngel |
no problemo |
| 17:07 |
celeron55 |
hmmmm: i could explain it completely but i'll rather not, the logic behind versioning is kind of hard and long to explain in a thorough way |
| 17:08 |
hmmmm |
to the people who complain about long waits between versions: I don't believe our release cycle is really that bad, considering the amount of stuff that was changed or added is really a spit in the bucket and nothing in comparison to some other FOSS projects |
| 17:09 |
celeron55 |
one thing i've been left wondering now is the question: is game design by committee better than game design by random? |
| 17:10 |
celeron55 |
we kind of have those options 8) |
| 17:10 |
hmmmm |
you say "by committee" as if this is what's happening |
| 17:11 |
celeron55 |
what's happening is somewhere in between of those |
| 17:11 |
|
Miner_48er joined #minetest-dev |
| 17:11 |
PilzAdam |
currently nothing is happening |
| 17:11 |
hmmmm |
"design by committee" is a lot worse than this. like ATM packet size |
| 17:11 |
PilzAdam |
we dont even have a game designer |
| 17:11 |
RealBadAngel |
in your opinion PA |
| 17:11 |
hmmmm |
the europeans wanted 32 bit packets for less latency because they wanted to use it for telephone calls |
| 17:11 |
hmmmm |
the 'murricans wanted 64 bit packets for higher throughput for data applications |
| 17:11 |
celeron55 |
PilzAdam: well, now i mean everything, including eg. jordach's new model |
| 17:12 |
celeron55 |
we need a way to choose those kinds of things |
| 17:12 |
hmmmm |
so the stupid committee decided "we should please both parties and make it 48 bytes" |
| 17:12 |
hmmmm |
err, i meant byte, not bit before |
| 17:12 |
RealBadAngel |
hehe |
| 17:12 |
sapier1 |
sfan5 is there any reason for you to put work in a outdated unsafe crypto library instead of finding a prooven maintained one first? |
| 17:12 |
kahrl_ |
hmmmm: I personally don't mind always using a modified in-project jthread (since it's so small), but the topic keeps coming up here repeatedly and the time talking about it could be used more productively |
| 17:12 |
kahrl_ |
so I fixed it once and for all |
| 17:12 |
celeron55 |
we have way more headroom in how much work could happen on the game content side; on the engine side we're kind of saturated |
| 17:13 |
hmmmm |
karhl, really to 'fix' it all you'd need to do is remove some lines from cmake/Modules/FindJthread.cmake |
| 17:13 |
hmmmm |
but that's hacky |
| 17:13 |
RealBadAngel |
content side shall be left for game creators |
| 17:13 |
kahrl_ |
well, distributors will keep asking how to "unbundle" it |
| 17:13 |
kahrl_ |
so it's not a full solution |
| 17:13 |
PilzAdam |
celeron55, I kinda stopped development of minetest_game because too many people complaining about it |
| 17:14 |
celeron55 |
kahrl_: what do you think of adding STATIC to jthread/CMakeLists.txt:16 like there is on lua/src/CMakeLists.txt:63? |
| 17:14 |
celeron55 |
that's the issue, really, if it's thought about as a build system bug |
| 17:14 |
sfan5 |
sapier1: outdated? unsafe? |
| 17:14 |
RealBadAngel |
they actually felt stopped by you and your vision of it PA |
| 17:14 |
sfan5 |
which other do you recommend? |
| 17:14 |
sfan5 |
+one |
| 17:14 |
celeron55 |
the lack of it allows package maintainers to break it with their flags that they use for making sure dynamic libraries get generated |
| 17:15 |
celeron55 |
and yes, also the removal of those like hmmmm said |
| 17:15 |
sapier1 |
last libtomcrypt major version is from 2007 last non minor bugfix is 2 years old with respect to development speed in cryptography and security libtomcrypt is useless by now |
| 17:15 |
RealBadAngel |
PilzAdam, but it actually turned good, we have more games now |
| 17:15 |
celeron55 |
we handle lua just well as a static version, we sure could do that for jthread |
| 17:15 |
kahrl_ |
sure, the in-project version can always be static |
| 17:15 |
PilzAdam |
RealBadAngel, thats indeed good |
| 17:15 |
PilzAdam |
I think we should pack more games with 0.4.8 |
| 17:16 |
sfan5 |
^ |
| 17:16 |
sapier1 |
I only know of two license compatible maintained crypto libraries ... openssl isn't wanted due to its api ... and I don't know if gnutls api is that much better |
| 17:16 |
celeron55 |
kahrl_: no, distributions don't ask about lua |
| 17:16 |
RealBadAngel |
technic is not ready for such voyage |
| 17:16 |
celeron55 |
kahrl_: because it _works_ without them even knowing about it |
| 17:16 |
celeron55 |
they don't go and dig up stuff |
| 17:16 |
celeron55 |
they just start looking when it doesn't work |
| 17:16 |
sfan5 |
sapier1: what about polarssl? |
| 17:16 |
RealBadAngel |
but soon it will be |
| 17:17 |
sfan5 |
RealBadAngel: define 'soon' |
| 17:17 |
RealBadAngel |
next week i have free |
| 17:17 |
sfan5 |
is that after the deadline? |
| 17:17 |
RealBadAngel |
weekend is planned to finish shaders |
| 17:17 |
sapier1 |
it's gpl ... not sure but seems to be at least more active then the one you selected |
| 17:17 |
celeron55 |
kahrl_, hmmmm: so my proposal is: let's make jthread handled exactly like lua is handled |
| 17:17 |
RealBadAngel |
next is technic fine tuning |
| 17:18 |
hmmmm |
sure |
| 17:18 |
sfan5 |
sapier1: celeron55 said libtomcrypt seemed to be most suited |
| 17:18 |
RealBadAngel |
we do have already working computer |
| 17:18 |
RealBadAngel |
wireless thingies |
| 17:18 |
celeron55 |
sfan5: i didn't know about the issues with it |
| 17:18 |
kahrl_ |
celeron55: I'm fine with that |
| 17:18 |
RealBadAngel |
another texture pack |
| 17:18 |
RealBadAngel |
and sounds/ambience |
| 17:18 |
sfan5 |
celeron55: what about polarssl? |
| 17:18 |
celeron55 |
sfan5: no idea |
| 17:19 |
RealBadAngel |
technic_game is already way different to minetest_game |
| 17:20 |
PilzAdam |
is anyone against a feature freeze for 0.4.8 now? |
| 17:20 |
sapier1 |
polarssl seams to be actively developed but no idea if it can be built for win and posix ... and they do sell a commercial license ... |
| 17:20 |
RealBadAngel |
not to mention lstystem trees included. AND moon flower :) |
| 17:20 |
kahrl_ |
sfan5: idea: make a mesecons competition "implement SSL in mesecons", then take the best entry |
| 17:21 |
sfan5 |
kahrl_: there will surely be many submissions |
| 17:21 |
sapier1 |
ok they use dual licensing with gpl2 so we should be fine for license issues |
| 17:21 |
sfan5 |
and it will work fast ;) |
| 17:21 |
RealBadAngel |
PilzAdam, i could be against, but i left it up to others if they want to get my patches sooner or later |
| 17:22 |
RealBadAngel |
so if majority decide to freeze i will too |
| 17:22 |
sapier1 |
I don't think anyone of us is capable of reviewing crypographic code ;-) correct me if I'm wrong |
| 17:23 |
RealBadAngel |
its too much encrypted for me ;) |
| 17:24 |
sapier1 |
but sfan5 I guess cryptography wont be added for 0.4.8 can we delay this discussion? at least if there's need to get 0.4.8 until 14th? |
| 17:24 |
sfan5 |
sapier1: k |
| 17:25 |
sapier1 |
I don't want to stop you from trying and find concepts that work of course I guess we need multiple tries to get a reasonable version |
| 17:26 |
hmmmm |
ahh of course, sapier wants cryptography in |
| 17:26 |
|
Calinou joined #minetest-dev |
| 17:26 |
kahrl_ |
sapier1: you can't use a gpl library from lgpl code |
| 17:26 |
RealBadAngel |
imho we shall merge some stuff during next week |
| 17:26 |
RealBadAngel |
and then from 8-14 make the freeze |
| 17:26 |
sapier1 |
ok so polarssl is out |
| 17:27 |
sapier1 |
gnutls is lgpl ... but I don't know if it can be built on win32 |
| 17:27 |
RealBadAngel |
so next sunday could be deadline |
| 17:27 |
RealBadAngel |
and freeze point |
| 17:28 |
kahrl_ |
sapier1: it is, they even provide official win32 builds |
| 17:28 |
PilzAdam |
RealBadAngel, I thought you wanted an ultra stable version |
| 17:28 |
RealBadAngel |
i do |
| 17:29 |
RealBadAngel |
mixed feelings ;) |
| 17:29 |
PilzAdam |
and then you think 6 days feature freeze is enough? |
| 17:29 |
RealBadAngel |
i will go with the flow |
| 17:29 |
sapier1 |
I don't have any Idea kahrl I just looked for recent license compatible crypt libraries ... and I deny it's me who started this discussion this time I only try to prevent adding a useless crypto lib ;-) |
| 17:29 |
Calinou |
6 days feature freeze is enough, minetest isn't that big |
| 17:29 |
Calinou |
you get to know immediatly when the game is broken :P |
| 17:30 |
sapier1 |
considering feature freeze what about 774,418 and 640 |
| 17:30 |
celeron55 |
so something called "gnu" is the best for us? lol, wouldn't have guessed |
| 17:30 |
RealBadAngel |
Calinou, i not such sure about it. technic game rebuilds meant lately 100k of lines |
| 17:30 |
kahrl_ |
Calinou: some obscure parts of the API are only used by a few mods, and they might not get tested immediately with new git commits |
| 17:30 |
RealBadAngel |
for a MOD |
| 17:30 |
sapier1 |
celeron gnutls is lgpl ;-) even with gnu in it's name ;-) |
| 17:31 |
celeron55 |
sapier1: i would have expected GPL, and long beards |
| 17:31 |
celeron55 |
the latter would be good though |
| 17:32 |
sapier1 |
me too but it isn't it's lglp2.1+ |
| 17:32 |
RealBadAngel |
Calinou, https://github.com/RealBadAngel/technic_game/contributors |
| 17:32 |
RealBadAngel |
take a look on the numbers |
| 17:32 |
sapier1 |
maybe because of openssl's open licensing scheme |
| 17:33 |
Calinou |
well, technic is really big, but aren't there a lot of testers? |
| 17:33 |
RealBadAngel |
when mods are starting to talk in kilos of lines of code, that means something |
| 17:34 |
sapier1 |
I don't have any idea how big mobf is but I don't have any testers ;-) |
| 17:34 |
RealBadAngel |
i have managed to attract some decent coders to technic game |
| 17:34 |
RealBadAngel |
and im proud of it |
| 17:34 |
sapier1 |
but guys I need 418 and 774 for next mobf version (or something similar) |
| 17:34 |
RealBadAngel |
theyre doing very good |
| 17:35 |
|
proller joined #minetest-dev |
| 17:36 |
RealBadAngel |
we do have such pearls as programmable computer |
| 17:36 |
RealBadAngel |
and lotsa other stuff |
| 17:37 |
sapier1 |
:-) interesting ... but I already programm computers I don't want to do it within mt |
| 17:37 |
RealBadAngel |
inception, buddy :) |
| 17:37 |
sapier1 |
418 automatic entity movment dir facing ... any comments on this? |
| 17:38 |
sapier1 |
I know it's most likely only usefull for mobs maybe for vessels too ... |
| 17:39 |
PilzAdam |
sapier1, add a comment to protocol version 21 in clienserver.h |
| 17:41 |
kahrl_ |
sapier1, shouldn't this check for hypot(m_velocity.Z,m_velocity.Z) > tolerance before changing m_yaw? |
| 17:41 |
kahrl_ |
X* |
| 17:42 |
sapier1 |
what would be a usefull tolerance? |
| 17:42 |
kahrl_ |
dunno |
| 17:42 |
RealBadAngel |
PilzAdam, do you think that including technic_game for sake of magazine release would be good? |
| 17:43 |
PilzAdam |
I dont know technic_game |
| 17:43 |
RealBadAngel |
ofc you do |
| 17:43 |
sapier1 |
but there's something else .. i guess it should be normalized |
| 17:43 |
RealBadAngel |
its bloated ;) |
| 17:43 |
kahrl_ |
normalized? |
| 17:43 |
sapier1 |
no no forget about it it's done by atan2 |
| 17:43 |
RealBadAngel |
32x texture pack, music, sounds, mesecons, trees, machines and all this stuff |
| 17:44 |
sapier1 |
I thought about m_yaw beeing 20 rotations for example |
| 17:44 |
RealBadAngel |
and sam II |
| 17:45 |
RealBadAngel |
also a computer programmable in forth, force fields, wrench, stained framed glass, concrete posts... |
| 17:46 |
RealBadAngel |
ask what technic dont have rather ;) |
| 17:46 |
sapier1 |
ok added comment to 418 |
| 17:47 |
RealBadAngel |
also CNC milling machine is there, circular saw |
| 17:47 |
sapier1 |
now the more interesting one 774 |
| 17:47 |
sapier1 |
I'm not sure if those protocol version changes are right |
| 17:47 |
RealBadAngel |
ah, and tetris game :) |
| 17:48 |
|
neko259 joined #minetest-dev |
| 17:48 |
sapier1 |
basicaly this adds a base speed definition for animations ... telling client what horizontal speed matches the animation at specified framerate |
| 17:48 |
sapier1 |
thus client can adjust the animation playback framerate as entities movement accelerates |
| 17:49 |
celeron55 |
sapier1: that was already discusses, you have to remove the raised version minimums and test that it doesn't crash with cross-version usage |
| 17:49 |
celeron55 |
discussed* |
| 17:49 |
sapier1 |
I can't test 20 version combinations celeron |
| 17:50 |
celeron55 |
just always keep the latest stable around and you're fine |
| 17:50 |
sapier1 |
I'll test against 0.4.7 but I wont test back to 0.4.0 |
| 17:50 |
celeron55 |
no need to |
| 17:50 |
celeron55 |
we don't care about that long network compatibility |
| 17:51 |
celeron55 |
(is that written down anywhere?) |
| 17:52 |
|
BlockMen joined #minetest-dev |
| 17:52 |
kahrl_ |
it's quite nice to be able to connect down to protocol version 13 |
| 17:53 |
sapier1 |
currently it's min version 13 we're at 21 ... so it's roughly 0.4.0 ... I'd need to test for days to be really sure everything beeing allowed works |
| 17:53 |
|
nore joined #minetest-dev |
| 17:53 |
sapier1 |
kahrl yes it's nice but I'm almost sure it hasn't been tested for quite a view versions |
| 17:54 |
nore |
I am thinking about texture packs |
| 17:54 |
nore |
I could add them with only a few lines of code |
| 17:54 |
kahrl_ |
sapier1: there are a few things that don't work, obviously |
| 17:54 |
nore |
would it be a good idea? |
| 17:54 |
sapier1 |
we already have texture packs nore |
| 17:55 |
kahrl_ |
for example some valid node showing up as unknown when you connect to an old server with a new client |
| 17:55 |
nore |
no, but textures packs that stay in a folder, with a menu option to say what texture pack to choose |
| 17:56 |
nore |
that we don't have |
| 17:57 |
sapier1 |
in a folder? |
| 17:57 |
celeron55 |
https://gist.github.com/celeron55/6133668 |
| 17:57 |
celeron55 |
that's a patch that makes jthread behave like lua behaves if luajit isn't available |
| 17:57 |
proller |
celeron55, like this ? https://github.com/proller/minetest/compare/ver ! |
| 17:57 |
sapier1 |
nore if you put a texture pack within a folder to textures it's in a single folder |
| 17:58 |
nore |
sapier1: you put a folder with the TP inside the textures folder, the name of the folder being the name of the TP |
| 17:58 |
nore |
and then you can choose in the main menu what folder is to be choosed for images |
| 17:59 |
proller |
celeron55, i can push it in 2 commits, for nodebox and disk |
| 17:59 |
sapier1 |
ok so you want a texture pack selection option in settings? |
| 17:59 |
celeron55 |
proller: i don't see any change |
| 17:59 |
nore |
sapier1: yes |
| 18:00 |
sapier1 |
good idea I suggest using a dropdown |
| 18:00 |
celeron55 |
proller: what did you change since last time? |
| 18:00 |
nore |
just need to change tile.cpp |
| 18:00 |
sapier1 |
why? |
| 18:00 |
sapier1 |
texture pack is set in settings? |
| 18:01 |
proller |
celeron55, since _READ and SerializeNetworkSpecific -- nothing |
| 18:01 |
kahrl_ |
celeron55: ah, I thought you meant just compiling a static jthread if the system jthread isn't found |
| 18:01 |
kahrl_ |
why remove the option to use a system jthread? |
| 18:02 |
sapier1 |
because we need more features than system jthreads provides? |
| 18:02 |
celeron55 |
like hmmmm said, because jthread is such a small wrapper and nobody benefits at all from a system version |
| 18:02 |
proller |
celeron55, oh, find your reply |
| 18:02 |
RealBadAngel |
quick thought: easy texture pack selection shall be made before we go magazine |
| 18:02 |
kahrl_ |
sapier1: we don't really, I just fixed that |
| 18:02 |
celeron55 |
and by doing our changes to jthread itself, we can have code in more logical places |
| 18:02 |
celeron55 |
that's hmmmm's view on this issue |
| 18:03 |
celeron55 |
i'm quite neutral other than that i want this fixed in way or another |
| 18:03 |
kahrl_ |
celeron55: system jthread removes a few seconds of compile time after I do a make clean |
| 18:03 |
kahrl_ |
small benefit ;) |
| 18:03 |
RealBadAngel |
and magazine pack imho shall consist of a few chosen texture packs |
| 18:04 |
celeron55 |
kahrl_: you'll have to fight this with hmmmm unless someone comes up with compelling arguments :P |
| 18:05 |
celeron55 |
kahrl_: is there any possible chance that we need to modify jthread's internals that can't be accessed from outside? |
| 18:05 |
celeron55 |
same to hmmmm of course |
| 18:05 |
celeron55 |
the answer to that could allow a decision to be made |
| 18:06 |
Jordach |
RealBadAngel, Vanessa's HDX, Misa's(?), PixelBox |
| 18:06 |
RealBadAngel |
and Sphax's one |
| 18:06 |
Jordach |
no |
| 18:06 |
kahrl_ |
celeron55: I don't claim to know the future so... no comment from me |
| 18:06 |
RealBadAngel |
why? |
| 18:06 |
celeron55 |
i'm kind of siding hmmmm on this, because always having our own causes less effort for us, because every platform other than windows provides well-working pthreads |
| 18:06 |
Jordach |
there is no re-dist allowed |
| 18:06 |
RealBadAngel |
ah ok |
| 18:07 |
RealBadAngel |
can mine go in? |
| 18:07 |
celeron55 |
a conditional build system easily overweights jthread itself :P |
| 18:07 |
celeron55 |
-t |
| 18:07 |
VanessaE |
don't forget Minetoon and Sphax |
| 18:07 |
celeron55 |
but otoh doing it your way is more what i would have originally done |
| 18:07 |
RealBadAngel |
sphax is excluded, at least if ashenk ask owner |
| 18:08 |
RealBadAngel |
i would like to see it onboard |
| 18:08 |
celeron55 |
this is a stupid issue really |
| 18:08 |
celeron55 |
we could as well flip a coin |
| 18:08 |
celeron55 |
it just doesn't matter |
| 18:08 |
kahrl_ |
right :) |
| 18:08 |
RealBadAngel |
its most complete and fine texture pack out there |
| 18:08 |
sapier1 |
ok I updated 774 tested client046 -> server 04(8) as well as server 046 ->client04(8) |
| 18:09 |
sapier1 |
I didn't have a 0.4.7 available but I guess 0.4.6 will do too |
| 18:09 |
RealBadAngel |
VanessaE, ofc next to HDX ;) |
| 18:09 |
sapier1 |
btw 774 fixes animation blending too |
| 18:09 |
celeron55 |
hmmmm: if you merge my patch in yourself, you'll get it your way |
| 18:09 |
celeron55 |
hmmmm: we can't choose |
| 18:09 |
celeron55 |
8D |
| 18:09 |
RealBadAngel |
but as for me HDX is too... girly style :) |
| 18:10 |
VanessaE |
:P |
| 18:10 |
RealBadAngel |
hahaha |
| 18:10 |
RealBadAngel |
you know what i mean :) |
| 18:10 |
kahrl_ |
do any other devs have a preference about the jthread issue? |
| 18:10 |
RealBadAngel |
i dont |
| 18:11 |
RealBadAngel |
not my playground at all |
| 18:11 |
celeron55 |
they really have no reason to care at all |
| 18:11 |
sapier1 |
imho we should implement threads ourselfs or fork jthread and integrate it completely |
| 18:11 |
RealBadAngel |
we do care |
| 18:11 |
celeron55 |
sapier1: basically my patch integrates it completely, in all ways that actually matter |
| 18:11 |
RealBadAngel |
but we are highly expertized in our areas |
| 18:12 |
RealBadAngel |
so celeron55, please dont say we dont care |
| 18:12 |
sapier1 |
considering the work this separate lib causes integration may also safe time ;-) |
| 18:12 |
celeron55 |
kahrl_: aren't you afraid for even a tiny bit about build system bloat? 8) |
| 18:12 |
sapier1 |
save |
| 18:12 |
celeron55 |
because of 50 line libraries |
| 18:13 |
RealBadAngel |
if you were about to touch shaders now i could argue with you. |
| 18:13 |
kahrl_ |
eh, I don't see it often so I don't care about bloat there :) |
| 18:13 |
hmmmm |
huh |
| 18:13 |
celeron55 |
but when it breaks, it's horrible because nobody is familiar with it |
| 18:13 |
sapier1 |
integration also eases feature updates |
| 18:13 |
RealBadAngel |
life is life |
| 18:13 |
RealBadAngel |
things broke |
| 18:13 |
hmmmm |
anyway, we should remove the system JThread option if only for the purpose of removing dependencies |
| 18:14 |
hmmmm |
more dependencies = bad |
| 18:14 |
RealBadAngel |
we can all live with it |
| 18:14 |
kahrl_ |
if you add /usr[/local]/include/jthread to the search paths it should only break very rarely |
| 18:14 |
sapier1 |
that's what I meant with integrating |
| 18:14 |
kahrl_ |
hmmmm, but from another point of view, more object code duplication = bad |
| 18:15 |
kahrl_ |
that's the distro maintainer's view |
| 18:15 |
celeron55 |
but it's so little object code |
| 18:15 |
celeron55 |
it doesn't matter |
| 18:15 |
kahrl_ |
how about this: allow using the system version for now, and integrate it if we need to modify it again for some reason |
| 18:15 |
hmmmm |
karhl, sure, except in this case the distro maintainer might want to take a look at JThread in particular |
| 18:15 |
RealBadAngel |
PilzAdam, have you reconsidered option for each game having own tiltle music score? |
| 18:15 |
celeron55 |
kahrl_: no, nobody remembers that and it gets just messed up |
| 18:15 |
sapier1 |
I've seen comercial software with three different thread implementations within a single application ;-P |
| 18:15 |
hmmmm |
so my arguments: |
| 18:16 |
hmmmm |
1). it allows us to remove an external dependency |
| 18:16 |
hmmmm |
2). we have total flexibility over the jthread implementation |
| 18:16 |
VanessaE |
Jordach: sphax is cc-by-nc-nd, but you're allowed to distribute it. |
| 18:16 |
hmmmm |
3). it gives us an organizational advantage |
| 18:16 |
Jordach |
oh |
| 18:16 |
RealBadAngel |
VanessaE, so we can include it? |
| 18:16 |
hmmmm |
4). it reduces build complexity |
| 18:16 |
VanessaE |
RealBadAngel, Jordach: yes, I just now downloaded and looked at the license declaration. |
| 18:17 |
RealBadAngel |
friggin great :)) |
| 18:17 |
VanessaE |
(which contains the "human readable text, and a link to http://creativecommons.org/licenses/by-nc-nd/3.0/legalcode ) |
| 18:17 |
celeron55 |
there's a name for this issue though |
| 18:17 |
celeron55 |
it's the... hmm, i don't remember it |
| 18:17 |
sapier1 |
+1 for integration and name change |
| 18:17 |
RealBadAngel |
i will add normal and heightmaps for it just |
| 18:18 |
sapier1 |
what about mtthread ;-) |
| 18:18 |
celeron55 |
this can be compared to someone bringing the plans of a nuclear reactor to the front of you asking whether to build it, and someone building the plans of a bike shed in front of you asking whether to build it; guess which one you are going to argue about? 8) |
| 18:18 |
celeron55 |
bringing* |
| 18:19 |
Jordach |
i'm going to complain about the bike shed; i know nuclear physics |
| 18:19 |
RealBadAngel |
celeron55, have you actually tried to build reactor in mt? :) |
| 18:19 |
sapier1 |
I don't need another bike shed lets build the reactor |
| 18:19 |
* celeron55 |
looks at RBA racing besides the point in his trollface car |
| 18:19 |
RealBadAngel |
:) |
| 18:20 |
Jordach |
if the a-team can build a tank out of a taxi, we can build a reactor out of a bike shed |
| 18:20 |
celeron55 |
can we decide based on the fact that we want to be evil (obviously we want to), so this allows us to be evil against distro maintainers |
| 18:20 |
RealBadAngel |
i just mentioned it because you can build a reactor in mt already :) |
| 18:21 |
sapier1 |
no we're not evil we're not google |
| 18:21 |
celeron55 |
if there's nothing else to think in the rest of our lifes, we can always silently laugh at them as they didn't know they were shipping countless copies of bundled jthreads |
| 18:21 |
celeron55 |
8) |
| 18:22 |
RealBadAngel |
celeron55, it looks like youre light years behind of what modders have done to the engine already |
| 18:22 |
RealBadAngel |
jordach would call it "fun fact" |
| 18:22 |
RealBadAngel |
:P |
| 18:22 |
sapier1 |
celeron we can reimplement jthread too if it's so important to be good ;-) |
| 18:23 |
kahrl_ |
has nobody mentioned that we should really use boost and boost::thread? |
| 18:23 |
sapier1 |
*looking for something to throw at kahrl* |
| 18:23 |
PilzAdam |
RealBadAngel, I tend to say: do what the fuck you want to your "magazine version" but dont bother the rest of us with it |
| 18:23 |
celeron55 |
boost::videogame<Block, Player, Cow> |
| 18:24 |
* RealBadAngel |
hands sapier1 an empty bucket |
| 18:24 |
sapier1 |
empty???? a platic one am I right? |
| 18:24 |
* Jordach |
throws ingots at sapier1 |
| 18:24 |
Jordach |
there. |
| 18:24 |
kahrl_ |
tomato ingots? |
| 18:25 |
sapier1 |
I hope it's at least copper ;-P |
| 18:25 |
sapier1 |
but I'd prefere gold jordach |
| 18:25 |
RealBadAngel |
PilzAdam, so i can read that youre against this release? |
| 18:25 |
Jordach |
sapier1, i was throwing air ingots |
| 18:25 |
Jordach |
to make an air sword |
| 18:25 |
kahrl_ |
you hacker you! |
| 18:26 |
PilzAdam |
RealBadAngel, no, I just dont care about a random magazine |
| 18:26 |
celeron55 |
kahrl_: how about you just merge your thing because it's already tested |
| 18:26 |
RealBadAngel |
PilzAdam, its not fuckin random. its the biggest polish one |
| 18:26 |
sapier1 |
I do care about it it's a big opportunity if we can use this chance why not do it? |
| 18:26 |
kahrl_ |
celeron55: most were against it, so I'm not going to |
| 18:26 |
PilzAdam |
re the jthread thing: I agree on what gets merged first |
| 18:27 |
sapier1 |
but we should push mod developers to integrate their mods to moddb too |
| 18:27 |
RealBadAngel |
i managed to get they approval and you say you pay no shit about it?? |
| 18:27 |
celeron55 |
kahrl_: but roughly as many were against mine too |
| 18:27 |
celeron55 |
and mine isn't tested |
| 18:27 |
celeron55 |
and we have to choose some of them |
| 18:28 |
sapier1 |
rba just ignore pilzadam he's strange the last days must be the heat ;-) |
| 18:28 |
RealBadAngel |
its fucking sad |
| 18:28 |
Jordach |
PilzAdam, New People = New Devs / Modders, New People = Word of Mouth = More people, loop; |
| 18:28 |
celeron55 |
RealBadAngel: you shouldn't care about what some dev cares; people have their priorities |
| 18:28 |
celeron55 |
RealBadAngel: you obviously care a lot more because you're polish |
| 18:29 |
kahrl_ |
we should get a release out soonish regardless of the magazine thing |
| 18:29 |
Jordach |
remember, the polish go in their thousands |
| 18:29 |
RealBadAngel |
celeron55, you have actutally learned me the most |
| 18:29 |
sapier1 |
celeron55 imho we should try do help as much as possible |
| 18:29 |
RealBadAngel |
i was about to quit the community |
| 18:29 |
RealBadAngel |
because of you |
| 18:29 |
sapier1 |
of course if there's no chance to get it stable we shouldn't rush it |
| 18:30 |
RealBadAngel |
but then VanessaE helped me realize i shouldnt |
| 18:30 |
PilzAdam |
celeron55, MinetestBot has a !rand function |
| 18:30 |
RealBadAngel |
i stayed, and im doing what i love to do |
| 18:30 |
PilzAdam |
we can use it to decide on the jthread thing |
| 18:30 |
sapier1 |
LOL |
| 18:30 |
kahrl_ |
design by rng, still better than design by committee :D |
| 18:31 |
RealBadAngel |
so, sorry, PA, im immune to your tricks |
| 18:31 |
celeron55 |
hmmmm: can you promise to merge either kahrl_'s or my code, because you're the one who made the problem in the first place |
| 18:31 |
RealBadAngel |
i was trained by c55 |
| 18:31 |
Jordach |
who isn't PilzAdam |
| 18:31 |
Jordach |
PilzAdam, you should stop with the: I'm elite, GTFO |
| 18:31 |
RealBadAngel |
and magazine version is going to be released in all its glory |
| 18:32 |
RealBadAngel |
for us all |
| 18:32 |
sapier1 |
rba is 14th date of release or last change? |
| 18:32 |
RealBadAngel |
14th is the date for files |
| 18:32 |
RealBadAngel |
dvds have to be burnt |
| 18:32 |
sapier1 |
ok so we should target our final build at 10th |
| 18:33 |
Jordach |
RC1 = July 8th |
| 18:33 |
Jordach |
RC2 = July 9th |
| 18:33 |
Jordach |
Release = 10th |
| 18:33 |
RealBadAngel |
as i was said, if we dont supply files by 14th |
| 18:33 |
RealBadAngel |
all will be delayed by month |
| 18:34 |
RealBadAngel |
and no excuses |
| 18:34 |
celeron55 |
well that's not bad at all, lol |
| 18:34 |
sapier1 |
of course not but are there many open issues right now? |
| 18:35 |
RealBadAngel |
mc has far more issues |
| 18:35 |
RealBadAngel |
without any wishing well |
| 18:35 |
kahrl_ |
we shouldn't use MC as an excuse |
| 18:35 |
|
Jordach_ joined #minetest-dev |
| 18:36 |
RealBadAngel |
but we shouldnt fear also |
| 18:36 |
kahrl_ |
if we did, we wouldn't have a modding api yet :P |
| 18:36 |
sapier1 |
are there any other changes that should be added expect of those I already suggested (and weather fixes) |
| 18:36 |
RealBadAngel |
we are solving them way faster mc did |
| 18:37 |
RealBadAngel |
i catch myself sometimes, sayin whoa! thats a thing mc doesnt have |
| 18:38 |
Jordach_ |
we got the modding api first |
| 18:38 |
RealBadAngel |
and we are really close to border |
| 18:38 |
RealBadAngel |
soon they gonna chase us |
| 18:38 |
sapier1 |
but we don't play those feature cards very well |
| 18:38 |
celeron55 |
well the racers aren't really even on the same track |
| 18:39 |
RealBadAngel |
we miss PR |
| 18:39 |
RealBadAngel |
dont you think? |
| 18:39 |
kahrl_ |
we don't really need PR as we don't make any money from this |
| 18:39 |
sapier1 |
and usability my littl bro still tells me minetest is to complicated |
| 18:39 |
RealBadAngel |
we have to sell ourselves |
| 18:39 |
sapier1 |
I guess the all new mod download store will draw a lot of ppl to minetest |
| 18:39 |
RealBadAngel |
sapier1, exactly |
| 18:39 |
PilzAdam |
<kahrl_> we don't really need PR as we don't make any money from this <- yep, exactly that |
| 18:40 |
RealBadAngel |
thats why i was screamin for installer |
| 18:40 |
RealBadAngel |
click n play |
| 18:40 |
RealBadAngel |
even for kids |
| 18:40 |
RealBadAngel |
because kids know what minecraft is |
| 18:40 |
PilzAdam |
the installer is actually more complicated than the .zip |
| 18:40 |
sapier1 |
guys everyone doing oss wants to get his work used so don't tell me you don't |
| 18:40 |
|
ecube joined #minetest-dev |
| 18:40 |
sapier1 |
lol pilzadam did you ever try it? |
| 18:41 |
kahrl_ |
sapier1: not necessarily; some do it just for learning purposes, for example |
| 18:41 |
celeron55 |
my view on everything is that diversity is best, but diversity can't be put in the same bucket |
| 18:41 |
RealBadAngel |
listen, 5 yrs old girl |
| 18:41 |
RealBadAngel |
saw my work screen |
| 18:41 |
kahrl_ |
and since they don't plan to make any money from it they release it as oss |
| 18:41 |
RealBadAngel |
and said youre playin minecraft? |
| 18:41 |
sapier1 |
yes kahrl and forget about it after they got their grades |
| 18:42 |
RealBadAngel |
i said no, its minetest |
| 18:42 |
kahrl_ |
yeah, and that's not bad |
| 18:42 |
kahrl_ |
if others else is interested |
| 18:42 |
kahrl_ |
oops |
| 18:42 |
celeron55 |
some money flow would stabilize minetest a lot, but otoh the lack of money kind of makes it what it is |
| 18:42 |
VanessaE |
RealBadAngel: I got the exact same reaction from a ~10 year old neighbor kid who used to stop by the window to talk |
| 18:42 |
kahrl_ |
if others are interested in it they can continue developing it |
| 18:42 |
RealBadAngel |
whats the difference,she asked? |
| 18:43 |
sapier1 |
kahrl I'm doing this for learning too of course but I do want others to use it |
| 18:43 |
RealBadAngel |
we DEFINITELY need dumb easy interface |
| 18:43 |
sapier1 |
rba that's what the new mainmenu is targeted at |
| 18:43 |
kahrl_ |
sure, I'm not saying noone cares about others using it |
| 18:43 |
sapier1 |
who did try mod download store? |
| 18:44 |
celeron55 |
RealBadAngel: make an alternative main menu for dummies |
| 18:44 |
celeron55 |
and make an installation package that uses it by default |
| 18:44 |
RealBadAngel |
celeron55, you mean whole the world outside |
| 18:44 |
celeron55 |
then throw that all over the internet (maybe even with a different name) |
| 18:44 |
VanessaE |
sapier1: the one in the "Mods" tab? |
| 18:44 |
sapier1 |
mainmenu can be switched by configuration option |
| 18:44 |
RealBadAngel |
because all the hardcore you already have there |
| 18:44 |
sapier1 |
the one showing up as soon as you press "download" yes |
| 18:45 |
VanessaE |
sapier1: it looks ok but is totally useless without content :P |
| 18:45 |
sapier1 |
exactly :-) but it's easy |
| 18:45 |
sapier1 |
and I'm next to sure content will be added fast as soon as this is released in a stable version |
| 18:45 |
RealBadAngel |
if im alone can bring here ten players |
| 18:46 |
RealBadAngel |
only by makin game easier |
| 18:46 |
RealBadAngel |
it means thats a prority |
| 18:46 |
VanessaE |
sapier1: extremely important is it needs feedback. when I click "Download", I should immediately see a "Fetching the list of mods, please wait..." |
| 18:46 |
VanessaE |
and then the list should appear. |
| 18:46 |
RealBadAngel |
and you guys should stop tech talks |
| 18:47 |
PilzAdam |
sapier1, the translation thing should be done before we release 0.4.8 |
| 18:47 |
RealBadAngel |
and make the game friedly |
| 18:47 |
sapier1 |
if I remember correctly modlist is already fetched if you press download |
| 18:47 |
RealBadAngel |
for any new user |
| 18:47 |
BlockMen |
RealBadAngel, just removing https://github.com/minetest/minetest/blob/master/src/environment.cpp#L2245 does not work because it get "reset" in #L2272. But when removing there liquid too you "drown" in air because it is set=true for every node |
| 18:47 |
PilzAdam |
RealBadAngel, why dont _you_ do anything about a more user friendly UI? |
| 18:47 |
RealBadAngel |
and this shall be a point |
| 18:47 |
sapier1 |
if we release as of 10th that's almost impossible |
| 18:47 |
BlockMen |
so that must be changed too like i mentioned ;) |
| 18:47 |
VanessaE |
sapier1: yes, but it causes the program to hang while it does so - no feedback saying "ok, that button works, but I need time to fulfill your request" |
| 18:48 |
sapier1 |
does it? didn't know about that ... I'm gonna have a look at it |
| 18:48 |
kahrl_ |
why aren't fetches of that kind done in a background thread? |
| 18:49 |
kahrl_ |
or asynchronously (seems more complicated than the thread) |
| 18:49 |
sapier1 |
because there isn't a way to do that right now |
| 18:49 |
PilzAdam |
RealBadAngel, I mean, you come here several times, say "everyone stop doing what you currently do, and make the UI more user friendly, this is the highest priority"; and what do you do? nothing |
| 18:49 |
RealBadAngel |
PilzAdam, i havent changed the logic |
| 18:49 |
RealBadAngel |
afaik its your job |
| 18:49 |
VanessaE |
kahrl_: I've been asking the same since the Public Server list was added, as it does the same damn thing - and if you lack a 'net connection, the whole game is unresponsive for quite some time when first started. |
| 18:50 |
RealBadAngel |
dont fuckin blame me for your faults |
| 18:50 |
VanessaE |
s/game/program/ |
| 18:50 |
VanessaE |
which makes modding a real pain in the ass if you're offline. |
| 18:50 |
RealBadAngel |
i just changed it to use m_breath |
| 18:50 |
kahrl_ |
you can change it to use the favorite server list by default |
| 18:50 |
sapier1 |
someone needs to decide which one until 10th both are impossible |
| 18:50 |
kahrl_ |
but yeah, it ought to be fixed |
| 18:50 |
RealBadAngel |
if it is faulty it means you have fucked it up |
| 18:51 |
PilzAdam |
RealBadAngel, wut? |
| 18:51 |
sapier1 |
either localization or 5 second timeout fix |
| 18:51 |
RealBadAngel |
wut wut |
| 18:51 |
VanessaE |
kahrl_: I believe the hang happens even if "favorites" is the default focus |
| 18:51 |
RealBadAngel |
use english |
| 18:51 |
kahrl_ |
it does? I never checked the code and my connection is fast enough to not notice it |
| 18:52 |
PilzAdam |
RealBadAngel, you seem to be talking about drowning, why do you talk to me then? |
| 18:52 |
VanessaE |
kahrl_: I don't notice it normally - but when I went offline for a few days recently, boy howdy did I notice it :P |
| 18:52 |
sapier1 |
almost szre vanaessae as curl uses a timeout to abort if no connection is possible |
| 18:52 |
RealBadAngel |
because you pointed it? |
| 18:52 |
VanessaE |
but I can't be 100% certain if it was focused on favorites or public at the time, already forgot. |
| 18:52 |
PilzAdam |
RealBadAngel, no, BlockMen did |
| 18:53 |
VanessaE |
sapier1: that timeout seems to be somewhere north of 30 seconds, which is plain unacceptable since it hangs the program entirely. |
| 18:53 |
BlockMen |
I was, whats wrong? |
| 18:53 |
RealBadAngel |
PilzAdam, i dont know whats wrong bout you but you alwayas raise my blood pressure |
| 18:54 |
RealBadAngel |
anyway, im not responsible for shape of drowning code |
| 18:54 |
BlockMen |
RBA, if i said sth wrong, sry, i just wanted inform you (cas i thought it could interest u) |
| 18:54 |
Jordach_ |
ladies ladies; hambags down, now get back to compiling and coding |
| 18:55 |
RealBadAngel |
i just exposed variables to lua |
| 18:55 |
* kahrl_ |
hands RBA some beta blockers |
| 18:55 |
sapier1 |
ok ok the timeout is only used for json fetching |
| 18:55 |
RealBadAngel |
kahrl_, thx, i already was applied with one |
| 18:55 |
RealBadAngel |
one week vacations |
| 18:56 |
* VanessaE |
hands RealBadAngel some calcium channel blockers :P |
| 18:56 |
PilzAdam |
RealBadAngel, I am still confused why you suddenly start to talk about drowning when we where talking about user friendly UIs |
| 18:56 |
RealBadAngel |
PilzAdam, shit, you have linked me to the code |
| 18:57 |
PilzAdam |
no, it was BlockMen |
| 18:57 |
RealBadAngel |
sorry |
| 18:57 |
* RealBadAngel |
is calming down |
| 18:57 |
RealBadAngel |
again, im sorry, please forgive me PilzAdam |
| 18:57 |
PilzAdam |
you know, BlockMen and me are different persons |
| 18:58 |
RealBadAngel |
no shit |
| 18:58 |
BlockMen |
we are? |
| 18:58 |
BlockMen |
dont say so :D |
| 18:58 |
RealBadAngel |
rly? |
| 18:58 |
sapier1 |
sorry favorites are a json value too ... can you check value of timeout vanessae? |
| 18:58 |
Jordach_ |
i always thought BlockMen == PilzAdam |
| 18:58 |
BlockMen |
i know Jordach -.-' |
| 18:58 |
|
smoke_fumus joined #minetest-dev |
| 18:58 |
kahrl |
BlockMen even fits the voxel concept |
| 18:58 |
sapier1 |
minetest.conf curl_timeout it's in ms |
| 18:59 |
RealBadAngel |
okay guys |
| 18:59 |
RealBadAngel |
lets put those aside |
| 18:59 |
RealBadAngel |
i have bigger problem |
| 18:59 |
VanessaE |
sapier1: that value is not set in my .conf (and is not explained in the .example, either) |
| 18:59 |
RealBadAngel |
each rendered tile needs variables |
| 19:00 |
BlockMen |
kahrl, pure accident :P |
| 19:00 |
RealBadAngel |
in GLSL shaders such variable is called attribute |
| 19:00 |
RealBadAngel |
irrlicht engine doesnt support such variables |
| 19:01 |
RealBadAngel |
so if i have a tile, i cannot get modifiers for it easily |
| 19:01 |
RealBadAngel |
i figured out how to solve it |
| 19:02 |
RealBadAngel |
im creaing textures with irrlicht |
| 19:02 |
RealBadAngel |
and setting pixels as data |
| 19:02 |
Jordach_ |
hax |
| 19:02 |
RealBadAngel |
yup |
| 19:02 |
kahrl |
you can get *some* parameters by using a different vertex type |
| 19:02 |
kahrl |
attributes* |
| 19:02 |
RealBadAngel |
but im sure that proper data reach the shader |
| 19:03 |
kahrl |
video::S3DVertexTangents for example |
| 19:03 |
sapier1 |
it's set in defaultsettings.cpp ... ppl shouldn't change it but you could try setting it manually |
| 19:03 |
RealBadAngel |
kahrl, no |
| 19:03 |
RealBadAngel |
theres no way to pass attribute |
| 19:03 |
RealBadAngel |
at least i couldnt find a way |
| 19:04 |
RealBadAngel |
irrlicht just doest support it |
| 19:04 |
kahrl |
let's add irrlicht as a static bundled library that we can modify :D |
| 19:04 |
RealBadAngel |
i do have tangent space calculations done in cpp |
| 19:05 |
RealBadAngel |
but no way to interface it |
| 19:05 |
RealBadAngel |
so i created texture interface |
| 19:05 |
RealBadAngel |
since textures are not limited |
| 19:06 |
RealBadAngel |
i reserved a channel for settings |
| 19:06 |
RealBadAngel |
and one for data |
| 19:06 |
kahrl |
textures are limited, that's why some people get messed up inventory textures |
| 19:06 |
RealBadAngel |
no they are not |
| 19:07 |
VanessaE |
kahrl: no, I believe that's some weird off-by-1 error |
| 19:07 |
RealBadAngel |
at least when we talk irrlicht |
| 19:07 |
kahrl |
I guess those people won't use fancy shaders anyway |
| 19:07 |
RealBadAngel |
shader no matter how fancy is a material type |
| 19:08 |
kahrl |
VanessaE: could be, but why does it only happen for a few people and always with weak GPUs? |
| 19:08 |
RealBadAngel |
material can have unlimited number of textures |
| 19:08 |
VanessaE |
kahrl: I am not sure at all, I've been trying to figure that out forever |
| 19:08 |
RealBadAngel |
i think limit is 64k |
| 19:09 |
RealBadAngel |
but anyways |
| 19:09 |
RealBadAngel |
theres no fuckin way to pass tile dependent data to shader |
| 19:10 |
RealBadAngel |
you can pass globals ofc |
| 19:10 |
RealBadAngel |
but not tile specific |
| 19:11 |
RealBadAngel |
i managed to solve it with setting new texture |
| 19:11 |
RealBadAngel |
holding a data which uniform sampler can get |
| 19:11 |
kahrl |
if you make a separate texture for each tile you will have an insane number of mesh buffers and an insane number of material switches in the rendering routine |
| 19:12 |
kahrl |
sounds like trouble |
| 19:12 |
RealBadAngel |
not really |
| 19:12 |
kahrl |
it might be faster to use the same secondary texture for multiple tiles and use a secondary texture coord to pass an index into it |
| 19:12 |
RealBadAngel |
im makin 10-15bytes long textures |
| 19:13 |
RealBadAngel |
which are deleted on nexr render approach |
| 19:13 |
kahrl |
I haven't measured it, but I'm always told that material switches are slow |
| 19:13 |
RealBadAngel |
hmmm |
| 19:13 |
RealBadAngel |
dunno |
| 19:14 |
celeron55 |
yes they are slow, and the speed of them variaes by multiple orders of magnitude between different GPUs |
| 19:14 |
RealBadAngel |
definitely its a problem |
| 19:14 |
kahrl |
e.g. in OpenGL it usually implies a whole bunch of commands to the video card to set the new material options |
| 19:14 |
RealBadAngel |
if you guys have better solotution just let me know |
| 19:14 |
celeron55 |
eg. i know some old laptop users that got totally crap perforamnce out of MT when the texture atlas once got inefficiently used, while i saw no difference on my old laptop |
| 19:14 |
kahrl |
as I said, reuse the same texture and use a secondary coord |
| 19:15 |
kahrl |
which is basically the idea of a texture atlas |
| 19:15 |
celeron55 |
and in modern rendering you don't even consider whether it might be fast or not, because every command will take forever compared to bulk rendering speed |
| 19:15 |
RealBadAngel |
ah |
| 19:16 |
RealBadAngel |
kahrl, we are facing another problem now |
| 19:16 |
RealBadAngel |
i have already forgot bout atlas |
| 19:16 |
RealBadAngel |
what bothers me now is tangent space |
| 19:17 |
RealBadAngel |
i need this vector for every plane |
| 19:17 |
proller |
celeron55, serialize with net version: https://github.com/proller/minetest/compare/ver , but now finding how to pass version to deserialize... |
| 19:17 |
RealBadAngel |
i CAN do this in shader, but its resource heavy |
| 19:18 |
RealBadAngel |
and is buggy |
| 19:18 |
celeron55 |
proller: just add a version in the data itself like in most places? |
| 19:18 |
celeron55 |
if that's an issue otherwise |
| 19:19 |
proller |
now finding where to get version on client... |
| 19:19 |
celeron55 |
(it probably is, because most of it is designed around versions being put in there) |
| 19:19 |
celeron55 |
proller: remember how nodebox did it? |
| 19:19 |
kahrl |
RealBadAngel: ah, irrlicht only has one type for vertices with a secondary texture coord and another with tangent vectors |
| 19:19 |
kahrl |
but none with both, that sucks |
| 19:19 |
celeron55 |
proller: do it in the same way; that's why there are the 1 and 2 versions now there |
| 19:20 |
celeron55 |
(better not invent anything new for it but rather rework everything at the same time if so is decided) |
| 19:20 |
celeron55 |
oh actually |
| 19:21 |
celeron55 |
there *is* a problem |
| 19:21 |
celeron55 |
it's that you really shouldn't read even a version byte on client if it's an older version |
| 19:22 |
* celeron55 |
facepalms deeply |
| 19:22 |
celeron55 |
yeah, that's a terrible job you've got there, try to find a sane way 8) |
| 19:22 |
celeron55 |
we'll all pity you after this is merged |
| 19:22 |
kahrl |
RealBadAngel: can you encode the tangent vector in the secondary texture? |
| 19:23 |
celeron55 |
proller: you can read it actually though, as it's the last thing in the data, just try-catch the serialization error |
| 19:24 |
proller |
versions hell 8( |
| 19:24 |
RealBadAngel |
kahrl, yes, i did that |
| 19:24 |
kahrl |
please, when all is done, someone put up a page on the wiki that explains to dummies like me what has been done to the serialization versions |
| 19:25 |
celeron55 |
yeah, we're going to need to tidy this up in a large way sometime |
| 19:25 |
celeron55 |
kahrl: it's probably not explainable in human language, but maybe it can be attempted... |
| 19:26 |
celeron55 |
by the way, where is is supposed to go there? |
| 19:26 |
celeron55 |
the dev wiki seems to be badly organized in that people just link some random pages out of nowhere from there |
| 19:27 |
RealBadAngel |
celeron55, https://forum.minetest.net/viewtopic.php?id=6737 |
| 19:27 |
RealBadAngel |
here |
| 19:27 |
RealBadAngel |
for example ;) |
| 19:28 |
kahrl |
maybe ChangeLog/Some_title_about_serialization_versions and link to it from ChangeLog |
| 19:28 |
kahrl |
unless it's meant to be a more general page |
| 19:28 |
celeron55 |
i'll try to make some organization in there |
| 19:29 |
celeron55 |
and actually i think the only page that actually has been recently used is the TODO page |
| 19:29 |
RealBadAngel |
please do |
| 19:29 |
celeron55 |
which isn't linked anywhere in there 8D |
| 19:29 |
PilzAdam |
celeron55, the changelog is the most used page, I think |
| 19:30 |
kahrl |
the changelog is linked from the download page on minetest.net |
| 19:30 |
|
neko259 joined #minetest-dev |
| 19:30 |
kahrl |
TODO: link TODO from somewhere |
| 19:32 |
proller |
celeron55, client doesnt know net_proto_version 8( |
| 19:32 |
celeron55 |
proller: do the same thing as the nodebox you did doe |
| 19:32 |
celeron55 |
+s |
| 19:33 |
proller |
why not leave as now with serialization version? |
| 19:33 |
celeron55 |
it is immensely bad to use a disk serialization version for network |
| 19:33 |
celeron55 |
you have to get rid of it, it's the worst thing to do for the long term |
| 19:37 |
celeron55 |
kahrl: do you think this should be in changelog, or should it be some separate page? |
| 19:37 |
kahrl |
separate page, it would get cluttered otherwise |
| 19:38 |
proller |
celeron55, nodebox already have version 1 sended from server |
| 19:38 |
proller |
now version 2 |
| 19:38 |
VanessaE |
<offtopic> another user on my server reports crashes/hangs when opening the inventory (probably https://github.com/minetest/minetest/issues/831) </offtopic> |
| 19:38 |
celeron55 |
proller: yes, just include a version similarly in the function you added |
| 19:38 |
celeron55 |
start it from 1 |
| 19:39 |
proller |
but MapBlock doesnt have separate transfer version now |
| 19:39 |
proller |
adding new field will broke something |
| 19:39 |
celeron55 |
it doesn't have to, as it's the exact same data as is on disk and the server and client agree on what disk serialization version they use for mapblocks |
| 19:40 |
celeron55 |
you only break some random development versions network compatibility |
| 19:40 |
celeron55 |
that is a non-issue |
| 19:40 |
kahrl |
about VanessaE's bug report |
| 19:40 |
celeron55 |
you gain compatibility with previous releases which is the goal |
| 19:41 |
proller |
will try... |
| 19:41 |
kahrl |
are there any threads besides the main thread and the mesh update thread that call ITextureSource::getTexture? |
| 19:41 |
kahrl |
TextureSource's request queue doesn't currently identify the caller |
| 19:42 |
celeron55 |
i'm going to call this new wiki page "Dev Log" |
| 19:45 |
|
nore joined #minetest-dev |
| 19:45 |
nore |
about texture pack selection, what do you think of this? https://github.com/Novatux/minetest/commit/a8aa531a85ebf10913355fb445e10f0656fc9838 |
| 19:49 |
VanessaE |
nore: I don't see how that's too helpful without the GUI part to go with it. |
| 19:50 |
nore |
I will soon do it, just need to know how to make the listdir of the textures folder, since lua has no listdir command |
| 19:50 |
sapier1 |
and texture_path == texture_pack |
| 19:50 |
sapier1 |
what should be the difference between texture path and pack? |
| 19:51 |
nore |
texture path is where the textures are, texture pack is the name of the texture pack |
| 19:51 |
VanessaE |
but, I guess as long as it doesn't interfere with using textures/all as we do now it's okay |
| 19:52 |
nore |
no, it does not change textures/all, but textures should not be in texture_path |
| 19:52 |
sapier1 |
no no no it's not ok it's adding another way to add a texture pack this is going to be a nightmare to handle backgrounds overlays ... |
| 19:53 |
nore |
sapier1: how do you list the worlds, so it is possible to list texture packs? |
| 19:53 |
sapier1 |
worlds are scanned by minetest within specific folders |
| 19:53 |
VanessaE |
nore: that said, why not just change texture_path to point directly to the desired folder? |
| 19:53 |
sapier1 |
no you need to implement your own get_texturepack_list function |
| 19:53 |
VanessaE |
handle that with the GUI, use the last directory component as the texture pack name |
| 19:54 |
nore |
VanessaE: that could be done, but we would still need a setting for the place of texture packs |
| 19:54 |
VanessaE |
e.g. texture_path=/home/user/texture-packs/my_kickass_pack -> "my_kickass_pack" in the GUI |
| 19:55 |
VanessaE |
nore: then let the user choose a folder directly with a normal file dialog. |
| 19:55 |
sapier1 |
any you can already read a list of directorys in mainmenu |
| 19:55 |
VanessaE |
don't overcomplicate it, and don't ask the user to change how they manage their texture packs |
| 19:55 |
sapier1 |
use get_dirlist with "/homeuser/texture-packs" for example |
| 19:55 |
nore |
is there any builtin file dialog for now? |
| 19:55 |
proller |
celeron55, like this? : https://github.com/proller/minetest/compare/ver |
| 19:56 |
sapier1 |
menu_lua_api.txt |
| 19:56 |
sapier1 |
L152 |
| 19:57 |
VanessaE |
no no no no no - point to $HOME and let the user navigate to where THEY keep their texture packs |
| 19:57 |
VanessaE |
don't just assume they're in some specific folder, they never will be |
| 19:57 |
sapier1 |
so you suggest a browe button instead of a dropdown vanessae? |
| 19:58 |
VanessaE |
sapier1: precisely. |
| 19:58 |
sapier1 |
I thought we wanted to make the gui EASY? |
| 19:58 |
sapier1 |
how to explain user what folder to select in file select dialog? |
| 19:58 |
VanessaE |
"Browse" -> [file dialog opens, with a clear, large title saying "Select a texture pack folder"] -> user clicks on a folder and hits "OK". |
| 19:58 |
VanessaE |
how much easier does it need to be? |
| 19:59 |
VanessaE |
don't cater to complete morons |
| 19:59 |
sapier1 |
what is a texture pack folder? |
| 19:59 |
VanessaE |
if you can't even navigate around your machine with a file manager/file dialog, you need to put your computer awat |
| 19:59 |
VanessaE |
away* |
| 19:59 |
sapier1 |
no this is only clear to you vanessa ;-) not to the common noob |
| 19:59 |
VanessaE |
sapier1: the common noob needs to learn, this is computers 101 stuff |
| 19:59 |
nore |
sapier1: how do you use engine.file_open_dialog? |
| 20:00 |
VanessaE |
sapier1: if they can find their minetest folder to open and run the game, they can find where they downloaded the texture pack to. |
| 20:00 |
sapier1 |
did you ever see win8? navigation isn't expected by current users ;-) |
| 20:00 |
nore |
menu_lua_api.txt is not clear |
| 20:00 |
sapier1 |
? .... how more clear can it be? you can specify a formname and a caption? |
| 20:01 |
VanessaE |
sapier1: no, never seen it, and I steadfastly refuse to dumb the game down that far (if I had the option anyway) |
| 20:02 |
sapier1 |
if you get something except nil user pressed accept |
| 20:02 |
sapier1 |
wait ok you're right |
| 20:02 |
celeron55 |
kahrl, proller: http://dev.minetest.net/Dev_Log |
| 20:02 |
sapier1 |
there's no return value |
| 20:03 |
celeron55 |
kahrl: do you think that from here on we should require short write-ups to there of anything that was discussed a lot? |
| 20:03 |
nore |
ok, but what is formname for? |
| 20:03 |
sapier1 |
forget about the return value and look for a button event |
| 20:03 |
sapier1 |
it's like you specify a button |
| 20:03 |
celeron55 |
kahrl: (i think so) |
| 20:04 |
sapier1 |
with only difference that a file dialog is two buttons at once an formname_accept and a formname_cancel button |
| 20:04 |
nore |
sapier: in what file do you use that function? I could understand it more easily |
| 20:05 |
kahrl |
celeron55: I wouldn't require it, sometimes the end result of the discussion is clear from the git log |
| 20:05 |
nore |
sapier1: ok, I see better what should be done |
| 20:05 |
kahrl |
but for difficult technical things that may be important to know later I would require it |
| 20:05 |
sapier1 |
modmgr |
| 20:05 |
sapier1 |
line 550 |
| 20:06 |
celeron55 |
kahrl: well, maybe make a topic and link to log if the log is clear? |
| 20:06 |
celeron55 |
it'd be good for newcomers to read about all the things... somehow |
| 20:06 |
celeron55 |
and all the devs too, as nobody reads this channel all the time |
| 20:07 |
kahrl |
ah, yeah that could be done |
| 20:07 |
nore |
celeron55: what do you think about texture pack selection: texture packs in a folder, then a dropdown, or folder selection with a file dialog? |
| 20:09 |
celeron55 |
nore: a dropdown |
| 20:09 |
celeron55 |
it's what we do with worlds too, and mods |
| 20:09 |
proller |
celeron55, ver works with old servers |
| 20:09 |
celeron55 |
(well, lists, but whatever) |
| 20:09 |
kahrl |
this Dev Log is very helpful (even though it still makes my head hurt, haha) |
| 20:10 |
nore |
and what would be better: http://irc.minetest.ru/minetest-dev/2013-08-01#i_3231640 |
| 20:10 |
celeron55 |
proller: what you have now seems quite what i requested; now if we'll get a few others look at it to spot bugs |
| 20:11 |
proller |
"Sky" server upped with this, can anybody connect with 0.4.7? |
| 20:12 |
proller |
hm.. something wrong with heat&humidity |
| 20:13 |
|
salamanderrake joined #minetest-dev |
| 20:13 |
proller |
or not.. |
| 20:14 |
proller |
works |
| 20:14 |
celeron55 |
lol, i had 0.4.dev-20120606 around... server's PROTOCOL_VERSION is 13...21, client's PROTOCOL_VERSION is 10...10 |
| 20:14 |
celeron55 |
8D |
| 20:15 |
celeron55 |
can't find anything in between |
| 20:15 |
proller |
grandpa |
| 20:15 |
celeron55 |
i'll build a 0.4.7, this'll take like 5 minutes |
| 20:16 |
proller |
somebody plays already except me |
| 20:16 |
nore |
should the engine be modified to allow a texture_pack setting: https://github.com/Novatux/minetest/commit/a8aa531a85ebf10913355fb445e10f0656fc9838 |
| 20:17 |
nore |
or should the gui just change texture_path |
| 20:17 |
nore |
? |
| 20:17 |
proller |
spawn catch 0 heat and 0 humidity - very rare point, and its not broken 8) |
| 20:17 |
proller |
already -3 |
| 20:18 |
proller |
why abms on loaded bocks works sometimes with chance=1 ? |
| 20:18 |
proller |
its bug or feature? |
| 20:19 |
nore |
proller: do you mean they do not always trigger? |
| 20:19 |
proller |
always, for examlpe block gets freezed |
| 20:19 |
proller |
16x16x16 |
| 20:19 |
proller |
its impossible |
| 20:20 |
proller |
because chance=20 |
| 20:20 |
proller |
or 16x16 area gets snow or rain |
| 20:21 |
kahrl |
nore: I'd say texture_pack |
| 20:21 |
nore |
ah, you mean that sometimes an ABM is executed as if chance=1? |
| 20:21 |
proller |
yes! |
| 20:21 |
nore |
kahrl: sapier ans VanessaE said the other was better |
| 20:21 |
celeron55 |
ha, 0.4.7 built |
| 20:21 |
nore |
proller: no idea |
| 20:21 |
celeron55 |
took more than 5 minutes |
| 20:22 |
proller |
using -jX ? |
| 20:22 |
nore |
kahrl: what do you think of the commit? |
| 20:22 |
nore |
https://github.com/Novatux/minetest/commit/a8aa531a85ebf10913355fb445e10f0656fc9838 |
| 20:22 |
celeron55 |
proller: -j2, fastest on this computer |
| 20:22 |
kahrl |
nore: 2 things |
| 20:23 |
kahrl |
1. the comment in minetest.conf.example seems a bit unclear, maybe use $ in front of setting names |
| 20:23 |
kahrl |
2. the code in tile.cpp could be optimized a little by just getting the texture_pack setting once |
| 20:23 |
nore |
ok, doing it... |
| 20:24 |
kahrl |
otherwise it looks good |
| 20:24 |
celeron55 |
proller: there's one thing still though, if this works: change the commit of serialization.h from "26: MapBlocks contain heat and humidity. Never written; read the same as 25" to "26: Never written; read the same as 25", as it is completely useless to mention anything about weather in there because nothing about weather was written on disk or anything |
| 20:24 |
kahrl |
oh, wait |
| 20:24 |
kahrl |
another thing, if texture_pack is "" just look in texture_path as it is done currently |
| 20:25 |
kahrl |
to avoid screwing up current users |
| 20:27 |
celeron55 |
holy shit that was terrible |
| 20:27 |
celeron55 |
fps=1 with no free_move |
| 20:27 |
celeron55 |
on icey water |
| 20:27 |
celeron55 |
i'll get nightmares out of this |
| 20:27 |
proller |
its will melt in 3-5 minutes |
| 20:28 |
celeron55 |
oh lol, i have shaders enabled |
| 20:28 |
Jordach |
celeron55, i used to play 0.2 with 6 fps |
| 20:28 |
celeron55 |
no wonder it ran so badly |
| 20:28 |
Jordach |
it was fun |
| 20:28 |
nore |
karhl: done now |
| 20:28 |
|
kaeza joined #minetest-dev |
| 20:29 |
nore |
new commit: https://github.com/Novatux/minetest/commit/ecb764a59fd8b5777b686e5341e2a6640efa9d75 |
| 20:37 |
sapier1 |
why do you still use texture pack? are you really that eager to fix backgrounds overlays headers and footers again? |
| 20:37 |
sokomine |
you can get the experience of 1-3 fps even with high-end hardware if you like - just go to a server that got hit by the item duplication bug and idle a bit in one area |
| 20:37 |
sokomine |
it would be great if that bug could be found |
| 20:37 |
sapier1 |
just use texture_path and create a reasonable gui for it. imho you don't need to change anything within c++ code to do so |
| 20:39 |
kahrl |
sapier1: so you suggest to list the contents of the parent directory of texture_path? |
| 20:39 |
sapier1 |
one way to do it ... or specify a reasonable default folder to look for texture packs |
| 20:40 |
sapier1 |
at least if dropdown variant is chosen |
| 20:40 |
nore |
but then we have a problem if there is no texture_path folder |
| 20:40 |
proller |
celeron55, 26 desc changed |
| 20:40 |
sapier1 |
that's not a problem if you use a reasonable default |
| 20:40 |
nore |
and what should be the default |
| 20:41 |
nore |
? |
| 20:41 |
VanessaE |
"reasonable default" is easy: $MINETEST/textures/all |
| 20:41 |
sapier1 |
MINETESTDIR/textures? |
| 20:41 |
celeron55 |
proller: i'm happy with it now; if you can, squash it to two commits; one for nodebox and one for mapblock |
| 20:41 |
proller |
щл |
| 20:41 |
celeron55 |
i'd rather have someone else test it too |
| 20:41 |
proller |
ok |
| 20:41 |
nore |
we still need a listdir command |
| 20:42 |
celeron55 |
but as far as i can see, it works |
| 20:42 |
sapier1 |
no we don't it's already there |
| 20:42 |
nore |
where? |
| 20:42 |
sapier1 |
get_dirlist? |
| 20:43 |
nore |
ah, ok, found it. |
| 20:43 |
nore |
I can now make my code. |
| 20:43 |
sapier1 |
maybe you should hide e.g. all but not sure about it |
| 20:44 |
sapier1 |
be aware that you're not allowed to list all folders for security reasons |
| 20:44 |
nore |
all should be renamed to "Default" in the menu |
| 20:44 |
kahrl |
hide the whole selection list if texture_path is set to something other than textures/pack |
| 20:44 |
kahrl |
? |
| 20:45 |
nore |
when you say all folders, which ones are you able to list? |
| 20:45 |
sapier1 |
good ide this can only be done by ppl modifying minetest.conf manuall thus menu doesn't need to support this |
| 20:45 |
sapier1 |
all folders expected to contain minetest data + tmp |
| 20:45 |
|
nalkri joined #minetest-dev |
| 20:46 |
kahrl |
sapier1: offtopic, but allowing tmp there could be dangerous |
| 20:46 |
nore |
and do you think there should be a special image in TPs for screenshot? |
| 20:46 |
kahrl |
can lua set $TMPDIR somehow? |
| 20:46 |
sapier1 |
I guess it can |
| 20:46 |
nore |
and then show it in the selection? |
| 20:46 |
sapier1 |
but even without this problem tmp may be dangerous on linux too |
| 20:47 |
kahrl |
sapier1: should downloaded mods be unpacked in client/tmp maybe? |
| 20:47 |
sapier1 |
we'd need our own mt tmp folder to avoid this |
| 20:47 |
kahrl |
err cache/tmp |
| 20:47 |
kahrl |
it already exists and it used for sounds |
| 20:47 |
kahrl |
is* |
| 20:47 |
celeron55 |
haha lol, the ogg loader |
| 20:47 |
celeron55 |
it's still there |
| 20:48 |
sapier1 |
yes I don't see any reason why this shouldn't be possible |
| 20:48 |
sapier1 |
still mainmenu isn't that critical to require instant action |
| 20:49 |
kahrl |
when we are bored during feature freeze we could change it |
| 20:49 |
sapier1 |
bored? :-) |
| 20:50 |
sapier1 |
I try to find a way to allow vanessae's async events in menu right now ... I thought it'd be a 50 liner ... |
| 20:50 |
kahrl |
you surely already know there are no bugs in minetest so there's nothing to do during feature freeze ;) |
| 20:51 |
BlockMen |
from when until when is feature freeze? |
| 20:52 |
kahrl |
BlockMen: not decided yet |
| 20:52 |
proller |
celeron55, 2 commits: https://github.com/proller/minetest/compare/ver |
| 20:53 |
BlockMen |
kahrl, ok |
| 20:54 |
nore |
texture pack selection should be merged before feature freeze, I reckon |
| 20:54 |
celeron55 |
i'd be relieved if somebody took a look at that one ^ |
| 20:55 |
proller |
celeron55, and something with defaults tune: https://github.com/proller/minetest/commit/5038bc00564913b2db5f1839ad52083c7e08414c |
| 20:56 |
sapier1 |
nore depends on when feature freeze will be done and what you're going to change ;-) |
| 20:56 |
nore |
only builtin/mainmenu.lua (and perhaps default_settings.cpp) |
| 20:58 |
celeron55 |
proller: i don't like it that everyone else is so busy now or went away that they're not looking at these |
| 20:58 |
celeron55 |
you shouldn't like it either, if there's anything we've learned |
| 21:00 |
celeron55 |
anyway merge the compatibility thing, i've looked at it so long that i'm pretty sure it works well enough |
| 21:00 |
proller |
щлфн |
| 21:00 |
proller |
okay |
| 21:01 |
celeron55 |
while looking at proller's things, i've noticed this time bomb by hmmmm: https://github.com/minetest/minetest/blob/master/src/mapgen.cpp#L694 |
| 21:01 |
celeron55 |
and the corresponding serialize |
| 21:02 |
celeron55 |
if mapnode serialization changes some day, schematic compatibility will silently break because it uses that constant rather than the actual version number |
| 21:02 |
celeron55 |
it should be changed to 25, probably |
| 21:03 |
celeron55 |
let's not do it now though |
| 21:03 |
celeron55 |
but it's wrong anyway |
| 21:04 |
proller |
celeron55, but inside deSerializeBulk version is checked |
| 21:05 |
celeron55 |
the check is useless |
| 21:05 |
celeron55 |
the version input doesn't come from the data |
| 21:05 |
celeron55 |
the schematic is versioned separately |
| 21:09 |
BlockMen |
has someone an idea what could cause an formspec error in my builds? ingame all labels are missing, but in the new formspec-menu all is shown correct |
| 21:10 |
proller |
celeron55, in long term backward compatibility is evil |
| 21:11 |
celeron55 |
proller: in on-disk formats, it's simply required |
| 21:11 |
celeron55 |
proller: in everything else, too much of it is evil |
| 21:11 |
proller |
required one-way convert from old versions |
| 21:11 |
celeron55 |
that's compatibility |
| 21:12 |
celeron55 |
it's evil, isn't it? |
| 21:12 |
celeron55 |
anyway the way we handle most compatibility simply sucks currently |
| 21:13 |
proller |
yes |
| 21:13 |
proller |
whats about https://github.com/proller/minetest/commit/5038bc00564913b2db5f1839ad52083c7e08414c |
| 21:13 |
celeron55 |
we could have the same amount of compatibility with much less trouble with better solutions |
| 21:13 |
Jordach |
BlockMen, sounds like sapier1 buggered up formspec again |
| 21:14 |
BlockMen |
Jordach, no |
| 21:14 |
proller |
but ned to switch everything to key-value |
| 21:14 |
BlockMen |
i have talked with him bout that already, and it works in e.g. PA builds |
| 21:14 |
sapier1 |
I didn't do anything to ingame formspec except of some sanity checks ... those result in elements not beeing shown at all but not text missing |
| 21:15 |
celeron55 |
proller: you can do the cloud thing as long as it looks the same by default, but notice that there are some mgparams stuff in there that you don't probably want |
| 21:16 |
celeron55 |
altough, as usual, it would be healthy to wait for others to look at it too |
| 21:16 |
proller |
in mgparams only liquid_finite save as you want |
| 21:16 |
BlockMen |
maybe wrong ft version |
| 21:16 |
BlockMen |
what version you use sapier? |
| 21:17 |
celeron55 |
proller: but it isn't used? |
| 21:17 |
proller |
cloud with this can be moved upper or lower with saving default visual speed and size, but if upper than 500 - too ugly clipping starts |
| 21:18 |
proller |
celeron55, used and works as water_level |
| 21:18 |
celeron55 |
how can it work now without it then |
| 21:18 |
proller |
with this patch it saved to map meta |
| 21:20 |
celeron55 |
uh oh |
| 21:20 |
celeron55 |
well if it works, it's good; but those aren't supposed to be in the same commit |
| 21:20 |
celeron55 |
they're completely different things |
| 21:20 |
proller |
PilzAdam, https://github.com/proller/minetest/commit/5038bc00564913b2db5f1839ad52083c7e08414c -- with increasing liquid update interval, to max 5000 blocks per secont |
| 21:21 |
proller |
celeron55, okay, will split it |
| 21:21 |
PilzAdam |
how finite liquids a mapgen param? |
| 21:21 |
PilzAdam |
+s |
| 21:22 |
proller |
its not really mapgen, but it for saving per world for not broking old worlds |
| 21:22 |
PilzAdam |
and I dont see why increasing the cloud height is neede |
| 21:22 |
PilzAdam |
+d |
| 21:23 |
proller |
because for example it can used for rain-snow upper limit |
| 21:23 |
BlockMen |
hmm...seems fess has same problems |
| 21:23 |
BlockMen |
https://forum.minetest.net/viewtopic.php?id=6769 |
| 21:23 |
celeron55 |
PilzAdam: changing the cloud height isn't needed, but i don't see how it's bad to allow someone to do that without getting their clouds look odd |
| 21:23 |
proller |
and 120 is too low and too easy to reach |
| 21:23 |
sapier1 |
VanessaE could you plz check if this prototype results in better favorites list behaviour for you? https://github.com/sapier/minetest/tree/asynchronous_events |
| 21:24 |
celeron55 |
oh |
| 21:24 |
proller |
i'm for 1000+ clouds, but its now impossible with clipping |
| 21:24 |
celeron55 |
that also adjust the defaults |
| 21:24 |
celeron55 |
i better go to sleep, i'm not noticing anything |
| 21:24 |
celeron55 |
proller: don't change the cloud height without approval of many |
| 21:24 |
proller |
ok |
| 21:25 |
proller |
PilzAdam, and clouds when you inside it - buggy |
| 21:25 |
celeron55 |
it is a fun part of the game to be able to reach clouds easily |
| 21:25 |
PilzAdam |
also, liquid_update 0.2 is way too fast for lava |
| 21:25 |
proller |
and musch more buggy when you in high mountain, and look at cloud in cave |
| 21:26 |
proller |
0.4 better? |
| 21:26 |
PilzAdam |
yea, 0.4 is better |
| 21:27 |
PilzAdam |
also increase liquid_loop_max to 10000 again |
| 21:27 |
PilzAdam |
a problem with the water update is that there is >1 second lag sometimes, even in singleplayer |
| 21:27 |
PilzAdam |
so increase the update interval doesnt really help here |
| 21:28 |
proller |
with 10000 no sense to touch upddate |
| 21:28 |
celeron55 |
...so are you making it so that most of minetest's network consumption will be due to... liquids? |
| 21:28 |
celeron55 |
there are reasons why it's 1.0 and not 0.00001 |
| 21:29 |
proller |
maybe limit mapblock update to 1s ? |
| 21:29 |
celeron55 |
and what do you gain with that? 8) |
| 21:30 |
proller |
faster finite liquid transform |
| 21:30 |
sapier1 |
great we're updating fluids faster than mob states :-) |
| 21:31 |
proller |
simple mobs now like to jump in lakes |
| 21:31 |
PilzAdam |
I kinda get the imprission that Minetest sucks at everything that is dynamic |
| 21:31 |
sapier1 |
they always ran into water |
| 21:31 |
celeron55 |
PilzAdam: it does, that's no secret |
| 21:31 |
proller |
8( |
| 21:32 |
sapier1 |
774 and 418 inprove this without adding (lots of) additional network overhead |
| 21:32 |
sapier1 |
:-) |
| 21:34 |
celeron55 |
well anyway, minetest kind of can cope with fast changing mapblocks by prioritizing transfers of them |
| 21:35 |
celeron55 |
but try to be careful, it's easy to make it just kill itself with eg. 10 players or so |
| 21:35 |
sapier1 |
why not make client predict some things? |
| 21:35 |
celeron55 |
that's the only way to practically make smooth things |
| 21:36 |
sapier1 |
I guess client could calculate fluids almost as precise as server does so updates may not result in big differences as long as latency isn't tooo bad |
| 21:36 |
proller |
maybe make dynamic update interval depending on queue size, like if >10000 -- 0.1, >5000 -- 0.3 <1000 -- 1, |
| 21:36 |
celeron55 |
well... it's probably hard to interpolate between liquid states in a smooth way |
| 21:37 |
PilzAdam |
proller, that wouldnt be good, the liquid "speed" depends on the update interval |
| 21:37 |
PilzAdam |
it would give incosistent gameplay |
| 21:37 |
sapier1 |
dynamic update interval assumes you're liquids are the only thing that need a lot of cpu performance |
| 21:37 |
proller |
PilzAdam, if queue big - speet gets slooow |
| 21:38 |
proller |
and if < 1000 - yes, it can affect |
| 21:38 |
sapier1 |
still mobs could use as much as possible cpu power to get smarter too ... so you'd need to add prioritys for high cpu tasks |
| 21:39 |
celeron55 |
there should be pie charts shown on the client of what uses server CPU and client CPU 8) |
| 21:40 |
sapier1 |
yes and preferably mod specific on server ;-) |
| 21:40 |
PilzAdam |
there should be more pie too |
| 21:40 |
celeron55 |
people would be more interested to keep their code good if they saw how bad it was |
| 21:40 |
celeron55 |
now they just throw it in and think "oh minetest is just bad, not my code" |
| 21:41 |
sapier1 |
or say mobf is slow because latency shows up for mobs not for other mobs |
| 21:41 |
sapier1 |
other mods of course |
| 21:43 |
proller |
celeron55, why abms sometimes can run with forced chance=1 ? |
| 21:43 |
celeron55 |
like when a block has been unloaded for a long time and gets loaded? |
| 21:43 |
proller |
yes |
| 21:44 |
celeron55 |
that's a feature |
| 21:44 |
proller |
its feature> |
| 21:44 |
celeron55 |
a bit hard to control feature though |
| 21:44 |
proller |
its possible to disable for some abms? |
| 21:44 |
proller |
its makes buggy flooding rain |
| 21:45 |
celeron55 |
i think not; that might be reasonable i guess... i also think it's been asked before but not enough for the lazy to get doing it |
| 21:45 |
sapier1 |
rain per abm? |
| 21:46 |
proller |
https://github.com/proller/minetest-mod-weather/blob/weather/weather/rain.lua |
| 21:49 |
proller |
but it hart to catch without fast and flying privs |
| 21:50 |
proller |
aabm.chance = chance / intervals |
| 21:55 |
nore |
sapier: I finally have a GUI, but textures do not change until minetest is restarted |
| 21:55 |
nore |
do you know why? |
| 21:55 |
nore |
I even tried to remove the contents of cache/media, but no sucess... |
| 21:57 |
kahrl |
proller: mathematically speaking, that formula isn't sound |
| 21:57 |
kahrl |
let p = 1/chance, P = 1/aabm.chance, n = intervals |
| 21:58 |
proller |
if(aabm.chance == 0)aabm.chance = 1; |
| 21:58 |
sapier1 |
in menu they don't change because the path is cached in game they should change as it's read on game startup |
| 21:58 |
nore |
no, but texture inside game |
| 21:58 |
kahrl |
the probability that at least one out of n random bernoulli events with probability p each succeeds is 1-(1-p)^n |
| 21:58 |
proller |
if big intervals ->chance=1 |
| 21:58 |
kahrl |
that should be 1-P |
| 21:58 |
sapier1 |
after exiting game menu should be changed too |
| 21:58 |
nore |
you run the game, exit to menu, change TP, re-run game |
| 21:58 |
kahrl |
P( |
| 21:58 |
kahrl |
P* |
| 21:59 |
nore |
textures have not changed |
| 21:59 |
kahrl |
right now it calculates P = 1 / ((1/p) / n) = n*p |
| 21:59 |
proller |
kahrl, stooop 8) |
| 21:59 |
sapier1 |
sorry don't have an instant answer you'll have to investigate |
| 22:00 |
nore |
what is that MutexedMap class? |
| 22:00 |
nore |
looks like it is used as a cache too |
| 22:00 |
sapier1 |
never heared about that one |
| 22:00 |
kahrl |
sapier1, nore: is g_texturename_to_path_cache ever cleared? |
| 22:01 |
nore |
I don't know, I cleared cache/media, but it looks like that should be cleared (and it is probably the origin of the bug) |
| 22:01 |
sapier1 |
I'd expected everything to be cleared after game exits but that's an assumption |
| 22:02 |
nore |
cache/media is not cleared |
| 22:02 |
nore |
I must go |
| 22:02 |
nore |
bbl |
| 22:03 |
sapier1 |
yes but it uses hashes to decide if update is required |
| 22:08 |
|
sapier1 left #minetest-dev |
| 22:12 |
hmmmm |
ack |
| 22:13 |
hmmmm |
celeron, good point i guess, the proper way to fix this would be to serialize the bulk serialization version as well and use that |
| 22:13 |
hmmmm |
but I don't see anything wrong with simply hardcoding 25 |
| 22:14 |
hmmmm |
i don't think i was really paying attention when i put that there |
| 22:16 |
|
Taoki[laptop] joined #minetest-dev |
| 22:30 |
PilzAdam |
hmmmm, https://github.com/PilzAdam/minetest/commit/4ec5185ed24b6c2c17d77595ee885fe60093a247 |
| 22:32 |
hmmmm |
aww... |
| 22:32 |
hmmmm |
i feared someone would try to add something like this |
| 22:33 |
hmmmm |
could you please just add multiple ore definitions instead? |
| 22:33 |
PilzAdam |
no |
| 22:33 |
PilzAdam |
they have different seeds then |
| 22:33 |
PilzAdam |
I want to generate gravel as ore in dirt_with_grass and dirt |
| 22:33 |
PilzAdam |
(not in minetest_game) |
| 22:33 |
hmmmm |
then how about adding an ore flag to share the same seed or something |
| 22:33 |
PilzAdam |
why dont you like the wherein list? |
| 22:34 |
hmmmm |
because it's inside of a speed critical loop |
| 22:35 |
hmmmm |
and this is such a rare case |
| 22:35 |
PilzAdam |
the average case is wherein.size()=1, is it really that slow then? |
| 22:37 |
hmmmm |
could you at least fix up the brace style and so on then? |
| 22:37 |
hmmmm |
also what's with the return statement on 96 |
| 22:38 |
PilzAdam |
if the oredef is invalid then wherein is just set to AIR, not need to loop through the others then |
| 22:39 |
hmmmm |
oh, that's true |
| 22:42 |
PilzAdam |
fixed the brace style: https://github.com/PilzAdam/minetest/commit/32ea9ece297fea8b89288d619fc8ae85d76ff4ac |
| 22:45 |
hmmmm |
line 101, the { would be on the previous line |
| 22:45 |
hmmmm |
line 164, you have all the operators clunked together |
| 22:45 |
hmmmm |
if(lua_istable( on line luaapi.cpp:684 |
| 22:45 |
hmmmm |
other than that it's good |
| 22:47 |
PilzAdam |
whats wrong with line 684? |
| 22:48 |
hmmmm |
no space after 'if' |
| 22:49 |
PilzAdam |
is it actually part of our code style guidelines to put a space there? |
| 22:49 |
hmmmm |
yes... |
| 22:49 |
hmmmm |
if isn't like some sort of function, it's a control statement |
| 22:50 |
hmmmm |
the reason why you don't see me constantly yelling about that is because that particular style is present in code everywhere else, but not really new code (like mapgen or emergemanager or so on) |
| 22:50 |
hmmmm |
so, you could use that style if it fits in with what's already there, but in general don't |
| 22:50 |
hmmmm |
like i said, follow the linux kernel code style |
| 23:01 |
proller |
astyle --style=attach --indent=tab --keep-one-line-blocks --keep-one-line-statements --indent-classes --pad-oper *.cpp *.h |
| 23:02 |
proller |
kill all human! |
| 23:03 |
VanessaE |
Who do you think you are? Bender? :) |
| 23:04 |
PilzAdam |
hmmmm, is a "biomes" field in oredef planned? |
| 23:22 |
|
BlockMen joined #minetest-dev |
| 23:24 |
hmmmm |
pilzadam, actually, yes |
| 23:40 |
BlockMen |
ok, i have rly no idea why the ingame formspecs have no label in my builds (and fess's too). i have tried different versions of gettext, freetype and irrlicht |
| 23:40 |
BlockMen |
always same result... |
| 23:40 |
BlockMen |
so if anyone has an idea, let me know plz |
| 23:40 |
PilzAdam |
since when do fess's builds have this problem? |
| 23:41 |
BlockMen |
https://forum.minetest.net/viewtopic.php?id=6769 |
