Time |
Nick |
Message |
00:52 |
|
fox_ joined #minetest |
00:52 |
fox_ |
hello! |
00:59 |
DeepThgt |
ok so mesecons inability to handle 1 tick state changes is driivng me nuts |
00:59 |
DeepThgt |
this essentially makes the detector tube useless |
01:00 |
DeepThgt |
its looking like digging into trying to figure out why the delays get "stuck" with a 1 tick operation is the only path i can see to fix it |
01:00 |
DeepThgt |
and i am not even sure why mesecons fails with 1 tick state changes |
01:02 |
|
fox joined #minetest |
01:03 |
fox |
whats your fav mod? |
01:03 |
DeepThgt |
surely not mesecons right now |
01:04 |
DeepThgt |
no offense to the work people have done it on it whatsoever |
01:05 |
DeepThgt |
just, the bug of things being stuck with 1 tick operations is annoying, and im curious as to why it was handled via the "overheating" mechanic |
01:05 |
fox |
yeah... |
01:07 |
DeepThgt |
from what i understand the overheat was added to keep from slowing down the server with too many operations |
01:07 |
DeepThgt |
which i understand as a reason |
01:08 |
DeepThgt |
but this seemes to have covered up bugs as an unintended side effect |
01:08 |
DeepThgt |
and made them more rare than they would have been without overheating |
01:10 |
DeepThgt |
local on_state = { |
01:10 |
DeepThgt |
description = S("You hacker you"), |
01:10 |
DeepThgt |
lol |
01:24 |
|
smk joined #minetest |
01:43 |
|
diceLibrarian2 joined #minetest |
01:46 |
|
fox joined #minetest |
02:20 |
|
Bombo joined #minetest |
02:20 |
|
Bombo joined #minetest |
02:55 |
|
srifqi joined #minetest |
02:56 |
DeepThgt |
im thinking if the pipeworks detector used globalstep instead of minetest.after it would work |
02:56 |
DeepThgt |
but idk at all |
04:18 |
* cheapie |
emits a digilines detector tube at DeepThgt |
04:19 |
DeepThgt |
is that my real answer? |
04:19 |
cheapie |
It's not an ideal answer, but it's one possible alternative. I reported the bug you're complaining about several years ago and I don't think much has changed since then :/ |
04:21 |
cheapie |
I should probably fix it, but I haven't actually used that particular part in ages now so I keep forgetting it even *has* that bug. |
04:25 |
DeepThgt |
a solid workaround is acceptable |
04:25 |
DeepThgt |
ty very much |
04:25 |
DeepThgt |
although i did learn a lot chasing that one... |
04:30 |
DeepThgt |
i am actually interested still in finishing the job of hunting down its cause and fixin |
04:30 |
DeepThgt |
but i still have a bit to learn i think to do so |
04:31 |
DeepThgt |
ive just started digging into rubenwardys book and the api documentation deeply when trying to figure out the cause of the behavior |
04:32 |
cheapie |
Another workaround that might or might not work (haven't tried it) is connecting a Luacontroller to the normal mesecons detector tube and doing things just based on the 'on' event (ignoring the 'off' and the pin state). |
04:32 |
cheapie |
(but if you're going to use a LuaC you might as well just use the digilines one) |
04:32 |
DeepThgt |
ya my other idea i was about to try is use a luac to replace the sticking delay |
04:33 |
DeepThgt |
but ill just do your way |
04:34 |
cheapie |
I have a tendency these days (when I play MT at all, which I am currently not) to just use one Luacontroller for everything (or nearly everything) and few if any mesecons. Digilines becomes quite powerful with a few extra mods using it :P |
04:34 |
DeepThgt |
ya my lua skills are subpar so ive been doing it all in "hardware" |
04:35 |
cheapie |
Time to work on the Lua skills :D |
04:35 |
DeepThgt |
ya especially since now the issues im encountering with running the server involve modding |
04:35 |
DeepThgt |
like adding intercompatibility to our modset |
04:36 |
DeepThgt |
eventually fixing lwcomponents |
04:36 |
cheapie |
See https://github.com/mt-mods/digistuff (full disclosure, originally one of my mods, this is mt-mods's continuing development project of it) for, among other things, a bunch of nodes allowing you to do traditionally mesecons things directly with digilines instead. |
04:40 |
|
kamdard joined #minetest |
04:40 |
DeepThgt |
that was already on the roadmap to add to the server |
04:40 |
DeepThgt |
just have performance issues to tackle first |
04:42 |
DeepThgt |
not that i havent optomized all i can engine side, i just have ideas :D I dont want egg on my face so tight lips unless i/we (the other admin) pull it off |
04:43 |
DeepThgt |
cause if succesful, the backend ideas we have will make a lot of things possible that are currently not due to the architecture of the engine |
04:51 |
|
qqq joined #minetest |
05:00 |
|
MTDiscord joined #minetest |
05:08 |
|
YuGiOhJCJ joined #minetest |
06:52 |
|
s20 joined #minetest |
07:22 |
|
calcul0n joined #minetest |
07:50 |
|
Sobinec joined #minetest |
08:18 |
|
definitelya joined #minetest |
09:01 |
MTDiscord |
<jordan4ibanez> The formspec in TypeScript https://github.com/jordan4ibanez/forgotten-lands/blob/main/mods/formspec/init.ts |
09:10 |
|
krupa1 joined #minetest |
09:11 |
|
s20 joined #minetest |
09:16 |
|
mrkubax10 joined #minetest |
09:22 |
|
Warr1024 joined #minetest |
09:38 |
|
jaca122 joined #minetest |
09:46 |
|
Warr1024 joined #minetest |
09:52 |
|
Leopold joined #minetest |
09:57 |
|
TomTom joined #minetest |
10:37 |
|
Desour joined #minetest |
11:03 |
|
appguru joined #minetest |
11:11 |
|
Waffelo joined #minetest |
11:15 |
|
imi joined #minetest |
11:29 |
|
calcul0n joined #minetest |
12:29 |
|
mrkubax10 joined #minetest |
13:02 |
|
definitelya joined #minetest |
13:08 |
erle |
MisterE123 next blog post when? i want to have xcam in it |
13:11 |
MTDiscord |
<mistere_123> We will probably do one for October-November. It would be nice to mention the game jam in it before it officially starts. |
13:12 |
MTDiscord |
<mistere_123> So... at the end of November. (read: January) |
13:18 |
erle |
LOL |
13:18 |
erle |
minetest blog time dilation |
13:18 |
erle |
thx |
13:19 |
ROllerozxa |
soon the blog interval is gonna become yearly 8) |
13:20 |
celeron55 |
it'll take exactly one blog-month |
13:38 |
rubenwardy |
just rename to "Recently in Minetest" or "Previously in Minetest" |
13:38 |
rubenwardy |
or "Minetest updates" |
13:38 |
rubenwardy |
no that's overloaded |
13:40 |
MTDiscord |
<warr1024> "some time in the past in Minetest" |
13:41 |
MTDiscord |
<warr1024> or better yet, "Once Upon a Time in Minetest" |
13:46 |
|
Lunatrius joined #minetest |
13:50 |
|
maeve joined #minetest |
13:54 |
|
Baytuch_ joined #minetest |
13:55 |
erle |
or just release very months on a schedule unless you have nothing |
13:55 |
erle |
small blog posts are nice too |
13:55 |
erle |
every month i mean |
13:55 |
rubenwardy |
I think the issue is more available time rather than not having enough to write about |
14:02 |
MTDiscord |
<warr1024> It's impossible to have nothing because then you'd just have an article about how blog contributions are worse this month than usual and people need to step up their game 😏 |
14:02 |
MTDiscord |
<warr1024> IIRC the blog is designed around a methodology that could scale well, but in practice people submit requests rather than articles so writing and editing bottleneck. |
14:03 |
|
appguru joined #minetest |
14:05 |
|
dabbill joined #minetest |
14:06 |
rubenwardy |
yeah exactly. Needs more editors |
14:07 |
rubenwardy |
I'm too busy writing about writing to work on the MT blog |
14:07 |
MTDiscord |
<warr1024> I'm too busy writing in here about how there aren't enough people writing elsewhere to write elsewhere. |
14:12 |
erle |
rubenwardy btw would you maybe accept additional info about texture handling? |
14:12 |
erle |
rubenwardy for your book? |
14:12 |
erle |
rubenwardy stuff like which other tools exist, how to optimize textures, what texture formats minetest does not load (it does not load all PNG or TGA files, not sure about JPEG, but arithmetic coding sometimes does not work with programs) |
14:13 |
erle |
my simplest suggestion would be: a bunch of people use mtpaint for textures, but it is not mentioned (the painting program, not the minetest mod) |
14:13 |
erle |
https://en.wikipedia.org/wiki/MtPaint |
14:13 |
MTDiscord |
<warr1024> Oh, a "now that you know how to do it, here's how to do it well" section in the book could be nice, with things like best practices and optimization advice |
14:13 |
erle |
yeah |
14:14 |
erle |
there is so much shitty optimization advice lol |
14:14 |
erle |
(mostly in the forums and on bug trackers) |
14:14 |
erle |
by shitty i do not mean stuff that is outdated, more stuff that totally sounds plausible but does not hold up once you benchmark it |
14:14 |
MTDiscord |
<rollerozxa> 🤔 |
14:16 |
MTDiscord |
<warr1024> There are some basics to distribution, like, make a repo, submit to cdb, use .gitattributes to exclude non-functional files from the "to play" audience download, and run your images through a few lossless optimizers, that are kinda obvious. |
14:17 |
MTDiscord |
<warr1024> One trick I've found is to make your image transparent areas alpha=1 instead of alpha=0, so that optimizers don't throw away the transparent part RGB info. Compare leaves in NodeCore in fancy vs opaque: they look pretty nice in both cases, but I had to preserve RGB info that can't be interpolated to make them work. |
14:18 |
MTDiscord |
<warr1024> In the long run I guess mod optimization advice could turn into a second book though. |
14:18 |
MTDiscord |
<warr1024> Maybe Ruben would want to sit that one out for the most part 😂 |
14:18 |
erle |
warr1024 the lossless optimizer stuff is not obvious, which is exactly what you just explain lol |
14:20 |
erle |
also i have noticed that people are generally not using colormapped images, even though they could |
14:21 |
erle |
or texture atlases for that matter |
14:21 |
rubenwardy |
when it comes to optimisation, I think the best approach would be for people to write blog posts or forum topics about different things. Then the modding book could maybe summarise some important ones and cite those posts |
14:21 |
erle |
rubenwardy and with painting programs? i already know that gimp is not a very popular tool for pixel art or textures in general |
14:22 |
erle |
(at least for those who actually choose the program instead of using the first thing they have installed, e.g. ms paint or gimp |
14:22 |
erle |
) |
14:22 |
MTDiscord |
<warr1024> Gimp seems to be pretty popular in the sense that a lot of people use it, but not necessarily in the sense that a lot of people want to use it. |
14:22 |
erle |
better phrased than i did hehe |
14:23 |
MTDiscord |
<warr1024> I mostly use gimp myself because I've got the head space to fit a jack of all trades tool, not a whole bunch of specialized shit. |
14:23 |
erle |
last night i told my friend to just check something in gimp and he was like “i am using mtpaint, i do not even have gimp installed now” |
14:24 |
MTDiscord |
<warr1024> MtPaint is unfortunately named considering our context here, since I assumed it was a mod that let you paint directly on cubes in the game, which is a gimmick I definitely don't need. |
14:24 |
erle |
Warr1024 those GNU Unifont emojis i did not create with emacs i created using the X11 bitmap(1) program ;) |
14:25 |
erle |
Warr1024 there is also a mod that recreates ms paint in minetest https://cheapiesystems.com/media/mtpaint-saveload.webm |
14:25 |
MTDiscord |
<warr1024> Heh, my preferred format for MT schematics is ASCII art in Lua source code, so there's no accounting for taste when it comes to tools and workflow. Gotta have my spacebar heating. |
14:26 |
erle |
oh, i actually created a bunch of bitmaps for my mods by having lua code generate them with tga_encoder |
14:26 |
erle |
makes it easier to have a usable diff when i update them |
14:26 |
erle |
and it's only small grayscale textures as far as i can remember |
14:27 |
erle |
(okay, almost all minetest textures are small) |
14:27 |
MTDiscord |
<warr1024> I have a few textures that I "bake" using imagemagick because I use a few effects that texturemods can't do, and so I have some media source that's actually obviously code ... and hence one of the reasons I don't do separate media and code licenses... |
14:28 |
erle |
what effects are those? |
14:29 |
erle |
i mean apart from gamma-correct blending :P |
14:30 |
|
Oblomov joined #minetest |
14:30 |
MTDiscord |
<warr1024> Like blur type stuff I think. |
14:31 |
MTDiscord |
<warr1024> Also I'm a bit unsure about how heavily I should lean on texturemods at runtime to begin with. I do some stuff with them that's borderline abuse for a base game texture. |
14:42 |
erle |
Warr1024 please tell |
14:43 |
erle |
Warr1024 i was thinking about making a pixelops mod that does some blending etc. operations in lua |
14:43 |
erle |
instead of using texmods |
14:45 |
MTDiscord |
<luatic> erle: sounds like https://github.com/appgurueu/modlib/blob/master/minetest/texmod/gen_tex.lua |
14:47 |
erle |
-- TODO implement counterclockwise rotations to get rid of this hack |
14:47 |
erle |
for _ = 1, 360 - self.rotation_deg / 90 do |
14:47 |
erle |
t = t:rotated_90() |
14:47 |
erle |
end |
14:47 |
erle |
this is peak lua |
14:47 |
erle |
luatic when are you going to split up modlib lol |
14:47 |
erle |
luatic also this is entirely unlike what i want. i want NO texmods. not even texmod parsing, what you seem to do here (right?). |
14:48 |
MTDiscord |
<luatic> erle: you can use this without texmod parsing |
14:48 |
MTDiscord |
<luatic> just use the dsl |
14:48 |
erle |
we have now 17 competing stantards lol |
14:48 |
erle |
gamma-correct blending when luatic |
14:49 |
erle |
the t/d being directly next to each other on neo2 is the most obvious trap i fall into |
14:49 |
erle |
repeatelyl |
14:49 |
MTDiscord |
<luatic> see https://github.com/appgurueu/modlib_test/blob/master/minetest/texmod/test.lua btw |
14:49 |
erle |
repeatedly |
14:49 |
MTDiscord |
<luatic> oh and also https://github.com/appgurueu/modlib/blob/master/tex.lua |
14:50 |
|
grorp joined #minetest |
14:51 |
|
definitelya joined #minetest |
14:52 |
MTDiscord |
<luatic> Basically modlib.minetest.texmod centers around Minetest's texmod abstraction; it allows constructing (using a simple DSL), parsing (efficiently!), writing (efficiently!), calculating dimensions of, and (roughly) computing textures (if base images are provided). |
14:53 |
MTDiscord |
<luatic> modlib.tex is just a texture implementation; it is the base modlib.minetest.texmod uses when computing textures. It tries to not have its API influenced by Minetest too much, but because it needs to provide all the stuff texmods need, it can't be too different either. |
14:54 |
erle |
luatic why exactly do you not make a lot of minimods but stuff everything into modlib? |
14:55 |
erle |
“(roughly) computing textures” yeah i can immediately see a bunch of cases it does not handle lol |
14:55 |
erle |
the equivalence between that and the minetest texmod handling is slightly questionable ;) |
14:55 |
erle |
but i appreciate the effort |
14:55 |
erle |
have you ever thought about cleaning up minetests texmod handling? you probably did right? |
14:56 |
erle |
i remember lizzy had some program to get used texmods right? |
14:56 |
erle |
did you write/use that too? |
15:15 |
sfan5 |
!seen Wuzzy |
15:15 |
MinetestBot |
sfan5: wuzzy was last seen at 2023-11-11 14:23:37 UTC on #minetest |
15:20 |
MTDiscord |
<luatic> erle: lizzy's program is https://github.com/LizzyFleckenstein03/texmodbot/, yes I used that |
15:22 |
MTDiscord |
<luatic> erle: I am aware (1) that it is not fully equivalent to Minetest's parser - it is not intended to be; (2) that computing the textures differs (for example, I didn't bother looking into how exactly Minetest does scaling) |
15:23 |
MTDiscord |
<luatic> I have thought about cleaning up Minetest's texmod handling, but C(++) is more work, the entire PR process etc. would take a while, and it would probably also be too much work to convince everyone that it is "equivalent enough" |
15:25 |
MTDiscord |
<luatic> as for why modlib is not a bunch of minimods: good question, laziness to some extent I'd say |
15:28 |
erle |
luatic tbh i would actually use parts of modlib if it was not a big ball of stuff |
15:32 |
MTDiscord |
<warr1024> "<erle> Warr1024 please tell" <-- https://gitlab.com/sztest/nodecore/-/blob/master/mods/nc_sponge/node.lua?ref_type=heads#L40-60 |
15:33 |
erle |
spongebob_face.jpg |
15:33 |
MTDiscord |
<warr1024> In the case of water animations, I bake them externally from the source material; in the case of the living sponge animation (a subtle pulsing crossfade) I bake the animation via texturemods. |
15:33 |
erle |
i like that style |
15:34 |
erle |
much nicer than texmods |
15:35 |
erle |
where is the source for nodecore.tmod located? |
15:42 |
MTDiscord |
<warr1024> https://gitlab.com/sztest/nodecore/-/blob/master/mods/nc_api/util_texturemod.lua |
15:44 |
|
definitelya joined #minetest |
15:45 |
erle |
Warr1024 nice mini mod |
15:45 |
erle |
i wonder if it would be nice to have a “mini mod” challenge |
15:46 |
MTDiscord |
<warr1024> you could, but tbh writing really elegant library code is the kind of sport that appeals to only a very specialized kind of spectator ... and actually adjudicating such a contest sounds like a nightmare 😄 |
15:47 |
erle |
the challenge is to come up with useful code |
15:47 |
erle |
not to ”win” |
15:48 |
erle |
i think AOSA has a “X projects in 500 lines or less” booklet |
15:48 |
MTDiscord |
<luatic> lines are a useless metric anyways 😏 |
15:49 |
erle |
https://aosabook.org/en/500L/introduction.html judge for yourself |
15:49 |
erle |
https://aosabook.org/en/ sorry |
15:50 |
erle |
luatic it is more a ballpark thing. the entire redo build system (well, my implementation) is less than 500 lines. as are a bunch of really interesting minetest mods. tga_encoder is 700 lines, but it contains three separate RLE encoding functions because i was lazy. |
15:50 |
|
A_Dragon joined #minetest |
15:50 |
erle |
one of them is even suboptimal |
15:51 |
erle |
(some color reduction happens during encoding and is interleaved with RLE, so the reduces color is encoded, but the decision when to encode a new packet is based on the not-reduced color) |
15:55 |
|
Desour joined #minetest |
15:58 |
|
grorp1 joined #minetest |
16:06 |
|
definitelya joined #minetest |
16:10 |
|
mrkubax10 joined #minetest |
16:52 |
|
sparky4 joined #minetest |
17:34 |
|
Talkless joined #minetest |
17:56 |
|
___nick___ joined #minetest |
18:00 |
|
___nick___ joined #minetest |
18:03 |
erle |
sfan5 do i get an explanation? |
18:04 |
sfan5 |
we haven't discussed what to communicate as the reason/explanation |
18:05 |
|
grorp joined #minetest |
18:07 |
muurkha |
erle: of what? |
18:07 |
erle |
muurkha this: https://irc.minetest.net/minetest-dev/2023-11-19#i_6134290 |
18:08 |
sfan5 |
I mean there are obviously reasons so I'll ask the rest of the team |
18:08 |
erle |
i mean, if it is not a permanent ban there is surely something you want me to do |
18:09 |
erle |
i must say i am not sure what being removed from the org actually implies |
18:09 |
erle |
i mean, i doubt i ever had special privileges? |
18:09 |
erle |
i mean, if so, i did not exercize them |
18:10 |
erle |
(or did not realize i did) |
18:11 |
muurkha |
oh, condolences |
18:32 |
erle |
just one more question about it: was *this* internal discussion #71? i always wondered. |
18:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/71 -- make paths modifiable by hasufell |
18:38 |
MTDiscord |
<warr1024> heh, thanks bot, for posting external discussion 71 out of context 😄 |
18:39 |
|
appguru joined #minetest |
18:42 |
erle |
i just want to point out that if you want me to *stop posting about regressions to the issue tracker* (not sure if that is meant with “minor issues”, but it is a lot of what i do) you can a) ask me to b) ban me entirely |
18:42 |
erle |
from github, i mean |
18:42 |
erle |
i mean, i have already figured out that it is not appreciated |
18:44 |
erle |
(which is why i am generally much more annoying about regressions that affect everyone than stuff that is only happening on my hardware) |
18:46 |
MTDiscord |
<warr1024> If it's really bothering everyone, then surely somebody else will already be likely to file the issue. Considering that we are not suffering a shortage of issues right now, it's not necessarily a tragedy if one gets missed and we have to discover it again later, either. |
18:46 |
erle |
ah, now i get it https://github.com/minetest/minetest/pull/14006 |
18:48 |
n_to |
First they came for Erle and I said nothing, because I wasn't Erle. |
18:49 |
ROllerozxa |
huh |
18:50 |
erle |
Hey ROllerozxa do you want to adopt that patch lol |
18:53 |
erle |
ROllerozxa if you do, you have to incorporate https://github.com/minetest/irrlicht/pull/254 (which i hereby offer as a sacrifice) into it |
18:58 |
n_to |
Musste eben sehr über diese tocotronic Lyrics lachen: |
18:58 |
n_to |
Wenn die Liebe endet, ist es mitten in der Nacht |
18:58 |
n_to |
Ein Lichtschein, der mich blendet, dringt aus meinem Tiefkühlfach |
18:58 |
n_to |
Dort liegt eine Pizza, die ich aufzupeppen versuch |
18:58 |
n_to |
Mit Kräutern der Provence hab ich keine Chance |
18:58 |
n_to |
Ah-ah-ah, ah-ah-ah, ah-ah-anse |
18:58 |
|
n_to was kicked by ShadowBot: Message flood detected. Use a pastebin like paste.ubuntu.com. |
19:06 |
MinetestBot |
[git] sfan5 -> minetest/minetest: Try to fix VS build failures 0e4de28 https://github.com/minetest/minetest/commit/0e4de28988a96e87f6391a654eff8eaeed3ef801 (2023-11-19T15:22:20Z) |
19:08 |
sfan5 |
erle: I will adopt the PR |
19:09 |
erle |
ok cool |
19:46 |
MinetestBot |
[git] Desour -> minetest/minetest: Fix cached wanted_range and camera_fov being written with out-of-rang… 73e85b2 https://github.com/minetest/minetest/commit/73e85b2ebb3e6649244a6fe4548f5b160c7c207d (2023-11-19T19:45:18Z) |
19:46 |
MinetestBot |
[git] Desour -> minetest/minetest: Fix undefined inf to s32 cast in GUIScrollBar::setPos 1bc74b0 https://github.com/minetest/minetest/commit/1bc74b0ba1d92c1b19ce281f974d79e549107794 (2023-11-19T19:45:18Z) |
19:46 |
MinetestBot |
[git] Desour -> minetest/minetest: Clamp values in read_ARGB8 585e6aa https://github.com/minetest/minetest/commit/585e6aa80ba9ee711aebcf3630ab8bbec1e446fd (2023-11-19T19:45:18Z) |
19:46 |
MinetestBot |
[git] Desour -> minetest/minetest: Devtest: Fix testnodes bouncy color calculation 7199ee4 https://github.com/minetest/minetest/commit/7199ee4ff89f8990fd6c9eed9499108ccefc887f (2023-11-19T19:45:18Z) |
19:46 |
MinetestBot |
[git] (1 newer commits not shown) |
19:46 |
Desour |
bim bim bim |
19:48 |
MinetestBot |
[git] MisterE123 -> minetest/minetest: lua_api.md: Add tick marks to position HUD element 31ee7af https://github.com/minetest/minetest/commit/31ee7af3ab805b1c7b64b7a03ff2b663b8030265 (2023-11-19T19:46:40Z) |
19:48 |
MinetestBot |
[git] Wuzzy2 -> minetest/minetest: Fix mod translation updater bugs (#13974) 61db32b https://github.com/minetest/minetest/commit/61db32beee936a5264ef17785d8efaa7cc14bda4 (2023-11-19T19:46:52Z) |
20:19 |
|
ChanServ joined #minetest |
20:33 |
|
krupa1 joined #minetest |
20:35 |
|
n_to joined #minetest |
20:37 |
|
n_to left #minetest |
20:56 |
|
___nick___ joined #minetest |
21:03 |
MTDiscord |
<warr1024> What does the "Unconfirmed Bug" tag mean? Does that mean that anyone can repro and confirm it by posting a comment, or does it need to be specifically reproable by a Core Dev? |
21:03 |
|
mrkubax10 joined #minetest |
21:06 |
sfan5 |
just an indication of state, help is welcome as always |
21:07 |
sfan5 |
if someone comes around and says they reproduces it (and it's credible), we can re-tag the issue |
21:14 |
|
fox joined #minetest |
21:14 |
celeron55 |
it could be written out as "failed to reproduce bug or information missing for reproducing" |
21:15 |
fox |
Hello! |
21:15 |
|
jaca122 joined #minetest |
21:16 |
MTDiscord |
<warr1024> In this case it sounds a bit more like "I don't have the time to even attempt to reproduce it right now, but am hoping somebody else does." I actually thought we had it as an automatic tag at one point, but it looks now like it's applied manually by triagers. |
21:17 |
sfan5 |
pretty sure it's still autoamtic |
21:17 |
sfan5 |
automatic* |
21:18 |
celeron55 |
it could be renamed if the name is too discouraging or confusing |
21:18 |
celeron55 |
"Problems reproducing bug" or something |
21:19 |
MTDiscord |
<warr1024> oh, haha, it IS automatic, I misread my own damn name as wsor4035 because his name was right under it, and our names look too similar. |
21:20 |
MTDiscord |
<warr1024> It seems okay to me now; knowing that it is actually automatic helps me not take it as some kind of criticism or mistrust or something; it's just a default state. |
21:20 |
celeron55 |
actually this is not a good name either as it's essentially intended to be applied to all bug issues first |
21:21 |
celeron55 |
"To Reproduce" would be an usable alternate name |
21:21 |
MTDiscord |
<warr1024> "Needs verification" or something could be more helpful, i.e. as a call to action. |
21:22 |
MTDiscord |
<warr1024> some kind of name that encourages people to try it out for themselves. |
21:22 |
celeron55 |
and of course the reason it's this way and not the other is that a tag gets more attention than no tag, and uncofirmed bugs need more attention than confirmed ones (at least that's my thinking) |
21:22 |
MTDiscord |
<luatic> celeron55: when the bugs start to reproduce we'll be in deep trouble... |
21:23 |
MTDiscord |
<luatic> I like "needs verification/confirmatioN" |
21:23 |
celeron55 |
"Needs confirmation" is closest to the current one, people might even realize it's the same tag |
21:24 |
MTDiscord |
<warr1024> I wonder whether it should be something like "confirmation wanted" rather than saying "need" ... in case we don't necessarily want to imply that it will NOT be worked on unless somebody else can repro it. |
21:25 |
MTDiscord |
<warr1024> Like, I don't know if anyone will be able to get the same results I did in my tests (people with more powerful hardware will have a harder time of it) but it sounds like the fix for it (batching draw calls) is something that's desired anyway. |
21:26 |
celeron55 |
the tag/label is referred to by name in the issue template so that needs to be changed also if the name is modified |
21:26 |
MTDiscord |
<warr1024> 14018 just in case the context is missing. |
21:26 |
MTDiscord |
<luatic> I think it's a good thing if our issues sound "needy" :-) |
21:26 |
MTDiscord |
<luatic> Quite frankly, if no one can reproduce an issue, chances that it will be worked on are pretty slim... |
21:26 |
MTDiscord |
<warr1024> Well, what we NEED is fixing of problems, not necessarily putting more prerequisites in front of fixing... |
21:28 |
MTDiscord |
<warr1024> 14018 actually sounds like the kind of issue that a few people have wanted to fix just out of general principle, so actually knowing it will have a real-world impact and isn't just a theoretical or unmeasurable thing might help. |
21:48 |
sfan5 |
!mod modlib |
21:48 |
MinetestBot |
sfan5: Modding Library [modlib] by LMD - https://forum.minetest.net/viewtopic.php?t=22345 - https://github.com/appgurueu/luon |
21:48 |
sfan5 |
that seems a bit off |
21:49 |
sfan5 |
!cdb modlib |
21:49 |
sfan5 |
hmm does MinetestBot not have this |
21:53 |
sfan5 |
@luatic glad to find out that modlib does not optimize written PNGs better than the engine |
21:54 |
erle |
well you both did the simplest thing that works |
21:54 |
erle |
it's not surprising |
21:55 |
erle |
also optimizing PNGs is not so easy unless you know what is in the texture, you have a combinatorical explosion, with the lowest thing doing it 5 times with different prefilters. |
22:37 |
|
qqq joined #minetest |
22:46 |
|
LizzyFleck joined #minetest |
22:50 |
|
appguru joined #minetest |
23:28 |
|
CRISPR joined #minetest |
23:34 |
|
panwolfram joined #minetest |
23:37 |
|
sometalgoo joined #minetest |
23:44 |
|
amfl2 joined #minetest |
23:53 |
|
appguru joined #minetest |
23:54 |
|
fluxionary joined #minetest |