| Time |
Nick |
Message |
| 01:04 |
|
smk joined #minetest |
| 01:22 |
|
amfl2 joined #minetest |
| 01:33 |
|
appguru joined #minetest |
| 01:38 |
|
MTDiscord1 joined #minetest |
| 02:10 |
|
amfl2 joined #minetest |
| 02:20 |
|
Trifton joined #minetest |
| 03:16 |
|
frostsnow joined #minetest |
| 03:25 |
MTDiscord |
<jordan4ibanez> Problem? |
| 03:25 |
MTDiscord |
<jordan4ibanez> https://cdn.discordapp.com/attachments/749727888659447960/1198830725445718137/image.png?ex=65c0551e&is=65ade01e&hm=ff4d837ce2681ea1e072fe7605f6611e8183c517ea414edd9b15be7973e5e6b2& |
| 03:27 |
MTDiscord |
<jordan4ibanez> Why yes, that is the original trollface I grabbed from the first commit of minetest ever made |
| 03:27 |
MTDiscord |
<jordan4ibanez> He's colorized in the shader |
| 04:24 |
|
YuGiOhJCJ joined #minetest |
| 05:00 |
|
MTDiscord joined #minetest |
| 05:27 |
|
Sobinec joined #minetest |
| 05:31 |
|
fluxionary_ joined #minetest |
| 06:05 |
|
qqq joined #minetest |
| 06:17 |
|
Sobinec joined #minetest |
| 07:05 |
|
tarsovbak joined #minetest |
| 07:27 |
|
liceDibrarian joined #minetest |
| 07:51 |
|
tarsovbak1 joined #minetest |
| 07:56 |
|
tarsovbak joined #minetest |
| 08:41 |
|
YuGiOhJCJ joined #minetest |
| 08:49 |
|
TomTom_ joined #minetest |
| 09:10 |
|
calcul0n joined #minetest |
| 09:21 |
|
tarsovbak joined #minetest |
| 09:33 |
|
Sobinec joined #minetest |
| 10:17 |
MTDiscord |
<jordan4ibanez> Okay so I did some more testing, and now it has a temporary color shader, on top of the colors that are built into the model so I decided to cycle through the channels and then you get this https://youtu.be/qA79q3Nheic?feature=shared |
| 10:18 |
|
Sobinec joined #minetest |
| 10:20 |
MTDiscord |
<jordan4ibanez> Now you can have problem? in 3 different colors, fancy |
| 10:28 |
|
chmodsayshello joined #minetest |
| 10:32 |
|
Guest7 joined #minetest |
| 10:44 |
|
Guest50 joined #minetest |
| 10:46 |
greeter |
huh, the minetest server works better if you reboot it more than once every three months. go figure |
| 11:05 |
|
BadComoc joined #minetest |
| 11:06 |
|
s20 joined #minetest |
| 11:21 |
|
Sobinec joined #minetest |
| 11:47 |
|
BadComoc_ joined #minetest |
| 12:34 |
|
Sobinec joined #minetest |
| 12:57 |
|
Sobinec joined #minetest |
| 13:12 |
|
jaca122 joined #minetest |
| 13:30 |
|
calcul0n joined #minetest |
| 14:07 |
|
kamdard joined #minetest |
| 14:10 |
|
calcul0n joined #minetest |
| 14:11 |
MTDiscord |
<danil_2461> are you working on the frontend of mtr? |
| 15:01 |
|
Cork joined #minetest |
| 15:03 |
|
Desour joined #minetest |
| 15:18 |
|
appguru joined #minetest |
| 15:31 |
|
tarsovbak joined #minetest |
| 15:49 |
|
definitelya joined #minetest |
| 15:51 |
|
tarsovbak joined #minetest |
| 16:11 |
|
sparky4 joined #minetest |
| 16:17 |
|
fluxionary_ joined #minetest |
| 16:19 |
|
khimaros_ joined #minetest |
| 16:38 |
|
fluxionary_ joined #minetest |
| 16:57 |
|
appguru joined #minetest |
| 17:01 |
|
khimaros_ joined #minetest |
| 17:05 |
|
whosit joined #minetest |
| 17:11 |
whosit |
hello. It's not clear from documentation what is the lifetime of the particle spawner with time=0. Does it disappear when mapblock is unloaded? If it does, how do I use the `id` that add_particlespawner returns? |
| 17:12 |
whosit |
If I just have a table storing those ids, it will fill up with invalid ids? since I can't clear them up on mapblock unloading (there's no callback for that?) |
| 17:13 |
|
calcul0n joined #minetest |
| 17:23 |
whosit |
hmm... looks like I should store the particle spawner id in node meta... |
| 17:24 |
appguru |
I don't think particle spawners persist. |
| 17:24 |
appguru |
(whereas the point of node meta is that it persists) |
| 17:25 |
whosit |
right, and ids will be reused... |
| 17:26 |
whosit |
I can't get time=0 particle spawner to "despawn" by leaving the area... |
| 17:26 |
whosit |
So, they are kept somewhere? |
| 17:27 |
whosit |
the question is: how do I attach a infinite particle spawner to a node? |
| 17:28 |
appguru |
whosit: As far as I can see and remember, particle spawners are managed separately from mapblocks. They do "disappear" on clients when they are out of range, but I don't think they disappear on the server (until the server is rebooted, they aren't persisted). If a client gets "in range" again, the particlespawner should appear again. So your table shouldn't fill up with "invalid IDs". |
| 17:29 |
MinetestBot |
[git] cx384 -> minetest/minetest: Tool specific pointing and blocking pointable type (#13992) 5958714 https://github.com/minetest/minetest/commit/59587143091a150ac496b20c2cddab9352c6d3fe (2024-01-22T17:27:08Z) |
| 17:30 |
appguru |
I think this is somewhat tricky. I would add the "infinite particlespawner" on demand using a LBM (first checking if there isn't a particlespawner already), and I would keep track of these particlespawners in a table [hashed node position] = particlespawner id. I would periodically poll positions in this table - if I get an ignore node, I would delete the particlespawner (mapblock has been unloaded). |
| 17:31 |
appguru |
whosit: you can see a rough implementation of this here: https://github.com/spiraling-down/game/blob/master/mods/sd_map/node_particles.lua |
| 17:31 |
whosit |
this is partially what I do: https://github.com/mt-mods/abritorch/pull/6/files |
| 17:31 |
whosit |
except polling, hmm.. |
| 17:35 |
whosit |
thank you appguru, this seems to be what I have to do |
| 17:35 |
appguru |
no problem :) |
| 17:37 |
whosit |
also, what is the difference between minetest.register_on_dignode and nodedef.on_destruct? seems like on_destruct is more fitting for this? |
| 17:42 |
appguru |
IIRC on_dignode is for player-caused actions whereas on_destruct also includes minetest.remove_node or similar. on_destruct is indeed more fitting. |
| 17:42 |
appguru |
but it's tricky to keep track of a node without polling if you don't control the entire game |
| 17:43 |
|
mrkubax10 joined #minetest |
| 17:43 |
appguru |
for example, what if someone replaces your torches using worldedit (voxelmanip)? AFAIK, that won't trigger on_destruct. |
| 17:44 |
whosit |
right... but polling will take care of that... |
| 17:45 |
appguru |
yep, that's how you do it |
| 17:45 |
whosit |
what's the best way to throttle that globalstep I wonder... |
| 17:45 |
appguru |
if you want to be clever, you could keep track of the count of torches. the more torches there are, the less frequently you run the globalstep. |
| 17:46 |
appguru |
besides that, profile and tweak :) |
| 17:47 |
whosit |
feels like the best way would be to do constant amount of work each globalstep, so something like a queue that processes fixed amount of ids... |
| 17:49 |
whosit |
why it's so hard X) |
| 17:51 |
|
tarsovbak joined #minetest |
| 17:51 |
jonadab |
Then you just have to decide which tasks it's ok to skip when the queue is overfull, versus which ones are worth slowing down the game for in that case. |
| 17:52 |
jonadab |
Unless you want to allow the queue to grow arbitrarily large and get further and further behind. |
| 17:54 |
whosit |
if only we could just attach stuff to nodes and let MT keep track of it ;) |
| 18:08 |
|
Talkless joined #minetest |
| 18:20 |
|
Talkless joined #minetest |
| 18:43 |
whosit |
another way could be to create an entity that would call on_deactivate and remove the spawners?.. |
| 18:44 |
|
Trifton_ joined #minetest |
| 18:52 |
|
grorp joined #minetest |
| 18:56 |
|
BadComoc joined #minetest |
| 18:56 |
|
Trifton joined #minetest |
| 19:07 |
MinetestBot |
[git] appgurueu -> minetest/minetest: Address `set_player_privs` footgun (#14297) afc48cf https://github.com/minetest/minetest/commit/afc48cf2242d576aed2371b4763a71fec8739857 (2024-01-22T19:06:03Z) |
| 19:11 |
|
___nick___ joined #minetest |
| 19:24 |
|
___nick___ joined #minetest |
| 19:26 |
|
___nick___ joined #minetest |
| 19:58 |
|
HumanG33k joined #minetest |
| 20:00 |
|
HumanG33k joined #minetest |
| 20:01 |
|
HumanG33k joined #minetest |
| 20:03 |
|
HumanG33k joined #minetest |
| 20:27 |
|
syncopia joined #minetest |
| 20:40 |
|
chmodsayshello joined #minetest |
| 20:44 |
chmodsayshello |
I know I asked this earlier today, but did so while debugging a selfwritten IRC client, so I am not too sure whether the message actually got though :P |
| 20:44 |
chmodsayshello |
Anyway: is there such a thing as a minetest "release cycle" (like a new minetest version all x months)… What determines the date of another stable engine version? |
| 20:45 |
celeron55 |
it's "debian style" - it's released when it's ready |
| 20:47 |
chmodsayshello |
but, I mean, there is a feature freeze? Is it just the coredevs saying "alright, we've got enoght features for a release"? |
| 20:50 |
celeron55 |
a milestone for the next release is built up consisting of features and issues. it lives during development according to what seems possible and/or likely to happen "soon enough". once it's looking like a meaningful amount of features and fixes have been merged, then the remaining ones are merged or gotten off the list and then the feature freeze begins and release candidates are made |
| 20:50 |
celeron55 |
feature freeze lasts until the release is finally made, and then the cycle repeats |
| 20:51 |
chmodsayshello |
Oooh, yeah, now the roadmap approval I needed on a PR of mine makes sense, thanks! |
| 20:52 |
celeron55 |
the core devs can't just make a release. at the least the feature freeze is to be had, but generally a milestone completion is seen through before that happens, in order to have a meaningful realease |
| 20:52 |
celeron55 |
release* |
| 20:53 |
celeron55 |
the roadmap approval is kind of a separate thing from the release cycle |
| 20:56 |
celeron55 |
i wonder if we have a high level overview of that in place anywhere |
| 20:58 |
celeron55 |
this is a bit complicated to describe on a whim... basically you have two options with a PR: either you do something that's on the pre-written roadmap (which is updated annually-ish), or you submit absolutely anything you like but a core dev has to individually approve the concept |
| 20:58 |
chmodsayshello |
Actually, it seems like it: https://dev.minetest.net/Releasing_Minetest |
| 20:59 |
chmodsayshello |
sorry, my bad for not finding that |
| 20:59 |
celeron55 |
once the PR is concept-approved in either way, then it's subject to the normal review process |
| 21:00 |
celeron55 |
see also these https://github.com/minetest/minetest/blob/master/.github/CONTRIBUTING.md https://github.com/minetest/minetest/blob/master/doc/direction.md |
| 21:00 |
Krock |
even with the feature freeze there were bad releases in the past 8) |
| 21:01 |
Krock |
happens |
| 21:13 |
MTDiscord |
<jordan4ibanez> I am currently building the rendering engine |
| 21:14 |
MTDiscord |
<danil_2461> thats what i was trying to say |
| 21:14 |
MTDiscord |
<danil_2461> good luck! |
| 21:14 |
MTDiscord |
<jordan4ibanez> Thanks. It's wgpu and SDL2, feels luxurious tbh |
| 21:14 |
|
jaca122 joined #minetest |
| 21:14 |
MTDiscord |
<danil_2461> i wonder if this will have GOOD mobile support.. :juanchi_face: |
| 21:15 |
MTDiscord |
<danil_2461> mayhe not |
| 21:15 |
MTDiscord |
<danil_2461> doubt any of you would want to delve into the Andrew developement |
| 21:16 |
MTDiscord |
<rollerozxa> Andrew development |
| 21:16 |
MTDiscord |
<danil_2461> Andrew |
| 21:19 |
MTDiscord |
<jordan4ibanez> Yeah it has opengl es |
| 21:23 |
MTDiscord |
<danil_2461> neat |
| 21:27 |
MinetestBot |
[git] appgurueu -> minetest/minetest: Fix revoke callbacks being run for `false` values passed to `set_priv… f0180ad https://github.com/minetest/minetest/commit/f0180ad488ec547758f56105b05e043db518086b (2024-01-22T21:24:32Z) |
| 21:41 |
|
rustaceous8 joined #minetest |
| 21:48 |
MinetestBot |
[git] appgurueu -> minetest/minetest: Minor documentation formatting fixes f6ecd93 https://github.com/minetest/minetest/commit/f6ecd931dc08a7a5a48b5d20787f6d8ba54462fc (2024-01-22T21:41:33Z) |
| 22:04 |
|
bwarden joined #minetest |
| 22:34 |
|
appguru joined #minetest |
| 22:34 |
|
rustaceous8 joined #minetest |
| 23:37 |
|
panwolfram joined #minetest |
| 23:46 |
|
khimaros_ joined #minetest |
