| Time |
Nick |
Message |
| 02:45 |
|
user333_ joined #luanti-dev |
| 02:49 |
MTDiscord |
<jordan4ibanez> https://klipy.com/gifs/its-not-true-thats-impossible-star-wars |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 07:57 |
|
YuGiOhJCJ joined #luanti-dev |
| 08:36 |
|
YuGiOhJCJ joined #luanti-dev |
| 09:04 |
sfan5 |
https://x0.at/kAhe.png are all of these supposed to look the same |
| 10:02 |
|
vampirefrog4 joined #luanti-dev |
| 10:05 |
|
vampirefrog joined #luanti-dev |
| 10:21 |
MTDiscord |
<.zenonseth> hey, was building something and had another thought for a possible API change - not sure if it has been suggested and perhaps rejected for some reason. An API flag in a node def to mark it as sunlight source - so that it acts as if its receiving full sunlight (or moonlight) regardless of its position, bypassing the usual checks for space above is empty. Of course then it has to affect everything below/around it as usual which may be |
| 10:21 |
MTDiscord |
the bigger change in code. This would let mods define sunlight-like lighting, and especially in some subgames, would allow for more freedom in design space. |
| 10:24 |
sfan5 |
how is that different from it being a light source? |
| 10:26 |
MTDiscord |
<.zenonseth> light sources have limited range even downwards - a 'daylight' node will illuminate everything downwards as if exposed to sky |
| 10:27 |
sfan5 |
oh |
| 10:28 |
sfan5 |
however the problem you run into here is that the "daylight node" can be any distance from a given node it may affect, and it may not be loaded when the lighting calculation happens |
| 10:29 |
MTDiscord |
<.zenonseth> yeah, thats why it'd have to be an engine change, can't due it via lua alone right now, it'd have to modify the looking "up" to see if its blocked to decide. Ofc, bypassing unloaded blocks to skip their light calcualtion is unavoidable (even currently) but that's just an existing issue |
| 10:30 |
MTDiscord |
<.zenonseth> there's more nuance to it, but basically the check upwards for daylight level will stop when it hits this fake daylight node and will say 'yes, exposed to sky' |
| 10:31 |
sfan5 |
I am already presuming that you'd change the engine to implement this |
| 10:32 |
sfan5 |
the thing is to make sunlight work the engine has basic heuristics on whether a block is underground or not. these won't work if you can place the sun at any or even multiple arbitrary points in the map. |
| 10:34 |
sfan5 |
so it will be a mess |
| 10:34 |
MTDiscord |
<.zenonseth> I can keep those, much like currently (from my experience) you can dig a really deep hole, block off its top, and then as long as you never load the mid sections for sunlight calc to propagate, the bottom will remain illuminate as if still exposed to sky |
| 10:36 |
MTDiscord |
<.zenonseth> if it turns out messy and requires a lot of patching, fair, won't even make the PR - just would have spent some time - I just wanted to know if it has been mentioned at any point in the past, quick search through issues log didn't yield anything too relevant |
| 10:56 |
|
vampirefrog joined #luanti-dev |
| 11:37 |
MTDiscord |
<luatic> sfan5: if inventory_items_animations is set to false, apparently yes |
| 13:58 |
sfan5 |
can we work on getting a read-only mirror of CDB working? |
| 14:01 |
MTDiscord |
<wsor4035> Ruben is working on adding anubis to cdb |
| 14:04 |
MTDiscord |
<wsor4035> (Ai crawler attack) |
| 14:10 |
sfan5 |
I would recommend go-away instead |
| 15:42 |
|
swags joined #luanti-dev |
| 17:31 |
MTDiscord |
<.zenonseth> is there some process i should be following for asking about API additions like i did above? I was going to submit an issue, but I don't want it to sound like I'm asking anyone else to spend their time to implement this, and just opening PRs may not be the best idea, as I may just be creating more work for you all without discussion first. |
| 18:11 |
MTDiscord |
<luatic> nothing wrong with opening an issue and including "i plan to work on this" |
| 18:21 |
MTDiscord |
<.zenonseth> on unrelated note, I do want to help with things already in progress, if that's an option, I don't expect this immedately as i get everyone's busy but i want to mention it so its not lost - the UI and SSCSM stuff especially |
| 18:25 |
MTDiscord |
<luatic> always happy to get some momentum behind SSCSM |
| 18:29 |
|
YuGiOhJCJ joined #luanti-dev |
| 18:34 |
MTDiscord |
<wsor4035> for sscsm you probably should pm desor |
| 18:35 |
MTDiscord |
<wsor4035> and ui vr0b if they are still around.... |
| 18:40 |
MTDiscord |
<.zenonseth> is that all best done on irc then? |
| 18:41 |
MTDiscord |
<wsor4035> the first is only on irc, second matrix rarely irc |
| 18:41 |
MTDiscord |
<wsor4035> iirc |
| 18:41 |
MTDiscord |
<luatic> or in public GitHub discussions. interested core devs will see them. we see everything 👁️ |
| 18:41 |
MTDiscord |
<.zenonseth> yes, thats why they're 'public' :D |
| 18:42 |
MTDiscord |
<luatic> well yeah. but we're also subscribed to notifications (normal users could subscribe to, but usually aren't). |
| 18:43 |
MTDiscord |
<luatic> so if you do start discussions in issues or PRs, devs do in fact see them. they don't have to actively seek out the issues. |
| 18:43 |
MTDiscord |
<luatic> s/to/too |
| 18:43 |
MTDiscord |
<wsor4035> anyways, my point was to talk to someone who is driving or interested in that area that is a core dev. much better one on one and then you likely will have someone who can review your stuff, 1/2 |
| 18:43 |
MTDiscord |
<wsor4035> at least for a general direction. specific stuff issues works best for |
| 18:44 |
MTDiscord |
<.zenonseth> yea absoltuely, i had no idea who is/was working on what, so this helps |
| 18:45 |
MTDiscord |
<luatic> fwiw i am very interested in SSCSM API stuff |
| 19:03 |
MTDiscord |
<herowl> sfan5: what are actually the heuristics for sunlight spreading and how do they interact with stuff like floatlands in v7? |
| 19:09 |
celeron55 |
you can't really do upstream API additions without having a public discussion. so, you *should* open a public discussion, but it would be best to do it with some proof of concept or test code so that people have easier time figuring out what it is all about |
| 20:01 |
MTDiscord |
<.zenonseth> i am totally fine with discussions, and also fine if they happen on PRs - there's 3 i have right now with 2 having discussions - and if that works, I can do that too - but just wasn't sure if that process is fine, or issues are preferrable. I also personally feel like I do need to write some code for anything I'm suggesting, to know exactly what I'm talking about |
| 20:40 |
|
Desour joined #luanti-dev |
| 21:08 |
Desour |
FYI, if someone needs directions for sscsm I could give some. I just don't have time to do stuff, maybe again in a month |
| 21:08 |
MTDiscord |
<the4spaceconstants2181> I could use some |
| 21:09 |
Desour |
if you want to work on API features, I have this branch for example: https://github.com/Desour/minetest/tree/sscsm_itemdefs |
| 21:09 |
Desour |
it's about adding itemdefs to sscsm |
| 21:10 |
Desour |
(I thought to do it in a way that in the future one can override_item from sscsm to override some of the client-side field) |
| 21:11 |
Desour |
(and interact stuff that is in game.cpp should be moved to sscsm. it can be made such that it just calls nodedef.on_punch to send a punch interact packet, for example. (and if a sscsm were to override on_punch, that thing will happen)) |
| 21:12 |
Desour |
(but that stuff should be done in another PR) |
| 21:22 |
MTDiscord |
<.zenonseth> hey, ah i was about to join irc tonight to find you, but yea also interested in working on this |
| 21:23 |
MTDiscord |
<.zenonseth> is there like a road-map like document or rfc or something like that about expectations ? |
| 21:34 |
sfan5 |
@herowl: https://github.com/luanti-org/luanti/blob/73e48bc348014e6673f22e6a4f34a383d95d9835/src/emerge.cpp#L361-L365 |
| 21:38 |
Desour |
written down inside an issue now: https://github.com/luanti-org/luanti/issues/8057#issuecomment-4883881343 |
| 21:39 |
MTDiscord |
<.zenonseth> thanks! getting late today but i have time tomorrow + this week, will checkout your banch and look at this if you dont mind |
| 21:47 |
|
mrcheese joined #luanti-dev |
| 21:49 |
Desour |
thanks! |
| 21:49 |
Desour |
also useful to check out: https://github.com/luanti-org/luanti/issues/5393#issuecomment-4883907434 |
| 22:00 |
MTDiscord |
<herowl> sfan5: maybe we should allow registering more surfaces and "sun layers" for usage with y-slice dimensions? I.e. game puts a dimensional barrier at y=-2000, then has surface of the new dimension at y=-3000 and so blocks between -2000 and -3000 would be considered "not underground"? |
| 22:02 |
|
YuGiOhJCJ joined #luanti-dev |
| 22:05 |
Desour |
we could also store the highest known non-sunlight-propagates node y pos in a 2D map (or one for each sun layer, if we had that), for correct sunlight shadows. (but this would cause ugly shadows below sky islands) |
| 22:10 |
MTDiscord |
<.zenonseth> i got the fake sunlight node to work for the most part - just another flag on nodedef, and when scanning down columns we have the new case of shadow can become sunlight, so added that. But now when i dig it up it doesn't update correctly so that might be harder part |
| 22:10 |
MTDiscord |
<.zenonseth> thanks |
| 22:33 |
|
panwolfram joined #luanti-dev |
| 22:37 |
MTDiscord |
<wsor4035> Be nice of you could fix the every chunk lighting jank. Pretty easy to replicate with we |
| 22:38 |
MTDiscord |
<.zenonseth> i think in the past few months ive only gotten jank once and it may have been due to using a machine to dig, so not sure how to reproduce tbh |
| 22:41 |
MTDiscord |
<wsor4035> Just we a large solid block |
