Time |
Nick |
Message |
00:02 |
srifqi |
done |
00:08 |
|
srifqi1 joined #minetest-dev |
00:27 |
|
YuGiOhJCJ joined #minetest-dev |
00:51 |
|
YuGiOhJCJ joined #minetest-dev |
01:50 |
|
calculon joined #minetest-dev |
02:35 |
|
fluxionary joined #minetest-dev |
02:39 |
|
jonadab joined #minetest-dev |
03:04 |
|
YuGiOhJCJ joined #minetest-dev |
05:00 |
|
MTDiscord joined #minetest-dev |
06:49 |
|
calcul0n joined #minetest-dev |
09:36 |
|
MTDiscord1 joined #minetest-dev |
10:53 |
|
appguru joined #minetest-dev |
11:19 |
|
MTDiscord2 joined #minetest-dev |
12:14 |
|
imi joined #minetest-dev |
12:29 |
|
diceLibrarian joined #minetest-dev |
12:40 |
|
erle joined #minetest-dev |
14:15 |
erle |
what part of the engine governs at which distance sprites become inivisible? |
14:20 |
|
grorp joined #minetest-dev |
14:25 |
celeron55 |
you're getting too far ahead |
14:25 |
celeron55 |
what do you mean by sprite? |
14:25 |
celeron55 |
or this is an even better question: what are you doing? |
14:27 |
erle |
i am moving a way from a sprite backwards and at some point the sprite becomes invisible |
14:28 |
erle |
an entity that is an upright sprite |
14:28 |
erle |
221 visual = "upright_sprite", |
14:28 |
erle |
222 visual_size = { x = 1, y = 1 }, |
14:28 |
erle |
223 physical = false, |
14:28 |
erle |
it is a photo from the xcam mod that i nailed to the wall. |
14:31 |
celeron55 |
so it is an entity |
14:31 |
celeron55 |
i would assume the entity gets unloaded and this has nothing to do with the sprite |
14:33 |
celeron55 |
to adjust the range from players where objects (including entities) are activated you need to adjust active_block_range and active_object_send_range_blocks |
14:34 |
celeron55 |
outside of active_block_range they are packed away as static data in the mapblock and outside of active_object_send_range_blocks they aren't sent to the client |
14:35 |
celeron55 |
(and then there's the forceload blocks mechanism that could help in some situations) |
14:36 |
celeron55 |
i'm sure this is described somewhere better than i can do it |
14:36 |
celeron55 |
i can't find such a place though... |
14:37 |
celeron55 |
maybe there's a FAQ somewhere where this could be put in |
14:40 |
celeron55 |
(all this is essentially an artefact of the pseudo-infinite world size which makes it essential to somehow curb the amount of stuff that has to be continuously updated and tracked) |
14:42 |
celeron55 |
(but to answer the question you didn't yet ask, yes: intuitively it all probably could still be baked into the mapblock meshes based on the static data and rendered efficiently that way, when not being active) |
14:43 |
celeron55 |
(that's not implemented and there probably is neither an issue nor a PR for such) |
14:48 |
grorp |
rubenwardy: since #13906, auto_install_spec is always a string. i just forgot to update that line. |
14:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/13906 -- Offer ContentDB updates for leftover bundled Minetest Game by grorp |
14:48 |
grorp |
#13970 |
14:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/13970 -- Fix auto_install_spec being used as a table by grorp |
14:57 |
erle |
thanks celeron55 |
15:00 |
erle |
celeron55 i had indeed set one of those properties to 1 for some reason |
15:00 |
erle |
(probably to test loading and unloading and then i forgot or so) |
15:10 |
rubenwardy |
RE: celeron55's roadmap - the difference between a roadmap and a wishlist is whether you plan to work on these things :) |
15:10 |
rubenwardy |
some of my MT goals are feeling more wishlisty at this point |
15:12 |
MTDiscord |
<warr1024> I just call everything a wishlist, and whatever actually turned out to be a roadmap can only be evaluated in retrospect. |
15:13 |
celeron55 |
i don't even see what the difference between a roadmap and wishlist is as i have about 100x more things that i'd like to do in my life than what i have the time and resources to do |
15:13 |
celeron55 |
s/time and resources to do/time and resources for doing/g |
15:13 |
rubenwardy |
step 1: human cloning |
15:14 |
celeron55 |
i'm even questioning that 100x. maybe it's more like 1000x? |
15:14 |
celeron55 |
give me a couple of years and it'll be 10000x |
15:15 |
rubenwardy |
I have a "things to do" list that contains all the hobby projects I want to do. There's over 40 projects on there, each are fairly big |
15:15 |
celeron55 |
yeah my personal "global todo list" is a text file with 700 lines. but i pruned that recently, the unpruned version is multiple times that, plus then there are the project specific todo lists |
15:16 |
celeron55 |
it generally takes multiple days to get a couple of lines off the list |
15:16 |
celeron55 |
or, a list |
15:17 |
celeron55 |
years ago i grew to live with the fact that i'll never be able to do more than a few percent of what i want to do |
15:17 |
celeron55 |
i still write them down though |
15:17 |
celeron55 |
it seems like good practice |
15:17 |
rubenwardy |
opportunity cost hits hard |
15:20 |
celeron55 |
and yes, i do name the lists to-do lists. not wishlists |
15:20 |
celeron55 |
a to-do list is an impossible concept |
15:20 |
celeron55 |
so might as well reuse that name for whatever these are |
15:22 |
celeron55 |
"idea graveyard" would probably be a better name |
15:30 |
MTDiscord |
<warr1024> I've heard "icebox" as a supposedly industry standard term. |
15:31 |
MTDiscord |
<warr1024> And of course I assume that by "industry" they mean the wishing in one hand and shifting in the other industry, I guess. |
15:50 |
|
fluxionary joined #minetest-dev |
16:08 |
celeron55 |
but at the moment you get the idea, you don't know yet how it'll end up being prioritized |
16:09 |
celeron55 |
it has to fight with the other stuff on the list first |
16:09 |
celeron55 |
to find its place |
16:11 |
|
fluxionary joined #minetest-dev |
16:11 |
MTDiscord |
<warr1024> I know that the probability that it ends up in the vanishingly small section at the top of the list that actually has a chance of ever getting attention is miniscule, and where it appears anywhere else on the list is of no practical relevance. Most of those things are just there to be able to say they're already on some list so stop asking about them. |
16:14 |
erle |
next up: hack the forum to put ”bigger map size” on top of the list |
16:15 |
MTDiscord |
<warr1024> Just set visual_size on the map item to be larger. Done. |
16:16 |
erle |
unfortunately, that is defeated by bilinear filtering |
16:17 |
|
grorp1 joined #minetest-dev |
16:21 |
celeron55 |
warr1024: well it's also about adding notes about them in case they pop up in the future, or in case something nudges the priority way up again |
16:22 |
celeron55 |
in the ideal situation you're all set for just doing it then |
16:22 |
celeron55 |
if the priority changes |
16:36 |
rubenwardy |
sfan5: please may you make a windows build for a release candidate? |
17:16 |
|
json joined #minetest-dev |
17:18 |
json |
Congratulations on minetest release candidate 1! Thank you for the work done |
17:33 |
jonadab |
celeron55: Do you keep separate prioritized and untriaged lists? |
17:36 |
rubenwardy |
release candidate (still needs Windows builds): https://forum.minetest.net/viewtopic.php?t=29937 |
17:40 |
json |
Minetest Game has fallen |
17:42 |
json |
Yay! |
17:49 |
sfan5 |
rubenwardy: done and added to forum post |
17:50 |
rubenwardy |
thanks |
17:56 |
|
Desour joined #minetest-dev |
18:08 |
celeron55 |
jonadab: no, it's a prioritized list where after a screenful or two it becomes essentially non-prioritized |
18:22 |
|
appguru joined #minetest-dev |
20:31 |
|
YuGiOhJCJ joined #minetest-dev |
20:41 |
MTDiscord |
<mistere_123> @Josiah (Sie/Sie) you approved my docs PR but forgot to add the two approvals tag? |
21:07 |
MTDiscord |
<mnh48> is the font selection menu not exist in the RC1 of 5.8.0?? |
21:07 |
MTDiscord |
<mnh48> I only see setting for font size |
21:08 |
MTDiscord |
<wsor4035> Josiah isnt a core dev |
21:16 |
MTDiscord |
<mistere_123> Oh. |
21:17 |
MTDiscord |
<mistere_123> Figures. |
21:18 |
rubenwardy |
mnh48: it's in advanced dettings |
21:27 |
MTDiscord |
<mnh48> oh |
21:27 |
MTDiscord |
<mnh48> so I need to check the advanced setting first before the setting search look there |
21:28 |
erle |
yeah this advanced settings thing is very weird |
21:28 |
erle |
you have some tabs for the more obscure ones and then you also have the show advanced settings |
21:29 |
erle |
but surely someone is already planning to streamline all of that a bit |
21:30 |
MTDiscord |
<mnh48> the advanced setting is fine, I just thought that the search box will look in there as well by default which is apparently not the case |
21:32 |
MTDiscord |
<mnh48> searching font without checking advanced setting: https://file.mnh48.moe/public/2023/11/f97aaaWM8FTPji4mcA.png |
21:32 |
MTDiscord |
<mnh48> with checking: https://file.mnh48.moe/public/2023/11/2fc3323vaYFQFcSOPq.png |
21:32 |
erle |
i think Advanced → Advanced is not really fine |
21:33 |
erle |
this needs some thought (later ig) |
21:37 |
[MTMatrix] |
<localhost> Advanced menu selector :D |
21:50 |
|
Wuzzy joined #minetest-dev |
21:52 |
Wuzzy |
hey there. ive heard about the feature freeze. soo i wonder, has minetest.features been updated yet? because this table tends to be updated rather randomly imho |
21:52 |
Wuzzy |
i mean are the any important changes to the Lua API where it should be exposed to minetest.features? |
22:03 |
MTDiscord |
<warr1024> We have a standard required process to bump the protocol version, since a couple versions ago. This is necessary because not every release involves something that somebody thought to make a feature flag for, but we often need to be able to tell releases apart of reasons such as bugs and other things that only get discovered later. |
22:04 |
MTDiscord |
<warr1024> We should probably ALSO bump features flags if there's something we realize ahead of time is likely to be relevant for that, but the protocol version thing is a fail-safe even if we miss something. |
22:20 |
Wuzzy |
oh its not about that. i thought of minetest.features to be useful for lua scripts to check if a feature is available for compability and such |
22:21 |
Wuzzy |
would be the player physics overrides be a possible candidate to minetest.features? |
22:22 |
MTDiscord |
<warr1024> If you're suggesting improving the usefulness and consistency of minetest.features then yeah, I'm in favor of that too (as long as we never try to solely rely on it again for the general case). |
22:33 |
sfan5 |
minetest.features should usually be updated right in the PR that adds something notable |
22:34 |
MTDiscord |
<warr1024> Ideally, yes, unless it only becomes obvious long after the fact. |
23:33 |
|
panwolfram joined #minetest-dev |