| Time |
Nick |
Message |
| 00:04 |
nore |
sofar: if class Client, why is there such an enormous hole reported after m_env? |
| 00:04 |
nore |
more precisely, if reports an hole of 368 bytes |
| 00:04 |
nore |
but it jumps 130kB |
| 00:05 |
nore |
seems like a pahole bug to me |
| 00:07 |
sofar |
I wonder if that's thread data |
| 00:07 |
sofar |
but yeah, that's entirely weird |
| 00:08 |
nore |
well pahole seems to report that something strange is going on as well |
| 00:12 |
paramat |
#5625 updated and tested so will merge in a while |
| 00:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/5625 -- Mgflat, Mgv7: Only create noise objects if needed by paramat |
| 00:14 |
nore |
anyway I'll try to see how many TileLayer copies I can avoid |
| 00:14 |
nore |
and let's hope it increases performance :) |
| 00:15 |
paramat |
nore ok with #5619 ? |
| 00:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/5619 -- Add on_flood() callback. by sofar |
| 00:16 |
nore |
paramat: yes |
| 00:16 |
paramat |
ok will merge later |
| 00:19 |
paramat |
will merge #5619 #5623 #5625 #5630 in a few mins |
| 00:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/5619 -- Add on_flood() callback. by sofar |
| 00:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/5623 -- Sneak glitch: Set default to false by paramat |
| 00:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/5625 -- Mgflat, Mgv7: Only create noise objects if needed by paramat |
| 00:19 |
ShadowBot |
https://github.com/minetest/minetest/issues/5630 -- Add /fixlight chat command by juhdanad |
| 00:23 |
|
kaeza joined #minetest-dev |
| 00:28 |
paramat |
merging .. |
| 00:32 |
paramat |
complete |
| 00:32 |
paramat |
lots of good stuff |
| 00:44 |
sofar |
maybe we can remove the lava cooling abm now |
| 00:45 |
sofar |
hadn't actually tried it yet |
| 00:45 |
VanessaE |
remove it in favor of..? |
| 00:45 |
sofar |
using on_flood() |
| 00:45 |
VanessaE |
right |
| 00:45 |
VanessaE |
bear in mind, gloopblocks uses the lavacooling abm |
| 00:45 |
VanessaE |
to alter it to work better. |
| 00:48 |
VanessaE |
(though I could simply redefine the two nodes to point to my code) |
| 00:56 |
paramat |
finally closed #47 |
| 00:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/47 -- Water Physics |
| 00:56 |
VanessaE |
wow, that's an OLD one... |
| 00:56 |
paramat |
issue moves to MTG |
| 00:57 |
VanessaE |
oh |
| 00:58 |
VanessaE |
as for torches, and maybe signs, for G*d sakes please DO flood them |
| 00:58 |
VanessaE |
there's little else I find more annoying than seeing people use those as a cheat to make a "water portal" thing :P |
| 01:03 |
paramat |
yeah maybe torches |
| 01:03 |
|
kaeza joined #minetest-dev |
| 01:04 |
VanessaE |
signs too. an argument can be made for OPEN wooden doors also |
| 01:04 |
VanessaE |
(maybe even open glass doors, but obsidian glass doors could be considered strong enough to withstand the water) |
| 01:06 |
paramat |
signs means then ladders, doors etc. and these do not make sense being removed by water |
| 01:06 |
nore |
sofar: not as easy as it seems |
| 01:06 |
VanessaE |
naw, you don't have to wash ALL of that away |
| 01:06 |
nore |
i.e. if you're just at the extreme of the liquid range |
| 01:07 |
VanessaE |
it's really too bad there isn't some way to make them look like they're under water e.g. no air |
| 01:07 |
paramat |
and i am very keen to avoid as much as possible liquids becoming destructive, due to ease of griefing combined with how water spreads out onto massive waterfalls so easily |
| 01:07 |
nore |
lava and water can be next to each other without flowin in each other |
| 01:07 |
nore |
+g |
| 01:08 |
paramat |
a sign mkes no sense being removed, it is something fixed securely to a wall, we cannot decide it according to 'it only taking up a small part of a node' |
| 01:08 |
sofar |
correct |
| 01:08 |
VanessaE |
that would indeed break a pumice/basalt generator |
| 01:08 |
sofar |
I'm not entirely convinced the ABM can be removed either |
| 01:08 |
paramat |
*makes |
| 01:08 |
nore |
well there is a solution |
| 01:08 |
VanessaE |
paramat: oh... see I always looked at wall signs like a wall clock - barely hanging on the node with a small nail in the back |
| 01:08 |
sofar |
allow on_flood to air |
| 01:09 |
nore |
I was thinking about something more general |
| 01:09 |
nore |
calling nodeupdate or whatever it is called now |
| 01:09 |
VanessaE |
sofar, why not just check horizontally during flooding also? |
| 01:09 |
sofar |
ahh yes |
| 01:09 |
nore |
and allow mods to register functions when a node is updated |
| 01:10 |
nore |
maybe even do the following instead: |
| 01:10 |
nore |
"nodeupdate" or its equivalent |
| 01:10 |
nore |
looks at the adjacent nodes |
| 01:10 |
sofar |
on_nodeupdate? |
| 01:10 |
nore |
yes |
| 01:11 |
nore |
then you can add an on_nodeupdate to lava that checks if water is next to it |
| 01:11 |
nore |
likewise, falling nodes would have an on_nodeupdate that makes them check for falling |
| 01:12 |
nore |
minetest.set_node/remove_node/swap_node would call these on_nodeupdate |
| 01:12 |
nore |
but not voxelmanips, for performance |
| 01:12 |
nore |
seems like a reasonable way to me to handle that and maybe get rid of ABMs entiremy |
| 01:12 |
nore |
*entirely |
| 01:13 |
nore |
and ABMs can take quite a lot of time, even if there are no ABMs running because you still have to check all nodes and all ABMs, which can take a long time is there are a lot of active mapblocks |
| 01:14 |
nore |
would get rid of all these rarely-firing ABMs as well such as grass<->dirt conversions |
| 01:14 |
VanessaE |
sofar, pm for a moment.. |
| 01:14 |
nore |
just check for the new condition on update and set a timer if needed |
| 01:15 |
paramat |
i wouldn't be concerned about water and liquid adjacent at the extremes of their range, unless this causes a big problem |
| 01:15 |
paramat |
*water and lava |
| 01:16 |
nore |
paramat: well, as I said, a way to reliably check some things only on node update would be to have such a node update callback |
| 01:16 |
nore |
even liquids could use it to check if they need to flow as well |
| 01:17 |
nore |
and so these on_flood callbacks preventing flooding could be done to run only once |
| 01:19 |
paramat |
ok i need to process that. what i'm saying is lava cannot keep checking around itself for performance reasons unless absolutely essential, remember we have massive caverns now with potentially massive lava flows |
| 01:21 |
nore |
paramat: that's what I am saying |
| 01:22 |
paramat |
anyway, i suggest trying lavacooling via on-flood in the simplest form first, then see what the problems are |
| 01:22 |
nore |
this would eliminate ABMs and the like completely |
| 01:22 |
nore |
and lava would check around itself only if a node near it is updated |
| 01:25 |
paramat |
i mean, we should try to avoid such checks even if only on nodeupdate, if they are not absolutely essential |
| 01:26 |
paramat |
maybe you mean your idea replaces using on-flood |
| 01:28 |
nore |
paramat: when a node is changed next to lava, check if the new node is lava |
| 01:29 |
nore |
That's about the best you can do |
| 01:30 |
paramat |
ok anyway i'll understand later i'm sure |
| 01:33 |
paramat |
indeed i'm not even sure how or if lavacooling by on_flood would work |
| 01:34 |
paramat |
if lava was 'floodable' that might cause waterflow chaos |
| 01:34 |
paramat |
sorry, liquid flow chaos |
| 01:35 |
paramat |
.. lava constantly flooding itself away etc |
| 01:36 |
|
ssieb joined #minetest-dev |
| 02:09 |
paramat |
sorry, i misunderstood. the ideas have potential. it seems making a liquid floodable would be a disaster that would constantly overload the liquid queue |
| 02:16 |
|
benrob0329 joined #minetest-dev |
| 02:24 |
nore |
yeah, that probably wouldn't be good |
| 02:24 |
nore |
that's why I think on_nodeupdate would be a good idea :) |
| 02:27 |
Hijiri |
ah nodeupdate |
| 02:27 |
Hijiri |
feels like convergent evolution |
| 03:20 |
sofar |
now that nodeupdate no longer is recursing, it can handle hundreds of nodes per second |
| 03:23 |
nore |
well if we add an on_nodeupdate I think we should move that to the engine |
| 03:23 |
nore |
have a nodeupdate queue there |
| 03:24 |
nore |
and call the on_nodeupdate field of nodes each time a node next to them is modified |
| 03:26 |
paramat |
certainly in engine, the speed is needed |
| 03:28 |
nore |
the thing that will help most there will be C++ data structures |
| 03:28 |
nore |
like set<v3s16> |
| 03:30 |
nore |
(i.e: keep a set<v3s16> of nodes to process, and while any are remaining in that set, process that node: call its on_nodeupdate function, and of course, if that functions uses set_node or the like, it will add positions back to this set) |
| 03:30 |
nore |
(also, probably try to process them in a sensible order, such as decreasing Y for instance for liquids) |
| 03:31 |
|
octacian_ joined #minetest-dev |
| 03:34 |
sofar |
there's a perception that nodeupdate needs to be in C++ |
| 03:34 |
sofar |
I'm not entirely sure it is |
| 03:35 |
sofar |
when it's all in lua, we don't have any lua -> C -> lua calls |
| 03:35 |
sofar |
that's highly efficient |
| 03:35 |
nore |
sofar: the thing is, we want to use it for liquid queue as well |
| 03:36 |
nore |
and you don't have good data structures such as set<T> in lua unfortunately |
| 03:38 |
nore |
I mean, I really want to rewrite the nodeupdate system completely, in an almost non-backwards compatible manner |
| 03:38 |
nore |
so that falling nodes are only one of the cases of node updating |
| 03:38 |
|
octacian joined #minetest-dev |
| 03:38 |
nore |
brb |
| 03:47 |
sofar |
Thread 1 "minetest" received signal SIGSEGV, Segmentation fault. |
| 03:47 |
sofar |
0x0000000000c3f92c in Noise::~Noise (this=0xdbe8000002bfb813, __in_chrg=<optimized out>) |
| 03:47 |
sofar |
at /home/sofar/git/minetest/src/noise.cpp:446 |
| 03:47 |
sofar |
446delete[] gradient_buf; |
| 03:48 |
sofar |
not sure what is up there |
| 03:48 |
sofar |
but my test branch crashes each game exit |
| 03:49 |
paramat |
latest master? |
| 03:55 |
paramat |
oops mine too, my fault |
| 03:55 |
paramat |
crash when exiting to menu |
| 03:55 |
paramat |
will fix within a few hours |
| 03:56 |
paramat |
must be the noise objects that are not created, delete cannot find them |
| 03:56 |
paramat |
sorry everyone |
| 03:57 |
sofar |
no worries, easy find, easy fix? |
| 03:57 |
paramat |
hope so |
| 03:58 |
sofar |
57eaf62c697cec91890d9cb28d10385d293d2d3f ? |
| 03:58 |
paramat |
i probably didn't notice that in testing because i was always exiting to OS |
| 03:58 |
paramat |
yes |
| 04:03 |
paramat |
starting work on fix |
| 04:05 |
paramat |
crash should be affecting mgv7 and mgflat |
| 04:11 |
sofar |
out of curiosity, which noise was the problem? |
| 04:13 |
paramat |
any noise that had it's noise object not created due to mapgen flags, in mgv7 floatlands are disabled by default |
| 04:23 |
paramat |
#5639 but still need to test, will get that merged within 2 hrs |
| 04:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/5639 -- Mgflat, Mgv7: Fix noise crash on world exit. by paramat |
| 04:29 |
paramat |
tested |
| 04:31 |
Zeno` |
would have been easier to init all of the to NULL, but *shrug* :) |
| 04:32 |
paramat |
ahh |
| 04:33 |
paramat |
well this seems equally acceptable |
| 04:33 |
paramat |
will merge in a moment |
| 04:33 |
Zeno` |
yeah, just sayin' :D |
| 04:34 |
paramat |
it's helpful, good to know another way |
| 04:38 |
paramat |
merging |
| 04:40 |
paramat |
complete, thanks sofar for the report |
| 04:53 |
|
behalebabo joined #minetest-dev |
| 04:55 |
|
Hunterz joined #minetest-dev |
| 05:49 |
|
pbrunet joined #minetest-dev |
| 06:07 |
|
nerzhul joined #minetest-dev |
| 06:39 |
|
kaeza joined #minetest-dev |
| 07:07 |
|
Krock joined #minetest-dev |
| 07:07 |
|
Krock joined #minetest-dev |
| 07:55 |
|
Lunatrius` joined #minetest-dev |
| 08:13 |
|
kilbith joined #minetest-dev |
| 09:00 |
|
Lunatrius` joined #minetest-dev |
| 09:02 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:03 |
|
cx384 joined #minetest-dev |
| 09:16 |
|
juhdanad joined #minetest-dev |
| 09:24 |
|
Lunatrius joined #minetest-dev |
| 09:43 |
|
Gael-de-Sailly joined #minetest-dev |
| 09:58 |
|
Fixer joined #minetest-dev |
| 10:02 |
|
kilbith joined #minetest-dev |
| 10:08 |
|
DS-minetest joined #minetest-dev |
| 10:28 |
|
benrob0329 joined #minetest-dev |
| 10:37 |
|
lisac joined #minetest-dev |
| 10:57 |
|
Lunatrius` joined #minetest-dev |
| 11:38 |
|
benrob03291 joined #minetest-dev |
| 11:58 |
nerzhul |
merging #5573 |
| 11:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/5573 -- Network: Remove old opcodes and fix documentation. by red-001 |
| 11:59 |
nerzhul |
sfan5, i will factorize it today or tomorrow :) |
| 11:59 |
|
proller joined #minetest-dev |
| 12:00 |
sfan5 |
ok |
| 12:00 |
|
kilbith joined #minetest-dev |
| 12:19 |
|
DS-minetest joined #minetest-dev |
| 12:20 |
|
pbrunet joined #minetest-dev |
| 12:30 |
|
benrob0329 joined #minetest-dev |
| 13:24 |
|
rubenwardy joined #minetest-dev |
| 13:49 |
|
proller joined #minetest-dev |
| 13:55 |
Taoki |
I noticed that latest Git master still has a very annoying issue, which has always existed with Minetest. It still affects and breaks my structures mod, so maybe it can be fixed? |
| 13:56 |
Taoki |
The problem is that, when you spawn a lot of schematics at once, some of them will fail to spawn completely. Certain blocks will either not spawn, either remain the same as the original ones (so instead of stone, a few walls will still have dirt_with_grass for a wall or floor). |
| 13:57 |
Taoki |
I believe hmmm made the schematics. Not sure if he's still around, or uses a different nickname now (shouldn't have been away for so long once more) |
| 13:57 |
Taoki |
But yeah... would be appreciated if perhaps this could be put on someone's TODO list. It's be a major annoyance for any kind of city building mod. |
| 14:00 |
Taoki |
I remember that while trying to work around this problem, I even added a timer. So if 100 buildings were queued for spawning, the server would wait 5 seconds before spawning each. Yet even that did not fix it... it only introduced the horrible annoyance where it took 10 minutes for a large town to finish appearing. Nowdays I spawn per-chunk instead, but even that has the incompletion problem. |
| 14:01 |
rubenwardy |
issue? |
| 14:01 |
Taoki |
Oh... I don't believe I added one on the tracker actually. I really should, sorry >_< |
| 14:01 |
Taoki |
Or I might have and it's been forgotten somewhere on page +10 now. |
| 14:19 |
|
Tre joined #minetest-dev |
| 14:26 |
|
pandaro_ joined #minetest-dev |
| 14:31 |
rubenwardy |
nerzhul, signed commits has broken the PPA |
| 14:32 |
rubenwardy |
the engine in the package hasn't been updated to include any recent commits |
| 14:33 |
rubenwardy |
(reported by DS-minetest) |
| 14:33 |
sfan5 |
i have told him weeks ago |
| 14:33 |
sfan5 |
but he didn't care or something |
| 14:34 |
rubenwardy |
so our options are to 1) force push, 2) fork and use a different repo for PPA, 3) use another PPA 4) write a fix for the git library |
| 14:36 |
sfan5 |
1) nope 2) sounds like a good workaround for now 3) wat? 4) long-term solution |
| 14:36 |
rubenwardy |
or 5) pretend the PPAs don't exist, like nerzhul does |
| 14:40 |
rubenwardy |
https://help.launchpad.net/Code/Git#Mirroring_repositories_from_other_sites |
| 14:41 |
rubenwardy |
looks like LP supports git without the git-to-bzr library whih is broken |
| 15:01 |
|
Krock joined #minetest-dev |
| 15:02 |
nerzhul |
5/ was also sofar thinks |
| 15:03 |
nerzhul |
if you want a new build working without doubt https://gitlab.com/minetest/minetest/pipelines/7776360 |
| 15:03 |
nerzhul |
:D |
| 15:04 |
rubenwardy |
you should definitely fix or delete the PPA though, it is important for end users |
| 15:04 |
|
cx384 joined #minetest-dev |
| 15:05 |
DS-minetest |
(and for modders) |
| 15:05 |
rubenwardy |
modders are end users :P |
| 15:06 |
nore |
http://stackoverflow.com/questions/36414732/import-git-repo-with-signed-commits-into-launchpad btw |
| 15:06 |
rubenwardy |
yeah, that's where I got the link above |
| 15:06 |
nore |
heh, I just saw that |
| 15:07 |
nore |
who takes care of the ppa btw? |
| 15:09 |
kilbith |
it was est31 iirc |
| 15:09 |
nerzhul |
ppa is not managed by us in fact if i remember |
| 15:09 |
rubenwardy |
https://launchpad.net/~minetestdevs |
| 15:09 |
rubenwardy |
it is, nerzhul |
| 15:09 |
nerzhul |
i don't know dmoora and juhani, it seems only SN can handle it now |
| 15:09 |
nerzhul |
oh celeron55 is owner |
| 15:09 |
rubenwardy |
est31, ShadowNinja, PilzAdam, then a few over random people |
| 15:10 |
nerzhul |
PilzAdam was absent over 6 months, est31 left project, only remaining contact is ShadowNinja |
| 15:12 |
kilbith |
fuck launchpad, compile or die |
| 15:15 |
nerzhul |
launchpad pain :p |
| 15:19 |
Krock |
kilbith, congratulations. who's going to clean up this mess now? |
| 15:21 |
nerzhul |
Krock, add a mod maybe ? |
| 15:22 |
Krock |
nerzhul, requires an entry in the trusted mods to do os.remove("mt_player*") |
| 15:22 |
|
est31 joined #minetest-dev |
| 15:22 |
est31 |
hi |
| 15:22 |
Krock |
hello est31 |
| 15:23 |
red-NaN |
hello |
| 15:23 |
est31 |
kilbith has summoned me, due to launchpad issues with signed commits |
| 15:23 |
|
Tre left #minetest-dev |
| 15:24 |
kilbith |
so any solution(s) to propose? |
| 15:25 |
est31 |
launchpad has direct git to git imports |
| 15:25 |
est31 |
right now I'm trying to make one |
| 15:26 |
est31 |
https://bugs.launchpad.net/ubuntu/+source/bzr-git/+bug/1084403 |
| 15:27 |
nerzhul |
2012 and canonical doesn't care about its users |
| 15:28 |
nerzhul |
est31, could be nice :) thanks |
| 15:28 |
est31 |
np |
| 15:29 |
sfan5 |
hah good meme |
| 15:29 |
sfan5 |
i was CC'd on an email by OC in which he calls the coredevs "disposable" (quote!) |
| 15:30 |
nerzhul |
sfan5, it's really a reality show |
| 15:30 |
nerzhul |
i hope it's not celeron55 the producer :p |
| 15:31 |
sfan5 |
it's all just an elaborate plan to get a script for a finnish tv reality show |
| 15:31 |
est31 |
so here it is https://code.launchpad.net/~minetestdevs/minetest-c55/+git/upstream |
| 15:32 |
est31 |
now I only have to create one for _game |
| 15:32 |
|
calculon joined #minetest-dev |
| 15:32 |
est31 |
and then move the recipes over |
| 15:32 |
sfan5 |
does this mean update LP builds will start now? |
| 15:32 |
est31 |
not so far yet |
| 15:38 |
est31 |
arghh you cant mix bzr branches with git repos |
| 15:39 |
est31 |
seems I have to move the packaging bzr repo over to git ... |
| 16:05 |
est31 |
nice nice |
| 16:05 |
est31 |
its pretty easy to create new git repos on launchpad you just add a remote with the desired name and push |
| 16:06 |
est31 |
but of course you need to know that is possible xD |
| 16:11 |
est31 |
so, lets see |
| 16:11 |
est31 |
https://code.launchpad.net/~minetestdevs/+recipe/minetest-daily |
| 16:11 |
est31 |
builds started |
| 16:12 |
sfan5 |
nice |
| 16:13 |
sfan5 |
you might wanna edit the descriptions to remove the outdated references to "build", "common" and "survial" |
| 16:13 |
est31 |
done |
| 16:14 |
est31 |
yeah a little bit of cleanup is still required |
| 16:14 |
est31 |
like dropping support for precise |
| 16:15 |
sfan5 |
huh xenial failed for some reason |
| 16:15 |
sfan5 |
>0.4.4 |
| 16:15 |
sfan5 |
wat |
| 16:17 |
sfan5 |
est31: the version format of the new build doesn't seem to match what was used previously |
| 16:17 |
est31 |
yeah |
| 16:17 |
est31 |
seeing it too |
| 16:18 |
est31 |
lemme check |
| 16:20 |
|
rubenwardy joined #minetest-dev |
| 16:20 |
est31 |
yeah the format changed, I have changed it back to one that should work |
| 16:20 |
est31 |
now also includes the git commit id |
| 16:21 |
est31 |
better for bug reports from users using the ppa :) |
| 16:23 |
est31 |
its now like <time when the package was built>-0~<first 7 chars of git commit> |
| 16:25 |
est31 |
okay, sfan5, I guess its fine to remove precise (12.04) support now? |
| 16:25 |
est31 |
from the ppa at least |
| 16:25 |
sfan5 |
no longer LTS? |
| 16:26 |
sfan5 |
travis is still using it no? |
| 16:26 |
est31 |
LTS ends at april 28 |
| 16:26 |
sfan5 |
then not yet |
| 16:26 |
est31 |
so I should migrate it to git? |
| 16:26 |
sfan5 |
yeah |
| 16:27 |
est31 |
btw, it has nothing to do with travis |
| 16:28 |
est31 |
that's about whether to publish the package on launchpad ppa |
| 16:30 |
sfan5 |
i know |
| 16:30 |
sfan5 |
but it would be bad if travis was using a distro versions that is out-of-support |
| 16:31 |
est31 |
it will be in less than a week, at least by canonical |
| 16:32 |
est31 |
https://blog.travis-ci.com/2017-04-17-precise-EOL |
| 16:32 |
|
benrob0329 joined #minetest-dev |
| 16:35 |
* est31 |
shrugs |
| 16:35 |
est31 |
okay, the precise daily build should be migrated as well |
| 16:38 |
est31 |
also, you dont need precise for travis if you want to keep pre c++11 support, just add --std=C++03 or sth to the flags passed to gcc |
| 16:41 |
|
DS-minetest joined #minetest-dev |
| 16:41 |
|
cx384 joined #minetest-dev |
| 16:49 |
est31 |
okay the daily legacy build is updated as well |
| 16:50 |
est31 |
& works |
| 16:50 |
est31 |
https://code.launchpad.net/~minetestdevs/+recipe/minetest-daily-legacy |
| 16:51 |
|
benrob03291 joined #minetest-dev |
| 16:53 |
est31 |
sadly I cant delete the legacy bzr branches, as still some recipes by third party users depend on them |
| 16:54 |
cx384 |
thank you :D |
| 16:54 |
est31 |
okay, time to go. bye! |
| 16:54 |
|
est31 left #minetest-dev |
| 16:58 |
|
est31 joined #minetest-dev |
| 16:59 |
est31 |
oh, before I forget it, you may want to revert this commit, its not relevant any more: |
| 16:59 |
est31 |
https://github.com/minetest/minetest/commit/7a6502a7a5007e4bed8c1dd10af39d4fa2b296a4 |
| 16:59 |
|
est31 left #minetest-dev |
| 17:13 |
|
rubenwardy joined #minetest-dev |
| 17:20 |
|
Warr1024 joined #minetest-dev |
| 17:23 |
|
cx384 joined #minetest-dev |
| 17:28 |
|
Warr1024 joined #minetest-dev |
| 17:29 |
ShadowNinja |
Developer meeting in ~30m. Devs: see -staff for editable notes. |
| 17:34 |
nore |
^ I won't be able to attend it, or only slightly, sorry (I have to go to the airport) |
| 17:35 |
ShadowNinja |
nore: Alright, enjoy your flight / whoever you're meeting / whatever happens to be the case :-) |
| 17:36 |
nore |
hehe, going on a conference |
| 17:36 |
nore |
(my first paper published ever \o/) |
| 17:37 |
|
torgdor joined #minetest-dev |
| 17:37 |
ShadowNinja |
O_O cool. |
| 17:43 |
rubenwardy |
I'm not in -staff |
| 17:49 |
|
rubywarden joined #minetest-dev |
| 17:52 |
|
rubywarden joined #minetest-dev |
| 17:54 |
Krock |
ah. will be here this time |
| 17:54 |
|
YuGiOhJCJ joined #minetest-dev |
| 17:54 |
Krock |
thanks rubenwardy |
| 17:57 |
Hijiri |
#5612 |
| 17:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/5612 -- Allow overriding tool capabilities through itemstack metadata by raymoo |
| 18:01 |
ShadowNinja |
Welcome to the second edition of the Minetest weekly developer meeting. Here are the meeting notes for those that want to follow along: http://sprunge.us/PXJj |
| 18:02 |
ShadowNinja |
First, old business: |
| 18:02 |
ShadowNinja |
Two PRs were merged since the last meeting but some are still in progress. |
| 18:03 |
ShadowNinja |
nore: How are getTime and keybindings going? |
| 18:03 |
nore |
ShadowNinja: keybindings are ready, I think |
| 18:03 |
nore |
Sorry, gtg now |
| 18:04 |
ShadowNinja |
nore: Alright, see you later. |
| 18:05 |
sfan5 |
i have something to add about #4035, it definitely needs changes as some callbacks should be moved somewhere else |
| 18:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/4035 -- Additional hooks for inventory manipulations callbacks. by Foghrye4 |
| 18:05 |
ShadowNinja |
Additional hooks for inventory manipulations callbacks (#4035) was discussed last time, we agreed to merge in principle but it needs a rebase and cleanup. |
| 18:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/4035 -- Additional hooks for inventory manipulations callbacks. by Foghrye4 |
| 18:06 |
ShadowNinja |
Is there anyone that's willing to work on that? |
| 18:07 |
ShadowNinja |
(sfan5, rubenwardy, sfan5, sofar, Krock, celeron55) ping. |
| 18:08 |
sfan5 |
me not rn as i have limited time |
| 18:08 |
Krock |
can do that tomorrow |
| 18:08 |
Krock |
at least the rebase & conflict solving part |
| 18:09 |
ShadowNinja |
Krock: Alright, great :-) |
| 18:09 |
ShadowNinja |
Next: Rename .txt to .md (#5451) |
| 18:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/5451 -- Rename doc/*.txt to *.md. by ensonic |
| 18:10 |
Krock |
the comments don't look promising and I'm opposed to it anyway since it breaks the old links |
| 18:10 |
sfan5 |
^ agree |
| 18:10 |
rubenwardy |
I feel like it's worth leaving it |
| 18:10 |
ShadowNinja |
I can see how it could make things more difficult on windows, but I think it would make sense to just have the Windows build scripts create a .txt copy. |
| 18:11 |
ShadowNinja |
The other concern is breaking links, but I'm not too woried about that since they can be updated. |
| 18:12 |
rubenwardy |
links currently break already, pretty much |
| 18:12 |
rubenwardy |
ie: linking to a line breaks over time |
| 18:12 |
rubenwardy |
the main advantage of .md is that you can link to a section, although you then can't link to a bullet |
| 18:13 |
sfan5 |
can we switch to html |
| 18:13 |
ShadowNinja |
sfan5: Too verbose. md can be rendered to HTML though. |
| 18:14 |
sfan5 |
yeah i meant as an output format |
| 18:14 |
sfan5 |
not src |
| 18:14 |
ShadowNinja |
sfan5: md works fine for that then. |
| 18:15 |
ShadowNinja |
What do you think about changing the build scripts for Windows to use .txt and then merging? |
| 18:15 |
sfan5 |
sounds fine to me |
| 18:16 |
Krock |
breaking all links instantly instead of letting them to become outdated slowly? |
| 18:17 |
ShadowNinja |
Krock: Yes. If you're linking to a particular line they should be pinned to a commit anyways... |
| 18:18 |
Krock |
right, I'm ok with that |
| 18:19 |
rubenwardy |
If we can break it up into more subheadings, then linking would be fine |
| 18:20 |
rubenwardy |
We're going to need to split up lua_api.txt into multiple files anyway due to CSM |
| 18:20 |
rubenwardy |
ie: shared user date |
| 18:20 |
ShadowNinja |
We can add a dummy lua_api.txt that just Tells you to check lua_api.md to not break links. |
| 18:21 |
ShadowNinja |
I'll add a comment to the PR, but we better move on. |
| 18:22 |
ShadowNinja |
New business: Should we schedule a Minetest_game meeting? |
| 18:22 |
rubenwardy |
sure |
| 18:22 |
Krock |
if there are enough points there to discuss, sure. |
| 18:22 |
ShadowNinja |
Same time (1800Z) sunday should work for most people. |
| 18:24 |
ShadowNinja |
Alright, who would host it? |
| 18:25 |
ShadowNinja |
(sofar, I think you suggested it, would you do it?) |
| 18:26 |
|
rubywarden joined #minetest-dev |
| 18:26 |
ShadowNinja |
Lets' move on for now. sofar ran a Coverity scan and discovered a number of issues. These need triaging by people familiar with the engine and then fines need to be applied. |
| 18:27 |
ShadowNinja |
Devs: If you can help, request access to the project to see the issues and categorize them. |
| 18:27 |
sfan5 |
why do i need to login to look at the issues |
| 18:27 |
ShadowNinja |
sfan5: Presumably because they could represent security issues. |
| 18:27 |
ShadowNinja |
Here's the link: https://scan.coverity.com/projects/12441 |
| 18:27 |
sfan5 |
*rolls eyes* |
| 18:28 |
ShadowNinja |
Now to new PRs: |
| 18:28 |
ShadowNinja |
Timed move (#1489) Thoughts? |
| 18:28 |
ShadowBot |
https://github.com/minetest/minetest/issues/1489 -- Timed move by sapier |
| 18:28 |
sfan5 |
ShadowNinja: submitted request |
| 18:29 |
ShadowNinja |
sfan5: Approved. |
| 18:29 |
sfan5 |
about timed move: concept/idea is very useful, haven't looked at code |
| 18:31 |
ShadowNinja |
rubenwardy, Krock? |
| 18:31 |
sfan5 |
hm |
| 18:31 |
Krock |
it may help to make it look better on laggy servers but this only seems to be helpful for edge cases where the new velocity is known |
| 18:31 |
sfan5 |
is luaL_typerror a noreturn? |
| 18:32 |
sfan5 |
because it seems some coverity issues are false-positives |
| 18:32 |
Krock |
looking at mobs or carts - where the new velocity isn't pre-calculated (yet?) |
| 18:33 |
ShadowNinja |
sfan5: Yeah, definitely plenty of false positive. It longjmps is there's an error. |
| 18:33 |
sfan5 |
lua should mark their funcs with __attribute__((noreturn)) |
| 18:34 |
|
benrob0329 joined #minetest-dev |
| 18:34 |
ShadowNinja |
sfan5: There's a profile file you can upload to coverity to tell it about noreturn functions. |
| 18:34 |
|
Fixer joined #minetest-dev |
| 18:35 |
ShadowNinja |
Alright, I guess we don't have enough consensus. |
| 18:35 |
sfan5 |
ugh http://i.imgur.com/9NDpR0w.png |
| 18:37 |
ShadowNinja |
sfan5: Well it's not an AI, but it does find some good stuff. |
| 18:37 |
ShadowNinja |
Added formspec element 'KeyEventBox' for charbased input (#1737) Rebase and merge or close? |
| 18:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/1737 -- Added formspec element 'KeyEventBox' for charbased input by ninnghazad |
| 18:37 |
sfan5 |
yeah but most of these kinda scanners assume a location is being written to if you pass it as a char* to a function |
| 18:38 |
sfan5 |
about the pr: might be useful in a few cases but it's probably complicated, -1 |
| 18:39 |
rubenwardy |
I feel like a lot of the usecases would be better done with CSM (ie: terminals, instant search) |
| 18:39 |
ShadowNinja |
IMO it should be clientside. Having two roundtrips + a server step for each key press is going to be quite annoying. |
| 18:39 |
rubenwardy |
even if you end up sending the key codes yourself (ie: terminals) |
| 18:40 |
red-NaN |
ShadowNinja, you can escape client-sided chatcommands |
| 18:40 |
ShadowNinja |
red-NaN: Oh, O.K. |
| 18:41 |
sfan5 |
i don't get this |
| 18:41 |
sfan5 |
the code is working with only s16's |
| 18:41 |
ShadowNinja |
There are some approvals though, and the author has been supporting it, so I'll just add a comment. |
| 18:41 |
sfan5 |
then coverity comes along and complains that casting the result of the division to double (wat) makes no sense |
| 18:42 |
ShadowNinja |
Next: Add ability to escape commands with a back-slash (#1768) |
| 18:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/1768 -- Add ability to escape commands with a back-slash by ShadowNinja |
| 18:42 |
sfan5 |
-1 from me still |
| 18:43 |
ShadowNinja |
I'll tweak, rebase, and merge it if wanted. |
| 18:43 |
ShadowNinja |
sfan5: Why? |
| 18:43 |
sfan5 |
see pr comments |
| 18:44 |
ShadowNinja |
O.K. Anyone else? |
| 18:44 |
ShadowNinja |
Alright, I'll close it. |
| 18:45 |
ShadowNinja |
Next: Split block position in SQLite3 database (and use R*Tree) (#1845) |
| 18:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/1845 -- Split block position in SQLite3 database by ShadowNinja |
| 18:47 |
sfan5 |
will soon need a rebase, +1 for concept |
| 18:47 |
Krock |
easier to access with external tools. +1 here too |
| 18:48 |
celeron55 |
oh, this is happening; i was afk |
| 18:49 |
Krock |
well then, wb :) |
| 18:49 |
celeron55 |
i think ShadowNinja himself should look at the getTime PR as it uses some stuff made by ShadowNinja (?) and seems to get it totally wrong like placing u32 values in u64 variables |
| 18:50 |
ShadowNinja |
I'd probably just merge my version of the patch verbatim. :-) |
| 18:50 |
celeron55 |
the code quality seems so bad it doesn't even know what it's trying to do, i mean |
| 18:50 |
ShadowNinja |
I'll discuss it with nore later. |
| 18:50 |
celeron55 |
sounds good |
| 18:51 |
nore |
^ yeah, I must say that I just blindly rebased the PR, so maybe SN is more qualified than me to look at this code |
| 18:53 |
ShadowNinja |
celeron55: Any thoughts on the pos split? |
| 18:55 |
sfan5 |
ShadowNinja: you're correct coverity catches some nice thingy |
| 18:55 |
sfan5 |
e.g. the bug in getNodeNoCheck |
| 18:56 |
ShadowNinja |
sfan5: Two bugs even, that method is very broken. |
| 18:56 |
|
Fritigern joined #minetest-dev |
| 18:56 |
sfan5 |
oh is valid_position allowed to be NULL? |
| 18:56 |
celeron55 |
ShadowNinja: performance seems to be the issue with that PR; i think it needs new tests by Rogier-5 if possible |
| 18:57 |
ShadowNinja |
sfan5: Could you add your +1 in the PR? |
| 18:57 |
sfan5 |
done |
| 18:57 |
celeron55 |
the numbers he gets with minetestmapper seem awful |
| 18:58 |
ShadowNinja |
celeron55: Yeah, a lot has changed. I know some types of queries will be much faster, but the stuff that Minetest does probably won't (but Minetest only works with one block at a time, so block write performance is a bit less critical). |
| 18:59 |
ShadowNinja |
In particular the mapper should be much faster, since it loads entire ranges of blocks at once. |
| 18:59 |
|
kaeza joined #minetest-dev |
| 19:00 |
ShadowNinja |
Well, lets move on I guess until there's better perf info for that. |
| 19:00 |
ShadowNinja |
Use a settings object for the main settings (#1949) | I also unified Initialize and InitiallizeAsync, which was necessary to implement this. I think the unification is worth merging even without the settings object change. This conflicts with just about the entire ScriptAPI, so I don't want to rebase it too often :-) |
| 19:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/1949 -- Use a settings object for the main settings by ShadowNinja |
| 19:05 |
ShadowNinja |
sfan5, celeron55, Krock? |
| 19:05 |
sfan5 |
idk |
| 19:05 |
Krock |
looking through the code |
| 19:06 |
Krock |
grouping the functions is a good idea, +1 for that |
| 19:07 |
celeron55 |
1949 seems fine, i guess it's been forgotten for no reason |
| 19:07 |
celeron55 |
it shouldn't spit out a warning for every setting.get though |
| 19:08 |
celeron55 |
that's going to flood out logs like nothing else |
| 19:08 |
celeron55 |
setting_get i mean |
| 19:08 |
celeron55 |
(and _getbool) |
| 19:11 |
Krock |
but some calls may occur in the "deep gameplay" |
| 19:12 |
ShadowNinja |
celeron55: "deprecated" is a special log level which isn't printed by default. There's a setting in minetest.conf to make it print or print with traceback. |
| 19:12 |
Krock |
only throwing a warning on-load wouldn't be helpful for that situation |
| 19:13 |
celeron55 |
ShadowNinja: if it is, then whatever; just add docs to it (i don't see lua_api.txt or anything like that in the file list) |
| 19:13 |
ShadowNinja |
celeron55: Hmmm, I though I did that, noted. |
| 19:14 |
ShadowNinja |
sfan5: Anything before we move on? |
| 19:15 |
|
Warr1024 joined #minetest-dev |
| 19:15 |
ShadowNinja |
Next: Add listpredict to the formspec (#1988) |
| 19:16 |
ShadowBot |
https://github.com/minetest/minetest/issues/1988 -- Fix #1374 by adding a listpredict piece to the formspec by MinerDad7 |
| 19:18 |
sfan5 |
what is this needed for |
| 19:19 |
VanessaE |
actually I do have something to say, since I came in late.... don't split the damn lua_api.txt. It's already hard enough to search if you don't know what you're looking for (precisely), splitting it up will just make that worse. |
| 19:19 |
sfan5 |
yes i'm against splitting it |
| 19:19 |
sfan5 |
too |
| 19:20 |
VanessaE |
if you're worried about CSM cluttering it, make a new file for that. |
| 19:20 |
sofar |
csm already is in its own file |
| 19:21 |
VanessaE |
ok then it's all good. |
| 19:21 |
ShadowNinja |
VanessaE: Yeah, we haven't discussed that, just .txt -> .md rename. |
| 19:22 |
VanessaE |
ruben mentioned it. |
| 19:22 |
ShadowNinja |
sofar made a rebased version (of list_predict) so I'd like him to take a second look at it, he probably knows more about it than any of us. |
| 19:22 |
ShadowNinja |
Last thing: Add non-global mod namespaces (#2039) |
| 19:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/2039 -- Add non-global mod namespaces by ShadowNinja |
| 19:23 |
sfan5 |
so i've looked at about half of the coverity issues |
| 19:23 |
sofar |
I wasn't convinced it actually worked btw |
| 19:24 |
|
benrob03291 joined #minetest-dev |
| 19:24 |
VanessaE |
ShadowNinja: thumbs down |
| 19:24 |
sfan5 |
":-1: Unnecessarily complicated" (quote of my gh comment) |
| 19:24 |
VanessaE |
as a modder that just looks like it'll make more work for me. |
| 19:26 |
|
Warr1024 joined #minetest-dev |
| 19:26 |
ShadowNinja |
VanessaE: It's backwards compatible, just a better way to do things in the future. |
| 19:26 |
sfan5 |
nobody mentioned compatiblity |
| 19:26 |
sfan5 |
also "better" is subjective |
| 19:27 |
|
Warr1024 joined #minetest-dev |
| 19:27 |
ShadowNinja |
sfan5: If you exclude docs and style fixes it's only about 20 lines. |
| 19:28 |
sfan5 |
so? |
| 19:28 |
celeron55 |
the only improvement it does in practice is that a mod's existence can be checked from minetest.mods[name]? (and this even for old mods?) |
| 19:29 |
sfan5 |
i think so yes |
| 19:29 |
celeron55 |
are there any downsides in checking mods the current way? |
| 19:29 |
Krock |
this brings a structure into modding but for some modders it might be annoying to localize the specific table value in each file for easier access |
| 19:30 |
VanessaE |
celeron55: well reading from a table is faster than calling a function, but any modder worth his or her salt minimizes such checks anyway |
| 19:30 |
celeron55 |
(and how often is it even done to begin with?) |
| 19:31 |
sfan5 |
once on startup hopefully |
| 19:31 |
VanessaE |
in theory yes. |
| 19:31 |
ShadowNinja |
celeron55: It reduces the number of globals and organizes mod APIs. It also encourages localization of and external APIs that are used (which saves a global lookup). |
| 19:31 |
celeron55 |
i don't think this is needed, unless modders are asked and many of them say they want it |
| 19:31 |
VanessaE |
typically if I do it exactly once somewhere, if minetest.get_modpath() then... but if I do the same check more than once, assign it to a variable at the start of my code. simple. |
| 19:31 |
sofar |
luacheck helps modders more imho |
| 19:33 |
ShadowNinja |
Alright, I'll close then. |
| 19:33 |
ShadowNinja |
Anything else to discuss? |
| 19:33 |
sfan5 |
don't think so |
| 19:34 |
Krock |
well, I'd have one: what's going to happen with #5268 ? |
| 19:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/5268 -- Send only changed node metadata to clients instead of whole mapblock by SmallJoker |
| 19:34 |
Krock |
was rebased now three times and still no decision |
| 19:34 |
celeron55 |
(throwing 2039 on #-hub and asking what people think of it might be a good idea? no? well whatever) |
| 19:35 |
Krock |
The question is, if the performance gain is significant enough for the amount of changes |
| 19:36 |
VanessaE |
some have made claims that it's helpful with complex, automation-laden spawns like VE-Survival. |
| 19:37 |
VanessaE |
I can't say definitively that it helps on my machine, in retrospect. |
| 19:37 |
VanessaE |
one thing that might be more helpful there is if the server would just not bother to send any metadata to the client that it can't use, if that's not already the case. |
| 19:38 |
sfan5 |
how do you determine "that it can't use"? |
| 19:38 |
VanessaE |
sfan5: well, does the client need to know that a cable at X Y Z has 45 EU of power going through it? :) |
| 19:38 |
celeron55 |
currently we know, except soon we won't due to CSM |
| 19:39 |
VanessaE |
it might be a situation where the modder has to explicitly tell the server what the client needs and what not. |
| 19:39 |
sfan5 |
well a formspec could require this |
| 19:39 |
Krock |
VanessaE, we can't know what's going to be implemented in the future, using the metadata |
| 19:39 |
sfan5 |
but having serverside-only meta might be useful |
| 19:39 |
VanessaE |
sfan5: that's what I'm thinking |
| 19:39 |
celeron55 |
we really need a way to mark which metadata should be sent to the client and which should not |
| 19:40 |
VanessaE |
of all the things I've either dealt with or written that used metadata, I don't think a single byte of it would have been useful to a client, formspecs and infotext aside |
| 19:40 |
sfan5 |
with CSM this will also be needed if you want to store anything "sensetive" in meta |
| 19:41 |
celeron55 |
anyway the concept of 5268 is fine |
| 19:42 |
VanessaE |
seems the smart thing to do is mark everything not part of a formspec or infotext as server-side now |
| 19:42 |
VanessaE |
and make the-client-needs-it a special call or flag or something |
| 19:42 |
sfan5 |
you're breaking backwards compat! |
| 19:43 |
sfan5 |
also formspecs can have stuff like ${foobar} in them to fetch meta keys when the formspec is opened |
| 19:43 |
Krock |
any value can be used there, which can't be prediced to prevent sending that metadata |
| 19:44 |
VanessaE |
well my point was to only mark stuff as send-to-client that clients already routinely display, and nothing else |
| 19:44 |
VanessaE |
them modders can fix what they need to, if at all |
| 19:44 |
VanessaE |
Krock: universally those two things are still called formspec and infotext, are they not? has anyone ever called them anything else? |
| 19:45 |
VanessaE |
then* |
| 19:46 |
celeron55 |
i would guess (hope) nobody actually uses the ${foobar} functionality :P |
| 19:46 |
Krock |
I'm looking for a mod that uses it.. hmm |
| 19:47 |
VanessaE |
I'm checking my tree also |
| 19:47 |
Krock |
the landrush sign: meta:set_string("formspec", "field[text;;${text}]") |
| 19:48 |
Krock |
circular saw: "field[0.3,3.5;1,1;max_offered;" ..S("Max").. ":;${max_offered}]" .. |
| 19:48 |
VanessaE |
Krock: what regex are you using to search? |
| 19:48 |
Krock |
just "${" on all .lua files |
| 19:48 |
Krock |
since that's not a valid Lua expression |
| 19:49 |
VanessaE |
nothing shows up in my search. |
| 19:49 |
sfan5 |
try grep -F |
| 19:49 |
Krock |
found in 18 files out of 998 |
| 19:49 |
VanessaE |
nada, out of 2200 files |
| 19:50 |
kaeza |
I think I've seen that used in technic |
| 19:51 |
Krock |
that can't be. There are also some in pipeworks |
| 19:51 |
kaeza |
in the recent digilinize all the things commits |
| 19:51 |
VanessaE |
must be doinbg the search wrong. |
| 19:51 |
VanessaE |
-b |
| 19:52 |
VanessaE |
ok, lots of matches when I do it right. |
| 19:53 |
VanessaE |
84 matches out of 1854 in games, 1124 matches out of 2289 in mods :-/ |
| 19:53 |
Krock |
wow, that's quite much |
| 19:54 |
VanessaE |
so mark all metadata as server-side only unless it's a formspec, infotext, or any thing using ${}, then |
| 19:55 |
sfan5 |
that still breaks backwards compat |
| 19:55 |
sfan5 |
wait or does it |
| 19:55 |
VanessaE |
why would it? |
| 19:55 |
VanessaE |
the engine already has to parse the string anyway |
| 19:55 |
ShadowNinja |
VanessaE: 50% of mods? That sounds high. Is that by file, line or mod? |
| 19:55 |
VanessaE |
let it decide then and there "ok, client needs this" (or doesn't) |
| 19:55 |
sfan5 |
the engine yes |
| 19:55 |
sfan5 |
but not server-side |
| 19:56 |
VanessaE |
that was by-file, ShadowNinja. |
| 19:56 |
sfan5 |
this would be quite some overhead |
| 19:56 |
VanessaE |
sfan5: hrm. well shit |
| 19:58 |
red-NaN |
meta as in node meta? |
| 19:58 |
VanessaE |
a little overhead during server startup is a small price to pay to be nice to clients and not break backward-compat |
| 19:58 |
VanessaE |
red-NaN: yes, basically |
| 19:58 |
Krock |
node meta, yes. |
| 19:59 |
kaeza |
I guess it also does not cope with plural forms does it? |
| 19:59 |
kaeza |
bah, wrong chan |
| 20:00 |
sfan5 |
VanessaE: sadly it's not during startup, every node has it's own potentially difference infotest + formspec |
| 20:00 |
sfan5 |
every node = every node at different positions in the map |
| 20:00 |
VanessaE |
well fuck. |
| 20:01 |
red-NaN |
aren't node formspecs set on a pre-node bases? |
| 20:01 |
Krock |
local server_meta = minetest.get_server_meta(pos), with the same functions as get_meta |
| 20:01 |
VanessaE |
well, which would involve more work for mod authors? fixing backward-compat? or restricting stuff from clients? |
| 20:02 |
sfan5 |
fixing compat would be lots of overhead + work for mod authors + unflexible solution |
| 20:02 |
red-NaN |
what sort of info do you even want to store in node meta? |
| 20:02 |
sfan5 |
latter would be work for mod authors |
| 20:02 |
sfan5 |
i think it's clear which way should be taken |
| 20:02 |
VanessaE |
sfan5: nono |
| 20:02 |
Krock |
red-NaN, cookie hashes and passwords |
| 20:03 |
red-NaN |
just hash the password with a server-sided salt? |
| 20:03 |
VanessaE |
sfan5: I mean more work for the modder: if the engine breaks backwards compat and ignores the use of ${} and the modder has to fix his or her mods to compensate? or if the engine stays the way it is and the modder has to fix his or her mod to restrict stuff being sent to the client? |
| 20:04 |
VanessaE |
s/engine/server engine/g |
| 20:04 |
sfan5 |
that's pretty much equal work |
| 20:05 |
VanessaE |
red-NaN: there's more than passwords that might be considered sensitive, though I can't think of anything right now. |
| 20:05 |
red-NaN |
just generate the hash on the first server startup and store it in mod storage |
| 20:05 |
VanessaE |
sfan5: in terms of the actual change, probably - but how many man-hours would be spent, aggregated across all of the mods out there so-affected? |
| 20:05 |
sfan5 |
it's not only sensetive stuff, the main point is avoiding resends of stuff the client won't need anyway |
| 20:06 |
sfan5 |
VanessaE: dunno but IMO it is preferred to have "work on your mod to use this new small nice feature" than "you need to work on your mod otherwise it's broken" |
| 20:06 |
VanessaE |
the search results I came up with would suggest it's more work to restrict the data than to forward it after a compat break (and for games, clearly the opposite) |
| 20:07 |
VanessaE |
but only just barely. |
| 20:07 |
|
Warr1024 joined #minetest-dev |
| 20:08 |
red-NaN |
well requiring modders to manually mark thier data as server-only wouldn't help much with the resend issue |
| 20:08 |
VanessaE |
but I tend to side with you as far as what's more preferable in general |
| 20:08 |
red-NaN |
most wouldn't bother |
| 20:08 |
VanessaE |
red-NaN: no, it wouldn't help, except in the case of something like technic or pipeworks, where 99% of the meta used with those is of no interest to clients. |
| 20:08 |
sfan5 |
red-NaN: it would because i'm guessing that it's mostly a small number of mods like pipeworks or technic that need this fix |
| 20:09 |
sfan5 |
the amount of modders that need to get involved is very different (lower) |
| 20:09 |
VanessaE |
ninja'd :) |
| 20:09 |
sfan5 |
indeed |
| 20:09 |
VanessaE |
ok then I concede. send all meta by default, restrict it where appropriate. |
| 20:10 |
VanessaE |
[04-22 16:01] <Krock> local server_meta = minetest.get_server_meta(pos), with the same functions as get_meta <--- makes sense. |
| 20:10 |
Krock |
just an idea. to have the same methods but the stuff isn't sent to the clients (handled differently) |
| 20:11 |
sfan5 |
i'd prefer having minetest.mark_meta_as_serverside(pos, {"password", "eu_level"}) |
| 20:11 |
sfan5 |
[maybe not that exact api though] |
| 20:12 |
Krock |
rather mymeta:mark_serverside({ fields }) :) |
| 20:12 |
Krock |
but that's also a good idea |
| 20:12 |
VanessaE |
that's probably better |
| 20:13 |
sfan5 |
yeah |
| 20:15 |
VanessaE |
any chance such a thing can make it in before freeze>? |
| 20:15 |
sfan5 |
likely not |
| 20:16 |
sfan5 |
but as its server-side only nothing prevents you from running a patched version |
| 20:16 |
VanessaE |
well I'm just thinking in terms of "ok, you need 0.4.16 for this to work" instead of the usual "get a dev build from Foovember 39th or later" |
| 20:18 |
sfan5 |
actually it depends on how simple it turns out to be |
| 20:22 |
|
torgdor joined #minetest-dev |
| 20:24 |
VanessaE |
who knows, someone might code it in response to this discussion :) |
| 20:35 |
|
Warr1024 joined #minetest-dev |
| 20:42 |
|
rubenwardy joined #minetest-dev |
| 20:48 |
|
juhdanad joined #minetest-dev |
| 20:51 |
|
proller joined #minetest-dev |
| 20:58 |
ShadowNinja |
"core.setting_getbool("instrument.chatcommand") or true" ummm... |
| 21:05 |
celeron55 |
lol |
| 21:07 |
|
Fritigern joined #minetest-dev |
| 21:08 |
|
benrob0329 joined #minetest-dev |
| 21:23 |
|
troller joined #minetest-dev |
| 21:27 |
|
electrodude512 joined #minetest-dev |
| 21:35 |
|
^v joined #minetest-dev |
| 21:45 |
|
paramat joined #minetest-dev |
| 21:45 |
paramat |
oops slept through meeting :] |
| 21:49 |
|
benrob0329 joined #minetest-dev |
| 22:36 |
|
halt_ joined #minetest-dev |
| 22:39 |
Fixer |
crash o_O |
| 22:40 |
paramat |
? |
| 22:41 |
Fixer |
minetest crash, interesting |
| 22:42 |
paramat |
which commit you on? |
| 22:42 |
Fixer |
4c03190 |
| 22:42 |
paramat |
ok not my fault then |
| 22:43 |
paramat |
hopefully |
| 22:43 |
|
halt_ joined #minetest-dev |
| 22:43 |
Fixer |
crash occured while i was on mp server, i tried to Press T chat key, pressed some keys like x c v before that |
| 22:43 |
Fixer |
and it crashed |
| 22:44 |
|
benrob0329 joined #minetest-dev |
| 22:46 |
Fixer |
minetest.exe / msvcrt.dll / 0xc0000005 |
| 22:47 |
Fixer |
also zoom |
| 22:52 |
rubenwardy |
try restarting your PC |
| 22:53 |
|
Fixer_ joined #minetest-dev |
| 22:53 |
rubenwardy |
I found that restarting fixed 0xc0000005 |
| 22:55 |
Fixer_ |
0xc0000005 is segfault iirc |
| 22:56 |
rubenwardy |
Are you able to run a debug build? |
| 22:56 |
rubenwardy |
/ attach a debugger |
| 22:58 |
Fixer_ |
yeah |
| 22:58 |
Fixer_ |
need to build a debug version |
| 22:58 |
Fixer_ |
can't reproduce |
| 23:00 |
red-NaN |
I used to get ranndom crashes like that in an older version of mt |
| 23:01 |
Fixer_ |
0xc0000005 is ultra rare for me |
| 23:04 |
|
benrob03291 joined #minetest-dev |
| 23:12 |
|
Fixer joined #minetest-dev |
| 23:30 |
|
QwertyDragon joined #minetest-dev |
| 23:35 |
electrodude512 |
rubenwardy: I didn't realize that CSM was now implemented until you just said so on the KeyEventBox PR |
| 23:36 |
electrodude512 |
I'm reading doc/client_lua_api.md now |
| 23:38 |
electrodude512 |
Instead of transferring mods to the client, why don't you just have a server-side lua function(player, code_as_string) that sends some code to a player's client and has the client run it? |
| 23:38 |
red-NaN |
thats a horrible idea |
| 23:39 |
electrodude512 |
Why? Because it can be abused, or what? |
| 23:39 |
electrodude512 |
It'd just be a remote dofile |
| 23:39 |
red-NaN |
plus it basicly gets rid of the only reason for it to exist |
| 23:40 |
electrodude512 |
I suppose I have an unusual use case, then. (computer mod - run computers on clients for less lag) |
| 23:40 |
red-NaN |
huh |
| 23:41 |
red-NaN |
it still has loadstring |
| 23:41 |
electrodude512 |
Can you give me an example of what CSM was intended for? |
| 23:41 |
rubenwardy |
visual things |
| 23:42 |
rubenwardy |
and client side prediction |
| 23:42 |
red-NaN |
more advance audio |
| 23:42 |
red-NaN |
particle stuff |
| 23:42 |
rubenwardy |
*audiovisual |
| 23:42 |
red-NaN |
and some user installed mods UI |
| 23:42 |
electrodude512 |
ok |
| 23:42 |
red-NaN |
e.g. improved chat |
| 23:43 |
electrodude512 |
Like tab completion and help and such? |
| 23:43 |
rubenwardy |
you must remember that the any code that a client runs can be tamptered with, so to reduce the ability to cheat you should only use CSM for UI/GUI stuff, audiovisual improvements, and client side prediction (ie: predicting where carts will move if the server is lagging, to stop derailing) |
| 23:43 |
red-NaN |
anyway you could implement your usecase with a local formspec and loadstring |
| 23:44 |
|
benrob0329 joined #minetest-dev |
| 23:44 |
rubenwardy |
so: terminals, canvas drawing on formspecs, ambient sounds |
| 23:44 |
red-NaN |
yeah there is a PR for tab completion |
| 23:44 |
|
tiwake left #minetest-dev |
| 23:44 |
electrodude512 |
ok |
| 23:48 |
electrodude512 |
I want to make a client-side computer item that has something like a client-side version of ninnghazad's KeyEventBox. It will run on the client of the player holding it, and will be able to communicate with server-side digiline networks via a wireless digiline modem. |
| 23:49 |
red-NaN |
is KeyEventBox a formspec element? |
| 23:49 |
electrodude512 |
It isn't now, but ninnghazad wants it to be one. |
| 23:50 |
electrodude512 |
https://github.com/minetest/minetest/pull/1737 |
| 23:52 |
electrodude512 |
#1737 |
| 23:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/1737 -- Added formspec element 'KeyEventBox' for charbased input by ninnghazad |
| 23:54 |
electrodude512 |
OK, I'm going to go read the CSM docs and mess around with it. Thanks. |
| 23:56 |
|
halt_ joined #minetest-dev |
| 23:56 |
|
Megaf joined #minetest-dev |
