Minetest logo

IRC log for #minetest-dev, 2016-12-30

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:05 turtleman joined #minetest-dev
00:09 TC02 joined #minetest-dev
00:13 red-001 I think I managed to create a client that avoids punch damage from other players
00:23 rubenwardy #4806 #4966 #4969
00:23 ShadowBot https://github.com/minetest/minetest/issues/4806 -- Add search to advanced settings by rubenwardy
00:23 ShadowBot https://github.com/minetest/minetest/issues/4966 -- Use tree to list mods rather than textlist by rubenwardy
00:23 ShadowBot https://github.com/minetest/minetest/issues/4969 -- Document registered_chatcommands, add def:run() by rubenwardy
00:24 red-001 joined #minetest-dev
00:27 red-001 joined #minetest-dev
00:57 octacian_ joined #minetest-dev
01:01 Fixer paramat: on heavy modpacks I've seen OOMs due to environment_OnGenerated() from technic-worldgen and darkage mod, any ways to improve this?
01:01 Fixer lua OOM's
01:03 paramat yeah probably
01:03 paramat i now know the 3 memory optimisations for lua mapgens
01:04 paramat anyway offtopic here
01:04 Fixer sorry
01:06 rubenwardy two_steps claims the damage hack is related to tools: https://forum.minetest.net/vi​ewtopic.php?p=244617#p244617
01:09 Shara red-oo1's attempts failed.
01:09 Shara 001*
01:09 Shara So whatever he tried wasn't it.
01:27 troller joined #minetest-dev
01:56 Player_2 joined #minetest-dev
02:59 garywhite Is it just me, or is this two_steps guy trying to taunt the devs now?
03:06 lhofhansl left #minetest-dev
03:11 ssieb joined #minetest-dev
03:12 sofar it's a very young kid I think
03:12 sofar ignore him as a person, just focus on the technical issues
03:12 turtleman joined #minetest-dev
03:16 turtleman joined #minetest-dev
04:03 hmmmm two_steps on the forums?
04:03 hmmmm i take it he is the MineHacker guy?
04:05 hmmmm why are people interested in cheating with minetest?  do people actually play it as a competitive game or something?
04:09 Shara The "kids" think it's "cool".
04:10 Shara I was watched players actually begging for hacked clients on one of the servers where this thing was demonstrated.
04:11 Shara I have*
04:20 troller joined #minetest-dev
04:22 Hunterz joined #minetest-dev
04:26 hmmmm hmmm
04:26 hmmmm people on the forum are saying that if you purchase a copy of minehacker, you are entitled to a copy of its source code
04:28 hmmmm these are indeed one option of distribution according to the GNU GPL v3, but not so much the LGPL v2.1...
04:28 hmmmm if you read here https://www.gnu.org/licenses/​old-licenses/lgpl-2.1.en.html  you'll notice that Minehacker would need to comply with either term 1 or term 2 under Terms and Conditions for Copying, Distribution, and Modification
04:29 hmmmm sorry, terms 2 or 3
04:29 hmmmm term 2 clause c mandates that the whole work must be licensed at no charge to all third parties
04:30 hmmmm term 3 is an option to convert the source to GPL v2, but in order for this to apply, the author needs to supply the GPL license notification, not the LGPL license notification
04:31 hmmmm i don't think he's smart enough to have read this so Minehacker is likely to be noncompliant
04:36 hmmmm mmm nevermind that, term 4 overrides everything.  he doesn't need to do anything special it seems, just distribute source at the same location as the object form at no extra charge.
04:36 hmmmm disregard my rambling :p
04:59 Tmanyo joined #minetest-dev
05:13 lordfingle joined #minetest-dev
06:01 Zeno` joined #minetest-dev
06:12 nrzkt joined #minetest-dev
06:12 Hunterz joined #minetest-dev
06:29 Zeno` I see paramat is still on his campaign to break game mechanics
06:41 nrzkt joined #minetest-dev
06:44 lumidify joined #minetest-dev
07:08 lhofhansl joined #minetest-dev
07:30 hmmmm how so?
07:31 Zeno` changing how saplings grow
07:31 Zeno` (reduced light levels -- actual light levels, not display light levels)
07:32 hmmmm well there's nothing necessarily wrong with that
07:32 hmmmm it's just making it easier to grow underground
07:32 Zeno` makes it harder
07:32 hmmmm reduced light levels needed to grow saplings?
07:33 Zeno` "normal" light levels are needed to grow sapling
07:33 hmmmm really?
07:33 hmmmm ugh
07:33 hmmmm i thought you said reduced light levels tho
07:33 Zeno` he wants to reduce them
07:33 Zeno` make torches darker
07:33 hmmmm torches darker!??!
07:33 Zeno` yes
07:33 hmmmm you mean they weren't dark enough
07:34 hmmmm we already need 5000000000000000000000 torches to light up anything indoors
07:34 Zeno` i know
07:34 hmmmm i disapprove of that change whichever one it is
07:34 Zeno` but by making torches darker all those underground forests that players make impossible (and there are a lot of them)
07:34 Zeno` https://github.com/minetest​/minetest_game/issues/1476
07:35 hmmmm yeah, i made them often to mine wood when i'm doing a deep underground mining operation
07:35 hmmmm gotta make lotsa ladders yknow?
07:35 Zeno` yes, that's what we used them for when we dug to the centre of the world
07:35 Zeno` we *needed* them
07:35 Zeno` for ladders, new torches etc etc
07:35 Zeno` otherwise it would have been impossible
07:35 Zeno` forgetting about the fact that underground forests look cool
07:39 Zeno` I remember now why my original gamma changes had an "adjustment table"
07:40 Zeno` it was to stop the exceedingly bright higher light levels and IIRC, and this is ironic, it may have been paramat who insisted upon it lol
07:40 Zeno` I don't mind "display values" being changed
07:41 Zeno` but changes that break game mechanics... hmm
07:41 hmmmm sofar just did something with the gamma
07:41 hmmmm he said your changes were stupid and made no sense
07:42 Zeno` correct
07:42 hmmmm correct about your changes being stupid and making no sense?  :P
07:42 Zeno` but those only change "display" levels not the 0-15 light level used internally
07:43 Zeno` well, I had an adjustment table so that the display levels at the default gamma remained the same as before gamma was changed, because people asked for it
07:43 Zeno` I also didn't invert gamma (which was stupid)
07:44 Zeno` but the adjustment table was just to keep people happy... it was never really needed
07:46 Zeno` I'd rather see the adjustment table put back to deal with things rather than breaking the game
07:46 Zeno` sofar's other change is ok
07:47 Zeno` basically it's   inputLevel (0-15) --> linear --> apply gamma correction --> apply adjustment/tweaks == display light level
07:47 Zeno` sofar removed the apply adjustment table
07:48 Zeno` he also changed how gamma correction was calculated (but that doesn't matter)
07:49 Zeno` linear is the linear light level of course
07:51 Zeno` this generates a lookup table, so performance doesn't matter
07:59 sofar the whole word gamma is irrelevant and wrongly used in that table :)
07:59 sofar all that matters is the end result IMHO
08:00 sofar I could care less how light is calculated as long as it's consistent
08:01 Zeno` yes, that's right
08:01 Zeno` I am suggesting now that the adjustment table be put back instead of breaking game mechanics
08:01 Zeno` https://github.com/minetest​/minetest_game/issues/1476
08:08 lhofhansl left #minetest-dev
08:14 emptty joined #minetest-dev
08:39 YuGiOhJCJ joined #minetest-dev
08:41 lumidify joined #minetest-dev
08:46 Ritchie_ joined #minetest-dev
09:30 Thomas-S joined #minetest-dev
09:37 DFeniks joined #minetest-dev
09:50 proller__ joined #minetest-dev
10:40 Krock joined #minetest-dev
10:40 Krock joined #minetest-dev
10:49 emptty joined #minetest-dev
11:01 Darcidride joined #minetest-dev
11:08 proller joined #minetest-dev
11:10 proller__ joined #minetest-dev
11:21 red-001 joined #minetest-dev
11:33 red-001 joined #minetest-dev
11:48 juhdanad joined #minetest-dev
11:51 juhdanad Shara do you have access to the server where MineHacker was demonstrated? Debug.txt would be useful.
11:51 juhdanad For example: did the player punch itself?
11:52 emptty joined #minetest-dev
11:59 troller joined #minetest-dev
12:19 Fixer joined #minetest-dev
12:22 troller joined #minetest-dev
12:36 Shara juhdanad: The owner of ESP CTF dislikes keeping logs. I did ask him to make them while this is going on, so can check what he has. Problem is, I don't know if the no damage hack was tested there or elsewhere.
12:37 juhdanad Okay, thanks anyways.
12:37 Shara Could you confirm which server it was tested on?
12:37 juhdanad No, I did not see this in action.
12:37 Shara I know two_steps is back and fore that server, so it might be there.
12:40 Fritigern joined #minetest-dev
13:02 emptty joined #minetest-dev
13:16 lumidify joined #minetest-dev
13:28 troller joined #minetest-dev
13:35 red-001 joined #minetest-dev
13:38 Fritigern joined #minetest-dev
13:39 zorman2000 joined #minetest-dev
13:50 red-001 joined #minetest-dev
14:15 STHGOM joined #minetest-dev
14:33 turtleman joined #minetest-dev
14:36 lumidify joined #minetest-dev
14:41 emptty joined #minetest-dev
15:06 Hunterz joined #minetest-dev
15:18 octacian joined #minetest-dev
15:37 STHGOM joined #minetest-dev
15:41 Darcidride joined #minetest-dev
15:51 red-001 joined #minetest-dev
15:54 troller joined #minetest-dev
15:56 rubenwardy joined #minetest-dev
15:59 blaze joined #minetest-dev
16:03 emptty joined #minetest-dev
16:31 STHGOM joined #minetest-dev
17:00 garywhite Hang on...did anyone notice that for this hacked client that he copyrighted the website?
17:01 Calinou garywhite: copyright is something anyone can claim, there's no registration process most of the time
17:01 garywhite ohh ok
17:03 turtleman joined #minetest-dev
17:06 KrimZon_2 joined #minetest-dev
17:07 AcidNinjaFWHR joined #minetest-dev
17:17 sfan5 garywhite: he made the website he can claim copyright
17:17 sfan5 also keep non-dev related stuff to #minetest
17:22 KrimZon_2 sfan5: does dev stuff include mods?
17:23 paramat joined #minetest-dev
17:25 emptty joined #minetest-dev
17:26 KrimZon_2 left #minetest-dev
17:29 red-001 joined #minetest-dev
17:35 paramat ~tell hmmmm everything zeno said to you last night about me and light levels was untrue, please read https://github.com/minetest/minetes​t/pull/4873#issuecomment-266915098 onwards. even with a lower light level value, torches will actually be visually brighter with my game PR because of recent engine lighting changes, the change will not affect growing stuff at all, torches have never been bright enough to grow any
17:35 paramat thing
17:35 ShadowBot paramat: O.K.
17:43 paramat nore sfan5 ShadowNinja sofar any comments on game#1472 game#1475 ?
17:43 ShadowBot https://github.com/minetest​/minetest_game/issues/1472 -- Papyrus, Cactus: Only make them grow in bright places by SmallJoker
17:43 ShadowBot https://github.com/minetest​/minetest_game/issues/1475 -- Blob ore: Add sand blobs throughout underground by paramat
17:45 paramat ~tell hmmmm torches have been unable to grow saplings for over a year, i'm making no changes to that
17:45 ShadowBot paramat: O.K.
17:52 ShadowNinja paramat: First: fine, Second: do you find sand at great depths IRL?  If so, good, otherwise maybe not.
17:52 paramat sofar, problem is, if we keep torch light level unchanged it now looks too bright, as does fire and lava
17:52 paramat ok. i'll research underground sand
17:54 juhdanad joined #minetest-dev
18:00 TC02 joined #minetest-dev
18:01 hmmmm joined #minetest-dev
18:07 Fixer paramat: could be interesting for you https://github.com/minetes​t-mods/moretrees/issues/32
18:09 blaze joined #minetest-dev
18:10 Hunterz joined #minetest-dev
18:10 paramat saw that :]
18:12 juhdanad Oh, I have seen a bug with moretrees too, when a mapblock was erased from a tree.
18:19 Fixer can you build official non-luajit build for heavy modpacks? For technic, dreambuilder, worldedit work?
18:19 Calinou it should be hidden because most people won't benefit from a non-LuaJIT build, but rather will be hurt by it
18:20 Fixer technic, dreambuilder, darkage is not usable with luajit right now :(
18:20 Fixer on my setup
18:27 sfan5 Fixer: https://kitsunemimi.pw/tmp/min​etest-0.4.15-noluajit-win64.7z
18:27 sfan5 built this earlier but you weren't here
18:27 Fixer sfan5: oh, thanks a lot, please publish this link on your page, can I also post it in technic and dreambuilder topics?
18:27 sfan5 except the updated gettext it (and obviously missing luajit) it is built identically to the release
18:28 sfan5 sure
18:28 paramat nice, lots of players are getting OOM errors
18:28 red-003 joined #minetest-dev
18:28 red-003 joined #minetest-dev
18:28 Fixer paramat: i've posted your opimisation topic to darkage and technic githubs, maybe someone will look into it
18:29 Fixer paramat: and it is this damn OnGenerated OOM :/
18:29 paramat ok, those mods could just use core oregen instead, another alternative
18:30 Fixer why not? it is good alternative to me
18:30 paramat we have a few new types now
18:30 paramat well just for speed and less memory use
18:30 paramat but those optimisations should be tried first
18:31 Fixer most people use luajit one and they will have bad experience with darkage, technic, dreambuilder, etc
18:31 Fixer i suspect
18:35 octacian_ joined #minetest-dev
18:35 hmmmm i like sofar's new light decay curve so much better
18:40 hmmmm paramat:  i just looked over the PR and it is exactly as Zeno said
18:40 paramat nope
18:40 hmmmm underground forests are broken
18:40 paramat that was done over a year ago
18:41 Fixer you can use MESE lamp
18:41 hmmmm i haven't updated my minetest_game in over a year so i didn't notice
18:41 hmmmm yes, now i see the dates
18:41 hmmmm but that did break things when it happened, you cannot possibly deny that
18:42 paramat saplings were missing a lighting check, all other plants have always required something brighter than a torch
18:42 hmmmm okay, perhaps so
18:43 paramat so yes, but it was a bug and an inconsistency
18:43 hmmmm but are you saying that the game mechanics did not change?
18:43 hmmmm because the game mechanics changed
18:43 paramat yeah i agree
18:43 hmmmm so you're going to upset at least some users
18:43 paramat but bugfixees will always irritate those who got used to them
18:44 paramat we made the sapling 'can grow' function global to be overridable
18:44 hmmmm and what was your stance on the elevator issue?
18:45 paramat and we added meselamp so that default game now has a growlamp
18:45 paramat hm elevator?
18:45 VanessaE an UGLY growlamp
18:45 hmmmm you add the blocks in a spiral pattern upward and then to go up you crouch a certain way, i'm not sure what it's called
18:46 paramat we could add a pretty mese torch
18:46 VanessaE (sorry.  it's a big, honking cube that just looks like shit when you're trying to use it for that kind of lighting)
18:46 hmmmm pretty mese torch or not
18:46 paramat ah sneak elevator
18:46 hmmmm the requirement you use mese now just to grow a source of wood does break peoples gameplay
18:46 hmmmm mese is much rarer than torches
18:46 VanessaE hmmmm: you hold space and sneak at the same time, btw.
18:47 paramat i don't really have an opinion yet on sneak elevator
18:47 hmmmm now deep mining operations are basically impossible
18:47 paramat mese ore is not rare, meseblock is
18:47 hmmmm well, there's an example of something technically a bug that was used extensively now
18:47 hmmmm but how deep does mese block start at?
18:47 VanessaE 1024, unless it changed.
18:48 hmmmm exactly
18:48 paramat mese ore 64, meseblock 1024
18:48 hmmmm oh
18:48 hmmmm still a lot though
18:48 paramat meselamp uses mese crystal
18:48 hmmmm mese ore is rare at 64
18:48 hmmmm it's not like coal or something
18:48 paramat a little yeah
18:48 hmmmm so are you going to accept that your change did break gameplay?
18:49 paramat we could make the meselamp recipe more generous
18:49 VanessaE the mese lamp should have looked like some kind of actual lamp.  that's all.
18:50 paramat yes, not being able to (unreasonably and inconsistently) grow saplings in darkness did break gameplay
18:50 hmmmm did you advertise that fact when you made the PR?
18:50 hmmmm i'm willing to bet a lot of opinions would've changed
18:51 paramat i have a PR in game to make sand blobs deep underground so that meselamps can be crafted easier
18:51 paramat see the links i posted, i made an issue first asking if it was reasonable
18:52 paramat https://github.com/minetest/minetes​t/pull/4873#issuecomment-269340876
18:53 paramat eventually 3 weeks later 2 pople complained
18:54 hmmmm sigh
18:54 hmmmm well if everybody likes it then so be it
18:55 hmmmm but this does break something i personally liked to do
18:55 VanessaE the problem with that, paramat, is that complaints that matter won't usually come through github
18:55 VanessaE (by "that matter", I mean from your average Joe user)
18:55 paramat anyway, i'm happy to make meselamps easier to craft, and to add new types of mese light
18:56 Shara New types would be welcome, if they are not ugly cubes :)
18:56 paramat hmmmmm you can use meselamps, torches have never been bright enough to grow anything
18:56 paramat sure i can add a mese torch
18:56 VanessaE except mushrooms.
18:56 paramat heh
18:57 hmmmm torches are going to be made darker
18:57 garywhite hmmmm: I've actually built an underground farm with meselamps, it just doesn't grow too well
18:57 paramat nope, they will be visually brighter
18:57 hmmmm yeah paramat, i am sorry.  everything that zeno said is 100% true
18:57 hmmmm no matter how you try to spin it, these are the facts
18:58 hmmmm now we're losing range on the torches
18:58 paramat that's true
18:58 hmmmm as if a spread of 14 wasn't bad enough
18:58 paramat and a concern
18:58 hmmmm the lighting model needs to be fundamentally improved
18:58 VanessaE hmmmm: I doubt that'll be possible until the map format changes
18:58 hmmmm right now gameplay decisions are being held hostage
18:58 VanessaE 4 bytes per node is...kinda limiting.
18:59 hmmmm no... 4 bytes per node is not limiting
18:59 paramat zeno gave the impression torches will be visually darker, which is the impression you got
18:59 hmmmm 4 bits per light level is horrible
18:59 VanessaE yeah
18:59 VanessaE and where will the extra bits come from?
18:59 VanessaE there's nothing left to steal
18:59 hmmmm nonsense
18:59 hmmmm we can do without the night bank
18:59 paramat "Zeno`:changing how saplings grow" not true
18:59 hmmmm i've never seen a single mod actually make use of that
19:00 VanessaE hm
19:00 VanessaE I was under the impression that the night bank was more for rendering purposes
19:00 VanessaE (after a fashion)
19:01 VanessaE that still leaves the problem of interpreting the value - a new map format (well, new version) will be needed.
19:01 hmmmm obviously
19:01 hmmmm this bumps the mapblock serialization version
19:01 paramat "Zeno`: but by making torches darker all those underground forests that players make impossible" not true, this was done a year ago
19:01 VanessaE right
19:02 hmmmm so
19:02 hmmmm right off what you could do is modify the light bank concept
19:02 hmmmm from 4-4 it could be 1-7
19:02 VanessaE 1?
19:03 hmmmm 1 bit for the night bank, 7 for day
19:03 VanessaE hm
19:03 hmmmm the 1 bit will be a boolean meaning
19:03 ShadowNinja Note that we'll also have to either break the Lua API or use 0-15 floating point light values if we add more bits to light.
19:03 hmmmm "this light comes from a light source, keep the light value constant with daytime"
19:03 hmmmm ShadowNinja an emulation mode can be added
19:04 VanessaE hmmmm: that's not a bad idea.
19:04 hmmmm in general this would be a huge gamechanger
19:04 ShadowNinja (Or leave the API as is and only allow 15 values)
19:04 hmmmm and again
19:04 hmmmm that's only one option
19:04 hmmmm having 128 possible light levels is very liberating
19:04 hmmmm but we can go further
19:04 hmmmm remember the meta get nodedef PR
19:05 hmmmm it's not an unprecedented idea to use nodedef while rendering blocks
19:05 hmmmm if it's fast enough, you can completely do without that 1 bit night bank
19:06 hmmmm and keep comparing ndef->get(foobar).is_light_source
19:06 paramat "Zeno` makes it harder" (to grow things underground) this was done a year ago
19:06 ShadowNinja We could also do something like 0x1FF = 15 = 255 light, or have a separate field such as light_v2.  I suppose that's a fairly minor point compared to everything else that will have to be done though.
19:06 hmmmm 0x1FF??
19:07 hmmmm i dunno
19:07 paramat "Zeno`: he wants to reduce them, make torches darker" they will be visually brighter than in 0.4.15
19:07 VanessaE paramat: there's one other caveat to that ^^
19:07 hmmmm but anyway this is a change to lighting that helps a LOT and it's quite conceptually simple
19:07 ShadowNinja hmmmm: Yeah, it's odd, plenty of other optios if we don't want that.
19:07 hmmmm but there are tons of changes
19:08 hmmmm there's going to be tons of changes no matter how you do this
19:08 paramat hmmmmm zeno was talking about stuff done a year ago and confusing that with current changes, you misunderstand
19:08 hmmmm the lighting model wasn't made very abstract
19:08 hmmmm paramat:  i've moved on from that topic
19:08 VanessaE actually strike that last statement
19:09 VanessaE (I was about to remind of an old trick that's no longer relevant)
19:09 hmmmm i'd like to make it so that reducing the light level produced by a torch to 13 isn't horrible to begin with
19:09 VanessaE hmmmm: I presume with 7-bit light values, we'd also get much wider spread?
19:09 hmmmm vanessae:  that's the primary benefit
19:10 VanessaE just making sure.
19:10 hmmmm so
19:10 VanessaE a lot of people love to conflate range with resolution (not saying you do)
19:10 hmmmm to summarize:
19:10 hmmmm right now we're at 4:4
19:10 hmmmm we can reasonably change this to 7:1 or even 8:0
19:11 hmmmm further if i implement the model where light data is separated from mapblocks
19:11 hmmmm we can do even better
19:12 hmmmm i still want truecolor lighting, and we can realize a savings of ~3.5 KB per block at the same time by storing only light at the borders of the mapblocks
19:12 lumidify joined #minetest-dev
19:12 hmmmm in reality we'd be spending 488 bytes more per block, but have a totally free 8 bits to do something else with
19:13 paramat is not light range limited by mapblock size? ie any light update only requires changes within 16 nodes, larger range means much more intensive light updates
19:14 VanessaE I'd love to have truecolor lights; ilights mod, homedecor's lighting, stained glass mod, probably many others would benefit greatly.
19:16 VanessaE paramat: if that were such a big deal, I'd be more concerned with the number of nodes that have to be updated (>51k versus ~800) rather than number of affected mapblocks.
19:16 VanessaE but it's not like players are sitting there adding/removing lights a dozen times a second or something, so is that really that big a concern?
19:16 paramat yeah that's what i mean
19:17 paramat well processing grows by the cube of light range
19:17 paramat and it's already quite heavy
19:18 paramat even range 32 would be excellent
19:19 sofar if you want to modify the light bank bits, don't put all 7 bits into (light+range) like it is now
19:19 sofar since light level and range are the same thing, which is the core of the problem
19:19 sofar what you want is some bits for range, and some for light level
19:20 VanessaE hm, forgot to consider 3 dimensions.  6.5M versus 12.8k, though the worse-case would be half of that since you can't cast light through a solid, opaque object
19:20 VanessaE worst*
19:20 sofar e.g. keep 3 bits for light level, and add 4 bits for range
19:20 hmmmm mapblock size and light range are coincidental
19:21 VanessaE sofar: in reality, light level and range are synonymous anyway, assuming the same projection type
19:21 hmmmm sofar, the problem is that you're describing a light by strength + range only works for defining light sources
19:22 hmmmm i'm talking about the data stored in the mapnode that gets used *on render*
19:22 octacian joined #minetest-dev
19:22 hmmmm on render we don't have time to know all about that stuff, we just know that node XYZ gets rendered with shade W
19:23 ShadowNinja If you're breaking the serialization format you might also want to look at #3946.
19:24 ShadowBot https://github.com/minetest/minetest/issues/3946 -- Improved block serialization format
19:24 Fixer sneak elevator bug also has big problem - you avoid damage everywhere on any slopes, and you can avoid damage on flat ground too
19:24 ssieb joined #minetest-dev
19:25 VanessaE sneak elevators should be easy to keep support for while fixing the damage issue, if the engine were to check for the common sneak elevator node pattern while dealing witha jump action
19:26 VanessaE (turn jump into 'climb up' if the pattern supports the notion)
19:39 Fixer this is weird, Dreambuilder works nice for Vanessa on luajit + linux, but works like 10 min for me in windows before OOM crash
19:40 Fixer i've started to google and found this: http://www.xsquawkbox.net/xpsdk/mediawiki/LuaJIT (xplane also uses luajit for plugin), it may be useful to you?
19:47 hmmmm no this is just a far out there idea
19:47 hmmmm if you want to actually improve lighting, this is how it's done
19:47 hmmmm i gotta do biome shit first
20:07 Fixer hmmmm: i have seen a guy on Just Test 1 and 2 that advertised and used his hacks on other people, he told me that he is doing this for fun, he ruined our fun though
20:08 Fixer he said he had lots of hacks for the game
20:08 Fixer he is from USA iirc
20:08 garywhite Fixer: What's his name?
20:08 Fixer gold_digger
20:09 garywhite oh ok, I think I remember him
20:14 juhdanad joined #minetest-dev
20:15 hmmmm not too interesting on "seeing a guy"
20:15 hmmmm unless it's an actual violation of the LGPL v2.1
20:16 juhdanad hmmmm: 7+1 bits for the lighting is not enough: imagine a mese lamp in a sunlit cave.
20:16 hmmmm imagining it...
20:17 VanessaE one thing to consider, by the way:
20:17 juhdanad there is half sunlight and full night light.
20:17 juhdanad When it is night, the mese lamp could only produce half of its light.
20:17 VanessaE there are light sources in real life that appear brighter (locally) than the sun itself.  I think magnesium does, for example.  Might be worth considering.
20:17 hmmmm what do you mean
20:18 hmmmm why is the mese lamp not able to produce its full range any less than it can at the present
20:18 juhdanad Because there's nowhere to store the lamp's light. There's only one bit.
20:19 hmmmm vanessae, fair enough, when you have 128 levels it's not really a problem making the sun level 120 or something
20:19 hmmmm what are you talking about?  what about the 7 bits?
20:19 juhdanad What would you like to store in the 7 bits?
20:20 hmmmm light values
20:20 juhdanad But you can store there either night or day light.
20:20 hmmmm i already said the distinction between night and day light is dumb and is not needed
20:20 juhdanad Oh, I see!
20:21 hmmmm the whole idea is to steal 3 bits from the night light to give to the day light
20:21 hmmmm the 4 bit night bank now becomes a 1 bit boolean "is artificial light source"
20:21 hmmmm if true then it stays lit when rendering during night
20:21 hmmmm and also gets rendered with the yellow tint
20:22 DFeniks joined #minetest-dev
20:22 juhdanad But then given an air node which has full day night and a dimmer artifical light source would be at max light level at night too!
20:23 hmmmm yeah that's true
20:23 hmmmm that's the hole in the theory i was looking for
20:23 hmmmm i knew my idea was too good to be true
20:23 juhdanad So the problem is that sunlight and artifical light are independent.
20:24 juhdanad You have to know them both.
20:24 juhdanad Same for color components.
20:24 rubenwardy there;s still the idea of storing light levels at chunk borders then relighting during emerge
20:24 hmmmm I mean
20:24 hmmmm each light bank is logically its own light source
20:25 juhdanad I think the problem here is not with disk space; but with RAM.
20:25 hmmmm right now it's not configured as such
20:25 hmmmm but you can think of the day bank being "the light produced from the sunlight source"
20:25 hmmmm and the night bank is "the light produced from all other sources"
20:26 hmmmm logically, you should be able to turn on or off each logical combination of these light sources
20:26 juhdanad Yes, light is cached for each node to speed up mesh generation and lighting queries for mods.
20:26 hmmmm day bank on, night bank off, night bank on, day bank off, night and day on
20:26 hmmmm etc.
20:26 hmmmm hmmm
20:27 hmmmm maybe there might be a workaround for this problem, i have to think more
20:29 juhdanad hmmm: what about another approach, where nodes store the direction they get their light from?
20:29 juhdanad This would be recursive, but 3 bits are enough for a light bank.
20:30 hmmmm which would require backtracking
20:30 juhdanad And it would be slower, but the light sources' range would be unlimited.
20:30 hmmmm due to the recursive algorithm the areas where light fades out wouldn't have a well defined light vector
20:30 hmmmm well
20:31 hmmmm rubenwardy mentioned my other idea
20:31 hmmmm for the truecolor lighting
20:31 hmmmm it's similar to that
20:31 hmmmm stored separate from the mapnode would be a plane covering each border of a mapblock that contains lighting info
20:31 hmmmm so say the edge of the block has light with a value of 14
20:32 hmmmm you just communicate that and no other lighting for the individual nodes
20:32 hmmmm the effective per-node lighting would be computed at render time
20:33 hmmmm like you're iterating downward when creating a mesh, you start with the +(x,z) of that border
20:33 red-001 joined #minetest-dev
20:33 red-001 joined #minetest-dev
20:33 juhdanad And what is it good for? I mean this does not give different lighting from what we have now.
20:33 hmmmm storage
20:33 hmmmm you'd only need to store 88 bytes the way things are right now
20:33 hmmmm per mapblock
20:34 juhdanad That is true.
20:34 hmmmm and you'd free up a byte per mapnode too
20:34 hmmmm but the only issue there is blending
20:34 hmmmm i have thought about all this but never made any proof of concept so there's still places where my ideas could fall short
20:34 juhdanad But does minetest run out of memory?
20:34 hmmmm all the time brotha
20:35 hmmmm yeah okay
20:35 hmmmm so this is how the algorithm works
20:35 hmmmm let's say you're making the mesh
20:36 hmmmm you iterate downward on a certain (x,z) column, so your light is mapblock_light_yplus_border[x + z * z_stride]
20:36 hmmmm you decay this light by 1
20:36 hmmmm and then query each opposing column when computing the effective mapnode light
20:36 VanessaE hmmmm: right, that (sun=120) is basically what I was thinking.
20:37 juhdanad But light can spread in all directions!
20:37 hmmmm so you have a loop where it'd go down and you fetch mapblock_light_xplus[y + z * zstride] and mapblock_light_xminus[y + z * zstride], subtract the distance away from the border relative to those coordinates it is and decay the light by that amount
20:38 hmmmm yeah
20:38 juhdanad And light can spread in an S shape in an S shaped tunnel.
20:38 hmmmm the way this recursive algorithm works is a real bummer
20:38 hmmmm makin things complicated
20:38 juhdanad One more thing: minetest.get_node_light() returns blended day-night light for a node.
20:38 hmmmm yes, i already accepted this would kill the performance for the light query API
20:39 hmmmm if i can get this idea to fully work though i think that'd be a very acceptable sacrifice
20:41 juhdanad And if a player places a node then would you recompute lighting for the whole block?
20:41 hmmmm unfortunately yes
20:42 hmmmm but that's not too bad, i mean a lot is already recomputed when nodes are modified
20:42 juhdanad Currently if you dig a dirt node on the ground, only this node gets updated.
20:43 juhdanad And if you hit a torch next to another one, only one half of the light is recomputed.
20:51 hmmmm yeah, okay, nevermind about my whole idea
20:53 hmmmm what i'm saying is equivalent to: given a specific X,Y,Z i can compute the L of a node with no other info
20:53 juhdanad Sorry if I disappointed you :(
20:53 hmmmm thanks for talking to me
20:53 hmmmm you made me draw it in kolourpaint and try to figure out if what i'm saying has a chance of working in reality
20:53 juhdanad To tell the truth, I have spent several nights thinking about new kinds of lighting.
20:55 hmmmm well i haven't spent that much time on it, but this has always been an issue you can't help but wonder if there's a solution to
20:55 juhdanad But the best idea was to store direction of incoming light. And it still has a drawback: you only know a block's lighting if the neighbor blocks are loaded.
20:55 hmmmm you see i've come up with several half-assed solutions with flaws in each
20:56 hmmmm again though
20:56 hmmmm each node has several sources
20:56 juhdanad Yes, but you have to store the one that gives maximal light.
20:56 hmmmm how can you tell what the direction is for the fade-out of two lights
20:57 hmmmm like say you have two beams crossing at X,Y,Z.  but (X+1, Y+1, Z+1) gets lit as well
20:57 hmmmm or is that relevant... hrmmm
20:57 juhdanad In minetest light sources' lights are not added, but the maximum is chosen.
20:57 juhdanad Currently it is a plain Dijkstra's algorithm.
20:58 juhdanad So the air would point towards the nearest light source.
21:00 hmmmm just so i know what you're talking about
21:00 hmmmm http://i.imgur.com/0Wi14rV.png  what direction would the periwinkle pixel in this diagram be?
21:01 hmmmm +N or +E?
21:01 juhdanad What do the colours mean?
21:02 hmmmm errm
21:02 hmmmm gray is the mapblock border
21:02 hmmmm red is a node that blocks light
21:02 hmmmm and the yellow is the fading light
21:03 juhdanad Then it can be both left and down. The resulting distance (and so brightness) would be the same.
21:03 hmmmm you mean either or
21:03 juhdanad Oh, yes!
21:03 hmmmm so lemme think about this...
21:04 hmmmm this node has a direction of north
21:04 hmmmm and where do you get the light *value* from?
21:04 hmmmm mapblock border?
21:04 juhdanad And each node points towards a brighter node.
21:04 hmmmm oh so it's the opposite
21:04 hmmmm so it points either W or S
21:05 juhdanad If a node has no direction, it means that it is a light source.
21:05 juhdanad We have to walk until we find such a node.
21:05 hmmmm eww
21:05 juhdanad Then node_light=light_source-distance
21:05 hmmmm trying to figure out how that can be done efficiently inside of the makemesh
21:06 hmmmm but i can understand why direction doesn't matter though
21:06 juhdanad This is not for meshes! This is to replace the current meaning of param1.
21:06 hmmmm you would need a plane for each mapblock border of light values though, no?
21:06 hmmmm yes but you still need to compute the effective lighting for a single node when making the mesh
21:07 juhdanad Yes, this is slower than caching the light for all nodes.
21:07 hmmmm waaaaaay slower
21:07 juhdanad This would only allow nodes with light_source>14.
21:08 hmmmm but so would my version, if you accepted running the light algorithm just before mesh making
21:08 hmmmm just one amendment to yours:
21:08 hmmmm if you take the scenario laid out in my diagram i pasted
21:08 hmmmm and the direction for the periwinkle node is either west or south
21:09 hmmmm there would be no light source since it came from a spread light
21:09 juhdanad The node with sunlight is the light source.
21:09 hmmmm nevermind sunlight right now
21:09 juhdanad There are three bits: 0-5 is direction, 6 is light source and 7 is sunlight.
21:09 hmmmm i'm just talking about a single artificial light source
21:10 juhdanad Oh, the node at the border would point out of the block.
21:10 juhdanad This is why I wrote: "you only know a block's lighting if the neighbor blocks are loaded."
21:11 hmmmm not at the border
21:11 hmmmm inside of the room with a single hole that light shines through
21:11 hmmmm the light radiates and so a node that's not directly in the path of the light gets lit
21:12 hmmmm according to your definition, it points toward the brighest node neighbor
21:12 hmmmm and that's the direction you trace back to find the light source
21:12 juhdanad Oh, you misunderstood me! The node points to its neighbor, which points towards an other node and following this path you get to the light source.
21:12 hmmmm but if you, say, the column at (X,Y) is the light source and you're considering the node at (X+1,Y+1,Z)
21:13 hmmmm have the situation where*
21:13 hmmmm it'd never trace back to a light source
21:13 hmmmm ahhh
21:13 hmmmm okay okay sorry
21:13 hmmmm that makes total sense now
21:13 hmmmm now watch this whole idea go to shit when you start adding RGB lights :)
21:14 hmmmm yeah i'm on board with your direction idea now
21:14 hmmmm the only problem is the unbounded time to compute a single light cell vs. a deterministic upper bound
21:14 juhdanad The problem with colored lights is that an orange light's red component fades slower than a red light's.
21:16 hmmmm yeah the direction idea is the best of the bunch so far, because it actually works unlike mine
21:16 juhdanad If you maximize light_source to 32, then it is guaranteed that you get a node's light after 32 iterations.
21:16 rubenwardy you could exit after X steps
21:16 hmmmm but then there goes the sales pitch of having infinite lighting range!
21:17 juhdanad Well, true.
21:17 hmmmm at this point you step back and wonder if it's all worth it
21:17 juhdanad I could rather say: brighter light sources with only 3 bits per light bank.
21:17 hmmmm you could just double the size of a mapnode and get everything you ever wanted
21:18 hmmmm just double the ram as if we aren't sucking up enough already
21:18 hmmmm double the cache misses
21:19 hmmmm another thing with the lighting idea:  is it possible for a node to get stuck in a circle
21:19 juhdanad Also currently placing a torch makes 6800 node's light recalculated.
21:19 hmmmm i mean the directional lighting idea*
21:20 juhdanad If you encouter a circle, it is a bug which would not happen. If you still encouter a circle, you set the node as a light source.
21:21 juhdanad (if it is air, it will provide zero light)
21:38 troller joined #minetest-dev
21:53 hmmmm yeah so how does zero light get represented
21:53 hmmmm don't you need an extra bit for that?
21:53 hmmmm bringing the total to 9, which would mean 4 bits per light bank?
21:54 juhdanad No. Zero light is a light source. Since nodedef.light_source is 0 there.
21:54 hmmmm ahhhh
21:55 hmmmm this is a tough problem
21:55 juhdanad hmmmm: sorry to bother you with that, but are you still planning to expose biome information to not mapgen code?
21:55 hmmmm i wonder if it'd be worth it trying to get hardware lighting working
21:56 hmmmm or do this all from within shaders
21:56 hmmmm yes
21:56 hmmmm i guess i have to, now that the biome system isn't undocumented anymore
21:57 juhdanad I would like to implement hardware-coloured node faces and the two together make biome-coloured grass and leaves.
21:57 hmmmm who doesn't want that
21:57 hmmmm it doesn't even need to be done in hardware though
21:58 juhdanad If it is done with hardware, one texture is enough for a node type (eg. wool).
21:58 juhdanad Less texture is faster graphics.
21:59 hmmmm there's a lot of potential in shaders
21:59 hmmmm it's just that none of us know how to use them well
21:59 hmmmm :/
22:00 hmmmm and then there's the issue with irrlicht
22:00 hmmmm ugh this whole thing is a giant can of worms
22:00 hmmmm so much work
22:00 juhdanad Maybe lhofhansl. He once tried to change shaders.
22:00 hmmmm hah
22:00 hmmmm i changed shaders a few time too
22:01 hmmmm times*
22:01 hmmmm it's not about knowing how to write a shader i suppose, it's more about being familiar with lots of specialized topics in computer graphics
22:24 lhofhansl joined #minetest-dev
22:26 Player_2 joined #minetest-dev
22:37 DI3HARD139 joined #minetest-dev
22:47 red-001 joined #minetest-dev
22:54 lhofhansl left #minetest-dev
23:00 Foz joined #minetest-dev
23:01 turtleman joined #minetest-dev
23:15 garywhite joined #minetest-dev
23:23 YuGiOhJCJ joined #minetest-dev
23:32 AntumDeluge joined #minetest-dev
23:35 red-001 joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext