| Time |
Nick |
Message |
| 00:34 |
|
crazyR joined #minetest-dev |
| 00:36 |
|
est31 joined #minetest-dev |
| 01:21 |
|
Player-2 joined #minetest-dev |
| 02:05 |
|
est31 joined #minetest-dev |
| 02:37 |
|
DI3HARD139 joined #minetest-dev |
| 03:34 |
|
Hunterz joined #minetest-dev |
| 04:07 |
|
paramat joined #minetest-dev |
| 04:10 |
|
Zeno` joined #minetest-dev |
| 04:18 |
|
DFeniks_ joined #minetest-dev |
| 04:19 |
paramat |
hi hmmmmm please can you leave generateBiomes in the mapgens? it's essential that each is customisable for each mapgen. i'm requesting this now to save you the work. although 4 mapges have identical generateBiomes, mgvalleys doesn't, mgwatershed and new mapgens will be increasingly specialised (i have a space mapgen planned), generateBiomes will be increasingly customised and use more variables from the mapgen |
| 04:20 |
paramat |
soon 3 from 7 mapgens will have customised genBiomes, some will be closely linked to each mapgen, so it makes more sense to leave them in each mapgen |
| 04:21 |
paramat |
instead we can have multiple versions of getBiome(x, [y], z) called from these to allow different types of biome calculations |
| 04:26 |
sofar |
at mapgen time or after? |
| 04:26 |
paramat |
i've worked on mgwatershed for a year and will merge it after release. it will be multi-levelled, getBiome(x, y, z) will not use y relative to water_level, but will use y relative to the sea level of each realm. this means genBiomes will be using more variables from the mapgen |
| 04:27 |
paramat |
sofar you're referring to what? |
| 04:27 |
sofar |
getBiome(x, [y], z) |
| 04:28 |
sofar |
is it getting exposed to lua? |
| 04:28 |
paramat |
that's during mapgen as the biome material is placed |
| 04:28 |
paramat |
no, this is c++ stuff |
| 04:28 |
sofar |
I still want to have a post-mapgen lua api for it |
| 04:28 |
sofar |
not just me :) |
| 04:28 |
paramat |
oh yes so do i |
| 04:28 |
sofar |
ok |
| 04:29 |
paramat |
it can be done easily by calculating heat/humid noises for that point |
| 04:29 |
paramat |
most of the code is already there in mgv7 |
| 04:29 |
paramat |
just the API needs adding |
| 04:30 |
sofar |
could you cache it in the mapblock (but not save it to disk) to speed up multiple accesses? |
| 04:30 |
hmmmmm |
paramat, I believe you are fundamentally misunderstanding the goal of my work |
| 04:31 |
paramat |
maybe, i'm just asking that genBiomes is left in the mapgens |
| 04:31 |
hmmmmm |
sure, but it does evenetually need to get deduplicated |
| 04:31 |
hmmmmm |
all of the modern mapgens are essentially v7 clones |
| 04:32 |
paramat |
to a degree |
| 04:32 |
hmmmmm |
for mapgens that do have slight differences, like valleys, maybe you should consider a way to modify a genericized interface that captures that specific difference |
| 04:33 |
paramat |
i don't mind the 4 identical genBiomes being combined and centralised |
| 04:33 |
hmmmmm |
as it stands right now this is bad coding practice |
| 04:33 |
hmmmmm |
it quadruples the chances of bugs being introduced by accident |
| 04:34 |
paramat |
yes indeed, for the duplicated ones |
| 04:34 |
paramat |
the ability to have a custom genBiomes *in the mapgen file* is essential |
| 04:35 |
paramat |
it already is for 2 mapgens, and will be increasingly in future |
| 04:36 |
hmmmmm |
i don't think it's actually necessary for valleys mapgen |
| 04:36 |
hmmmmm |
all you need is a bit more clever of a design |
| 04:36 |
paramat |
well the river_water stuff could be added to the other 4, but it will be unused code |
| 04:37 |
paramat |
mgwatereshed and others will need more complex cusomisations which will not be combinable |
| 04:38 |
paramat |
(watershed) |
| 04:39 |
hmmmmm |
so let's take valleys as an example |
| 04:39 |
hmmmmm |
there are some misunderstandings here |
| 04:39 |
hmmmmm |
the purpose of generateTerrain is to generate the shape of the terrain using three basic node types, the stone node type, water, and air |
| 04:40 |
paramat |
and river water |
| 04:40 |
hmmmmm |
the purpose of generateBiome is to replace the placeholder stone, water, and air nodes with the biome specific nodes |
| 04:40 |
paramat |
that's the 4th base terrain node |
| 04:40 |
hmmmmm |
it's not... |
| 04:40 |
paramat |
it is |
| 04:40 |
hmmmmm |
you made it that way but that simply isn't the intended design |
| 04:41 |
paramat |
river water is a base node replaced by genBiome |
| 04:41 |
hmmmmm |
i cannot understand the reason it should be. |
| 04:41 |
paramat |
rivers have to be placed during baseterrain gen |
| 04:42 |
paramat |
the whole mapgen is shaped around them |
| 04:42 |
hmmmmm |
the originally intended purpose of generateTerrain is to generate the basic shape though |
| 04:42 |
hmmmmm |
not place the specific permanent node types |
| 04:42 |
paramat |
they could be filled with normal water but then you lose the ability to differentiate the river from the ocean, essential for glacier etc |
| 04:42 |
hmmmmm |
now there are two non-basic nodes being placed in valleys' generateTerrain, sand and river water |
| 04:43 |
hmmmmm |
it seems to me like this could be abstracted away by using voxelmanip flags |
| 04:43 |
paramat |
yes i admit the sand is hacky |
| 04:43 |
hmmmmm |
what you're actually trying to say here is, "hey this node is part of a river" |
| 04:43 |
paramat |
it was a hack to avoid other problems |
| 04:44 |
paramat |
we can improve that agreed |
| 04:44 |
hmmmmm |
so one of the key advantages of having cleanly designed code is that it becomes easily to compartmentalize |
| 04:44 |
paramat |
but river water being a 4th base terrain node is essential |
| 04:45 |
hmmmmm |
you can compartmentalize generateTerrain to do one thing - generate the basic shape of the terrain |
| 04:45 |
hmmmmm |
and then you can have biomes do one thing - replace the basic shape with biome-specific nodes |
| 04:45 |
hmmmmm |
then you *could* have another function specific to valleys mapgen that does one thing - forms the nodes of the river |
| 04:46 |
paramat |
it's much cleaner and simpler for that to be part of genBiomes |
| 04:46 |
hmmmmm |
by doing this you're able to isolate the chunks of code that are unique to that mapgen |
| 04:46 |
paramat |
ok i understand |
| 04:46 |
hmmmmm |
by isolating chunks of code that are different, you're free to combine pieces of code that are the same |
| 04:47 |
hmmmmm |
sure, i agree it might be simpler |
| 04:47 |
paramat |
it's much better to have an entire customised genBiomes for mgvalleys |
| 04:47 |
hmmmmm |
but so would everything if it were written in such a concrete manner with no regard to abstraction or inheritance |
| 04:48 |
hmmmmm |
how about this |
| 04:48 |
hmmmmm |
i'll clean up mgvalleys and retain the same exact functionality without removing anything or breaking anything |
| 04:48 |
paramat |
nope, i don't mind ores, decos being combined and centralised, genBiomes is difeferent, remember i understand it more than you |
| 04:48 |
hmmmmm |
then you can be the judge of whether or not it was worth it |
| 04:48 |
paramat |
(different) |
| 04:49 |
paramat |
yeah agreed |
| 04:49 |
paramat |
but the same may not be possible for mgwatershed or a space mapgen |
| 04:49 |
hmmmmm |
i wouldn't expect it to be |
| 04:50 |
hmmmmm |
maybe that's a place where specialization is actually necessary |
| 04:50 |
paramat |
so, we still need the option of a custom genBiomes *in the mapgen file* |
| 04:50 |
hmmmmm |
for 6/7 of the mapgens it'd suffice to inherit 90% of the code from MapgenV7 |
| 04:50 |
hmmmmm |
paramat, do you understand what the keyword "virtual" means? |
| 04:51 |
paramat |
not much |
| 04:51 |
hmmmmm |
ok. that seems to be where the misunderstanding stems from. |
| 04:51 |
hmmmmm |
i just want this to be clear |
| 04:51 |
hmmmmm |
i am not taking away your toys |
| 04:51 |
hmmmmm |
i'm just putting them back in order in your room |
| 04:52 |
paramat |
lol |
| 04:53 |
hmmmmm |
you should read up on 'virtual'. |
| 04:54 |
paramat |
ok. until then could you confirm that a heavily customised genBiomes in the maogen file will still be possible? |
| 04:54 |
hmmmmm |
..yes |
| 04:54 |
paramat |
(Chairman Mao gen again) |
| 04:55 |
paramat |
ok cool |
| 04:55 |
hmmmmm |
what i'm frustrated about with valleys is how it's cemented to this single biome implementation |
| 04:55 |
paramat |
well i admit mgvalleys is a nightmare |
| 04:55 |
paramat |
it hurts my head |
| 04:56 |
paramat |
my mapgens are beautifully clean in comparison |
| 04:56 |
hmmmmm |
i guess what i could do is simply not allow alternative biomegens to be used with mgvalley |
| 04:56 |
paramat |
that should be ok |
| 04:56 |
paramat |
it's very specialised, following the lua version |
| 04:58 |
paramat |
mgwatershed may have to be this way too |
| 04:59 |
paramat |
as my work on it is centred around the 'original' biome system |
| 04:59 |
paramat |
it will certinaly have a heavily custom genBiomes that will need to be in the mapgen file |
| 05:04 |
|
Hunterz joined #minetest-dev |
| 05:15 |
paramat |
hmmmm just to be clear, river water should remain a base terrain node placed in terrain generation. there's stone, air, gravity-settled mass liquid below a specific y (ocean), and downhill flowing non-settled liquid (rivers), it's fundamental enough to be a 4th base terrain node |
| 05:23 |
paramat |
biome definitions define a node to replace river water, in glacier biome rivers become ice |
| 05:32 |
paramat |
ok so virtual is about a mapgen being able to override a function in the base class :) |
| 05:33 |
paramat |
hmmmmm while you're at it, dustTopNodes can certainly be combined and centralised, it's identical in all (non-mgv6) mapgens, even mgvalleys and in mgwatershed too i think |
| 05:40 |
hmmmmm |
no kidding |
| 05:40 |
hmmmmm |
i'm convinced that 90% of each of the new mapgens can be condensed |
| 05:43 |
paramat |
we've discovered 2 old PRs with 2 approvals that were somehow forgotten #3267 #3977 will merge very soon if no objections. Zeno` |
| 05:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/3267 -- Standardize the menu button order and sizes by SmallJoker |
| 05:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/3977 -- Add basic_privs setting by rubenwardy |
| 05:43 |
paramat |
will merge with #4031 |
| 05:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/4031 -- Android menu: Unified serverlist by kilbith |
| 05:54 |
hmmmmm |
all three look good to merge |
| 05:55 |
hmmmmm |
actually hold off on 3977 |
| 05:56 |
hmmmmm |
doesn't lua interpret a blank string as an "empty" value? |
| 05:57 |
hmmmmm |
nevermind, it doesn't, i just checked. |
| 05:59 |
Zeno` |
3267 and 4031 seem fine (I was looking at them only about an hour ago actually) |
| 06:00 |
Zeno` |
I have no comment on 3977 but don't object either :P |
| 06:00 |
paramat |
hmmmm this is why i misunderstood http://irc.minetest.ru/minetest-dev/2016-04-26#i_4595531 |
| 06:01 |
paramat |
ok will merge all 3 |
| 06:01 |
Zeno` |
yay |
| 06:01 |
Zeno` |
then we can release tomorrow! |
| 06:01 |
paramat |
nope, see game |
| 06:02 |
paramat |
oh heh |
| 06:02 |
Zeno` |
I try not to look at the notifications for _game :) |
| 06:02 |
paramat |
anyway, freeze will probably be moved to end of weekend |
| 06:02 |
Zeno` |
delayed until end of weekend? |
| 06:03 |
paramat |
might be sooner |
| 06:04 |
Zeno` |
https://github.com/minetest/minetest/graphs/punch-card |
| 06:04 |
Zeno` |
looks like some kind of weird eye test |
| 06:07 |
paramat |
but which time zone, UTC? |
| 06:07 |
Zeno` |
no idea... looking at it started to make me dizzy so I closed it |
| 06:08 |
paramat |
looks like UTC or adjusted for local time, i can see euro and us shifts |
| 06:11 |
paramat |
#4032 needs review, i'm confident about it though, well tested |
| 06:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/4032 -- Mapgen: Make 3D noise tunnels' width settable by paramat |
| 06:13 |
paramat |
now merging to engine |
| 06:13 |
hmmmmm |
wait |
| 06:13 |
hmmmmm |
before you do that, could you remove the newliens you added between all the Mapgen<XX>Params *sp = ...; this->spflags = sp->spflags? |
| 06:13 |
hmmmmm |
newlines* |
| 06:14 |
hmmmmm |
this is horrible |
| 06:15 |
hmmmmm |
nevermind just merge as-is, i'm going to have to deal with all the merge conflicts |
| 06:15 |
hmmmmm |
and you understand that by merging this commit you will break existing valleys worlds, correct? |
| 06:18 |
Zeno` |
is it ok to break things like worlds and protocols in a minor releasE? |
| 06:19 |
sofar |
not really :D |
| 06:19 |
sofar |
depends on your definition of "breakage" too imho |
| 06:19 |
hmmmmm |
as i recall, the valleys mapgen was added within this development cycle |
| 06:19 |
hmmmmm |
so by definition it's unstable |
| 06:23 |
Zeno` |
what will break? |
| 06:24 |
Zeno` |
oh i see... |
| 06:27 |
paramat |
merged |
| 06:27 |
paramat |
i didn't merge 4032 |
| 06:28 |
paramat |
just the first 3 |
| 06:29 |
paramat |
yeah it will break any existing mgvalleys worlds using custom noises |
| 06:29 |
paramat |
i have put a post in forum explaining this and the workaround |
| 06:30 |
paramat |
and yeah mgvalleys was added during 0.4.13 and is unstable, better to correct this now rather than never |
| 06:30 |
Zeno` |
yes |
| 06:30 |
paramat |
i'll remove the newlines as you requested |
| 06:30 |
Zeno` |
and it's not a huge breakage anyway (from what I can understand) |
| 06:30 |
hmmmmm |
don't bother |
| 06:30 |
hmmmmm |
there are too many changes to avoid the merge conflicts |
| 06:31 |
paramat |
so your request is for avoiding conflict, not a code style issue? |
| 06:32 |
hmmmmm |
right |
| 06:32 |
paramat |
ok. btw it's ok for a dev to add own approval |
| 06:33 |
paramat |
my approval counts |
| 06:33 |
hmmmmm |
where does it say that |
| 06:33 |
paramat |
it's just not a 'code review by someone else' |
| 06:33 |
Zeno` |
it's always been that way |
| 06:33 |
paramat |
we can have another label for code approval if you want |
| 06:33 |
paramat |
we discussed this already |
| 06:33 |
hmmmmm |
WE did not |
| 06:33 |
hmmmmm |
it was me, gregory, and celeron |
| 06:33 |
Zeno` |
approval by two core devs means only one other core dev needs to approve if the PR is made my a core dev |
| 06:34 |
paramat |
c55 discussed it with you last time you objected |
| 06:34 |
paramat |
yeah |
| 06:34 |
Zeno` |
It's been that way for at least 2 years |
| 06:34 |
hmmmmm |
okay |
| 06:34 |
Zeno` |
But I don't see the point of adding your own "1 approval" label heh |
| 06:34 |
Zeno` |
seems redundant |
| 06:34 |
Zeno` |
we all know you're a core dev :P |
| 06:35 |
hmmmmm |
is there an argument for the current system other than "i've done it that way for a long time" ? |
| 06:35 |
paramat |
erm possibly redundant, but i don't add it if it's WIP |
| 06:35 |
paramat |
so it's useful this way |
| 06:35 |
hmmmmm |
you can have a "ready" label |
| 06:35 |
Zeno` |
hmmmmm, c55 says it cuts down on unnecessary work (which I agree with) |
| 06:35 |
paramat |
certainly we might need a new label for 'actual *review* by someone else' |
| 06:36 |
paramat |
sorry, i mean 'actual code review by someone else' |
| 06:36 |
Zeno` |
paramat if it's work in progress you could simply use the WIP label :/ |
| 06:36 |
paramat |
this label is for 'overall dev agreement', only 2 are normally needed |
| 06:36 |
paramat |
yeah |
| 06:37 |
paramat |
but it is flexible of course |
| 06:37 |
paramat |
1-3+ depending |
| 06:37 |
hmmmmm |
i'll make a post on the forum about this and gather everybody's opinion. |
| 06:37 |
Zeno` |
we should have a vote every time |
| 06:37 |
Zeno` |
like a poll |
| 06:37 |
Zeno` |
</sarcasm> |
| 06:38 |
Zeno` |
do we really have to discuss this every couple of weeks? |
| 06:39 |
paramat |
funny that it only became an issue when i added labels |
| 06:39 |
|
jin_xi joined #minetest-dev |
| 06:39 |
Zeno` |
All "more approvals" will do is slow things down even more |
| 06:39 |
paramat |
i agree the use of labels had caused confusion and seems to upset some people 'you can't self approve!' |
| 06:40 |
Zeno` |
paramat, if you hadn't been adding the "one approval" label to your own PRs nobody would have noticed :P |
| 06:40 |
paramat |
approval != review obviously |
| 06:41 |
paramat |
yeah i did wonder about whether a core dev actually uses that label or not, i think i'll stop to avoid the complaints |
| 06:41 |
Zeno` |
if merging gets any more difficult doing things will increase from a year to merge a PR to maybe 5 years |
| 06:41 |
paramat |
evenif it's otherwise helpful |
| 06:41 |
hmmmmm |
is it really difficult to merge things? |
| 06:41 |
hmmmmm |
i don't get it |
| 06:41 |
paramat |
dev shortage |
| 06:42 |
paramat |
other mtgame devs are very absent |
| 06:42 |
Zeno` |
hmmmmm, it is if we start having votes and requiring 3 agreements etc |
| 06:42 |
paramat |
it's mostly me running things |
| 06:42 |
paramat |
(in game) |
| 06:42 |
hmmmmm |
the agreements part scales depending on the scope and importance of the commit |
| 06:42 |
Zeno` |
yeah of course |
| 06:43 |
Zeno` |
but to have a blanket rule that all PRs need 3 approvals is silly |
| 06:43 |
hmmmmm |
nobody said it needs 3 approvals |
| 06:43 |
hmmmmm |
that's only for something farmap sized |
| 06:43 |
Zeno` |
hmmmmm, you are effectively (if you're saying that a core dev still needs approval from two other devs) |
| 06:43 |
hmmmmm |
two other devs are going to code review it, right? |
| 06:44 |
Zeno` |
not necessarily |
| 06:44 |
hmmmmm |
for moderate sized changes |
| 06:44 |
hmmmmm |
small changes require only one approval/code review, and then trivial ones don't require any approval/code review |
| 06:44 |
hmmmmm |
or at least that was the concept |
| 06:44 |
paramat |
my own review of my mapgen code doesn't count? here it does as i understand it more than anyone |
| 06:45 |
paramat |
but other PRs may be different and need 2 code reviews |
| 06:45 |
hmmmmm |
if you weren't confident in your own code, why would you be comitting it in the first place? |
| 06:45 |
hmmmmm |
you need to convince others that it won't break everything |
| 06:45 |
paramat |
because we don't merge things alone |
| 06:46 |
hmmmmm |
in any case, the approval system has done an incredible amount more good than harm |
| 06:46 |
paramat |
oh i see |
| 06:46 |
hmmmmm |
there are so many bugs that have been prevented |
| 06:46 |
hmmmmm |
the earlier a bug is caught, the less effort it takes to track and the less harm it could ever cause |
| 06:46 |
paramat |
actually, i very often open PRs not confident in the code |
| 06:46 |
paramat |
many contributors do |
| 06:47 |
hmmmmm |
if you think this is a restrictive system you haven't seem very many code submission processes |
| 06:47 |
paramat |
anyway 'approval' != 'code review' |
| 06:47 |
hmmmmm |
i have to deal with shit that's 100x more obstructive and hardly any more effective at work |
| 06:47 |
paramat |
yeahi can imagine |
| 06:48 |
Zeno` |
hmmmmm, we're not a company where we have resources and most of the people are around at the same time every day |
| 06:48 |
* sofar |
wonders what hmmmm does for work |
| 06:48 |
paramat |
we got it easy here |
| 06:48 |
hmmmmm |
Zeno`, most of the people review at their own leisure even during business hours |
| 06:48 |
|
nrzkt joined #minetest-dev |
| 06:49 |
hmmmmm |
in general things get reviewed slower than minetest |
| 06:49 |
Zeno` |
so a small 50 line PR will take a year to get a year to get reviewed and merged? |
| 06:49 |
hmmmmm |
3/4ths of the developers decide it's not their problem and then the other 1/4th might give you a single set of comments one day and then re-review the next |
| 06:50 |
hmmmmm |
there are plenty of PRs that are still pending after years if that's what you mean |
| 06:50 |
paramat |
self-approving is useful because then one can filter for 'two approvals', that filter doesn't detect that the author is a core dev and that therefore their approval is obvious. so i'm re-adding my approvals |
| 06:50 |
hmmmmm |
it fell through the cracks |
| 06:50 |
hmmmmm |
if you post it here i promise i'll give you an answer right now |
| 06:51 |
hmmmmm |
i honestly don't think minetest's code submission process is bad at all. it could certainly be a lot more restrictive, and slower, the only major issue is one of organization |
| 07:01 |
jin_xi |
guys anyone up for bouncing some questions about collision detection and mt? |
| 07:03 |
paramat |
hmmmmm code style-wise would you prefer there to be no spaces in mapgen parameter lists? i was seperating flags from noises from others for clarity but i don't mind them together |
| 07:03 |
hmmmmm |
just do whatever makes sense |
| 07:04 |
paramat |
ok |
| 07:15 |
hmmmmm |
valleys mapgen is so fucked from an organizational standpoint |
| 07:15 |
hmmmmm |
the terrain is intermingled with the biome results |
| 07:15 |
hmmmmm |
i'm going to write that one off as a lost cause |
| 07:16 |
hmmmmm |
no offense to whoever originally developed it |
| 07:17 |
hmmmmm |
separation of concerns? i'm too cool for that! |
| 07:17 |
hmmmmm |
put everything into one big monolithic blob why not |
| 07:17 |
hmmmmm |
it's totally modular this way |
| 07:34 |
paramat |
yeah i can barely understand it |
| 08:02 |
|
proller__ joined #minetest-dev |
| 08:12 |
Hunterz |
that mapgen will be cool in the minetest: https://camo.githubusercontent.com/a66d97c50115a099d8f3e4033bd80d0ce7a75bc6/687474703a2f2f692e696d6775722e636f6d2f46634c52374d712e676966 |
| 08:14 |
Hunterz |
its very realistic terrain generator... hills, erosion... |
| 08:15 |
|
est31 joined #minetest-dev |
| 08:15 |
paramat |
MC mod? |
| 08:15 |
|
proller joined #minetest-dev |
| 08:16 |
paramat |
looks like it, nice |
| 08:16 |
Hunterz |
yes mc mod |
| 08:16 |
Hunterz |
https://github.com/Team-RTG/1.9-Realistic-Terrain-Generation |
| 08:19 |
|
est31 joined #minetest-dev |
| 08:19 |
est31 |
nice mapgen |
| 08:19 |
est31 |
still, its GPL v3 |
| 08:19 |
est31 |
so not usable for minetest |
| 08:20 |
est31 |
@ least not as builtin mapgen |
| 08:20 |
VanessaE |
..unless you ask for permission. |
| 08:20 |
VanessaE |
(to relicense) |
| 08:23 |
est31 |
https://github.com/Team-RTG/1.9-Realistic-Terrain-Generation/blob/dev/.github/CONTRIBUTING.md#coordinates |
| 08:23 |
est31 |
hehe they should check out minetest |
| 08:23 |
est31 |
we have far more coordinates |
| 08:23 |
est31 |
chunks, blocks, nodes, then this BS nodes stuff, etc etc |
| 08:23 |
est31 |
i think we also have absolute and relative node pos |
| 08:23 |
est31 |
relative inside a mapblock |
| 08:24 |
est31 |
used for nodetimer serialisation i think |
| 08:25 |
hmmmmm |
wow |
| 08:25 |
hmmmmm |
a third party mapgen has almost 2000 commits alone |
| 08:26 |
est31 |
hmmmmm, you know that we are comparing ourselves with the most successful game of this decade |
| 08:26 |
hmmmmm |
i know |
| 08:26 |
hmmmmm |
they have the sheer volume of people necessary to make that happen |
| 08:26 |
hmmmmm |
look at all those people dedicated to nothing more than a single mapgen |
| 08:27 |
est31 |
and the result looks pretty good |
| 08:27 |
hmmmmm |
no kidding! |
| 08:27 |
hmmmmm |
or, as celeron would say, "it's too large-scale" |
| 08:28 |
hmmmmm |
paramat, keep on the lookout for changes in this branch https://github.com/kwolekr/minetest/tree/biomegen |
| 08:28 |
hmmmmm |
i've made only one commit so far, https://github.com/kwolekr/minetest/commit/a699e1ba8d19a5635f6309b45b3896762b2a1df7 |
| 08:31 |
paramat |
ok |
| 08:32 |
Hunterz |
I like nature and landscape, but minetest miss more diverse landscape, mountains, hills, natural formations, rock, landscape seems too rounded, lack of erosion, it's a much smoother .. |
| 08:33 |
hmmmmm |
kinda hard to do erosion when you are only able to generate one cubic chunk of map at a time |
| 08:33 |
paramat |
indeed |
| 08:33 |
paramat |
it would be simulated |
| 08:33 |
hmmmmm |
i'm figuring ways out around that |
| 08:34 |
paramat |
mgv6 has a simple mudflow erosion though |
| 08:34 |
hmmmmm |
possibly letting the mapgen insert its own block generation phases into the emerge/generate pipeline |
| 08:34 |
hmmmmm |
that way the mapgen can have as much surrounding "context" as it needs |
| 08:43 |
paramat |
anyway, given time (and money to live on) i could do something almost as good as that MC mod |
| 08:46 |
Hunterz |
mgv8 |
| 08:48 |
hmmmmm |
go down to the job centre and get a jobby job! |
| 08:48 |
hmmmmm |
ok later i'm going to have a cuppa |
| 08:49 |
paramat |
toodle pip! |
| 08:49 |
paramat |
anyway i can't get a job, that's the problem |
| 08:50 |
paramat |
such a mapgen would probably not use the biome API, it's flexibility makes it limiting |
| 08:58 |
|
Amaz joined #minetest-dev |
| 09:16 |
paramat |
(can't get benefits either, so no income) |
| 09:27 |
celeron55_ |
minetest - brought to you by crazy homeless people |
| 09:27 |
celeron55_ |
i've got a new interesting catchphrase |
| 09:32 |
* jin_xi |
throws cat |
| 09:33 |
paramat |
heh |
| 09:36 |
Hunterz |
why you can't get a job? what is your specialty, practice and skills? |
| 09:37 |
Hunterz |
i think everywhere is hunger for programmers |
| 09:39 |
paramat |
i can understand you asking that and not understanding why, and if i explained you would understand, but it's personal information i prefer to not share |
| 09:40 |
est31 |
build your free home in this free game |
| 09:40 |
est31 |
developers scratching their itch |
| 09:40 |
paramat |
heh yeah |
| 09:40 |
Hunterz |
ok |
| 09:42 |
celeron55_ |
i'm still waiting for paramat's monetary support button to appear somewhere |
| 09:42 |
paramat |
i'm really not a programmer, i only know very basic c++ |
| 09:42 |
paramat |
yeah i must sort that out, i hate asking for donations |
| 09:48 |
Hunterz |
yours mapgens are awesome, i think many people will support you without asking... |
| 09:53 |
paramat |
:) |
| 09:54 |
Zeno` |
https://github.com/minetest/minetest/issues/4056-- Add donate to paramat button by Hunterz |
| 09:54 |
Hunterz |
lol :) |
| 09:56 |
Zeno` |
paramat, how are the release notes going? :-o |
| 09:57 |
paramat |
you mean time of freeze? |
| 09:58 |
Zeno` |
nah I mean the change log that has to go with the release |
| 09:58 |
Zeno` |
http://dev.minetest.net/Changelog |
| 09:59 |
paramat |
oh crumbs i haven't even thought of that |
| 09:59 |
Zeno` |
:-( |
| 09:59 |
paramat |
during freeze i guess |
| 10:00 |
Zeno` |
Looks like that time it was just an edited list from the git history |
| 10:00 |
paramat |
anyway, it's not necessarily my job |
| 10:00 |
Zeno` |
last time* |
| 10:00 |
paramat |
yeah it's not very clear |
| 10:00 |
Zeno` |
But I've assigned it to you |
| 10:00 |
paramat |
lol |
| 10:00 |
Zeno` |
xD |
| 10:00 |
paramat |
i might make a clearer explanation of my own mapgen stuff |
| 10:01 |
Zeno` |
yeah, so the changelog is only going to include mapgen changes? :) |
| 10:01 |
Zeno` |
sounds fair enough to me! |
| 10:06 |
paramat |
i'm actually in the mood for refusing tasks because i do so much, i can do a simplified summary of mapgen changes (because i understand it), the full log can be done by someone else :P |
| 10:08 |
Zeno` |
most of it can be done with a script and sed |
| 10:08 |
Zeno` |
And then just hand-edited |
| 10:08 |
* Zeno` |
wonders who is good at writing scripts |
| 10:09 |
|
kilbith joined #minetest-dev |
| 10:10 |
kilbith |
rubenwardy wrote a script to make the changelog : http://paste.ubuntu.com/16093226/ |
| 10:10 |
|
proller joined #minetest-dev |
| 10:11 |
Zeno` |
there we go |
| 10:11 |
Zeno` |
job done |
| 10:11 |
Zeno` |
well, 70% done |
| 10:11 |
kilbith |
the last one has been made with this one |
| 10:12 |
Zeno` |
I would say so yes |
| 10:12 |
Zeno` |
which is probably why it said my real name instead of Zeno (until I changed the wiki today) |
| 10:16 |
* Zeno` |
wonders how kilbith answered a question that he had not seen |
| 10:16 |
Zeno` |
must be psychic |
| 10:20 |
|
hmmmm joined #minetest-dev |
| 10:20 |
paramat |
it's past your bedtime! |
| 10:21 |
hmmmm |
back pain |
| 10:21 |
hmmmm |
couldn't fall asleep |
| 10:21 |
kilbith |
Zeno`, because i'm omniscient |
| 10:21 |
paramat |
aww |
| 10:21 |
* Zeno` |
puts on the heavy rubber gloves and hazmat suit |
| 10:22 |
Zeno` |
ready for your massage, hmmmm? |
| 10:22 |
hmmmm |
just shoot me already |
| 10:22 |
hmmmm |
i can't take this much longer |
| 10:22 |
Zeno` |
I am a pacifist |
| 10:23 |
Zeno` |
hmmmm, go to the Dr! |
| 10:23 |
hmmmm |
lol doctor handed me a perscription for muscle relaxants |
| 10:23 |
Zeno` |
and no pain killers to go with them?! |
| 10:23 |
hmmmm |
it's hard to diagnose because it's kinda vague but i need to be more aggressive about this issue because it's really screwing my life up |
| 10:23 |
Zeno` |
they're normally prescribed together :/ |
| 10:24 |
Zeno` |
yeah, I had a medical issue and had to keep hassling the Dr for a long time |
| 10:24 |
Zeno` |
it was hard to describe also |
| 10:25 |
hmmmm |
did you get it fixed eventually |
| 10:27 |
Zeno` |
yes |
| 10:28 |
Zeno` |
not fixed as in a permanent solution, but something that makes my life live-able again |
| 10:28 |
hmmmm |
that's good to hear |
| 10:29 |
Zeno` |
Yeah, it did take awhile though :( |
| 10:29 |
hmmmm |
me, my life is sorta livable, if i don't get ambitious.. |
| 10:29 |
Zeno` |
oh mine was also, but when the condition expressed itself I was basically immobolised |
| 10:29 |
hmmmm |
hard to focus at times and i get frustrated with the constant pain |
| 10:29 |
hmmmm |
it's literally non-stop |
| 10:29 |
hmmmm |
there is no 5 minute break |
| 10:30 |
hmmmm |
i just want to tell it time out |
| 10:30 |
Zeno` |
yeah |
| 10:33 |
paramat |
*** looking at remaining milestones i'm moving freeze to sunday *** |
| 10:33 |
paramat |
but feel free to get them done sooner :) |
| 10:34 |
|
paramat left #minetest-dev |
| 10:35 |
|
lisac joined #minetest-dev |
| 10:36 |
|
damiel joined #minetest-dev |
| 10:41 |
|
kilbith left #minetest-dev |
| 11:23 |
|
gregorycu joined #minetest-dev |
| 11:23 |
gregorycu |
Fixer, can you please stop breaking my shit please |
| 11:24 |
hmmmm |
he certainly fixed your shit |
| 11:26 |
|
est31 joined #minetest-dev |
| 11:37 |
|
STHGOM joined #minetest-dev |
| 11:59 |
|
Fixer joined #minetest-dev |
| 12:01 |
|
proller joined #minetest-dev |
| 12:18 |
|
troller joined #minetest-dev |
| 12:19 |
gregorycu |
Bloody hell, another API doesn't work properly |
| 12:20 |
gregorycu |
One should expect it shouldn't be this hard to rename a file |
| 12:25 |
gregorycu |
It just failed to write the file because file explorer was in the middle of querying file properties when it went to rename |
| 12:25 |
gregorycu |
Like |
| 12:25 |
gregorycu |
Are you kidding me |
| 12:29 |
|
rubenwardy joined #minetest-dev |
| 12:39 |
|
est31 joined #minetest-dev |
| 12:43 |
gregorycu |
est31: How fare thee |
| 12:44 |
est31 |
Me fealst good |
| 12:44 |
est31 |
my shakesperian english sucks |
| 12:46 |
|
BrandonReese joined #minetest-dev |
| 12:47 |
gregorycu |
The only language skill I care about is C++ |
| 12:51 |
est31 |
It could be better |
| 12:53 |
est31 |
but i can express the ideas i want with it |
| 12:53 |
est31 |
and i can read most of the code, and if i cant i know where and how to look it up |
| 12:55 |
gregorycu |
What about C++11 |
| 12:56 |
est31 |
90% of my c++ knowledge is thanks to minetest |
| 12:56 |
est31 |
and minetst doesnt use c++11 |
| 12:56 |
est31 |
so very lacking knowledge |
| 13:10 |
gregorycu |
So, my code now attempts to replace the file, and it that fails cause the file doesn't exist, it moves it |
| 13:14 |
|
proller joined #minetest-dev |
| 13:32 |
|
AnotherBrick joined #minetest-dev |
| 13:40 |
|
lisac joined #minetest-dev |
| 13:41 |
gregorycu |
Time for me to look at the pathfinder |
| 13:49 |
|
Taoki joined #minetest-dev |
| 13:53 |
|
johnnyjoy joined #minetest-dev |
| 13:55 |
Zeno` |
#4039 seems ready to merge. Will do so shortly |
| 13:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/4039 -- Map boundary check for /teleport by tenplus1 |
| 13:56 |
|
proller joined #minetest-dev |
| 13:57 |
|
proller joined #minetest-dev |
| 13:59 |
|
davisonio joined #minetest-dev |
| 14:01 |
Zeno` |
done |
| 14:01 |
gregorycu |
Not many milestone items left now |
| 14:01 |
gregorycu |
#4032 and #4024 |
| 14:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/4032 -- Mapgen: Make 3D noise tunnels' width settable by paramat |
| 14:01 |
ShadowBot |
https://github.com/minetest/minetest/issues/4024 -- Expiring particle spawners broken |
| 14:01 |
gregorycu |
The rest are non-issues |
| 14:02 |
|
proller joined #minetest-dev |
| 14:03 |
Zeno` |
hopefully the milestones don't move again. Heh |
| 14:04 |
Fixer |
i'm still busy, can't check filerename thing yet for few hours |
| 14:06 |
gregorycu |
Ahh good :) |
| 14:06 |
gregorycu |
No rush, we are sailing towards the milestone nicely |
| 14:07 |
|
proller joined #minetest-dev |
| 14:11 |
|
lisac joined #minetest-dev |
| 14:11 |
gregorycu |
&result.first->second |
| 14:18 |
|
proller joined #minetest-dev |
| 14:40 |
|
dfelinto joined #minetest-dev |
| 14:40 |
nore |
gregorycu: what about writing a new file over the previous one, and only then remove the temp file instead of doing a rename? Would it work? |
| 14:41 |
gregorycu |
What is the purpose of the temp file? |
| 14:42 |
nore |
having a backup if MT crashes/is killed or if there is a filesystem error while writing the file |
| 14:42 |
nore |
In order not to lose important data |
| 14:43 |
gregorycu |
So, we recover from the crash, and then what? |
| 14:43 |
gregorycu |
If the temp file exists, do we use its contents instead? |
| 14:43 |
nore |
Ehm, it's something that has to be done manually |
| 14:44 |
nore |
The user (most likely server owner) sees there was a problem, and renames the temp file |
| 14:44 |
gregorycu |
Why server owner? This is the favourites file |
| 14:45 |
gregorycu |
The goal of the changeset wasn't to fix the potential to fix updates not getting saved, but the potential for the whole file to be wiped |
| 14:46 |
|
PilzAdam joined #minetest-dev |
| 14:47 |
gregorycu |
We can retain the temporary file, but what if we cannot write to the temporary file |
| 14:47 |
nore |
well, this function was introduced mostly for map_meta.txt |
| 14:48 |
gregorycu |
Don't we have a standalone database engine? |
| 14:48 |
nore |
I don't think so |
| 14:51 |
|
troller joined #minetest-dev |
| 14:52 |
nore |
Could we avoid removing the file perhaps? |
| 14:53 |
nore |
Or, isn't there any way to do an atomic rename? |
| 14:54 |
gregorycu |
The problem isn't atomicidy |
| 14:55 |
gregorycu |
It's the replace operation which has issues |
| 14:55 |
gregorycu |
On windows it has to be a delete + move |
| 14:55 |
gregorycu |
the delete can "fail" |
| 14:56 |
gregorycu |
There is a function that apparently protects against this, however the destination file must exist |
| 14:56 |
gregorycu |
As the code suggests |
| 14:57 |
nore |
What does it mean, that the delete can fail? |
| 14:57 |
nore |
I mean, precisely |
| 14:57 |
gregorycu |
It means windows can defer the delete until later |
| 14:57 |
gregorycu |
Which causes the move to fail |
| 14:58 |
nore |
What about then: rename the old file, then do the rename, then remove the old file that has the old name |
| 14:58 |
nore |
(Yes, this is even hackier) |
| 14:59 |
|
Hunterz joined #minetest-dev |
| 14:59 |
gregorycu |
Yeah, there is probably a series of steps that will get us there |
| 15:00 |
nore |
Is the rename immediate though? |
| 15:00 |
gregorycu |
No |
| 15:00 |
nore |
Uh |
| 15:00 |
gregorycu |
I believe the rename can also be deferred |
| 15:01 |
gregorycu |
It's not a very good system |
| 15:01 |
nore |
Can't we set some kind of flag to tell the IO function to be blocking until the delete/rename actually happens? |
| 15:01 |
gregorycu |
No, but we can check ourselves |
| 15:01 |
gregorycu |
What we should really do is use a database engine where all these specific filesystem/OS issues have been solved |
| 15:02 |
* nore |
agrees |
| 15:02 |
gregorycu |
And rely on the more stringent database ACID guarantees |
| 15:02 |
gregorycu |
We really don't want to reinvent the wheel here |
| 15:03 |
|
dfelinto joined #minetest-dev |
| 15:05 |
Zeno` |
Well it works fine for POSIX systems |
| 15:05 |
Zeno` |
so maybe Windows is the problem :D |
| 15:05 |
nore |
http://stackoverflow.com/questions/1261269/how-to-open-file-in-windows-while-not-blocking-its-renaming <-- looks bad |
| 15:05 |
gregorycu |
We are still managing the transactionality ourselves |
| 15:06 |
gregorycu |
But yeah, windows generally sucks at this stuff |
| 15:07 |
|
hmmmmm joined #minetest-dev |
| 15:07 |
nore |
So, I guess the best solution would be to do the following things: |
| 15:07 |
nore |
1. Write the temp file |
| 15:07 |
nore |
2. Open the output file (erasing its data), and writing new contents over it |
| 15:08 |
nore |
3. Remove the temp file |
| 15:08 |
gregorycu |
Except that 2 requires manual intervention should it fail |
| 15:09 |
nore |
What do you mean? |
| 15:09 |
gregorycu |
With the current system, should we crash in the middle of writing, we are in a good state |
| 15:09 |
Zeno` |
I think you should go back to the code you had yesterday but add a check to ensure that the destination file exists (if not just create an empty file) before calling ReplaceFile |
| 15:09 |
gregorycu |
If we were to crash at stage 2, we would have a half written file |
| 15:10 |
nore |
Ah, indeed |
| 15:10 |
nore |
What does ReplaceFile exactly do btw? |
| 15:11 |
Zeno` |
I'm not sure if the Windows devs even know that for sure |
| 15:11 |
gregorycu |
Zeno`: But the destination file may exist because it is held open for a few milliseconds because of a delayed delete |
| 15:11 |
gregorycu |
Wait, nevermind, I think |
| 15:12 |
gregorycu |
ReplaceFile does a lot of stuff |
| 15:12 |
gregorycu |
A lot of low level calls, copies file attributes across, permissions etc. |
| 15:13 |
Zeno` |
If there is a delayed delete then checking if the file exists should, I would imagine, return false even if the file is still there waiting for the final delete |
| 15:13 |
gregorycu |
I'm not so sure |
| 15:13 |
Zeno` |
If the OS can't handle this then everything breaks |
| 15:14 |
gregorycu |
Bold statement |
| 15:14 |
Zeno` |
Bold but true |
| 15:14 |
gregorycu |
The OS will disallow you from opening the file if it's marked for deletion |
| 15:14 |
Zeno` |
yes |
| 15:14 |
Zeno` |
as it should |
| 15:14 |
Zeno` |
but will it disallow you creating a file with the same name? |
| 15:15 |
gregorycu |
Yes |
| 15:15 |
gregorycu |
Unlike on linux |
| 15:15 |
gregorycu |
The file is still there, linked to the name |
| 15:15 |
gregorycu |
When you go to open, you get a permission denied error |
| 15:16 |
Zeno` |
Surely there is a documented way to handle this |
| 15:16 |
Zeno` |
I mean it's not uncommon for some other process to have a file open temporarily |
| 15:17 |
gregorycu |
Yeah, you can still delete, you just can't quickly recreate the file |
| 15:17 |
Zeno` |
And having apps write 1000 lines of code to handle something that is so common doesn't make sense |
| 15:17 |
Zeno` |
let's use Qt |
| 15:18 |
Zeno` |
That will handle it properly xD |
| 15:18 |
Zeno` |
actually if it does, perhaps its source code provides a hint |
| 15:22 |
celeron55_ |
gregorycu: what is this file thing you are talking about? |
| 15:22 |
gregorycu |
I'm not sure you want to know |
| 15:22 |
celeron55_ |
i want to make sure you are not breaking something i did |
| 15:22 |
celeron55_ |
if it's a new thing, then i don't care |
| 15:23 |
gregorycu |
#4042 |
| 15:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/4042 -- Use ReplaceFile to rename files on Windows (not rename) by gregorycu |
| 15:25 |
celeron55_ |
ok, as long as you are careful to not break the working posix implementation, i don't care |
| 15:26 |
celeron55_ |
i agree that the windows one has been basically a catastrophe |
| 15:30 |
gregorycu |
Yeah, all a fan for a better solution |
| 15:42 |
|
johnnyjoy joined #minetest-dev |
| 16:00 |
|
Krock joined #minetest-dev |
| 16:01 |
|
paramat joined #minetest-dev |
| 16:14 |
gregorycu |
No obvious error with the pathfinder code |
| 16:14 |
gregorycu |
Which means I'll actually have to do context-sensitive analysis |
| 16:14 |
paramat |
nore PilzAdam sfan5 ShadowNinja this is very masochistic of me but i'm proposing a new grass texture game#1025 |
| 16:14 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1025 -- Default: New 'dirt with grass' textures by paramat |
| 16:14 |
|
johnnyjoy joined #minetest-dev |
| 16:15 |
* paramat |
hides |
| 16:16 |
|
STHGOM joined #minetest-dev |
| 16:16 |
PilzAdam |
paramat, I really don't care about the grass texture anymore |
| 16:19 |
PilzAdam |
paramat, I give this C1ffisme my vote on this issue; he seems to like discussing useless stuff |
| 16:20 |
VanessaE |
paramat: for once, I actually kinda-sorta like it :) |
| 16:20 |
VanessaE |
(which can't be a good thing :P ) |
| 16:20 |
gregorycu |
Dear me |
| 16:20 |
gregorycu |
Night all |
| 16:21 |
paramat |
it's Casimir's Voxelgarden texture modified |
| 16:22 |
VanessaE |
(at least, the "vox7" variant shown in the first post, anyway) |
| 16:22 |
paramat |
PilzAdam that's wise for your sanity, do you care about game at all? |
| 16:22 |
paramat |
yeah 1st screenshot is the proposal |
| 16:22 |
PilzAdam |
yes, of course I do |
| 16:22 |
sfan5 |
paramat: so many screenshots which ones compare the current and new one? |
| 16:23 |
paramat |
first post, proposal and current are labelled |
| 16:23 |
paramat |
PA ok :) just wondering |
| 16:24 |
ShadowNinja |
Merging Gradle conversion... |
| 16:26 |
paramat |
celeron55_ it's such an important texture i would like you to be reasonably happy with it, or at least not hate it |
| 16:26 |
sfan5 |
looks pretty much the same to me |
| 16:27 |
nore |
paramat: the new one looks good to me |
| 16:28 |
nore |
although the current one is fine too |
| 16:28 |
nore |
so, +1 if you want to merge, but I don't really care |
| 16:29 |
celeron55_ |
paramat: i really don't care because i don't think i have been asked about the previous ones either for a long time |
| 16:30 |
paramat |
ok |
| 16:30 |
celeron55_ |
it doesn't look awful |
| 16:30 |
paramat |
phew |
| 16:32 |
paramat |
thanks all for looking, i'm rather shocked at the lack of opposition. but will merge later |
| 16:33 |
paramat |
lol |
| 16:37 |
crazyR |
btw paramat my comment was'nt in opposition to your suggestion lol. I do like your suggestion under the current capabilities of minetest. |
| 16:38 |
paramat |
ah you're ryan-nolan. no problem i didn't take it as opposition |
| 16:40 |
crazyR |
Lol yeah i should probably add my alias in brackets to avoid confusion lol. Just though id mention i#as i sometimes say things and it come's across different to what I meant :) |
| 16:40 |
paramat |
replied |
| 16:43 |
crazyR |
thanks |
| 16:46 |
|
nrzkt joined #minetest-dev |
| 16:47 |
|
DI3HARD139 joined #minetest-dev |
| 16:49 |
|
turtleman joined #minetest-dev |
| 17:01 |
paramat |
added screenshot of side texture, which is almost identical to the current |
| 17:05 |
|
kaadmy joined #minetest-dev |
| 17:05 |
ShadowNinja |
#4046 |
| 17:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/4046 -- Update and rework Android app by ShadowNinja |
| 17:05 |
sofar |
can I make a proposal about textures & sounds? |
| 17:06 |
sofar |
and models, too, for that purpose |
| 17:07 |
sofar |
I think it's taking a long time to get past little one-by-one texture updates |
| 17:07 |
sofar |
I'm wondering if we can somehow do it way more efficiently |
| 17:08 |
sofar |
e.g. something like having a `visuals` branch and collectively merging it before release at once |
| 17:08 |
sofar |
so that it doesn't stop the code review |
| 17:09 |
sofar |
and settle on an actual *timeline* for discussing all the proposed changes and alternatives |
| 17:09 |
sofar |
since it's always going to be a bit of a beauty peageant |
| 17:13 |
paramat |
textures would have to wait to just before release to be considered? |
| 17:13 |
sofar |
something like that |
| 17:13 |
sofar |
e.g. they would get merged before freeze |
| 17:14 |
sofar |
it's probably too late now to change the rules, but maybe we can do something like that for the next release |
| 17:16 |
ShadowNinja |
Merging #3824. |
| 17:16 |
ShadowBot |
https://github.com/minetest/minetest/issues/3824 -- Fix race on thread creation (fixes OSX thread tests) by ShadowNinja |
| 17:16 |
paramat |
hm. not sure it would be more efficient, it might just mean a huge amount of argument all at once, instead of spread out over a dev version |
| 17:18 |
paramat |
personally i would find it irritating to have to wait 8 months to have a texture considered, stuff should be discussed as it arises, because that's the 'right time' for it |
| 17:24 |
|
davisonio joined #minetest-dev |
| 17:33 |
|
Foghrye4 joined #minetest-dev |
| 17:51 |
|
est31 joined #minetest-dev |
| 17:51 |
paramat |
any input on game#1060 ? specifically the 2nd commit |
| 17:51 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1060 -- TNT: Fix multiple explosions erasing drops by sofar |
| 17:54 |
est31 |
wow #3994 got merged without having conflicted #4033 |
| 17:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/3994 -- Upgrade Android build to Gradle build system by ShadowNinja |
| 17:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/4033 -- Fix issue #4005 and update depends by MoNTE48 |
| 17:57 |
ShadowNinja |
est31: It did conflict actually, but only on two lines (I modified the line below the cURL version change, so Git marked them both as conflicting). |
| 18:00 |
|
paramat left #minetest-dev |
| 18:02 |
|
est31 joined #minetest-dev |
| 18:02 |
est31 |
ShadowNinja, if you want to review a change, you can have a look at #4037 |
| 18:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/4037 -- Pathfinder cleanup by est31 |
| 18:03 |
est31 |
note however that it does not intend to leave behind a perfect pathfinder |
| 18:03 |
est31 |
i just want to alleviate the biggest aches reading the code made me feel |
| 18:03 |
hmmmmm |
hold on a minute |
| 18:04 |
hmmmmm |
i thought a release was going to be soon |
| 18:05 |
est31 |
well idk the gradle pr went in as well didnt it |
| 18:05 |
est31 |
and my pathfinder changes are even older i think they were just part of a separate pr ... if pr age matters anything |
| 18:06 |
sofar |
the walkable fix is pretty crucial |
| 18:06 |
sofar |
without it mobs can't walk through grass plants |
| 18:06 |
est31 |
and it has a big speed improvement |
| 18:06 |
sofar |
I'm thinking we should not make "unable to update cost map" an error |
| 18:07 |
sofar |
it's a legitimate "there's really no path" case |
| 18:07 |
est31 |
thats stuff i wanted to avoid in my pr |
| 18:07 |
sofar |
yes, agreed that would be a new PR |
| 18:07 |
est31 |
i wanted to be very cautious with stuff i do |
| 18:07 |
sofar |
I've seen my target position code pick the top of a tree |
| 18:07 |
est31 |
the first two commits should be completely non functional |
| 18:08 |
sofar |
and it's obvious that the sheep can't go there |
| 18:08 |
est31 |
they are added so that its super easy to review them |
| 18:08 |
est31 |
hmmmmm, the patch is not complicated in any way, just read through it. |
| 18:09 |
est31 |
and the suggested read order is to read every commit separately |
| 18:09 |
est31 |
well I'm going now, bye |
| 18:14 |
hmmmmm |
now why is gradle an 'upgrade' to ant exactly? |
| 18:14 |
ShadowNinja |
hmmmmm: Ant support has been droped by the Android developers -- all further development happens on Gradle. |
| 18:15 |
|
Fixer_ joined #minetest-dev |
| 18:15 |
hmmmmm |
..swell |
| 18:15 |
ShadowNinja |
And of course, gradle is easier to use and integrates some usefull functionality like vector compat and (experimental) JNI support. |
| 18:33 |
|
dfelinto joined #minetest-dev |
| 18:40 |
|
Megal_ joined #minetest-dev |
| 18:43 |
|
davisonio joined #minetest-dev |
| 18:44 |
|
Fixer joined #minetest-dev |
| 18:48 |
|
Zeno` joined #minetest-dev |
| 18:50 |
|
troller joined #minetest-dev |
| 19:02 |
|
Amaz joined #minetest-dev |
| 19:08 |
nore |
Should we close #4040? |
| 19:08 |
ShadowBot |
https://github.com/minetest/minetest/issues/4040 -- Update tab_multiplayer.lua by Emon-Omen |
| 19:29 |
Zeno` |
#3388 should be closed also |
| 19:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/3388 -- Add hunger by BlockMen |
| 19:31 |
Zeno` |
If somebody wants to resurrect it then they can, and make a new PR, but atm there is no reason for it to sit there because it cannot be merged |
| 19:34 |
Zeno` |
I think I'll just close it |
| 19:34 |
Zeno` |
Will do so in 10 minutes |
| 19:38 |
Zeno` |
Actually... no reason to wait :) |
| 19:50 |
|
Megal joined #minetest-dev |
| 19:51 |
|
luizrpgluiz joined #minetest-dev |
| 19:59 |
|
troller joined #minetest-dev |
| 20:04 |
|
Zeitgeist_ joined #minetest-dev |
| 20:11 |
|
luizrpgluiz left #minetest-dev |
| 20:12 |
|
davisonio joined #minetest-dev |
| 20:16 |
|
bugzapper joined #minetest-dev |
| 20:17 |
nore |
There are way too many changes I want to do that are incompatible :/ |
| 20:18 |
nore |
Well, old maps could be converted, but old clients would not be able to connect to new servers |
| 20:18 |
nore |
(I guess, it is only a protocol bump after all) |
| 20:20 |
nore |
But that includes: BKVL serialisation, configurable map coordinates size; changing the map saving format (especially, how the coordinates of blocks are stored), client-side translations, natural/artificial lighting instead of day/night |
| 20:21 |
nore |
Well, maybe it could be for 0.5... |
| 21:03 |
|
user3208 joined #minetest-dev |
| 21:04 |
user3208 |
Can someone explain how Minetest does its meshing? |
| 21:07 |
user3208 |
Does it just make a quad for each face exposed to air, or does it do more advanced techniques like combining faces to achive faster rendering? |
| 21:08 |
KaadmY |
just adds a quad per exposed face i think |
| 21:08 |
sofar |
content_mapblock.cpp |
| 21:14 |
celeron55_ |
there's not much that can be done, and the remnants of any advanced techniques like that are rotting away because they're practically useless |
| 21:14 |
celeron55_ |
but that's the file |
| 21:19 |
jin_xi |
i'm hacking around trying to use greedily meshed blocks for collision detection, but they can ignore different textures and light values |
| 21:19 |
celeron55_ |
yeah in use cases like that optimizing the mesh becomes way more useful |
| 21:20 |
jin_xi |
but still its kinda hard with dynamic map... |
| 21:21 |
user3208 |
What about merging adjacent block faces of the same type and using 3d lightmaps to implement lighting from nearby torches? Would that be possible? |
| 21:21 |
celeron55_ |
jin_xi: you might want to check what buildat does: https://github.com/celeron55/buildat/blob/master/src/impl/mesh.cpp#L823 |
| 21:21 |
jin_xi |
it does try and tile some faces |
| 21:22 |
jin_xi |
thanks will do |
| 21:22 |
celeron55_ |
it basically has rather huge mapblocks and then just optimizes the physics mesh inside each one individually |
| 21:22 |
celeron55_ |
it doesn't make a mesh; it makes a list of overlapping boxes |
| 21:23 |
celeron55_ |
and feeds them to urho3d's physics component which is basically bullet physics |
| 21:24 |
jin_xi |
and this is done for every block alongside the mesh for drawing? |
| 21:24 |
celeron55_ |
user3208: tough with irrlicht; feel free to attempt to rework |
| 21:25 |
celeron55_ |
jin_xi: yes; i don't remember anymore but maybe they're generated only if the player goes close enough to them |
| 21:25 |
celeron55_ |
feeding a lot of stuff into a real physics engine isn't exactly a free operation |
| 21:26 |
KaadmY |
it isn't? |
| 21:26 |
celeron55_ |
it takes time, and cannot be done in a different thread, at least in urho3d |
| 21:26 |
celeron55_ |
well, again, if i remember anything right |
| 21:30 |
celeron55_ |
that doesn't really matter though, don't believe me |
| 22:02 |
|
Taoki joined #minetest-dev |
| 22:03 |
|
turtleman joined #minetest-dev |
| 22:08 |
|
Player_2 joined #minetest-dev |
| 22:32 |
|
Hijiri joined #minetest-dev |
| 22:43 |
|
proller joined #minetest-dev |
| 23:13 |
|
Wayward_One joined #minetest-dev |
| 23:13 |
|
Wayward_One joined #minetest-dev |
| 23:22 |
|
crazyR_ joined #minetest-dev |
| 23:39 |
|
crazyR joined #minetest-dev |
| 23:46 |
|
damiel joined #minetest-dev |
