| Time |
Nick |
Message |
| 02:48 |
|
celeron55_ joined #minetest-dev |
| 03:26 |
hmmmm |
heh, terrain looks a little bit cooler with mgv6_np_terrain_higher.offset = 40 instead of 20 |
| 03:31 |
hmmmm |
what do i name this commit.... |
| 03:34 |
hmmmm |
alright so i totally cleaned up that hack to make the mapgen name a string in that last commit. i have a new arbitrary factory class thing going on, but new mapgens need to do some additional work now; define a factory class derived from MapgenFactory that will return a new instance of a Mapgen and a new instance of a MapgenParams |
| 03:34 |
hmmmm |
https://github.com/kwolekr/minetest/commit/ecd99ae6f49720da9eb58937a964bf5cad9837d2 |
| 03:34 |
hmmmm |
and ServerMap gets the EmergeManager on construction (again) |
| 03:36 |
hmmmm |
the only thing mapgen makers have to modify outside of their own source files now is mapgen.cpp, EmergeManager's ctor, they just add a registerMapgen("mapgen_name_here", new MapgenFactoryHere()); |
| 03:37 |
hmmmm |
if we ever get to the point where .dlls and .sos are loaded, i can export EmergeManager::registerMapgen(), and they just call that |
| 03:38 |
hmmmm |
of course i'll document ALL of this in due time |
| 03:46 |
|
kahrl joined #minetest-dev |
| 06:22 |
darkrose |
urgh, what idiot decided right clicking was a good way to open a door? |
| 06:35 |
hmmmm |
someone who wanted to be able to mine them out easily |
| 07:05 |
hmmmm |
sfan5: https://github.com/kwolekr/minetest/commit/dcd2047b08589353e52d9cdabcc8d039697f3def |
| 07:05 |
hmmmm |
shoot i left in an unused variable |
| 07:22 |
hmmmm |
https://github.com/kwolekr/minetest/commit/819dd7723ca0357dedbf67fe3cd5ba5c648c11a6 |
| 08:50 |
celeron55_ |
thexyz: the translation template file should be updated using the updatepo.sh script or whatever it was |
| 08:50 |
celeron55_ |
thexyz: also, i gave access to https://github.com/minetest |
| 08:59 |
celeron55_ |
< hmmmm> damn how do you even break this up into two lines <- typedef, man |
| 10:00 |
celeron55_ |
i quite like how the trees look in these: http://forum.minetest.net/viewtopic.php?pid=65416#p65416 http://forum.minetest.net/viewtopic.php?pid=65436#p65436 |
| 10:00 |
celeron55_ |
that is a good size |
| 10:00 |
celeron55_ |
or, well, a good varation of sizes |
| 10:20 |
|
rsiska joined #minetest-dev |
| 14:22 |
|
darkrose joined #minetest-dev |
| 14:22 |
|
darkrose joined #minetest-dev |
| 14:32 |
|
hmmmm joined #minetest-dev |
| 14:32 |
RealBadAngel |
hi all |
| 14:33 |
RealBadAngel |
celeron55, youre comparing those screenshots in this topic to l-system trees or what? |
| 14:37 |
RealBadAngel |
im asking, because if im not blind, those ARE L-system trees... |
| 14:39 |
RealBadAngel |
you still havent tried them but commenting out some screenshots... |
| 14:39 |
hmmmm |
he likes l-system trees in general, he just thinks that a few of them are too big, but those are well-sized trees |
| 14:39 |
RealBadAngel |
so epic fail |
| 14:40 |
RealBadAngel |
because he just said he likes my models of jungle trees which he said were too big |
| 14:40 |
RealBadAngel |
repeat: he just watches some random screenshot and not tryin how they look ingame |
| 14:41 |
RealBadAngel |
we finally have a proof |
| 14:41 |
hmmmm |
some trees really are huge IRL. |
| 14:41 |
RealBadAngel |
yes, ofc, sequoia avg is 120meters |
| 14:41 |
hmmmm |
i don't judge things by how they look in-game either, it is a lot of hassle to set it up |
| 14:42 |
thexyz |
celeron56 / celeron55_: wtf does that one do and why should it be executed by tool which only changes *.po? |
| 14:42 |
RealBadAngel |
but this was comic indeed |
| 14:42 |
thexyz |
also, we probably should discuss which languages to add |
| 14:42 |
hmmmm |
'comic'? hardly.... |
| 14:42 |
hmmmm |
what's so funy |
| 14:42 |
hmmmm |
funny |
| 14:43 |
RealBadAngel |
on one screenshot it was too big for gameplay, and on another its ok? |
| 14:43 |
hmmmm |
are they the same tree? |
| 14:43 |
RealBadAngel |
i do recognize my models |
| 14:43 |
RealBadAngel |
i wrote them |
| 14:43 |
hmmmm |
well let me be the judge of that.... what are the screenshots we're comparing here exactly |
| 14:44 |
hmmmm |
lemme just look up in the logs |
| 14:44 |
RealBadAngel |
download plantlib/moretrees and check for yourself |
| 14:44 |
hmmmm |
lol i love how the smiley face sheep are humping in the foreground there |
| 14:45 |
hmmmm |
perhaps he didn't realize there was more to the sequoias to the right in the first screenshot. *shrug* |
| 14:46 |
hmmmm |
as for the second screenshot...... those are indeed smaller examples of the l-system trees |
| 14:47 |
RealBadAngel |
there are currently 12 kinds of trees |
| 14:47 |
RealBadAngel |
only one is bigger than old jungle tree |
| 14:48 |
RealBadAngel |
sequoia |
| 14:48 |
hmmmm |
how much bigger? |
| 14:48 |
RealBadAngel |
1/3 or something like that |
| 14:48 |
RealBadAngel |
lookin now a place in the world to make a screenshot |
| 14:48 |
hmmmm |
that's really not that much |
| 14:49 |
hmmmm |
the whole size argument does seem dumb now |
| 14:49 |
RealBadAngel |
btw i posted early today a patch to treegen engine |
| 14:49 |
RealBadAngel |
can some1 check it out? |
| 15:03 |
RealBadAngel |
couldnt find a nice spot for screenshot, so placed some sapling |
| 15:03 |
RealBadAngel |
gonna take a while for them to grow ;) |
| 15:13 |
RealBadAngel |
dont have jungle ones yet, but made one view |
| 15:13 |
RealBadAngel |
http://realbadangel.pl/scr1.png |
| 15:13 |
RealBadAngel |
its actual mapgen creation |
| 15:13 |
hmmmm |
hah i like those palm trees |
| 15:13 |
hmmmm |
they really add a nice feeling |
| 15:14 |
hmmmm |
https://github.com/kwolekr/minetest/commit/7365cae0b053cc9cc5d9f0d85ede34683d5ec243 |
| 15:23 |
|
kahrl_ joined #minetest-dev |
| 15:28 |
RealBadAngel |
hmmm, one thing, since you have moved defalut trees to v6.cpp i think i should remove the leftovers from treegen.cpp |
| 15:28 |
RealBadAngel |
theyre not functional anymore |
| 15:30 |
hmmmm |
leave that to me |
| 15:31 |
hmmmm |
i actually want all tree generation to stay in treegen.cpp, so it'd be much more organized if the copy in the mapgen was removed |
| 15:37 |
RealBadAngel |
http://realbadangel.pl/scr2.png |
| 15:37 |
RealBadAngel |
another nature capture |
| 15:47 |
|
PilzAdam joined #minetest-dev |
| 15:50 |
RealBadAngel |
hmmmm, palms vs the biggest ones: http://realbadangel.pl/scr3.png |
| 15:51 |
RealBadAngel |
hi PilzAdam |
| 15:51 |
PilzAdam |
hi |
| 15:53 |
RealBadAngel |
and palm beach itself |
| 15:54 |
RealBadAngel |
http://realbadangel.pl/scr4.png |
| 15:55 |
RealBadAngel |
PilzAdam, those screenshots i post are actual mapgen generated ones |
| 15:59 |
celeron55_ |
RealBadAngel: so you're not fine with me being fine with the trees? okay, i'll be against them then |
| 15:59 |
RealBadAngel |
hehe, no |
| 15:59 |
celeron55_ |
thexyz: ...i don't even know; how is the translation template updated, then? |
| 16:00 |
RealBadAngel |
i just pointed that once you called them too big, once proper sized |
| 16:00 |
RealBadAngel |
lookin at the very same trees :) |
| 16:00 |
celeron55_ |
thexyz: i think we should use the same policy as openttd uses - include anything that is 90% translated, and exclude everything if they get outdated to under 90% |
| 16:00 |
celeron55_ |
s/exclude everything/exclude anything/ |
| 16:01 |
celeron55_ |
thexyz: because there isn't really a reason to exclude a language as long as it's complete |
| 16:02 |
RealBadAngel |
celeron55_: dont get me wrong please. i was just laughin :) |
| 16:02 |
RealBadAngel |
and i really think you shall try to play with them |
| 16:03 |
RealBadAngel |
when we made them generated on mapgen, world is just marvellous |
| 16:04 |
RealBadAngel |
you really feel youre going somwhere now |
| 16:04 |
RealBadAngel |
before there was almost no point to move and explore because world was the same whenever you went |
| 16:05 |
RealBadAngel |
when played at server only point to explore was to find clay |
| 16:06 |
RealBadAngel |
nothin more |
| 16:10 |
|
Jeija joined #minetest-dev |
| 16:13 |
Jeija |
I want to send a command to all clients straight from the scriptapi (spawn particle). Sending the command from the server e.g. on an event works, but what is the recommended way to make the scriptapi trigger the command? |
| 16:13 |
celeron55_ |
see the code that launches a custom formspec |
| 16:13 |
celeron55_ |
just add a method to Server and add a wrapper to scriptapi.cpp |
| 16:14 |
Jeija |
thank you, didn't think of that, the formspec code is was I was looking for |
| 16:14 |
celeron55_ |
(scriptapi.cpp should really be only wrappers, and all real functionality should be accessible via C++ interfaces so the core can use them all too) |
| 16:17 |
thexyz |
celeron55_: i don't get it, why should it be updated when translation is changed? |
| 16:17 |
celeron55_ |
thexyz: where do the translation services get the strings they give for users to translate? |
| 16:17 |
celeron55_ |
if i edit C++ code, how do they get the new original string |
| 16:18 |
thexyz |
source = msgid, translation = msgstr |
| 16:18 |
thexyz |
well, i don't think that should be done by translation service (and afaik, weblate can't do that) |
| 16:19 |
celeron55_ |
...but how does the mapping get done? |
| 16:19 |
thexyz |
what mapping? |
| 16:19 |
celeron55_ |
to my understanding something can generate the translation template file, .pot |
| 16:19 |
celeron55_ |
and such service will read the pot |
| 16:19 |
celeron55_ |
and generate .po files based on it |
| 16:19 |
celeron55_ |
the .pot is never edited by hand, but rather gettext automatically can generate it from C++ |
| 16:20 |
celeron55_ |
in some way; and i am wondering what that way is |
| 16:21 |
|
kahrl joined #minetest-dev |
| 16:21 |
celeron55_ |
yes, it happens in updatepo.sh |
| 16:21 |
celeron55_ |
xgettext --package-name=minetest -kN_ -kwgettext -F -n -o $potfile src/*.cpp src/*.h |
| 16:21 |
thexyz |
there's also another problem, regarding your suggestion >include anything that is 90% translated, and exclude everything if they get outdated to under 90 |
| 16:21 |
celeron55_ |
and then it updates the .po files based on it |
| 16:21 |
hmmmm |
by the way, did you check out the commit to fix the mapgen name string hack |
| 16:21 |
celeron55_ |
for what has changed |
| 16:21 |
thexyz |
weblate is only able to work with .po's that are in the repo |
| 16:22 |
thexyz |
hm.. well, it can merge with git repo |
| 16:22 |
celeron55_ |
launchpad eats the .pot and produces any languages from it |
| 16:22 |
celeron55_ |
in any case i'll run updatepo.sh now and commit the changes, so we are getting new translations in any case |
| 16:23 |
thexyz |
ok |
| 16:23 |
celeron55_ |
a lot has changes since it was last run |
| 16:23 |
celeron55_ |
changed* |
| 16:24 |
thexyz |
i think we can translate using weblate and then run updaterepo.sh by hand from time to time |
| 16:24 |
thexyz |
and to support more languages firstly we have to add empty .po's |
| 16:25 |
celeron55_ |
there should be some place to request .pos for new languages |
| 16:25 |
thexyz |
i think it may be a good idea to put some kind of poll for that |
| 16:25 |
celeron55_ |
add a thread on forum and link to it from weblate? |
| 16:25 |
thexyz |
and then add empty po's for most popular languages |
| 16:25 |
thexyz |
probably |
| 16:25 |
celeron55_ |
well, people should request on the thread only if they are ready to translate a lot |
| 16:27 |
celeron55_ |
.pot and existing .po files have now been updated |
| 16:27 |
thexyz |
ok |
| 16:27 |
thexyz |
yes, sure |
| 16:28 |
celeron55_ |
much seems to be the same, but there are many new messages |
| 16:31 |
celeron55_ |
hmmmm: no, maybe add a pull request or something so it isn't forgotten |
| 16:32 |
celeron55_ |
or, well, link it now and maybe i will have time to immediately check it |
| 16:32 |
celeron55_ |
a pull request is generally the best idea though |
| 16:34 |
thexyz |
celeron55_: does that look fine http://bpaste.net/show/TVBPGbelSFBru9skchUD/ ? |
| 16:34 |
celeron55_ |
depends on what the content is |
| 16:35 |
celeron55_ |
if it basically reverts it to the point where it was before the update, then it's so wrong you should cry |
| 16:35 |
celeron55_ |
8) |
| 16:38 |
hmmmm |
Jeija.... https://github.com/Jeija/minetest/commit/45c48f79652e92a2f31aa0569ebb20cfc2cf6699#L3R465 %z is a glibc-ism and should be entirely avoided. |
| 16:38 |
hmmmm |
it's an invalid format specifier with anything other than gcc. |
| 16:39 |
celeron55_ |
thexyz: probably the best way to make sure all is right is to run updatepo.sh on top of that, then commit, and then squash them to one that will surely end up being a clean update |
| 16:39 |
celeron55_ |
...or something like that |
| 16:40 |
celeron55_ |
hmmmm: related to that: also, the %ll and whatever are different sizes on 64bit vs. 32bit and might even differ in different compilers; there are some macros for proper compatibility |
| 16:42 |
celeron55_ |
(of course, if actually long long is used, then %ll is right; but it isn't right for int64_t or so) |
| 16:42 |
hmmmm |
what? %ll is fine for int64 |
| 16:43 |
hmmmm |
long long is at least 64 bits |
| 16:43 |
|
Calinou joined #minetest-dev |
| 16:43 |
thexyz |
oh, well, the only change that was made by Calinou is not needed in latest git so I decided to reset the local repo |
| 16:43 |
celeron55_ |
ehm... well, SOME of the printf things have that problem |
| 16:43 |
thexyz |
seems everything went fine |
| 16:43 |
Calinou |
thexyz: what change? |
| 16:44 |
hmmmm |
as far as C++ is concerned, you use %ll in a format specifier, you better pass a long long int. or else problems may happen. |
| 16:44 |
Calinou |
talking about changes, can my glitch ladder fix be merged please? |
| 16:44 |
thexyz |
Calinou: translation |
| 16:44 |
Calinou |
ah |
| 16:44 |
Calinou |
I was testing ;-) |
| 16:44 |
celeron55_ |
here's such a fix in musicd: https://github.com/Kray/musicd/commit/3308701c09beddff38c1ac0026a7becb4cba8df0 |
| 16:45 |
celeron55_ |
hmm, i wonder what the original problem in that has been |
| 16:45 |
hmmmm |
you have no idea unless you look at the definition of track, really |
| 16:46 |
celeron55_ |
https://github.com/Kray/musicd/blob/3308701c09beddff38c1ac0026a7becb4cba8df0/src/track.h |
| 16:46 |
hmmmm |
this wins the shitty code award of the month size = pow(2, ceil(log(size)/log(2))); |
| 16:48 |
hmmmm |
well if you notice the commit topic he says he replaces "ld li and lu", not "lld lli and llu" |
| 16:48 |
celeron55_ |
(that is an invalid argument unless you provide with a replacement that is less shitty) |
| 16:49 |
celeron55_ |
hmm so you're saying that that fix could have been as well just using ll instead of l in all of those |
| 16:49 |
celeron55_ |
do all compilers support ll? |
| 16:49 |
celeron55_ |
or, well, standard libraries |
| 16:49 |
hmmmm |
yes. |
| 16:49 |
hmmmm |
it's STANDARD C |
| 16:49 |
hmmmm |
if something doesn't support ll then it's defective |
| 16:50 |
celeron55_ |
something being defective doesn't mean you wouldn't have to support it |
| 16:51 |
celeron55_ |
i asked about that elsewhere, i'll mention here if the answer is useful |
| 16:51 |
hmmmm |
of course, but when something's defective, you don't bend over backwards for it because it's junk |
| 16:52 |
hmmmm |
i used to do handstands for windows support for my own programs |
| 16:52 |
celeron55_ |
if it's gcc, mingw, llvm of msvc, minetest will bend 720 degrees to handle it 8) |
| 16:52 |
hmmmm |
it's ridiculous at times though |
| 16:53 |
celeron55_ |
it's one of the policies i won't change, until windows has less than 20% of market share |
| 16:53 |
celeron55_ |
then i promise all windows support will be dumped like it was never there |
| 16:56 |
hmmmm |
well windows is pretty bad but it could be worse, so what i said wouldn't really apply here |
| 16:56 |
hmmmm |
especially since windows support is already here and excellent |
| 16:57 |
|
Kray joined #minetest-dev |
| 16:58 |
Calinou |
"until windows has less than 20% of market share" <= did you count mobile devices? :P |
| 16:59 |
celeron55_ |
http://stackoverflow.com/questions/5140871/sprintf-for-unsigned-int64 |
| 16:59 |
celeron55_ |
seems to be pretty messed up |
| 17:00 |
celeron55_ |
Calinou: minetest runs only on desktop, so desktop OSes |
| 17:01 |
celeron55_ |
everybody keeps saying that %l is 64bit on 64bit, but nobody says if %ll is 64bit or not |
| 17:01 |
celeron55_ |
it could be 128 on something, but... |
| 17:01 |
hmmmm |
doesn't matter if it's 128 or not, it's "at least 64" which is what you need |
| 17:01 |
celeron55_ |
"You need to use %I64u with Visual C++" sounds like fun, and sounds like going in hand with MSVC not supporting C99 |
| 17:02 |
hmmmm |
%l is 32 bit on 64 bit windows |
| 17:02 |
hmmmm |
you can still use %ll in windows, no need for I64u |
| 17:02 |
hmmmm |
PRIu64 is part of C99 though, so we should probably use that. |
| 17:05 |
hmmmm |
of course.. inttypes.h is not available on windows |
| 17:06 |
celeron55_ |
i wonder why windows hasn't already been sued to death because of harming programmer's health |
| 17:07 |
hmmmm |
it's not too bad, what you need to do is #ifdef _MSC_VER #define PRIu64 "%I64u" #define PRId64 "%I64" #else #include <inttypes.h> #endif |
| 17:09 |
hmmmm |
by the way, i don't know if anybody pointed this out to you before or not, but the # in preprocessor needs to be the first character of the line as per the C standard, it's technically invalid if it's been indented. |
| 17:09 |
hmmmm |
i don't know of any compiler that strictly follows those rules, however, and you already indented the hashtag, so I followed suit |
| 17:09 |
celeron55_ |
i don't think any of the compilers we support has problems with that |
| 17:09 |
darkrose |
http://code.google.com/p/msinttypes/ <- could be useful |
| 17:11 |
celeron55_ |
we don't need even 2% of that, but could be a reliable source for checking things are done right |
| 17:24 |
RealBadAngel |
i made some fried apple pan cakes |
| 17:24 |
RealBadAngel |
anybody want some? :) |
| 17:25 |
hmmmm |
no |
| 17:26 |
RealBadAngel |
theyre tasty, believe me :) |
| 17:27 |
sfan5 |
i would like a faster computer to compile linux 3.8-rc4 |
| 17:27 |
RealBadAngel |
hehehe |
| 17:28 |
sfan5 |
i just want to try out f2fs :( |
| 17:28 |
RealBadAngel |
i afraid i cant make one out of just flower, milk, eggs, sugar and apples ;) |
| 17:29 |
thexyz |
oh, please, →#minetest |
| 17:29 |
RealBadAngel |
slight oftopic, sorry |
| 17:29 |
hmmmm |
sfan |
| 17:29 |
hmmmm |
did you see my patch for you |
| 17:30 |
RealBadAngel |
hmmm, have you moved also caves to another file? |
| 17:30 |
hmmmm |
no |
| 17:30 |
RealBadAngel |
uff, i got patch for them |
| 17:31 |
RealBadAngel |
based on your avg height idea, but just more points to get it (you know where) |
| 17:34 |
hmmmm |
i didn't want to continue using that method |
| 17:34 |
hmmmm |
it fixes things to an extent but it doesn't solve the core problem |
| 17:36 |
RealBadAngel |
have any better idea to make cavegen stop to generate caves on any height? |
| 17:37 |
RealBadAngel |
by now you can go at y=30000 and theyre still there generating |
| 17:37 |
celeron55_ |
it's still not really about the height, it's about what it replaces :P but if it's the one that disables them above the maximum of a chunk, it's acceptable (until we have floating islands, which again makes it unusable) |
| 17:38 |
celeron55_ |
(because you want occasional caves in them too) |
| 17:39 |
RealBadAngel |
so maybe simply let caves replace only basic nodes |
| 17:39 |
RealBadAngel |
like stones, sand, etc |
| 17:39 |
hmmmm |
that already happens |
| 17:39 |
hmmmm |
but the problem is the overlapping bits |
| 17:39 |
RealBadAngel |
but they do destroy everything |
| 17:40 |
RealBadAngel |
all stuff generated with mapgen |
| 17:41 |
RealBadAngel |
and this is not makin world look any better. it looks ugly |
| 17:41 |
celeron55_ |
i have already said this, but will say again: the right solution currently is to disable the cave generator in places that both 1. are generally on top of the ground and 2. are inside the xz borders of the not-yet-fully-generated area |
| 17:42 |
celeron55_ |
because that is where the trees get busted |
| 17:42 |
celeron55_ |
eh, s/inside/outside/ |
| 17:42 |
RealBadAngel |
avg height was supposed to solve 1. |
| 17:43 |
celeron55_ |
the caves need to only be disabled if 1 && 2 |
| 17:43 |
celeron55_ |
certain features of the world depend on caves getting generated if 1 and !2, or if !1 and 2 |
| 17:44 |
RealBadAngel |
but they do generate inside trees. removing they trunks, cut holes in leaves, placin there blobs |
| 17:44 |
celeron55_ |
are you aware that limiting the caves by the maximum of a chunk does not get rid of all of the tree chopping? |
| 17:44 |
celeron55_ |
we really have two problems in here |
| 17:45 |
celeron55_ |
one is chopping of trees, one is caves going far above the ground |
| 17:45 |
RealBadAngel |
i already posted onve patch that solved all the issues |
| 17:45 |
RealBadAngel |
all of them |
| 17:45 |
celeron55_ |
yeah sure, disabling caves gets rid of all cave problems |
| 17:45 |
celeron55_ |
it's not a solution |
| 17:45 |
RealBadAngel |
no, they were still there |
| 17:45 |
RealBadAngel |
even was makin holes in the ground or cliffs |
| 17:46 |
* celeron55_ |
will not argue this same discussion again |
| 17:46 |
RealBadAngel |
i will try to make that code even better and post it again |
| 17:47 |
celeron55_ |
don't overwork on it unless you know it's going to be good; wasted coding isn't fun |
| 17:48 |
RealBadAngel |
those are not big changes |
| 17:48 |
RealBadAngel |
just bunch of skip conditions in right place |
| 17:50 |
RealBadAngel |
btw i will apply seed changes to trees with next patch |
| 17:51 |
PilzAdam |
why not in the current patch? |
| 17:51 |
RealBadAngel |
because this one was ready 1 week ago |
| 17:51 |
RealBadAngel |
and wasnt posted before it was tested |
| 17:52 |
RealBadAngel |
ive changed style of pushin. |
| 17:52 |
RealBadAngel |
im not pushing anything before im not 100% sure its ok |
| 17:53 |
PilzAdam |
you still dont use branches? |
| 17:53 |
RealBadAngel |
of course i do |
| 17:53 |
RealBadAngel |
but not using github |
| 17:53 |
|
doserj joined #minetest-dev |
| 17:54 |
celeron55_ |
has somebody tested these? https://github.com/celeron55/minetest/pull/436 |
| 17:54 |
celeron55_ |
other than this guy who just joined 8) |
| 17:54 |
RealBadAngel |
lol |
| 17:54 |
doserj |
heh |
| 17:55 |
PilzAdam |
celeron55_, ive tested the first 3 commits |
| 17:55 |
celeron55_ |
hmm, i think the fourth might be not good |
| 17:56 |
celeron55_ |
consider this: you launch minetest, edit and save config, shut down minetest |
| 17:56 |
celeron55_ |
edit = add an option |
| 17:56 |
celeron55_ |
currently, changed configuration is just changed in there and you addition stays intact |
| 17:56 |
celeron55_ |
after that patch, your addition will be removed; as far as i understand |
| 17:57 |
RealBadAngel |
celeron55_, we have talked once bout mapgen spikes, you remeber? |
| 17:57 |
doserj |
celeron55_: i currently also removes it if you happen to change a different one |
| 17:57 |
RealBadAngel |
http://realbadangel.pl/spike.png |
| 17:57 |
RealBadAngel |
one example of those |
| 17:57 |
celeron55_ |
RealBadAngel: as if i hadn't seen them; talk to hmmmm or somebody; i can't and won't handle everything |
| 17:58 |
RealBadAngel |
i know, but such spike looks just ugly |
| 17:58 |
celeron55_ |
(the spikes are a real bitch in v6 if you try to tune it to do something different) |
| 17:59 |
RealBadAngel |
is it perlin bug? |
| 17:59 |
celeron55_ |
it is not a bug, it is a glitch |
| 17:59 |
celeron55_ |
doserj: umm? |
| 18:07 |
doserj |
celeron55_: it would only keep your addition if you didn't change some setting in minetest |
| 18:08 |
|
iqualfragile joined #minetest-dev |
| 18:08 |
doserj |
or did i read that code wrong? |
| 18:08 |
celeron55_ |
so it does already overwrite the whole file out of memory if it updates something? |
| 18:08 |
celeron55_ |
hmm, well then your commit is fine i guess |
| 18:11 |
doserj |
celeron55_: it keeps most of the file intact, like comments, etc, but it only keeps actual settings in the file, if those are also in m_settings. |
| 18:11 |
celeron55_ |
merged thoes ones |
| 18:11 |
celeron55_ |
those* |
| 18:11 |
celeron55_ |
doserj: can't remember everything; it was one of the first things i wrote in this whole project 8) |
| 18:11 |
doserj |
if you are in a mood to merge stuff: https://github.com/celeron55/minetest/pull/439 |
| 18:11 |
doserj |
celeron55_: np |
| 18:12 |
doserj |
:P |
| 18:13 |
|
SpeedProg joined #minetest-dev |
| 18:14 |
celeron55_ |
have you tested for liquid-liquid and liquid-glass and liquid-leaf glitches? |
| 18:17 |
doserj |
it doesn't draw faces for liquid-liquid, it does draw for liquid-glass |
| 18:17 |
celeron55_ |
does it introduce any changes regarding to those? |
| 18:18 |
celeron55_ |
i don't care if there are no changes, but a change could be either good or bad |
| 18:21 |
doserj |
i didn't change anything for that. basic check was (and still is) draw a face if !same_liquid && !(solidness == 2) |
| 18:22 |
iqualfragile |
can someone explain the mapgen-thing to me? what hammened? |
| 18:22 |
doserj |
except for top-sides, which are also drawn if the top neighbor is solid |
| 18:23 |
doserj |
(still, as before) |
| 18:24 |
celeron55_ |
thexyz: i linked http://translate.minetest.ru/projects/minetest/core/ on dev.minetest.net |
| 18:24 |
thexyz |
fine, now we need some forum thread |
| 18:25 |
celeron55_ |
more specifically, here http://dev.minetest.net/Translation |
| 18:25 |
|
SpeedProg1 joined #minetest-dev |
| 18:28 |
doserj |
celeron55_: but wait, there may be an issue |
| 18:55 |
celeron55_ |
https://github.com/celeron55/minetest/pull/426 |
| 18:55 |
celeron55_ |
^ this'll have to wait until i have time for a thorough check |
| 18:55 |
celeron55_ |
modifying on-disk map format is a bitch if something goes wrong 8) |
| 18:56 |
doserj |
yeah |
| 18:57 |
Calinou |
new comment just now ;-) |
| 18:59 |
|
rsiska joined #minetest-dev |
| 18:59 |
doserj |
celeron55_: there seem to be quite some things to work out for liquid faces. for example, liquid sources currently don't draw interiour faces against glass, but they do draw the exterior ones. my patch for flowing liquids draws interior faces exactly when the exterior face is drawn. |
| 19:00 |
celeron55_ |
umm... what is an inferior and exterior face? |
| 19:00 |
celeron55_ |
...interior |
| 19:00 |
doserj |
interior is what you see when the camera is inside the node, looking outwards |
| 19:01 |
celeron55_ |
ah... well, you'll immedialy run into z fighting problems if you try to draw the interior face that touches glass behind it |
| 19:02 |
celeron55_ |
basically you need to choose which one, and the glass is the important one in that case |
| 19:03 |
celeron55_ |
-> interior faces should be drawn only when facing air |
| 19:03 |
doserj |
ok, i will have to change my patch then for flowing liquids |
| 19:04 |
doserj |
well, air and things like signs, torches, etc |
| 19:04 |
celeron55_ |
there probably are some fancy ways of doing that (at least with shaders), but they are probably out of scope of this patch |
| 19:04 |
celeron55_ |
yes... umm... whatever the term for that would be |
| 19:04 |
doserj |
not quite related: what is the intended status of new_style_water? |
| 19:05 |
celeron55_ |
things that mostly contain air at their node boundaries |
| 19:05 |
|
rsiska joined #minetest-dev |
| 19:05 |
celeron55_ |
it's to be removed and the thing done in shaders is to be moved to a mesh generation post processing stage |
| 19:06 |
celeron55_ |
somehow |
| 19:06 |
celeron55_ |
well, that's a plan - i'm not 100% sure it's viable |
| 19:06 |
celeron55_ |
should be |
| 19:07 |
celeron55_ |
point is, we want (at least i want) that water source surfaces use the smooth lighting and simple tessellation that regular node surfaces have |
| 19:07 |
|
rsiska joined #minetest-dev |
| 19:08 |
celeron55_ |
so the main surface should come from from where regular node surfaces come, but it should be postprocessed to be lower where applicable |
| 19:09 |
doserj |
ah, makes sense |
| 19:09 |
|
rsiska joined #minetest-dev |
| 19:09 |
celeron55_ |
so it would be a bit like this in here https://github.com/celeron55/minetest/blob/master/src/mapblock_mesh.cpp#L1090 |
| 19:11 |
|
rsiska joined #minetest-dev |
| 19:12 |
celeron55_ |
probably a flag needs to be added to this list, like MATERIAL_FLAG_WATER_TO_BE_LOWERED: https://github.com/celeron55/minetest/blob/master/src/tile.h#L169 |
| 19:12 |
celeron55_ |
s/WATER/LIQUID/ |
| 19:12 |
celeron55_ |
or... something |
| 19:12 |
celeron55_ |
the data path is there, it just needs to be put to use |
| 19:13 |
celeron55_ |
(that is a good starting point in this large a codebase...) |
| 19:13 |
celeron55_ |
of course, feel free to find out it's not doable and find some other solution 8) |
| 19:32 |
thexyz |
celeron55_: german translation is completed, ># Your branch is ahead of 'origin/master' by 9 commits.; will you bitch about number of commits? ^^ |
| 19:34 |
thexyz |
the problem with rebasing is that those commits are made by different people |
| 19:34 |
thexyz |
squashing^ |
| 19:36 |
PilzAdam |
thexyz, maybe mention the authors in the commit message |
| 19:38 |
thexyz |
dunno, i'm not sure whether squashing will break something or not |
| 19:38 |
thexyz |
so i'd better just push what is here |
| 19:55 |
doserj |
celeron55_: one more thing: liquid sources currently don't draw any face against liquid sources of a different liquid. my patch does draw these faces for flowing liquids. |
| 19:57 |
celeron55_ |
liquid sources are generically handled as solidness=1, right? |
| 19:57 |
doserj |
liquid sources are handled in makes_face(), depending on difference in solidness and visual_solidness. flowing liquids are handles in mapblock_mesh_generate_special() |
| 19:58 |
doserj |
yes |
| 19:58 |
celeron55_ |
i think there is a comment about this case in there |
| 19:59 |
doserj |
this:TODO: Add 3: Both faces drawn with backface culling, remove equivalent ? |
| 19:59 |
celeron55_ |
ah, the comment is at... yes, that one |
| 20:01 |
celeron55_ |
maybe that should happen when two different (that are also different liquid) solidness=1 nodes make a face in between (that is, there would be two faces, so that from each liquid you will see the other liquid at the face) |
| 20:03 |
celeron55_ |
it's a bit laborous to implement; getTileInfo's handling of face_contents has to be extended, as well as getTileInfo's interface, as well as updateFastFaceRow that uses getTileInfo |
| 20:03 |
celeron55_ |
and it has to be fast |
| 20:04 |
|
Jeija left #minetest-dev |
| 20:04 |
doserj |
to start with: if (contentDiffers && f1.solidness == 1 && f2.solidness == 1) return 3; |
| 20:04 |
doserj |
in makes_face()? |
| 20:05 |
celeron55_ |
you mean face_contents? |
| 20:05 |
doserj |
erm, yes |
| 20:06 |
celeron55_ |
i guess something like that (dunno about visual_solidness; it's handling will probably have something to do with flowing liquids (they are solidness=0, visual_solidness=1 IIRC)) |
| 20:07 |
celeron55_ |
if they are so, they should work out fine with that logic |
| 20:07 |
celeron55_ |
...maybe |
| 20:08 |
doserj |
solidness=0, visual_solidness=0 for flowing liquids. |
| 20:08 |
doserj |
visual_solidness=1 for glass and leaves |
| 20:09 |
celeron55_ |
hmm, i wonder why it is so |
| 20:09 |
celeron55_ |
well, better not fiddle with that, there is likely a reason |
| 20:10 |
celeron55_ |
that probably has something to do with some face-making priorities |
| 20:11 |
doserj |
face_contents basically says draw the face with the bigger solidness |
| 20:11 |
celeron55_ |
it's funny how everything starts seeming like sheets of paper instead of solid cubes when you think these things 8) |
| 20:12 |
celeron55_ |
yes; originally it did just that |
| 20:12 |
celeron55_ |
then it has bloated up a bit |
| 20:12 |
doserj |
and then adds some special cases |
| 20:19 |
hmmmm |
the spikes thing... that's a big WONTFIX |
| 20:20 |
hmmmm |
it's hard to prevent and the occurance of them is rare, some people might even find them interesting |
| 20:20 |
hmmmm |
sorry RBA |
| 20:20 |
celeron55_ |
more like CANTFIX, with the clause: one is free to try, but it will likely only cause his head to explode |
| 20:21 |
celeron55_ |
hmmmm: they're a PITA if you want to try to make v6 to make large mountains - but it isn't designed for that anyway |
| 20:21 |
hmmmm |
celeron, if you'd like v6 to make large mountains it's as easy as modifying the offset and scale of terrain_higher |
| 20:21 |
hmmmm |
i've tried it before and i must say the results are neat |
| 20:21 |
celeron55_ |
i tried it for multiple hours and i must say nope |
| 20:22 |
hmmmm |
what, tried different settings? |
| 20:22 |
celeron55_ |
you did try to also make them very wide? |
| 20:22 |
hmmmm |
no |
| 20:22 |
celeron55_ |
different parameters, those stored in map_meta.txt |
| 20:22 |
celeron55_ |
i tried to make that happen too |
| 20:22 |
hmmmm |
you didn't like the results? |
| 20:22 |
hmmmm |
i thought it was cool. |
| 20:22 |
celeron55_ |
it just doesn't work; every large wide mountainy mountain ends up having spikes on top of it 8) |
| 20:23 |
celeron55_ |
or on the sides of it |
| 20:23 |
hmmmm |
oh yeah |
| 20:23 |
celeron55_ |
depends of things |
| 20:23 |
hmmmm |
i know what you mean there |
| 20:23 |
hmmmm |
i've seen that |
| 20:23 |
hmmmm |
in order to fix that i think you'd have to modify the noise for the steepness |
| 20:23 |
celeron55_ |
the steepness factor and the level selector noises are really hard to control |
| 20:24 |
celeron55_ |
really we'd need a generator that allows modifying the parameters of a noise with other noises |
| 20:24 |
hmmmm |
inception |
| 20:24 |
celeron55_ |
it's how the generator of Ternadim works |
| 20:24 |
celeron55_ |
and how some 0.2 minetest worked |
| 20:24 |
hmmmm |
never heard of Ternadim |
| 20:25 |
celeron55_ |
i'm getting you a screenshot if my connection permits |
| 20:25 |
hmmmm |
you have DSL... how bad can it be? |
| 20:25 |
celeron55_ |
very bad |
| 20:25 |
hmmmm |
:/ |
| 20:25 |
celeron55_ |
http://i.imgur.com/fhMq5.jpg |
| 20:25 |
celeron55_ |
a bit old, but anyways |
| 20:25 |
hmmmm |
this is 0.2 minetest or ternadim? |
| 20:26 |
doserj |
ok, pushed an update for the interior faces of flowing liquids. faces between liquid sources of different kinds will have to wait (at least until tomorrow). |
| 20:26 |
celeron55_ |
ternadim |
| 20:26 |
celeron55_ |
it's an in-development RTS game by me |
| 20:26 |
hmmmm |
which noise parameters have you actually modified with noise? |
| 20:26 |
thexyz |
celeron55_: will you comment on that translating issue? |
| 20:26 |
celeron55_ |
glorious closed source |
| 20:27 |
hmmmm |
ahh this is the simpler game you were talking about |
| 20:27 |
celeron55_ |
hmmmm: it's useful to modify at least the persitence |
| 20:27 |
celeron55_ |
offset may be too, to get some very large or very small scale variation on top of some middleway octaves |
| 20:28 |
hmmmm |
that's useful |
| 20:28 |
hmmmm |
i'm going to have something like that for v7 |
| 20:29 |
celeron55_ |
really locking to "octaves" is an arbitrary limitation too - the difference in the used noise scales applied together to form perlin noise could be anything instead of 2x |
| 20:29 |
hmmmm |
i think it'll definitely reduce the "seen it before" factor one experiences when generating new land in minetest |
| 20:29 |
celeron55_ |
it's really hard to make unpredictable terrain predictably |
| 20:30 |
celeron55_ |
you need to take huge samples to make sure you're maybe getting what you want 8) |
| 20:30 |
celeron55_ |
it's a skill to do it in large scale without sampling results so much |
| 20:30 |
celeron55_ |
an another limitation we/you are going to face is that 2d noise can't make interesting cliffs; it requires 3D |
| 20:31 |
celeron55_ |
dunno how that could be handled |
| 20:31 |
hmmmm |
i disagree there |
| 20:31 |
hmmmm |
i think i can make neat cliffs with 2d |
| 20:31 |
celeron55_ |
you can only prove me wrong by actually doing it |
| 20:32 |
hmmmm |
i have some ideas on how to make that happen, but i need to do other stuff first |
| 20:32 |
hmmmm |
which really isn't too much more now that i think about it |
| 20:32 |
celeron55_ |
one thing i know for sure is that 3d noise is a silver bullet for interesting cliffs |
| 20:32 |
celeron55_ |
it really is |
| 20:33 |
hmmmm |
i believe you, i've seen it |
| 20:33 |
hmmmm |
quite nice |
| 20:33 |
celeron55_ |
if in trouble, just slap in 3d noise; done |
| 20:33 |
celeron55_ |
8D |
| 20:33 |
celeron55_ |
computationally heavy, but it just does it |
| 20:34 |
hmmmm |
i can generate an 80x80x80 piece in about 110ms |
| 20:34 |
celeron55_ |
...why do you even consider anything else then? |
| 20:34 |
hmmmm |
because |
| 20:34 |
hmmmm |
i think it's more challenging this way |
| 20:34 |
hmmmm |
more interesting (to me) |
| 20:34 |
celeron55_ |
there's no reason to take extra challenges; we're struggling to get results even without any of them |
| 20:34 |
hmmmm |
(not to the end user) |
| 20:35 |
* celeron55_ |
the producer |
| 20:35 |
hmmmm |
the sooner i get done with the current stuff, the sooner i can get working on some really cool noise. |
| 20:36 |
hmmmm |
nearly done with the Lua functions for the new perlin noise things |
| 20:37 |
hmmmm |
who is the guy with the "set node range" lua function? was that plizadam? |
| 20:37 |
celeron55_ |
yes |
| 20:37 |
hmmmm |
i don't think that function is useful on its own |
| 20:37 |
hmmmm |
it needs a "get node range" as well |
| 20:37 |
hmmmm |
i should talk to him about that |
| 20:37 |
celeron55_ |
sounds like a lua interface to voxelmanipulator |
| 20:37 |
hmmmm |
yes. |
| 20:37 |
hmmmm |
that was my original plan. |
| 20:38 |
celeron55_ |
that has been on the todo lists since forever |
| 20:38 |
hmmmm |
i was going to do it but someone did something that approximates it faster than i got to it |
| 20:38 |
celeron55_ |
well, directly after "find out if it's of any real use" |
| 20:38 |
hmmmm |
s/faster/sooner/ |
| 20:38 |
hmmmm |
of course it is |
| 20:38 |
celeron55_ |
also, please note that VM is broken by design |
| 20:38 |
celeron55_ |
especially now for lua |
| 20:39 |
celeron55_ |
it doesn't handle node metadata, and doesn't handle node constructors/destructors/anything |
| 20:39 |
celeron55_ |
it's just fast and doesn't care about anything |
| 20:39 |
hmmmm |
i don't believe that matters |
| 20:39 |
hmmmm |
if you're setting bulk nodes, would you really care about metadata and that stuff? |
| 20:39 |
celeron55_ |
there's kind of two levels of node manipulation in minetest - one is using them as plain data, and the other one is using them like game elements |
| 20:40 |
celeron55_ |
maybe they should be clearly said to be so |
| 20:40 |
celeron55_ |
to not cause confusion |
| 20:40 |
celeron55_ |
well, that'll go in the lua documentation of VM, if that becomes to exist |
| 20:41 |
hmmmm |
the VM i won't document |
| 20:41 |
hmmmm |
i'm sure you understand it better and what not |
| 20:41 |
hmmmm |
i just know how to use ie |
| 20:41 |
hmmmm |
s/ie/it/ |
| 20:41 |
celeron55_ |
there are two points in VM |
| 20:42 |
celeron55_ |
1) it allows copying node data between threads |
| 20:42 |
celeron55_ |
2) it allows constructing something from nodes (a bit faster than on a regular map), but most importantly it happens without lighting, and it can be then bulk-updated afterwards |
| 20:43 |
celeron55_ |
(well, also heavy algorithms are faster on them, but it's kind of 2 again) |
| 20:45 |
celeron55_ |
dunno if that was any news to anyone, but i had to say it anyway 8) |
| 20:47 |
celeron55_ |
actually, 2 is doable without them too, but it's a bit messy |
| 20:47 |
celeron55_ |
or... different |
| 20:58 |
hmmmm |
how do i do a pull request for a specific commit? |
| 20:59 |
celeron55_ |
make a branch that has only it on top of c55/master |
| 20:59 |
celeron55_ |
now that i think of it, i've actually never made a single pull request 8D |
| 20:59 |
hmmmm |
ugh that's a lot more work, i was hoping there was some github option |
| 21:00 |
celeron55_ |
well, tbh, that isn't a lot of work |
| 21:01 |
celeron55_ |
it implicitly makes sure the thing actually can be merged on master too |
| 21:03 |
thexyz |
just send a .patch then |
| 21:04 |
celeron55_ |
a patch is fine too; just go to your commit on github and append .patch to the page |
| 21:04 |
celeron55_ |
it's like magic, except more magical |
| 21:06 |
hmmmm |
alright, so i back up my directory i'm working with, checkout -b mapgen_factories, now what, git fetch upstream/master? |
| 21:08 |
celeron55_ |
depends on what your initial state was, in detail |
| 21:08 |
celeron55_ |
a branch that has many unrelatedcommits? |
| 21:08 |
celeron55_ |
+space |
| 21:10 |
hmmmm |
i want to set the contents of the branch |
| 21:10 |
hmmmm |
oh wait, maybe what i do is checkout to master, and THEN do the checkout -b from there. |
| 21:11 |
celeron55_ |
i'd maybe first fetch upstream, then branch from it rather than your stuff, and then cerry-pick the commit into it |
| 21:11 |
celeron55_ |
yeah, branch -d mapgen_factories and start over like that 8) |
| 21:15 |
hmmmm |
alright so i'm at the point where i have the latest code, and i'm on a new branch |
| 21:15 |
hmmmm |
now i have to use "cherry-pick" or something along those lines |
| 21:16 |
celeron55_ |
if you have a single commit to put in the branch, try git cherry-pick hashstuff |
| 21:17 |
hmmmm |
i just did that |
| 21:17 |
hmmmm |
alright |
| 21:17 |
hmmmm |
so i think i'm good |
| 21:18 |
hmmmm |
ah no i need to push to origin first |
| 21:20 |
hmmmm |
alright great |
| 21:22 |
hmmmm |
I did it |
| 21:23 |
hmmmm |
so what's the point of the "followers" thing on github? i can't really figure it out |
| 21:31 |
doserj |
you can "follow" users and "watch" repositories to see on your github homepage what they do |
| 21:32 |
hmmmm |
https://github.com/celeron55/minetest/pull/441 https://github.com/celeron55/minetest/pull/442 |
| 21:32 |
hmmmm |
why would i bother with that |
| 21:32 |
hmmmm |
i don't care what other people are doing |
| 21:33 |
doserj |
it#s the social network thing. it's hip! all the cool kids are doing it :) |
| 21:34 |
doserj |
but seriously, there are cases where it is useful |
| 21:48 |
celeron55_ |
i use none of that 8) |
| 21:49 |
celeron55_ |
but otoh, i guess people find it useful to follow my repo |
| 21:50 |
celeron55_ |
can somebody make a pull request that doesn't compile? just for the kicks, as we have those fancy travis messages in there? 8) |
| 22:59 |
|
rsiska joined #minetest-dev |
