| 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 |
