Time Nick Message 12:27 Fleckenstein is there a way to create a irr::video::ITexture from an irr::video::IImage without irr::video::IVideoDriver::addTexture? (because that function associates the newly created texture with a name) 12:32 sfan5 why is it a problem for you if the texture is named? 12:36 Fleckenstein I'm reworking crack rendering so that no map block animation is needed for it. Rather, the crack is rendered as a separate mesh with a polygon offset. I need to get the crack frame from crack_anylength.png to then render it. For that I operate with IImages, but the end result has to be an ITexture. Currently nothing is cached and the crack texture is recreated every frame. I guess I should probably 12:36 Fleckenstein change that, but how should the crack frames extracted from crack_anylength be named? 12:37 celeron55 just generate a unique name like you'd do for any kind of cache 12:37 sfan5 you have the wrong approach, you can ask the ITextureSource for a texture of original_name + "^[crack:1" or whatever 12:38 sfan5 no need to do this manually 12:38 Fleckenstein yea, the thing is there is no original_name 12:38 sfan5 or just "[crack:1" then I guess 12:39 sfan5 by the way, have you thought about z-fighting? 12:39 Fleckenstein polygon offset 12:39 Fleckenstein the thing is, with the approach of rendering the crack separately instead of overlaying images on the CPU things like ^[crack are just not needed anymore 12:40 sfan5 sure overlaying crack will not be needed anymore but that doesn't mean you have to work with crack_anylength.png manually instead of reusing the existing infrastructure 12:41 Fleckenstein I really don't see why, if crack rendering is replaced, we would need ^[crack anymore - i mean it can just easily be replaced by a ^[combine with the appropriate frame from crack_anylength 12:41 MTDiscord Fleckenstein: How would this handle cracko? 12:42 celeron55 [crack has to exist for backwards compatibility anyway, no reason not to use it 12:42 Fleckenstein ok i see 12:42 Fleckenstein i gotta readd ^[crack then 12:42 sfan5 what does `[cracko` do again? 12:42 celeron55 well, a reason not to use it would be if you'd be using texture coordinates instead of generating images of a single crack phase 12:43 MTDiscord sfan5: the crack getting the opacity from the underlying texture 12:43 sfan5 hm 12:43 Fleckenstein right, TC is probably better 12:43 sfan5 I bet you can do that using GL functions (or shaders in any case) 12:43 MTDiscord you can 12:43 Fleckenstein but would i need to add an extra shader for that? 12:43 MTDiscord probably 12:44 celeron55 using texture coordinates to switch textures has been used way before shaders were a thing 12:44 Fleckenstein yea, but can irrlicht do it as flexible as legacy opengl? 12:44 Fleckenstein and if yes, how? 12:44 sfan5 legacy opengl is the thing irrlicht is best at ;) 12:44 celeron55 there's a texture coordinate for each vertex 12:44 MTDiscord We can make it be as flexible :) 12:45 celeron55 just set it to grab the part of crack_anylength.png you want 12:45 sfan5 Fleckenstein: if you don't know I suggest starting with a generated crack texture, you can optimize it later 12:45 Fleckenstein just felt like the entire crack thing is really chaotic and it'd be better to solve the overlaying GPU-side 12:45 sfan5 definitely 12:45 Fleckenstein of course texture coordinates would be the correct way to go here 12:45 MTDiscord Elaborate 12:46 Fleckenstein basically, if the crack is rendered as a part of the mapblock's texture the mapblock has to be animated 12:46 Fleckenstein and it also messes up some batching MT does 12:47 Fleckenstein enable wireframe, place a chain of like 4 stone blocks, then start digging one of them 12:47 Fleckenstein you are gonna notice how the one you are digging is not connected to the other 3 anymore like it was before 12:48 Fleckenstein i was also hoping to be able to simplify things a bit by removing ^[crack completely but I understand it needs to stay for backwards compatibility 12:48 sfan5 some code for a texture modifier is the least of our worries, improving rendering is more relevant 12:54 Fleckenstein ok 12:54 Fleckenstein also, im working on correct physics calculation 12:55 Fleckenstein it should probably be enabled in physics override, similar to sneak glitch? 12:55 sfan5 yea 13:38 MTDiscord sfan5: before I make an issue, is there any way to get a player's collision info? 13:38 sfan5 no 13:39 sfan5 for the simple reason that player physics are client-side but mods run on the server 13:39 MTDiscord I wanted to know when a player collided with a bomb entity 13:39 MTDiscord So they can kick it 13:40 MTDiscord But the collision info in the bomb's onstep did not include info about the player having collided with it 13:41 MTDiscord Because the bomb is stationary, and the player hit it 13:41 sfan5 yeah that's doesn't work either 13:42 sfan5 that* 13:42 MTDiscord Attach a player to an entity and let the player control the entity and use the entity's on_step collision data 13:42 MTDiscord Even tho that is quite hacky 13:43 MTDiscord Would it be easy to add a collided field to the ent's on_step, which contains collision info for objects that have collided with the ent (as opposed to the collisions field with info about collisions the ent has caused)? should I make an issue for that? 13:44 MTDiscord J45, I am concerned about network lag like you can get with boats 13:45 MTDiscord I see 13:45 MTDiscord sfan5 ^ 13:46 MTDiscord Grr I erased the question above in discord, but I'm sure its still readable in irc 13:46 sfan5 that wouldn't be easy 13:53 MTDiscord Blah. Well its another missing feature. Can you think of any easy way to implement something that will achieve the desired effect? 13:54 MTDiscord If not, its cool, I ended up having players punch the bomb instead of kicking it 13:55 sfan5 you can do the collision detection yourself in lua using the player's speed and position to see if they bumped into it 13:55 sfan5 not sure how reliable that is 13:58 MTDiscord Ok, well thank you for your help sfan5 14:26 sfan5 rubenwardy: cdb search is actually useless https://content.minetest.net/packages/?q=mobs+redo 14:26 sfan5 I couldn't spot mobs redo on the first page but it is there 14:26 sfan5 regardless it should be first place 15:11 sfan5 irregular reminder for someone to please confirm #11753 (I can't repro on my system) 15:11 ShadowBot https://github.com/minetest/minetest/issues/11753 -- Images in formspecs use "smooth" linear instead of nearest neighbor filtering 15:15 MTDiscord 3D items are now rendered as actual 3D, so they now require hardware AA. The software AA only works with images. It's been like this for ... years now...? 15:15 MTDiscord When were true 3D items introduced? It was like a 5.0 feature or something... 15:16 MTDiscord Buttons in that image are high enough res that I can't tell. The inventory_image items look correct: they're using nearest scaling with software AA. 15:17 sfan5 make sure to test this without gui_scaling_filter... 15:17 MTDiscord If you wanted them to be consistent, we're probably special-casing 3D vs. flat items to render them as images, when instead we could special-case them to generate a simple flat model but use the rest of the 3D path for them. 15:18 MTDiscord Oh, is this without gui_scaling_filter? Didn't say in the issue OP 15:21 MTDiscord Just looking at the screenshot, the inventory_image items are not being filtered, they're scaled up nearest, and any "blur" on them is caused by AA because they're not scaled up by an exact integer multiple. The same will apply to the 3D items but they're dependent on a separate AA setting, so it's possible to have the 2 settings out of sync. 15:21 MTDiscord It may actually be desirable to have the settings out of sync because they have different and game-dependent performance costs. 15:23 Krock will merge game#2906 game#2905 and game#2911 in 15 minutes 15:23 ShadowBot https://github.com/minetest/minetest_game/issues/2906 -- Convert door model to B3D by An0n3m0us 15:23 ShadowBot https://github.com/minetest/minetest_game/issues/2905 -- Slovak translation update by daretmavi 15:23 ShadowBot https://github.com/minetest/minetest_game/issues/2911 -- Pull some parent node vars for stairs and slabs by yamanq 15:37 Krock merging 15:39 Krock done 15:47 sfan5 https://www.minetest.net/credits/ is a biit out of date 15:50 Krock copy&paste from the in-game credits? 15:57 sfan5 looks like it 17:07 Fleckenstein is there a reason the version string from get_player_information is not available in non-debug server builds? 17:10 Fleckenstein knowing the client version can be useful for various things (kicking players that use a hacked client that sends a modified version string, checking whether the client supports a certain feature etc.) 17:12 Krock pretty sure there's at least three closed issues about this topic 17:13 Fleckenstein ok 17:15 Fleckenstein actually, i can't find any, could you point me to one? https://github.com/minetest/minetest/issues?q=get_player_information does not seem to show anything related. 17:16 MTDiscord https://github.com/minetest/minetest/issues/4822 here is one sorta related tldr because it might be misused 17:16 MTDiscord which is ironic given that some servers just compile right before latest stable to use this anyways 17:21 Fleckenstein why not just -DCMAKE_BUILD_TYPE=Debug ? 17:21 MTDiscord for example https://github.com/mt-mods/beowulf 17:22 MTDiscord theres others that are closed source that use it to 17:26 Fleckenstein Of course it's not optimal because of forks. But the attitude of saying, it does not work 100% perfect in all cases, so we're not exposing it to modders is wrong. Having _something_ that works right in most cases is still better than having nothing at all. This is similar to SSCSM. For game developers, not being able to ship client side code is a fucking pain. There is a lot of things that could just 17:26 Fleckenstein be done client side, even with how limited the current CSM API is, the only thing keeping us from doing it is shipping the CSM code. I think that in general the attitude "this solution is not perfect, let's rather not give the people anything" is just wrong. Also, mods that determine features based on version string can check the version string to detect the minetest fork and decide based on that. Come 17:26 Fleckenstein on, just give modders/gamedevs a little bit more power, the current state is just frustrating. 17:28 MTDiscord its just typical core dev lets not give info because it might be misused, etc. see dpi/screen size info issues. which ironically one of them is tagged for 5.5 now 17:28 Fleckenstein people are using workarounds and forks/custom builds just to get around some limitation, this should not be necessary 17:28 Fleckenstein "This was extensively discussed in the past and the potential for misuse is just too big with such an API" 17:29 Fleckenstein look, everything can be misused in some way 17:29 Krock the Minetest version should not be sent in first place 17:29 Fleckenstein but that way feature detection is not possible at all 17:29 Krock that's what formspec_version and the protocol version do 17:29 rubenwardy it's not similar to SSCSM because SSCSM is intentional remote code execution 17:30 Fleckenstein protocol is only changed when there are significant changes to the protocol 17:30 Krock that's also discussed and the conclusion is to raise the protocol version for new features, each release if necessary 17:31 Fleckenstein a lot of people are against SSCSM because they want it to be done properly 17:31 Krock in case the feature is notable enough 17:31 MTDiscord Agreed with rubenwardy. Executing code in an outdated VM (PUC Lua 5.1 and LuaJIT both haven't been updated in years) is fairly risky. 17:31 Fleckenstein of course there are also security concerns, which are valid 17:31 Fleckenstein well, afaik protocol version is limited to 255? 17:31 rubenwardy I think the solution to modders misusing version strings to check for features isn't to withhold the version strings, but to make it easier to check for features 17:32 Fleckenstein the argument of "it is possible to use this wrong" is not a reason to not make something available 17:32 Fleckenstein everything can be misused 17:33 Fleckenstein rubenwardy, that would pretty much just mean checking the client version in the C++ code 17:33 Krock with the current rate of protocol version bumps, it'll take approx. 63 years to reach the uin8_t limit 17:33 rubenwardy Fleckenstein: which is done with protocol versions 17:33 nrz Krock, it's a problem, we (coredevs) should not be dead, and we will have to handle it before dying 17:34 rubenwardy the problem with protocol version is that it's min(client_ver, server_ver) 17:34 rubenwardy so if the server is outdated, then the client will report as being older than it is 17:34 rubenwardy this is fine for actual protocol features, which is most of the cases 17:34 Fleckenstein yea but im not sure whether you want to increase the proto version e.g. for small things like #11855 17:34 ShadowBot https://github.com/minetest/minetest/issues/11855 -- Correct gravity calculation by EliasFleckenstein03 17:34 rubenwardy well, the bigger problem is going from "I want this feature" to "protocol version" 17:35 Fleckenstein because there is no such thing as a features network packet, and even if it was added, all the forks and earlier version ofc don't have it 17:35 Krock nrz: the easy fix is to use the current protocol version's MSB to determine whether a second byte is to be expected 17:36 nrz i don't see why we should handle protocol version now there is no issue 17:36 nrz but as you like to fix a year 2070 issue ? 17:36 Krock > nrz> Krock, it's a problem, we (coredevs) should not be dead, and we will have to handle it before dying 17:36 Krock I thought you were talking about the protocol version limit? 17:37 nrz yeah the overflow ? 17:37 MTDiscord >that's what formspec_version and the protocol version do this is ironic also because just a few months ago core devs where opposed to this as well 17:37 rubenwardy if all developers are dead, then the protocol version won't increase 17:37 Fleckenstein i think the problem here is the "with the current rate of version bumps" part 17:37 nrz rubenwardy, that's the point, logically we should not :p 17:37 Fleckenstein the current rate of proto version bumps is not sufficient for feature detection 17:37 MTDiscord Which has been acknowledged 17:38 MTDiscord finally 17:38 MTDiscord after much badgering 17:38 MTDiscord Fleckenstein: I'm getting a 404 for your PR link? 17:38 Fleckenstein wait a sec 17:38 Fleckenstein #11855 17:38 ShadowBot https://github.com/minetest/minetest/issues/11855 -- Correct gravity calculation by EliasFleckenstein03 17:38 MTDiscord . s/issue/pull 17:39 Fleckenstein hmm i think the ShadowBot is broken 17:39 MTDiscord it is 17:39 MTDiscord https://github.com/minetest/minetest/pull/11855 17:39 rubenwardy looks like GitHub no longer redirects /issues/ -> /pull/ 17:39 MTDiscord Works for me 17:41 MTDiscord Anyways, if Minetest ever reaches protocol version 255, protocol version 255 just also needs to include an extra byte for the actual protocol version 17:41 MTDiscord And we'll get another 70 years out of it 17:42 Fleckenstein uhm i dont think thats how it works 17:42 Fleckenstein its more like 70 * 255 years 17:42 rubenwardy the MSB approach would give us 16384 years 17:42 rubenwardy plus 128 17:42 MTDiscord Human scale, Ruben :P 17:46 MTDiscord Fleckenstein: Its not widening the int, as that would break comparability, its adding another 17:46 MTDiscord *compatibility 17:48 Fleckenstein ah ok 17:49 Fleckenstein but i mean that additional int could just be made 4 bytes long so we simply dont run into problems ever again 17:49 Fleckenstein its sent once, when connecting so the impact is really minor 17:50 MTDiscord I never really got while value widths are used so sparingly 17:50 MTDiscord There's little reason to ever use u8 nowadays... 17:52 MTDiscord I'm a bit shocked at just how incorrect MT's physics are 17:56 rubenwardy sending less data is better 17:56 rubenwardy u8 is too short for a protocol version though 17:58 nrz protocol version is sent only one time, it's not so data consuming 18:10 Fleckenstein When I made my first game (2D Minetest with Javascript) I actually made the same mistake minetest does of doing v = at, x = vt and only later in 8th grade I finally had the knowledge to solve it properly with x = 1/2at². Funny how just leaving it would actually have matched Minetest better. 18:16 rubenwardy I've only recently discovered that it should be v += ut + 1/2 at^2 18:18 Fleckenstein in germany we learn such stuff at school 18:22 sfan5 the override should be called new_acceleration, it affects more than just gravity 18:22 rubenwardy I learned it at school as well, as SUVAT 18:23 rubenwardy p += ut is correct - the problem is when using timesteps 18:24 rubenwardy nvm 18:25 Fleckenstein sfan5, done 18:32 MTDiscord Fleckenstein: yeah :P 18:34 Fleckenstein Are object properties the correct way to add the opt-in for luaentities (the client needs to know it for client side prediction)? 18:35 Fleckenstein (opt-in for the new_acceleration feature) 18:35 MTDiscord probably yes 18:36 MTDiscord then these properties could be used for players as well 18:36 Fleckenstein yes, but the client side player physics are different from client side entity physics 18:36 Fleckenstein so it might be more idiomatic to have different ways to set the feature actually 18:38 Fleckenstein Entity/Player abstraction is terrible in MT anyway 18:39 Fleckenstein e.g. :get_meta() and :get_inventory() are present for players but not players, and :get_luaentitiy() is present for luaentities, but not players 18:41 rubenwardy RVWP has a separate PlayerRef to EntityRef (=ObjectRef). I think it makes much more sense to separate the peer from the in-game object 18:41 rubenwardy bit too late for MT to do that 18:41 Fleckenstein it can be useful to store persistent data into luaentities (currently done by on_staticdata) or have a quick-access non-persistent lua table associated which each player (which can be solved by having a table that maps player ref -> table) 18:41 rubenwardy Entities should have meta and inventory though, probably 18:42 Fleckenstein of course it can easily be worked around, but it is somewhat arbitrary to give players persistent storage only and entities non-persistant storage only 18:42 Fleckenstein and one thing i keep seeing that annoys me is people using the player name as key 18:43 Fleckenstein this is just unnecessary 18:43 Fleckenstein just use the player ref 18:43 rubenwardy the player's ObjectRef will expire when the leave, and won't activate again 18:43 Fleckenstein im talking about non-persistent storage 18:43 rubenwardy that would work for caches where you delete on leave 18:43 sfan5 also applies there 18:43 Fleckenstein persistant data should be stored in player meta anyway 18:45 Fleckenstein it's just unnecessary to always have to add a separate way to handle players and entities when implementing any mechanic that applies to objects and stores some sort of data 18:45 Fleckenstein also, there should be a way to check whether and object ref has expired, other than `obj:is_player() or obj_get_luaentity()` 18:46 Fleckenstein i get that the idea is to not store object refs 18:46 Fleckenstein but often you have to 18:46 Fleckenstein so legalize the expiry checking 18:46 sfan5 no 18:46 sfan5 the correct fix to to give objects persistent IDs 18:46 Fleckenstein the worst case here is that people store object refs and don't check for expiry 18:47 Fleckenstein giving objects persistent IDs is not the correct solution since objects can still just not be available 18:47 Fleckenstein if e.g. a baby sheep knows it's mother 18:48 sfan5 it is the correct solution because it means you can discard the object at any point in time and retrieve it (or `nil` if it's gone) again 18:48 Fleckenstein and the mother dies or is unloaded she's just unavailable 18:48 Fleckenstein you can't access an object at any time again 18:48 Fleckenstein sometimes its not loaded 18:48 sfan5 that's what "gone" means 18:48 Fleckenstein checking of ref expiry is totally valid 18:49 sfan5 I don't think you understood my point 18:49 sfan5 if there's a way to get objectrefs back using a primary key then there is no need to ever store an objectref 18:49 Fleckenstein having to re-get the object ref from id every time does not seem like a very performant approach 18:49 Fleckenstein neither is it practical 18:50 Fleckenstein of course, persistent IDs are _also_ good, but they are not the solution to the problem 18:51 Fleckenstein people will store object refs if it's more performant that way 18:51 sfan5 well I can't stop people from doing it wrong 18:51 Fleckenstein it's not wrong if it's more performant 18:53 Fleckenstein the problem here is the attitude of thinking that something is definitely wrong or right 18:53 rubenwardy you can use `get_pos() ~= nil` to check whether an ObjectRef is valid 18:53 Fleckenstein in different cases, different things are valid and people have to use their brain 18:54 rubenwardy I store ObjectRefs in Conquer to track selected objects, much easier then any other approach and safe since 5.2 18:54 Fleckenstein yea, ofc i can use that rubenwardy, but i'd like some official method not a workaround 18:54 Fleckenstein it's just not a good idea to tell people 'don't do this' if that something makes sense to some degree and can't be prevented 18:55 Fleckenstein people need to be educated about the fact that they have to check for expiry and the best way to do that is a method that _officially_ does that, not coincidentally can be used for it 18:56 rubenwardy given that refs are invalidated immediately on removal, this is also required even without storing refs 19:24 Fleckenstein well, only if you call a function that might potentially remove the object 19:25 Fleckenstein this actually lead to some engine crashes (uncaught LuaError) in MCL2 when the item entity on_step function would remove the object and then go on with the on_step function normall 19:25 Fleckenstein *normally 19:42 Fleckenstein apparently, physics calculation is already correct for objects that dont have collisions+ 19:43 Fleckenstein but it is not for objects that have 19:44 Fleckenstein should i a) not add any sort of opt-in at all and just fix physical objects b) add opt-in for physical objects and leave non-physical objects c) add opt-in for both physical and non-physical objects ? 19:45 Fleckenstein I'd say b) but I figured I'd ask to avoid unnecessary work 19:48 sfan5 for c) how do you add an opt-in for something that is already the case? 19:48 sfan5 the property will exist either way 19:48 sfan5 so b) is indistinguishable from c) 19:51 Fleckenstein so I should do b) ? 19:53 Fleckenstein oh god, there is particles 19:53 Fleckenstein i have to add opt-in for these as well i guess 19:56 sfan5 Fleckenstein: you add a property for opt-in and it silently does nothing for non-physical objects 19:56 Fleckenstein yea, thats b) basically 19:57 sfan5 and c)