Minetest logo

IRC log for #minetest-dev, 2021-12-12

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:24 Alias2 joined #minetest-dev
00:41 ShadowBot joined #minetest-dev
00:42 Taoki joined #minetest-dev
01:18 proller joined #minetest-dev
03:29 queria joined #minetest-dev
03:33 queria joined #minetest-dev
04:21 v-rob joined #minetest-dev
05:00 MTDiscord joined #minetest-dev
06:41 v-rob joined #minetest-dev
07:13 olliy joined #minetest-dev
08:33 calcul0n joined #minetest-dev
09:22 Alias joined #minetest-dev
09:58 tech_exorcist joined #minetest-dev
10:11 proller joined #minetest-dev
11:06 Fixer joined #minetest-dev
12:06 tekakutli joined #minetest-dev
12:13 Fleckenstein joined #minetest-dev
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 <luatic> 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 <luatic> 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 <luatic> you can
12:43 Fleckenstein but would i need to add an extra shader for that?
12:43 MTDiscord <luatic> 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 <luatic> 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 <luatic> 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
12:58 tech_exorcist joined #minetest-dev
13:04 calcul0n joined #minetest-dev
13:38 MTDiscord <MisterE> 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 <MisterE> I wanted to know when a player collided with a bomb entity
13:39 MTDiscord <MisterE> So they can kick it
13:40 MTDiscord <MisterE> But the collision info in the bomb's onstep did not include info about the player having collided with it
13:41 MTDiscord <MisterE> 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 <j45> 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 <j45> Even tho that is quite hacky
13:43 MTDiscord <MisterE> 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 <MisterE> J45, I am concerned about network lag like you can get with boats
13:45 MTDiscord <j45> I see
13:45 MTDiscord <MisterE> sfan5 ^
13:46 MTDiscord <MisterE> 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 <MisterE> 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 <MisterE> 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 <MisterE> 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
14:51 kilbith joined #minetest-dev
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 <Warr1024> 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 <Warr1024> When were true 3D items introduced?  It was like a 5.0 feature or something...
15:16 MTDiscord <Warr1024> 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 <Warr1024> 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 <Warr1024> Oh, is this without gui_scaling_filter?  Didn't say in the issue OP
15:21 MTDiscord <Warr1024> 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 <Warr1024> 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:50 Taoki joined #minetest-dev
15:57 sfan5 looks like it
16:00 Taoki joined #minetest-dev
17:01 Taoki joined #minetest-dev
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 <Jonathon> https://github.com/minetest/minetest/issues/4822 here is one sorta related tldr because it might be misused
17:16 MTDiscord <Jonathon> 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 <Jonathon> for example https://github.com/mt-mods/beowulf
17:22 MTDiscord <Jonathon> 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 <Jonathon> 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 <luatic> 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 <Jonathon> >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 <Benrob0329> Which has been acknowledged
17:38 MTDiscord <Jonathon> finally
17:38 MTDiscord <Jonathon> after much badgering
17:38 MTDiscord <luatic> 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 <Jonathon> . s/issue/pull
17:39 Fleckenstein hmm i think the ShadowBot is broken
17:39 MTDiscord <Jonathon> it is
17:39 MTDiscord <Jonathon> https://github.com/minetest/minetest/pull/11855
17:39 rubenwardy looks like GitHub no longer redirects /issues/ -> /pull/
17:39 MTDiscord <Benrob0329> Works for me
17:41 MTDiscord <Benrob0329> 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 <Benrob0329> 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 <Benrob0329> Human scale, Ruben :P
17:46 MTDiscord <Benrob0329> Fleckenstein: Its not widening the int, as that would break comparability, its adding another
17:46 MTDiscord <Benrob0329> *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 <luatic> I never really got while value widths are used so sparingly
17:50 MTDiscord <luatic> There's little reason to ever use u8 nowadays...
17:52 MTDiscord <luatic> 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:26 Extex joined #minetest-dev
18:32 MTDiscord <luatic> 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 <luatic> probably yes
18:36 MTDiscord <luatic> 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:39 Extex joined #minetest-dev
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:19 olliy joined #minetest-dev
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:26 olliy1or joined #minetest-dev
19:29 Extex joined #minetest-dev
19:32 olliy joined #minetest-dev
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)
20:13 tech_exorcist joined #minetest-dev
20:18 Evergreen joined #minetest-dev
20:30 appguru joined #minetest-dev
20:40 tekakutli joined #minetest-dev
21:04 tech_exorcist joined #minetest-dev
21:24 proller joined #minetest-dev
22:08 Taoki joined #minetest-dev
22:24 Taoki joined #minetest-dev
22:39 appguru joined #minetest-dev
22:57 proller joined #minetest-dev
23:34 proller joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext