| Time |
Nick |
Message |
| 00:54 |
|
AliasAlreadyTake joined #minetest-dev |
| 01:08 |
|
kilbith_ joined #minetest-dev |
| 01:13 |
Pexin |
https://github.com/minetest/minetest/pull/11939 |
| 01:13 |
Pexin |
I mean #11939 |
| 01:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/11939 -- Restore bouncy behavior by pecksin |
| 01:29 |
|
kilbith__ joined #minetest-dev |
| 01:38 |
erlehmann |
when has “pointing out what exactly breaks” become “whining” btw? |
| 01:38 |
erlehmann |
is this minetest lingo? |
| 01:38 |
erlehmann |
i know whining as just complaining *without* any actionable content |
| 03:29 |
|
queria joined #minetest-dev |
| 03:33 |
|
queria joined #minetest-dev |
| 04:29 |
|
tekakutli joined #minetest-dev |
| 04:34 |
|
tekakutli joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:04 |
|
olliy1or joined #minetest-dev |
| 06:15 |
|
olliy joined #minetest-dev |
| 07:02 |
|
Pexin joined #minetest-dev |
| 07:12 |
celeron55 |
https://gist.github.com/celeron55/e16200de201750869f576187ee581f2c |
| 07:12 |
celeron55 |
gist.github.com is my blog now |
| 07:25 |
erlehmann |
> - non-first/third-person controls and cameras have to be supported, again because we're wasting the engine by locking it into a special case. |
| 07:25 |
erlehmann |
cheat clients already have this |
| 07:25 |
erlehmann |
what is missing is a way to script them from a game ig? |
| 07:28 |
celeron55 |
well it needs to be in the hands lf gamedevs instead of players directly, as you can imagine from reading the first lines |
| 07:28 |
celeron55 |
of* |
| 07:31 |
|
v-rob joined #minetest-dev |
| 07:33 |
celeron55 |
i'm actually kind if tired of hearing about cheat clients. they're useless to me, their developers need to focus their effort upstream |
| 07:34 |
celeron55 |
it's wasted work when you consider the long term benefit of MT |
| 07:35 |
celeron55 |
if all C++ devs went to cheat clients, the project would die |
| 07:36 |
celeron55 |
if nobody spent a single second on cheat clients, the project would be better off |
| 07:46 |
erlehmann |
in my experience, people develop cheat clients because the regular client have worse CSM & accessability features |
| 07:46 |
erlehmann |
for example, the ability to selectively disable rendering of specific things (like entities) can prevent client lag |
| 07:47 |
erlehmann |
all the “easy” (privilege bypass) hacks are super uninteresting |
| 07:50 |
erlehmann |
celeron55 how do you envision the integration of something like dragonfire or waspsaliva into upstream mte? |
| 07:50 |
erlehmann |
“focus efforts upstream” |
| 07:50 |
erlehmann |
i mean obv those features have not been considered in the past |
| 07:50 |
erlehmann |
or even been rejected |
| 07:51 |
erlehmann |
(some for good reason) |
| 07:53 |
|
freshreplicant[m joined #minetest-dev |
| 07:54 |
|
v_rob joined #minetest-dev |
| 07:55 |
|
wsor4035 joined #minetest-dev |
| 08:24 |
|
Taoki joined #minetest-dev |
| 08:58 |
|
Fleckenstein joined #minetest-dev |
| 08:59 |
|
Fleckenstein joined #minetest-dev |
| 09:12 |
|
calcul0n_ joined #minetest-dev |
| 09:31 |
|
tech_exorcist joined #minetest-dev |
| 09:52 |
sfan5 |
he didn't say integration of code those clients already have |
| 09:53 |
sfan5 |
minus possible refactor/cleanup efforts writing an API for client-lua to freely control the camera is wasted work (from the POV of upstream) |
| 09:54 |
sfan5 |
an API that is acceptable to us needs to look different because it has to be on the server, transfer state over network packets and cater to gamedev needs |
| 09:55 |
sfan5 |
anyway what I came here to ask was: didn't we have a PR in MTG that compressed all OBJ files? did I imagine that? |
| 10:11 |
|
YuGiOhJCJ joined #minetest-dev |
| 10:21 |
|
appguru joined #minetest-dev |
| 10:38 |
|
Fixer joined #minetest-dev |
| 10:42 |
|
jonadab joined #minetest-dev |
| 13:04 |
|
kilbith joined #minetest-dev |
| 13:04 |
|
appguru joined #minetest-dev |
| 13:06 |
MTDiscord |
<numzero> btw regarding compatibility, 5.3.0 crashes when connecting to master devtest. is that ok? |
| 13:08 |
celeron55 |
doesn't sound right |
| 13:35 |
Krock |
is there a backtrace? maybe a new test was added to explicity check against this problem |
| 13:42 |
Krock |
will merge #11863 in 10 minutes |
| 13:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/11863 -- Fully remove bitmap font support by sfan5 |
| 13:43 |
Krock |
did a quick test. works. |
| 13:45 |
MTDiscord |
<numzero> in debug, it crashes with: |
| 13:45 |
MTDiscord |
<numzero> Assertion failed: liquid_type == LIQUID_SOURCE (/home/numzero/projects/minetest/5.3/src/nodedef.cpp: updateTextures: 743) |
| 13:46 |
Krock |
yes, afaik wuzzy improves the uses of liquid nodes |
| 13:46 |
Krock |
*improved |
| 13:49 |
MTDiscord |
<numzero> in release, it SEGVs in TextureSource::getTextureAverageColor called from updateTextures called from updateTextures |
| 13:52 |
Krock |
_._ |
| 13:52 |
Krock |
merging |
| 13:53 |
Krock |
done |
| 14:12 |
celeron55 |
numzero: it looks like 5.3.0 doesn't allow a node to have the drawtype of a liquid but not actually be a liquid |
| 14:14 |
celeron55 |
and not even so but also something that looks like flowing liquid has to has to be flowing liquid and something that looks like source liquid has to be source liquid |
| 14:15 |
celeron55 |
-has to |
| 14:16 |
celeron55 |
#10737 |
| 14:16 |
ShadowBot |
https://github.com/minetest/minetest/issues/10737 -- Can use "liquid" and "flowingliquid" drawtypes even if liquidtype="none" by Wuzzy2 |
| 14:27 |
Krock |
hmm. compat code shouldn't be too difficult. there was a protocol version bump in the meantime afaik |
| 14:28 |
Krock |
for NDT_FLOWINGLIQUID and NDT_LIQUID, the liquid_type must be forced to expected values in older builds |
| 14:28 |
Krock |
s/in older/for older/ |
| 15:04 |
sfan5 |
it can be made to not crash but the expected features won't work for sure |
| 15:10 |
celeron55 |
the client doesn't do a whole lot with liquids though other than showing them |
| 15:10 |
celeron55 |
so maybe it could be usable |
| 15:49 |
MTDiscord |
<josiah_wi> Where are the defaults for Lua definitions determined? I found the default values for the struct as defined in the engine source, but they do not match the values listed in lua_api.txt. |
| 15:50 |
celeron55 |
which definition? |
| 15:50 |
MTDiscord |
<josiah_wi> ObjectProperties |
| 15:51 |
MTDiscord |
<josiah_wi> I grepped the engine source and I found that they're also set when loading serialized properties, and in c_content.h when they're being set from the Lua API. |
| 15:52 |
MTDiscord |
<josiah_wi> c_content.cpp* |
| 15:57 |
MTDiscord |
<josiah_wi> Does the Lua code somehow set default values in the registration? |
| 15:57 |
celeron55 |
i don't think there are any defaults in builtin for objects in general |
| 15:57 |
celeron55 |
the default item of course has default properties though |
| 15:58 |
celeron55 |
and... maybe the player, i didn't check |
| 15:58 |
celeron55 |
but if you add an entity that you made yourself, i think the only thing that matters is read_object_properties and the default values of ObjectProperties in src/object_properties.h |
| 16:00 |
MTDiscord |
<josiah_wi> Interesting. Thank you. |
| 16:00 |
celeron55 |
does it seem like it isn't so? |
| 16:01 |
celeron55 |
it's possible lua_api.txt lists wrong defaults |
| 16:01 |
celeron55 |
in fact i don't even know if it's supposed to list defaults, or just some examples |
| 16:02 |
MTDiscord |
<josiah_wi> I have not tested it yet, but I may do so to see what happens. I have been tasked with getting the correct default values for the minetest_docs project, and the disagreement between object_properties.h and lua_api.txt means I need a very good reason before saying lua_api.txt is wrong. xD |
| 16:02 |
celeron55 |
it certainly doesn't state that they would be defaults |
| 16:02 |
MTDiscord |
<josiah_wi> I have not looked at lua_api.txt myself - maybe I should; that was a reviewer's concern. |
| 16:03 |
celeron55 |
so if they aren't defaults, lua_api.txt isn't wrong... it just doesn't list defaults |
| 16:03 |
MTDiscord |
<josiah_wi> Ah. That would make sense. Maybe someone confused that with the defaults for the player specifically, then. |
| 16:07 |
MTDiscord |
<josiah_wi> It does list defaults, and they look just like the defaults in object_properties.h. Some confusion must have crept in somehow during review. |
| 16:10 |
MTDiscord |
<josiah_wi> lua_api.txt says physical defaults to true, and object_properties.h defaults it to false. |
| 16:17 |
celeron55 |
yes, and lua_api.txt has no say about it, object_properties.h is very rude |
| 16:18 |
MTDiscord |
<luatic> As said, when reading the properties from a Lua table, different defaults might be set |
| 16:20 |
MTDiscord |
<luatic> Hmm that's weird, taking physical as an example |
| 16:20 |
MTDiscord |
<luatic> getboolfield(L, -1, "physical", prop->physical); |
| 16:20 |
MTDiscord |
<luatic> So the default of false would indeed be preserved |
| 16:21 |
MTDiscord |
<josiah_wi> heh |
| 16:22 |
MTDiscord |
<luatic> This seems to be the case for most fields, but not collisionbox or selectionbox |
| 16:22 |
MTDiscord |
<luatic> prop->collisionbox = read_aabb3f(L, -1, 1.0); |
| 16:23 |
celeron55 |
there's an if condition to make that line not happen if the collisionbox doesn't exist in the definition table |
| 16:23 |
MTDiscord |
<luatic> The constructor appears to include two other defaults: ObjectProperties::ObjectProperties() { textures.emplace_back("no_texture.png"); colors.emplace_back(255,255,255,255); } |
| 16:24 |
MTDiscord |
<luatic> celeron55: Yes, this default only applies to omitted fields in a boxdef I assume |
| 16:25 |
celeron55 |
you mean the 1.0? |
| 16:25 |
celeron55 |
it's a scaling factor |
| 16:26 |
celeron55 |
applied to every field |
| 16:26 |
MTDiscord |
<luatic> ah |
| 16:26 |
MTDiscord |
<luatic> then NVM |
| 16:29 |
MTDiscord |
<luatic> Totally different topic, #11902 requires a final benevolent dictator decision - I agree with Zughy on that one. |
| 16:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/11902 -- Rotate custom moon texture the right way by Zughy |
| 16:29 |
MTDiscord |
<luatic> celeron55: ^ |
| 16:32 |
|
fluxionary joined #minetest-dev |
| 17:09 |
|
asdflkj_sh joined #minetest-dev |
| 17:54 |
|
jonadab joined #minetest-dev |
| 18:23 |
Krock |
Does anyone already take care of #10737 ? If not, I'll write a fix for that. |
| 18:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/10737 -- Can use "liquid" and "flowingliquid" drawtypes even if liquidtype="none" by Wuzzy2 |
| 18:23 |
Krock |
guess I will have to test with an old Windows binary as mine broke due to irrlichtmt changes |
| 18:25 |
celeron55 |
well, wine is, after all, the de-facto ABI for linux |
| 18:25 |
celeron55 |
feel free to fix it, i certainly didn't start anything |
| 18:29 |
Krock |
crash in ntdll. not the place I'd expect but good enough. |
| 18:29 |
Krock |
generateImagePart also spams a lot about "invalid modification", presumably an unknown modifier |
| 18:35 |
|
fluxionary joined #minetest-dev |
| 18:39 |
celeron55 |
putting an assert into a function that parses data coming from network isn't a good design at all. If it really wanted to shut down it should have thrown a descriptive exception instead, but really oftentimes invalid network input should be more like silently discarded (but in a smart way. in a way that is likely to allow some sort of safe compatibility in cases like this) |
| 18:40 |
Krock |
smart way: warning, and default to something |
| 18:40 |
celeron55 |
the hard limits are meant to be done using the protocol version, not some random serialization function |
| 18:41 |
celeron55 |
and yes, it's likely i wrote that assert |
| 18:41 |
celeron55 |
11 years ago |
| 18:42 |
Krock |
> : page fault on read access to 0x00000000 in 64-bit code (0x00000000004c7403). |
| 18:42 |
Krock |
guess I won't use Wine then |
| 18:43 |
celeron55 |
https://github.com/minetest/minetest/commit/eed727c61b |
| 18:44 |
celeron55 |
here it is, one of the original commits making 0.4 a reality |
| 18:54 |
Krock |
appimage does not want to be debugged either |
| 18:56 |
Krock |
0 0x000000000060bc0e in ?? () |
| 18:56 |
Krock |
I hate this |
| 18:57 |
celeron55 |
i guess the easiest way is to just clone the repo, checkout 5.3.0 and build it using the global irrlicht installation (and never installing irrlichtmt globally of course) |
| 18:57 |
Krock |
I need a new build anyway. setup from scratch |
| 18:58 |
celeron55 |
cmake . -DCMAKE_BUILD_TYPE=Release -DBUILD_SERVER=0 -DBUILD_CLIENT=1 -DRUN_IN_PLACE=1 |
| 18:58 |
celeron55 |
there's the line to speed you uåp |
| 18:58 |
celeron55 |
-å |
| 18:58 |
Krock |
-â |
| 18:59 |
Krock |
thanks. that seems to work. |
| 19:03 |
Krock |
god bless I won't miss the copy&paste fixes in the recent MInetest versions |
| 19:03 |
Krock |
s/won't/would/ |
| 19:07 |
MTDiscord |
<josiah_wi> If you keep each build in its own directory you can easily make new builds. |
| 19:10 |
Krock |
[png crashes the client too |
| 19:14 |
celeron55 |
uh oh, that's a way more difficult one |
| 19:15 |
celeron55 |
i suppose there's absolutely no strategy in place for texture modifier cross compatibility of any kind, not even tolerance |
| 19:18 |
celeron55 |
the only correct choice is to disable it until 6.0 |
| 19:20 |
celeron55 |
like, there's absolutely no way [png can be made to do anything reasonable on 5.4 or lower |
| 19:21 |
MTDiscord |
<Jonathon> minetest already requires modders to enforce a minimum version with formspecs, i fail to see how [png is any different |
| 19:21 |
celeron55 |
well that's true |
| 19:22 |
MTDiscord |
<Jonathon> so documentation is another choice |
| 19:23 |
celeron55 |
all these versioning gotchas need to be documented better |
| 19:23 |
MTDiscord |
<Jonathon> something like https://github.com/minetest/minetest/issues/11603 needs to be formalized so the dumpster fire that was figuring out 5.2 from 5.3 does not happen again |
| 19:24 |
sfan5 |
"if you use a feature newer than the client it will usually just not work but no guarantees" has been unofficial policy for a while |
| 19:24 |
MTDiscord |
<Jonathon> ^ |
| 19:28 |
|
fluxionary joined #minetest-dev |
| 19:28 |
celeron55 |
well this seems like an easy issue to get rid of |
| 19:28 |
MTDiscord |
<luatic> sfan5: Have you stress tested dynamic media? When adding 100+ at once, it sometimes SEGFAULTs for me. Note that it works if done across multiple server steps and not "all at once". |
| 19:29 |
sfan5 |
I have not |
| 19:30 |
erlehmann |
celeron55 tbh [png looks like a solution looking for a problem to me |
| 19:33 |
MTDiscord |
<Jonathon> the ironic coming from you given it was a solution to your whining |
| 19:33 |
erlehmann |
uh. what? |
| 19:33 |
MTDiscord |
<luatic> erlehmann: it does have it's usecases |
| 19:33 |
erlehmann |
luatic, i just wonder where |
| 19:33 |
MTDiscord |
<luatic> I have in fact considered using it for the project I'm working on, but refrained as I want 5.4 support |
| 19:34 |
MTDiscord |
<luatic> Consider an entity with a "dynamic" texture |
| 19:34 |
erlehmann |
Jonathon i am pretty sure i never asked for base64 encoded PNGs in texture modifiers, that is horribly cursed |
| 19:34 |
MTDiscord |
<luatic> This texture modifier is almost perfect for this use case: The texture will only be sent to (and generated by) clients which see the CAO |
| 19:35 |
erlehmann |
oh. i bet inline texture modifiers are nice. it is just the base64 PNG thing that seems a poorly-thought-out idea too me. |
| 19:35 |
MTDiscord |
<luatic> Whereas with dynamic media, I have to send the texture to all clients, regardless of whether they will need it or not, as they might need it when seeing the object - and it will already be too late if they object is loaded for them. |
| 19:36 |
MTDiscord |
<luatic> Well, the downsides of it are that it might be resent arbitrarily often. But for small textures - large strings don't fit in texmods anways - it's supposedly fine. |
| 19:36 |
MTDiscord |
<luatic> I would prefer advanced dynamic media though. |
| 19:37 |
erlehmann |
the thing is, this solution is hilariously complex and wasteful for the purpose because of the base64 png choice |
| 19:40 |
Krock |
#11942 |
| 19:40 |
ShadowBot |
https://github.com/minetest/minetest/issues/11942 -- Fix NodeDef backwards compatibility to 5.3.0 by SmallJoker |
| 19:41 |
Krock |
feel free to test |
| 19:41 |
erlehmann |
Jonathon luatic just eyeballing it, there is about 100 bytes or more overhead from the base64 PNG thing. meaning a hypothetical [pbm texture modifier could encode a 10×10 bitmap in less space than the base64 png thing wolud require for a single pixel – and still be easily editable by hand. |
| 19:42 |
MTDiscord |
<luatic> Has Minetest ever supported PBM? |
| 19:43 |
celeron55 |
10x10 seems like a contrived example. use something like 16x16 at least, maybe 16x32 as a realistic example |
| 19:44 |
erlehmann |
celeron55 10x10 = 100. in my tests i found more than 100 bytes overhead, but i wanted to be conservative. the whole overhead comes from the fact that PNG needs about 70 bytes before it starts encoding any type of content (which is why its compression matters less than many people think for small images). |
| 19:44 |
erlehmann |
so you have the base64 encoding of the 70 bytes of overhead in every [png texmod |
| 19:45 |
erlehmann |
this could have been solved in a better way surely |
| 19:46 |
erlehmann |
luatic i think PBM may have been one of the formats that hecks removed, but it also was not used anywhere. not sure about that, will look. |
| 19:49 |
erlehmann |
luatic supported were png, jpg, bmp, pcx, ppm, tga |
| 19:50 |
erlehmann |
i do not want to plug pbm anyway, i just wanted to point out that the [png texture modifier is an ugly and inefficient thing |
| 19:50 |
erlehmann |
and it certainly does not solve any of *my* problems |
| 19:51 |
celeron55 |
a naive texture modifier encodable 10x10 image would consume 534 bytes though |
| 19:51 |
erlehmann |
to me the problem is one of layering |
| 19:52 |
celeron55 |
given you just rolled the raw 4 byte per pixel data into base64, and you'd need the size information also |
| 19:52 |
erlehmann |
uh, how do you get to 534 bytes? |
| 19:53 |
celeron55 |
but anyway, that doesn't matter |
| 19:53 |
erlehmann |
it does not, indeed |
| 19:53 |
celeron55 |
what matters is that it was the PR that was made |
| 19:53 |
erlehmann |
yeah so what was it for? |
| 19:53 |
celeron55 |
there's still time to replace the format if someone feels like it and does the work |
| 19:53 |
erlehmann |
like what game or mod uses it? |
| 19:53 |
erlehmann |
or wants to use it? |
| 19:54 |
erlehmann |
i must have missed that thing |
| 19:54 |
erlehmann |
and Jonathon falsely attributed it to my “whining”, so i guess i am not the only one being confused about why [png was made |
| 19:55 |
erlehmann |
i just want to know the story ^^ |
| 19:56 |
celeron55 |
it makes no sense to wait for imaginary PRs that will never happen, no matter how much you insist on them happening. a texture modifier encoded image is a reasonable feature to have, and what was made is PNG. if you want something else, you'll have to make something else yourself |
| 19:56 |
celeron55 |
if it's measurably better then it will replace [png |
| 19:57 |
erlehmann |
as you know, i am a big fan of understanding problems before i attempt solutions |
| 19:57 |
erlehmann |
so i doubt i will make anything better without understanding why [png was made – except if the choice of format is arbitrary |
| 19:58 |
celeron55 |
the problem seems to be: you generated some image data at runtime, you want to display it to certain players momentarily |
| 19:58 |
celeron55 |
and then throw it away |
| 20:00 |
erlehmann |
i'd rather do this with dynamic media improvements though :/ |
| 20:00 |
Krock |
except that you cannot "throw it away" on client-side. |
| 20:00 |
erlehmann |
right now! |
| 20:01 |
erlehmann |
i can understand the inline image texture modifier desire a bit … i *could* use it for markers on maps. but tbh, it is *way* easier to a) have a static marker image or several b) reach directly into the TGA and burn it in, without needing texture modifiers |
| 20:02 |
erlehmann |
b) is probably the way to go for having trails on maps |
| 20:12 |
celeron55 |
i prefer flexibility to correctness when i can't have both. it needs to be manageable, but i can't see how this isn't manageable |
| 20:15 |
erlehmann |
well, i think about it from the POV of a mod/game author |
| 20:16 |
erlehmann |
to generate that texture, i have to a) generate some bitmap b) encode it to PNG c) encode that to base64 |
| 20:16 |
|
v-rob joined #minetest-dev |
| 20:16 |
erlehmann |
and the result is some opaque string where i have to do the dance in reverse to edit it |
| 20:17 |
erlehmann |
i guess if i would implement it, i'd probably see how far i would get using PNM (i.e. the really wasteful route) and see if that is a better API |
| 20:18 |
erlehmann |
but it needs to be used anyway to figure it out IMO |
| 20:18 |
erlehmann |
so luatic if you get something working using [png – even a proof of concept – ping me |
| 20:21 |
MTDiscord |
<luatic> erlehmann: I'm not using [png |
| 20:21 |
erlehmann |
ah ok |
| 20:21 |
MTDiscord |
<luatic> I just had it planned at some point |
| 20:21 |
MTDiscord |
<luatic> But texture modifiers are currently cached infinitely too |
| 20:21 |
erlehmann |
oh ok lol |
| 20:21 |
erlehmann |
that makes it highly questionable |
| 20:22 |
MTDiscord |
<luatic> As for the two "dances" you mention, they are both actually pretty simple |
| 20:22 |
MTDiscord |
<luatic> One is just minetest.encode_base64 + minetest.decode_png |
| 20:23 |
MTDiscord |
<luatic> minetest.encode_png* |
| 20:23 |
MTDiscord |
<luatic> The other one is minetest.decode_base64 + your own PNG decoder |
| 20:23 |
MTDiscord |
<luatic> And then prefixing with or removing [png: at the beginning |
| 20:24 |
MTDiscord |
<luatic> Another advantage to dynamic media - in it's current form - is that these texture modifiers don't fill up the serverside cache forever |
| 20:24 |
MTDiscord |
<luatic> As soon as the string containing them is dropped, they're gone serverside |
| 20:25 |
MTDiscord |
<luatic> dynamic media is stored on disk, and you can't delete it until the server is shutting down |
| 20:25 |
MTDiscord |
<luatic> If Minetest doesn't cache media files in RAM, that only fills up the disk though - storing the paths in RAM is negligible |
| 20:26 |
sfan5 |
did you miss the possibility of ephemeral media |
| 20:30 |
MTDiscord |
<luatic> Huh? WDYM? |
| 20:30 |
MTDiscord |
<luatic> I use pretty much only ephemeral media |
| 20:32 |
MTDiscord |
<luatic> I am referring to the server's disk being filled up with dynamic media files, not the client media cache |
| 20:36 |
sfan5 |
you can delete files for ephermal media after the function call |
| 20:42 |
MTDiscord |
<luatic> Well then it is kept in RAM? |
| 20:43 |
sfan5 |
no |
| 20:43 |
sfan5 |
a temporary folder, the engine takes care to delete it when it's been delivered |
| 20:44 |
MTDiscord |
<luatic> But what about new clients? |
| 20:44 |
sfan5 |
what about them? |
| 20:44 |
MTDiscord |
<luatic> Does ephemeral=true mean they won't receive the media on join? |
| 20:45 |
sfan5 |
ephemeral is only ever sent to clients that are already on the server |
| 20:45 |
sfan5 |
+media |
| 20:46 |
MTDiscord |
<luatic> hmm, then I misunderstood the docs |
| 20:47 |
MTDiscord |
<luatic> could probably be worded more clearly |
| 20:49 |
sfan5 |
ephemeral=false is for "everyone needs this media now and will in the future, e.g. a player has a new skin" |
| 20:50 |
sfan5 |
ephemeral=true is for "I need to show this media to one or a bunch of players right now" |
| 20:51 |
sfan5 |
s/right now/just once/ |
| 20:52 |
MTDiscord |
<luatic> and what about a 3D skin editing mod ;) |
| 20:53 |
sfan5 |
`true` for the editing phase, `false` when you're done |
| 20:53 |
MTDiscord |
<luatic> the problem is that there is no "done" |
| 20:53 |
MTDiscord |
<luatic> and new players might see the editing phase |
| 20:53 |
MTDiscord |
<luatic> I don't want to fill up client caches |
| 20:54 |
sfan5 |
guess you have to wait for the next revoluationary feature |
| 20:55 |
sfan5 |
-a |
| 20:55 |
MTDiscord |
<luatic> ahead of it's time ¯_(ツ)_/¯ |
| 20:56 |
MTDiscord |
<luatic> it would be an option to use only ephemeral=false (fills up client caches, but eh), or only ephemeral=true (fills up client RAM) |
| 20:56 |
|
Yad joined #minetest-dev |
| 20:56 |
MTDiscord |
<luatic> ephemeral=true would require me to resend the media under a new name, even to players who have already received it (the media is an entity texture) |
| 20:57 |
MTDiscord |
<luatic> each time a player joins, for all media, basically implementing the "adding to the media sent on startup" myself |
| 20:57 |
erlehmann |
luatic that would be a good idea any way, to use a new name (based on hashes or sth) |
| 20:57 |
erlehmann |
to make the bookkeeping easier |
| 20:57 |
MTDiscord |
<luatic> I use a new name. Currently autoincrementing. |
| 20:59 |
MTDiscord |
<luatic> Wait :o |
| 21:00 |
MTDiscord |
<luatic> Forgot about to_player! |
| 21:00 |
MTDiscord |
<luatic> I can send ephemeral media to all online players! |
| 21:00 |
MTDiscord |
<luatic> And then send it on joinplayer! |
| 21:00 |
MTDiscord |
<luatic> The release date has just moved to Sunday ;) |
| 21:00 |
erlehmann |
oh lol |
| 21:00 |
erlehmann |
well good that we talked about it, seems sfan5 helped you a lot |
| 21:00 |
MTDiscord |
<luatic> Yeah |
| 21:01 |
MTDiscord |
<luatic> I will take care to properly document this |
| 21:01 |
MTDiscord |
<luatic> Currently it says this: https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L5732-L5733 which is slightly misleading |
| 21:02 |
MTDiscord |
<luatic> In the "details" it mentions what happens to new clients: https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L5741-L5744, but that might be misunderstood as only applying to older clients |
| 21:02 |
MTDiscord |
<luatic> Thanks sfan5 |
| 21:03 |
sfan5 |
it's hard to improve those docs without making them too verbose |
| 21:06 |
Yad |
sfan5: I look forward to contributing my copyediting services to that file though. >:D |
| 21:06 |
erlehmann |
Yad sfan5 well there is a docs team now |
| 21:06 |
erlehmann |
Yad go to #minetest-docs ig |
| 21:07 |
sfan5 |
from what I gathered the docs team writes a totally new thing |
| 21:07 |
|
calcul0n joined #minetest-dev |
| 21:07 |
erlehmann |
sfan5 yeah but i bet copying part of that over is easier than coming up with a new way to describe it once they have it |
| 21:18 |
erlehmann |
sfan5, as this has been cleared up, could you maybe retitle it to “remove (or preserve) non-freetype font support”? https://github.com/minetest/minetest/issues/11611 |
| 21:19 |
erlehmann |
the issue title is somewhat inaccurate (as freetype will load other stuff than TTF just fine) |
| 21:19 |
erlehmann |
and the removal was about freetype anyway |
| 21:19 |
sfan5 |
I don't think we support that |
| 21:19 |
sfan5 |
(!= it doesn't work) |
| 21:20 |
erlehmann |
whatever you mean with “support”, what was removed was non-freetype. it was news to me as well that you can have bitmap fonts with freetype! |
| 21:20 |
erlehmann |
i guess that is a “no” to retitling the issue, then |
| 21:21 |
sfan5 |
I indeed don't feel it's important |
| 21:21 |
erlehmann |
ok |
| 21:37 |
rubenwardy |
the bitmap fonts are also TTF |
| 21:51 |
erlehmann |
rubenwardy i was referring to real bitmap font formats supported by freetype (like PCF) |
| 21:52 |
erlehmann |
(if you look at freetype API it can indeed load more than TTF) |
| 22:05 |
|
Taoki joined #minetest-dev |
| 23:13 |
|
v-rob joined #minetest-dev |
| 23:26 |
|
appguru joined #minetest-dev |
| 23:53 |
sfan5 |
we didn't manage more than a single release on 2021, that's pretty bad |
| 23:56 |
|
v-rob joined #minetest-dev |
