Time Nick Message 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: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 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: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) 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? 13:06 MTDiscord 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 in debug, it crashes with: 13:45 MTDiscord 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 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 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 ObjectProperties 15:51 MTDiscord 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 c_content.cpp* 15:57 MTDiscord 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 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 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 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 Ah. That would make sense. Maybe someone confused that with the defaults for the player specifically, then. 16:07 MTDiscord 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 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 As said, when reading the properties from a Lua table, different defaults might be set 16:20 MTDiscord Hmm that's weird, taking physical as an example 16:20 MTDiscord getboolfield(L, -1, "physical", prop->physical); 16:20 MTDiscord So the default of false would indeed be preserved 16:21 MTDiscord heh 16:22 MTDiscord This seems to be the case for most fields, but not collisionbox or selectionbox 16:22 MTDiscord 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 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 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 ah 16:26 MTDiscord then NVM 16:29 MTDiscord 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 celeron55: ^ 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: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 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 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 so documentation is another choice 19:23 celeron55 all these versioning gotchas need to be documented better 19:23 MTDiscord 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 ^ 19:28 celeron55 well this seems like an easy issue to get rid of 19:28 MTDiscord 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 the ironic coming from you given it was a solution to your whining 19:33 erlehmann uh. what? 19:33 MTDiscord erlehmann: it does have it's usecases 19:33 erlehmann luatic, i just wonder where 19:33 MTDiscord 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 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 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 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 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 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 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 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 erlehmann: I'm not using [png 20:21 erlehmann ah ok 20:21 MTDiscord I just had it planned at some point 20:21 MTDiscord 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 As for the two "dances" you mention, they are both actually pretty simple 20:22 MTDiscord One is just minetest.encode_base64 + minetest.decode_png 20:23 MTDiscord minetest.encode_png* 20:23 MTDiscord The other one is minetest.decode_base64 + your own PNG decoder 20:23 MTDiscord And then prefixing with or removing [png: at the beginning 20:24 MTDiscord 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 As soon as the string containing them is dropped, they're gone serverside 20:25 MTDiscord dynamic media is stored on disk, and you can't delete it until the server is shutting down 20:25 MTDiscord 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 Huh? WDYM? 20:30 MTDiscord I use pretty much only ephemeral media 20:32 MTDiscord 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 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 But what about new clients? 20:44 sfan5 what about them? 20:44 MTDiscord 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 hmm, then I misunderstood the docs 20:47 MTDiscord 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 and what about a 3D skin editing mod ;) 20:53 sfan5 `true` for the editing phase, `false` when you're done 20:53 MTDiscord the problem is that there is no "done" 20:53 MTDiscord and new players might see the editing phase 20:53 MTDiscord 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 ahead of it's time ¯_(ツ)_/¯ 20:56 MTDiscord 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 MTDiscord 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 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 I use a new name. Currently autoincrementing. 20:59 MTDiscord Wait :o 21:00 MTDiscord Forgot about to_player! 21:00 MTDiscord I can send ephemeral media to all online players! 21:00 MTDiscord And then send it on joinplayer! 21:00 MTDiscord 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 Yeah 21:01 MTDiscord I will take care to properly document this 21:01 MTDiscord Currently it says this: https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L5732-L5733 which is slightly misleading 21:02 MTDiscord 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 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 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) 23:53 sfan5 we didn't manage more than a single release on 2021, that's pretty bad