| Time |
Nick |
Message |
| 00:43 |
|
Taoki joined #minetest-dev |
| 00:59 |
|
Alias2 joined #minetest-dev |
| 01:29 |
|
behalebabo joined #minetest-dev |
| 01:35 |
|
v-rob joined #minetest-dev |
| 01:54 |
|
kilbith joined #minetest-dev |
| 02:58 |
ShadowNinja |
Merging #11871 and #11919 in 10m. |
| 02:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/11871 -- Cap damage overlay duration to 1 second by Wuzzy2 |
| 02:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/11919 -- Fix vector.from_string returning a table without vector metatable by Desour |
| 03:28 |
|
queria^clone joined #minetest-dev |
| 03:33 |
|
queria^clone joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:14 |
|
YuGiOhJCJ joined #minetest-dev |
| 06:10 |
|
v-rob joined #minetest-dev |
| 08:43 |
|
calcul0n_ joined #minetest-dev |
| 09:15 |
|
calcul0n__ joined #minetest-dev |
| 09:17 |
|
kilbith joined #minetest-dev |
| 09:35 |
|
kilbith_ joined #minetest-dev |
| 10:55 |
|
Fixer joined #minetest-dev |
| 11:19 |
MTDiscord |
<j45> is the object property "colors" a functional feature? according to GreenXenith, it has been in the engine for 9 years and the commit was e42eeec: "New object property which allows changing the color and alpha of mesh materials. Due to the current lighting systems it doesn't work yet, but the full implementation is there", is there a chance this still doesnt work, as when GreenXenith tried it and it didnt work |
| 11:24 |
celeron55 |
the colors do get given to irrlicht via setMeshColor() |
| 11:25 |
MTDiscord |
<GreenXenith> nothing seems to happen, however |
| 11:25 |
celeron55 |
// Set mesh color (only if lighting is disabled) |
| 11:25 |
celeron55 |
if (!m_prop.colors.empty() && m_glow < 0) |
| 11:25 |
celeron55 |
setMeshColor(mesh, m_prop.colors[0]); |
| 11:25 |
celeron55 |
but only if glow < 0 |
| 11:27 |
celeron55 |
i mean, that gives setMeshColor() the first one from colors of course |
| 11:28 |
MTDiscord |
<luatic> but m_glow < 0 is impossible |
| 11:28 |
MTDiscord |
<GreenXenith> so, not only is it impossible to evaluate, but it wont even use all the colors as documented? |
| 11:28 |
celeron55 |
so when glow < 0, colors[0] is for... manually forcing the mesh to be colored as if the mesh was displayd under lighting of such color |
| 11:29 |
celeron55 |
but otherwise colors is not used at all |
| 11:29 |
celeron55 |
wait |
| 11:29 |
MTDiscord |
<GreenXenith> again, glow cant be < 0 |
| 11:29 |
celeron55 |
i missed all the other uses of colors |
| 11:29 |
MTDiscord |
<luatic> the other uses require directional lighting which we don't have |
| 11:30 |
sfan5 |
of course glow can be < 0, it's even documented |
| 11:30 |
celeron55 |
well lua_api.txt does say glow can be < 0 |
| 11:30 |
MTDiscord |
<GreenXenith> Ah, right that is what thats supposed to do |
| 11:31 |
celeron55 |
what i don't know whether that system actually works or is used by anyone |
| 11:31 |
MTDiscord |
<GreenXenith> Well glow less than 0 works as intended (disables lighting) but the colors certainly still dont work |
| 11:33 |
celeron55 |
hmm, setMeshColor isn't an irrlicht thing, it just sets the vertex colors of all the meshbuffers |
| 11:35 |
MTDiscord |
<luatic> pretty sure we ignore those colors in the shaders though |
| 11:35 |
celeron55 |
ah shaders |
| 11:35 |
celeron55 |
does it work with shaders disabled? |
| 11:36 |
MTDiscord |
<GreenXenith> Nope |
| 11:36 |
celeron55 |
the only way that wouldn't be visible is if something else sets them to something else right after before the mesh is shown... or if you have to tell irrlicht the meshbuffers were modified, i really should remember how this works |
| 11:39 |
celeron55 |
yes i think it's set to something else right after |
| 11:40 |
celeron55 |
nothing prevents GenericCAO::updateLight from ending up calling setMeshColor() when glow < 0 |
| 11:41 |
celeron55 |
and when shaders are enabled the shader version of the same thing happens even when glow < 0 |
| 11:41 |
celeron55 |
wait |
| 11:41 |
celeron55 |
i'm absolutely blind |
| 11:42 |
celeron55 |
literally at the beginning of GenericCAO::updateLight it says "if (m_glow < 0) return;" |
| 11:42 |
MTDiscord |
<GreenXenith> lmao |
| 11:42 |
MTDiscord |
<luatic> loool |
| 11:42 |
MTDiscord |
<j45> xD |
| 11:43 |
celeron55 |
i think realistically the only way to find out what actually happens is a debugger... |
| 11:45 |
|
KvL joined #minetest-dev |
| 11:46 |
celeron55 |
does someone have a minimal mod handy that tries to use this? |
| 11:51 |
celeron55 |
well i do now |
| 11:56 |
celeron55 |
the glow=-1 of a luaentity does get transferred up to GenericCAO::m_glow and is handled in GenericCAO::updateLight like it should be |
| 11:57 |
celeron55 |
that's the diff for testing it http://paste.dy.fi/7gK |
| 11:58 |
celeron55 |
though i sure hope that's the correct way to specify color for that field |
| 11:58 |
celeron55 |
wait of course it's not |
| 11:58 |
MTDiscord |
<j45> yes, colors wants colorspec from what i saw |
| 11:59 |
celeron55 |
add one more {} because it's a list of colors |
| 11:59 |
MTDiscord |
<j45> oh yes |
| 11:59 |
celeron55 |
and of course it doesn't give any error 8) |
| 12:00 |
MTDiscord |
<j45> by the way, https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L7190 contradicts https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L7215 |
| 12:01 |
celeron55 |
wait what |
| 12:01 |
celeron55 |
the m_glow < 0 stuff happens only for m_prop.visual == "upright_sprite" |
| 12:01 |
celeron55 |
:D |
| 12:01 |
MTDiscord |
<j45> it doesnt say that textures = {itemname} is deprecated on 7215,, and that you should use wield_item = itemname |
| 12:02 |
celeron55 |
and IT WORKS |
| 12:03 |
MTDiscord |
<j45> ? |
| 12:03 |
celeron55 |
as long as you have upright_sprite, glow < 0 it works |
| 12:03 |
celeron55 |
somebody just forgot to add the glow < 0 stuff into other visuals in GenericCAO |
| 12:04 |
celeron55 |
but... it only works *with* shaders |
| 12:05 |
celeron55 |
this is so broken it might as well be removed |
| 12:17 |
|
Fleckenstein joined #minetest-dev |
| 12:30 |
|
appguru joined #minetest-dev |
| 13:56 |
|
appguru joined #minetest-dev |
| 15:15 |
|
calcul0n joined #minetest-dev |
| 15:29 |
|
appguru joined #minetest-dev |
| 16:01 |
appguru |
sfan5: I'm getting a -Wsign-compare warning, should I cast to u32? Should be irrelevant as this is in an if-branch which checks whether the signed value is positive anyways. |
| 16:02 |
sfan5 |
yes |
| 16:02 |
sfan5 |
sign-compare is a stupid warning anyway |
| 16:03 |
|
Extex joined #minetest-dev |
| 19:01 |
|
v-rob joined #minetest-dev |
| 19:31 |
|
Desour joined #minetest-dev |
| 20:12 |
|
v-rob joined #minetest-dev |
| 20:28 |
|
Taoki joined #minetest-dev |
| 21:08 |
|
behalebabo joined #minetest-dev |
| 21:55 |
|
x2048 joined #minetest-dev |
| 22:26 |
|
Extex joined #minetest-dev |
| 22:36 |
|
olliy joined #minetest-dev |
| 22:39 |
|
appguru joined #minetest-dev |
| 22:45 |
|
olliy1or joined #minetest-dev |
| 22:49 |
|
Extex joined #minetest-dev |
| 22:51 |
|
olliy joined #minetest-dev |
| 22:57 |
|
olliy1or joined #minetest-dev |
| 23:11 |
|
appguru joined #minetest-dev |
