| Time |
Nick |
Message |
| 00:05 |
VanessaE |
http://forum.minetest.net/viewtopic.php?pid=77032#p77032 |
| 00:05 |
VanessaE |
\o/ |
| 00:08 |
VanessaE |
I need to make a "dyeing" table at some point. |
| 00:08 |
VanessaE |
something that can be used to color objects like unified bricks, colored woods, etc etc |
| 00:08 |
VanessaE |
so I can get these four million nodes out of the inventory :-) |
| 00:09 |
Exio |
and four millions seconds for loading the game |
| 00:50 |
hmmmm |
erm what |
| 00:51 |
hmmmm |
vanessa, the problem with the multi-threaded mapgen is that one thread generating a block doesn't know about that same block's present state when it's being used as a neighboring chunk in another thread, causing solid terrain to be generated on top of a cave in some cases, causing caves to get "walled in" |
| 00:52 |
hmmmm |
ditto with trees and air |
| 00:52 |
hmmmm |
causing trees to get sawed down the middle |
| 00:52 |
hmmmm |
i have an idea of how to fix that completely, but it sucks |
| 00:53 |
VanessaE |
ah, guess I was oversimplifying |
| 00:53 |
VanessaE |
btw, the idea I just had: if overflow from one block to another is the issue, then give each thread every *other* block, never genrate two side by side in separate threads |
| 00:54 |
hmmmm |
lol you can't do that, if you're thinking of a checkerboard pattern of generation you can't do that either, since chunks being generated would still share corners |
| 00:54 |
VanessaE |
so if you have two threads generating a 3x3 area, the center one thread might go to each corner, then when those have finished, one thread to each of the top/bottom/left/right middle ones |
| 00:54 |
VanessaE |
shit. |
| 00:54 |
hmmmm |
yes i know what you mean |
| 00:54 |
hmmmm |
i considered all of that already |
| 00:55 |
VanessaE |
(why didn't I think to say "checkerboard" in the first place?) |
| 00:55 |
VanessaE |
oh well |
| 00:57 |
Exio |
hmmmm: i don't know how the values works for the mapgen_v6_noise and so, but is there any "way" to make it less predictable? |
| 00:58 |
hmmmm |
not really |
| 00:58 |
Exio |
hm k |
| 00:58 |
Exio |
btw, this is what i got from my random-seed-experiment http://exio4.com.ar/_/mt/map.png |
| 00:59 |
hmmmm |
you were expecting something different? |
| 01:00 |
Exio |
yes, chunks more random, because chunksize=1 |
| 01:00 |
|
ecube joined #minetest-dev |
| 01:00 |
Exio |
now that is fixed, no? |
| 01:01 |
hmmmm |
huh? what does chunksize have to do with random |
| 01:01 |
Exio |
how is the size of the chunk defined? |
| 01:01 |
hmmmm |
in the config |
| 01:01 |
Exio |
i mean, how you know the 'chunks' will have that size? |
| 01:01 |
hmmmm |
because that's what i generate |
| 01:02 |
hmmmm |
it's a setting for a reason.. |
| 01:03 |
Exio |
so, if i replaced every thing where you can use 'seed' with 'rand()', why are the "edges of chunks" not 'very near' |
| 01:03 |
Exio |
? |
| 01:04 |
hmmmm |
because of how perlin noise fundamentally works |
| 01:04 |
Exio |
hm, how does it work in that way? |
| 01:04 |
hmmmm |
the only reason why it's as coherent as it is with your experiment is because the seed doesn't change for the entire chunk |
| 01:05 |
hmmmm |
you should probably read up on perlin noise |
| 01:05 |
Exio |
i will |
| 01:22 |
Exio |
i see what you meant with the mapgen |
| 01:22 |
Exio |
the multithreaded stuff ate a whole desert stone wall.. in .. "nothing" |
| 01:24 |
Exio |
and removed the ocean where i was swimming :( |
| 03:17 |
|
loggingbot_ joined #minetest-dev |
| 03:17 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 06:30 |
|
darkrose joined #minetest-dev |
| 07:42 |
|
darkrose joined #minetest-dev |
| 08:57 |
|
darkrose joined #minetest-dev |
| 09:00 |
|
proller joined #minetest-dev |
| 09:14 |
|
kaeza joined #minetest-dev |
| 09:14 |
kaeza |
hi all |
| 09:15 |
kaeza |
would it be possible to add support to control client's FOV from Lua? |
| 09:16 |
kaeza |
I mean, for the server to control client's FOV |
| 09:50 |
|
jin_xi joined #minetest-dev |
| 09:55 |
|
Taoki joined #minetest-dev |
| 10:23 |
|
jin_xi joined #minetest-dev |
| 10:27 |
|
celeron55 joined #minetest-dev |
| 10:31 |
|
serengeor joined #minetest-dev |
| 10:36 |
|
jin_xi joined #minetest-dev |
| 10:49 |
|
PilzAdam joined #minetest-dev |
| 11:05 |
|
darkrose joined #minetest-dev |
| 11:05 |
|
darkrose joined #minetest-dev |
| 12:06 |
|
kaeza1 joined #minetest-dev |
| 12:06 |
|
kaeza1 left #minetest-dev |
| 12:20 |
|
Traxie21|Kindle joined #minetest-dev |
| 12:20 |
Traxie21|Kindle |
Hello |
| 12:44 |
|
Taoki joined #minetest-dev |
| 13:17 |
|
hmmmm joined #minetest-dev |
| 13:28 |
|
celeron55_ joined #minetest-dev |
| 14:12 |
RealBadAngel |
hi all |
| 14:25 |
|
PilzAdam joined #minetest-dev |
| 14:30 |
RealBadAngel |
hmmmm, are you there? |
| 15:06 |
|
iqualfragile joined #minetest-dev |
| 15:09 |
|
serengeor joined #minetest-dev |
| 16:08 |
|
Calinou joined #minetest-dev |
| 16:45 |
|
Exio joined #minetest-dev |
| 16:46 |
|
celeron55 joined #minetest-dev |
| 17:02 |
|
hmmmmm joined #minetest-dev |
| 17:02 |
hmmmmm |
y0 |
| 17:03 |
hmmmmm |
why should the server control the client's FOV? |
| 17:03 |
hmmmmm |
1). i can't see any reason for that, and 2). it'd add yet another network packet |
| 17:10 |
celeron55 |
the answer to why is probably quite simple: to make binocular-like stuff |
| 17:10 |
celeron55 |
which is useless-ish though |
| 17:14 |
VanessaE |
I could see one use for it. |
| 17:14 |
VanessaE |
well, skip that. |
| 17:15 |
VanessaE |
(wouldn't be of much use in practice, not in MT) |
| 17:22 |
serengeor |
#opengl |
| 17:23 |
serengeor |
oops |
| 17:28 |
thexyz |
binocular-like? |
| 17:28 |
thexyz |
i think we can achieve the same with metology hud api |
| 17:29 |
VanessaE |
I thought of quake/openarena's "zoom" (middle mouse) feature when he said that. |
| 17:29 |
hmmmmm |
about that |
| 17:30 |
hmmmmm |
the metology hud conflicts with my plans for the bar api |
| 17:30 |
thexyz |
there's no point in doing that server-side then |
| 17:30 |
thexyz |
hmmmmm: do we really need the bar api then? |
| 17:30 |
hmmmmm |
yes |
| 17:30 |
hmmmmm |
the bar api is much more flexible |
| 17:31 |
thexyz |
how so? |
| 17:31 |
hmmmmm |
read about it on the TODO dev wiki page |
| 17:32 |
thexyz |
so why can't we implement a generic client hud api and then write a simple wrapper for such bar api? |
| 17:34 |
hmmmmm |
look at how overcomplicated it is.... |
| 17:36 |
hmmmmm |
plus, didn't we want lua to not have that sort of power over clients, to draw arbitrary figures? |
| 17:36 |
thexyz |
but it's already done |
| 17:36 |
thexyz |
+statbar~<image>~<amount>~<X>~<Y> |
| 17:36 |
thexyz |
+^ Draw a statbar. |
| 17:36 |
thexyz |
+^ amount is in half-points. |
| 17:37 |
thexyz |
hm.. |
| 17:37 |
thexyz |
well, I didn't want that |
| 17:44 |
|
Calinou joined #minetest-dev |
| 17:51 |
hmmmmm |
woah. so i'm compiling minetest to play on my laptop, and it's taking forever compared to my desktop... my new computer has spoiled me |
| 17:52 |
Exio |
what cpu in the laptop? |
| 17:52 |
hmmmmm |
Sempron SI-42 |
| 17:53 |
VanessaE |
a 486 SX25 ;-) |
| 17:53 |
Exio |
hmmmmm: time it!, it takes 30 minutes in my intel atom n270 |
| 17:56 |
Calinou |
about 20-25 mins on my netbook's N455 :P |
| 17:56 |
Calinou |
40 seconds to 60 seconds on my desktop |
| 17:57 |
Calinou |
(make -j8) |
| 17:57 |
Calinou |
no noticeable difference with make -j9 |
| 17:57 |
VanessaE |
Calinou: fix yer busted-ass circular saw ;) |
| 18:00 |
Exio |
Calinou: with time? |
| 18:00 |
hmmmmm |
omg |
| 18:00 |
hmmmmm |
717.065u 26.304s 13:38.68 90.7%7751+2947k 365+54io 33pf+0w |
| 18:01 |
hmmmmm |
also it seems like it compiled the same stuff twice |
| 18:01 |
VanessaE |
gah, posted that on the wrong channel, sorry. |
| 18:27 |
|
proller joined #minetest-dev |
| 18:32 |
PilzAdam |
I added some labels to the issue tracker of the engine |
| 18:40 |
Exio |
:D thanks |
| 19:02 |
proller |
50+% external mobs crashes server at random time |
| 19:03 |
proller |
maybe report lua error to log and continue working? |
| 19:13 |
|
khonkhortisan joined #minetest-dev |
| 20:10 |
|
sapier joined #minetest-dev |
| 20:28 |
|
jin_xi joined #minetest-dev |
| 20:33 |
|
jin_xi joined #minetest-dev |
| 20:56 |
|
sapier1 joined #minetest-dev |
| 21:02 |
celeron55 |
hmmmm: that is why everyone should seriously aim to keep header bloat as minimal as possible 8) |
| 21:04 |
celeron55 |
and use interface classes for things, as those are very good at making sure a single change won't recompile half of things |
| 21:05 |
celeron55 |
(well, that was already included in the first statement; *goes away*) |
| 21:23 |
|
ecube joined #minetest-dev |
| 21:28 |
|
ecube_ joined #minetest-dev |
| 21:36 |
hmmmm |
but, at the cost of needing a vtable, adding another layer of indirection, which is less efficient |
| 21:36 |
hmmmm |
at runtime |
| 21:38 |
sapier1 |
vtable dereferencing is quite fast as far as I know only rtti is performance critical |
| 21:38 |
|
iqualfragile1 joined #minetest-dev |
| 21:39 |
sapier1 |
vtable usage might even be optimized by compiler |
| 21:40 |
sapier1 |
btw I've just assembler debugged vtable usage for two days ;-) but of course compiler may not always be able to optimize that good |
| 22:10 |
|
proller joined #minetest-dev |
| 22:12 |
proller |
initial float islands - https://github.com/minetest/minetest/pull/555 |
| 22:37 |
|
iqualfragile joined #minetest-dev |
| 22:43 |
thexyz |
Land Up, Canyon & Chasm ported in core would be great too |
| 22:44 |
PilzAdam |
thexyz, maybe there is a bug caused by stl that breaks nick completion |
| 22:44 |
PilzAdam |
need to research |
| 22:44 |
sapier1 |
yes ... imho we need to make core more modular in order to improove maintenance for things like that |
| 22:44 |
thexyz |
PilzAdam: seems so |
| 22:45 |
VanessaE |
nick completion? in minetest? |
| 22:45 |
thexyz |
wow! |
| 22:45 |
thexyz |
so, nothing is broken |
| 22:45 |
thexyz |
as no one used it |
| 22:46 |
|
Taoki joined #minetest-dev |
| 22:46 |
PilzAdam |
it only works for my own nick |
| 22:47 |
|
Guest88189 joined #minetest-dev |
| 22:47 |
VanessaE |
what's the completion key? tab? |
| 22:47 |
thexyz |
PilzAdam: it doesn't work at e204bedf1d781e43b8caa334a99319efc5b7ce46 either |
| 22:47 |
sapier1 |
wait you mean list of all logged in players is transfered to any client no matter if client needs to know or not? |
| 22:47 |
VanessaE |
ah no wonder I never used it, it only works in the F10 screen, not in the 't' tialog. |
| 22:47 |
VanessaE |
dialog* |
| 22:48 |
thexyz |
sapier1: yes? /status ? |
| 22:48 |
thexyz |
hm, compiling minetest while updating @world is not fun |
| 22:48 |
thexyz |
should probably get hexacore |
| 22:49 |
sapier1 |
puuhhh I don't like the idea someone can write a simple client creating a login profile of any player |
| 22:49 |
Exio |
hahaha |
| 22:49 |
Exio |
poor computer |
| 22:49 |
Exio |
thexyz: what cpu atm? |
| 22:50 |
thexyz |
Exio: i5-2400 |
| 22:50 |
thexyz |
sapier1: hmm? |
| 22:50 |
thexyz |
i didn't get it |
| 22:50 |
proller |
seems landup possible with mapgen params now - change scale |
| 22:50 |
Exio |
ah |
| 22:51 |
proller |
and already in indev mapgen far mountains higher |
| 22:51 |
sapier1 |
I wasn't aware of minetest yelling out my presence to everyone ;-) |
| 22:52 |
sapier1 |
in most mmos for example you can talk to everyone of course (at least if you know the name) but you only see online status of your friends |
| 22:52 |
thexyz |
sapier1: well, it's quite obvious |
| 22:52 |
thexyz |
I doubt minetest can be counted as MMO |
| 22:52 |
thexyz |
PilzAdam: was this feature ever working? |
| 22:52 |
PilzAdam |
dunno |
| 22:53 |
sapier1 |
so minetest assumes all players in a game are friends ... hmm while this might be a possible interpretation I suggest thinking about changing this behaviour if minetest servers start to get more players ;) |
| 23:27 |
proller |
PilzAdam, fixed initial size, coal+iron at minimal, minimum height |
| 23:27 |
thexyz |
PilzAdam: so, the issue with tab completing is related to Environment |
| 23:28 |
thexyz |
as in non-local game it only knows about local player |
| 23:28 |
thexyz |
and tab completion code calls its getConnectedPlayers() method |
| 23:28 |
thexyz |
which, obviously, returns only the local player |
| 23:30 |
thexyz |
i wonder what's the right way to fix it |
| 23:31 |
sapier1 |
:-) I suggest not fixing it at all but I assume this is only my opinion ;-) |
| 23:31 |
thexyz |
why? |
| 23:31 |
sapier1 |
for privacy reasons |
| 23:32 |
thexyz |
what privacy reasons? |
| 23:32 |
thexyz |
it's not like /status doesn't work anymore |
| 23:32 |
thexyz |
so your argument is invalid |
| 23:32 |
sapier1 |
ok then it's useless :-( |
| 23:32 |
thexyz |
oh, also, today /status showed 2 "unknown" guys |
| 23:32 |
thexyz |
what is useless? |
| 23:33 |
sapier1 |
useless not to fix it if there's another way to get that information |
| 23:33 |
thexyz |
yes, for example, you may as well look around to see other players' names |
| 23:33 |
proller |
PilzAdam, commit please https://github.com/minetest/minetest/pull/555 - its in dev mapgen, change in minimal game will not affect current mapgen, later will make better no-edge way |
| 23:34 |
sapier1 |
yes but it's a difference if you see all players at once or get a well formated guaranteed to be complete list ;-) |
| 23:34 |
PilzAdam |
proller, I would prefer that hmmmm looks over it first |
| 23:34 |
sapier1 |
-or + and |
| 23:34 |
proller |
PilzAdam, ok |
| 23:35 |
proller |
hmmmm, https://github.com/minetest/minetest/pull/555/ |
| 23:45 |
thexyz |
hmmmm: http://forum.minetest.net/viewtopic.php?id=5188 |
| 23:45 |
thexyz |
(you may be interested i think) |
| 23:48 |
PilzAdam |
celeron55, Id like to hear what you think: http://forum.minetest.net/viewtopic.php?pid=77359#p77359 |
| 23:57 |
hmmmm |
the only thing that could be computed with a GPU is the perlin noise, and the benefit would only be great enough if you're generating the entire world at once |
