| Time |
Nick |
Message |
| 00:21 |
|
calcul0n joined #minetest |
| 00:56 |
|
ANAND joined #minetest |
| 01:16 |
|
luizrpgluiz joined #minetest |
| 01:29 |
|
luizrpgluiz left #minetest |
| 02:32 |
|
Edgy1 joined #minetest |
| 03:37 |
|
est31 joined #minetest |
| 04:05 |
air |
can mod B add fields to node definitions in mod A? |
| 04:08 |
Cornelia |
You should be able to get the node definition using a Lua function.. I think it's called something like "get_node" |
| 04:19 |
ChimneySwift |
air: make mod A a dependency of mod B and use minetest.override_item(name, redefinition) |
| 04:20 |
|
AlexYst joined #minetest |
| 04:20 |
ChimneySwift |
where redefinition is a table of. fields you wish to override if they already exist or add if not |
| 04:27 |
air |
thank you |
| 04:48 |
|
Tux[Qyou] joined #minetest |
| 04:52 |
|
lisac joined #minetest |
| 04:57 |
|
Elon_Satoshi joined #minetest |
| 05:03 |
|
Sketch2 joined #minetest |
| 05:42 |
|
Scotty_Trees joined #minetest |
| 06:10 |
|
nowhere_man joined #minetest |
| 06:20 |
|
reductum joined #minetest |
| 06:25 |
AlexYst |
It there a way to unregister a single decoration without clearing all decorations? |
| 06:26 |
AlexYst |
Or should I just make a copy of minetest.registered_decorations, clear all decorations, then restore the ones I was never wanting to remove? |
| 07:07 |
|
comrad joined #minetest |
| 07:09 |
ChimneySwift |
maybe iterate through through the decoration list till you find the one you want. to remove then delete that table index? |
| 07:25 |
|
red-001_ joined #minetest |
| 07:29 |
|
wilkgr left #minetest |
| 07:52 |
AlexYst |
ChimneySwift: I tried that. The decorations are handed off to the C++ before being put into the table, so when you delete or update the contents of that table, it has no effect on mapgen. |
| 08:03 |
ChimneySwift |
hmm |
| 08:04 |
ChimneySwift |
that's dumb, not sure then... |
| 08:20 |
|
ChimneySwift joined #minetest |
| 09:09 |
|
opal joined #minetest |
| 09:11 |
|
aheinecke joined #minetest |
| 09:15 |
|
opal joined #minetest |
| 09:35 |
AlexYst |
I found another strange quirk too. If I clear the decorations, the schematics used by the decorations are still loaded and parsed. And they're loaded *AFTER* the decorations were cleared, just after load time ends. |
| 09:36 |
AlexYst |
That means that any node used in a schematic decoration cannot be unregistered, even if the schematic decoration is cleared, or it'll raise an error just after load time. |
| 09:45 |
AlexYst |
Also worth noting: The default mod contains schematics that use the mushrooms from the flowers mod, but default doesn't depend on flowers. Maybe those schematics should be moved to the flowers mod. |
| 09:48 |
|
rafalcpp joined #minetest |
| 09:54 |
|
rafalcpp joined #minetest |
| 09:55 |
|
queip joined #minetest |
| 10:11 |
|
tpe joined #minetest |
| 10:16 |
yusf[m] |
> That means that any node used in a schematic decoration cannot be unregistered, even if the schematic decoration is cleared, or it'll raise an error just after load time. |
| 10:16 |
yusf[m] |
AlexYst You should file an issue! https://github.com/minetest/minetest/issues |
| 10:20 |
AlexYst |
yusf[m]: Honestly, it's such a bizarre use case that I'm not sure filing an issue would be worth it. However, I really should file an issue about the lack of a way to unregister a single decoration. I mean, there's a way to clear them all, so why not just one? I'm not sure when you'd ever want to clear them *all*. There are surely timesit'd beuseful, but I'm guessing those times arevastly outnumbered by the |
| 10:20 |
AlexYst |
times you'd want to clear one very specific schematic. |
| 10:23 |
yusf[m] |
Perhaps it's a niche bug, yes. But for any of us building games that includes massive overrides of other mods it's a real issue. |
| 10:33 |
|
Fixer joined #minetest |
| 10:44 |
|
Tux[Qyou] joined #minetest |
| 10:44 |
|
dzerk joined #minetest |
| 11:21 |
|
Krock joined #minetest |
| 12:12 |
|
Fulgen joined #minetest |
| 12:14 |
|
progysm joined #minetest |
| 12:17 |
|
AspireMint joined #minetest |
| 12:21 |
|
AndroBuilder joined #minetest |
| 12:33 |
|
hecks joined #minetest |
| 12:33 |
hecks |
Somebody explain this PR to me https://github.com/minetest/minetest/pull/7569 |
| 12:33 |
hecks |
Is minetest using fixed point numbers? |
| 12:53 |
|
Fuchs joined #minetest |
| 12:53 |
air |
to serialize when sending over the network, because archs store floats differently |
| 12:57 |
|
Fuchs joined #minetest |
| 13:14 |
|
hecks joined #minetest |
| 13:18 |
est31 |
hecks: that's one of the funnier minetest design descisions |
| 13:18 |
est31 |
basically every digital device on the planet uses IEEE 754 |
| 13:18 |
est31 |
but minetest has to do its own standard |
| 13:19 |
est31 |
because the C standard doesn't specify what float/double means |
| 13:19 |
est31 |
and that's correct it doesn't specify |
| 13:19 |
est31 |
but devices with float != ieee 754 float are super rare |
| 13:20 |
hecks |
but aside from the network, it's all floats in their broken glory anyway? |
| 13:20 |
est31 |
yes |
| 13:21 |
hecks |
oh well then, that PR isn't going to break anything more than it already is |
| 13:22 |
est31 |
the only platform specific thing is endianness |
| 13:22 |
est31 |
but that can be fixed by a single function call |
| 13:22 |
est31 |
htobe |
| 13:22 |
est31 |
betoh |
| 13:22 |
est31 |
iirc those are the names |
| 13:22 |
hecks |
uh huh |
| 13:22 |
hecks |
it just got me thinking about coordinate precision far away from the origin, is all |
| 13:23 |
hecks |
I suppose things are acceptable up to the 32-ish kilometers radius minetest gives us |
| 13:23 |
est31 |
minetest has maximum limits far below where coordinate precisions should create problems |
| 13:23 |
est31 |
yup |
| 13:24 |
hecks |
I'd say 16k is where problems normally start appearing in games, it's just that minetest is blocky enough that it doesn't matter |
| 13:24 |
est31 |
and that radius is already needed because of node indices being integers of limited width |
| 13:24 |
hecks |
or maybe it's doing some rendering tricks to handle it |
| 13:24 |
est31 |
plus a mapgen border |
| 13:25 |
hecks |
yeah, I figured out that the limit comes from 16 bit unsigned |
| 13:25 |
hecks |
or, signed actually |
| 13:25 |
hecks |
a 64k cube either way |
| 13:25 |
hecks |
wonder how hard would it be to make the world loop around like a torus |
| 13:26 |
est31 |
a 32 bit float mantissa has 23 bits |
| 13:26 |
est31 |
that's enough for well beyond 32k |
| 13:27 |
hecks |
yeah, but it's distributed on a log scale |
| 13:27 |
hecks |
it's got a ton of precision at the origin and less out there |
| 13:27 |
hecks |
in most game engines, 64k from the origin is where you start seeing transforms jitter |
| 13:29 |
est31 |
32k is 15 bits in the mantissa, means there are 23-15 remaining that's 8 bits |
| 13:29 |
est31 |
so the node can still be split into 2^8 parts |
| 13:30 |
est31 |
2^8 = 256 |
| 13:30 |
* est31 |
hopes he didnt do any off by one errors |
| 13:30 |
est31 |
also not sure whether doubles or floats are used in minetest |
| 13:30 |
est31 |
it's some time ago since I last did something with minetest |
| 13:30 |
|
behalebabo joined #minetest |
| 13:30 |
air |
has nothing to do with nodes, its the player position, which has 1/256 precision inside each node while at the edge of the map |
| 13:30 |
hecks |
my guess is floats on irrlicht's side, and doubles in lua |
| 13:32 |
hecks |
and it kinda does have to do with nodes if we're considering, say, nodebox thickness |
| 13:32 |
air |
nah |
| 13:32 |
hecks |
wouldn't there be collision oddities at the edge with super thin boxes? |
| 13:32 |
air |
rendering would use camera origin of zero |
| 13:33 |
air |
ya collision has issues, but again, that is about the player position |
| 13:41 |
Krock |
<est31> also not sure whether doubles or floats are used in minetest |
| 13:41 |
Krock |
f32 (float) for object positions |
| 13:41 |
Krock |
basically float for everything on C++ side |
| 13:41 |
Krock |
and double for Lua because that's how it works |
| 13:42 |
|
dzerk joined #minetest |
| 13:42 |
Krock |
and the smallest network representable number is 0.001, largest INT32_MAX / 1000 |
| 13:43 |
Krock |
because the float format sucks |
| 13:44 |
Krock |
disclaimer: didn't read the entire conversation |
| 13:45 |
Krock |
hecks: cheers. The PR links to the relevant resources to understand why it's even a concern |
| 13:49 |
Krock |
#minetest-dev might be interesting for you if you'd like to talk about the engine development (PRs, concept questions, Minetest structure questions etc) |
| 14:02 |
|
rafalcpp joined #minetest |
| 14:25 |
|
rubywarden joined #minetest |
| 14:25 |
|
antims joined #minetest |
| 14:28 |
|
zarcade_droid joined #minetest |
| 14:42 |
|
dzerk joined #minetest |
| 14:44 |
hecks |
Before I open a stupid issue |
| 14:44 |
hecks |
Is there no way to check if an ObjectRef is touching the ground, outside of raycasting? |
| 14:44 |
rubenwardy |
Get node |
| 14:44 |
rubenwardy |
It depends on the object |
| 14:44 |
rubenwardy |
But for players the position is at their feet |
| 14:45 |
hecks |
But no actual collider state is available, right? |
| 14:45 |
rubenwardy |
So you can do a get_node with a small y difference |
| 14:45 |
hecks |
I can raycast or get node, but this fails in case you're standing a little off ledge |
| 14:45 |
rubenwardy |
Right |
| 14:45 |
rubenwardy |
True |
| 14:46 |
Krock |
no, collision results are not exposed to the Lua API |
| 14:46 |
Krock |
but there's already a feature request on implementing that |
| 14:46 |
Krock |
just search a little :D |
| 14:46 |
hecks |
https://a.uguu.se/402qQC58wWQG_boo.gif |
| 14:48 |
Krock |
I think the wind is too strong and the ambience too cold |
| 14:48 |
hecks |
that's a falling animation |
| 14:48 |
hecks |
hence my complaint |
| 14:48 |
Krock |
well yes, then it's about right. Much wind when falling down |
| 14:48 |
hecks |
also I'm underground |
| 14:49 |
hecks |
it seems that somebody fixed the bug where my entity-attached character would turn black when not in sunlight |
| 14:49 |
hecks |
but it still happens to entities themselves |
| 14:49 |
Krock |
and in 50% of the cases, the hat is not glued to the head but moves 1 server step behind the player |
| 14:50 |
Krock |
no idea why but it sucks |
| 14:50 |
hecks |
not in 50% of the cases, it's one frame behind always when I tested it |
| 14:50 |
|
Tux[Qyou] joined #minetest |
| 14:50 |
hecks |
it's much more noticeable when you switch on speed and flying |
| 14:51 |
hecks |
https://a.uguu.se/bEB8rpKyM3gd_bleh.png so yeah, this still happens |
| 14:51 |
hecks |
it does not happen when the mob is standing on a slab, and my slabs let light through because of other bugs |
| 14:51 |
hecks |
so I guess fixing this is a matter of querying light like 0.6 of a unit higher |
| 14:52 |
hecks |
then again, sunlight is fine, only node light is busted |
| 14:52 |
Krock |
Hint: the light is calculated using the model's zero position point |
| 14:52 |
hecks |
yyyup, my thoughts exactly |
| 14:52 |
hecks |
and my models have the origin at the feet, like you'd normally do |
| 14:53 |
Krock |
nodes don't have light, unless they're glowy by themselves |
| 14:53 |
Krock |
well, and when they're like glass and let the light through |
| 14:53 |
Krock |
changing this to a non-0 light value would mes up the entire lighting system |
| 14:53 |
hecks |
anyway, a light_offset vector property for objectrefs would fix this |
| 14:54 |
Krock |
they always turn black. question is only where the node has to be |
| 14:55 |
hecks |
what I mean is, the object queries how bright it should be based on the node it's in, right? |
| 14:55 |
hecks |
and in this case, it queries the one under it which is black, because it's solid |
| 14:55 |
hecks |
I think this is why I made slabs propagate light in the first place |
| 14:56 |
Krock |
rather because you could make a slab house which is then entirely dark inside even though you can see the bright sun through the gaps |
| 14:57 |
hecks |
right, I'm talking about the slabs I use for terrain smoothing though |
| 14:58 |
hecks |
normally I wouldn't need to give them sunlight_propagates or paramtype light or whatever it is I did to fix it |
| 14:58 |
hecks |
but I had this black object bug so there you go |
| 15:00 |
hecks |
https://a.uguu.se/7NUbRCRYetIG_whatifidon%27tfixslabs.png |
| 15:00 |
hecks |
it's caused by the same thing |
| 15:01 |
rubenwardy |
Invalid certificate authority |
| 15:02 |
hecks |
whatever, it's not important |
| 15:02 |
Krock |
works for me |
| 15:02 |
rubenwardy |
Wait nevermind |
| 15:02 |
Krock |
hah "Lame Retard" |
| 15:02 |
hecks |
I generate names for mobs to keep track of them |
| 15:02 |
rubenwardy |
The firewall is blocking it due to a security threat |
| 15:02 |
hecks |
if you know where I ripped the naming scheme from, you're a cool guy |
| 15:03 |
rubenwardy |
Because malware ha |
| 15:08 |
|
dzerk joined #minetest |
| 15:28 |
|
CBugDCoder joined #minetest |
| 15:45 |
MinetestBot |
[git] beyondlimits -> Uberi/Minetest-WorldEdit: Wand: select node under or above depending on pressed sneak key. f725663 https://git.io/fN1P9 (2018-08-06T15:43:08Z) |
| 15:52 |
Krock |
hecks: I'm not keen digging further in this, mostly because I get some 18+ NSFW results on Duckduckgo with that search query |
| 15:52 |
hecks |
h-huh, what search query |
| 15:53 |
Krock |
"lame retard lost hound red mistress lusty bull" |
| 15:53 |
hecks |
oh you |
| 15:53 |
hecks |
no, there's this one game that generates these sorts of names for things |
| 15:54 |
hecks |
at least you used Duck |
| 16:01 |
|
paramat joined #minetest |
| 16:17 |
paramat |
maybe we need a tiny +y offset for entity light calculation pos for entities with zero pos at feet? (if not done already) |
| 16:20 |
paramat |
ah you're on it already |
| 16:22 |
|
AlexYst joined #minetest |
| 16:23 |
|
Beton joined #minetest |
| 16:47 |
|
twoelk joined #minetest |
| 16:53 |
|
Scotty_Trees joined #minetest |
| 17:07 |
|
Scotty_Trees joined #minetest |
| 17:12 |
|
Scotty_Trees joined #minetest |
| 17:18 |
|
bwarden joined #minetest |
| 17:37 |
|
Cornelia joined #minetest |
| 17:50 |
|
Cornelia joined #minetest |
| 17:52 |
|
Fulgen joined #minetest |
| 18:10 |
|
hecks joined #minetest |
| 18:18 |
|
Krock joined #minetest |
| 18:21 |
|
Cornelia joined #minetest |
| 18:40 |
|
Fulgen joined #minetest |
| 18:43 |
|
AndroBuilder joined #minetest |
| 18:46 |
|
Krock joined #minetest |
| 19:23 |
|
CBugDCoder joined #minetest |
| 19:50 |
|
AndroBuilder joined #minetest |
| 20:05 |
|
minduser00 joined #minetest |
| 20:17 |
|
CBugDCoder joined #minetest |
| 20:23 |
|
CalebDavis joined #minetest |
| 20:24 |
|
CalebDavis joined #minetest |
| 20:29 |
|
CBugDCoder joined #minetest |
| 20:30 |
|
el joined #minetest |
| 20:31 |
|
rtjure joined #minetest |
| 20:34 |
|
CBugDCoder joined #minetest |
| 20:39 |
|
hecks joined #minetest |
| 20:41 |
|
minduser00 joined #minetest |
| 20:42 |
|
luizrpgluiz joined #minetest |
| 20:42 |
luizrpgluiz |
hi |
| 20:43 |
|
rafalcpp_ joined #minetest |
| 21:02 |
|
ChimneySwift joined #minetest |
| 21:13 |
|
Natechip joined #minetest |
| 21:29 |
|
paramat joined #minetest |
| 21:43 |
|
DMackey joined #minetest |
| 22:39 |
|
luizrpgluiz left #minetest |
| 23:06 |
|
YuGiOhJCJ joined #minetest |
| 23:16 |
|
ANAND joined #minetest |
| 23:23 |
|
wilkgr joined #minetest |
| 23:55 |
|
craigger joined #minetest |
