| Time |
Nick |
Message |
| 00:16 |
|
VargaD_ joined #minetest-dev |
| 00:39 |
VanessaE |
although GPU time is more precious, remember too that there are things a GPU can do that a CPU might be 100x slower at doing. |
| 00:39 |
VanessaE |
better to spend GPU cycles if the result is faster and doesn't hinder the ability to use the GPU for other things |
| 01:17 |
|
domtron joined #minetest-dev |
| 02:24 |
|
domtron left #minetest-dev |
| 02:56 |
RealBadAngel |
VanessaE, finalColorBlend is implemented both sides |
| 02:57 |
VanessaE |
I was speaking in general terms. |
| 02:58 |
VanessaE |
however in this case, which one is faster/ |
| 02:58 |
VanessaE |
? |
| 02:58 |
RealBadAngel |
and i think CPU's one is faster, mainly because its called once, when ratio changes |
| 02:58 |
VanessaE |
then do it in the CPU, by all means. |
| 02:58 |
RealBadAngel |
while on GPU each render pass |
| 05:43 |
|
Hunterz joined #minetest-dev |
| 07:00 |
|
NakedFury joined #minetest-dev |
| 08:21 |
|
Calinou joined #minetest-dev |
| 08:35 |
|
asl joined #minetest-dev |
| 09:16 |
|
Megaf joined #minetest-dev |
| 09:19 |
|
jin_xi joined #minetest-dev |
| 09:27 |
|
nore joined #minetest-dev |
| 09:32 |
|
Amaz joined #minetest-dev |
| 09:34 |
|
proller joined #minetest-dev |
| 09:56 |
|
PenguinDad joined #minetest-dev |
| 09:59 |
|
iqualfragile joined #minetest-dev |
| 10:37 |
|
Jordach joined #minetest-dev |
| 11:05 |
|
proller joined #minetest-dev |
| 11:21 |
|
casimir joined #minetest-dev |
| 11:27 |
|
Megaf joined #minetest-dev |
| 12:01 |
|
ImQ009 joined #minetest-dev |
| 12:30 |
|
proller joined #minetest-dev |
| 12:32 |
|
Amaz joined #minetest-dev |
| 12:33 |
|
casimir joined #minetest-dev |
| 12:51 |
|
PilzAdam joined #minetest-dev |
| 13:02 |
|
hmmmm joined #minetest-dev |
| 13:15 |
|
VanessaE_ joined #minetest-dev |
| 13:56 |
|
Zeitgeist_ joined #minetest-dev |
| 14:21 |
|
Amaz joined #minetest-dev |
| 14:35 |
|
eugd joined #minetest-dev |
| 14:44 |
|
domtron joined #minetest-dev |
| 14:46 |
|
domtron left #minetest-dev |
| 14:52 |
|
NakedFury joined #minetest-dev |
| 14:58 |
|
Calinou joined #minetest-dev |
| 15:12 |
|
Hunterz joined #minetest-dev |
| 15:26 |
|
proller joined #minetest-dev |
| 15:36 |
nore |
sfan5, BlockMen: what about improving ore generation in minetest_game, using the noise_threshhold option (so the ores don't spawn everywhere, you have to find an ore mine) to make mining more interesting? |
| 15:37 |
sfan5 |
sounds interesting |
| 15:51 |
Sokomine |
i'm not sure if that's such a good idea. it might work on servers where there's much traffic and lots of players for trading. in general, the "everything is everywhere" approach works quite well |
| 15:53 |
nore |
well, the scale should not be too high |
| 15:53 |
nore |
perhaps 100 nodes |
| 16:01 |
|
alexxs joined #minetest-dev |
| 16:17 |
nore |
sfan5, http://nore.mesecons.net/screenshot_3665078645.png |
| 16:17 |
nore |
(made the ores generate in air for testing) |
| 16:18 |
nore |
thoughts? |
| 16:19 |
proller |
COMMIT! |
| 16:23 |
VanessaE_ |
nore: holy moses |
| 16:23 |
nore |
hm? |
| 16:23 |
VanessaE_ |
that's a bit too scattered imho |
| 16:24 |
VanessaE_ |
make the groups larger, and more spread apart |
| 16:24 |
VanessaE_ |
or wait |
| 16:24 |
VanessaE_ |
that's the default pattern isn't it |
| 16:24 |
nore |
it's the default (but more dense) where the noise is high enough |
| 16:24 |
VanessaE_ |
hm |
| 16:25 |
nore |
for mese, you'll have to find an area where it spawns, and then search around it |
| 16:25 |
VanessaE_ |
I stand by my previous statement then :)_ |
| 16:26 |
nore |
for ores such as coal or iron, once you've found an area, there are a lot of other ones around |
| 16:26 |
VanessaE_ |
raise the threshold and make the spawning more dense - so that the ores group together more. create more dead zones between ores |
| 16:27 |
nore |
it is there: https://github.com/Novatux/minetest_game/tree/new_ore_gen |
| 16:27 |
nore |
^ no, that's a problem |
| 16:27 |
nore |
it becomes too easy to get a lot of ores when you've found an area |
| 16:28 |
VanessaE_ |
well just raise the threshold then and keep the density the same |
| 16:28 |
nore |
of which ones? |
| 16:28 |
VanessaE_ |
just iron and coal, by the look of it. |
| 16:28 |
nore |
actually, in the screenshot, there is a *huge* area without ores |
| 16:28 |
VanessaE_ |
or is that copper on the left? |
| 16:28 |
VanessaE_ |
I can't tell |
| 16:28 |
nore |
copper |
| 16:29 |
VanessaE_ |
oh ok |
| 16:29 |
VanessaE_ |
from this screenshot it's kinda hard to tell what's where |
| 16:29 |
VanessaE_ |
the mese and diamond look about right though |
| 16:29 |
nore |
well, I see no iron in it |
| 16:29 |
VanessaE_ |
maybe a bit more dense on diamond, if what's there is average |
| 16:29 |
nore |
it's hard to get all the ores at once |
| 16:30 |
nore |
there's some gold on the left |
| 16:30 |
VanessaE_ |
I see it. |
| 16:30 |
nore |
ah, and iron too |
| 16:30 |
VanessaE_ |
american cheese ore. |
| 16:31 |
nore |
well, you can try it if you want |
| 16:31 |
VanessaE_ |
naw |
| 16:31 |
VanessaE_ |
I'll leave it in your capable hands |
| 16:31 |
nore |
problem of screenshots like that is that it is difficult to see how hard it is to get those ores when they're in stone |
| 16:32 |
eugd |
now how about tying this to biomes? |
| 16:33 |
nore |
hm.. not all mapgens support biome |
| 16:35 |
nore |
btw: the iron/copper/coal may look close, but it's still not trivial to find them when you've got one |
| 16:36 |
nore |
and for other ores it's more like giving you some vague hint about where to dig |
| 16:37 |
|
Krock joined #minetest-dev |
| 16:39 |
nore |
there, #301 |
| 16:43 |
VanessaE_ |
https://github.com/VanessaE/dreambuilder_game/commit/1a76e272727de63a2f4237fb438f52925b3b234d :-) |
| 16:43 |
nore |
:) |
| 16:43 |
|
rubenwardy joined #minetest-dev |
| 16:43 |
|
Miner_48er joined #minetest-dev |
| 16:45 |
|
khonkhortisan joined #minetest-dev |
| 16:54 |
|
OldCoder joined #minetest-dev |
| 17:02 |
|
sapier joined #minetest-dev |
| 17:07 |
sapier |
anyone to comment this http://dev.minetest.net/Lua_code_style_guidelines? |
| 17:11 |
Calinou |
in before this violates every single of my own guideline |
| 17:11 |
rubenwardy |
It looks okay |
| 17:11 |
Calinou |
foo({baz=true}) |
| 17:11 |
Calinou |
ugly |
| 17:12 |
Calinou |
foo({baz = true}) |
| 17:12 |
Calinou |
is way better |
| 17:12 |
rubenwardy |
^ +! |
| 17:12 |
rubenwardy |
* +1 |
| 17:12 |
VanessaE_ |
wtf? |
| 17:12 |
sapier |
that's allowed by the guidelines ... but it's not written very obvious ... I interpreted it wrong too |
| 17:12 |
VanessaE_ |
what's with all the ^^^---- ------vvv crap? |
| 17:12 |
sapier |
those are my comments |
| 17:13 |
sapier |
wiki isn't a good env to do discussions |
| 17:13 |
Calinou |
someone who didn't learn wikicode |
| 17:13 |
Calinou |
there's a talk page. |
| 17:13 |
rubenwardy |
But you said comments should be done with -- <space> Capital |
| 17:13 |
Calinou |
-- This is how I write comments, as full sentences. |
| 17:13 |
rubenwardy |
also <!-- --> works in wikis |
| 17:13 |
Calinou |
lots of people hate on this, but it makes the most sense |
| 17:13 |
Calinou |
rubenwardy, any HTML does ;) |
| 17:13 |
sapier |
yes but talk pages are not WITHIN the page but separate ... for reviewing that's quite silly |
| 17:15 |
sapier |
it's temporary to mark thinks I consider to be at least questionable |
| 17:15 |
Calinou |
use italic text? |
| 17:16 |
sapier |
and how to mark the part I'm talking about? |
| 17:16 |
rubenwardy |
~~!~~ LOOK TO THE PLACE THE IS ABOVE THIS TEXT ~~!~~ |
| 17:16 |
Calinou |
↑ ↓ |
| 17:17 |
Calinou |
↙↓↘â†â†”→↖↑↗↕↔ full set :D |
| 17:17 |
sapier |
and what's the difference to the ^^^markers? ;-) |
| 17:17 |
VanessaE_ |
what, no four-way arrow? ;) |
| 17:18 |
sapier |
well I tried italic right now ... the difference is almost non existent on my font ... wiki is just wrong tool for doing reviews :) |
| 17:19 |
sapier |
I suggest discussion those things fast to be able to remove the markers quick ;) |
| 17:19 |
Calinou |
they look proper |
| 17:19 |
Calinou |
v is a letter, ^ is exponent |
| 17:20 |
sapier |
do we need to write a style guide to define how do discuss about style guides first ? |
| 17:24 |
sapier |
well some things actually aren't even worth discussing as this is minetest core styleguide and minetest does support lua 5.1 as base version only there ain't any discussion about 5.2 functions |
| 17:24 |
sapier |
at least until minetest upgrades to 5.2 |
| 17:27 |
sapier |
>>Don't compare values explicitly to true, false, or nil, unless it's really needed.<< either disallow it or skip unspecific rules like that one at all |
| 17:28 |
sapier |
especially as that specific example is plain wrong, comparing for nil instead of false IS a valid check |
| 17:42 |
|
AnotherBrick joined #minetest-dev |
| 17:44 |
|
kahrl joined #minetest-dev |
| 17:46 |
|
kaeza joined #minetest-dev |
| 17:47 |
sapier |
http://dev.minetest.net/Lua_code_style_guidelines do you feel better this way of commenting? ;-) |
| 17:50 |
Krock |
yay! guidelines |
| 17:50 |
PenguinDad |
I'm not too sure about the hh############################################################# lines |
| 17:51 |
sapier |
they're gonna be removed once it's no longer a draft ;-) |
| 17:54 |
celeron55 |
can someone explain what all those ^------- things are |
| 17:54 |
sapier |
comments ? |
| 17:54 |
celeron55 |
why don't they have any mention about who made the comments |
| 17:55 |
sfan5 |
maybe we should use an etherpad like we used it for minetest.features |
| 17:59 |
celeron55 |
a wiki is fine for commenting on things, as long as people comment so that the comments are organized properly (for example, they should contain the name of the author of the comment) |
| 18:00 |
sapier |
it's not even close to as comforable as commenting code on github ;) |
| 18:01 |
sapier |
but I fixed my comments anyway |
| 18:03 |
kahrl |
"Paranthesis always improve readability a lot" ok, let's write mods in lisp :P |
| 18:04 |
sfan5 |
:P |
| 18:04 |
sapier |
https://github.com/minetest/minetest/pull/1557 can someone test this? I know modders don't like to be told "your mod consumes way to much time per step" but it's gonna help a lot |
| 18:04 |
sapier |
well kahrl I wrote my comments mimicrying level of coding style |
| 18:05 |
sapier |
somehow right but completely wrong for some other things ;-) |
| 18:05 |
kahrl |
heh |
| 18:06 |
sapier |
yet most of the guidelines are fine except thos parts ShadowNinja wrote to have something to complain about ;) |
| 18:07 |
|
swaaws joined #minetest-dev |
| 18:18 |
Krock |
Ehm.. the serverlist hasn't been fixed yet. is it going to happen client- or serverside? |
| 18:18 |
Krock |
(talking about *CDP display) |
| 18:27 |
kahrl |
Krock: issue #? |
| 18:28 |
Krock |
kahrl, pull of 1 month ago (feeling) |
| 18:28 |
Krock |
+request |
| 18:29 |
Krock |
ah right. I needed to find someone who agrees that merge |
| 18:29 |
VanessaE_ |
https://github.com/minetest/minetest/pull/1480 |
| 18:29 |
VanessaE_ |
kahrl: ^^^^ |
| 18:30 |
sapier |
krock why didn't you squash it? |
| 18:30 |
kahrl |
sapier: eh, the one who merges it can squash it |
| 18:31 |
Krock |
and I can't merge.. |
| 18:32 |
sapier |
of course... as the one who merges it can do the code style fixing the bug fixing ... code writing ... but yes in this special case it's not a lot of work |
| 18:32 |
kahrl |
what I find more problematic is that 1. the C++ side passes parsed json to lua unchecked (not problematic in itself) and 2. the lua side doesn't do any checks at all |
| 18:33 |
sapier |
nice to know I already mentioned that and I have been punched for this opinion |
| 18:34 |
kahrl |
have you? |
| 18:34 |
Krock |
well, if the client can not use it, it will ignore it.. |
| 18:34 |
sapier |
discussion? ;-) |
| 18:35 |
kahrl |
sapier: I don't see it |
| 18:35 |
sapier |
"not sure if it's a problem or an additional feature but this code would cause ANY element sent to be transfered to lua not those we support only" |
| 18:36 |
kahrl |
sapier: yeah I saw that, but I didn't see anyone bashing you for it |
| 18:36 |
sapier |
well that's been here in minetest-dev |
| 18:37 |
sapier |
still I stay at my position so at least I will not agree to it ... so whoever merges it needs two other agreements |
| 18:38 |
kahrl |
I would agree to b761d2d at least |
| 18:39 |
kahrl |
the rest I only agree to if the lua side validates the data |
| 18:39 |
sapier |
lua side validating data still violates rule to catch errors and undefined behaviour as soon as possible |
| 18:40 |
sapier |
if there's some malicious data in server list response passing it to lua opens up another huge part of software containing errors that can be exploited |
| 18:41 |
sapier |
that's why I don't agree to just pass everything |
| 18:43 |
kahrl |
so let's merge b761d2d? |
| 18:44 |
sapier |
b761d2d seems to be fine for me too |
| 18:45 |
kahrl |
I'll merge it in an hour then |
| 18:49 |
Krock |
fine. |
| 18:54 |
kahrl |
btw: this would've been far harder had the commits already been squashed :P |
| 18:55 |
sapier |
well if you want it that way I can stop squashing all of my pulls ;-P |
| 18:55 |
kahrl |
:P |
| 18:57 |
kahrl |
well what I mean is, squash commits that belong to the same change, but don't squash commits that do different things |
| 18:57 |
kahrl |
fixing the *CDP display and switching to push_json_value are different things |
| 18:57 |
sapier |
if course but whatever was changed in the commit you're gonna merge was reverted by later changes |
| 18:58 |
kahrl |
true |
| 18:58 |
sapier |
in this case it's actually history not different things ... for this special case history is good ... usually I don't wanna have the early experimental attempts ;-) |
| 18:59 |
kahrl |
I guess the way to go is: if you see devs fighting over a later change, don't squash those later changes with earlier changes |
| 19:00 |
|
rubenwardy left #minetest-dev |
| 19:01 |
sapier |
yes but I guess we won't have something similar to this case soon ;-) |
| 19:01 |
kahrl |
no fighting between devs? you sure? |
| 19:01 |
sapier |
that part is permanent ;-P |
| 19:01 |
sapier |
the previous and later changes thing ;-) |
| 19:02 |
kahrl |
yeah |
| 19:02 |
sapier |
btw who feels responsible for modstore? |
| 19:02 |
kahrl |
though it happens from time to time |
| 19:02 |
sapier |
to be more precise mmdb |
| 19:02 |
kahrl |
not me :P |
| 19:02 |
sapier |
seems like it's broken atm |
| 19:03 |
Calinou |
fixing weblate is more important |
| 19:04 |
sapier |
both is important |
| 19:04 |
sapier |
while mmdb results in direct user experience |
| 19:05 |
sapier |
maybe we should replace it by some sort of linklist in minetest github repository combined with a github interface |
| 19:06 |
sapier |
mod list containing links on minetest and some sort of description to be placed in the mods own github repository (or any other git repository) .. or other vcs if someone implements the interface |
| 19:07 |
|
ImQ009 joined #minetest-dev |
| 19:07 |
|
casimir joined #minetest-dev |
| 19:25 |
sapier |
https://gist.github.com/sapier/3b6b8327d1fefadd72cc Any comment to implementing mod store this way? |
| 19:26 |
Krock |
sapier, how about a forum link? |
| 19:27 |
sapier |
type forum would be ok too but it's way more hard to parse a forum post then download files from some webfrontend |
| 19:27 |
* Krock |
likes that idea |
| 19:28 |
sapier |
well I'll not implement the forum thingy as I believe it not to be any more reliable then current variant |
| 19:28 |
sapier |
but as there's a type in my specification the design is open for it |
| 19:31 |
kahrl |
sapier: what about mods with rolling release? |
| 19:31 |
kahrl |
i.e. no version numbers |
| 19:32 |
sapier |
special "tag" "LATEST"? |
| 19:32 |
kahrl |
could work |
| 19:32 |
kahrl |
or HEAD to keep with git terminology |
| 19:32 |
sapier |
yes |
| 19:33 |
sapier |
we couln't do voting ... but that feature didn't even work by now so not a big loss |
| 19:34 |
eugd |
do mapsectors have metadata? |
| 19:34 |
sapier |
the only bad thing would be as it's lua code we'd rely on content beeing correct and can't verify content in c++ easyly |
| 19:35 |
eugd |
i see functions referencing that, but also comments that it's depreciated? |
| 19:35 |
|
jin_xi joined #minetest-dev |
| 19:35 |
sapier |
can you provide an example? |
| 19:35 |
eugd |
looking in map.cpp and map.h |
| 19:35 |
eugd |
map.cpp has functions dealing with mapsector meta |
| 19:36 |
eugd |
and map.h mentions the possible depreciation |
| 19:36 |
kahrl |
sapier: if you remove the "return" and replace = with : it'd be json |
| 19:36 |
* kahrl |
hides |
| 19:37 |
sapier |
as we already have a json parser that be a possibility ... yet the other way would be way more easy |
| 19:38 |
sapier |
the only difference to serverlist is modlist isn't automatically loaded each logon ... not sure if this is enough to allow direct passing to lua |
| 19:38 |
sapier |
-logon +start |
| 19:39 |
kahrl |
wait, where are these file stored and who executes them when? |
| 19:40 |
kahrl |
files* |
| 19:40 |
sapier |
first one in some repository on minetest github account |
| 19:40 |
sapier |
last one within the mod itself |
| 19:41 |
kahrl |
I don't think downloading lua code and executing it (before you accept to download a mod) is a great idea |
| 19:41 |
sapier |
eugd seems to be almost completely dead code, the only thing written to metadata is a version number |
| 19:42 |
sapier |
kahrl: you're right |
| 19:42 |
sapier |
so json |
| 19:42 |
sapier |
uargh |
| 19:42 |
kahrl |
hehe |
| 19:43 |
kahrl |
we could hack libjson to parse lua table syntax (without executing it as lua) instead ;) |
| 19:50 |
sapier |
https://gist.github.com/sapier/3b6b8327d1fefadd72cc vetter? |
| 19:51 |
kahrl |
sapier: looks good |
| 19:51 |
kahrl |
oh, line 5 needs updating |
| 19:52 |
sapier |
done .. I'm not sure if last one is correct json anyway but it's good enough to show how it's intended |
| 19:52 |
kahrl |
yeah |
| 19:53 |
kahrl |
sapier: hmm, there could be one problem |
| 19:53 |
sapier |
yes? |
| 19:53 |
kahrl |
validated_versions lists tags but any modder could force push to replace the tags |
| 19:53 |
kahrl |
maybe list the corresponding commit hashes as well? |
| 19:54 |
sapier |
would limit us to github ... maybe md5/sha sums? |
| 19:54 |
sapier |
of zip file |
| 19:54 |
kahrl |
yeah I was about to suggest that |
| 19:56 |
sapier |
I'd suggest support of md5 and sha256 |
| 19:56 |
kahrl |
even just sha256 |
| 19:56 |
|
Megaf joined #minetest-dev |
| 19:56 |
kahrl |
md5 shouldn't really be used anymore |
| 19:56 |
Megaf |
why not? |
| 19:57 |
sapier |
hmm guess current hw will be fast enough but we'd need to implement it ourselfs |
| 19:57 |
Megaf |
its so good to check file integrity |
| 19:57 |
Megaf |
but it is slow |
| 19:57 |
kahrl |
Megaf: there have been a number of attacks |
| 19:58 |
sapier |
yes kahrl but I'd guess we remove a mallicious mod from our list too |
| 19:58 |
kahrl |
the first one in 1996 |
| 19:58 |
|
cg72 joined #minetest-dev |
| 19:58 |
kahrl |
sapier: still, no reason to use an outdated hash algorithm |
| 19:58 |
sapier |
well md5 is easy to implement sha256 too? |
| 19:59 |
sapier |
we're not writing high security code ;-) |
| 19:59 |
kahrl |
I guess there are premade implementation |
| 19:59 |
kahrl |
+s |
| 19:59 |
sapier |
lglp? |
| 19:59 |
kahrl |
public domain probably |
| 20:00 |
kahrl |
although sha256 is designed by the N*A... maybe use something else? :) |
| 20:01 |
sapier |
did you just volonteer to implement and verify and proofe a brand new hash algorithm? :-) |
| 20:01 |
Calinou |
http://jxself.org/skein.shtml GPL though |
| 20:01 |
Calinou |
ask author for exception? |
| 20:01 |
Calinou |
there may be other implementations of it |
| 20:02 |
kahrl |
whirlpool? |
| 20:02 |
kahrl |
that one is public domain |
| 20:02 |
sapier |
we should use something ppl can verify too not only we |
| 20:05 |
kahrl |
we could allow ./minetest --whirlpool <filename> with only a few lines of code |
| 20:05 |
kahrl |
or whatever we end up choosing |
| 20:05 |
sapier |
yes but I'd still prefer standard tools |
| 20:06 |
kahrl |
most people are using windows, they are out of luck anyway |
| 20:06 |
kahrl |
on linux you can install md5deep |
| 20:06 |
kahrl |
(which implements whirlpool too) |
| 20:07 |
sapier |
still fearing nsa having a backdoor to sha256 for a program having security level like minetest is like replacing heavy reinforced wooden front door by steel door while having a paper backdoor |
| 20:08 |
kahrl |
I guess you're right |
| 20:09 |
kahrl |
we should still implement ./minetest --sha256 <filename> for those poor windows users |
| 20:10 |
sapier |
if they install a mod from store check is done automatically and if we manage to fix the localization issues we can reenable the in game install of local mods too |
| 20:12 |
|
AnotherBrick joined #minetest-dev |
| 20:13 |
|
cg72 left #minetest-dev |
| 20:21 |
|
Calinou joined #minetest-dev |
| 20:22 |
blaise |
lol, I guess.. urhm,, |
| 20:22 |
blaise |
sapier: I shouldn't be grabbing your animals_modpack from git.. eh? |
| 20:23 |
blaise |
only the zip? |
| 20:23 |
sapier |
you can grab it from git but you need adv_spawning too ... and factions is suggested too ... it's all written in lead post ;-) |
| 20:23 |
blaise |
yeah, I know |
| 20:23 |
blaise |
I got all that |
| 20:23 |
blaise |
having random crashes though |
| 20:23 |
sapier |
and you shouldn't grab the 2.5 dev version that's early wip |
| 20:24 |
sapier |
can you provide the error logs blaise? |
| 20:24 |
blaise |
can't seem to keep it up for any ammount of time |
| 20:24 |
blaise |
yeah, just a sec |
| 20:24 |
blaise |
should I wgetpaste for url, or drop in the chan? |
| 20:25 |
blaise |
I'll wgetpaste |
| 20:25 |
blaise |
lmao |
| 20:31 |
RealBadAngel |
hi |
| 20:31 |
RealBadAngel |
kahrl, youre here? |
| 20:31 |
blaise |
Hi! |
| 20:31 |
* blaise |
hugs RealBadAngel |
| 20:31 |
RealBadAngel |
oh why? |
| 20:34 |
blaise |
sorry.. |
| 20:34 |
* blaise |
takes his hug back |
| 20:34 |
RealBadAngel |
lol |
| 20:36 |
Calinou |
hug takeback party |
| 20:38 |
VanessaE_ |
sapier: *poke* |
| 21:04 |
|
proller joined #minetest-dev |
| 21:20 |
RealBadAngel |
quick question: why light tables start with 8? |
| 21:20 |
RealBadAngel |
thx to that nodeboxes are lightsources |
| 21:20 |
Calinou |
because full darkness doesn't make sense |
| 21:20 |
Calinou |
yeah, if you use the debug light tables, anything that's not a solid cube will glow in the dark |
| 21:21 |
Calinou |
this includes plantlike nodes and nodeboxes… |
| 21:21 |
RealBadAngel |
blue channel is supposed to hold lightsources only |
| 21:21 |
RealBadAngel |
light tables that start with 8 are fucked up |
| 21:22 |
RealBadAngel |
Calinou, you would expect then stairs, slabs etc to glow in the dark? |
| 21:22 |
Calinou |
nope |
| 21:22 |
Calinou |
it's a bug, no idea why |
| 21:23 |
RealBadAngel |
light table (in the current use at least) has to be revisited |
| 21:23 |
RealBadAngel |
and 0 has to be 0 |
| 21:23 |
RealBadAngel |
no matter what |
| 21:24 |
RealBadAngel |
in commented out ones, we can find such sets starting with 0 |
| 21:25 |
RealBadAngel |
by now, thx to that table, video::SColor c = MapBlock_LightColor(255, l, decode_light(f.light_source)); |
| 21:26 |
RealBadAngel |
with f.light_source = 0 |
| 21:26 |
RealBadAngel |
blue channel holds 8 |
| 21:26 |
RealBadAngel |
and node becomes lightsource at level 8 |
| 21:27 |
RealBadAngel |
this is nodeboxes case |
| 21:29 |
RealBadAngel |
Calinou, wasnt that you that wanted to change the light table? |
| 21:30 |
VanessaE_ |
https://github.com/minetest/minetest/issues/1362 |
| 21:30 |
RealBadAngel |
indeed |
| 21:32 |
Calinou |
yes |
| 21:40 |
|
domtron joined #minetest-dev |
| 21:46 |
|
domtron joined #minetest-dev |
| 22:00 |
|
ImQ009 joined #minetest-dev |
| 22:05 |
|
sapier left #minetest-dev |
| 22:19 |
|
ImQ009 joined #minetest-dev |
| 22:24 |
|
domtron joined #minetest-dev |
| 22:24 |
|
domtron left #minetest-dev |
| 23:45 |
|
proller joined #minetest-dev |
