Time |
Nick |
Message |
00:00 |
specing |
I prefer TechPack |
00:01 |
Gustavo6046 |
? |
00:01 |
Gustavo6046 |
iamweasel: ah |
00:01 |
Gustavo6046 |
specing: don't let Vanny know |
00:01 |
Gustavo6046 |
:P |
00:02 |
Gustavo6046 |
There were those wide plains of sand and silver sand mixed. But there was no desert sand or desert stone, nor were there cacti. They were not deserts? |
00:03 |
specing |
I think she suspects from my bug reports |
00:04 |
Gustavo6046 |
lol |
00:05 |
Gustavo6046 |
if I have the guts to learn Minetest's Lua API (not the first time I mention that condition), I will fork it and makeitgood :D |
00:05 |
Gustavo6046 |
Disregard the very obscure Re-Volt reference, but still |
00:08 |
specing |
I did just that |
00:10 |
|
dax joined #minetest |
00:13 |
Gustavo6046 |
:o ? |
00:14 |
Gustavo6046 |
I want to know that |
00:38 |
Hawk777 |
I was wondering, I know there has been some talk about moving away from Minetest Game being considered “the default”. At this point, my distro package manager provides Minetest but not MTG. However, MTG is also not available for download from contentdb, with the comment “Because minetest game is currently distributed with the client, and so we don't want users to download it”. Is it intended that MTG should be shipped alon |
00:38 |
Hawk777 |
h MT still, or is it intended to be “just another game”? If the former, it seems it ought to be in a distro package. If the latter, it seems it ought to be in contentdb. |
00:38 |
Hawk777 |
Of course I can grab it from git, but it seems like this situation is missing some pieces. |
00:40 |
Hawk777 |
This is not meant as an accusation of anything missing at the devs—merely a question of which packaging method is *intended* to be used. |
00:56 |
|
illwieckz joined #minetest |
01:11 |
iamweasel |
i would double-check you distro does not have mtg in repo, and then just git or dowload tarball matching your engine version |
01:11 |
iamweasel |
what distro is it, i am curious? |
01:16 |
specing |
Gustavo6046: https://framagit.org/specing/minetest + https://framagit.org/specing/csm enjoy |
01:17 |
Gustavo6046 |
specing: ooh |
01:17 |
Gustavo6046 |
wait, is it a native mod? |
01:18 |
Gustavo6046 |
like does it require your fork of minetest? |
01:18 |
Gustavo6046 |
I was referring to forking pipeworks |
01:19 |
specing |
Yes, it requires my engine |
01:19 |
specing |
it's a collection of CSMs |
01:19 |
Gustavo6046 |
Ah |
01:19 |
Gustavo6046 |
Meh |
01:20 |
Gustavo6046 |
Interesting! |
04:01 |
|
Taoki joined #minetest |
04:06 |
|
Hawk777 joined #minetest |
04:09 |
Gustavo6046 |
If an ore cluster spawns partially into a bunch of gravel, is it possible for the parts that try to spawn into it to wind up spawning in the other side? |
04:09 |
Gustavo6046 |
Like the first stone in a breadth-first floodfill |
04:16 |
Sokomine |
Gustavo6046: yes, exactly, dms do fire fireballs. i think it's a misbehaviour. mobs ought to be friendly towards players :-) (even if we invade their territory and steal their property) |
04:17 |
Gustavo6046 |
Ah |
04:17 |
Gustavo6046 |
lol :P |
04:48 |
|
YuGiOhJCJ joined #minetest |
05:00 |
|
MTDiscord joined #minetest |
06:11 |
|
FeXoR joined #minetest |
06:12 |
iamweasel |
Sokomine: i was looking for a mod that has the magic wand or whatnot to fire the same fireballs, but couldn't find one :) |
06:12 |
iamweasel |
must be a 3-liner |
06:14 |
iamweasel |
yeah, how about that? like a wand and and expensive catalyst, non-stackable, to fire a dm fireball? |
06:14 |
iamweasel |
ten+1 implemented burbon just cuz i whined, i think if i submit a pull request, it's a slam dunk :D |
06:22 |
|
fluxflux_ joined #minetest |
06:38 |
|
TLuna joined #minetest |
06:51 |
|
appguru joined #minetest |
07:00 |
|
aheinecke joined #minetest |
07:06 |
|
Flabb joined #minetest |
07:12 |
|
aheinecke joined #minetest |
07:16 |
|
lisac joined #minetest |
08:00 |
|
ShadowNinja joined #minetest |
08:02 |
|
mizux joined #minetest |
08:03 |
|
Peppy joined #minetest |
08:14 |
|
zughy[m] joined #minetest |
08:15 |
|
antoine62[m] joined #minetest |
08:16 |
|
Sires joined #minetest |
08:17 |
|
Quiark joined #minetest |
08:22 |
|
heavygale joined #minetest |
08:22 |
|
scr267 joined #minetest |
08:22 |
|
perrier joined #minetest |
08:22 |
|
dabbill joined #minetest |
08:22 |
|
TC01 joined #minetest |
08:22 |
|
alket joined #minetest |
08:22 |
|
Shara joined #minetest |
08:22 |
|
cheapie joined #minetest |
08:22 |
|
Kray joined #minetest |
08:22 |
|
MinetestBot joined #minetest |
08:22 |
|
VadtecWk joined #minetest |
08:55 |
|
calcul0n joined #minetest |
09:11 |
|
hecks joined #minetest |
09:17 |
|
Pest joined #minetest |
09:21 |
|
GreenXenith joined #minetest |
09:46 |
|
Pest|2 joined #minetest |
09:47 |
|
TLuna joined #minetest |
09:56 |
|
daiNoZord joined #minetest |
10:16 |
daiNoZord |
find_node_near seems to behave until it finds first instance of specified node, rtn pos of found node. but then returns pos every time placed.... i've found a couple of examples but cant quite get it to work |
10:18 |
sfan5 |
you can exclude the center position from the search if you need to |
10:18 |
|
Pest joined #minetest |
10:19 |
daiNoZord |
am i right in thinking that it's pos, radius, node name? |
10:20 |
|
Pie-jacker875 joined #minetest |
10:21 |
|
proller joined #minetest |
10:24 |
daiNoZord |
it gets upset if i take away its arguments |
10:27 |
sfan5 |
!api |
10:27 |
MinetestBot |
Someone thinks you should read the API docs, please go to: https://github.com/minetest/minetest/blob/master/doc/lua_api.txt |
10:27 |
sfan5 |
pos, radius, node names yes |
10:27 |
|
unclouded joined #minetest |
10:27 |
sfan5 |
and as an optional fourth argument you can tell it not to search the center position |
10:27 |
daiNoZord |
ok thanks |
10:34 |
daiNoZord |
false by default |
10:35 |
sfan5 |
oh indeed |
10:37 |
daiNoZord |
i was reading a conversation a while ago that must have predated the option to enable |
10:46 |
|
Fixer joined #minetest |
10:48 |
|
Pest|2 joined #minetest |
10:57 |
|
aheinecke joined #minetest |
12:02 |
|
proller joined #minetest |
12:03 |
|
erlehmann joined #minetest |
12:20 |
|
riff-IRC joined #minetest |
12:36 |
|
daiNoZord joined #minetest |
12:55 |
|
nore joined #minetest |
12:55 |
|
Peppy joined #minetest |
13:07 |
|
riff-IRC joined #minetest |
13:15 |
|
TLuna joined #minetest |
13:18 |
|
turtleman joined #minetest |
13:22 |
|
craigger joined #minetest |
13:26 |
|
Lukwe joined #minetest |
13:36 |
|
Someguy123 joined #minetest |
13:46 |
|
NetherEran joined #minetest |
13:53 |
Calinou |
More Blocks 2.1.0 released: https://github.com/minetest-mods/moreblocks/releases/tag/v2.1.0 |
13:53 |
|
kamdard joined #minetest |
13:54 |
rubenwardy |
and ContentDB is broke |
13:56 |
Calinou |
it seems ContentDB is trying to do automatic import |
13:56 |
Calinou |
not sure if it'll work |
13:56 |
|
olliy joined #minetest |
13:57 |
Calinou |
yeah, it's not working: "fatal: update_ref failed for ref 'HEAD': cannot update ref 'refs/heads/master" |
13:57 |
|
SwissalpS joined #minetest |
13:57 |
Calinou |
how do I manually configure a release once it was created automatically? |
13:57 |
Calinou |
do I have to create a new one? |
13:57 |
Calinou |
or delete the previous ne |
13:58 |
Calinou |
yeah, I removed the old one and created a new one |
13:58 |
Calinou |
it's still failing to fetch it though |
14:00 |
tango_ |
woohoo |
14:04 |
rubenwardy |
I think it's the same bug as this: https://github.com/minetest/contentdb/issues/249 |
14:04 |
rubenwardy |
The Git stuff in ContentDB is easily the most unreliable part |
14:09 |
|
Taoki joined #minetest |
14:19 |
|
TLuna joined #minetest |
14:27 |
daiNoZord |
if somebody doesn't ban me soon, I can't promise I won't ask another question...! |
14:27 |
daiNoZord |
unless i go and learn latin instead. I might find that easier |
14:28 |
|
daiNoZord left #minetest |
14:42 |
|
est31 joined #minetest |
15:38 |
MTDiscord |
<appguru> what? |
15:40 |
rubenwardy |
unless i go and learn latin instead. I might find that easier |
15:45 |
Helenah |
VanessaE: Is HDX texture pack out of date? |
15:45 |
Helenah |
It seems to have textures in there which I assume are incorrectly named. |
15:52 |
VanessaE |
it needs some updates |
15:52 |
VanessaE |
kinda outdated now yeah |
15:59 |
|
absurb joined #minetest |
15:59 |
|
MadScientist joined #minetest |
16:05 |
|
milkt joined #minetest |
16:18 |
|
Hawk777 joined #minetest |
16:23 |
|
MDude joined #minetest |
16:31 |
|
fluxflux_ joined #minetest |
16:33 |
|
dabbill joined #minetest |
16:34 |
|
est31 joined #minetest |
16:35 |
Helenah |
VanessaE: I'm assuming I just need to simply rename some of the files. |
16:35 |
Helenah |
I can see there are textures available which aren't being applied, while other available textures are being applied. |
16:36 |
|
est31 joined #minetest |
16:36 |
VanessaE |
yeah, that's all that would be needed |
16:36 |
VanessaE |
pull requests welcome btw |
16:37 |
VanessaE |
I don't know what all has changed since I don't have much opportunity to use HDX anyway |
16:37 |
VanessaE |
(MT doesn't run well on my machine, never has, and HDX just kills what little FPS I do have) |
16:43 |
Helenah |
Ah :3 |
16:47 |
tango_ |
rubenwardy: rememebr when you suggested that a PR to improve placement could be considered maintenance and I was skeptical? |
16:48 |
tango_ |
I should have bet money ;-) https://github.com/minetest/minetest_game/pull/2797 |
16:48 |
tango_ |
and this is the simple one |
16:48 |
tango_ |
no way I'm going to submit the moreblock enhancement while paramat is around |
16:53 |
VanessaE |
fire him :P |
16:55 |
tango_ |
eh 8-) |
16:55 |
tango_ |
VanessaE: I'm just going with a friendly fork with that stuff |
16:55 |
VanessaE |
you'll be playing into his hands |
16:56 |
VanessaE |
sorry to be bitter here, but the whole point of closing off future feature dev in mtg was to encourage forks |
16:56 |
VanessaE |
which I disagree with intensely. |
16:56 |
tango_ |
me too |
16:56 |
tango_ |
but we could do a single fork 8-) |
16:57 |
sfan5 |
I actually planned to do that but haven't come around to it |
16:58 |
tango_ |
sfan5: do the fork? |
16:58 |
sfan5 |
yes |
16:59 |
tango_ |
I'm more than happy with somebody else taking over |
16:59 |
VanessaE |
every time someone's tried to fork MT or mtg it's always ended up as a dead project. |
16:59 |
tango_ |
my intention was to keep it friendly, not a full fork |
16:59 |
VanessaE |
(well apart from some android forks which seem to persist) |
16:59 |
tango_ |
so kept in sync with the maintenance of the “official” mtg |
16:59 |
sfan5 |
VanessaE: *or* merged into MTG |
16:59 |
tango_ |
VanessaE: OTOH, the mtg we have now was a fork once |
17:00 |
tango_ |
from the last time this BS happened |
17:00 |
VanessaE |
fair point, both |
17:00 |
VanessaE |
but now paramat has closed that avenue, sfan5 |
17:00 |
tango_ |
at least for now |
17:00 |
tango_ |
this is why I think it's important to stick to ONE friendly fork |
17:01 |
tango_ |
it imports maintenance fixes from the frozen MTG, but provides room for improvements |
17:01 |
VanessaE |
maybe I should transition Dreambuilder back to a full game distro :) |
17:01 |
|
Verticen joined #minetest |
17:01 |
tango_ |
I'm calling it MTG+, but I suck at logos https://github.com/Oblomov/minetest_game/tree/mtg-plus |
17:01 |
VanessaE |
(it started as a fork of mtg, then became a modpack as that was easier to maintain) |
17:02 |
tango_ |
well, a modback is actually easier to maintain with a frozen base |
17:02 |
tango_ |
modpack |
17:02 |
rubenwardy |
VanessaE: MTG was frozen in 2013, and then thawed in 2014 ish after a fork was merged into it |
17:02 |
tango_ |
e.g. you don't have to worry about recipes changing upstrem |
17:02 |
rubenwardy |
it's happened before |
17:02 |
VanessaE |
rubenwardy: sure I remember that, but that wasn't a permanent freeze. |
17:02 |
rubenwardy |
years roughly wrong |
17:02 |
tango_ |
VanessaE: see e.g. the changes I made recently to moreblocks, to resync some of the recipes |
17:02 |
rubenwardy |
neither is this one, VanessaE |
17:03 |
VanessaE |
rubenwardy: er, you better check again |
17:03 |
tango_ |
this is just until paramat gets bored and drops out of the project ;-) |
17:03 |
VanessaE |
I'm pretty sure paramat intends to kill it. |
17:03 |
rubenwardy |
it's no more permanent than the previous freeze - there wasn't a duration or end date in either case |
17:03 |
tango_ |
somebody please find something interesting to do for paramat |
17:03 |
|
Talkless joined #minetest |
17:04 |
sfan5 |
there is no certainty that MTG won't be unfrozen but discontinuing it entirely is meant to encourage different games and stop people from only focusing on MTG |
17:04 |
sfan5 |
so from that angle you're correct |
17:04 |
rubenwardy |
yeah |
17:04 |
rubenwardy |
plus no one wants to work on MTG currently, it's basically been dead for years |
17:04 |
VanessaE |
rubenwardy: "Because we need to move on from MTG, which is holding MT back. There is still too much focus on MTG, core dev and contributor time is better spent elsewhere on new games." |
17:05 |
rubenwardy |
same for the previous freeze |
17:05 |
VanessaE |
hard to read that as anything other than "mtg is dead". |
17:05 |
rubenwardy |
the previous freeze was to encourage modding |
17:06 |
|
Peppy joined #minetest |
17:06 |
rubenwardy |
in any case, people need to work on games and escape the design-by-committee that plagues MTG |
17:08 |
VanessaE |
design by committee? hah |
17:08 |
VanessaE |
a committee of one, maybe :P |
17:08 |
specing |
I find the whole game idea silly |
17:08 |
rubenwardy |
well, it's practically the same problem - it's trying to fulfill conflicting problems without satisfying everyone |
17:09 |
specing |
a game is a collection of mods, which are picked by server hosts and that define the game that is played |
17:09 |
specing |
I don't think MTG should exist at all |
17:10 |
VanessaE |
rubenwardy: your comment https://github.com/minetest/minetest_game/issues/2710#issuecomment-655705075 still holds true, imho |
17:12 |
VanessaE |
I mean think about it |
17:12 |
sfan5 |
it still is true, MTG eventually needs a replacement |
17:12 |
VanessaE |
take MTG, remove that which you don't like, add new mods until it's right, publish |
17:13 |
VanessaE |
(by remove I could also mean to add config options to disable those things) |
17:14 |
VanessaE |
and that's what every server owner out there does (if you s/publish/go live/) |
17:15 |
tango_ |
rubenwardy: the problem with the “maintenance only” is that what consitutes a feature and what consitutes a maintenance action is entirely subjective |
17:15 |
VanessaE |
since to the engine, a game mod is no different from an add-on mod, apart from load order/dependency resolution. |
17:15 |
tango_ |
rubenwardy: I created two PRs that are maintenance-only (make lava reproduction optional and ladder placement improvements) and they are considered “new features” |
17:16 |
tango_ |
I'd say that the issue isn't the design by committee, it's who's on that committee |
17:16 |
tango_ |
that being said, I do agree that having a design document would be a good idea |
17:16 |
tango_ |
(also restructuring default so that it's considerably more sensible) |
17:17 |
VanessaE |
^ the idea of making default into a "meta" mod is good |
17:18 |
VanessaE |
gives modders time to alter their projects to depend on only the bare essentials, before said "meta mod" ceases to exist. |
17:18 |
VanessaE |
but then that raises the question: |
17:18 |
VanessaE |
how would you divvy it all up? |
17:18 |
tango_ |
I also honestly doubt that MTG is “holding MT back” for any real meaning of the expression |
17:18 |
tango_ |
it's not like “oh my god we are so busy on MTG that we don't have time to work on MT” |
17:19 |
rubenwardy |
it's not that, it's the fact that MTG is so terrible and the reliance on it is bad |
17:19 |
MTDiscord |
<appguru> TBH builtin is crappier than MT as most of it hasn't been touched in a while |
17:19 |
tango_ |
rubenwardy: how does that limit MT? |
17:20 |
MTDiscord |
<appguru> Why do all games start out with pulverize, clearinv etc. for example? |
17:20 |
VanessaE |
(I might tend to split things up by node type -- chests in some kind of "storage" mod, furnaces in a "smelting-cooking" mod along with the proposed blast furnaces, stone and stone-like in another, lighting in another, and so on) |
17:20 |
tango_ |
VanessaE: and it should be devised in such a way that combining the elements doesn't require 200 lines of scripting |
17:20 |
VanessaE |
tango_: how do you mean? |
17:21 |
rubenwardy |
I prefer organisation based on dependencies rather than node types - but that's the same for those examples. Chests in `chests` and furnace in `furnace` |
17:21 |
tango_ |
VanessaE: a lot of mods provide stuff done with different materials, but “assembling” that stuff is not easy |
17:21 |
tango_ |
VanessaE: think e.g. stairs |
17:21 |
VanessaE |
oh and of course my basic_materials mod ought to be included in mtg ;) |
17:21 |
rubenwardy |
no |
17:21 |
tango_ |
VanessaE: lol |
17:21 |
rubenwardy |
maybe if it lazy loaded resources |
17:21 |
VanessaE |
inb4 "it's another default" |
17:22 |
VanessaE |
rubenwardy: [meme: "Ackshually..."] |
17:22 |
VanessaE |
I had intended something along those lines but never got around to it |
17:22 |
tango_ |
rubenwardy: OTOH, these kind of stress tests are good to point out deficiencies in the engine |
17:22 |
rubenwardy |
having a mod like that only fixes the problem for those materials. It also confuses players by having resources that are never used |
17:22 |
VanessaE |
and the materials are split into groups already |
17:22 |
tango_ |
rubenwardy: so if anything overloading MTG would be a push to improve MT |
17:22 |
tango_ |
rubenwardy: this is what I suggested, actually |
17:23 |
VanessaE |
rubenwardy: but can you be clear what you mean by "lazy" here?> |
17:23 |
tango_ |
make MTG the testbed for all features, pushing the limits |
17:23 |
rubenwardy |
lazy loading is when you only load something if it is used |
17:23 |
rubenwardy |
so if no mods use plastic, then plastic isn't registered |
17:23 |
tango_ |
rubenwardy: shouldn't that be an engine feature though? |
17:23 |
VanessaE |
rubenwardy: ok, but apart from mods depending on those resources via mod.conf, how else could it be done? |
17:23 |
rubenwardy |
yeah, exactly |
17:24 |
rubenwardy |
which is why I don't think basic_materials solves the problem well enough |
17:24 |
rubenwardy |
VanessaE: API calls, like basic_materials.use("plastic") |
17:24 |
VanessaE |
rubenwardy: I am willing to refine it but like others I kinda need a direction here.. |
17:24 |
rubenwardy |
the engine should fix this anyway |
17:24 |
VanessaE |
but that's impossibel |
17:24 |
VanessaE |
le* |
17:25 |
tango_ |
rubenwardy: the problem with that is chicken and egg |
17:25 |
VanessaE |
there's no way for the engine to just "activate" a new mod (or nodes/items) after it's up and running |
17:25 |
tango_ |
you would have apii calls to require some usages, but also api calls to give some providers, but what if there's circular dependencies |
17:26 |
tango_ |
rubenwardy: consider the case of a stairs mod that does “for every material, provide stairs of that material” |
17:26 |
tango_ |
rubenwardy: the set of materials is undefined if you need registering |
17:26 |
VanessaE |
rubenwardy: either way, the best solution without such a thing would be to split-up basic_materials into several smaller mods, by material type. That's trivial and I could do it in about 20 minutes. |
17:27 |
tango_ |
or, you would need to define everything in call backs |
17:27 |
tango_ |
VanessaE: well, you should do that anyway 8-) |
17:27 |
VanessaE |
but I'll only do that if the results are worth it e.g. if it ends up in mtg for example |
17:27 |
tango_ |
and make each material group a mod option |
17:27 |
VanessaE |
tango_: just so. |
17:28 |
VanessaE |
they're grouped as metals, plastics, electrical, and misc at the moment |
17:29 |
VanessaE |
(though a few "misc" items like the gear and lock could be separated into say "mechanical") |
17:29 |
|
majochup joined #minetest |
17:30 |
tango_ |
(definitely) |
17:30 |
VanessaE |
(the concrete, stuff to make it, along with terracotta base, could go into another mod, "construction" maybe) |
17:34 |
tango_ |
I'm not familiar with your mod, but I think one possibility per rubenwardy's suggestion, aside from mod configuration options to toggle individual classes or materials, would be to provide hooks for registering “providers” and “consumers” of the material |
17:34 |
VanessaE |
it's here if you care to look, https://forum.minetest.net/viewtopic.php?t=21000 |
17:34 |
tango_ |
so for example a “consumer” could say I want to use material X if possible, and it would be possible only if (1) it's enable and (2) there is some provider for it |
17:35 |
tango_ |
but there's obviously the issue with mod registration order |
17:35 |
VanessaE |
well the engine has no concept of "providers" |
17:35 |
VanessaE |
closest is node groups |
17:35 |
tango_ |
VanessaE: no that would be at your mod api level |
17:35 |
VanessaE |
if items could also have groups, that would solve the issue |
17:36 |
tango_ |
as in: a mod says basic_material.register_provider("some material") |
17:36 |
Sokomine |
no :-( i don't think paramat wants to kill mtg. just has no time for it. it would be great if mtg could become a community effort. in my view it's a standard - a base to write mods for |
17:36 |
tango_ |
and you know that that mod will have nodes or mechanism that providethe material |
17:36 |
VanessaE |
so you're suggesting basic_materials ought to work something like biome_lib or signs_lib then |
17:36 |
tango_ |
Sokomine: if paramat has no time for it, then they shouldn't gatekeep changes to it |
17:36 |
tango_ |
but this is not what they are doing |
17:37 |
tango_ |
VanessaE: I'm not entirely sure how biome_lib or sign_lib work 8-P but I trust your word on it |
17:37 |
Sokomine |
the assumtion that any mod has to be written for *just one* particular "game" is very alien to me. my mods are not built and designed that way. they ought to be usable wherever the player/game designer wants to. i frown upon deliberate incompatibility |
17:37 |
VanessaE |
tango_: they're APIs other mods hook into to create new things, in essence. |
17:38 |
tango_ |
VanessaE: that sounds more or less like what we're talking about then, yes |
17:38 |
VanessaE |
I could make basic_materials do that too, but I don't see much point in doing so when 99% of what's really wanted could be solved with finert-grained dependencies in the same way as we're talking of breaking-up the monopoly that is `default`. |
17:42 |
|
daiNoZord joined #minetest |
17:42 |
Sokomine |
what i truely want is a collection of easy-to-use-apis which are already there and can be used without having to install extra mods |
17:44 |
daiNoZord |
Aww crap I'm still here! Oh well for what it may have been worth - I wasn't just trying to learn the bare minimum to get a new "toy" for my world or whatever. I don't play games much. I can take or leave it. If I was interested in just "playing" then I can use any old mod, perhaps with some tweaking. My son plays though, he loves minetest and the time we spend building together, and I thought that it would be a great way |
17:44 |
daiNoZord |
to get into programming. Therefore I set myself small goals to understand things such as physics as they pertain to the game. That said, "lua.api.txt" is not a bible. It's not some great resource for a beginner, but it is a pretty crap place to signpost someone to when they're trying to get their head around an entirely new thing (Insult to injury when it's already open in one of about 20 browser tabs linked to the |
17:44 |
daiNoZord |
question). I get that this is not a "programming advice" room, but the subject appears to be "minetest", and I had hoped for "discussion" around the one or various ways to accomplish any arbitrary goal pertaining to that subject. As it is, however, I will formally request a ban, so I'm not tempted in future to change my mind and bother people any further with my "noob" nonsense, and subsequently I can focus my attention |
17:44 |
daiNoZord |
on better documented and resourced learning endeavours. |
17:45 |
Sokomine |
tango_: your stairs example works to some degree. usually such a mod would wait for a second or so and then iterate over the materials registered by other mods in the meantime and add stairs for them. a more convenient way to do this might be good |
17:45 |
|
daiNoZord left #minetest |
17:45 |
tango_ |
Sokomine: exactly |
17:46 |
tango_ |
Sokomine: but this requires either a change in the way mods are loaded and/or provide features, or to do everything in callbacks |
17:46 |
tango_ |
but then again this isn't an MTG issue per-se |
17:46 |
tango_ |
although MTG could be used as testbed for this feature |
17:50 |
|
AndDT joined #minetest |
17:53 |
tango_ |
Sokomine: the problem is that the dependency tree can be nontrivial to manage |
17:54 |
tango_ |
Sokomine: I had such an example recently when adding some variants to moreblocks. doing all combos has exponential complexity growth |
17:56 |
|
olliy joined #minetest |
17:56 |
|
antims joined #minetest |
18:09 |
Sokomine |
tango_: oh yes. moreblocks is very difficult in that regard |
18:10 |
|
TLuna joined #minetest |
18:10 |
Sokomine |
i'd rather like to see it...divided: into the blocks it provided and the stairsplus mod it comes with |
18:11 |
Sokomine |
"normal" mtg would then still have its stairs mod with its api. if you want more - like the nice stair shapes in moreblocks - you'd replace the mtg-stairs-api with the moreblocks-stairs-api - ideally without having to change any api calls |
18:14 |
tango_ |
Sokomine: I see what you mean about the API thing |
18:15 |
tango_ |
Sokomine: but that's actually the general idea behind mods |
18:17 |
tango_ |
unrelated question, but does the latest MTG master work with 5.3 or is 5.4-dev-only? |
18:18 |
|
Pest|2 joined #minetest |
18:18 |
MTDiscord |
<Jonathon> 5.4-dev i believe |
18:19 |
|
Pest joined #minetest |
18:19 |
|
gerugri joined #minetest |
18:19 |
MTDiscord |
<wwar> 5.4 isnt up for android |
18:20 |
|
fluxflux joined #minetest |
18:21 |
gerugri |
hi all, i would set up a little server on my school for not so much clients (10-20)...someone has this tipe of experience? |
18:21 |
|
Pest joined #minetest |
18:23 |
gerugri |
i mean, do i need some particular hardware or a normal pc is it enough? |
18:24 |
VanessaE |
tango_, rubenwardy anyway if it'll get basic_materials merged into mtg, I may be willing to make it into something more like an API, provided it still works with MT 5.3.0 and wouldn't need a ton of updates to the mods that depend on it. |
18:26 |
tango_ |
VanessaE: given the current attitude from paramat, I wouldn't bother, if inclusion in MTG would be your only reason to do it |
18:27 |
tango_ |
OTOH, working on the API so that mods can start to adapt to it might be a good idea anyway |
18:27 |
tango_ |
and of course you can provide a config option (default true, for the time being) where all stuff gets registered anyway |
18:34 |
VanessaE |
tango_: well like I said, I kinda need a direction too |
18:36 |
VanessaE |
I mean sure, it's simple enough to have some mod that needs a material call a function to declare that need, but since everything has to be registered at startup anyway, about the mod could do is log all such calls, and then after a while, force-*UN*register everything that wasn't asked for |
18:36 |
VanessaE |
and that's....messy |
18:36 |
VanessaE |
about all the* |
18:38 |
VanessaE |
so until then, the most logical solution is to break it up into multiple smaller components like what I did with Homedecor ages ago, and gradually adapt mods that use it to be more fine-grained in their usag. |
18:38 |
VanessaE |
+e |
18:39 |
VanessaE |
come to think of it, are modpacks allowed within a game? |
18:40 |
VanessaE |
i.e. minetest_game/mods/basic_materials_modpack/basic_materials_[foo, bar, baz, ...]/ |
18:40 |
sfan5 |
gerugri: no, normal pc hardware is fine doesn't need to be particularily new either |
18:42 |
|
FeXoR joined #minetest |
18:42 |
|
Pest joined #minetest |
18:43 |
* tango_ |
has no idea what a modpack is |
18:44 |
tango_ |
VanessaE: I'm thinking that maybe registration could be delayed and made inside a callback, but I don't know if that's allowed |
18:44 |
VanessaE |
literally a handful of mods contained in a top-level folder, with an empty file 'modpack.txt' included. that's it. |
18:45 |
VanessaE |
(though normally those mods are gathered together to form a theme of some kind) |
18:45 |
|
longerstaff13 joined #minetest |
18:45 |
|
luk3yx joined #minetest |
18:53 |
|
Jhalman joined #minetest |
18:55 |
specing |
gerugri: it depends on the mods |
18:55 |
specing |
e.g. petz might require a 20 GHz machine at 20 clients |
18:56 |
sfan5 |
no such thing ;) |
18:57 |
specing |
exactly |
19:04 |
MTDiscord |
<IhrFussel> Many mods just aren't optimized much for server gameplay...I disable some intensive parts of mods when there are too many lag spikes for example |
19:07 |
MinetestBot |
[git] SmallJoker -> minetest/minetest: Revert "GUIFormSpecMenu: Shift+Click listring workaround for MacOS" f2c8c6b https://git.io/JLLiz (2020-12-14T19:05:24Z) |
19:10 |
|
proller joined #minetest |
19:10 |
VanessaE |
rubenwardy, tango_ would you guys mind filing an issue on basic_materials about all this? maybe we can come to some consensus on a direction? or at least, just so it's not forgotten |
19:25 |
Sokomine |
tango_: right now mods are mostly standalone things. apis exist, but it's rare that anyone but the creator ever uses them due to the libs not beeing provided with the "standard" game |
19:26 |
|
TLuna joined #minetest |
19:29 |
tango_ |
Sokomine: but that's up to the mod creators though, isn't it? this isn't something for the minetest devs to decide |
19:29 |
Sokomine |
VanessaE: hm. a mt.requires("plastic") call...it sounds a bit complicated. might be easier to check i.e. recipes at registration and have such a call when there's additional need |
19:29 |
tango_ |
Sokomine: for example for my experimental dowsing mod I did provide sort-of an API, but again it's up to me |
19:29 |
Sokomine |
tango_: the lib situation won't improve until they're more easily available |
19:29 |
tango_ |
VanessaE: I tend not to open issues for stuff I don't personally use, sorry 8-P |
19:30 |
Hawk777 |
TBH, a plethora of games scares me a bit, as an ordinary user. Right now I know that most mods work with MTG. If there are a lot of base games, sounds like an easy way to have no standardization, fragmentation, and then the mod community also fragments into mods that work on game A, mods that work on game B, and so on, and now I can’t have all the nice things at once. Seems like a lot of effort and a worse experience for players |
19:30 |
Hawk777 |
e should that happen. |
19:30 |
tango_ |
Hawk777: that has been discussed in the “freeze mtg” issue |
19:33 |
VanessaE |
tango_: do it anyway ;) your input could be useful. Sokomine's too |
19:38 |
Hawk777 |
Yeah, it was, but not AFAICT with any conclusion. AFAICT the answer is to keep MTG as a modding base, but then… what? Either all the mods build on top of MTG (in which case all the new fancy wonderful games that people want to replace it with are kind of fail because you can’t use any mods in them), or else one of the new wonderful fancy games wins (in which case the world is fragmented into the old mods that work with MTG, an |
19:38 |
Hawk777 |
new mods that work with New Fancy Game, and they can’t be used together). |
19:38 |
Hawk777 |
Even if the new games are just forks of MTG, as soon as they add a new feature that some mod might want to use, the same fragmentation happens. |
19:40 |
Hawk777 |
If some fork of MTG wins the popularity contest and essentially all the mods work with it (either because they’re old, depend on MTG, and the fork retained compat, or because they’re new and built on the popular winner) then great, but until that winner emerges, feels like a mess. |
19:41 |
Hawk777 |
Shrug. I don’t like forks in general for this reason. |
19:42 |
Hawk777 |
Not like I have any choice, the devs will do what they do, just… scary. |
19:42 |
MTDiscord |
<appguru> I have recently started yet another fork |
19:42 |
MTDiscord |
<appguru> Just to merge my two PRs hehe |
19:53 |
tango_ |
appguru: that makes two of us |
19:54 |
MTDiscord |
<appguru> what have you merged in your fork? |
19:54 |
MTDiscord |
<appguru> I might merge it too |
19:55 |
tango_ |
https://github.com/Oblomov/minetest_game/tree/mtg-plus it's basically master plus my (currently two) branches intended for MTG plus a branch to add an icon with a big red plus and a rename of the game |
19:56 |
tango_ |
https://github.com/Oblomov/minetest_game/commits/mtg-plus shows the branches merged |
19:56 |
tango_ |
renewable lava and improved ladder placement |
19:58 |
tango_ |
they are trivial, PR pending, paramat objected because according to them it's “new features” |
19:58 |
tango_ |
but at least the PRs are not closed yet |
20:01 |
Bombo |
!tell Bombo /grantme all |
20:01 |
MinetestBot |
You can tell that to yourself |
20:02 |
Bombo |
pffh |
20:02 |
tango_ |
I mean the bot is not wrong 8-D |
20:02 |
Bombo |
thought it would tell me more ;) |
20:03 |
tango_ |
Bombo: probably does the same for anyone who's already in chat |
20:03 |
tango_ |
!tell Bombo look at this |
20:03 |
MinetestBot |
tango_: I'll pass that on when Bombo is around |
20:03 |
tango_ |
ah no |
20:03 |
tango_ |
then it's stupid 8-D |
20:03 |
tango_ |
I mean, it's a bot 8-) |
20:04 |
|
Swift110-mobile joined #minetest |
20:04 |
tango_ |
maybe when you speak then? |
20:21 |
|
fleeky_ joined #minetest |
20:23 |
tango_ |
not the biggest fan of squashed merges, TBH |
20:36 |
|
Pest joined #minetest |
20:36 |
|
Jhalman joined #minetest |
20:40 |
|
gerugri joined #minetest |
20:45 |
|
I_am_6r1d joined #minetest |
20:53 |
|
jluc joined #minetest |
21:07 |
rubenwardy |
Calinou: I've fixed the release bug and added 2.1.0 to CDB |
21:07 |
Calinou |
thanks! :) |
21:37 |
tango_ |
Calinou: about the glass texture: when you have a cube of glass, you cannot see “the other side” of the cube |
21:37 |
tango_ |
is this a general rendering limitation of minetest, or specific to the (clean) glass texture? |
21:38 |
tango_ |
it's funny because you can see the surface of the adjacent blocks, but not e.g. the opposite edge through the glass |
21:38 |
tango_ |
not sure if I'm being clear |
21:42 |
|
Lukwe joined #minetest |
21:46 |
Calinou |
tango_: it's a rendering limitation, it could be lifted by adding a new drawtype in C++ but it's not really worth it |
21:46 |
Calinou |
(one that has backface culling disabled) |
21:47 |
Calinou |
alternatively, you could have a nodebox that's a cube with very thin hollow faces |
21:47 |
tango_ |
says you 8-D |
21:47 |
tango_ |
(on the worthness) |
21:47 |
Calinou |
the nodebox approach would only work for leaves, not glass since you want adjacent faces to disappear |
21:47 |
tango_ |
not entirely sure I understand |
21:48 |
tango_ |
doesn't the disappearing or not depend on that infamous client-side option? |
21:48 |
tango_ |
oh but still it would need to be supported |
21:48 |
tango_ |
hm |
21:52 |
|
TLuna joined #minetest |
22:02 |
Gustavo6046 |
Do you think Lua lacking any sort of type-checking or safety features whatsoever could be a detriment and an inconvenience to modders? |
22:04 |
sfan5 |
perhaps |
22:05 |
Gustavo6046 |
Lua is tedious to write, difficult to debug, and convoluted. It's kind of obsolete nowadays, which shows in the form of its community slowly shrinking -- it's noticeably less active today than it was ages past. It is the main reason I proposed an alternative JS API. JS does almost everything Lua does, and it's both easier to write and to fix, and it's also easier to understand. |
22:05 |
Gustavo6046 |
JS is also easy to embed, thanks to projects like Duktape and QuickJS which are basically small and portable JavaScript VMs written in C. |
22:07 |
rubenwardy |
Lua has safety features - it has stronger typing than JS, and there's LuaCheck |
22:08 |
sfan5 |
JS "we know what the programmer meant" dynamic typing is worse than Lua's. I contest the "easier to understand" point too, core language features of both are pretty simple. And "difficult to write" or "convoluted" are subjective. |
22:08 |
rubenwardy |
I like JS, and it's awesome with typescript |
22:08 |
sfan5 |
more importantly, how's the speed of embeddable js interpreters compared to luajit? |
22:08 |
rubenwardy |
V8 has beaten LuaJIT for many years |
22:08 |
rubenwardy |
not sure how large that is |
22:09 |
sfan5 |
I know, but V8 doesn't seem realistically embeddable |
22:10 |
rubenwardy |
I'd be surprised given how browsers embed it. I'd also be surprised if it's not massive |
22:12 |
|
grumble joined #minetest |
22:20 |
|
Taoki joined #minetest |
22:25 |
Gustavo6046 |
rubenwardy: Lua has no typing at all |
22:25 |
Gustavo6046 |
I don't know what you mean |
22:25 |
Gustavo6046 |
And V8 is not very embeddable |
22:25 |
Gustavo6046 |
Luajit is superfast, so that's a plus |
22:25 |
rubenwardy |
False, it has booleans, numbers, functions, tables, and userdata |
22:26 |
Gustavo6046 |
But quickjs offers pretty decent performance, for a portable embedded language interpreter anyway |
22:26 |
rubenwardy |
There's less weird casting like in JS - you can't add an array to a number |
22:26 |
rubenwardy |
That makes it have stronger typing |
22:26 |
rubenwardy |
It's just not statically typed |
22:26 |
Gustavo6046 |
rubenwardy: I think JS weird casting is irrelevant |
22:26 |
Gustavo6046 |
it's more of a quirk than a point that matters |
22:26 |
Gustavo6046 |
If you ask me, anyway |
22:27 |
Gustavo6046 |
And Lua tables and userdata are kind of idiosyncrasies |
22:27 |
Gustavo6046 |
I prefer JS's object syntax, with the C-like dot notation |
22:28 |
Gustavo6046 |
What, why can't I add diacritics to vowels in chat or in Travelnet box names? |
22:28 |
Gustavo6046 |
If I use deadkeys, it looks like "^a", not â |
22:29 |
Gustavo6046 |
and if I try pasting (at least in the latter case), it just brings up an abnormally big space |
22:31 |
sfan5 |
input bug with irrlicht likely |
22:37 |
Gustavo6046 |
Ah |
22:37 |
Gustavo6046 |
Also, I see what seems to be a desert -- big, relatively flat plains of desert sand with a massive layer of desert stone underneath --, but no cacti :( |
22:43 |
|
Jhalman joined #minetest |
22:44 |
Hawk777 |
I don’t see why it makes any sense for the core devs to spend a zillion hours integrating a Javascript engine when any decent programmer can learn a language they don’t know without too much trouble, and personally I found Lua to be a particularly easy language to learn. I’d rather they spend their limited time on something with a higher bang-for-buck ratio. |
22:46 |
|
Fixer_ joined #minetest |
22:50 |
Gustavo6046 |
Hawk777: it's easy to integrate, depending on the "engine" |
22:50 |
MinetestBot |
[git] Zughy -> minetest/minetest: Semi-transparent background for nametags (#10152) 4d41ed0 https://git.io/JLtWN (2020-12-14T22:49:30Z) |
22:50 |
Gustavo6046 |
and Lua is troubling, yes |
22:50 |
Gustavo6046 |
It is fine to learn but not fine for larger codebases |
22:50 |
sfan5 |
another scripting backend is not that hard to implement in itself but it opens up quite some trouble over who gets to handle a callback and other ordering issues |
22:51 |
Hawk777 |
You are also proposing that the maintenance work related to scripting engines be doubled, because there are two of them. Unless you propose replacing Lua rather than adding in addition, in which case you have just broken every single game and mod that existed anywhere ever. |
22:52 |
Hawk777 |
I also personally opine that Javascript is unsuitable for larger codebases because I happen to like static typing, and neither Lua nor JS have that. |
22:53 |
Hawk777 |
So now you get to endlessly bikeshed which language should be added. |
22:53 |
tango_ |
obviously everything should be done in C |
22:53 |
tango_ |
what's with this fancy smancy C++ thingie in the core |
22:53 |
tango_ |
psssht |
22:53 |
tango_ |
OK seriously though, why isn't there something like a brick wall |
22:54 |
tango_ |
I mean the red clay bricks |
22:54 |
tango_ |
only slabs and stairs? |
22:54 |
sfan5 |
I can assure bricks exist |
22:54 |
sfan5 |
assure you* |
22:54 |
tango_ |
bicks of course |
22:54 |
tango_ |
I have plenty of brick blocks |
22:55 |
tango_ |
but I can only do slabs and stairs with them, not the poles |
22:55 |
tango_ |
not even with moreblocks it seems 8-( |
22:55 |
sfan5 |
hmm that's a good point |
22:56 |
tango_ |
hm but I can do brick block panels with moreblocks |
22:56 |
tango_ |
hmmmmmmm |
22:56 |
tango_ |
damn I have to decide what to use to build my fancy house |
22:56 |
tango_ |
stone bricks are too thick visually |
22:57 |
tango_ |
(ditto sandstone bricks etc) |
22:57 |
tango_ |
BTW I hate non-renewable materials |
23:00 |
blaise |
so, can we play minetest using google cardboard? |
23:00 |
specing |
Sounds proprietary |
23:00 |
blaise |
eh, using a phone via usb as another display ? |
23:01 |
tango_ |
does MT support VR at all? |
23:01 |
tango_ |
I don't think so |
23:01 |
blaise |
it does... |
23:01 |
tango_ |
it does? |
23:01 |
blaise |
it has support for several means of 3d.. |
23:01 |
blaise |
even the old red/blue shift |
23:02 |
tango_ |
really, how do you enable it? |
23:02 |
blaise |
it's in the video settings |
23:02 |
sfan5 |
3d video output is not all that's needed for VR |
23:03 |
blaise |
to support using split view VR for use with the widely documented cardboard VR headset's that anyone can build and use with a cellphone, there is a vivecraft mod on curseforge.. |
23:04 |
blaise |
google opensourced their cardboard project quite some time ago |
23:06 |
blaise |
and here is an opensource project called phone VR https://github.com/ShootingKing-AM/PhoneVR as an alternative to iVRy, VRidge, and others.. |
23:08 |
blaise |
quite nifty.. and rather fun.. :) |
23:13 |
Helenah |
How do I debug why wheat wont grow all of a sudden? |
23:18 |
MTDiscord |
<srinivas> also; > I'd be surprised given how browsers embed it. I'd also be surprised if it's not massive in this age of increasingly common 1 tb drives, does another say 50 mb even matter? |
23:19 |
tango_ |
Helenah: sun + wet soil afaik is the only requirement |
23:19 |
tango_ |
Helenah: are they in the shadow |
23:19 |
tango_ |
oh wtf walls can only be made of cobblestone? |
23:22 |
MTDiscord |
<srinivas> no? |
23:22 |
MTDiscord |
<srinivas> last i checked there were other bricks too |
23:22 |
specing |
Helenah: heh you look at what changed since it last grew |
23:23 |
tango_ |
srinivas: I mean at the actual wall node |
23:23 |
tango_ |
srinivas: as far as I can see it's only cobblestone |
23:23 |
tango_ |
all others you have to do it with non-connecting 1x1x1 nodes |
23:24 |
tango_ |
unless I'm missing something |
23:24 |
tango_ |
ah, super duper walls |
23:31 |
blaise |
lmao |