| Time |
Nick |
Message |
| 00:02 |
red-001 |
https://github.com/minetest/minetest/issues/3507 |
| 00:02 |
red-001 |
opened a bug report |
| 00:20 |
|
rom1504 joined #minetest-dev |
| 00:24 |
|
dzho joined #minetest-dev |
| 00:27 |
red-001 |
rubenwardy why should the TNT API be put here https://github.com/red-001/minetest_game/blob/tnt-api/game_api.txt#L147 |
| 00:28 |
red-001 |
the files doesn't appear to be ordered in anyway.. |
| 00:28 |
red-001 |
file* |
| 00:43 |
rubenwardy |
mods are alphabetically ordered |
| 00:43 |
rubenwardy |
except for more generic stuff at the bottom of the file |
| 00:43 |
rubenwardy |
which really should go in "D" |
| 00:43 |
rubenwardy |
default |
| 00:44 |
|
Darcidride joined #minetest-dev |
| 00:44 |
rubenwardy |
it's all alphabetical, except for default which is at the bottom |
| 00:44 |
rubenwardy |
red-001, |
| 00:46 |
red-001 |
ok that makes sense |
| 00:46 |
red-001 |
why markdown format? |
| 00:48 |
rubenwardy |
all the files are pretty much |
| 00:48 |
red-001 |
shouldn't extensions be change to .md then? |
| 00:48 |
rubenwardy |
.txt is used rather than .md for windows support, irc |
| 00:49 |
rubenwardy |
writing in md makes this easier: http://rubenwardy.com/minetest_modding_book/lua_api.html |
| 00:49 |
rubenwardy |
There are a lot of links to .txt files, mainly lua_api.txt, it'll be hard to change. |
| 00:49 |
rubenwardy |
Admittedly lua_api.txt links break all the time |
| 00:50 |
rubenwardy |
I'd support changing to .md |
| 00:50 |
red-001 |
github could render it then |
| 00:50 |
rubenwardy |
yeah |
| 00:51 |
red-001 |
looks strange to read raw markdown |
| 00:51 |
rubenwardy |
I just use http://rubenwardy.com/minetest_modding_book/lua_api.html now. </selfpromotion> |
| 00:52 |
* red-001 |
finds no begin tag |
| 00:52 |
rubenwardy |
hmmm |
| 00:52 |
* red-001 |
assumes all site is selfpromation |
| 00:53 |
red-001 |
reverse cross site scripting |
| 00:55 |
red-001 |
happy new year |
| 00:56 |
red-001 |
everyone in UTC-1 |
| 00:56 |
|
Darcidride joined #minetest-dev |
| 01:05 |
red-001 |
I made a bug report for the cursor locking on loading https://github.com/minetest/minetest/issues/3507 |
| 01:12 |
|
Drangue joined #minetest-dev |
| 01:16 |
cmdskp |
anyone know this function: nodeupdate? https://github.com/cmdskp/minetest_game/blob/master/mods/fire/init.lua#L239 |
| 01:17 |
cmdskp |
I can't find it defined anywhere and it has no namespace |
| 01:17 |
sofar |
heh |
| 01:18 |
cmdskp |
it's used in another file too, but again, no definition of it |
| 01:22 |
|
gregorycu joined #minetest-dev |
| 01:26 |
sofar |
./game/falling.lua:function nodeupdate(p, delay) |
| 01:26 |
sofar |
it's builtin |
| 01:26 |
sofar |
https://github.com/minetest/minetest/blob/master/builtin/game/falling.lua#L187 |
| 02:05 |
|
Player2 joined #minetest-dev |
| 02:16 |
gregorycu |
How's everyone's 1st day of the year? |
| 02:49 |
gregorycu |
VanessaE/paramat: Do we know the cause of the shadow bugs? https://github.com/minetest/minetest/issues/3455 |
| 02:59 |
|
paramat joined #minetest-dev |
| 03:01 |
paramat |
the shadows in issue 3345 are probably due to moretrees mod, the patches of light might be too but i haven't seen those before |
| 03:03 |
paramat |
here's the most critical lighting bug, still a mystery, does not affect mgv6 https://github.com/minetest/minetest/issues/2759 |
| 03:07 |
paramat |
spawning schematics (growing saplings) sometimes causes shadows too. i think 'updateLighting' needs work to be more robust |
| 03:14 |
gregorycu |
Yeah, I plan to look at it |
| 03:14 |
gregorycu |
After doing a touch of perf work on that functiopn |
| 03:14 |
gregorycu |
I can repo locally |
| 03:15 |
paramat |
coolness |
| 03:19 |
gregorycu |
Nothing like exceptions to slow shit down |
| 03:26 |
|
Calinou joined #minetest-dev |
| 03:31 |
|
paramat left #minetest-dev |
| 03:38 |
|
Calinou joined #minetest-dev |
| 04:03 |
|
kaadmy joined #minetest-dev |
| 04:09 |
Fritigern |
gregorycu: You may want to team up with RealBadAngel for that one. According to VanessaE, he may not only have found a solution, but may even have found a way to enhance the lighting system |
| 04:12 |
Fritigern |
gregorycu: I pastebinned the chat in question here: https://paste.kde.org/p0noxb5cd |
| 04:17 |
gregorycu |
Yeah, I know about RBA's ideas |
| 04:17 |
gregorycu |
But it's possible that the lighting bug in quesiton is easily fixed without requiring another library |
| 04:20 |
gregorycu |
I'm not convinced hardware lighting would be better, to be honest |
| 04:20 |
sofar |
see my question in #minetest - my map now has lots of dark areas, how can I fix those up manually? |
| 04:21 |
gregorycu |
Follow the directions in the pastebin? |
| 04:22 |
kaadmy |
i found out that the dark areas are caused by a single(or sometimes 2-3) nodes that are lit wrong, if you can figure out the center of the dark area, place some nodes and the problem may get fixed |
| 04:22 |
sofar |
oh |
| 04:23 |
sofar |
I tried //fixlight :( |
| 04:23 |
kaadmy |
you have to update the badly lit node, so it's tricky to get it to work |
| 04:23 |
gregorycu |
When you say node, do you mean block? |
| 04:23 |
sofar |
fixing badly lit nodes isn't a problem - place a torch on it and it's fine |
| 04:24 |
sofar |
I'm talking huge areas that are dark |
| 04:25 |
sofar |
meh, fixed up only half the area with //replace air air |
| 04:25 |
sofar |
ah, a second run turned the whole area dark again |
| 04:27 |
gregorycu |
I'm going to look at this bug right now |
| 04:28 |
sofar |
welp, my map is hoooooosed |
| 04:34 |
sofar |
and it's only because of moretrees planting saplings even when I told it not to plant anything :( |
| 04:34 |
gregorycu |
um... |
| 04:35 |
gregorycu |
Damn |
| 04:44 |
gregorycu |
Fucking visual studio |
| 04:47 |
sofar |
gheghe |
| 04:48 |
sofar |
wouldn't want to be you :) |
| 04:48 |
gregorycu |
Trying to multitask to work on two things at once |
| 04:48 |
gregorycu |
Which is the definition |
| 04:49 |
gregorycu |
But yeah, doing optimisation work and trying to fix that bug |
| 05:03 |
|
GhostDoge joined #minetest-dev |
| 05:24 |
|
Calinou joined #minetest-dev |
| 05:31 |
sofar |
ughhh I wish worldedit had a //drain function |
| 05:38 |
Fritigern |
Then perhaps someone show look at sfan5 with their best puppy dog eyes ;-) |
| 05:42 |
sofar |
I pretty much coded it up, I'll post him some proto code he can use |
| 05:44 |
kaadmy |
well, good night to anybody still up ;) |
| 05:44 |
sofar |
I added a //drain and a //extuinguish |
| 05:48 |
sofar |
https://github.com/Uberi/Minetest-WorldEdit/issues/98 code here |
| 07:10 |
gregorycu |
I made spawn_ltree faster by 70% |
| 07:52 |
sofar |
lol |
| 07:54 |
gregorycu |
That wasn't a joke, I did it |
| 08:07 |
* sofar |
pops champagne |
| 08:07 |
sofar |
gregorycu: nice, PR incoming? |
| 08:38 |
|
Hunterz joined #minetest-dev |
| 08:51 |
|
Krock joined #minetest-dev |
| 08:56 |
VanessaE |
gregorycu: [12-31 21:16] <gregorycu> How's everyone's 1st day of the year? <--- got sufficiently drunk for a bit, and walked away without a hangover. I'd call that a good start. :) |
| 09:01 |
|
kaeza joined #minetest-dev |
| 10:04 |
|
celeron55_ joined #minetest-dev |
| 10:24 |
|
celeron55 joined #minetest-dev |
| 10:34 |
|
celeron55 joined #minetest-dev |
| 11:03 |
|
red-001 joined #minetest-dev |
| 11:04 |
|
alket joined #minetest-dev |
| 11:57 |
|
red-001 joined #minetest-dev |
| 12:21 |
|
zupomanek joined #minetest-dev |
| 12:32 |
|
CraigyDavi joined #minetest-dev |
| 12:42 |
|
cmdskp joined #minetest-dev |
| 12:53 |
|
DFeniks joined #minetest-dev |
| 12:59 |
cmdskp |
ooo, I like the new fire flames hugging close to the blocks - neat! |
| 13:13 |
red-001 |
It was like that for the past few months |
| 13:13 |
red-001 |
at least the past few months |
| 13:14 |
cmdskp |
I've been playing mostly on an old Carbone server, it only got updated a couple weeks ago |
| 13:15 |
red-001 |
and you only got around to setting things on fire now? |
| 13:15 |
cmdskp |
I usually put things out |
| 13:15 |
red-001 |
the fire is a lot slower then it used to be |
| 13:15 |
red-001 |
just as cpu expensive through |
| 13:16 |
cmdskp |
I've made some modifications to speed it up a little and allow flammable nodes to handle what happens to them when the flammable nodes finally get burnt/removed |
| 13:16 |
red-001 |
thats a good idea |
| 13:17 |
red-001 |
so a callback like on_burn? |
| 13:17 |
cmdskp |
yep, on_burnt |
| 13:17 |
cmdskp |
could be on_burn |
| 13:17 |
cmdskp |
mmm, choices |
| 13:17 |
red-001 |
or there could be two |
| 13:17 |
red-001 |
on for burning one for burnt |
| 13:18 |
red-001 |
so did you do it all in lua? |
| 13:18 |
cmdskp |
well, I allow the on_burn(t) to return a true/false/nothing and remove based on that, thus allowing the on_burn(t) to either handle the removal or by default, fire will remove |
| 13:19 |
cmdskp |
yeah, it's only a 1 in four chance of burnt happening originally |
| 13:19 |
cmdskp |
I kept that bit in |
| 13:19 |
red-001 |
so it's like the new tnt callback on_blast ? |
| 13:20 |
cmdskp |
yes, I think so |
| 13:21 |
red-001 |
maybe you should open a PR then |
| 13:23 |
cmdskp |
I pass in the position, node name that's burning it and an action string "remove" - to tell the flammable node what's potentially happening to it. The action string isn't really necessary, but offers potential in other situations |
| 13:23 |
cmdskp |
I was thinking about our the idea on_damage |
| 13:24 |
cmdskp |
where different actions can cause damage |
| 13:25 |
cmdskp |
but it's not desirable to have tons of callback functions for each possible cause of damage, hence the idea of an action string parameter |
| 13:25 |
red-001 |
good idea |
| 13:28 |
cmdskp |
I like your suggestion of on_burn, changing to it - makes more sense, since it's not necessarily removed/burnt until the function returns |
| 13:30 |
cmdskp |
I better check furnaces don't have that though |
| 13:34 |
|
CraigyDavi joined #minetest-dev |
| 13:37 |
|
Fixer joined #minetest-dev |
| 13:37 |
|
behalebabo joined #minetest-dev |
| 13:44 |
cmdskp |
here's a thought - define a fire.version to allow mods to determine if they need to handle later version functionality themselves or not |
| 13:44 |
cmdskp |
same with other default mods that get new, added API features? |
| 13:47 |
celeron55 |
feature lists are better than version numbers for that purpose |
| 13:48 |
cmdskp |
but how can you tell if a mod uses a call-back function? |
| 13:50 |
cmdskp |
e.g. fire gets the ability to call node.on_burn, other mods either need to replicate this functionality for version of fire mod that don't have it, or they can utilise the same ABM the higher version Fire has, rather than create their own duplicate |
| 13:51 |
cmdskp |
a fire.version number provides a means to determine this and reduce ABM registering by other mods |
| 13:52 |
celeron55 |
you add a fire.features = {} and fire puts on_burn_callback = true in it if it supports that |
| 13:53 |
cmdskp |
ah, I see what you're getting at |
| 13:53 |
celeron55 |
the "version"-checking code then becomes much more understandable and doesn't require federated control of the fire mod; i.e. forks work fine no matter what features they choose to support |
| 13:54 |
red-001 |
do any mods in minetest game do this? |
| 13:54 |
cmdskp |
never hurts to start =) |
| 13:54 |
celeron55 |
minetest does this itself too, altough it's rarely used because most features can be checked without it |
| 13:55 |
celeron55 |
https://github.com/minetest/minetest/blob/master/builtin/game/features.lua |
| 13:57 |
celeron55 |
none of those features can be checked in any other reasonable way, which is why they are there |
| 13:59 |
red-001 |
makes sense |
| 13:59 |
celeron55 |
usually new features can be detected by just checking if a function exists, or are backwards compatible in a way that makes a mod not have to care if they exist or not |
| 14:32 |
|
Darcidride joined #minetest-dev |
| 14:44 |
|
rubenwardy joined #minetest-dev |
| 14:57 |
|
cmdskp joined #minetest-dev |
| 15:00 |
cmdskp |
default Fire on_burn callback, includes a small optimisation by removing a duplicate call to find_node_near before removing flammable nodes: https://github.com/minetest/minetest_game/pull/766 |
| 15:32 |
red-001 |
could you document this in game_api.txt? |
| 15:32 |
cmdskp |
good point! |
| 15:32 |
red-001 |
use the markdown format |
| 15:32 |
|
leat joined #minetest-dev |
| 15:38 |
|
kaadmy joined #minetest-dev |
| 15:46 |
celeron55 |
https://github.com/minetest/minetest/issues/3084 |
| 15:47 |
celeron55 |
this has gotten no comments during all this time |
| 15:47 |
|
zat joined #minetest-dev |
| 15:47 |
celeron55 |
i think i will do what i describe in it then |
| 15:54 |
cmdskp |
@red-001: I've added a section now: https://github.com/minetest/minetest_game/pull/767 |
| 15:56 |
celeron55 |
https://gist.github.com/celeron55/27245358fb5cdcc90c3e |
| 15:56 |
red-001 |
you should do it as one PR |
| 15:56 |
celeron55 |
so does somebody now suddenly after half a year find an issue in this proposed fix? |
| 15:57 |
celeron55 |
i guess no but i'll wait for 10 minutes |
| 15:57 |
cmdskp |
How do you merge two PRs done via the github website? |
| 15:57 |
red-001 |
what os do you have? |
| 15:57 |
cmdskp |
currently, I'm unable to use other tools |
| 15:58 |
red-001 |
ok then edit the branch cmdskp:patch-2 |
| 15:58 |
red-001 |
with the documentation |
| 15:59 |
red-001 |
https://github.com/cmdskp/minetest_game/tree/patch-2 |
| 16:00 |
cmdskp |
ty for link! |
| 16:23 |
celeron55 |
did it https://github.com/minetest/minetest/commit/64c060e1f2d94d8277246d8cdd8a886010564770 |
| 16:45 |
|
paramat joined #minetest-dev |
| 16:46 |
paramat |
any help appreciated https://github.com/minetest/minetest/pull/3501#issuecomment-168315892 |
| 16:56 |
red-001 |
how could ignores be place accidently? |
| 16:57 |
|
hmmmm joined #minetest-dev |
| 16:57 |
red-001 |
maybe users shouldn't be able to use giveme to get ignore |
| 16:58 |
red-001 |
there is no good reason for them to be able to anyway |
| 16:59 |
red-001 |
it is impossible to place it with setnode |
| 17:00 |
celeron55 |
paramat: you didn't add reading of it from lua |
| 17:01 |
paramat |
thanks |
| 17:01 |
celeron55 |
script/common/c_content.cpp |
| 17:02 |
paramat |
ok |
| 17:04 |
paramat |
found it |
| 17:07 |
cmdskp |
I was wondering, who are the current core developers in minetest? (and their areas of interest?) |
| 17:07 |
red-001 |
^ |
| 17:10 |
paramat |
https://github.com/orgs/minetest/people except calinou rubenwardy |
| 17:10 |
celeron55 |
wait why is the minetest team secret? |
| 17:10 |
cmdskp |
do any of them use siginifcantly different aliases on chat? |
| 17:10 |
celeron55 |
did github change some defaults or something |
| 17:11 |
paramat |
most are currently elusive :} |
| 17:11 |
celeron55 |
https://github.com/orgs/minetest/teams/team-minetest https://github.com/orgs/minetest/teams/minetest-website-team |
| 17:12 |
celeron55 |
now it's not secret |
| 17:12 |
kaadmy |
they are for me ;) |
| 17:12 |
cmdskp |
I recognise most of them, except kahrl, kwolekr, Ekdohibs |
| 17:12 |
kaadmy |
need to sign in for both links |
| 17:12 |
celeron55 |
cmdskp: people use all kinds of names, sometimes i don't even know them myself |
| 17:13 |
cmdskp |
How about 'asl97' and 'troller'? |
| 17:13 |
paramat |
ekdohibs == nore kwolekr == hmmmmm |
| 17:13 |
cmdskp |
ah, ty, paramat :) |
| 17:14 |
red-001 |
thanks |
| 17:14 |
kaadmy |
ty :) |
| 17:14 |
kaadmy |
cmdskp: i think it's 'proller'? |
| 17:14 |
red-001 |
could be |
| 17:15 |
paramat |
luckily pr/troller is not a dev |
| 17:15 |
celeron55 |
also shadowninja uses some weird name sometimes |
| 17:15 |
celeron55 |
i... think |
| 17:15 |
paramat |
'tesseract?' |
| 17:15 |
paramat |
troller == proller |
| 17:16 |
cmdskp |
ty again |
| 17:17 |
celeron55 |
the areas of interest thing is a difficult question |
| 17:17 |
celeron55 |
i don't even know my own areas of interest |
| 17:17 |
celeron55 |
so there you go |
| 17:18 |
cmdskp |
=] |
| 17:19 |
celeron55 |
i guess it would be possible to write some kind of a list of what people generally do but that hasn't been done |
| 17:19 |
red-001 |
where does the server decide what blocks does it sent to clients? |
| 17:20 |
celeron55 |
clientiface.cpp |
| 17:20 |
red-001 |
thanks |
| 17:20 |
celeron55 |
well, mostly |
| 17:21 |
red-001 |
I what way? |
| 17:21 |
red-001 |
in* |
| 17:22 |
paramat |
in a partial way |
| 17:23 |
|
asl joined #minetest-dev |
| 17:25 |
celeron55 |
8D |
| 17:25 |
celeron55 |
i'm pretty sure it's what you are asking; ask again with more details if it turns out not to be |
| 17:26 |
celeron55 |
it's again one of the things my far-map branch reworks in a major way though |
| 17:26 |
kaadmy |
farmesh* |
| 17:32 |
|
rubenwardy joined #minetest-dev |
| 17:46 |
red-001 |
where does the server decide to load a block/sector from disk or generate it? |
| 17:47 |
celeron55 |
that's kind of uncomfortably spread around; but you're looking at emerge.cpp and then whatever that calls from map.cpp |
| 17:47 |
celeron55 |
and whoever calls the stuff in emerge.cpp |
| 17:47 |
celeron55 |
mostly it's called by clientiface.cpp but there are other minor cases |
| 17:49 |
|
asl joined #minetest-dev |
| 17:49 |
red-001 |
ok thanks |
| 17:54 |
red-001 |
wow loadBlock still supports loading maps form versions of minetest that didn't use databases |
| 17:55 |
red-001 |
I didn't know minetest is that backwards compatible |
| 17:58 |
|
rubenwardy joined #minetest-dev |
| 18:00 |
celeron55 |
i wouldn't be so sure that it works because nobody ever tests it |
| 18:00 |
celeron55 |
i have a mini test framework for testing world compatibility though: https://github.com/celeron55/minetest-worldtest |
| 18:00 |
celeron55 |
that doesn't include pre-sqlite versions by default though |
| 18:01 |
celeron55 |
and it's 3 years old 8) |
| 18:03 |
celeron55 |
i don't remember why i made that to begin with... i guess there was some rework being done and i wanted to make sure things stayed compatible |
| 18:05 |
celeron55 |
i guess it would be fairly easy to add a rule for modern minetest versions which would stay compatible for a long time |
| 18:05 |
celeron55 |
0.4.3's hacks needed for that aren't going to apply to 0.4.13 |
| 18:06 |
|
Amaz joined #minetest-dev |
| 18:11 |
red-001 |
so how do positions work in minetest? Is the position of a mapblock the node at its center? |
| 18:11 |
|
BlockMen joined #minetest-dev |
| 18:12 |
celeron55 |
the position of the node at the mapblock's origin (which is at a corner) is the mapblock's position * 16 |
| 18:12 |
BlockMen |
Taking a break from Minetest for a bit now. Backported a few things from blockplanet, see #3513 #3514 #3515 #3516 |
| 18:13 |
|
rubenwardy_ joined #minetest-dev |
| 18:14 |
paramat |
thanks for those |
| 18:35 |
|
blert2112 joined #minetest-dev |
| 18:36 |
red-001 |
est31 |
| 18:37 |
|
paramat left #minetest-dev |
| 18:40 |
|
blert2112 left #minetest-dev |
| 18:43 |
red-001 |
when breaking a line like return true or false do you indent once or twice? |
| 18:46 |
cmdskp |
looking at the style guide, I'd say once after the 'or' |
| 18:46 |
cmdskp |
http://dev.minetest.net/Code_style_guidelines |
| 18:47 |
red-001 |
well some people complain about others not reading style guides and don't know the guides themselves |
| 18:48 |
red-001 |
does this also apply to lua? |
| 18:48 |
cmdskp |
I'm looking at the examples shown on that page, like the "bool success = " |
| 18:49 |
cmdskp |
http://dev.minetest.net/Lua_code_style_guidelines |
| 18:50 |
cmdskp |
It would appear to be two tabs... |
| 18:50 |
cmdskp |
in Lua |
| 18:51 |
red-001 |
the lua example only show continuing lines in if/else statements and function arguments |
| 18:51 |
cmdskp |
I would consider a return with an or, similar to an if/else |
| 18:52 |
red-001 |
what about a variable definition with a or statement |
| 18:54 |
cmdskp |
For all these, if they are short together, I'd put them on the same line, if long, I'd follow the two-tabs as it seems to be mentioned in all other line breaks on that guide |
| 18:55 |
cmdskp |
unless it's particularly many 'or's, where having them on separate lines aids readability |
| 18:55 |
|
Taoki joined #minetest-dev |
| 18:55 |
red-001 |
yeah |
| 18:56 |
red-001 |
I looks strange to have a double indent in the middle of variable definitions |
| 19:01 |
cmdskp |
I tend to follow the cardinal rule of using non-abbreviated, meaningful variable names - with the added benefit of them stretching over to those double tabs =) |
| 19:14 |
|
blert joined #minetest-dev |
| 19:28 |
|
Drangue joined #minetest-dev |
| 19:56 |
|
paramat joined #minetest-dev |
| 19:58 |
paramat |
just realised i don't need to add a 'floodable' node property, i can check for 'buildabe to' and not 'ignore' |
| 19:58 |
red-001 |
..... |
| 19:58 |
kaadmy |
yep |
| 19:58 |
paramat |
then water can be used to clear areas of long grasses |
| 19:59 |
cmdskp |
that's good |
| 20:01 |
cmdskp |
It looks like it'd be useful to have a find_total_nodes_in_area that just returns the number found(up to a limit parameter, if supplied), rather than the heavy uses of find_nodes_in_area in Fire and Flowers currently. find_nodes_in_area creates two table results and processes every node in big blocks usually, when often mods only want to check if there are X matches present and don't care about positions or overall total tables returned |
| 20:02 |
paramat |
no drops, 'buildable to' nodes are destroyed when 'built to', we can consider the water node is being built in the node |
| 20:04 |
red-001 |
well someone will use this for griefing |
| 20:04 |
red-001 |
sooner or latter |
| 20:05 |
cmdskp |
This is true, esp. I imagine with arranged flowers? |
| 20:05 |
cmdskp |
or would they survive? |
| 20:05 |
red-001 |
greifers heaven |
| 20:06 |
red-001 |
maybe it time minetest get protection integrated |
| 20:06 |
red-001 |
gets* |
| 20:06 |
paramat |
hm, so it may still be preferable to have a 'floodable' property, it's actually faster to process |
| 20:07 |
red-001 |
how much faster? |
| 20:07 |
paramat |
only slightly, one bool to check instead of a bool and a content id |
| 20:08 |
paramat |
i don't often think about griefers.. |
| 20:08 |
cmdskp |
a 'floodable' property does allow more control...and games can easily overwrite it to change default behaviour of water/lava removing plants, flower, etc. |
| 20:08 |
cmdskp |
though lava already does that =) |
| 20:08 |
cmdskp |
I think |
| 20:09 |
paramat |
there are probably cases where someone would not want water to destroy 'buildable to' |
| 20:09 |
red-001 |
true |
| 20:09 |
paramat |
ok floodable it is |
| 20:10 |
cmdskp |
it seems preferable, all ways round =) |
| 20:13 |
sofar |
I like it |
| 20:14 |
sofar |
flooding water just needs to check protection |
| 20:14 |
sofar |
of course, that would prevent people from flood-farming their own crops |
| 20:14 |
cmdskp |
sounds costly, performance-wise though - the code does a lot of removal/re-adding water round the fringe nodes |
| 20:15 |
* cmdskp |
was experimenting with trying to change it from draining away to air and instead leave a block - I got a very nice crust round about it, instead. |
| 20:15 |
paramat |
i think protection checks in liquid flow was rejected recently for performance reasons |
| 20:16 |
paramat |
servers can just be careful what nodes they make 'floodable' |
| 20:17 |
red-001 |
is there any reason that protection isn't integrated into minetest |
| 20:17 |
red-001 |
other then no one adding it of course |
| 20:18 |
sofar |
well, I personally don't care too much about griefing problems |
| 20:18 |
sofar |
so, full steam ahead with "floodable" :) |
| 20:19 |
red-001 |
in what corner of the block is the origin? |
| 20:21 |
paramat |
minimum point |
| 20:22 |
paramat |
all co-ords at minimum value |
| 20:22 |
red-001 |
thanks |
| 20:24 |
cmdskp |
I'm limited to a text editor atm, anyone know the MAX constant name for u64? |
| 20:25 |
paramat |
yeah um.. |
| 20:26 |
paramat |
U64_MAX i think |
| 20:27 |
cmdskp |
much appreciated! |
| 20:31 |
celeron55 |
UINT64_MAX |
| 20:32 |
cmdskp |
tyvm |
| 21:03 |
paramat |
okay https://github.com/minetest/minetest/pull/3501 'Liquids: Flow into and destroy 'floodable' nodes' is ready for review. this is a step towards enabling space subgames and mapgen < hmmmm |
| 21:06 |
|
red-001 joined #minetest-dev |
| 21:11 |
|
red-001 joined #minetest-dev |
| 21:29 |
cmdskp |
paramat, possibility for dropping the node as an item as well as destroying the node? E.g. washed off torches in water, etc. |
| 21:31 |
kaadmy |
cmdskp: afaik that's what MeinCrapt does with farming stuff; if you flood a field of harvestable wheat, it'll harvest it all |
| 21:31 |
kaadmy |
then you can have auto-harvesting, too |
| 21:31 |
kaadmy |
and itemdrops flow with water ;) |
| 21:31 |
cmdskp |
I didn't know about farming stuff doing that there |
| 21:31 |
kaadmy |
only in MC |
| 21:31 |
kaadmy |
MT doesn't have it |
| 21:34 |
paramat |
yeah i should some text about drops |
| 21:35 |
kaadmy |
imho just having water floodand drop buildable_to nodes would be nice, having itemdrops flow in water wouldjust be better :) |
| 21:35 |
paramat |
no drops for simplicity and speed, and because it's not much needed, this is meant to be similar to 'buildable to' in that the node is destroyed when liquid is 'built to' it |
| 21:36 |
paramat |
drops could be coded later i guess |
| 21:37 |
cmdskp |
It should be relatively easy then, just add an item entity when floodable found |
| 21:38 |
paramat |
this commit is mainly about allowing liquids to flow into 'airlike' nodes, stuff you don't want dropped |
| 21:39 |
cmdskp |
ah |
| 21:40 |
sofar |
can it cause on_destroy() to get called? |
| 21:41 |
paramat |
hm i'm not sure it will do that.. |
| 21:41 |
cmdskp |
I doubt it will |
| 21:41 |
paramat |
it might not do that for speed |
| 21:42 |
sofar |
alternatively you'd have an ABM for fluid nodes, check the fuild level is high enough then flood certain items, all from lua |
| 21:46 |
|
CraigyDavi joined #minetest-dev |
| 21:48 |
|
alket joined #minetest-dev |
| 21:59 |
|
Red-001 joined #minetest-dev |
| 22:32 |
|
est31 joined #minetest-dev |
| 22:34 |
est31 |
I'd like to announce: I'll do a pause from minetest. plan is that you don't hear alot from me for the next 8 weeks. |
| 22:34 |
est31 |
have fun. |
| 22:34 |
celeron55 |
is this stuff organized somewhere outside of this channel because BlockMen just did the same |
| 22:36 |
paramat |
coincidence i think |
| 22:39 |
paramat |
now we're really short of devs :) |
| 22:40 |
|
cmdskp joined #minetest-dev |
| 22:45 |
celeron55 |
maybe; i'm just wondering |
| 22:45 |
celeron55 |
i guess people decide to want to focus on something new as it's a new year again |
| 22:47 |
celeron55 |
but it doesn't exactly create a very upbeat atmosphere when people disagree about things and then some of those leave for months |
| 22:48 |
celeron55 |
i'm just numb to this already; if everything is exploding and i just don't see it, good luck to everyone lol |
| 22:49 |
paramat |
nah many devs are busy, some just feel they need a break |
| 22:50 |
dzho |
it's healthier for people to realize they need a break, and then to take it, then to reach the breaking point anyway and it turn unpleasant |
| 22:50 |
dzho |
s/then/than/ |
| 22:50 |
red-001 |
talking about explosions https://github.com/minetest/minetest_game/pull/667 |
| 22:52 |
celeron55 |
dzho: for sure yes; it's often hard to discern those two... altough i have seen that the burnout is often preceded by a rant of some kind somewhere 8) |
| 22:52 |
celeron55 |
(yes i have seen too much of that) |
| 22:53 |
paramat |
some of our devs are now at university age and are increasingly busy |
| 22:54 |
celeron55 |
one failure mode of a free-time project like this is that people get old and go to universities and start families and become so busy they can't do anything anymore |
| 22:55 |
celeron55 |
i'm sure most people will end up being like that |
| 22:56 |
paramat |
well luckily we do have some 'older' devs |
| 22:56 |
celeron55 |
the question is whether there are enough remaining ones and whether there is enough influx of people that there's at least some that will stick for a while |
| 23:07 |
paramat |
it's ok, there's enough for slower, simpler dev, and there are some new people |
| 23:14 |
red-001 |
https://github.com/minetest/minetest/pull/3504 |
| 23:14 |
red-001 |
add back the old settings tab |
| 23:20 |
|
VargaD joined #minetest-dev |
| 23:23 |
|
zupomanek joined #minetest-dev |
| 23:25 |
|
est31 joined #minetest-dev |
| 23:26 |
VanessaE |
celeron55: I think it's more a matter of frustration than burnout |
| 23:26 |
est31 |
Note i am not in cahoots with blockmen, i just saw what he announced, and thought well I can do similar as well |
| 23:27 |
est31 |
I'd wanted to focus on other projects for some few months already |
| 23:27 |
est31 |
but didnt have the time, always uni and minetest and other stuff |
| 23:27 |
celeron55 |
no worries; but it's nice if people explain what they're doing instead of minetest |
| 23:28 |
celeron55 |
i do a lot of "other projects" personally too |
| 23:28 |
est31 |
I want to learn the rust programming language |
| 23:28 |
est31 |
I've already done some projects |
| 23:28 |
est31 |
small ones |
| 23:29 |
est31 |
https://github.com/est31/podiff-review |
| 23:29 |
est31 |
I want to write an ogg decoder in rust |
| 23:29 |
kaadmy |
est31: i plan on learning Rusy, too :) |
| 23:30 |
est31 |
but I am new to the subject of audio codecs so its time intensive |
| 23:30 |
kaadmy |
this is one reason:https://www.reddit.com/r/programming/comments/3qp5j9/rustdoom_a_reimplementation_of_doom_in_idiomatic/ |
| 23:31 |
est31 |
and uni testing phase is in those 8 weeks as well |
| 23:32 |
est31 |
including the preparation phase |
| 23:35 |
est31 |
I'll still follow + review sofar 's nodebox connection pr, i really like the feature. |
| 23:35 |
VanessaE |
it almost looks like that ^^^ could supply the "cable like" thing wanted for technic |
| 23:36 |
est31 |
yeah, if it isnt able to support it, I won't +1 it |
| 23:36 |
est31 |
only problem will be switching station I think |
| 23:36 |
est31 |
because it only allows cable to be below |
| 23:37 |
est31 |
would break some builds probably... |
| 23:37 |
VanessaE |
well that was how technic originally intended the cabling to work |
| 23:37 |
|
paramat left #minetest-dev |
| 23:37 |
VanessaE |
I'm pretty sure that cables connecting from the sides originated as a bug |
| 23:38 |
est31 |
well even that can be encoded into the nodedef |
| 23:38 |
VanessaE |
yeo |
| 23:38 |
VanessaE |
yep |
| 23:38 |
est31 |
it just gets bit complicated |
| 23:39 |
est31 |
so you'll have 7 values in the nodedef or so, each of them containing a list of node groups, to which the defined node should connect to, to which side (6 sides, and one for "connect no matter which side") |
| 23:40 |
sofar |
wait what? |
| 23:40 |
sofar |
is this about my PR? |
| 23:40 |
est31 |
yes. |
| 23:40 |
sofar |
sorry I just rebooted after adding 6gb to my system, missed the backlog until just now |
| 23:41 |
est31 |
http://irc.minetest.ru/minetest-dev/2016-01-01#i_4490537 |
| 23:41 |
est31 |
there it starts |
| 23:42 |
est31 |
but the pr is already looking really good |
| 23:42 |
sofar |
I hope people saw the third cross-bar in the fence in the screenshot ... |
| 23:43 |
VanessaE |
I saw it. |
| 23:43 |
sofar |
ah ok thanks for posting the logs |
| 23:43 |
VanessaE |
not sure what I think of that other than "nice touch", given that everyone's used to two-rung fences. |
| 23:44 |
sofar |
it was to demonstrate that it really was a different fence model |
| 23:44 |
sofar |
I can do a picket fence too if you desire :) |
| 23:44 |
VanessaE |
I assumed, yeah |
| 23:44 |
VanessaE |
oooohhh.... |
| 23:44 |
VanessaE |
you got my attention with that :) |
| 23:45 |
sofar |
I'm letting the PR accrue some thought and will resubmit in a few days when I get to addressing all the comments |
| 23:45 |
sofar |
my brain works better not touching code for a few days before I code it all up at once |
| 23:46 |
sofar |
est31: the wires aren't necessarily ideal just yet, if you ask me, but it works. It's just different than current wires |
| 23:46 |
sofar |
also the question as to what-does-it-connect-to needs to be solved |
| 23:47 |
sofar |
which will need a new lua option |
| 23:47 |
VanessaE |
sofar: treat it like that "connected fences" PR |
| 23:47 |
sofar |
I'm thinking, by default, just connect to only the same node name |
| 23:47 |
VanessaE |
i.e. a node def field for the object the connected-nodebox-thing should connect to |
| 23:48 |
VanessaE |
i.e. the wire has a field that says "connect to foo in direction +Y" |
| 23:48 |
sofar |
well I can see multiple ways |
| 23:48 |
sofar |
e.g. group fences connect to group |
| 23:48 |
sofar |
but also, connect to drawtypes perhaps |
| 23:48 |
VanessaE |
or, put multiple fields into the node connected to, e.g. the generic machine has a field that says "wire of node name foo:bar can connect to me from direction -Y" |
| 23:48 |
sofar |
and some to just specific nodes? of course that could be groups |
| 23:49 |
sofar |
oh |
| 23:49 |
VanessaE |
(s/node name/node or group name/) |
| 23:49 |
sofar |
the node lookup currently is too stupid to know that if it can connect to the North, the other end may not connect to the South |
| 23:49 |
sofar |
so that needs fixing as well |
| 23:50 |
sofar |
but if the switching station only has connections downwards, that would solve that problem |
| 23:50 |
sofar |
anyway, I need to AFK some more |
| 23:50 |
sofar |
I'll catch any irc log tho |
| 23:50 |
sofar |
------ |
| 23:50 |
VanessaE |
also, supply converters aree only supposed to connect from top and tbottom |
| 23:51 |
VanessaE |
-e -t |
| 23:52 |
VanessaE |
(personally, I'd be happy if ALL technic machines, save for supply converters and battery boxes, only connected from the bottom, and those two specifically top-or-bottom) |
| 23:52 |
est31 |
well it does make building nice walls consisting from machines impossible |
| 23:56 |
|
Lunatrius` joined #minetest-dev |
| 23:57 |
|
werwerwer joined #minetest-dev |
| 23:58 |
|
Ritchie_ joined #minetest-dev |
| 23:59 |
|
VanessaE_ joined #minetest-dev |
| 23:59 |
VanessaE_ |
netsplit? |
