| Time |
Nick |
Message |
| 00:17 |
|
fz72 joined #minetest-dev |
| 00:18 |
|
exio4_ joined #minetest-dev |
| 00:20 |
|
n4x joined #minetest-dev |
| 00:23 |
fz72 |
PilzAdam: I think, you should enable -DCMAKE_BUILD_TYPE=Release for the packages in ppa |
| 00:25 |
PilzAdam |
hm? is it set to debug? |
| 00:28 |
PilzAdam |
fz72, where would I change that? |
| 00:32 |
fz72 |
run cmake -DCMAKE_BUILD_TYPE=Release before compiling with make -j2 |
| 00:33 |
PilzAdam |
the launchpad builds are automated |
| 00:33 |
PilzAdam |
which script do I need to change to set that? |
| 00:33 |
|
acerspyro joined #minetest-dev |
| 00:34 |
Tesseract |
Builds should be release unless explicitly specified otherwise. |
| 00:36 |
fz72 |
sorry, I never worked with launchpad |
| 00:36 |
acerspyro |
Tesseract, Have you heard of #tesseract? |
| 00:37 |
PilzAdam |
fz72, oh, I thought you saw that it was set to Debug somewhere in the scripts |
| 00:37 |
PilzAdam |
if it's not specified, then it's "Release" by default |
| 00:39 |
fz72 |
when, i clone a minetest from github it is set to debug by default |
| 01:12 |
|
exio4 joined #minetest-dev |
| 01:13 |
|
exio4_ joined #minetest-dev |
| 01:19 |
|
Zeno` joined #minetest-dev |
| 01:25 |
|
VargaD joined #minetest-dev |
| 01:26 |
shadowzone |
hi Zeno` |
| 01:32 |
|
acerspyro joined #minetest-dev |
| 01:46 |
|
MichaelRpdx joined #minetest-dev |
| 02:00 |
|
twoelk joined #minetest-dev |
| 02:24 |
|
exio4 joined #minetest-dev |
| 02:25 |
|
n4x joined #minetest-dev |
| 02:26 |
|
prozacgod joined #minetest-dev |
| 02:34 |
hmmmm |
gonna start pushing some shit |
| 02:34 |
hmmmm |
say something now or forever hold your peace |
| 02:35 |
VanessaE |
branch off first? |
| 02:35 |
VanessaE |
:) |
| 02:36 |
hmmmm |
https://github.com/minetest/minetest/commit/b67f37f27ea7d89b2098fa9fcc2533fa1091e695 |
| 02:36 |
hmmmm |
done~ |
| 02:36 |
|
paramat joined #minetest-dev |
| 02:46 |
Zeno` |
https://github.com/minetest/minetest/blob/b67f37f27ea7d89b2098fa9fcc2533fa1091e695/src/mg_ore.cpp#L65 <--- What's the thinking behind this? |
| 02:47 |
Zeno` |
specifically, line 69 |
| 02:48 |
Zeno` |
Why not have just line 69? |
| 02:49 |
Tesseract |
Zeno`: clear() doesn't delete, it just destructs. |
| 02:49 |
Zeno` |
clear calls the destructor of the objects doesn't it? |
| 02:49 |
Tesseract |
(and pointer destructors are no-op) |
| 02:50 |
Zeno` |
so what's the loop doing? |
| 02:50 |
Tesseract |
Zeno`: It's an array of pointers, not objects. |
| 02:50 |
Zeno` |
ok |
| 02:51 |
Zeno` |
yes I see now. Thanks |
| 03:10 |
hmmmm |
erm |
| 03:10 |
hmmmm |
ever test something and then you end up playing it? |
| 03:11 |
VanessaE |
that's how it's supposed to work, hmmmm :) |
| 03:11 |
hmmmm |
does LazyJ's schematic problem have a PR? |
| 03:13 |
VanessaE |
um.. |
| 03:14 |
VanessaE |
not that I can see. |
| 03:14 |
paramat |
hi hmmmm, are you planning to edit mapgen_v7.cpp/.h anytime in the next week? i'm working on these and don't want to deal with merge conflicts |
| 03:14 |
hmmmm |
i have no clu |
| 03:14 |
hmmmm |
i won't, i guess |
| 03:15 |
paramat |
okay good |
| 03:17 |
paramat |
i'm adding overgeneration to avoid stone lines at y = 47 etc. also, the caves are horrid, can i port in v5 type caves, but non-eased for speed and perhaps a larger 'scale' to suit the terrain |
| 03:18 |
hmmmm |
overgeneration is causing issues with LVM worlds |
| 03:19 |
paramat |
current caves in v7: https://cdn.mediacru.sh/-/-EXA7AkfIwOK.png |
| 03:21 |
hmmmm |
i don't know what I want to do with caves yet |
| 03:21 |
paramat |
okay i won't touch caves then |
| 03:21 |
hmmmm |
v5 caves have issues as well |
| 03:22 |
hmmmm |
they aren't as serious as the current cave issues though |
| 03:22 |
paramat |
overgen issues with LVM sounds interesting/worrying? |
| 03:25 |
hmmmm |
it's because LVM doesn't take into account overgen |
| 03:26 |
hmmmm |
i'll have to query the chunk size from the mapgen somehow |
| 03:27 |
|
MinerDad joined #minetest-dev |
| 03:28 |
paramat |
mmm .. i can't see the problem. however i admit my v5 overgen is perhaps a little hacky (but it works) |
| 03:29 |
paramat |
i could probably improve it |
| 03:31 |
paramat |
okay seems best i stop work on v7 for now but keep the branch for reference |
| 03:31 |
hmmmm |
see... |
| 03:32 |
hmmmm |
v6 caves are absolutely necessary for v6 terrain |
| 03:32 |
hmmmm |
not quite so much for v7 |
| 03:32 |
hmmmm |
i thought for a moment that maybe it would be a cool idea to choose the cave type |
| 03:35 |
paramat |
okay the only thing i need to change in v7 then is integrating the improved biome api |
| 03:35 |
|
exio4 joined #minetest-dev |
| 03:36 |
|
exio4_ joined #minetest-dev |
| 03:37 |
paramat |
for my biome api branch i'm waiting for the right time to manually rebase it (for the 3rd time heh) because code keeps changing |
| 03:37 |
paramat |
i need to rebase it on your latest commit |
| 03:38 |
VanessaE |
hmmmm: there's your "code rot" issue.. |
| 03:38 |
hmmmm |
right now would probably be a good opportunity |
| 03:38 |
paramat |
but that takes time and by the time it's ready code may have changed again |
| 03:38 |
paramat |
okay good |
| 03:39 |
hmmmm |
i'm going to be modifying l_mapgen.cpp a bit with the next three or so commits but it won't be anything in proximity to the biome register function |
| 03:39 |
paramat |
ah good |
| 03:39 |
paramat |
i can give it top priority and have it ready within 1-2 days, fast enough? |
| 03:39 |
|
shadowzone joined #minetest-dev |
| 03:40 |
hmmmm |
that's totally fine |
| 03:40 |
paramat |
cool |
| 03:40 |
paramat |
i will be editing mapgenv5.cpp mapgenv7.cpp mgbiome.cpp mgbiome.h and lmapgen.cpp |
| 03:41 |
paramat |
so hands off those files everyone! RRR! |
| 03:42 |
hmmmm |
i'm gonna have my hands all over mg_schematic.cpp for a while |
| 03:43 |
hmmmm |
adding a register_schematic() function finally |
| 03:48 |
paramat |
good. now i can't see the problem with LVM and overgeneration, since already there are bits of dungeon and tree protruding from a mapchunk, a bit of stone amkes no difference. LVM volume contains the mapblock shell anyway |
| 03:48 |
paramat |
*makes |
| 04:01 |
paramat |
since biome material is roughly 4 nodes deep i want to extend the overgeneration to 2 up 2 down. i'll work on this in v5 only for now, good thing it's still unstable |
| 04:03 |
* paramat |
has more experience with mapgen-object-voxelmanip as anyone else here ^_^ |
| 04:09 |
hmmmm |
https://github.com/minetest/minetest/commit/8334100fe1b1bb40bfebff9ec9780c18fe3fd0c7 |
| 04:11 |
hmmmm |
local vm = VoxelManip(p1, p2); local emin, emax = vm:get_emerged_area(); local data = vm:get_data() <write data here> vm:set_data(data); vm:write_to_map(); vm:update_map() |
| 04:12 |
hmmmm |
setting a node to CONTENT_IGNORE in a VoxelManipulator means "skip writing this node on blit back" |
| 04:13 |
|
MinerDad joined #minetest-dev |
| 04:17 |
|
selat joined #minetest-dev |
| 04:26 |
* paramat |
will study this |
| 04:35 |
|
paramat left #minetest-dev |
| 04:48 |
|
exio4_ joined #minetest-dev |
| 04:49 |
|
n4x joined #minetest-dev |
| 05:04 |
|
shmancelot joined #minetest-dev |
| 05:27 |
|
paramat joined #minetest-dev |
| 05:28 |
paramat |
https://github.com/paramat/minetest/commits/biomeapi3 coded but not yet tested. will test over the next few hours |
| 05:28 |
|
paramat left #minetest-dev |
| 06:01 |
|
n4x joined #minetest-dev |
| 06:01 |
|
exio4_ joined #minetest-dev |
| 06:23 |
|
sol_invictus joined #minetest-dev |
| 07:16 |
|
exio4_ joined #minetest-dev |
| 07:17 |
|
exio4 joined #minetest-dev |
| 07:29 |
|
Zeno` joined #minetest-dev |
| 07:29 |
Zeno` |
hmmmm, https://github.com/minetest/minetest/commit/8334100fe1b1bb40bfebff9ec9780c18fe3fd0c7#diff-1305560bd8befb32862f0feeefabd02eR1598 |
| 07:30 |
Zeno` |
are you planning to add an option to have a vmanip with the data not initialized at all? |
| 07:31 |
Zeno` |
although I guess cignore is the next best thing (which you've already added) |
| 07:32 |
Zeno` |
Any comments on #1967? |
| 07:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/1967 -- Add display_gamma option for client by Zeno- |
| 07:34 |
Zeno` |
also, #1851 to fix #1993 |
| 07:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/1851 -- Cleanup updateCameraDirection and fix random input not working by Zeno- |
| 07:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/1993 -- random-input is always looking into the same direction |
| 07:36 |
Zeno` |
And #1977 should be merged very soon if markdown is the "new way" otherwise commit conflicts are going to get annoying pretty fast |
| 07:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/1977 -- Rewrite lua_api.txt into Markdown format by Wuzzy2 |
| 07:41 |
n4x |
what about #1952? |
| 07:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/1952 -- Use the console instead of a dedicated window when pressing chat/command keys by ShadowNinja |
| 07:43 |
hmmmm |
Zeno`, not possible |
| 07:44 |
hmmmm |
why would you want that anyway? |
| 07:45 |
VanessaE |
which one? |
| 07:49 |
Zeno` |
If I get want a vmanip with the whole area filled with, say, sand I don't think I'd want it pre-initialised to content ignore |
| 07:49 |
Zeno` |
If I want to set up a vmanip* |
| 07:52 |
hmmmm |
well a prerequisite to that would be to make an exact-node-size vmanip |
| 07:53 |
hmmmm |
in order to do that you'd have to write a new blitBackAll that can deal with partial mapblocks |
| 07:53 |
hmmmm |
and in order to do that now you need to start modifying the mapblock structure |
| 07:53 |
hmmmm |
well, data shouldn't be private to start with |
| 07:54 |
hmmmm |
what's wrong with just filling it in your mod? |
| 07:56 |
Zeno` |
nothing. Quite possibly the changes already do want I want. E.g. using vmanip to clear areas of the map |
| 07:57 |
hmmmm |
you could've done anything you wanted to before this change |
| 07:57 |
Zeno` |
Not without getting the map data first |
| 07:57 |
hmmmm |
all this change does is make it unnecessary to load map into the voxelmanipulator for faster performance |
| 07:58 |
Zeno` |
ok, so if I'm understanding you it's doing what was needed already now |
| 07:59 |
|
paramat joined #minetest-dev |
| 07:59 |
paramat |
biome api now tested, pull incoming.. |
| 08:00 |
Zeno` |
IIRC before it was not possible without first getting the data from the map because there was no way (other than that) to specify where the data should go when you wrote it back |
| 08:00 |
hmmmm |
from an external point of view, i guess so |
| 08:02 |
hmmmm |
ooh snap |
| 08:02 |
hmmmm |
i should probably createBlock() if it returns NULL |
| 08:04 |
paramat |
https://github.com/minetest/minetest/pull/2019 |
| 08:05 |
hmmmm |
looks good |
| 08:07 |
|
Hunterz joined #minetest-dev |
| 08:09 |
paramat |
i will write a post on the forum explaining the features and how players' should rewrite their biome registrations for a near seamless transition (all that changes is the lack of glitches) |
| 08:13 |
paramat |
one thing i'd like to do with mgv7 (if ok with you) is remove the range limiting of mountain height so we can control that with noiseparams in .conf and do stuff like this http://i.imgur.com/bwge8zu.png |
| 08:15 |
hmmmm |
the intention of range limiting mountain height was so that it creates kind of a top tier of flat-ish terrain for players to build on |
| 08:15 |
hmmmm |
but that failed miserably |
| 08:15 |
hmmmm |
i can do a lot of great things with mapgen v7 - it's just not a priority at all |
| 08:16 |
hmmmm |
sure, i guess you could do that |
| 08:16 |
|
nore joined #minetest-dev |
| 08:18 |
paramat |
okay thanks. yeah the range limiting doesn't create plateaus at all, good intention though |
| 08:20 |
paramat |
also i might submit a pull to add a check for 'ignore or air' when placing mountain terrain, so that dungeons don't get cut off. anyway time to watch anime.. |
| 08:23 |
paramat |
http://i.imgur.com/zxIISlu.png the 3d noise of mgv7 is good for creating floatlands |
| 08:28 |
hmmmm |
vein ore is really slow |
| 08:29 |
|
exio4 joined #minetest-dev |
| 08:30 |
|
n4x joined #minetest-dev |
| 08:40 |
|
paramat left #minetest-dev |
| 08:51 |
|
AnotherBrick joined #minetest-dev |
| 09:03 |
|
shadowzone joined #minetest-dev |
| 09:14 |
|
Calinou joined #minetest-dev |
| 09:15 |
|
cib0 joined #minetest-dev |
| 09:17 |
|
kilbith joined #minetest-dev |
| 09:18 |
cib0 |
Hello. |
| 09:21 |
sfan5 |
hi |
| 09:22 |
cib0 |
Random question: How well would the minetest engine lend itself to Dwarf Fortress-y features(worldgen, civilization simulation, settlements with AI controlled actors and so on) |
| 09:23 |
Calinou |
it is possible to do all these |
| 09:24 |
cib0 |
Nice. :) It's been years since I checked this project, and I'm very impressed by how it's developed. |
| 09:25 |
Calinou |
cib0, check the mg and mg_villages mod for Lua map generation with villages |
| 09:26 |
cib0 |
In minetest_game? |
| 09:27 |
Calinou |
they are not included |
| 09:27 |
Calinou |
you have to download and install them from forums |
| 09:27 |
cib0 |
Oh, okay. |
| 09:28 |
|
chchjesus__ joined #minetest-dev |
| 09:38 |
cib0 |
Hm, maybe I should just take a poke at a bug. |
| 09:44 |
|
chchjesus__ joined #minetest-dev |
| 09:50 |
Calinou |
https://forum.minetest.net/viewtopic.php?f=3&t=10848&p=166107#p166107 |
| 09:50 |
Calinou |
I agree about the versioning change, but make it 1.0, that's less daunting |
| 09:52 |
Zeno` |
Personally I think 1.0 is better as well |
| 09:53 |
Zeno` |
1.0.0 rather ;) |
| 09:54 |
Calinou |
yes, 1.0.0 |
| 09:55 |
cib0 |
Huh. |
| 09:57 |
cib0 |
What kind of bugs are we talking about? I hope not the kind where someone didn't test their stuff properly. :P |
| 10:01 |
|
chchjesus__ joined #minetest-dev |
| 10:02 |
Zeno` |
huh |
| 10:02 |
|
ImQ009 joined #minetest-dev |
| 10:02 |
Zeno` |
I didn't know we were talking about bugs at all :P |
| 10:02 |
|
compunerd joined #minetest-dev |
| 10:02 |
Zeno` |
Oh, the "hacky workarounds"? |
| 10:03 |
cib0 |
Referring to the thread, someone said minetest is in a perpetual state of bugginess. |
| 10:03 |
Zeno` |
stable is |
| 10:04 |
Calinou |
all software has bugs |
| 10:04 |
Zeno` |
mainly because bug fixes are not backported/cherry-picked back into stable |
| 10:04 |
Zeno` |
and some of the reason that doesn't happen is, strangely enough, because of the version numbering |
| 10:05 |
Zeno` |
so major.minor.patch is what hmmmm is suggesting (I hope I haven't misunderstood) |
| 10:05 |
Zeno` |
and I'm fine with that, just not fine with the next release being 5.0.0 |
| 10:06 |
Calinou |
http://semver.org |
| 10:06 |
Calinou |
is pretty much common sense, but worth following |
| 10:06 |
Zeno` |
yeah I am a proponent of semantic versioning myself |
| 10:07 |
cib0 |
Well, yeah, there will always be bugs. Sometimes because they're really obscure, rare and hard to reproduce. Sometimes because some important aspect of the source isn't fleshed out enough. But most code should be bug-free the moment it's merged. |
| 10:08 |
cib0 |
And eyah lots of projects use that versioning scheme. |
| 10:10 |
cib0 |
Hm, I think I'd kinda prefer a binding generator to hardcoding all the bindings in C++ with the lua API.. would make it much more easy to plug in other scripting languages. |
| 10:11 |
Zeno` |
Unfortunately a lot of the code is barely understandable and not structured in any way |
| 10:12 |
cib0 |
Well that's a people problem. :) |
| 10:12 |
Zeno` |
I don't think anyone debates that hehe |
| 10:12 |
cib0 |
So far I'm okay with the source I've seen. Where shouldn't I look? |
| 10:12 |
Zeno` |
but seriously... the 1000 line functions have to go. But this will take time |
| 10:13 |
Zeno` |
cib0, look at game.cpp before I refactored it a couple months ago (it was seriously a 3000+ line function) |
| 10:13 |
Zeno` |
there are heaps of other examples... I'm sure you can find them |
| 10:13 |
cib0 |
Ouch. |
| 10:14 |
cib0 |
Well, if it's just legacy code, I don't take issue. |
| 10:14 |
cib0 |
But code like that isn't merged anymore, right? |
| 10:15 |
Zeno` |
mostly not |
| 10:16 |
Zeno` |
I guess |
| 10:16 |
cib0 |
Well, it was nice knowing you. :P j/k |
| 10:17 |
Zeno` |
main.cpp and game.cpp still need more work |
| 10:17 |
Zeno` |
I did the bare minimum |
| 10:17 |
cib0 |
I could work on stuff like that, too, I guess. |
| 10:17 |
cib0 |
For now I just grabbed the first issue on the tracker that seemed doable. |
| 10:17 |
cib0 |
I don't have much time though. :( |
| 10:17 |
|
casimir joined #minetest-dev |
| 10:18 |
Zeno` |
client.cpp probably needs work |
| 10:18 |
Zeno` |
what are you working on? |
| 10:18 |
cib0 |
https://github.com/minetest/minetest/issues/2015 |
| 10:19 |
Zeno` |
void Client::ProcessData() is only 1005 lines long |
| 10:19 |
Zeno` |
oh yeah, cool |
| 10:19 |
|
PilzAdam joined #minetest-dev |
| 10:21 |
cib0 |
What needs work in main.cpp? |
| 10:21 |
Zeno` |
cib0, I don't know. I just know that when I'd refactored it there were still parts I thought were "clumsy" |
| 10:21 |
Zeno` |
I should have made a list |
| 10:23 |
cib0 |
Man, these files look fine to me. I've seen so much worse. |
| 10:24 |
Zeno` |
:) |
| 10:24 |
Zeno` |
I can't remember why I brought this up though |
| 10:25 |
Zeno` |
weird |
| 10:26 |
Zeno` |
anyway I vote 1.0.0 should be next release and not 5.0.0 |
| 10:27 |
Zeno` |
maybe it can be a short release cycle; squash the major bugs, release |
| 10:27 |
cib0 |
Sounds reasonable. |
| 10:27 |
Zeno` |
(for the 1.0.0 release I mean) |
| 10:27 |
|
n4x joined #minetest-dev |
| 10:28 |
cib0 |
We do not need firefox version numbering. :) minetest 5564.0.1 released! |
| 10:28 |
Zeno` |
is it? |
| 10:28 |
* Zeno` |
checks |
| 10:28 |
cib0 |
Not yet, but soon |
| 10:28 |
Zeno` |
Was gonna say... I'm only on 35.0.5 |
| 10:29 |
Zeno` |
34* |
| 10:29 |
Zeno` |
but yes, that's a good example |
| 10:30 |
cib0 |
Do we have code style guidelines? |
| 10:30 |
sfan5 |
yes |
| 10:31 |
sfan5 |
cib0: http://dev.minetest.net/Code_style_guidelines |
| 10:31 |
cib0 |
ty |
| 10:40 |
cib0 |
Well great. My first bugfix ends in realizing it's a design issue. :3 |
| 10:44 |
|
jin_xi joined #minetest-dev |
| 10:44 |
cib0 |
Uhm.. I built the project in minetest/dist/ and it put the binary in minetest/bin anyway. >_< |
| 10:46 |
sfan5 |
thats a feature |
| 10:47 |
cib0 |
Is performance a priority btw.? |
| 10:52 |
Calinou |
yes, but not at the cost of features |
| 10:53 |
cib0 |
Of which features? |
| 10:56 |
cib0 |
It's always possible to keep adding features until the thing only runs on a dedicated gaming rig anymore. I don't own one, though. :/ Developing for a game and slowly watching it drift into unplayability on your rig is annoying. |
| 10:58 |
|
n4x joined #minetest-dev |
| 11:03 |
Calinou |
it won't happen probably |
| 11:03 |
Calinou |
the core game will stay relatively lightweight |
| 11:04 |
cib0 |
Nice. |
| 11:05 |
Calinou |
however, people often complain about it (eg. lack of mobs) |
| 11:06 |
cib0 |
Well rendering mobs shouldn't be too much of a problem, and AI and all that stuff can be done in mods/forks. |
| 11:07 |
Calinou |
people want mobs in the core game |
| 11:07 |
Calinou |
they can be done in a lightweight way, but there needs to be a way to easily disable them, in case people want to use mob mods |
| 11:09 |
cib0 |
Yes. |
| 11:09 |
cib0 |
Like me. :P |
| 11:09 |
cib0 |
Though I "want" to do many things I don't have time for. >_< |
| 11:09 |
cib0 |
But wouldn't it be possible to just implement the mob entity similar to node entities, then do everything else in lua? |
| 11:10 |
|
leat joined #minetest-dev |
| 11:12 |
cib0 |
Hm, can't find any more bugs that seem doable for me. |
| 11:12 |
cib0 |
Anyone want me to refactor something? :P |
| 11:13 |
|
ImQ009 joined #minetest-dev |
| 11:13 |
|
fz72 joined #minetest-dev |
| 11:17 |
Calinou |
cib0, look at already-made mob mods |
| 11:17 |
Calinou |
https://forum.minetest.net/viewtopic.php?f=11&t=9656 |
| 11:25 |
|
FR^2 joined #minetest-dev |
| 11:29 |
Zeno` |
<cib0> It's always possible to keep adding features until the thing only runs on a dedicated gaming rig anymore. I don't own one, though. <-- that cannot happen at this point in time |
| 11:29 |
Zeno` |
because the game is CPU limited ;) |
| 11:30 |
cib0 |
Oh. |
| 11:30 |
Zeno` |
it's CPU limited on my i7 |
| 11:31 |
cib0 |
Well the CPU is the strongest part of my system anyway. |
| 11:31 |
Zeno` |
yeah; it's not as bad now (compared to 0.4.10) but there is still a lot of work needed :( |
| 11:32 |
Zeno` |
and none of it particularly trivial |
| 11:32 |
cib0 |
Performance? |
| 11:32 |
Zeno` |
yeah |
| 11:33 |
cib0 |
Hm.. is there some place where we can store custom info about chunks? |
| 11:34 |
cib0 |
What needs to be done for performance? |
| 11:42 |
|
mrtux joined #minetest-dev |
| 11:49 |
|
leat joined #minetest-dev |
| 11:52 |
|
MinerDad joined #minetest-dev |
| 11:53 |
|
MinerDad joined #minetest-dev |
| 11:58 |
cib0 |
So I installed this mob framework.. Now is there some way to debug spawn mobs? |
| 11:58 |
|
leat joined #minetest-dev |
| 11:58 |
|
nore joined #minetest-dev |
| 12:05 |
|
leat joined #minetest-dev |
| 12:10 |
|
n4x joined #minetest-dev |
| 12:12 |
|
exio4 joined #minetest-dev |
| 13:18 |
|
exio4 joined #minetest-dev |
| 13:34 |
|
fz72 joined #minetest-dev |
| 13:42 |
|
fz72 joined #minetest-dev |
| 13:54 |
cib0 |
Dear god so many mob and NPC implementations |
| 13:55 |
cib0 |
I saw a pathfinding cpp file, can that be used for moving mobs? |
| 13:56 |
|
roniz joined #minetest-dev |
| 13:56 |
fz72 |
whois cib0 |
| 13:57 |
Zeno` |
^^ that person |
| 13:57 |
|
leat joined #minetest-dev |
| 13:58 |
cib0 |
I'm the ghost of christmas past or something. |
| 13:58 |
fz72 |
lol |
| 13:58 |
Zeno` |
really? |
| 13:59 |
cib0 |
No. |
| 13:59 |
Zeno` |
Good; I'm scared of ghosts |
| 14:24 |
|
n4x joined #minetest-dev |
| 14:25 |
|
exio4 joined #minetest-dev |
| 14:26 |
cib0 |
... This NPC builder is just floating through the air. |
| 14:26 |
cib0 |
Please stop wasting my time T_T |
| 14:27 |
cib0 |
Let's see if npcf does this any better. |
| 14:29 |
|
T4im joined #minetest-dev |
| 14:29 |
|
deezl joined #minetest-dev |
| 14:47 |
|
shadowzone joined #minetest-dev |
| 15:07 |
|
MinetestForFun joined #minetest-dev |
| 15:20 |
|
shadowzone joined #minetest-dev |
| 15:28 |
|
exio4 joined #minetest-dev |
| 15:30 |
|
kaeza joined #minetest-dev |
| 15:44 |
Megaf |
For fucks sake, can you pelase doing shit and fix memory leaks!? |
| 15:44 |
Megaf |
please* |
| 15:45 |
Megaf |
Stop implemeting new stuff and candy eye and actually fix bugs! |
| 15:45 |
Megaf |
useless people |
| 15:45 |
Megaf |
Being polite, asking nicely and opening issues doenst work with you peple |
| 15:46 |
Megaf |
the bloody client still with huge memory leak |
| 16:11 |
|
n4x joined #minetest-dev |
| 16:15 |
|
jin_xi joined #minetest-dev |
| 16:15 |
|
PilzAdam joined #minetest-dev |
| 16:22 |
|
Calinou joined #minetest-dev |
| 16:31 |
|
exio4 joined #minetest-dev |
| 16:36 |
|
ElectronLibre joined #minetest-dev |
| 16:37 |
|
Brains joined #minetest-dev |
| 16:49 |
fz72 |
PilzAdam: http://bazaar.launchpad.net/~minetestdevs/minetest-c55/packaging/view/head:/rules |
| 16:49 |
fz72 |
this is the file to configure the release build, I think |
| 16:55 |
|
PilzAdam joined #minetest-dev |
| 16:58 |
|
cib0 joined #minetest-dev |
| 17:01 |
|
acerspyro joined #minetest-dev |
| 17:05 |
|
PilzAdam joined #minetest-dev |
| 17:07 |
PilzAdam |
fz72, nothing there says that it's set to "debug"; and it's "release" by default |
| 17:16 |
|
n4x joined #minetest-dev |
| 17:25 |
|
neoascetic joined #minetest-dev |
| 17:34 |
kahrl |
Megaf, thanks for shitting on the work Zeno did when he spent days collecting and analyzing massif data. |
| 17:34 |
kahrl |
Acting entitled like a spoiled little brat will not help your cause. Kthxbye. |
| 17:35 |
|
n4x joined #minetest-dev |
| 17:36 |
Megaf |
kahrl: on the other channel I talked about the impressive work he has done |
| 17:37 |
Megaf |
kahrl: but month after month seeing the same thing... New features, more perfomance and and ever growing resources usage |
| 17:37 |
|
hmmmm joined #minetest-dev |
| 17:59 |
|
johnnyjoy joined #minetest-dev |
| 18:06 |
|
rubenwardy joined #minetest-dev |
| 18:14 |
|
ElectronLibre joined #minetest-dev |
| 18:16 |
|
PilzAdam joined #minetest-dev |
| 18:22 |
|
Krock joined #minetest-dev |
| 18:22 |
|
PilzAdam joined #minetest-dev |
| 18:36 |
|
casimir joined #minetest-dev |
| 18:36 |
|
n4x joined #minetest-dev |
| 19:06 |
rubenwardy |
Can another core developer have a look at this? Rewrite lua_api.txt into Markdown format https://github.com/minetest/minetest/pull/1977 |
| 19:06 |
rubenwardy |
If they agree, it can be rebased and merged. |
| 19:09 |
|
ImQ009 joined #minetest-dev |
| 19:27 |
|
exio4 joined #minetest-dev |
| 19:29 |
rubenwardy |
http://rubenwardy.github.io/minetest_doc/lua_api.html |
| 19:31 |
T4im |
nice :) |
| 19:31 |
Krock |
SN already rebased it |
| 19:31 |
rubenwardy |
To the latest? We just need another core dev to agree. |
| 19:31 |
Krock |
I prefer a new file, lua_api.md |
| 19:32 |
rubenwardy |
That would be better, but first things first |
| 19:32 |
VanessaE |
rewrite it into markdown, but render a plaintext version periodically. |
| 19:32 |
rubenwardy |
VanessaE... |
| 19:32 |
VanessaE |
for us luddites ;) |
| 19:32 |
exio4 |
markdown is easy to read |
| 19:32 |
rubenwardy |
Do you understand how Markdown works? |
| 19:32 |
exio4 |
it isn't intrusive |
| 19:33 |
exio4 |
you can think of it as a just a bunch of conventions (# is title, and * is for lists, and what not) |
| 19:33 |
rubenwardy |
It was almost in markdown before, it just didn't follow exact standards |
| 19:33 |
VanessaE |
rubenwardy: of course I do, but not every program that can read a markdown-encoded textfile will actually interpret the markdown. |
| 19:33 |
rubenwardy |
So? |
| 19:33 |
VanessaE |
so? too much markdown makes the file hard to mentally parse |
| 19:33 |
rubenwardy |
It is designed to be read in plaintext as well |
| 19:33 |
rubenwardy |
It was almost in markdown before, it just didn't follow exact standards |
| 19:33 |
VanessaE |
it's like reading raw HTML versus the rendered page |
| 19:34 |
exio4 |
it isn't |
| 19:34 |
rubenwardy |
it isn't |
| 19:34 |
VanessaE |
well it's the closest analogy I can make |
| 19:34 |
rubenwardy |
https://github.com/minetest/minetest/blob/master/doc/lua_api.txt |
| 19:34 |
VanessaE |
I read through the markdown version. I found it harder to read. |
| 19:34 |
rubenwardy |
That is practically markdown |
| 19:34 |
kahrl |
I agree with VanessaE |
| 19:34 |
kahrl |
especially all those ` everywhere |
| 19:35 |
VanessaE |
kahrl: precisely |
| 19:35 |
hmmmm |
i'm sure it would be easier to read if you were viewing it as a markdown file |
| 19:35 |
Krock |
too bad. I really loved the '^' explanations like https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L1062 and those ugly `..meh. |
| 19:35 |
rubenwardy |
With markdown you don't need to refer to line numbers. |
| 19:35 |
rubenwardy |
Try s/`/ |
| 19:36 |
rubenwardy |
According to stack overflow, you can convert to HTML and then to plain text |
| 19:36 |
VanessaE |
hmmmm: which is exactly the point - it's NOT a markdown file as far as gedit, chromium, or github is concerned. ergo it's plaintext and harder to read. |
| 19:37 |
hmmmm |
:( |
| 19:37 |
rubenwardy |
It should be renamed to .md |
| 19:37 |
rubenwardy |
And renamed to .txt in windows builds |
| 19:38 |
VanessaE |
rubenwardy: perhaps so - that fixes one case (github)/ |
| 19:38 |
VanessaE |
but not the other two |
| 19:38 |
hmmmm |
this is tough |
| 19:38 |
rubenwardy |
Any objections to renaming to .md? It wouldn't break pull requests |
| 19:38 |
hmmmm |
have you guys ever used .rst? |
| 19:38 |
Krock |
nope.avi |
| 19:38 |
VanessaE |
nope. |
| 19:38 |
rubenwardy |
* as formating to markdown already does |
| 19:39 |
hmmmm |
welp |
| 19:39 |
hmmmm |
i don't really have an opinion on this |
| 19:39 |
hmmmm |
it's tough |
| 19:41 |
rubenwardy |
rst looks like markdown, but without all the ` |
| 19:41 |
hmmmm |
the plain text format is already difficult to read |
| 19:41 |
|
exio4 joined #minetest-dev |
| 19:41 |
Krock |
let's do our own documentation style rules. yay! <.< |
| 19:42 |
|
n4x joined #minetest-dev |
| 19:42 |
rubenwardy |
Advantages: linking to a header without worrying about the position of lines changing, output to HTML, standardised. |
| 19:45 |
|
neoascetic joined #minetest-dev |
| 19:53 |
rubenwardy |
You could remove all the `'s. It is the headers and lists and code snippets which are important |
| 19:55 |
rubenwardy |
Added table of contents: http://rubenwardy.github.io/minetest_doc/lua_api.html |
| 19:55 |
rubenwardy |
oops |
| 20:01 |
hmmmm |
i was looking at the pull request and really the `` isn't that distracting |
| 20:04 |
|
neoascetic joined #minetest-dev |
| 20:08 |
rubenwardy |
That's what my opinion i |
| 20:08 |
rubenwardy |
s |
| 20:08 |
rubenwardy |
Even if it isn't renamed to .md, it is still better as I can make an automated script to do this: http://rubenwardy.github.io/minetest_doc/lua_api.html |
| 20:10 |
neoascetic |
Github already have great git-versioned wiki with web-editing abilities. Why something third? |
| 20:15 |
|
Megaf joined #minetest-dev |
| 20:15 |
|
leat joined #minetest-dev |
| 20:16 |
Megaf |
Hi, I deeply apologize for my awful words and behavior about an hour ago. I should never have acted like that here. |
| 20:16 |
Megaf |
I would like to help to track down all memory leak issues but we do need to find a better way of doing that. |
| 20:18 |
Megaf |
And I know that most of, if not all active developers and working to make minetest better and I feel that, it is very very fast and on the server side it's using less resources than ever. |
| 20:18 |
Megaf |
However, on the client side there are something that still making it use up to 2 GB of ram for nothing. |
| 20:19 |
Krock |
2 GB? Are you using 2048px textures? |
| 20:22 |
Megaf |
Krock: default minetest textures |
| 20:23 |
Megaf |
Krock: But I believe that even with 2048x texture that wouldnt explain such a high usage of ram |
| 20:23 |
Krock |
it would. |
| 20:23 |
Krock |
I think you already tried a build from scratch? |
| 20:30 |
Megaf |
Krock: What do you mean? |
| 20:31 |
|
shadowzone joined #minetest-dev |
| 20:32 |
PilzAdam |
hmmmm, https://forum.minetest.net/viewtopic.php?p=166179#p166179 and your opinion is that the code reviews should be removed? |
| 20:38 |
hmmmm |
if they aren't reformed, then yes |
| 20:38 |
PilzAdam |
replied |
| 20:39 |
hmmmm |
Good... because we believe that devices that don't work correctly should be DESTROYED. |
| 20:39 |
hmmmm |
wonder if anybody will get that reference |
| 20:40 |
hmmmm |
without googling |
| 20:50 |
|
cib0 joined #minetest-dev |
| 21:06 |
|
shadowzone joined #minetest-dev |
| 21:12 |
fz72 |
PilzAdam: http://bazaar.launchpad.net/~minetestdevs/minetest-c55/packaging/files, these are the files for building the ppa, right? |
| 21:17 |
|
PilzAdam joined #minetest-dev |
| 21:42 |
VanessaE |
ok |
| 21:42 |
VanessaE |
is it possible for a node's can_dig = function(pos, player) to return nil for the player field? |
| 21:43 |
|
zat joined #minetest-dev |
| 21:47 |
|
exio4 joined #minetest-dev |
| 21:48 |
|
selat joined #minetest-dev |
| 21:49 |
|
jluc joined #minetest-dev |
| 21:52 |
T4im |
VanessaE: minetest.dig_node(pos) calls it with a nil player (stumbled over for #2015) |
| 21:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/2015 -- minetest.dig_node(test_position) does not fail when expected -- always returning true |
| 21:56 |
|
VanessaE_ joined #minetest-dev |
| 21:57 |
|
OldCoder joined #minetest-dev |
| 21:57 |
VanessaE_ |
T4im: that bug is causing signs_lib to crash |
| 21:57 |
|
shadowzone joined #minetest-dev |
| 21:58 |
T4im |
you mean the passing of nil? |
| 21:59 |
|
prozacgod joined #minetest-dev |
| 21:59 |
T4im |
all it needs then is porbably some user to dig a protected node while standing close near it |
| 21:59 |
T4im |
protected sign* |
| 21:59 |
T4im |
bones mod uses that function :/ |
| 22:00 |
T4im |
and unnecessarily :P |
| 22:01 |
VanessaE_ |
signs_lib has a locked sign, which is where that crash is happening, too |
| 22:03 |
T4im |
makes sense :) minetest_game has a pull request fixing that though |
| 22:03 |
T4im |
at least if its caused by bones |
| 22:04 |
VanessaE_ |
probably isn't. |
| 22:04 |
VanessaE_ |
this is code that was working fine in the recent past. |
| 22:04 |
VanessaE_ |
and I don't have bones on the affected server |
| 22:09 |
T4im |
hmm so basicly you can't even worldedit signs away atm? |
| 22:09 |
VanessaE_ |
idk |
| 22:10 |
VanessaE_ |
I don't know how this crash is being triggered, I only saw it via IRC and checked my server's log. |
| 22:19 |
VanessaE_ |
fuck |
| 22:19 |
VanessaE_ |
the whole protection system is crashing |
| 22:20 |
VanessaE_ |
it's just signs_lib catching it is all |
| 22:20 |
VanessaE_ |
17:16:23: ACTION[ServerThread]: bulldog1 tried to dig technic:concrete at protected position (-276,14,826) --> crash |
| 22:22 |
VanessaE_ |
http://pastebin.com/M6YRTR9X |
| 22:22 |
VanessaE_ |
example crash (ignore the "digs display_blocks" line at the top) |
| 22:27 |
VanessaE_ |
and for reference, the code that is somehow being caused to crash: https://github.com/VanessaE/homedecor_modpack/blob/master/signs_lib/init.lua#L808 |
| 22:28 |
VanessaE_ |
nothing special there, this code's been in place for a long while and that particular part hasn't been touched in months |
| 22:34 |
T4im |
I banned that wsd guy latly.. for treating to crash the server |
| 22:35 |
T4im |
after ignoring simply commands like "stop your technic from overflowing" |
| 22:35 |
T4im |
maybe he knows something? ;) |
| 22:38 |
T4im |
def.can_dig(digpos, minetest.get_player_by_name(owner)) hm |
| 22:38 |
T4im |
constructor placed quarry maybe? |
| 22:51 |
|
n4x joined #minetest-dev |
| 23:07 |
|
MinerDad joined #minetest-dev |
| 23:24 |
|
tunczyk_ joined #minetest-dev |
