| Time |
Nick |
Message |
| 00:03 |
|
sloantothebone joined #minetest-dev |
| 00:05 |
|
asl97 joined #minetest-dev |
| 00:15 |
|
Anchakor joined #minetest-dev |
| 00:45 |
|
est31 joined #minetest-dev |
| 01:30 |
|
Routh_ joined #minetest-dev |
| 03:26 |
VanessaE |
Could someone consider adding a feature to let players' name tags "fade away" as the players get further from the viewer? I know (now) that there's a max-transfer-distance setting, but I guess that's an all-or-nothing sort of thing. |
| 03:26 |
VanessaE |
how about making players' names fade gradually according to that setting? |
| 03:29 |
VanessaE |
today my server peaked at 53 users, and players' names are, according to some folks, basically turning parts of the view white because of there being so many in one spot. |
| 03:30 |
TBC_x |
Ideally, when there will be client-side modding all those things could be optional |
| 03:31 |
VanessaE |
perhaps, but that's the sort of thing that needs to operate totally realtime, so it needs to be in-core with a setting, rather than in a mod |
| 04:01 |
|
sloantothebone joined #minetest-dev |
| 05:24 |
|
leat1 joined #minetest-dev |
| 05:28 |
|
RealBadAngel joined #minetest-dev |
| 05:42 |
|
Hunterz joined #minetest-dev |
| 05:58 |
|
zat joined #minetest-dev |
| 06:05 |
|
leat1 joined #minetest-dev |
| 06:26 |
|
leat1 joined #minetest-dev |
| 06:46 |
|
crecca joined #minetest-dev |
| 06:47 |
|
leat1 joined #minetest-dev |
| 06:58 |
|
leat1 joined #minetest-dev |
| 07:04 |
|
Anchakor joined #minetest-dev |
| 07:10 |
|
rubenwardy joined #minetest-dev |
| 07:13 |
|
Darcidride joined #minetest-dev |
| 07:14 |
|
RealBadAngel joined #minetest-dev |
| 07:15 |
RealBadAngel |
crecca, here? |
| 07:17 |
VanessaE |
greetz, RealBadAngel |
| 07:17 |
|
Player_2 joined #minetest-dev |
| 07:18 |
RealBadAngel |
hi Ve |
| 07:19 |
RealBadAngel |
i guess thx to relief mapping code and new normalmaps i will be just shoot down with incoming issues ;) |
| 07:19 |
VanessaE |
don't forget about those other textures |
| 07:19 |
|
jin_xi joined #minetest-dev |
| 07:19 |
VanessaE |
desert stone/cobble/sand/stonebrick |
| 07:20 |
crecca |
RealBadAngel: yes I'm here |
| 07:20 |
RealBadAngel |
crecca, please make a screenshot how it looks like for you |
| 07:21 |
crecca |
ok |
| 07:22 |
|
Player_2 joined #minetest-dev |
| 07:24 |
RealBadAngel |
VanessaE, im making new normals one by one, you have saw yesterday the results |
| 07:24 |
VanessaE |
ok. |
| 07:25 |
RealBadAngel |
theres no script to make them all at one time |
| 07:25 |
RealBadAngel |
i have to try, try and try again ;) |
| 07:26 |
VanessaE |
RealBadAngel: well I meant for example, copy default stone --> desert stone since the texture is the same, only the color is different. |
| 07:26 |
VanessaE |
same for default stone bricks -> desert stone bricks |
| 07:26 |
VanessaE |
and desert vs regular sand |
| 07:26 |
VanessaE |
copy the normals that is. |
| 07:29 |
RealBadAngel |
VanessaE, thats obvious. i just havent made new pr yet |
| 07:30 |
VanessaE |
RealBadAngel: ok, just a reminder is all. |
| 07:30 |
RealBadAngel |
last time you reminded me desert stone i showed you a screenie |
| 07:31 |
RealBadAngel |
https://imgrush.com/Yei7bxNd3Gk1.png |
| 07:31 |
VanessaE |
oh yes, I forgot |
| 07:32 |
VanessaE |
btw that would seem to imply that there's still a view angle error in the parallax code ;) |
| 07:32 |
VanessaE |
(since the two textures with identical parallax info don't quite line up) |
| 07:33 |
RealBadAngel |
they almost do |
| 07:34 |
RealBadAngel |
atm idk what makes the difference |
| 07:36 |
RealBadAngel |
crecca, and? youre painting the screenshot? |
| 07:38 |
|
leat1 joined #minetest-dev |
| 07:39 |
VanessaE |
lol |
| 07:41 |
RealBadAngel |
that could be actually interesting, how folks are percepting what you have done ;) |
| 07:41 |
crecca |
RealBadAngel: it is born in pain |
| 07:41 |
crecca |
http://i.imgur.com/WcUSyBE.png |
| 07:41 |
crecca |
http://i.imgur.com/sJEw25p.png |
| 07:42 |
hmmmm |
oh nice |
| 07:42 |
hmmmm |
i just noticed another nerzhul fuckup |
| 07:42 |
crecca |
it happens only if I have the three options selected: mipmap, bumpmapping, and normalmaps |
| 07:42 |
hmmmm |
god dammit, relying on platform dependent behavior is bad. this is how we got the wstring problem. |
| 07:43 |
|
chchjesus_ joined #minetest-dev |
| 07:43 |
RealBadAngel |
crecca this show actual triangles when rendering |
| 07:44 |
crecca |
yup |
| 07:44 |
RealBadAngel |
crecca, i need to ask you for game backup |
| 07:45 |
RealBadAngel |
without cache |
| 07:45 |
crecca |
what do you mean? |
| 07:45 |
crecca |
you want me to pack it and sand it to you? |
| 07:45 |
RealBadAngel |
but binaries, world used, pos of the scene |
| 07:45 |
RealBadAngel |
and the mods |
| 07:45 |
crecca |
just an executable? |
| 07:45 |
RealBadAngel |
upload it somwhere |
| 07:46 |
RealBadAngel |
all except the media cache |
| 07:46 |
crecca |
I don't have mods |
| 07:46 |
RealBadAngel |
so youre connecting to the server yes? |
| 07:47 |
crecca |
yeah |
| 07:47 |
crecca |
I can recreate in singleplayer |
| 07:47 |
crecca |
if you need |
| 07:48 |
RealBadAngel |
preferably |
| 07:48 |
crecca |
what was the method for saving the map locally? |
| 07:48 |
|
leat1 joined #minetest-dev |
| 07:49 |
RealBadAngel |
makin map local is not the point |
| 07:50 |
RealBadAngel |
what is your platfrom? |
| 07:52 |
RealBadAngel |
i need to go now, please pm me with all the details |
| 07:52 |
crecca |
nvm |
| 07:52 |
RealBadAngel |
game ver, system etc |
| 07:52 |
crecca |
ok |
| 07:52 |
RealBadAngel |
and please upload somwhere your zipped game folder |
| 07:52 |
RealBadAngel |
just without media cache |
| 07:54 |
|
nrzkt joined #minetest-dev |
| 07:54 |
|
Krock joined #minetest-dev |
| 07:58 |
|
leat1 joined #minetest-dev |
| 07:59 |
|
leat1 joined #minetest-dev |
| 08:00 |
|
Yepoleb_ joined #minetest-dev |
| 08:09 |
|
leat1 joined #minetest-dev |
| 08:10 |
|
Calinou joined #minetest-dev |
| 08:11 |
crecca |
#c3dead is the greatest commit number |
| 08:19 |
|
leat1 joined #minetest-dev |
| 08:22 |
Krock |
^^ |
| 08:30 |
|
nore joined #minetest-dev |
| 08:31 |
|
julienrat joined #minetest-dev |
| 08:40 |
|
Amaz joined #minetest-dev |
| 09:11 |
|
leat1 joined #minetest-dev |
| 09:21 |
|
leat1 joined #minetest-dev |
| 09:24 |
|
Taoki[mobile] joined #minetest-dev |
| 09:31 |
|
leat1 joined #minetest-dev |
| 09:42 |
|
leat1 joined #minetest-dev |
| 10:13 |
|
leat1 joined #minetest-dev |
| 10:38 |
|
H-H-H joined #minetest-dev |
| 10:39 |
|
amadin joined #minetest-dev |
| 10:54 |
|
leat1 joined #minetest-dev |
| 10:58 |
|
ra_ joined #minetest-dev |
| 10:59 |
ra_ |
Anybody can help me with this forum.minetest.net/viewtopic.php?f=6&t=12816 ? Server erased map.sqlite size = 0 byte |
| 11:15 |
|
leat1 joined #minetest-dev |
| 11:25 |
|
leat1 joined #minetest-dev |
| 11:30 |
|
Warr1024_ joined #minetest-dev |
| 11:31 |
|
jin_xi_ joined #minetest-dev |
| 11:35 |
|
leat1 joined #minetest-dev |
| 11:37 |
|
kahrl joined #minetest-dev |
| 12:23 |
|
Taoki joined #minetest-dev |
| 14:07 |
|
leat1 joined #minetest-dev |
| 14:20 |
|
FR^2 joined #minetest-dev |
| 14:38 |
|
ExcaliburZero joined #minetest-dev |
| 14:39 |
|
hmmmm joined #minetest-dev |
| 14:41 |
ExcaliburZero |
I'm thinking about trying to make my first change to Minetest. What would be a good way to compile Minetest with the changes I make to the source? |
| 14:48 |
TBC_x |
cd build && cmake .. & make ? |
| 14:49 |
TBC_x |
whoops... cd build && cmake .. && make |
| 14:50 |
ExcaliburZero |
Would that keep the build separate from my previous installation of Minetest (Dev Build)? |
| 14:50 |
ExcaliburZero |
Just want to make suer that I don't mess up the version I play with. |
| 14:51 |
VanessaE |
ExcaliburZero: make clean ; rm -f CMakeCache.txt ; cmake . -DRUN_IN_PLACE=1 -DCMAKE_BUILD_TYPE=Release -DENABLE_FREETYPE=true -DENABLE_LEVELDB=1 ; make -j8 |
| 14:51 |
VanessaE |
that's all you need to do, aside from installing the dependencies, of course. |
| 14:51 |
VanessaE |
and change -j8 to be however many cores you have, plus 1 or 2. |
| 14:52 |
ExcaliburZero |
Thanks! I |
| 14:52 |
VanessaE |
this will compile it and keep it within its' own folder. |
| 14:52 |
VanessaE |
you can just bin/minetest to run it. |
| 14:54 |
ExcaliburZero |
Okay, I'm running the command now. I think I should already have the dependencies install from previous uses of the one line install command from the forums. |
| 14:55 |
ExcaliburZero |
Looks like it worked. Thanks! |
| 14:55 |
VanessaE |
yep, you should be good then |
| 14:55 |
VanessaE |
enjoy :) |
| 15:16 |
|
sloantothebone joined #minetest-dev |
| 15:18 |
Calinou |
make -j$(grep -c "processor" /proc/cpuinfo) |
| 15:19 |
Calinou |
automatic detection |
| 15:34 |
|
twoelk joined #minetest-dev |
| 15:38 |
|
OldCoder joined #minetest-dev |
| 15:39 |
|
leat1 joined #minetest-dev |
| 15:54 |
ExcaliburZero |
So I started working on making my first change to the source and came up with one commit so far (more to come). However, I looked at the commit on GitHub, and it looks like my editor (Atom) removed a extra tab on a "blank" line. Would it be correct to remove such uneeded tabs, or should I set my editor to keep them in? |
| 15:54 |
ExcaliburZero |
https://github.com/ExcaliburZero/minetest/commit/be191625854cbf374cebc459b1c12a0bd5304bca |
| 15:59 |
|
Robert_Zenz joined #minetest-dev |
| 16:07 |
|
twoelk|2 joined #minetest-dev |
| 16:17 |
VanessaE |
two more backtraces added to #2913 |
| 16:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/2913 -- Unexplained, random segfaults and aborts |
| 16:26 |
|
est31 joined #minetest-dev |
| 16:31 |
Calinou |
ExcaliburZero, change settings of whitespace package to not trim whitespace on save |
| 16:32 |
|
Hunterz joined #minetest-dev |
| 16:32 |
hmmmm |
ExcaliburZero, that's not an issue |
| 16:33 |
est31 |
hmmmm, https://github.com/minetest/minetest/pull/2912#discussion_r34642464 |
| 16:33 |
est31 |
+= is fastest for string concatenation according to a test |
| 16:34 |
hmmmm |
no, no, no... nothing is faster than the other, this is all platform independent bullocks |
| 16:34 |
hmmmm |
dependent* |
| 16:34 |
hmmmm |
do things the way which makes the most sense |
| 16:35 |
hmmmm |
if you actually wanted to concatenate strings the fastest way possible, you would not be using C++ |
| 16:35 |
hmmmm |
you'd be using raw pointers and memcpy |
| 16:35 |
est31 |
so why is += discouraged then? |
| 16:35 |
est31 |
or is it not |
| 16:35 |
hmmmm |
it most certainly isn't |
| 16:35 |
hmmmm |
i don't understand who said that or why they'd say such a thing |
| 16:36 |
est31 |
I think I remember you commenting on RBA's PR once but i may be mistaken |
| 16:36 |
hmmmm |
for appending a single character? |
| 16:36 |
est31 |
so its completely ok to write string = string + "text"; then? |
| 16:36 |
hmmmm |
absolutely... |
| 16:37 |
hmmmm |
appending a single character *could* be done with std::string::push_back(), which avoids the need for creating a new string literal and avoids allocating a new std::string |
| 16:38 |
hmmmm |
the problem with RealBadAngel's code was that he always allocated that unnecessary std::string for absolutely no good reason |
| 16:38 |
hmmmm |
but it's not even a problem |
| 16:38 |
hmmmm |
it's just something that isn't 100% optimal |
| 16:40 |
est31 |
hrmm might be a relic of my java past to dislike + |
| 16:40 |
est31 |
= http://stackoverflow.com/a/1532547 |
| 16:46 |
Warr1024_ |
.net definitely and java probably optimize string + operators to use efficient stringbuilder mechanisms where practical, anyway. |
| 16:46 |
Warr1024_ |
don't worry about "slow" code until your profiler confirms that it's a problem. |
| 16:48 |
est31 |
yea, the answers in that thread said it too |
| 16:48 |
est31 |
it optimizes a = a + "hello" + "world"; |
| 16:49 |
est31 |
but for(sometinh){a = a + "*";} isnt optimized |
| 16:49 |
Warr1024_ |
it's also possible that a compiler may leave strings in mutable form until referenced outside of your loop |
| 16:50 |
* twoelk|2 |
just had someone interacting on his none interact server and is confused |
| 16:52 |
est31 |
what are general opinion on #2910 |
| 16:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/2910 -- Treegen: Add enable_unique_ids option by est31 |
| 16:52 |
est31 |
s* |
| 16:53 |
ExcaliburZero |
Sorry, for the slight delay in reply. But should I keep extra whitespace tabs in or remove them? hmmmm noted that it shouldn't be an issue, but Calinou gave me instructions on how to do so, so I'd assume he is telling me to leave the whitespace in. |
| 16:55 |
|
VargaD joined #minetest-dev |
| 16:55 |
hmmmm |
ExcaliburZero: the official policy for a while has been to remove trailing whitespaces when present |
| 16:56 |
ExcaliburZero |
Ok, thanks hmmm! |
| 16:56 |
hmmmm |
keeping that setting enabled gradually cleans the files affected by trailing whitespace problems, and also it makes it easier for contributors to submit code without new whitespace errors |
| 16:57 |
est31 |
RealBadAngel, btw have you fixed your CRLF problem? |
| 16:59 |
est31 |
ExcaliburZero, if we use info.txt we should make a warning that its deprecated |
| 16:59 |
est31 |
Also, commit messages are in present tense |
| 17:00 |
|
Krock joined #minetest-dev |
| 17:03 |
est31 |
VanessaE, the second and third backtraces look more promising than the first one, but I have to look at them more closely |
| 17:05 |
hmmmm |
that being said, string operations do take up a surprising amount of time |
| 17:05 |
hmmmm |
gregorycu optimized an innocent-looking piece of code that recorded the reason why a mapblock was modified to take a char pointer instead of a string reference |
| 17:06 |
hmmmm |
made the function (which was very hot) like 2x as fast |
| 17:06 |
hmmmm |
and then I got rid of the strings completely and made it 6x faster :p |
| 17:06 |
est31 |
heh |
| 17:06 |
ExcaliburZero |
Okay, est31, I'll change the commit description to be past tense. Though how would we handle noting that info.txt is depreciated? |
| 17:07 |
ExcaliburZero |
Also I made a new commit that adds backwards compatibility for "info.txt": |
| 17:07 |
ExcaliburZero |
https://github.com/ExcaliburZero/minetest/commit/a99441dc05aa00ba67ef255fdb444fa56719a7fb |
| 17:07 |
ExcaliburZero |
Still need to change the tense for it though. |
| 17:09 |
est31 |
ExcaliburZero, I would do a if file_exists(infofile) then inside the other if, and there I'd call minetest.log |
| 17:09 |
est31 |
I think there is the method warn( |
| 17:09 |
|
leat1 joined #minetest-dev |
| 17:10 |
ExcaliburZero |
Okay, I'll try that. |
| 17:11 |
est31 |
ok you can't use warn, use minetest.log |
| 17:12 |
est31 |
Tesseract's log pr adds the warn loglevel,once its theree it can be changed |
| 17:12 |
ExcaliburZero |
So something like this: |
| 17:12 |
ExcaliburZero |
if file_exists(infofile) then |
| 17:12 |
ExcaliburZero |
minetest.log("info.txt is depreciated. description.txt should be used instead."); |
| 17:12 |
ExcaliburZero |
end |
| 17:13 |
est31 |
yea |
| 17:16 |
ExcaliburZero |
Okay, how does this commit look? |
| 17:16 |
ExcaliburZero |
https://github.com/ExcaliburZero/minetest/commit/7e8b35e1dcbc9a207b4f0730f16368ce7e0a40be |
| 17:17 |
est31 |
not good |
| 17:17 |
est31 |
the second if is placed wrongly |
| 17:18 |
ExcaliburZero |
How so? |
| 17:18 |
ExcaliburZero |
Sorry, I'm not very used to C++. |
| 17:18 |
est31 |
thats lua |
| 17:19 |
ExcaliburZero |
*facepalm |
| 17:19 |
est31 |
think,, when should we log? |
| 17:19 |
est31 |
we should only log if there is an info.txt file, not if there is a description.txt file |
| 17:19 |
est31 |
also we should not log if there are both files, because texture packs can do that for backwards compat |
| 17:20 |
ExcaliburZero |
Oh, I see the issue. |
| 17:21 |
|
proller joined #minetest-dev |
| 17:22 |
ExcaliburZero |
Okay, I think I've fixed it: |
| 17:22 |
ExcaliburZero |
https://github.com/ExcaliburZero/minetest/commit/70beff89f03f986d9569b81b61d3cd22bf5a05b6 |
| 17:23 |
est31 |
+1 |
| 17:35 |
|
blaise joined #minetest-dev |
| 17:39 |
TBC_x |
are in C++ code any facilities to do debug logging? |
| 17:41 |
|
est31 joined #minetest-dev |
| 17:41 |
est31 |
TBC_x, there is dstream, but thats to be removed |
| 17:42 |
est31 |
I simply print to errorstream |
| 17:42 |
est31 |
errorstream << "message" << std::endl; |
| 17:42 |
est31 |
you have to include log.h |
| 17:42 |
TBC_x |
k, thanks |
| 17:55 |
TBC_x |
I wonder whether the server could use some sort of culling algorithm |
| 17:56 |
TBC_x |
because while I'm waiting at the border, the server still digs up blocks deep underneath |
| 18:00 |
|
leat1 joined #minetest-dev |
| 18:03 |
est31 |
what do people think |
| 18:04 |
est31 |
I want to have blame-ability and attribution (both go hand in hand here) for translations, but otoh, i dont want the "noise" of single line edits from weblate |
| 18:04 |
est31 |
we have multiple options here |
| 18:05 |
est31 |
1. use a separate repository for translations (git submodule or subtree) |
| 18:06 |
est31 |
2. don't have attributions, and have blame-ability by retaining history in local clones |
| 18:07 |
est31 |
3. accept the noise |
| 18:08 |
est31 |
I'm for 1. |
| 18:10 |
Calinou |
I don't know of any project that does 1. |
| 18:10 |
Calinou |
the best translation scheme IMO is to make contributors release their translations as CC0, so attribution is optional |
| 18:11 |
Calinou |
we can do it by hand in the Credits menu |
| 18:12 |
est31 |
so you say 2 with attribution in credits menu? |
| 18:13 |
Calinou |
yes |
| 18:19 |
|
proller joined #minetest-dev |
| 18:34 |
|
stormchaser3000 joined #minetest-dev |
| 18:35 |
Calinou |
is - allowed in subgame names? |
| 18:35 |
Calinou |
(folder) |
| 18:36 |
Calinou |
it works, yes |
| 18:38 |
Calinou |
I plan to close all my minetest_game pull requests in order to maintain a fork of minetest_game |
| 18:38 |
Calinou |
are you OK with it? |
| 18:38 |
Calinou |
https://github.com/minetest/minetest_game/pulls/Calinou |
| 18:38 |
Calinou |
none of those PRs seem to be really popular |
| 18:38 |
Calinou |
(the opened ones) |
| 18:55 |
|
nerzhul_ joined #minetest-dev |
| 18:58 |
|
nrzkt joined #minetest-dev |
| 18:58 |
|
nrz joined #minetest-dev |
| 19:00 |
Calinou |
I found a way to keep those PRs |
| 19:09 |
|
rubenwardy joined #minetest-dev |
| 19:12 |
RealBadAngel |
est31, i believe i dont have any cr-lf here |
| 19:12 |
RealBadAngel |
when i let my editor show whitespaces and eols, i can see only LF |
| 19:13 |
est31 |
ok |
| 19:13 |
rubenwardy |
how can I make a server in a keep-alive loop automatically use gdb and print debug stacks on a problem? |
| 19:13 |
rubenwardy |
ie segfault |
| 19:13 |
RealBadAngel |
maybe its something with my github client |
| 19:13 |
est31 |
VanessaE, ^ |
| 19:14 |
rubenwardy |
debug stacks = trace backs |
| 19:14 |
rubenwardy |
my server crashed twice today, both due to segfaults |
| 19:14 |
est31 |
VanessaE publishes her stacks somewhere |
| 19:14 |
est31 |
lemme see where |
| 19:15 |
est31 |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/Server-scripts/ |
| 19:15 |
est31 |
then look at e.g. minetestserver-vanilla.sh |
| 19:16 |
sfan5 |
that doesn't use gdb though |
| 19:17 |
rubenwardy |
that's actually the script I'm using right now |
| 19:18 |
est31 |
hrmm |
| 19:19 |
RealBadAngel |
est31, so about commits (mine and your) shall i push mine inactive first? |
| 19:19 |
est31 |
yes |
| 19:19 |
est31 |
ok rubenwardy |
| 19:19 |
est31 |
before the /bin/minetestserver line |
| 19:19 |
est31 |
insert gdb -batch -x /home/minetest/Scripts/gdbopts --args \ |
| 19:20 |
RealBadAngel |
ok, will do that in the morning, now im too tired and i have to rebase it thx to paramat's changes to minimal |
| 19:20 |
est31 |
then make /home/minetest/Scripts/gdbopts be |
| 19:20 |
est31 |
run\nthread apply all bt full\nquit |
| 19:21 |
est31 |
ofc with \n expanded to newline |
| 19:23 |
RealBadAngel |
est31, also, after thinkin about #2910 its not worth sacrificing leftover bits for such marginal change |
| 19:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/2910 -- Treegen: Add enable_unique_ids option by est31 |
| 19:24 |
RealBadAngel |
est31, you know what we could have with just one bit of param2? tiles being switcheable from regular to special_tiles |
| 19:24 |
est31 |
perhaps we can remove it again if we actually use it? |
| 19:24 |
RealBadAngel |
and thats way more useable |
| 19:24 |
est31 |
RealBadAngel, we dont sacrifice anything here. we only write it if the nodedef's paramtypes allow it |
| 19:24 |
RealBadAngel |
so for example active/non actice defs could become just one |
| 19:29 |
est31 |
I dont see much merit there |
| 19:30 |
RealBadAngel |
i wast thinkin making params2 MSB being able to switch between tile set |
| 19:30 |
RealBadAngel |
for all the drawtypes |
| 19:30 |
est31 |
whats msb |
| 19:30 |
RealBadAngel |
most significant bit |
| 19:31 |
RealBadAngel |
there should be a PR with that |
| 19:31 |
est31 |
question is however, whats an "active" dirt node? |
| 19:31 |
RealBadAngel |
that was meant for two-state nodes |
| 19:31 |
RealBadAngel |
furnaces, mesecons and the like |
| 19:31 |
est31 |
only very very few nodes can profit from this |
| 19:32 |
est31 |
or technic machines in general |
| 19:32 |
est31 |
i see |
| 19:32 |
est31 |
so they have a custom "activateable" drawtype you mean |
| 19:32 |
est31 |
where you supply a second set of tiles? |
| 19:32 |
RealBadAngel |
look, you have atm furnace active and furnace inactive |
| 19:32 |
RealBadAngel |
and abm to switch them |
| 19:33 |
RealBadAngel |
now if you could just toggle the bit |
| 19:33 |
RealBadAngel |
there are not many furnaces in the worlds, but mesecon wires? |
| 19:34 |
est31 |
ah, ok |
| 19:34 |
RealBadAngel |
updating them would be way faster |
| 19:34 |
est31 |
meh, no |
| 19:34 |
est31 |
you would still have to access the map |
| 19:34 |
est31 |
changing byte or two close bytes is as fast as changing one bit |
| 19:35 |
est31 |
computers are made that way |
| 19:35 |
est31 |
you cant request single bits from the memory |
| 19:35 |
est31 |
its always in words |
| 19:35 |
RealBadAngel |
still, there are doubled nodedefs |
| 19:36 |
est31 |
which drawtypes do you want to change? |
| 19:37 |
RealBadAngel |
i wanted that to be general feature for all the drawtypes |
| 19:37 |
est31 |
no |
| 19:37 |
est31 |
-1 |
| 19:39 |
|
MinetestForFun joined #minetest-dev |
| 19:39 |
est31 |
yes, we do have many nodes which come in pairs, like dirt with grass, dirt without grass or farmland and farmland dry |
| 19:40 |
est31 |
but adding one bit extra for that? the change is too basic imo |
| 19:40 |
RealBadAngel |
i dont meant pairs |
| 19:40 |
RealBadAngel |
look at the furnace and imagine it being single nodedef |
| 19:41 |
est31 |
so you want to add a paramtype then |
| 19:41 |
est31 |
paramtype2 to be precise |
| 19:42 |
RealBadAngel |
one bit of param2, to switch between 2 sets of defined properties |
| 19:42 |
est31 |
or do you want to remove that bit from all future assignments? |
| 19:42 |
RealBadAngel |
we do have 2 sets of tiles by now |
| 19:43 |
RealBadAngel |
we would need for the change to be complete also lightsource value to be switcheable |
| 19:43 |
RealBadAngel |
im not sure |
| 19:43 |
RealBadAngel |
we could discuss what drawtypes could use it |
| 19:44 |
RealBadAngel |
but imho such change is too general, to limit it |
| 19:44 |
est31 |
imho we shouldnt just make it a single bit |
| 19:44 |
est31 |
lets take more bits |
| 19:44 |
est31 |
and make it properly |
| 19:44 |
RealBadAngel |
one bit is exactly the amount needed |
| 19:44 |
est31 |
for your usecase yes |
| 19:45 |
est31 |
but there are many others |
| 19:45 |
est31 |
we had this "metad defined nodedef" thingy |
| 19:45 |
RealBadAngel |
thats something similar but not as advanced |
| 19:45 |
kahrl |
what is the goal here? there isn't any danger of exhausting node ids any time soon, even dreambuilder is far from it |
| 19:45 |
est31 |
my approach to that is that we have a value in param2 or param1, and the mod can provide a function that returns a fake nodedef |
| 19:45 |
RealBadAngel |
this method is way faster |
| 19:46 |
RealBadAngel |
kahrl, number of defs is not the problem |
| 19:46 |
RealBadAngel |
but what it does to the cache? its a serious problem |
| 19:46 |
est31 |
which cache |
| 19:46 |
RealBadAngel |
mesh cache |
| 19:46 |
RealBadAngel |
we do have for example mesecon wires |
| 19:47 |
RealBadAngel |
lotsa of them to represent all possible connections |
| 19:47 |
RealBadAngel |
many of them |
| 19:47 |
est31 |
so add a drawtype for them |
| 19:47 |
RealBadAngel |
and doubled by a fact they can be in on or off state |
| 19:48 |
est31 |
add a drawtype, then you have precisely two mesecon wire nodes: one active, one not active |
| 19:48 |
RealBadAngel |
switching to special_tiles cuts the number by half |
| 19:48 |
RealBadAngel |
even then |
| 19:48 |
RealBadAngel |
when we would need two? just one will be enough |
| 19:48 |
RealBadAngel |
always cut by two |
| 19:52 |
kahrl |
perhaps it would help to have a flag in the nodedef that says "this node only uses the first 4 of the 24 possible facedirs" |
| 19:52 |
kahrl |
that would cut the mesh cache for those nodes by a factor of 6 |
| 19:52 |
|
leat1 joined #minetest-dev |
| 19:52 |
est31 |
well it would be an extra paramtype |
| 19:52 |
est31 |
paramtype2 |
| 19:53 |
kahrl |
I wouldn't introduce a new paramtype2 for that |
| 19:53 |
kahrl |
it would break too much lua code |
| 19:54 |
kahrl |
just add a boolean that says "please only create 4 cached meshes for this guy" |
| 19:54 |
est31 |
in which ways would you see breakage? |
| 19:54 |
kahrl |
(if a node of that type with an out of range param2 occurs, nothing will break, just mesh creation will be a little slower) |
| 19:55 |
kahrl |
every piece of code that works with facedir will have to be updated |
| 19:55 |
kahrl |
simple example: screwdriver |
| 19:55 |
est31 |
and with that extra flag? |
| 19:55 |
kahrl |
see above |
| 19:55 |
est31 |
would it have to be updated then? |
| 19:56 |
kahrl |
it's just an optimization hint for the mesh creation code |
| 19:56 |
est31 |
and if you screwdriver something? |
| 19:57 |
kahrl |
mesh creation will be slower |
| 19:58 |
kahrl |
(although there have been reports that there wasn't that much speed difference between disabled and enabled mesh cache anyway) |
| 19:58 |
est31 |
^ |
| 19:58 |
est31 |
partly mine |
| 19:59 |
* VanessaE |
peeks in |
| 20:00 |
est31 |
from my tests, the mesh cache only has required ram, with not much speedups at all |
| 20:00 |
VanessaE |
totally non-scientific tests on my end say the same. |
| 20:00 |
est31 |
see #2597 for the discussion |
| 20:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/2597 -- Disable mesh cache by default by est31 |
| 20:04 |
|
selat joined #minetest-dev |
| 20:04 |
est31 |
whats the current drawtype of mesecon wires? |
| 20:12 |
VanessaE |
nodebox |
| 20:12 |
VanessaE |
6dfacedir |
| 20:12 |
est31 |
nodebox too |
| 20:12 |
est31 |
who the heck wants to screwdriver mesecon wires |
| 20:12 |
VanessaE |
I've done it :) |
| 20:12 |
VanessaE |
it can sometimes be useful to move a wire up to the ceiling, for example |
| 20:13 |
VanessaE |
rarely anyway |
| 20:14 |
est31 |
I could think of an "additive nodebox" drawtype |
| 20:14 |
est31 |
or "cablelike" |
| 20:14 |
est31 |
there, you specify 7 nodeboxes |
| 20:14 |
est31 |
one that's shown always, and 6 others that are shown depending on whether other "cablelikes" are close to the node |
| 20:15 |
est31 |
perhaps we should add a "cablelike group" parameter, so that it only connects to nodes in that group |
| 20:15 |
VanessaE |
that's what I suggested a while back in fact |
| 20:15 |
VanessaE |
RBA suggested the drawtype, I suggested the multi-part idea |
| 20:16 |
VanessaE |
however, ultimately it would be better to just specify a cable/wire cross-section, and a flag that says if it's in the middle of the node (like a technic cable) or hugging the bottom/sides (like mesecons) |
| 20:17 |
VanessaE |
then let the engine build a suitable mesh |
| 20:17 |
VanessaE |
texture it like you'd texture a nodebox |
| 20:17 |
est31 |
well its like the torchlike discussion i guess |
| 20:17 |
est31 |
and blockmens pr |
| 20:17 |
VanessaE |
true |
| 20:18 |
VanessaE |
however his PR was initially intended to redefine a drawtype, not add a new one |
| 20:19 |
est31 |
well i think its better to be abled to manually specify it |
| 20:23 |
VanessaE |
maybe |
| 20:23 |
VanessaE |
but there would need to be *seven* meshes |
| 20:24 |
est31 |
well the engine still has to create the meshes |
| 20:24 |
est31 |
but we dont have to cache them |
| 20:24 |
VanessaE |
oh ok. I was thinking from the standpoint of one each for the 6 directions, and the 7th would be for that little bump in the middle for the three- and four-way connections |
| 20:24 |
est31 |
also, we can create the meshes from the resulting nodebox on the fly |
| 20:24 |
est31 |
this is inside the implementor's freedom i guess |
| 20:26 |
|
stormchaser3000 joined #minetest-dev |
| 20:30 |
|
stormchaser3000_ joined #minetest-dev |
| 20:31 |
est31 |
the addition of a "special" bit is bad imo |
| 20:33 |
VanessaE |
well what I said mesh in this context, I mean a model, as in a mesh node. |
| 20:33 |
VanessaE |
but it could just as well be nodeboxes |
| 20:33 |
VanessaE |
so long as the engine knows what to do with them |
| 20:39 |
est31 |
what RealBadAngel proposes is entirely novel, never done by minetest since param1 and 2 exist |
| 20:40 |
est31 |
he wants to hardcode the usage of a bit of the nodedef regardless of the paramtype and drawtype and whatsoever |
| 20:40 |
est31 |
thats extremely bad |
| 20:40 |
VanessaE |
yeah I know |
| 20:40 |
est31 |
for example, i have a node in mind, to solve the "homedecor sofa" problem |
| 20:40 |
VanessaE |
I don't like it either because you would need to be able to switch in an entirely different node def |
| 20:41 |
VanessaE |
not just the textures and/or lighting |
| 20:41 |
est31 |
for that node, I would define new paramtypes and paramtype2 |
| 20:42 |
est31 |
i want to store the directional information where the "original" node was in those data |
| 20:45 |
VanessaE |
est31: btw, you have messages waiting in shadowbot on #trepca. |
| 20:47 |
est31 |
VanessaE, doesnt work |
| 20:57 |
|
blaise joined #minetest-dev |
| 21:02 |
est31 |
Calinou, nobody stops you from forking mtgame |
| 21:02 |
est31 |
instead i think new subgames are good |
| 21:10 |
|
EvergreenTree joined #minetest-dev |
| 21:18 |
|
proller joined #minetest-dev |
| 21:34 |
|
OldCoder joined #minetest-dev |
| 21:56 |
|
blaise joined #minetest-dev |
| 21:57 |
|
kilbith joined #minetest-dev |
| 22:14 |
|
est31 joined #minetest-dev |
| 22:15 |
|
blaise joined #minetest-dev |
| 22:28 |
|
blaise joined #minetest-dev |
| 23:03 |
|
blaise joined #minetest-dev |
| 23:11 |
|
stormchaser3000 joined #minetest-dev |
