| Time |
Nick |
Message |
| 01:38 |
|
twoelk|2 joined #minetest-dev |
| 02:07 |
|
RealBadAngel joined #minetest-dev |
| 02:44 |
|
Hunterz joined #minetest-dev |
| 03:04 |
|
kaeza joined #minetest-dev |
| 03:06 |
|
blaise joined #minetest-dev |
| 04:18 |
|
cornernote_ joined #minetest-dev |
| 04:19 |
|
paramat joined #minetest-dev |
| 04:21 |
paramat |
argh! est31 is too obsessed with getting a release out on a fixed date at all costs |
| 04:23 |
kaeza |
well, we complained time and time again that the "it's done when it's done" release model of Minetest leaves players hanging |
| 04:23 |
paramat |
0.4.13 stable mtgame has been forced through with errors, my mushroom drops have been changed to a stupid system, and the essential renaming of pine tree nodes has not yet been merged. all with no discussion with me or any mtgame devs |
| 04:24 |
paramat |
mtgame 0.4.13 stable will have to be re-released |
| 04:24 |
paramat |
i will fix the mushrrom drops, est and vanessa misunderstood how it works |
| 04:26 |
paramat |
yeah i don't mind minetest 0.4.13 being released, luckily i had nothing essential to go in |
| 04:27 |
paramat |
i made a mistake with the names of pine tree nodes, these needed fixing before mtgame release, my PR is ready to go i will push it very soon |
| 04:31 |
paramat |
mushroom drops: digging a mushroom should always drop a mushroom (obviously), plus a variable number of spores from 0 to 3, with an average just above 1 spore, this allows a slow multiplication of mushrooms when farming, just like trees and saplings |
| 04:32 |
VanessaE |
paramat: didn't you see the part where the player can re-placed/re-dig the mushroom to get more spores? |
| 04:33 |
paramat |
ah i see, dig, place, dig, place? |
| 04:33 |
VanessaE |
yeah |
| 04:34 |
VanessaE |
the only way to solve that is either a bunch of extra on-place code, or limiting drops to 1 item(stack) |
| 04:34 |
paramat |
oh sorry okay this needs fixing |
| 04:34 |
paramat |
um a mushroom item is dropped that can't be placed? |
| 04:35 |
VanessaE |
no |
| 04:35 |
VanessaE |
at least it doesn't work that way in dan's/my mushrooms mod |
| 04:35 |
VanessaE |
if you do that, players can't place them decoratively. |
| 04:36 |
paramat |
despite my misunderstanding, est31 still rushed a release with no consultation with devs or myself, charlie brown says 'oh good grief!' |
| 04:37 |
paramat |
okay this needs work then, what was commited was not good enough |
| 04:37 |
VanessaE |
I still say the junglewood textures need to go in too |
| 04:37 |
paramat |
yes sure |
| 04:38 |
paramat |
another couple of days and we re-release mtgame 0.4.13 |
| 04:38 |
paramat |
when i see another mtgame dev i'll ask for the 0.4.13 tag and release to be reverted |
| 04:39 |
paramat |
mtgame release is not usually on the same day |
| 04:40 |
paramat |
the day for release is 'the right time' not a fixed arbitary date, otherwise we have broken releases |
| 04:44 |
paramat |
don't worry about aliases not being transative, pine nodes have only ever been in 0.4.12dev so they can be renamed freely, we don't really need the aliases at all, those were just to be extra nice to players =) |
| 04:44 |
VanessaE |
we need aliases :) |
| 04:45 |
VanessaE |
my Basic world tons of such nodes in use |
| 04:46 |
paramat |
sure, i mean for pine nodes |
| 04:47 |
paramat |
anyway i support a continued feature freeze, we need it, i was hoping for a really long freeze this time |
| 05:09 |
paramat |
okay lets have 2 types of mushroom, only the type grown by abm will drop spores, the picked one is sporeless |
| 05:10 |
VanessaE |
use meta for that. |
| 05:10 |
VanessaE |
like placed leaves |
| 05:10 |
VanessaE |
if placed: dig gets no drops |
| 05:10 |
paramat |
meh don't like metadata |
| 05:10 |
VanessaE |
on the other hand, wild grass and jungle grass work the way est set for the mushrooms |
| 05:11 |
VanessaE |
you can place-dig-... over and over until you've converted the grass into seeds |
| 05:11 |
VanessaE |
(and you have no grass then) |
| 05:11 |
paramat |
sure but that only gives seeds for another crop, so is less cheaty =) |
| 05:12 |
VanessaE |
well that was the idea I was suggesting for mushrooms too |
| 05:12 |
VanessaE |
guess it didn't end up so. |
| 05:13 |
paramat |
hmmmm, please can you revert the release of mtgame 0.4.13? so that players don't start filling longterm worlds with the wrongly named pine nodes |
| 05:14 |
paramat |
we need a couple more days to fix important stuff |
| 05:14 |
hmmmm |
well i don't think we came to a complete consensus on it but I think we're moving to a model where even version numbers are bugfix releases and odd versions are feature releases |
| 05:14 |
hmmmm |
so it's like a tick-tock model of development |
| 05:15 |
paramat |
meh players will see mtgame 0.4.13 and think 'stable!' |
| 05:15 |
hmmmm |
so i don't necessarily think that calling what we have right now "0.4.13" is that bad, so long as throughout this -dev cycle we focus on improvements and bugfixes only |
| 05:15 |
hmmmm |
we need to retrain them perhaps |
| 05:15 |
hmmmm |
fwiw nerzhul was against this, vanessae and est liked it |
| 05:16 |
hmmmm |
if you don't like it i'll count you as a nay |
| 05:16 |
paramat |
it was forced through without discussion and with 2 big problems, that's reason enough to revert the release |
| 05:16 |
VanessaE |
I favor any versioning scheme that doesn't confuse people :) |
| 05:16 |
hmmmm |
vanessae what do you think |
| 05:16 |
hmmmm |
should it be reverted or not |
| 05:16 |
VanessaE |
with all due respect to est, revert. |
| 05:17 |
hmmmm |
est doesn't take very kindly to reverts FYI... |
| 05:17 |
VanessaE |
or it might be cleaner to just rewrite history |
| 05:17 |
paramat |
i will work full time now to get it ready, just 1-2 days |
| 05:17 |
VanessaE |
(I know it's WAY beyond the usual time limit, but this is a special case) |
| 05:17 |
hmmmm |
what do other people around think about it? kaeza? cornernote? RBA? kilbith?? sfan5 i saw around earlier |
| 05:18 |
hmmmm |
btw what do you guys think about this https://github.com/minetest/minetest_game/commit/6a64ec4dac8c92b8435107fb6ab1bc6bb7ce1820 |
| 05:18 |
paramat |
i'm sure est will realise his/her mistake and accept the revert |
| 05:18 |
hmmmm |
est is a guy |
| 05:18 |
paramat |
okay |
| 05:19 |
paramat |
est commited some texturs then removed them later? |
| 05:19 |
paramat |
(textures) |
| 05:19 |
VanessaE |
hmmmm: for that texture, see game#619 |
| 05:19 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/619 -- Better jungle wood and jungle tree top textures by VanessaE |
| 05:19 |
VanessaE |
paramat: yeah. |
| 05:19 |
hmmmm |
did he? |
| 05:19 |
VanessaE |
he thought he was breaking the no-features freeze rule. |
| 05:19 |
hmmmm |
it seems like they're not part of history |
| 05:19 |
hmmmm |
oh come on that obviously does not apply to minetest_game |
| 05:20 |
VanessaE |
I assume he force-pushed them out |
| 05:20 |
paramat |
that was without dev discussion too |
| 05:20 |
hmmmm |
the whole point of the no-features rule is to ensure stability |
| 05:20 |
VanessaE |
hmmmm: tell that to kilbith :) |
| 05:20 |
hmmmm |
a texture change isn't harming stability |
| 05:20 |
hmmmm |
i don't give a rats ass about textures as long as the grass is fixed to something that isn't that depressing shade of green, and gold stops looking like blocks of american cheese |
| 05:21 |
VanessaE |
lol |
| 05:21 |
hmmmm |
so it's up to what you guys think about the textures |
| 05:21 |
paramat |
we're almost ready with the new textures, vanessa's latest tree top is good |
| 05:21 |
kaeza |
that system could work |
| 05:21 |
paramat |
i'm planning to change the grim grass |
| 05:21 |
VanessaE |
I personally don't have a problem with the grass, but honestly the dirt just looks like noisy brown, to me. |
| 05:21 |
paramat |
i can't stand it anymore |
| 05:21 |
kaeza |
I'm more interested in better grass sounds |
| 05:21 |
hmmmm |
kaeza, ? you mean what I proposed with the feature release/improvement release? |
| 05:21 |
kaeza |
ye |
| 05:21 |
hmmmm |
so another yay for that |
| 05:22 |
hmmmm |
yay: me, est, kaeza | nay: vanessae, paramat, nerzhul |
| 05:22 |
VanessaE |
eh? |
| 05:22 |
hmmmm |
er |
| 05:22 |
VanessaE |
I'm on the "yea" side. |
| 05:22 |
kaeza |
I think VE is a yay |
| 05:22 |
hmmmm |
I thought you said whichever doesn't confuse people |
| 05:22 |
VanessaE |
I did. |
| 05:23 |
VanessaE |
I don't think your idea will confuse too much |
| 05:23 |
hmmmm |
well okay |
| 05:23 |
hmmmm |
should we make a forum vote maybe |
| 05:23 |
VanessaE |
nah |
| 05:23 |
paramat |
nah |
| 05:23 |
hmmmm |
we're getting a very limited sample size you know |
| 05:23 |
hmmmm |
so just to be clear: |
| 05:24 |
hmmmm |
adopting the stable/feature release number scheme would mean NOT reverting the 0.4.13 version bump commits |
| 05:24 |
hmmmm |
or would you rather still adopt it but rollback that change |
| 05:24 |
VanessaE |
I'd say adopt and roll-back |
| 05:24 |
VanessaE |
it's the cleanest way |
| 05:24 |
VanessaE |
less'n someone here has a better idea |
| 05:25 |
VanessaE |
we all seem to agree 0.4.13 should not have hit the shelves |
| 05:25 |
hmmmm |
yeah |
| 05:25 |
VanessaE |
but then again, it hasn't hit the website yet |
| 05:25 |
hmmmm |
well |
| 05:25 |
hmmmm |
the 0.4.13 bump commit serves as the HEAD for 0.4-stable |
| 05:25 |
paramat |
i don't mind minetest 0.4.13 being released. but mtgame was forced through without discussion so the 0.4.13 tag/release needs removing |
| 05:26 |
VanessaE |
yeah I know |
| 05:26 |
hmmmm |
the engine needs some work before a release |
| 05:26 |
hmmmm |
i'm working on the delete_area fixes, rollback fixes, and adding more information about the double error |
| 05:26 |
hmmmm |
I think that at the very least if those things get fixed a release COULD be plausible |
| 05:26 |
kaeza |
to be fair, bad node names are not exactly world-breaking bugs like other things that have been added (*looks at proller* [weather]) |
| 05:26 |
VanessaE |
so my proposal is to reset --hard to a953ff4d and carry on from there |
| 05:27 |
hmmmm |
yeah but |
| 05:27 |
hmmmm |
how many people have already checked out this version in git |
| 05:27 |
VanessaE |
probably a few, BUT it's a non-functional change |
| 05:27 |
hmmmm |
the problem with hard resetting is you screw everybody's repos |
| 05:27 |
VanessaE |
other than a couple flags in CMakeLists anyway |
| 05:27 |
hmmmm |
well |
| 05:27 |
hmmmm |
it can't be more than a few |
| 05:28 |
hmmmm |
kaeza, are you on board? paramat? |
| 05:28 |
VanessaE |
I know, but it's not impossible to force-pull or just re-clone if your repo goes wonky |
| 05:28 |
paramat |
erm let me reread |
| 05:28 |
hmmmm |
we're going to reset to HEAD^2 |
| 05:29 |
kaeza |
hmmmm, I have no problems with resets. also, a 1 day reset is not that of a big deal really |
| 05:30 |
kaeza |
if it's even 1 day |
| 05:30 |
hmmmm |
here we go then |
| 05:30 |
paramat |
yeah rollback the 0.4.13 bump |
| 05:30 |
VanessaE |
kaeza: exactly, and it's only been 8 hours anyway |
| 05:31 |
VanessaE |
hmmmm: inb4 kilbith complains ;) |
| 05:32 |
hmmmm |
ooh |
| 05:32 |
hmmmm |
git push -f upstream master |
| 05:32 |
hmmmm |
that -f. |
| 05:32 |
hmmmm |
that does not happen often. |
| 05:32 |
hmmmm |
it's done |
| 05:33 |
kaeza |
inb4 -f means --fuck-up |
| 05:33 |
hmmmm |
-f is the short flag for --fuck-upstream |
| 05:33 |
VanessaE |
lol |
| 05:34 |
paramat |
mtgame doesn't have a bump commit, just a tag and entry on the releases page |
| 05:34 |
hmmmm |
for what it's worth, you guys can do anything you want to minetest_game |
| 05:34 |
hmmmm |
just don't screw it up |
| 05:34 |
hmmmm |
there's no special restrictions |
| 05:35 |
paramat |
yeah i just don't know how to remove that release entry and tag =) |
| 05:35 |
paramat |
anyway now to sort it out.. |
| 05:35 |
hmmmm |
here ya go |
| 05:35 |
hmmmm |
https://www.google.com/search?q=git+delete+tag+remote |
| 05:37 |
paramat |
thanks, this will need to be done before i push the next commit? |
| 05:37 |
hmmmm |
i don't think so no |
| 05:37 |
paramat |
okay will do so anyway |
| 05:39 |
hmmmm |
https://github.com/kwolekr/minetest/commit/18cfd89a86af550b3c4663def77a5fac46e895ae |
| 05:39 |
hmmmm |
PTAL |
| 05:39 |
paramat |
soon after that i will push the corrected pine node names, then vanessa's tree top and kilbith's dark planks, then will work on mushroom farming |
| 05:40 |
hmmmm |
can you also add the light grass texture back |
| 05:40 |
hmmmm |
that's really annoying but i learned to accept it |
| 05:40 |
paramat |
and yes |
| 05:40 |
paramat |
new grass |
| 05:40 |
VanessaE |
light grass texture pack? |
| 05:40 |
hmmmm |
every time i update minetest_game i need to fix it |
| 05:40 |
VanessaE |
back* |
| 05:40 |
VanessaE |
hmmmm: good idea regarding the mem usage |
| 05:41 |
hmmmm |
yeah |
| 05:41 |
hmmmm |
it's actually quite variable on my system |
| 05:41 |
hmmmm |
sometimes it's 512MB |
| 05:41 |
hmmmm |
others it's ~1980 MB |
| 05:41 |
paramat |
i made a bright new grass recently based on the current one https://github.com/minetest/minetest_game/issues/560 what do you think? |
| 05:41 |
hmmmm |
yeah I think that's an improvement |
| 05:42 |
paramat |
it's colour, brightness and contrast matched to what came before |
| 05:42 |
hmmmm |
RealBadAngel's comment is the real solution but the thing is that comes along with client-side biomes |
| 05:42 |
VanessaE |
paramat: +1 |
| 05:42 |
hmmmm |
i.e. not a thing we can do right now |
| 05:44 |
hmmmm |
paramat: did you look at my commit? |
| 05:44 |
* paramat |
looks |
| 05:45 |
paramat |
useful feature |
| 05:45 |
|
Hunterz joined #minetest-dev |
| 05:46 |
hmmmm |
+1?? |
| 05:46 |
paramat |
yes |
| 05:46 |
hmmmm |
ok :) |
| 05:46 |
hmmmm |
push complete |
| 05:48 |
VanessaE |
what's the disposition of game#581 ? |
| 05:48 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/581 -- New stairs and slabs discussion |
| 05:49 |
paramat |
i'd like steelblock added |
| 05:49 |
paramat |
we need at least one ption for modern stairs |
| 05:49 |
hmmmm |
heh this reminds me of terasology's setup |
| 05:49 |
paramat |
(option) |
| 05:49 |
hmmmm |
each mapnode has a material and a block type |
| 05:50 |
hmmmm |
can't help but think that ours is kind of inefficient and repetitive |
| 05:50 |
VanessaE |
it is. |
| 05:50 |
hmmmm |
well we're not going to fix that without splitting up param1 |
| 05:50 |
hmmmm |
err, i mean param0 |
| 05:50 |
hmmmm |
that's the tough part |
| 05:50 |
VanessaE |
the only reason dreambuilder has over 16'000 nodes is because it's stair-this and slab-that and colored-this-other-thing |
| 05:51 |
hmmmm |
i dunno, maybe |
| 05:51 |
hmmmm |
the longer we go the more pressure there is to move to an 8-byte mapnode structure |
| 05:51 |
hmmmm |
and, man, trust me I am not going to waste 3 of those bytes on something as pathetic as colored lighting |
| 05:51 |
VanessaE |
8 byte for alignment purposes? |
| 05:51 |
hmmmm |
of course |
| 05:51 |
hmmmm |
we don't really have much of a choice.. |
| 05:52 |
hmmmm |
if you increase the structure by 1 bit it's going to be now 8 bytes |
| 05:52 |
VanessaE |
regarding colored lighting, seems to me you could just use *one* byte as an index into a color lookup table. |
| 05:52 |
VanessaE |
(not unlike the idea you had for generic colorized nodes) |
| 05:52 |
paramat |
i don't see coloured light as all that important, or needed |
| 05:52 |
hmmmm |
not only that |
| 05:52 |
hmmmm |
but if i were going to do colored lighting, i'd rather fix the minetest lighting algorithm first |
| 05:53 |
VanessaE |
yes |
| 05:53 |
VanessaE |
RBA will want to have a hand in that |
| 05:53 |
hmmmm |
that's what's really needed rather than monkey patching individual color channels into the central data structure of the game |
| 05:53 |
VanessaE |
still this is out of scope for now |
| 05:53 |
hmmmm |
well i still need to come up with the lighting algorithm |
| 05:53 |
hmmmm |
it's tough |
| 05:53 |
hmmmm |
yeah all this is future talk |
| 05:53 |
hmmmm |
but think about it, if we doubled the size of a mapnode, what things would you use it for |
| 05:54 |
VanessaE |
well 4 bytes is a lot of space given the sort of constraints we're working with, so .. I dunno |
| 05:55 |
VanessaE |
alternate nodes. |
| 05:55 |
VanessaE |
that's the first thing that comes to mind. |
| 05:55 |
VanessaE |
1 bit stored somewhere that will switch in an entirely different node def for that spot |
| 05:56 |
VanessaE |
(for the mesecons/furnaces/et al. use case) |
| 05:56 |
hmmmm |
how do furnaces work right now again? |
| 05:56 |
hmmmm |
i forget |
| 05:56 |
VanessaE |
they swap in a new def manually. |
| 05:56 |
VanessaE |
minetest.swap_node() |
| 05:56 |
VanessaE |
which may as well be read-meta, minetest.set_node(), rewrite meta. |
| 05:56 |
hmmmm |
ah |
| 05:57 |
VanessaE |
mesecons is similar. |
| 05:57 |
hmmmm |
yeah, we'll see what we can do |
| 05:57 |
hmmmm |
I think that's already quite doable tbh, if param1 is stolen |
| 05:57 |
VanessaE |
it is yes |
| 05:57 |
hmmmm |
we just need somebody to work on it |
| 05:57 |
hmmmm |
man this is depressing |
| 05:58 |
hmmmm |
all the NetworkPacket handler routines lack PacketError exception handlers |
| 05:58 |
|
OldCoder joined #minetest-dev |
| 05:58 |
hmmmm |
you can crash any minetest client right now by sending a packet with an invalid length |
| 05:59 |
hmmmm |
crash, as in stop it from running, but thankfully no remote code execution or arbitrary memory reads or anything bad like that |
| 05:59 |
hmmmm |
you know, if the minetest gaming community had users that were just 5% smarter than they are right now there would be havoc |
| 06:00 |
hmmmm |
thanks nerz |
| 06:04 |
|
paramat left #minetest-dev |
| 06:06 |
VanessaE |
hmmmm: come to think of it, what harm would there be in partially adopting terasology's model? |
| 06:06 |
VanessaE |
regarding block types and materials |
| 06:06 |
hmmmm |
nothing, i think it might be a decent idea |
| 06:06 |
hmmmm |
but you'd also have a lot of irrelevant combinations for one-of node types |
| 06:07 |
VanessaE |
for example? |
| 06:07 |
hmmmm |
mesecons with the grass material? |
| 06:07 |
hmmmm |
lol. |
| 06:07 |
VanessaE |
haha |
| 06:07 |
VanessaE |
right |
| 06:08 |
VanessaE |
well I was thinking, one new byte for the material (index into a table that a mod can add to/change), one byte for the model/block type (if 0, refer to the node def's drawtype) |
| 06:09 |
VanessaE |
block type could even indicate different tables for different drawtypes for that node |
| 06:09 |
hmmmm |
ha.. |
| 06:09 |
hmmmm |
maybe... |
| 06:09 |
hmmmm |
okay how about this setup |
| 06:09 |
hmmmm |
MAX_CONTENT is still at 32k right? |
| 06:10 |
VanessaE |
yeah |
| 06:10 |
hmmmm |
we'll steal the top bit |
| 06:10 |
hmmmm |
if the top bit is set, that means that param0 is a block type/material pair |
| 06:10 |
hmmmm |
the low 8 bits of param0 will be the block type |
| 06:10 |
hmmmm |
and then the top 7 bits will be the material |
| 06:10 |
hmmmm |
yea? |
| 06:10 |
VanessaE |
I like it. |
| 06:10 |
hmmmm |
there you go, it's even reverse compatible |
| 06:11 |
hmmmm |
will 128 materials be enough for you though? |
| 06:11 |
VanessaE |
well worst-case in any mod I've ever written, only about 90 unique nodes for a given shape |
| 06:11 |
VanessaE |
(unified dyes-related stuff) |
| 06:12 |
hmmmm |
so which is needed more |
| 06:12 |
hmmmm |
more materials or more shapes |
| 06:12 |
VanessaE |
hm |
| 06:12 |
VanessaE |
you know, I'm not really sure. |
| 06:13 |
VanessaE |
if I were to use one node per hue in a unified dyes based mod, then a given node would only need one of 6 or 7 materials |
| 06:14 |
hmmmm |
btw you realize this is a global number, not a per-mod number, right? |
| 06:14 |
VanessaE |
the "worst offender" is probably the stained glass mod |
| 06:14 |
VanessaE |
yeah, I'm just thinking out loud at the moment |
| 06:15 |
VanessaE |
more shapes than materials, it seems to me |
| 06:16 |
hmmmm |
okay |
| 06:16 |
hmmmm |
i still think 7 bits is too small |
| 06:16 |
VanessaE |
yeah |
| 06:17 |
VanessaE |
damn |
| 06:17 |
hmmmm |
what do you think about this |
| 06:17 |
hmmmm |
https://github.com/kwolekr/minetest/commit/1c408c4f1df25ecec0dd8ea8b6cb00534e08bc66 |
| 06:17 |
VanessaE |
I don't think you'll be able to cover everyone's use cases without adding another byte to the node. |
| 06:17 |
hmmmm |
PTAL |
| 06:18 |
VanessaE |
I'm curious about the change to line 88 but the rest seems reasonable to me |
| 06:19 |
hmmmm |
that's there because i missed that instance when i changed the rest of them |
| 06:19 |
VanessaE |
(of course, in no case will a u16 ever be more than 2 bytes, so it's probably moot anyway) |
| 06:19 |
hmmmm |
sizeof(u16) isn't ever not going to be 2, but it's just for consistency with the rest of them |
| 06:19 |
VanessaE |
right |
| 06:19 |
hmmmm |
get into the habit of using the number literal for when you mean serialized byte lengths instead of in-memory-representations |
| 06:21 |
VanessaE |
damn, you don't waste any time :P |
| 06:24 |
VanessaE |
what about this: steal that top bit, lower 10 bits for materials, upper 5 from there plus another 5 from another byte for shapes |
| 06:24 |
|
nrzkt joined #minetest-dev |
| 06:24 |
VanessaE |
use one of the leftover 3 bits for that special-nodedef idea |
| 06:25 |
VanessaE |
that least 2 bits plus another three unassigned bytes |
| 06:25 |
hmmmm |
yeah we can use param1 |
| 06:26 |
hmmmm |
param1 is only ever used for torchlike |
| 06:26 |
VanessaE |
how are you gonna wrestle-away the lighting info from the engine? |
| 06:26 |
hmmmm |
well I highly doubt a transparent node needs to have variable materials |
| 06:27 |
hmmmm |
unless you want a grassy air node and a brick air node |
| 06:27 |
VanessaE |
glass stairs |
| 06:27 |
hmmmm |
hum |
| 06:31 |
kahrl |
even stairs made of a solid material have paramtype = "light" |
| 06:31 |
VanessaE |
right |
| 06:31 |
VanessaE |
otherwise they'll be black. |
| 06:32 |
hmmmm |
oops |
| 06:32 |
kahrl |
anyway I did a quick valgrind run and it showed two problems |
| 06:32 |
kahrl |
first, there is an uninitialized value in minimap.cpp:272 |
| 06:33 |
kahrl |
second, intlGUIEditBoxes are leaked |
| 06:34 |
kahrl |
this should fix those issues: https://gist.github.com/kahrl/4c3f9d0f75572a93c079 |
| 06:35 |
hmmmm |
looks good to me |
| 06:35 |
kahrl |
pushing. |
| 06:39 |
hmmmm |
:) |
| 06:40 |
kahrl |
gah, that typo in the commit message is going to haunt me forever :P |
| 06:41 |
hmmmm |
5 minute rule |
| 06:41 |
hmmmm |
you can still amend that commit |
| 06:41 |
kahrl |
alright. I didn't see it as important enough but I'll do it :) |
| 06:45 |
|
paramat joined #minetest-dev |
| 06:47 |
paramat |
actually i do have an essential engine PR to go in before 0.4.13 #3020 can anyone approve? will push when i rename pine nodes in mtgame |
| 06:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/3020 -- Treegen: Rename pine tree mapgen alias by paramat |
| 06:48 |
hmmmm |
that i think is fine |
| 06:48 |
hmmmm |
go ahead |
| 06:48 |
paramat |
thanks |
| 06:49 |
VanessaE |
paramat: wait a sec... |
| 06:50 |
paramat |
yeah |
| 06:50 |
VanessaE |
mmm.. nevermind |
| 06:50 |
paramat |
lol |
| 06:51 |
paramat |
will push 3020 and game#617 very soon |
| 06:51 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/617 -- Default: Rename pine tree nodes, textures and mapgen aliases by paramat |
| 06:55 |
paramat |
since there's still much to do in mtgame i'd like roughly a week before releasing 0.4.13 |
| 06:55 |
VanessaE |
at least. |
| 07:03 |
|
paramat left #minetest-dev |
| 07:03 |
hmmmm |
no problem |
| 07:04 |
VanessaE |
ok time for me to head to bed |
| 07:04 |
VanessaE |
night |
| 07:19 |
nrzkt |
i see a bump version but no git tag, is this normal ? |
| 07:29 |
|
nore joined #minetest-dev |
| 07:30 |
|
paramat joined #minetest-dev |
| 07:34 |
paramat |
hi nore please can you remove the mtgame 0.4.13 tag and 0.4.13 release from the releases page? (see logs for why) i was going to do it myself but not confident i will do it right |
| 07:36 |
nore |
hm... I don't know how to do it :/ |
| 07:36 |
paramat |
heh |
| 07:37 |
nrzkt |
https://nathanhoad.net/how-to-delete-a-remote-git-tag |
| 07:37 |
nrzkt |
look at this |
| 07:37 |
paramat |
i did =) |
| 07:39 |
paramat |
not sure if that's to be done from my master branch or from a cloned repo |
| 07:40 |
paramat |
anyway no rush everyone knows 0.4.13 has been reverted now |
| 07:41 |
|
paramat left #minetest-dev |
| 07:41 |
|
RealBadAngel joined #minetest-dev |
| 07:54 |
|
Darcidride_ joined #minetest-dev |
| 07:57 |
kahrl |
re-tagging will screw up everyone who already pulled the tag (a lot of people) |
| 07:57 |
kahrl |
https://www.kernel.org/pub/software/scm/git/docs/git-tag.html#_on_re_tagging |
| 07:59 |
kahrl |
I would just make a new tag called 0.4.13.1 or something like that |
| 08:00 |
kahrl |
even if it's ugly, it's a lot less hassle |
| 08:01 |
kahrl |
(I guess you can do that and also delete the 0.4.13 tag) |
| 08:05 |
|
Yepoleb joined #minetest-dev |
| 08:13 |
|
paramat joined #minetest-dev |
| 08:14 |
paramat |
ah okay kahrl lets not retag then no problem |
| 08:15 |
paramat |
now pushing game#617 |
| 08:15 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/617 -- Default: Rename pine tree nodes, textures and mapgen aliases by paramat |
| 08:23 |
paramat |
complete, 500 commits! |
| 08:24 |
sfan5 |
would minetest_game be ready for a releave after this? |
| 08:28 |
paramat |
nah still lots to do, perhaps in a week |
| 08:28 |
paramat |
will push #3020 when checks are done |
| 08:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/3020 -- Treegen: Rename pine tree mapgen alias by paramat |
| 08:29 |
paramat |
a week at most, maybe less |
| 08:30 |
paramat |
read logs for details |
| 08:32 |
|
rubenwardy joined #minetest-dev |
| 08:33 |
|
Player_2 joined #minetest-dev |
| 08:34 |
paramat |
hmmmm is fed up with the depressing grass texture, so is cele55 and myself, i think it will need to be changed to a brighter one, or at least something more lush, i will work on it |
| 08:37 |
paramat |
.. and submit a dark improved one and a brighter one, maybe 3.. |
| 08:39 |
|
leat joined #minetest-dev |
| 08:46 |
|
proller joined #minetest-dev |
| 08:47 |
paramat |
now pushing 3020 |
| 08:48 |
|
SopaXorzTaker joined #minetest-dev |
| 08:53 |
rubenwardy |
#3020 |
| 08:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/3020 -- Treegen: Rename pine tree mapgen alias by paramat |
| 08:54 |
paramat |
complete |
| 08:54 |
|
paramat left #minetest-dev |
| 09:06 |
|
Amaz joined #minetest-dev |
| 09:07 |
|
SopaXorzTaker joined #minetest-dev |
| 09:39 |
|
WSDguy2014 joined #minetest-dev |
| 09:48 |
|
kilbith joined #minetest-dev |
| 09:49 |
|
rubenwardyy joined #minetest-dev |
| 09:51 |
|
SopaXorzTaker joined #minetest-dev |
| 09:53 |
kilbith |
VanessaE: reverting the textures was not about my complaints |
| 09:53 |
kilbith |
it was clearly a violation of the rules |
| 09:54 |
kilbith |
textures, especially, have to subjected to the maintainers since they highly depend on tastes |
| 09:55 |
kilbith |
also i agree with the devel model of hmmmm |
| 10:01 |
|
CraigyDavi joined #minetest-dev |
| 10:17 |
|
diemartin joined #minetest-dev |
| 10:41 |
|
rubenwardy joined #minetest-dev |
| 10:43 |
|
asl97 joined #minetest-dev |
| 10:51 |
|
SopaXorzTaker joined #minetest-dev |
| 10:52 |
|
Niebieski joined #minetest-dev |
| 11:20 |
|
Calinou joined #minetest-dev |
| 11:37 |
|
Ardonel joined #minetest-dev |
| 11:37 |
|
est31 joined #minetest-dev |
| 11:38 |
est31 |
seems a 0.4.13 release is highly not wanted |
| 11:39 |
est31 |
so we're going the irrlicht route then, no release for years |
| 11:39 |
Calinou |
seriously, don't let that happen. |
| 11:39 |
Calinou |
"release early, release often" is still very true |
| 11:42 |
est31 |
and about ordering nodedefs by criteria: I hate this |
| 11:42 |
est31 |
the criteria just limit how generic we are |
| 11:42 |
est31 |
its wasted space |
| 11:43 |
est31 |
we can do something like it, but please as mod then |
| 11:43 |
est31 |
and without wastery |
| 11:44 |
est31 |
e.g. criteria_lib.register_node_wood_type(pine", "pine_wood_1.png") |
| 11:44 |
est31 |
or so |
| 11:45 |
est31 |
I'd like to hear technical arguments which speak for such a change |
| 11:47 |
est31 |
if we dont release, people will think this project is dead |
| 11:48 |
est31 |
seems the windows builds done by sfan and blockmen were in vain then |
| 11:48 |
est31 |
well, no problem, they can be re-done |
| 11:49 |
nrzkt |
maybe having a news field in the client could be good to show the project is not dead :p |
| 11:49 |
nrzkt |
and i dont' think project is dead, look at commits |
| 11:50 |
est31 |
irrlicht has commits too |
| 11:50 |
Calinou |
news in the client is possible with the master server |
| 11:50 |
|
kilbith joined #minetest-dev |
| 11:50 |
est31 |
might be an idea |
| 11:50 |
est31 |
well, its a feature, so future talk |
| 11:50 |
kilbith |
some people are facing a new bug : https://forum.minetest.net/viewtopic.php?f=6&t=13001 |
| 11:51 |
est31 |
for the version after 0.4.14 or how its called |
| 11:51 |
est31 |
heh, i guess its a deadlock thanks to one of those "race prevention" locks added |
| 11:54 |
kilbith |
RealBadAngel: how goes the handmade relief mapping for the default textures you were heading to do ? |
| 11:56 |
nrzkt |
est31: an added muted ? |
| 11:56 |
nrzkt |
mutex* ? |
| 11:56 |
est31 |
perhaps, just a wild guess |
| 11:57 |
est31 |
to fix one of the race conditions added thanks to an "optimisation" |
| 12:00 |
nrzkt |
some mutex were useless in the code |
| 12:00 |
nrzkt |
as i said when they were merged... |
| 12:00 |
nrzkt |
like one mutex on a getter function but no mutex in setter... |
| 12:01 |
est31 |
they arent useless |
| 12:01 |
est31 |
they are just creating bugs, like before already |
| 12:01 |
est31 |
just different bugs |
| 12:11 |
|
SopaXorzTaker joined #minetest-dev |
| 12:12 |
est31 |
I have tried to do a sensible discussion about what to do before the release |
| 12:13 |
est31 |
and we ended up with "fix every medium bug in the tracker" |
| 12:13 |
nrzkt |
critical and very high okay, but medium can be differed |
| 12:14 |
est31 |
even that's too much |
| 12:14 |
est31 |
people are running around labeling every bug as critical |
| 12:14 |
est31 |
critical bugs are ones which ruin the game for EVERYBODY |
| 12:14 |
est31 |
not just for some person with an ATI card when they install this mod and play for 10 hours a piece. |
| 12:16 |
nrzkt |
for me it's medium in that case |
| 12:16 |
nrzkt |
but label are handled by coredevs, not users, no ? |
| 12:16 |
est31 |
I have just tried to make a release with not more bugs as 0.4.12, and then give us time to do a bugfix release |
| 12:18 |
est31 |
the delete_area suckery has existed since < 0.4.12 |
| 12:18 |
est31 |
no need to block everything for it |
| 12:19 |
est31 |
~topic |
| 12:19 |
ShadowBot |
est31: Minetest core development and maintenance. Feature freeze IN EFFECT until 0.4.13 release, no commits on the master branch except bugfixes or trivial (small) cleanups. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 12:19 |
est31 |
I've thought ive done something everybody wants |
| 12:20 |
est31 |
hmmm wants to have eternal feature freeze, so let him have it |
| 12:20 |
est31 |
others want a release, so let them have it |
| 12:21 |
est31 |
everything would have bene fine |
| 12:21 |
est31 |
been* |
| 12:21 |
est31 |
what do we have now |
| 12:22 |
nrzkt |
est31, have you taken holidays this summer ? : |
| 12:22 |
nrzkt |
:) |
| 12:22 |
est31 |
nrzkt, I'll quit doing stuff for minetest, perhaps, and let people fuck it as they wish |
| 12:23 |
est31 |
no more changes, any day! |
| 12:23 |
est31 |
no release for years! |
| 12:25 |
kilbith |
this is not what hmmmm wants btw |
| 12:25 |
kilbith |
he wants a linux release scheme |
| 12:26 |
kilbith |
we can afford weekly-released software |
| 12:26 |
|
deltib joined #minetest-dev |
| 12:26 |
est31 |
he didnt say weekly released |
| 12:27 |
est31 |
he and VanessaE just wanted to stop progress until every medium bug was fixed in the tracker |
| 12:27 |
kilbith |
bumped versioning for minor patches and so on |
| 12:27 |
Calinou |
to be honest, maybe we would be better off with rolling release. |
| 12:27 |
Calinou |
that's what Red Eclipse does now |
| 12:27 |
Calinou |
an updater is included in the game |
| 12:28 |
Calinou |
(uses curl, no GUI front-end currently) |
| 12:53 |
|
FR^2 joined #minetest-dev |
| 12:55 |
|
leat joined #minetest-dev |
| 13:01 |
kilbith |
yet again another crash : https://forum.minetest.net/viewtopic.php?f=6&t=13010 |
| 13:03 |
est31 |
oh, even reproducible |
| 13:09 |
|
FR^2 left #minetest-dev |
| 13:11 |
* VanessaE |
looks at est31 and kilbith and grumbles. loudly. |
| 13:11 |
kilbith |
oh i love that |
| 13:21 |
VanessaE |
est31: 0.4.13 release is not wanted *yet*.. I told you that it was a bad idea to push it through. |
| 13:21 |
VanessaE |
the plan right now is to postpone it for a week or so |
| 13:22 |
VanessaE |
kilbith: given the number of disparaging remarks you've levied at me in public lately despite every attempt on my part to help make this a project people actually WANT to use, frankly I'm not at all inclined to accept any further criticisms from you for now. |
| 13:23 |
kilbith |
of course you get naturally frustrated because *your* PR was reverted, that's human |
| 13:24 |
kilbith |
but there are rules, it's not for our pets |
| 13:25 |
kilbith |
isn't that you that harassed RBA for reverting a texture that you don't liked btw ? |
| 13:25 |
VanessaE |
wat |
| 13:25 |
kilbith |
the handmade sand relief map |
| 13:25 |
kilbith |
and a bunch of others |
| 13:25 |
kilbith |
that was included in a PR |
| 13:27 |
kilbith |
well, all that for demonstrating how poor-standards you have |
| 13:28 |
VanessaE |
maybe you should talk to RealBadAngel then about that because I don't recall harassing him over such a thing |
| 13:28 |
kilbith |
ok, i'll dig the logs |
| 13:29 |
VanessaE |
if someone produces a texture or feature that's terrible, I will yell about it until they fix it or provide a way to disable it. |
| 13:30 |
VanessaE |
in the case of those texture maps, it's absolutely critical that they be as good as possible if they're gonna be there as a default feature. |
| 13:31 |
VanessaE |
and a blurry or rounded looking texture is not good. |
| 13:31 |
VanessaE |
as far as I can remember that's the only complaint I had with those particular textures. |
| 13:31 |
kilbith |
that was rather repetitive injections for reverting |
| 13:31 |
VanessaE |
as for my PR I understand why it was reverted, however it was apparently NOT against the rules to put it in. |
| 13:32 |
kilbith |
http://dev.minetest.net/minetest_game_Development |
| 13:33 |
kilbith |
it's not because it comes from miss ezekowitz that the rules should be tilted for her |
| 13:33 |
kilbith |
people had always to comply with the rules and won't change |
| 13:34 |
kilbith |
at the time BlockMen reverted easily commit that haven't another +1, whatever if it was minor or not |
| 13:35 |
kilbith |
the benevolent father of _game is gone, people are getting insolently commit-friendly |
| 13:36 |
est31 |
yea, a benevolent father is good to have, less fighting, if things are aligned to one person's preferences |
| 13:39 |
kilbith |
as for the VE's injonctions for revert things she subjectively don't like : http://irc.minetest.ru/minetest-dev/2015-07-13#i_4321680 |
| 13:40 |
kilbith |
not even in a suggestive mean... |
| 13:40 |
VanessaE |
yeah, just as I stated |
| 13:40 |
VanessaE |
be was trying to push through blurry images. |
| 13:40 |
kilbith |
it sounded like an order |
| 13:40 |
kilbith |
no, it *was* an order |
| 13:40 |
VanessaE |
well it wasn't. in normal english parlance, "you have got to X" used in this context means "this is terrible, PLEASE undo it" |
| 13:41 |
kilbith |
err, look around for the other input containing "revert" |
| 13:41 |
kilbith |
that's literally an harassing |
| 13:42 |
kilbith |
not even only for this day, not even for this channel |
| 13:43 |
VanessaE |
what you don't see in the logs is the the private discussions I usually have with him, sometimes others, to clarify the whole thing without polluting the public log with useless discussion |
| 13:44 |
kilbith |
... and ? good strategy for re-writing the history |
| 13:44 |
VanessaE |
RBA has said unequivocally that my input is valuable to him. |
| 13:44 |
nrzkt |
VanessaE: did you use RFID or Wi-Fi for you wireless discussions ? |
| 13:44 |
VanessaE |
nrzkt: huh> |
| 13:44 |
VanessaE |
? |
| 13:44 |
kilbith |
people can't check the private part, re-writing the history is easy |
| 13:44 |
nrzkt |
lol... i read wireless instead of useless, i need to clean my eyes :p |
| 13:44 |
VanessaE |
haha |
| 13:44 |
* VanessaE |
hands nrzkt some new reading glasses :) |
| 13:47 |
|
Robert_Zenz joined #minetest-dev |
| 13:52 |
VanessaE |
as for rewriting history, the discussion for that was entirely in public |
| 13:58 |
|
leat joined #minetest-dev |
| 14:02 |
est31 |
so, as we give every random person who comes along with a crash the blocker label, I've labeled some further bug reports: https://github.com/minetest/minetest/labels/blocker |
| 14:02 |
est31 |
please complete the list with more bugs |
| 14:42 |
VanessaE |
celeron55, can you please weigh in on #611 ? Let's end this damned debate about the origin of the game's jungle tree. |
| 14:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/611 -- Animation blending. by blue42u |
| 14:42 |
VanessaE |
er |
| 14:42 |
VanessaE |
game 611 |
| 14:42 |
VanessaE |
game#611 damn it. |
| 14:42 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/611 -- Junglewood texture too light, boring |
| 14:47 |
|
leat joined #minetest-dev |
| 14:49 |
celeron55 |
well i prefer whatever is the most faithful to the original |
| 14:50 |
celeron55 |
because it's one of the textures i used some time actually designing |
| 14:51 |
celeron55 |
altough it is kind of weird 8) |
| 14:51 |
celeron55 |
but it's my kind of weird! |
| 14:52 |
VanessaE |
heh |
| 14:52 |
VanessaE |
well in this case I meant the species that you patterned it after :) |
| 14:53 |
VanessaE |
see also game#619 for my proposal (I just want to replace the wood with an image kilbith came up with, and tried to derive a matching tree top) |
| 14:53 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/619 -- Better jungle wood and jungle tree top textures by VanessaE |
| 14:55 |
celeron55 |
well i threw a comment in there |
| 14:55 |
celeron55 |
maybe it helps |
| 15:04 |
|
hmmmm joined #minetest-dev |
| 15:11 |
|
SopaXorzTaker joined #minetest-dev |
| 15:17 |
|
leat joined #minetest-dev |
| 15:21 |
hmmmm |
jeez, delaying a release is not equivalent to never releasing |
| 15:22 |
hmmmm |
I already did the same thing one time and guess what, it was a disaster |
| 15:22 |
hmmmm |
and everybody else even supported the idea of a new release |
| 15:33 |
|
est31 joined #minetest-dev |
| 15:34 |
est31 |
hmmmm, why do you want to delay the release? |
| 15:34 |
hmmmm |
because it's half-baked |
| 15:34 |
est31 |
is there any bug thats so severe we cant release? |
| 15:34 |
hmmmm |
there are too many reviews |
| 15:34 |
hmmmm |
err |
| 15:34 |
hmmmm |
too many problems |
| 15:35 |
est31 |
are there less problems, than e.g. for 0.4.11? |
| 15:35 |
est31 |
or 0.4.10? |
| 15:35 |
hmmmm |
it's like serving people half-raw chicken |
| 15:35 |
hmmmm |
yes |
| 15:35 |
est31 |
so LESS problems |
| 15:35 |
est31 |
? |
| 15:35 |
hmmmm |
in both of those releases we didn't know about blatant crashes or things taking down a server every 3 to 4 hours |
| 15:36 |
est31 |
why can't it wait for 0.4.14 |
| 15:36 |
est31 |
you want to rush the bugfixes |
| 15:36 |
est31 |
and make them inproperly |
| 15:36 |
hmmmm |
i don't actually understand what the reason is why there needs to be a release so badly |
| 15:36 |
hmmmm |
est31, out of everybody here, you're actually the ONLY one to want a release right now |
| 15:37 |
est31 |
am I? |
| 15:37 |
hmmmm |
yes |
| 15:37 |
est31 |
so then lets blow it off |
| 15:37 |
hmmmm |
why don't we |
| 15:37 |
est31 |
no release until 2016 |
| 15:37 |
est31 |
until then we have freeze |
| 15:38 |
est31 |
then minetest is proper |
| 15:38 |
est31 |
finally |
| 15:38 |
hmmmm |
oh my god this is RBA level bullshit |
| 15:38 |
hmmmm |
come on |
| 15:38 |
est31 |
so you want a release? |
| 15:38 |
est31 |
yes or no |
| 15:38 |
est31 |
and when do you want it |
| 15:39 |
est31 |
name me a date |
| 15:39 |
|
leat joined #minetest-dev |
| 15:39 |
hmmmm |
one week from now |
| 15:39 |
est31 |
lets say two, so that we have time |
| 15:39 |
|
nrzkt joined #minetest-dev |
| 15:39 |
VanessaE |
one or two weeks -- unless we find a reason to delay again |
| 15:39 |
est31 |
august 24? |
| 15:40 |
hmmmm |
whichever you prefer |
| 15:40 |
est31 |
VanessaE, no additional delays |
| 15:40 |
est31 |
we can have three weeks if you want |
| 15:40 |
VanessaE |
est31: what if some critical bug pops up right before release, as a result of another bug fix? |
| 15:40 |
est31 |
lets determine it NOW |
| 15:40 |
hmmmm |
but jesus christ, it's like not only are you taking the half-cooked chicken out of the oven, but you're trying to cram it down your customers' throats |
| 15:40 |
VanessaE |
you know fix one, create two, that sorta thing. |
| 15:40 |
est31 |
ok, but only new bugs |
| 15:40 |
est31 |
not existing ones |
| 15:41 |
est31 |
thats what you say VanessaE? |
| 15:41 |
VanessaE |
yes basically. |
| 15:41 |
est31 |
ok august 23 then, people like sundays more it seems |
| 15:42 |
est31 |
and possible delays if more critical bugs pop up |
| 15:42 |
VanessaE |
fine. |
| 15:42 |
VanessaE |
but now: |
| 15:43 |
VanessaE |
what's the *real* list of bugs that must be fixed by then? |
| 15:43 |
est31 |
next thing: no bug wishlists, but actual lists which bugs we deem as "blocking" |
| 15:43 |
est31 |
ninja'd lol :D |
| 15:43 |
VanessaE |
well that's actually what I was referring to |
| 15:43 |
VanessaE |
I saw where you tagged a lot of issues as blocker |
| 15:43 |
VanessaE |
I wasn't sure if some of those were so-tagged out of frustration, irritation, or legitimate. |
| 15:44 |
est31 |
more to show that we did have crashes before |
| 15:44 |
VanessaE |
ok |
| 15:44 |
est31 |
and that giving the blocker label is easy |
| 15:45 |
est31 |
and if you just dont want to release, pressing the blocker label button is even easier |
| 15:46 |
VanessaE |
but that raises the question: why should a crash bug skip multiple releases? |
| 15:46 |
VanessaE |
rather, "if not now, when?" |
| 15:46 |
VanessaE |
(don't get me wrong, I understand perfectly well that some stuff can be a real bitch to fix) |
| 15:49 |
VanessaE |
at what point do you say "Ok, that's it - there's no way in hell we can make another release until old bugs X, Y and Z are fixed once and for all" ? |
| 15:49 |
est31 |
that's what bugfix releases are for |
| 15:50 |
hmmmm |
again the whole point of it is |
| 15:50 |
hmmmm |
we never released while in a state where we KNEW that something was crashing, and was a common problem |
| 15:51 |
est31 |
what are common problems in your eyes? |
| 15:51 |
est31 |
please, github numbers only |
| 15:51 |
VanessaE |
hmmmm: right, however we did release in a few cases where there was an irritating, common problem that *didn't* result in a crash |
| 15:51 |
VanessaE |
(for example we nearly released 0.4.13 with that extruded wield mesh glitch) |
| 15:51 |
est31 |
firefox too has a list of "known bugs" on every release |
| 15:52 |
est31 |
but agreed, if there is a bug that makes minetest crash all 4 hours, its inacceptable |
| 15:52 |
hmmmm |
#3027 and #3011 at least |
| 15:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/3027 -- PcgRandom crashes the application. |
| 15:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/3011 -- Sometimes, you get "Lua: error in error handling" messages. Is the (non-handling) error caused by the engine? |
| 15:53 |
hmmmm |
these are really obvious bugs |
| 15:53 |
hmmmm |
big bugs |
| 15:53 |
hmmmm |
3011 is hard to track down but it happens every 3-4 hours |
| 15:53 |
est31 |
ok, agree |
| 15:53 |
VanessaE |
*nod* |
| 15:53 |
hmmmm |
and then delete_area() needs to be fixed |
| 15:53 |
hmmmm |
this was introduced in 0.4.12-dev |
| 15:53 |
hmmmm |
*not before* |
| 15:53 |
est31 |
delete_area? |
| 15:53 |
est31 |
its older than 0.4.12 |
| 15:53 |
hmmmm |
minetest.delete_area() |
| 15:53 |
hmmmm |
it is? |
| 15:53 |
* hmmmm |
goes to look |
| 15:54 |
est31 |
https://github.com/minetest/minetest/blob/0.4.12/doc/lua_api.txt#L1885 |
| 15:54 |
est31 |
ok, addition of 0.4.12 it seems |
| 15:54 |
hmmmm |
when was 0.4.12 released |
| 15:55 |
hmmmm |
feb 18th |
| 15:55 |
hmmmm |
okay so i guess you're right |
| 15:55 |
hmmmm |
didn't seem that long ago |
| 15:55 |
est31 |
time flies :/ |
| 15:57 |
hmmmm |
6/6/2013 - 11/24/2013 - 1/1/1024 - 7/6/2014 - 12/26/14 - 2/18/15 - 8/18/15 |
| 15:57 |
hmmmm |
just looking at the timeline of releases |
| 15:57 |
Calinou |
1024 heh |
| 15:58 |
VanessaE |
Calinou: well he likes nice round numbers :) |
| 15:58 |
hmmmm |
5.5 months, 1 month, 6 months, 5 months, 3 months, 6 months |
| 15:58 |
hmmmm |
sorry 1024 just gets typed more naturally than 2014 |
| 15:58 |
est31 |
heh lol |
| 15:58 |
est31 |
yea it does indeed |
| 15:58 |
hmmmm |
I really don't think that 0.4.13 is taking too long |
| 15:59 |
est31 |
you convinced me |
| 15:59 |
hmmmm |
you can see there have been releases that were clearly rushed in the past and another release was made a month later to fix it |
| 15:59 |
hmmmm |
the thing is though |
| 15:59 |
hmmmm |
the general public sees our big nasty bugs |
| 15:59 |
hmmmm |
and they form opinions about minetest |
| 16:00 |
hmmmm |
the opinions are not positive |
| 16:01 |
est31 |
what do you mean with "big nasty"? |
| 16:01 |
hmmmm |
crashing sort of stuff |
| 16:02 |
est31 |
the fact that 0.4.12 generates shadow fields everywhere, which is fixed now? |
| 16:02 |
hmmmm |
minetest becomes known as "that minecraft ripoff that crashes every couple of hours" |
| 16:02 |
VanessaE |
is not fixed. |
| 16:02 |
est31 |
further bugs of 0.4.12? |
| 16:02 |
hmmmm |
"hah, the chinese must've ripped off minecraft" |
| 16:02 |
hmmmm |
"it's so poorly made" |
| 16:03 |
est31 |
the reviews I've seen in the internet say "minetest doesn't have the features of minecraft, but for people who like minecraft alpha, its a nice nostalgic journey" |
| 16:03 |
VanessaE |
I still get random, square, black shadows on my worlds from time to time. not super-common, but occasional and out of nowhere in areas already generated. Easily fixed with worldedit thankfully. |
| 16:03 |
hmmmm |
yeah |
| 16:04 |
est31 |
admittedly, most of those reviews are outdated |
| 16:04 |
VanessaE |
I'd take that as a negative review frankly. |
| 16:04 |
hmmmm |
the shadow thing wasn't as big of a deal IMHO because it didn't /crash/ |
| 16:04 |
hmmmm |
and it's pretty difficult to solve |
| 16:04 |
VanessaE |
given that we're trying to build something here that's definitely not merely "minecraft alpha/nostalgic" quality |
| 16:04 |
est31 |
crashes are difficult to solve too |
| 16:04 |
est31 |
quality or feature set VanessaE? |
| 16:05 |
VanessaE |
both. |
| 16:05 |
est31 |
the reviewers complained about the feature set. |
| 16:05 |
hmmmm |
what i plan on working on next version should actually fix this for real along with any other mapchunk dependency ordering-class problems |
| 16:05 |
est31 |
you mean after the bugfix version 0.4.14 or whatever it's called? |
| 16:05 |
VanessaE |
most revies I've seen, when there was a complaint, it was of a general quality nature - i.e. the game feels buggy or "laggy" (usually low FPS) or some other nebulous thing. |
| 16:05 |
hmmmm |
hmm |
| 16:06 |
hmmmm |
est, we'll do things normally for one more version |
| 16:06 |
hmmmm |
0.4.14 should have bugfixes/improvements for 0.4.13's new features |
| 16:06 |
est31 |
"normally"? |
| 16:06 |
hmmmm |
normally as in |
| 16:07 |
hmmmm |
we'll resume with adding new features next version |
| 16:08 |
est31 |
this way we never get stable |
| 16:09 |
est31 |
we have to freeze for months, or we wont get into a state VanessaE and others deem as "bug free" |
| 16:09 |
|
kilbith joined #minetest-dev |
| 16:10 |
hmmmm |
well |
| 16:10 |
VanessaE |
when did I say "bug free"? |
| 16:10 |
est31 |
"ok for release" |
| 16:10 |
est31 |
dunno, hmmmm said it |
| 16:10 |
hmmmm |
i just don't want to be embarassed if i tell somebody that i work on minetest |
| 16:10 |
est31 |
lemme see |
| 16:11 |
hmmmm |
and they try it out |
| 16:11 |
VanessaE |
to me, "ok for release" == "no nasty, major bugs that are gonna piss off the userbase" :) |
| 16:11 |
hmmmm |
oh god that's my biggest fear |
| 16:11 |
hmmmm |
i don't want people who know me IRL to look at minetest |
| 16:11 |
VanessaE |
heh |
| 16:11 |
hmmmm |
why is my name stamped on this thing even |
| 16:11 |
est31 |
http://irc.minetest.ru/minetest-dev/2015-08-09#i_4357791 |
| 16:11 |
hmmmm |
"hey <name> I played around with it a while, it crashed when I did X" |
| 16:12 |
VanessaE |
well to be fair, hmmmm, at least people who know I work on it (as a modder) are pretty happy to hear. I'd say if that's the case, then you should be rather proud. |
| 16:12 |
hmmmm |
heh |
| 16:12 |
hmmmm |
that's because you don't work with the messy parts |
| 16:14 |
VanessaE |
true enough |
| 16:14 |
VanessaE |
BUT, the average person doesn't see the "messy" parts. |
| 16:14 |
VanessaE |
they just see that it works or doesn't (or fails after some time) |
| 16:15 |
VanessaE |
so a nasty, messy bodge like connection.cpp matters to us, but the user doesn't mind a little spaghetti as long as it tastes good. |
| 16:16 |
hmmmm |
they'd get a bug in their spaghetti every once in a while with that connection.cpp :) |
| 16:16 |
hmmmm |
that's enough to make me throw up |
| 16:16 |
hmmmm |
and probably a call from the health inspectors |
| 16:17 |
VanessaE |
lol |
| 16:23 |
est31 |
ok hmmmm VanessaE #3031 |
| 16:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/3031 -- Critical bugs to be fixed before 0.4.13 |
| 16:23 |
VanessaE |
in any case you've put a ton of work into the project, and it's objectively better for it, so you should be proud at least of that much, even if the current state of the code is less than stellar. |
| 16:28 |
est31 |
suggest further bugs |
| 16:29 |
est31 |
but we need an actual list of bugs |
| 16:29 |
est31 |
vague ideas are bad |
| 16:32 |
|
Krock joined #minetest-dev |
| 16:42 |
|
Hunterz joined #minetest-dev |
| 16:50 |
est31 |
sigh |
| 16:51 |
est31 |
I try to assemble an actual list of bugs to be fixed until 0.4.13, and I just get the reply "use the blocker label" |
| 16:54 |
VanessaE |
take the compromise: if it has a blocker label now, either add it to your list or remove the blocker label |
| 16:55 |
VanessaE |
and put them in a task list that can be checked off |
| 16:56 |
VanessaE |
(I think the markdown for that is "[ ] Fix crash foo in barBlah()" ) |
| 16:58 |
est31 |
VanessaE, do you propose additional bugs to be added? |
| 16:58 |
VanessaE |
not precisely. lemme skim through the list again. |
| 16:59 |
|
ripper93 joined #minetest-dev |
| 17:00 |
ripper93 |
Hello everyone. This is the channel where I can report a problem with the dev wiki? |
| 17:01 |
VanessaE |
ripper93: as long as it's not "I can't create an account because no kitten captcha" :) |
| 17:01 |
ripper93 |
VanessaE: lol, never mind then. |
| 17:01 |
VanessaE |
ripper93: in which case, ask Calinou to create one for you :) |
| 17:02 |
est31 |
/msg Calinou e-mail address |
| 17:02 |
ripper93 |
VanessaE: thank you. |
| 17:02 |
Calinou |
hi |
| 17:02 |
ripper93 |
est31: this means I should send my e-mail address for him in a private message? |
| 17:03 |
est31 |
yes |
| 17:03 |
Calinou |
ripper93, in the PM, specify e-mail, desired username (MediaWiki will add an uppercase character automatically at the first character) |
| 17:03 |
est31 |
and I think its her |
| 17:03 |
Calinou |
and whether you want an account for regular wiki, dev wiki, or both |
| 17:03 |
Calinou |
est31, him* |
| 17:03 |
est31 |
ok |
| 17:04 |
VanessaE |
est31: how about this one: https://github.com/minetest/minetest/issues/2984 |
| 17:04 |
VanessaE |
it's not a regression, but rather a skin compat failure |
| 17:04 |
est31 |
it is a valid bug I agree |
| 17:05 |
est31 |
but its rather something for github's milestone feature |
| 17:05 |
est31 |
you like to have it, but perhaps you like to procrastinate it too |
| 17:09 |
VanessaE |
ok this one I can confirm: #2964 |
| 17:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/2964 -- right click and drag inventory bug |
| 17:10 |
est31 |
the question is whether this is a bug |
| 17:10 |
est31 |
e.g. whether it is actually desired behaviour |
| 17:10 |
VanessaE |
if it doesn't work the way users expect, it's a bug imho |
| 17:10 |
VanessaE |
well that's not strictly tue |
| 17:10 |
VanessaE |
true* |
| 17:11 |
est31 |
just you know, pushing things back, then forth, then back again is time waste imo |
| 17:11 |
est31 |
and at the end of the day you dont even release |
| 17:11 |
VanessaE |
but in this case, you try to use the feature and it just acts weird even to seasoned users. An implementation failure, you could call it since it's trying to mimic a feature in MC./ |
| 17:11 |
est31 |
even more waste |
| 17:12 |
|
twoelk joined #minetest-dev |
| 17:13 |
VanessaE |
#2945 |
| 17:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/2945 -- Immortal/Zombie Glitch |
| 17:13 |
VanessaE |
ok this one is a definite gameplay breaker. |
| 17:13 |
VanessaE |
but as you said, it's not new |
| 17:19 |
VanessaE |
I think you can close #2690 .. it's been fixed hasn't it? |
| 17:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/2690 -- positions of particle_spawner output not entirely accurate |
| 17:20 |
est31 |
I think no, im not sure |
| 17:29 |
VanessaE |
anything else I could suggest would be among the ones labeled as blocker. |
| 17:40 |
|
MinetestForFun joined #minetest-dev |
| 17:49 |
|
kaeza2 joined #minetest-dev |
| 17:51 |
|
FR^2 joined #minetest-dev |
| 17:55 |
|
kaeza joined #minetest-dev |
| 18:16 |
|
blaise joined #minetest-dev |
| 18:20 |
|
nore joined #minetest-dev |
| 18:21 |
|
nore_ joined #minetest-dev |
| 18:21 |
|
nore_ left #minetest-dev |
| 18:38 |
|
lag01 joined #minetest-dev |
| 18:45 |
|
blaise joined #minetest-dev |
| 19:01 |
|
est31 joined #minetest-dev |
| 19:02 |
est31 |
hmmmm, kahrl what's your preferred way to make heaps? |
| 19:02 |
est31 |
I want to fix this leak paramat keeps pointing to |
| 19:02 |
est31 |
so I need to order mapblocks now by their last used time |
| 19:02 |
est31 |
(last used for rendering) |
| 19:02 |
|
kaeza joined #minetest-dev |
| 19:03 |
est31 |
and then I've planned to delete mapblocks older than a specified amount of seconds |
| 19:03 |
est31 |
err |
| 19:03 |
est31 |
delete mapblocks that are over a given count |
| 19:03 |
est31 |
e.g. 1000 mapblocks are allowed to be loaded, not more |
| 19:04 |
VanessaE |
est31: what about also freeing them based on distance from the player? |
| 19:04 |
est31 |
not good |
| 19:04 |
est31 |
a day ago you suggested to add travelnets to mtgame |
| 19:04 |
VanessaE |
mmhmm |
| 19:05 |
|
MinetestForFun joined #minetest-dev |
| 19:06 |
VanessaE |
but I am thinking more a multiplier - i.e. if max(age_seconds,0)*max(distance_meters, 0) is greater than some reasonable threshold, delete the block |
| 19:06 |
VanessaE |
and if the count is over 1000, delete strictly by age |
| 19:07 |
est31 |
if you limit by count only, the leak is gone |
| 19:07 |
est31 |
so distance metric not needed |
| 19:08 |
VanessaE |
true |
| 19:09 |
VanessaE |
but if you also limit by age and distance, you reduce the total memory in use, for example of a typical player who teleports back and forth between his/her home and mine |
| 19:09 |
VanessaE |
in theory one shouldn't need more than a few hundred mapblocks loaded in that case - for that user anyway |
| 19:10 |
est31 |
travelnets are much like quotient space identifications of points |
| 19:10 |
est31 |
the metric needs to be updated |
| 19:11 |
VanessaE |
in that example, the blocks' age would be fairly low, enough to keep even a large distance from exceeding the unload threshold. |
| 19:11 |
VanessaE |
in any case limiting it by count alone is enough for now |
| 19:11 |
VanessaE |
the rest can be worked out later. |
| 19:14 |
hmmmm |
no don't add travelnet to mtgame until the error in error handling gets fixed |
| 19:14 |
VanessaE |
of course, there's network bandwidth to consider - the less you keep loaded, the more you have to re-transfer as the old blocks expire. if the client would cache the received data and only query the server for newly-changed blocks (based on timestamp, not content) then it wouldn't matter how many the client keeps on hand |
| 19:15 |
est31 |
well yeah |
| 19:16 |
VanessaE |
hmmmm: agreed, though I think that was more the result of using any generic teleporter between two points on the map |
| 19:16 |
est31 |
but that goes in the feature domain |
| 19:16 |
VanessaE |
(i.e. how that would affect how many blocks are loaded) |
| 19:16 |
est31 |
hmmmm, fully agree |
| 19:18 |
est31 |
hmmmm, does std::priority_queue sound goo? |
| 19:18 |
est31 |
good* |
| 19:18 |
hmmmm |
I don't know, I guess |
| 19:18 |
hmmmm |
whatever works |
| 19:18 |
est31 |
also, should I rather implement a custom type to get the comparisons, or should I implement a custom comparator |
| 19:19 |
est31 |
I need it to store 1. the useagetimer |
| 19:19 |
hmmmm |
est, the thing is, mapblocks are already deleted |
| 19:19 |
est31 |
2. the mapblock |
| 19:20 |
est31 |
and 3. the mapsector |
| 19:20 |
est31 |
while 1 isnt required |
| 19:20 |
est31 |
it can be read from the mapblock already |
| 19:20 |
est31 |
its one pointer dereference and method call |
| 19:21 |
est31 |
hmmmm, they are, just they are deleted by time, not by how much there are |
| 19:21 |
hmmmm |
so do you know if that's the actual problem?? |
| 19:22 |
est31 |
I've set the time to 10 seconds, and the blocks got deleted |
| 19:22 |
est31 |
but setting time that low is bad again, because of the server |
| 19:22 |
est31 |
instead we should allocate as much blocks as we can, and only delete if there is no more room |
| 19:22 |
est31 |
people can adjust it then in their settings |
| 19:23 |
hmmmm |
sounds good to me |
| 20:09 |
TBC_x |
hey, aren't the too-far-away mapblocks sitting in memory uncompressed |
| 20:09 |
TBC_x |
? |
| 20:11 |
est31 |
yes |
| 20:11 |
TBC_x |
why not to do all caching compressed? |
| 20:11 |
est31 |
thats a feature |
| 20:12 |
TBC_x |
well... memory overuse is not a bug? |
| 20:12 |
est31 |
I just delete them |
| 20:13 |
est31 |
no need to do fancy compressing |
| 20:13 |
est31 |
also its hard to find out how far away mapblocks really are for clients |
| 20:13 |
est31 |
as they can teleport around |
| 20:14 |
TBC_x |
I think the most offenders are underground, never actually seen by the player |
| 20:14 |
TBC_x |
therefore I think that a server could use some form of occulsion culling (if that's the correct term) |
| 20:15 |
est31 |
it is |
| 20:15 |
est31 |
and currently the client manages it |
| 20:15 |
TBC_x |
oh, okay |
| 20:17 |
TBC_x |
is there any kind of statistics of visible vs loaded blocks? |
| 20:19 |
est31 |
yes |
| 20:19 |
est31 |
either turn on infostream |
| 20:19 |
est31 |
@ least loaded blocks) |
| 20:19 |
est31 |
( |
| 20:20 |
est31 |
or edit map.cpp, change infostream to actionstream in Map::timerUpdate |
| 20:20 |
est31 |
and remove the deleted_count != 0 case for if |
| 20:20 |
TBC_x |
and I expect that too-far-away mapblocks deallocate their meshes |
| 20:25 |
est31 |
its damn hard to find out what too far away means |
| 20:26 |
est31 |
because if you have a travelnet, and teleport back and forth, you have a problem |
| 20:26 |
est31 |
you'll need to "cut" the distance here |
| 20:26 |
est31 |
its better to manage them based on count |
| 20:27 |
TBC_x |
for mapblock meshes I would say that renderable distance |
| 20:27 |
TBC_x |
for any meshes |
| 20:28 |
TBC_x |
teleportation would just skip mapblock download |
| 20:29 |
est31 |
#3033 |
| 20:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/3033 -- Add count based unload limit for mapblocks by est31 |
| 20:52 |
|
lag01 joined #minetest-dev |
| 22:30 |
|
cheapie joined #minetest-dev |
| 22:50 |
|
nore_ joined #minetest-dev |
| 22:50 |
|
Guest26086 joined #minetest-dev |
| 22:50 |
|
Guest26086 left #minetest-dev |
| 23:19 |
|
Lunatrius joined #minetest-dev |
| 23:27 |
|
Sokomine joined #minetest-dev |
| 23:49 |
|
Taoki_1 joined #minetest-dev |
