Time  Nick      Message
09:25 kilbith   would it be a waste of time if I redesign the mainmenu myself?
09:26 nrz       depends if we merge or not ? ?
09:26 kilbith   that's what I'm asking, would it be seriously considered by the committee?
09:27 nrz       what is the main menu needs you want to implement ?
09:27 kilbith   because the GUI rewrite ain't gonna happening and I can't stand that design any longer
09:27 nrz       it's clearly a year 90 design in terms of game menu ?
09:27 nrz       functional but not so enjoyable
09:28 kilbith   and I don't see anyone else making a better work at this but me
09:28 nrz       we need multiple views and navigation instead of this tab model
09:28 kilbith   rubenwardy: ^
09:29 kilbith   okay, everyone has an idea but I want to impose mine as I have the legitimacy for it
09:29 kilbith   otherwise we wouldn't never get a new design
09:29 kilbith   -n't
09:29 nrz       don't impose but propose
09:29 nrz       and if it's a good idea you have my suport ?
09:30 kilbith   we aren't going anywhere with that
09:30 nrz       maybe draft some design on paint or something like this to show us what you expect to do
09:30 kilbith   and I'm not waiting for your feedbacks tbh
09:30 nrz       then why are you asking if you don't care ? ?
09:31 kilbith   because you are not the guy to talk with about GUI stuff.
09:31 nrz       i'm not GUI owner but i have design ideas in mind, it doesn't mean i should be ignored
09:31 nrz       those silo are so 90 development model ?
09:36 erlehmann kilbith, look just implement it and see how it goes?
09:36 MTDiscord <luatic> kilbith: striving to become the new Mainmenu Dictator?
09:37 erlehmann current main menu has a few warts, but it's very functional
09:37 kilbith   I just expect the committee to give me free hand on it, so that I don't waste my precious time
09:37 erlehmann if you can improve on that, i bet ppl will like it – if you remove functionality, prepare for being ridiculed, i guess?
09:38 erlehmann “I just expect the committee to give me free hand on it”, ah yeah, where in history did this ever go wrong?
09:38 erlehmann kilbith, do you have code? i am willing to test your new main menu
09:38 kilbith   look, I don't give a fuck of whay you say in this channel
09:38 kilbith   it's all noise
09:39 kilbith   just look at my legacy and maybe you would understand why I'm requiring this
09:39 kilbith   endless discussions doesn't lead to anywhere, time for action
09:40 erlehmann i get it. if the answer to “i am willing to test your code” is “i don't give a fuck what you say”, obviously you don't want or need any help.
09:40 kilbith   I just want the green light from the decision makers
09:50 erlehmann <kilbith> just look at my legacy and maybe you would understand why I'm requiring this
09:50 erlehmann kilbith URL?
09:53 kilbith   https://github.com/minetest/minetest_game/blob/master/mods/creative/license.txt#L6
09:54 kilbith   https://github.com/minetest-mods/i3
09:54 kilbith   I also designed the mainmenu of EvidenceB/Kidscode
09:55 kilbith   oh and: https://github.com/minetest/minetest_game/blob/master/mods/mtg_craftguide/license.txt#L6
09:56 kilbith   + several contributions to the GUI engine
09:56 kilbith   :]
09:58 erlehmann i see
10:01 nrz       tbh kilbith we all have precious time, just do what you want to do and stop think you are over others ?
10:02 nrz       it's totally toxic behaviour and not constructive
10:05 kilbith   I'm better than all of you at GUI making, it's just fact
10:06 kilbith   the same way that hecks is better than all of you at understanding the rendering pipeline
10:06 kilbith   and he had free hand at refactoring IrrlichtMt
10:07 erlehmann and created totally avoidable problems, yeah
10:07 erlehmann look, just being very good – experience and talent-wise – doesn't mean that everyone will agree with you in the end
10:07 kilbith   sure - that's how I became the best
10:07 erlehmann usually you can't shortcut to acceptance
10:08 kilbith   I listened people an observed other work
10:08 kilbith   * and
10:09 erlehmann look whenever i talk about signed integer overflows or validating inputs or constraints, ppl don't care much – unless i produce a crash (or worse), then they suddenly do.
10:11 erlehmann why should it be different for any other discipline? i do disagree with hecks a lot, but i never saw hecks claiming ppl waste their time wanting results before they make up their mind (granted, i should probably look further back).
10:11 kilbith   because you are german and you struggle with central authority, it is in your culture
10:13 kilbith   I come from a very centralized country and the decision process can be very effective country-wise compared to Germany
10:15 kilbith   that's what we need in MT, less german-ey and more french-ey
10:15 kilbith   for the community benefit
10:15 erlehmann germany had very effective central decision making. millions of people died. end of history lession.
10:15 erlehmann tbh this is a stupid argument.
10:16 erlehmann lesson.
10:16 kilbith   France has centuries of monarchy and still has a very centralized model, and it works better than Germany duh
10:17 erlehmann look, i am not interested in debating which country can fail more often conquering europe.
10:17 erlehmann it has nothing to do with the main menu
10:18 kilbith   we need to understand your background culture to understand your arguments on this one
10:18 kilbith   that the MT's model is too influenced by the germanic culture
10:18 erlehmann i am pretty sure that my main argument is “if you compare yourself to hecks favorably, then you will make similar mistakes and maybe even lie out of arrogance”
10:19 erlehmann as being talented and skillful does not mean you do not make mistakes
10:19 kilbith   sure, but the thing is, I'm *less* prone to mistakes than anyone else on this discipline
10:20 erlehmann i work at a company where everything technical needs a mandatory review. it helps so much
10:20 kilbith   and I leave you on that - bye
10:21 erlehmann kilbith, i suspect your mistake is to think that others will value your time so much that they think it is unreasonable to wait for a prototype before making decisions?
10:33 hecks     Slowly getting back to the shader thing, did I miss anything important?
10:37 erlehmann hecks you may have missed the part where ppl figured out you didn't do your research about what file formats and hardware are in use and what isn't, but i guess that will come up in code review if you do that again.
10:38 erlehmann hecks do you have an idea how to detect cards that claim to support ogles but actually don't?
10:38 erlehmann bc i have a bunch of computers with cards that … uh … render total bullshit, to say it mildly.
10:38 hecks     I guess you can just do a duck test
10:38 erlehmann duck test?
10:39 hecks     try to get a function pointer and use an ES2 api, see if it works
10:39 hecks     if it compiles a shader, it's probably fine
10:39 erlehmann no no, what i mean is: the stuff is then *not* fine
10:39 hecks     it breaks visually?
10:39 erlehmann yep
10:39 hecks     well, that's a driver/hardware issue, it's not GLES2 compatible
10:40 hecks     hopefully those devices are very rare
10:40 erlehmann yeah but how to detect that?
10:40 hecks     well, you don't detect a driver bug, you can add some workaround for it once it's known
10:40 hecks     based on the vendor string
10:40 hecks     that's the normal way to do this sort of thing
10:40 hecks     of course if a card is a basket case then it's probably not worth the effort
10:41 erlehmann render using mesa with LIBGL_ALWAYS_SOFTWARE=1 and compare? that's an idea, but the problem is i already figured that mesa disagrees sometimes without noticeable visual artifacts
10:42 hecks     that is something you can do for an automated test, and you can use a heuristic to accept "good enough" images
10:42 hecks     if you want to weed out bad cards in bulk
10:43 hecks     in that case you just need reference images rendered by mesa or a known good card, and a scene used to produce these
10:43 hecks     log some kind of event when an image is different enough and then investigate manually where it fails
10:44 hecks     I wonder if a test suite like this already exists, it must be a thing
10:44 erlehmann hecks the problem is that once you rip and tear everything out and i only got OGLES2, minetest quickly goes from “run on all computers i own” to “runs on the reform2” (the newest computer i own) and i would be a bit pissed if it didn't render right, so i want to identify it early.
10:44 hecks     Do know that GLES2 is far from high hanging fruit feature wise
10:45 erlehmann it's a new laptop that got delivered this year, it has imx8
10:45 hecks     where by GLES2 I also mean the subset of desktop OpenGL 2 that matches it
10:45 erlehmann ah ok?
10:45 erlehmann “log some kind of event when an image is different enough” i was also for that, but a lot of people here said comparing images visually is bad testing, for reasons i do not understand
10:45 hecks     well I meant obvious things like things not sorting correctly
10:46 hecks     in any case you'd inspect the result manually and figure out what breaks, and probably file a bug with your driver vendor
10:46 erlehmann there is already a workaround for the reform1 (a 2018 laptop) in minetest
10:46 hecks     the alpha discard thing?
10:46 erlehmann i think yeah, if that's the thing contributed by mntmn (the laptop guy)
10:47 erlehmann had something to do with plant rendering i think
10:47 hecks     I mean we can prioritize support for all sorts of libre friendly hardware and software if that concerns you
10:47 erlehmann well if you need rendering tests on reform2, ping me
10:47 hecks     either way, discard as alpha test is actually the GLES2 way to do it
10:47 hecks     and it's legacy GL features that this card was having issues with
10:48 erlehmann i already figured out that it gets 10 fps more if you use ogles (meanwhile, all the old thinkpads i have get like 10 to 15 fps *less*)
10:48 hecks     and I'm inclined to believe that it's more likely that a fixed function GL feature would be neglected in a driver rather than ES2
10:48 hecks     as for FPS, I've already investigated this
10:48 hecks     the irrlicht GLES2 driver is just comically bad
10:49 hecks     we can replace it
10:49 hecks     this is because irrlicht uses it in a way that tries to be compatible with how irrlicht does things, and irrlicht was made for fixed function and software rendering mostly
10:49 erlehmann ah, well, it's a difficult situation. i believe the vivante GPU driver was mostly improved by a vendor of inflight-entertainment systems or something like that.
10:50 hecks     if we bypass irrlicht and just use GL2 itself, framerate should be optimal
10:50 erlehmann this is hearsay ofc, but what i heard is that basically they only focus on what makes their menus and videos work
10:51 hecks     well, that sucks
10:51 hecks     however, limiting the GL subset to ES2 actually reduces the bug surface for those wonky cards
10:51 erlehmann indeed. what i'm saying is that real life hardware is far removed from whatever steam surveys ppl use to justify supporting this or that
10:51 erlehmann integrated graphics is just a minefield
10:51 hecks     ES2 is only a couple dozen procedures, less chance of a driver not doing one of them correctly
10:52 hecks     unfortunately if a card is really bad and doesn't do 3D graphics properly, mesa should be used
10:53 erlehmann so what would you expect to support hardware that can't do OGLES2 correctly? mesa software rendering doesn't really cut it, i know of no machine on which i get a playable game that way.
10:53 hecks     ultimately, at one point a fixed function path would be a big liability
10:54 erlehmann i once again want to offer that i can try to maintain the existing fixed pipeline code, as in try to keep it working and implement workarounds for stuff like night vision (idc what happens elsewhere, as long as it doesn't break that). but i have very little understanding of it other than “seems to work”.
10:54 hecks     the problem isn't just our workload
10:54 hecks     imagine a modding API that allows game defined shaders
10:55 erlehmann that sounds horrifying
10:55 erlehmann like webGL
10:55 erlehmann i.e. a HUGE security issue
10:55 erlehmann (like webGL)
10:56 hecks     From what I gather the only problem is people exploiting crappy drivers, not the idea of shaders itself
10:56 hecks     anyway, imagine that security issues are sufficiently solved and this is a thing
10:57 hecks     now modders also have to worry about fallback textures for fixed function clients
10:57 erlehmann look, i barely know C++, but i have seen the quality of minetest code
10:58 erlehmann i develop on mineclonia (mainly performance fixes) and i can assure you modders have to think back as far as 5.3
10:58 hecks     well, if I'm the one implementing and reviewing it then maybe it will be acceptable, I do security sensitive things in my day job
10:58 erlehmann ok cool
10:58 hecks     *implementing or reviewing it
10:59 erlehmann i do too, but no one ever believes me when i say every signed integer overflow is bad lol
10:59 erlehmann btw, did you ever try to write to memory from voxelmanips
10:59 hecks     as I've said, there is not much a GPU itself can do to harm your computer, and few people would waste a good driver zeroday to pwn a few minetest players
10:59 hecks     the worst part is usually the shader compiler but that can be mitigated with heavy sanitization
11:00 erlehmann i worrd about shader compiler too
11:00 hecks     memory from voxelmanips.... kilbith has a branch for that
11:00 erlehmann i have a meeting, see you later
11:00 erlehmann nice
11:00 hecks     I haven't tried it myself yet but I'll probably do it at some point
11:00 erlehmann so it is already being exploited?
11:00 erlehmann i only can get crashes so far :/
11:00 hecks     exploited? uhh
11:00 hecks     I thought you meant ffi pointer access to VM data
11:00 erlehmann i have never been able to write into memory that i should not write into without it being crashed
11:01 erlehmann i suspect it should be able to construct a mesecons machine to take over the host
11:01 erlehmann but i haven't managed to o anything else than crashing
11:01 erlehmann there is a fun bug though with which you can obtain arbitrary nodes
11:01 hecks     uh oh
11:01 hecks     has this been reported?
11:02 erlehmann of course not, no one takes less important stuff seriously without a demonstration. so it would only benefit bad ppl.
11:02 erlehmann if i get somewhere i tell you
11:02 hecks     this does seem like an attack vector though I doubt that with good ASLR you could do anything remotely interesting
11:02 erlehmann oysterity, and clamity before it, has to deal with griefers who actually try to crash the server
11:03 hecks     denial of service is still a vulnerability though and you should report it in the current state
11:03 hecks     I mean, report what you already have
11:03 erlehmann sorry, i got bad experiences with that
11:03 hecks     with reports?
11:04 erlehmann with reporting stuff where i do not have a fully working bugfix. essentially, i often warn about obvious but wrong solutions, but ppl latch on to them – probably bc i am quite bad at explaining why the obvious solution is wrong.
11:04 hecks     we have a special form for reporting vulnerabilities, you could use that
11:04 hecks     those aren't public I think
11:05 hecks     just tell us how you can crash a server with node manipulation and we can continue from there
11:05 erlehmann look, i have been through this in other projects too. when i report a thing *with a proof of concept*, it gets fixed. but when i report something without, it gets ignored. and if i say “the obvious but wrong bugfix is X”, ppl just *love* X sometimes.
11:06 hecks     A minimal lua mod that causes a segfault without using an unsafe environment would suffice
11:10 erlehmann hecks, i recently filed an issue. reading nodes out of bounds of s16 with minetest.find_nodes_n_area crashes (but only in specific areas actually). the obvious but wrong bugfix is limiting that function to MAX_MAPGEN_LIMIT or how it is called and i seem to be very bad at explaining *in abstract* that having 31000 as the boundary leads to more problems than just choosing the boundaries of the s16 data type.
11:11 sfan5     hecks: o/
11:11 erlehmann so if i can not explain it will, i need to make a bugfix myself before reporting it.
11:11 hecks     hi sfan
11:11 erlehmann it's that simple
11:11 erlehmann will → well
11:11 hecks     well, whatever works for you :o
11:11 erlehmann minetest is comparatively fine
11:11 hecks     just, if you can't nail down that voxelmanip vulnerability then please report what you have because it's important
11:12 hecks     someone else could figure it out
11:12 erlehmann i actually suggested minetest as a good target for the next team event of the security team at my workplace
11:13 erlehmann bc tbh i suck at writing exploits
11:13 hecks     wow, nice
11:13 erlehmann well, we will see
11:13 erlehmann i doubt ppl like it as much as i do, but the team is small (less than 10 ppl)
11:13 hecks     you'll probably find a dozen ACEs -.-
11:13 erlehmann last time we got some iot webcam and opened it up to replace the binaries
11:13 hecks     pay attention to the packet serialization especially
11:13 hecks     I'm sure there's a rats nest somewhere in there
11:14 erlehmann which told me i am very bad at cross compiling for non-libc stuff
11:14 erlehmann hecks do you have contact to anon5?
11:14 hecks     who's that?
11:14 erlehmann ppl like fleckenstein or cora or specing or me cheat in minetest by having a custom client.
11:15 hecks     I am vaguely aware of fleckenstein's custom client thing
11:15 erlehmann anon5 made a) a custom go library to dissect the protocol b) a proxy for minetest to reduce lag by removing stuff from overlong item meta (i think this breaks map saving though) c) probably a bunch of other things that are not public
11:16 hecks     interesting
11:16 hecks     by dissecting the protocol you mean something like a packet inspector?
11:16 erlehmann yeah, i look for it
11:16 hecks     that's not hard to do with the code being public and all but
11:16 sfan5     well if he wrote a proxy I bet it's more of a reimplementation
11:16 hecks     spoofing packets is where the fun begins
11:17 erlehmann the proxy has been used for a long time on clamity
11:17 erlehmann and i think it might be in use on oysterity as well
11:17 hecks     I once crashed MT by using clumsy to simulate packet corruption so that's why I suggest people look for vulnerabilities there
11:18 hecks     the packet code is completely untyped and more like assembly, the packet structures are defined in comments and only exist as code encoding and decoding them
11:19 hecks     goes without saying that this is a precarious way to do things :o
11:20 hecks     would be nice if someone replaced that with actual structs
11:20 nrz       in fact kilbith to make you on ground, you are clearly not the best, but the only one it seems. It means you are the best from the only people on it. No reason to congrats you and being toxic ?
11:20 hecks     uh oh drama
11:20 sfan5     nrz: he left already (but might read the log)
11:22 nrz       oh okay matterbridge is not showing irc users events ? thanks sfan5
11:24 erlehmann hecks, for context, kilbith previously today was like “give me absolute power over main menu refactoring, i am better than all of you. also germany sucks, france is superior.”
11:24 erlehmann IMO nrz is not exactly wrong in calling that toxic
11:25 erlehmann just read the logs if you want the drama
11:25 nrz       hello hecks, glad to see you there
11:25 erlehmann sfan5 hecks https://github.com/anon55555/mt
11:25 erlehmann i am pretty sure anon5 cheats using that thing
11:25 nrz       for the GL issues, on my pretty external point on view as i'm not so active nowadays, it seems that removing stuff broke many people setup, it's pretty anoying unfortunately. We should ensure some compat level and not let them cry because we broke them ? i think irrlicht has subtile things for them ?
11:26 hecks     the removed thing that broke people's stuff was not really GL related
11:26 erlehmann yeah, it was just standard “did not do the research”
11:26 erlehmann i bet hecks has learned from that
11:26 hecks     the thing is that this wasn't documented
11:27 nrz       yeah if i read you correctly you said driver, but it's the problem with GL, that there is the norm, and there is the implementations xD
11:27 nrz       i think mesa have interesting shits due to hardware too ?
11:27 hecks     and mineclone was just about the only user of this, also, I gave them a dynamic PNG API to migrate to and hope they eventually will
11:27 hecks     because what they are doing seems like a pretty poor use of bandwidth
11:28 erlehmann the dynamic png API arguably sucks for the purpose that mcl wants it to, but lets talk about this later
11:28 hecks     TGA has almost no compression =[
11:28 erlehmann i also thought that bandwith was the issue originally
11:28 hecks     it's the same thing they do really, saving an image to a file
11:28 erlehmann but it's not
11:28 hecks     the only thing that "sucks" about my implementation is that I skipped the paeth predictor, but that can be added
11:28 erlehmann the issue is a) ease of use to write from lua b) supporting minetest <5.5
11:28 hecks     in any case, zlib probably beats TGA's RLE
11:29 hecks     I'm fine with this revert until 6.0
11:29 nrz       hecks: i'd say if TGA is shit format it's not reason to remove it i think :p if end user wants bad exp on their server it's their issue, not our
11:29 sfan5     it's already added back so not much point discussing it a lot
11:29 hecks     I just swept it up with more than a dozen other obscure formats, irrlicht actually requires DIB support to compile so I thought it was redundant with that
11:30 hecks     this was purely housekeeping to make irrlicht compile faster and be more viable for absorption
11:30 erlehmann hecks, to summarize: PNG is better than TGA for bigger images, even without the predictor thing. TGA – even uncompressed – is better for small pixel art. the ideal thing you want as a mod is having palette support.
11:30 hecks     does TGA have indexed modes?
11:31 hecks     granted, I did not implement those but we actually discussed it here and decided against it
11:31 erlehmann the “always RGBA” thing is definitely not what a mod like the maps mod wants
11:31 erlehmann bc internally it already builds a palette
11:31 hecks     I'd actually have to test that cause I kind of doubt that TGA wins even in a 16x16 tile (and in any case, you probably want a tileset if you really care about space)
11:32 hecks     from what I understand about deflate, zlib should always win vs TGA's rle
11:32 erlehmann i tested it and was suprised, but at such small sizes it is not about image size anymore (and if it were, it depends on the image)
11:32 erlehmann you forget the PNG overhead, which easily beats the payload for small images
11:32 hecks     in any case, if you have lots of small tiles and care about space, *please* build a tileset and use ^[sheet:
11:32 erlehmann youwrite ~70 bytes before you write a single byte of payload. but again, that's not the issue.
11:32 hecks     this is the greatest thing you could do for your load times
11:33 erlehmann the issue is that with TGA you dump a header and then dump the pixel data or the bytes that index into the palette
11:33 hecks     because the compression can then reuse data from between tiles, which it can never do with individual images
11:33 erlehmann it is basically impossible to get that wrong
11:33 erlehmann even if you do it by hand
11:33 erlehmann that is why it is used
11:33 hecks     well I made the API as easy as building a TGA, anyway there was just one mod in existence using TGA and we reverted it for them. case closed
11:33 erlehmann i remember that mcl2 actually experimented with png before you even came up with your api and chose tga
11:34 erlehmann my issue is bigger, you made the API without understanding why ppl chose a particular thing
11:34 hecks     yes because I made the API for them specifically
11:34 erlehmann you did not, or you would have made it paletted
11:34 erlehmann the mcl2 code internally builds a palette for each node
11:34 erlehmann to figure out how to make the picture
11:34 erlehmann you could have used that
11:35 erlehmann no need to do it now
11:35 erlehmann i just want to point out that your solution is not as useful as you think it is
11:35 sfan5     that would have arguably made the API more complex for anyone else
11:35 hecks     I discussed it with some people here in the channel and suggested indexing myself
11:35 hecks     even wanting to make it the only possible mode
11:36 hecks     we went with RGBA instead for simplicity
11:36 erlehmann as i said, the simplest API right now (in terms of maintenance and backwards compat) is – from the POV of a mod author – dump 20 bytes of header and then dump your pixels. case closed (for now).
11:36 erlehmann hecks i will do some work on the maps API in the future, i'll get back to you with complaints to improve the API. ok?
11:36 hecks     you're forgetting the part where you actually have to know the structure of the TGA format
11:36 hecks     many modders don't know even that
11:37 hecks     anyway, palettes and predictors are on the to-do list for PNG
11:37 erlehmann i suggest to talk to appgurueu about that
11:37 hecks     I can implement paeth and palettes myself, thanks
11:38 erlehmann no, bc to me it seems the C thing is not noticeably faster than doing it in lua, but maybe that is only for small image sizes
11:38 sfan5     writing RGB instead of RGBA or paletting sounds more useful to me than predictors in terms of compression
11:38 sfan5     maybe I'm wrong
11:38 hecks     if every pixel gets an FF alpha it'll probably end up getting a short huffman code
11:39 erlehmann sfan5 everyone involved (including you and me) has been so wrong about “this is better than that in terms of compression” before benchmarking it, so i say: measure it. but round trips will eat your lunch much more than 50 bytes savings.
11:39 sfan5     better than a short huffman code is no huffman code ;)
11:39 hecks     and then repetitive pixel sequences will get RLEd together by deflate
11:39 hecks     this is why palettes aren't actually that big of a deal
11:39 hecks     deflate is capable of RLEing not just one color but a repeating sequence of them
11:40 erlehmann look hecks, just compare the checkerboard texture from devtest with the same but optipng having crunched it
11:40 erlehmann you get a 95% in filesize
11:40 hecks     checker pattern sounds like a trivial case for deflate
11:40 erlehmann IMO that should be the target
11:40 erlehmann it *sounds* trivial but obv the current implementation doesn't cut it
11:40 hecks     sure thing, I think paeth would do the trick, we don't have that currently
11:40 hecks     just let me get more important things done first
11:41 erlehmann as i said, pls don't work on it right now. there is no need.
11:41 hecks     this png thing was an emergency feature made in a day after I heard that MCL needs dynamic images and it kind of annoys me that people complain about it
11:41 sfan5     erlehmann: did you benchmark it properly by setting the highest compression level inside MT?
11:42 erlehmann hecks, the other thing about TGA is that at least windows 10 minecraft seems to use it, so removing it removes support for copying over mc assets without converting them.
11:42 hecks     does our api even take a deflate level param?
11:42 sfan5     you wrote it you should know
11:42 sfan5     yes
11:42 erlehmann sfan5, probably not. why is this even adjustable?
11:42 erlehmann i just took the devtest image and figured it is 20 times the size it should be
11:42 hecks     I wrote it almost half a year ago ;-;
11:42 sfan5     hmm I don't know, try thinking about it
11:43 hecks     also, pirating minecraft assets doesn't sound like a high priority concern
11:43 hecks     sorry about that
11:43 erlehmann look, i don't intend to shit on it. having texture generation is cool. but a) it's not the thing that helped at the moment b) it needs work.
11:43 hecks     and nothing that a trivial convert script couldn't handle
11:43 erlehmann and c) if you don't need the API, spare yourself the frustration
11:44 hecks     I need the dynamic image API myself for, guess what, map display
11:44 erlehmann i think you over estimate what kind of person copies minecraft skins over
11:44 sfan5     your concern appears to be "it needs to be 100% identical to use with existing case, smaller and faster than TGA in my usecase"
11:44 erlehmann ah lol
11:44 hecks     I've been using PPM before actually
11:44 sfan5     which is honestly not an useful standard
11:44 sfan5     s/case,/code,/
11:44 erlehmann well hecks previously claimed it was only made as an emergency measure for that map thing, maybe i got it wrong
11:45 erlehmann honestly, as a mod author i'd love having PPM much more than TGA
11:45 erlehmann (if you can compress it in flight, obv)
11:45 hecks     now that's one way to make your users download megabytes
11:45 erlehmann ease of use trumps everything else
11:46 hecks     sure it would be lovely if we just zlibbed ALL assets
11:46 erlehmann no, only the ones where it makes sense
11:46 MTDiscord <exe_virus> Btw, there's even better formats coming out, avix is awesome, and webp2 is another 30% smaller for lossless compression than webp haha.   As for the zipping thing, no
11:46 erlehmann you wouldn't zlib a vorbis file
11:46 hecks     but uh. ppm isn't any easier than having an image building API you can use from lua
11:46 MTDiscord <exe_virus> Zlib makes png, jpg, vorbis, etc. Larger
11:46 hecks     oh sure about vorbis
11:46 hecks     I was thinking models, those should be compressed
11:47 MTDiscord <exe_virus> And requires extra processing power. Hell yes to the obj and eventual .gtlf/collada compression with zstd
11:47 erlehmann look, it's a tradeoff. as someone running minetets on a slow connection with an old computer a bit, i can tell you that asset size is *usually* not a big problem.
11:47 hecks     gltf has its own compression, DRACO
11:47 hecks     which is honestly the best but yeah. we'd have to implement gltf
11:47 MTDiscord <exe_virus> But then we have to bring in draco, and draco is lossless
11:47 erlehmann exe_virus collada needs XML and XML got axed
11:47 MTDiscord <exe_virus> Not lossless***
11:48 hecks     for now I would just attempt zlibbing every media asset on server init and pick whichever is smaller
11:48 MTDiscord <exe_virus> Draco looks like crap for a lot of our use cases sadly
11:48 erlehmann uh, don't do it
11:48 hecks     collada sucks.
11:48 MTDiscord <exe_virus> True
11:48 hecks     well draco compression relies on quantization
11:48 hecks     it's actually the same trick I use to compress ascii meshes now
11:48 hecks     but binary quantization would be a lot more efficient
11:48 MTDiscord <exe_virus> I was leaning just gltf for mesh data, animation data, and texture data
11:49 sfan5     different topic:
11:49 sfan5     hecks: what are your thoughts on the how TTF pixel fonts become blurry at certain sizes and how the legacy bitmap font support could avoid this? erlehmann argued this and as far as I can tell he's right (not that anyone has or would ever use this)
11:49 MTDiscord <exe_virus> When do they become blurry? When the TTF doesn't support a certain font size?
11:49 erlehmann i think the reason that the TTF becomes blurry is very simple: minetest allows setting the size of the font only in pt, not px.
11:49 hecks     my thoughts are that it's fine to use TTF for pixel fonts as long as you can constrain the size to the sizes that the font actually implements
11:50 sfan5     well we don't have size constraints
11:50 hecks     and their integer multiples
11:50 erlehmann hecks, it renders differently based on the dpi though
11:50 MTDiscord <exe_virus> Well, we could also do a different resize algo
11:50 erlehmann with 120 dpi 16pt unifont is blurry, with 96dpi it is not
11:50 sfan5     so I guess this is the same conclusion
11:50 MTDiscord <exe_virus> That doesn't do blending
11:50 hecks     and this is exactly the thing I've been complaining about re: DPI and absolute GUI sizing, that v-rob(?) has been arguing with me about
11:50 hecks     to make a nice GUI you need absolute sizes on things. period
11:50 hecks     integer scaling is fine
11:51 MTDiscord <exe_virus> Yep, we need DPI and viewport dimensions exposed to make formspecs perfect
11:51 sfan5     I bet you support #10632 too then
11:51 ShadowBot https://github.com/minetest/minetest/issues/10632 -- Retrieve DPI from get_player_information
11:51 hecks     and honestly, integer scaling is probably all you need to handle various screen sizes
11:51 erlehmann i think v-rob did not understand the part where the font size is given in pt but pixel fonts need 1pt = n * 1px
11:51 hecks     well we have some issues with DPI and GUI sizing in general
11:51 erlehmann tbh i doubt exposing dpi is the way to go actually
11:51 hecks     at the moment, there is no way to have a pixel perfect GUI at any DPI
11:52 hecks     some things will always be wonky, item icons usually
11:52 MTDiscord <exe_virus> It's the way to go if we don't want to do something fancy engine side
11:52 erlehmann i *really* would like to have a guarantee that my assets are rendered with an integer scaling
11:52 hecks     yes exactly
11:52 erlehmann other games do that too, like openttd
11:52 erlehmann ok it has 1.5x
11:52 erlehmann but it is the users fault if they chose that tbh
11:52 sfan5     somehow relevant #11753
11:52 ShadowBot https://github.com/minetest/minetest/issues/11753 -- Images in formspecs use "smooth" linear instead of nearest neighbor filtering
11:53 hecks     filtering is another thing, although
11:53 erlehmann i think pixel fonts currently expose that thing very well. but the images in formspec or images in main menu thing does too.
11:53 hecks     if you're on integer scale, GL_LINEAR should look exactly like GL_NEAREST
11:53 sfan5     the tricky thing about the DPI thing is whether we want to account for runtime DPI changes or not
11:53 erlehmann like there is no way to get the mineclonia icon show up nicely
11:53 hecks     can we just snap the DPI to known integer values
11:53 MTDiscord <exe_virus> Maybe we need to add the option for a different blend mode?
11:53 erlehmann sfan5 that's not very important IMO, most apps require a restart
11:53 erlehmann hecks, no lol
11:53 erlehmann hecks, how do you think this would work for pixel fonts?
11:54 MTDiscord <exe_virus> Well wouldn't pixel fonts also have the scaling and blending issue?
11:54 erlehmann like how would minetest *know* a TTF font is not blurry, trial and error?
11:54 sfan5     hecks: the actual scale factor is dpi/96 so that wouln't do anything
11:54 sfan5     I'm not actually sure what we're talking about now
11:54 erlehmann px vs pt everywhere :D
11:54 hecks     yeah so imagine if the DPI we read from the system was snapped to a multiple of 96
11:54 erlehmann a multiple lol
11:55 erlehmann i bet you get complaints that way
11:55 sfan5     that wouldn't look good but I think some game authors might want this
11:55 hecks     I would want this kind of constraint for my formspecs
11:55 hecks     I'd like to develop them assuming 96 DPI and have a guarantee it'll be an integer multiple of that
11:56 hecks     same for hud really
11:56 sfan5     hud is ... well a mess
11:56 hecks     if the screen gets big enough, the GUI gets scaled 2x or more. that simple
11:56 sfan5     for formspecs an element that toggles integer scaling is possible
11:57 hecks     would be useful
11:57 hecks     well the thing is, I've got HUD to work in the exact same way
11:57 sfan5     you just have to convince v-rob ;)
11:57 hecks     that is; it's fine on 96 and 96 * n
11:57 MTDiscord <exe_virus> Integer scaling makes perfect sense as a toggle option
11:57 hecks     people who use painted or vector graphics and vector fonts do not need this integer scaling at all
11:57 hecks     but pixel art? must have
11:58 hecks     that would also fix issues with font sizes
11:58 hecks     you could use absolute sizes for pixel fonts that you know are valid on 96
12:00 erlehmann i do not know how applicable this is, but in web design, ppl who need absolute pixel things and monitor dpi are usually wrong. the solution that *mostly* works is having stuff work at 12pt, 16pt, 24pt and using constraints to switch between layouts, not absolute specifications.
12:01 erlehmann hecks, sfan5, i'd be happy if my 96x96px game icons would not look mangled anywhere, for start. oh, and pixel fonts ofc. lol
12:01 hecks     I've recently made a HTML page that uses pixel art, in the exact same way I do my formspecs, it renders fine on all devices
12:01 erlehmann bc right now i can't even do a main menu icon that is not mangled, except if it is a single colored squase
12:01 hecks     nothing wrong with absolute sizing as long as you're smart about it
12:02 hecks     things like offsets and margins can vary but the scale of the artwork is sacred
12:02 erlehmann the “as long as you're smart about it” thing is the problem. “most ppl aren't as talented or driven as you” is a thing.
12:02 hecks     if it's not integer, it'll look like crap
12:02 erlehmann mostly true
12:02 MTDiscord <Hugues Ross> yeah, pixel art will pretty much get mangled at any non-integer scale. It's why absolute sizing works particularly well for pixel art even if it's not needed for vectors/highres
12:02 hecks     anyway. somebody please fix inventory and hotbar image scaling
12:03 hecks     there is currently no way to make it look good at ANY dpi
12:03 erlehmann for once i totally agree with hecks
12:03 hecks     i've gotten away with 48x48 items at 96 dpi but either the hotbar or the formspec list is broken (don't remember which)
12:03 hecks     one of them has a really odd scale
12:03 hecks     scaling the hotbar to match invlist is probably the least destructive fix
12:04 hecks     the hotbar skin also behaves weirdly so it would be a good opportunity to fix that
12:04 erlehmann in general, i think the engine should bend over backwards so that mods don't want to know about dpi. the “give us dpi” thing seems to not happen in GUI frameworks that are … uh … easier to use than formspec.
12:04 erlehmann <hecks> scaling the hotbar to match invlist is probably the least destructive fix
12:04 erlehmann that must be tested
12:04 erlehmann not sure if it breaks mcl* mods?
12:05 hecks     it can be a hud flag
12:05 hecks     as long as there is a way to fix it at all, it's fine
12:05 hecks     can be off by default
12:05 erlehmann yeah
12:05 sfan5     is the hotbar a hud element yet or still harcoded
12:05 erlehmann not sure
12:05 hecks     possibly hardcoded
12:06 erlehmann <hecks> you could use absolute sizes for pixel fonts that you know are valid on 96
12:06 sfan5     anyway it would be nice if someone could confirm #11753, doesn't seem to affect the ogles2 driver (that I use)
12:06 ShadowBot https://github.com/minetest/minetest/issues/11753 -- Images in formspecs use "smooth" linear instead of nearest neighbor filtering
12:06 erlehmann hecks, most pixel fonts are just given as-is
12:06 hecks     regarding DPI and game dev expectations; in Unity, you build GUIs against a reference resolution that you pick yourself
12:06 hecks     for instance, you use 1280x720 as your virtual "screen" and arrange your elements and anchors in those units
12:06 erlehmann i have no idea what unity would even compile on my machine, isn't it something ultra new?
12:06 hecks     this is more or less how I've been working in MT too
12:07 erlehmann > use 1280x720 as your virtual "screen" and arrange your elements and anchors in those units
12:07 erlehmann how to address mobile?
12:07 erlehmann also, 1400x1050 here, how would it be scaled?
12:07 sfan5     most games do not run on mobile and desktop at the same time
12:07 hecks     anchors handle screen aspect ratios
12:07 hecks     you'd probably have elements anchored to various corners
12:08 hecks     and maintain some headroom to allow the screen to scale
12:08 erlehmann well, i know how that breaks down in web design.
12:08 erlehmann i have done it too, you need a minimum size to enforce
12:08 hecks     anyway, I've had success just assuming 1280x720 for mibi's formspecs
12:08 erlehmann or the elements mash into each other at small sizes
12:08 MTDiscord <Hugues Ross> I don't see a problem enforcing a minimum resolution in a game
12:09 erlehmann hecks, what's your showcase game/mod anyway? i wanna test it
12:09 hecks     if I just had a thing which will bump it to 2x and 4x on 1080p and 4K screens respectively, I'd be happy with that
12:09 hecks     you don't get to test it yet
12:09 hecks     but I can show you the GUI I guess
12:09 erlehmann uh ok
12:09 erlehmann yeah i just wanna check it out on different screen sizes
12:09 erlehmann to see how well it performs when i poke it
12:10 erlehmann bc arguably “reduce resolution” is the only thing i know to improve performance if everything else fails
12:10 erlehmann (not that i need to rn)
12:11 hecks     at the moment my gui only looks good at 96 and its multiples
12:11 erlehmann anyways, hecks, if you are interested in improving the wireshark dissector, i'm with you
12:12 erlehmann hecks do you have experience with network fuzzing, afl-style? bc i do not
12:12 sfan5     what about it?
12:12 hecks     not really, I'm just encouraging people to try and exploit MT with spoofed packets to find bugs.
12:12 hecks     me neither but someone should probably do some fuzzing =]
12:12 erlehmann hecks, try running mt with ubsan, asan or tsan and weep ;)
12:13 erlehmann (asan is dog slow though)
12:13 erlehmann hecks do you know about the thing where you are connected but not really and you can already see chat btw?
12:14 erlehmann like, a player can see chat from before they spawned
12:14 sfan5     is that a hyptothetical or did you test it? if so, why not go an open a bug
12:14 hecks     I suppose the server doesn't check whether someone has completed the whole login process?
12:14 erlehmann i was told it is possible to stay in that state
12:14 erlehmann but i haven't gotten any code that can do it
12:15 erlehmann to surveil server chat
12:15 hecks     that sounds easy to try, just comment out parts of the login process
12:15 erlehmann sfan5 you can easily test it by throttling your connection and joining a chatty server like catlandia
12:15 hecks     oh right, you could just block up packets, but I guess you'll get timed out eventually
12:15 hecks     maybe the server should time you out if you do not complete the login process within a few seconds
12:16 erlehmann hi Fleckenstein
12:16 erlehmann hecks, uh no. don.t do it. i am on 2g (3g got shut down).
12:16 erlehmann i need a new mobile dongle
12:16 erlehmann minetest is surprisingly well playable on low bandwith once you have dl'd the assets
12:16 hecks     it's kinda annoying that someone can join a server in ghost mode like this but the admin can still see you connecting
12:17 hecks     as for bandwidth - depends on the mods
12:17 hecks     nodes work well but objectrefs are extremely wasteful
12:17 hecks     games and mods that manipulate objects a lot will kill your connection
12:17 erlehmann hecks, see, “maybe we should do a thing that might break your personal setup” is the reason why i'd like to present bugs with a fix attached
12:17 hecks     I meant commenting things out on your own build of the client, obviously
12:18 hecks     for testing
12:18 erlehmann oh ok
12:18 hecks     did you think I'm about to commit that to master ,ó
12:18 erlehmann hecks i have a lot of experience in debugging wasteful network traffic. it was one of the reasons that mineclonia split from mcl2. i think ppl like Fleckenstein just have cool gamer rigs and fast internet, so it is hard for them to even reproduce half of the stuff.
12:19 erlehmann hecks let's say i am a bit biased bc of your past behaviour ^^
12:19 erlehmann but i get it, you try to not break stuff on purpose here!
12:20 erlehmann btw, i am of the opinion that devs should always try to have worse constraints than users so that stuff runs smothly. e.g. when i was programming audio synthesizer stuff, i'd use a machine older than my users to make it likely that i encounter performance problems during development, and they do not.
12:21 erlehmann if i had a software team to manage, they'd all get underpowered netbooks and a throttled 3g connection and get told to make it work ;d
12:21 erlehmann ;D
12:21 erlehmann that's not the main reason i have older hardware though
12:22 hecks     well, that stale channel decoupling PR was the result of trying to run a server with 1 mbps upload
12:22 erlehmann (before someone thinks that)
12:22 hecks     so there's something to that
12:22 hecks     but that still doesn't resolve the object properties bottleneck
12:23 hecks     if you want to help network issues and have lots of machines and time to waste, please please test #10699
12:23 erlehmann regarding improving traffic, one of the easiest things would be to silently, or with a warning, not set properties again if they already have that value.
12:23 ShadowBot https://github.com/minetest/minetest/issues/10699 -- Break up the message queue by category by hecktest
12:23 hecks     this PR was basically done but it needs testing for crazy edge cases
12:23 erlehmann there are so many mods setting stuff way too often
12:23 hecks     we shouldn't warn, we should CACHE properties
12:23 erlehmann to me, every edge case is just … a case.
12:23 hecks     and only send what changed, not the whole thing
12:24 erlehmann hecks it should warn bc at least with mcl2 that object setting was usually indicative of doing wasteful recalculations in a global step.
12:24 erlehmann it still is
12:25 hecks     that sounds a little pedantic
12:25 hecks     sometimes you do need to do recalculations and set a property every frame
12:25 hecks     there is really no reason for the engine not to just auto optimize this
12:26 erlehmann look, in the *vast* majority of cases i have seen, it was useless busywork. and it rears its ugly head when typical servers have less resources than dev machines.
12:26 sfan5     if a property needs to be set every frame that'd be a prime usecase for a CSM
12:27 hecks     not if the property is gameplay significant like a collider's dimensions
12:27 erlehmann hecks, if you are interested – just compare the traffic of idling in mineclone2 0.71 to the mineclonia branch “cora-production” (that is what runs on oysterity) and then we can talk in-depth about it
12:27 hecks     it's also a prime usecase for shaders if it's a purely visual thing =]
12:27 sfan5     true
12:28 erlehmann as always, benchmarking object updates is important
12:29 erlehmann for mineclonia, for example, it turned out that being able to be on fire multiple times was much more influential than updating the fire texture (which still happened too often)
12:29 erlehmann but endermen updates are horrible
12:29 hecks     because it's more objects?
12:29 hecks     i'm pretty sure someone told me that updating ANY property on an objects sends all of them
12:30 hecks     and if true, that's the highest bottleneck
12:30 erlehmann yeah, cora got up to 100kbps setting herself on fire with the /burn command i added. i verified it, but stopped at 500k
12:30 erlehmann uh, typo, cora got to 1000kpbs
12:30 hecks     it's not hard to optimize this
12:31 erlehmann by which i want to say, you can lag out other players by setting them on fire. hilarious, isn't it?
12:31 erlehmann oh, none of the optimizations were hard
12:31 hecks     for each client, maintain a hashmap of player to entity that contains the known property set for that client
12:31 erlehmann it's just that the simplest thing that works in singleplayer breaks down if you have 20 players
12:31 hecks     use that to determine what actually must be sent
12:31 hecks     it would cost a bit of ram but not a whole lot
12:31 erlehmann that's why i think there should be a warning if sth is set to the value it already has
12:32 hecks     no, you see
12:32 erlehmann i bet Fleckenstein can chime in on this. Fleckenstein if the engine warned, would you have cached more obj property setting?
12:32 hecks     a check for that in lua might be slower than an engine side check
12:32 sfan5     so far it all seems to be tales of MCL's awful code
12:32 hecks     additionally in luajit, branches can mess with JIT trace generation
12:33 hecks     and often it's just less code when you don't check something
12:33 hecks     and CPUs tend to like predictable code
12:33 hecks     and smaller code
12:33 hecks     so it's not such a clear cut thing
12:33 erlehmann sfan5 you can of course say that mod authors are behaving in a stupid manner, but i think that letting them, without any benefit to anything, is the problem.
12:33 sfan5     I bet not sending updates on redundant set_properties calls would do more than splitting up the packet to re-send only individual properties
12:33 hecks     then, emitting such a warning would be a very annoying thing when you know what you're doing
12:33 erlehmann look, just *measure* it
12:33 erlehmann we measure all of our stuff
12:34 erlehmann at mineclonia
12:34 hecks     I mean, figuring out the delta of the properties would automatically handle the duplicate thing
12:34 hecks     as it would generate an empty delta
12:34 erlehmann “we had massive server lag before checking if redundant stuff is sent” is kinda proof of that it works. it could work better.
12:34 hecks     but I would not yell at the player unless logging was set to verbose
12:34 hecks     I mean, at the server admin
12:34 erlehmann no, yell at the dev. so verbose logging is fine.
12:34 sfan5     nobody ever looks at the verbose log
12:35 erlehmann i have written a script to fish out average packet count from the verbose log and postprocess it, others are using it too
12:35 hecks     sadly even if it's an option, you have at least one more jz instruction for every set_property call sent to any player
12:35 erlehmann admins of crashy servers look at the thing
12:35 hecks     and more code in icache
12:35 hecks     are you sure it's worth it to prevent people from doing stupid things they should know better than to do
12:35 erlehmann yes
12:35 hecks     not to mention there are legitimate reasons to just set the duplicate property
12:35 hecks     just to keep things simple
12:35 erlehmann i'd bet cold hard cash on it
12:36 erlehmann hecks, worrying about engine checks being CPU-bound sounds like premature optimization. the clients network is the bottleneck!
12:36 erlehmann besides, i am writing you from: Intel(R) Core(TM) Duo CPU      T2400  @ 1.83GHz
12:37 erlehmann surely you can see if the lua check is good enough for me, the c check will be even better
12:37 hecks     we would optimize the network automatically in this case
12:37 hecks     doing the best possible thing without the user having to care about it
12:37 erlehmann yes
12:37 erlehmann i want this
12:37 hecks     given that the engine already would do the best possible thing
12:37 hecks     what's the point of warning the user?
12:37 erlehmann if it is fully backwards compatible
12:37 erlehmann the point is that i have seen a bunch of stuff, not only in mcl2, where the mod code recalculates the value before it is sent out
12:38 hecks     it should be, I mean, hopefully not a single property executes any important side effect on a duplicate assignment
12:38 erlehmann which also creates server load
12:38 hecks     this sounds like mcl problems
12:38 erlehmann hopefully lol
12:38 sfan5     modders writing dumb code is a law of nature
12:39 erlehmann hecks you can talk to Fleckenstein about the merits of spamming properties in a global step. but even though the code is stupid, Fleckenstein is not. he did the simplest thing that worked and it works fine … locally. or with a big rig.
12:39 erlehmann i think it is the responsibility of the engine to warn here, so ppl are aware of it
12:39 hecks     the MT implementation of properties is stupid, it's nobody's fault
12:39 erlehmann look, you warn about other stuff too, like tha texture alpha thing
12:40 hecks     I've talked to people who got upwards of 10 Mb/s per client from entities
12:40 erlehmann and modders fix it
12:40 sfan5     I half agree with hecks here, the engine cannot do code review for you
12:40 hecks     it's sometimes okay to warn the user about things but this isn't one of those cases
12:40 erlehmann no, but if the engine is doing a workaround, ppl *should* be made aware of it
12:40 sfan5     on the other hand updating a single property to be the same it already was is usually stupid
12:40 hecks     it's too arbitrary
12:40 sfan5     same with HUD elements
12:40 erlehmann it's stupid, but it is by far the most common cause of lag i have seen
12:40 erlehmann haha the HUD element thing was in minetest game too, right?
12:40 hecks     I can see myself just intentionally allowing a duplicate property set once in a while and I don't want that polluting my logs or eating CPU time
12:41 erlehmann not sure actually
12:41 erlehmann i have to look
12:41 hecks     we don't delta HUD either?
12:41 hecks     sounds like solving one would help with the other
12:41 erlehmann hecks, just look at mineclonia performance fixes and how much traffic it saves, it can short cut the whole conversation
12:41 hecks     HUD is easier because there's only one HUD per client
12:41 erlehmann other mods have similar problems
12:42 hecks     and no extra hashmap is needed
12:42 sfan5     you don't need that hashmap for entities either
12:42 sfan5     if a client knows about an entity its info will be up-to-date
12:42 hecks     shouldn't it be per player per entity?
12:43 erlehmann i don't care about the implementation, i just think that if a bunch of modders write code that performs and it can be fixed automatically and warned about, it should be done. well-tested obv.
12:43 sfan5     maybe I'm missing something but I can't think of why that would ever desync
12:43 erlehmann performs badly, i mean
12:43 hecks     hmm
12:43 erlehmann sfan5 stepping in and out of range?
12:43 hecks     with the hashmap, it might be possible to, yeah what he said
12:44 hecks     not forget the whole delta at the edge of the line of sight, but wait a bit before deleting the map entry
12:44 hecks     although
12:44 hecks     client side, entities don't get "unloaded", it's a delete packet
12:44 sfan5     if the server decides you're too far you get a "this entity disappeared" packet
12:44 hecks     so maybe that's moot
12:44 erlehmann hmmm
12:44 hecks     it's literally the same packet as a removal
12:45 hecks     and when it comes back into view, it's as if it were just spawned
12:45 erlehmann well, now that you are aware of it being a problem, i'm interested in what you come up with. i hope there are no desyncs possible.
12:45 hecks     I guess it wouldn't be hard to add a map to it if a shared delta set doesn't work for some reason
12:45 erlehmann mcl2 0.71 is probably the best test case, as mcl2 >0.71 already merged stuff from mineclonia
12:45 hecks     I don't feel smart enough today to figure this out
12:46 sfan5     if anyone wants to write code the HUD thing should be fixed first, everything needed is already there on the server it just doesn't skip sending
12:46 hecks     hud network deltas?
12:46 hecks     ah so it already has a cache, just doesn't use it
12:46 sfan5     hud packets already only set individual properties
12:46 erlehmann i think delta thing is overengineered tbh
12:46 sfan5     and the server knows the values of them
12:46 hecks     uh, pardon?
12:47 hecks     it needs not be a binary delta, I just mean delta as in "send what changed"
12:47 erlehmann ah ok
12:47 hecks     but honestly a binary delta of the state sounds like a clean solution, if the state is easily expressed as a binary buffer
12:47 hecks     and sent as such
12:47 erlehmann hecks, in that case i hereby eat my words
12:48 sfan5     that sounds like one of those smart solutions that will bite you in the ass in the long run but I can't think of anything yet
12:48 sfan5     ¯\_(ツ)_/¯
12:48 hecks     there is a third area where this sort of thing could be done
12:48 hecks     and that is formspecs
12:48 hecks     why are we resending a whole formspecs to change one element again?
12:48 erlehmann “that sounds like one of those smart solutions that will bite you in the ass in the long run but I can't think of anything yet” is exactly the feeling i have when ppl ask me for “how would this even break” most of the time
12:48 hecks     why not just send something like a text diff from the already opened form
12:48 erlehmann uh oh
12:49 sfan5     the client can throw away the opened formspecs at any time when the user presses Esc
12:49 erlehmann yeah, or automatically, even without esc
12:49 hecks     form sends are reliable packets, yes?
12:49 sfan5     if/when formspecs are rewritten it'd be better (okay not sure actually) to make them stateful
12:49 erlehmann (think CSM provided forms)
12:49 sfan5     yes
12:49 hecks     I mean closing the form with esc is not a problem if the client still remembers what the last opened form was
12:50 sfan5     it is also possible to open an entirely different form in a split second without server involvement or CSM
12:50 hecks     and since the client only maintains one immediate and one inventory formspec at any given time
12:50 hecks     I don't see a reason why this wouldn't work out of the box
12:50 hecks     even without checking the form ID
12:50 sfan5     thought better question: if you send a diff for an old formspecs and it's already closed, does it matter?
12:50 hecks     because honestly, it would even optimize similar forms
12:50 sfan5     though*
12:51 hecks     whichever show_formspec form was last, and whichever inventory formspec was last should be consistent state already
12:51 erlehmann look, if you want to optimize formspecs i have a MUCH better idea for you
12:51 hecks     shouldn't be much trouble for the client to just hold on to those two strings and only receive diffs over them
12:51 erlehmann actually it is one coming from wuzzy
12:52 erlehmann static formspecs for nodes
12:52 hecks     isn't that already a thing
12:52 sfan5     that is already on my todo list
12:52 hecks     in metadata
12:52 erlehmann it can reduce perceived lag by A LOT
12:52 sfan5     hecks: only if you put them in meta
12:52 erlehmann sfan5, goood thx
12:52 hecks     oh, you want them per CID
12:52 sfan5     erlehmann: I also already told you that it is on my todo list
12:52 hecks     that sounds useful
12:52 erlehmann sfan5, i forgot
12:52 erlehmann tbh
12:53 hecks     however, updating the per CID form could still use a diff =]
12:53 hecks     no conflict here
12:53 erlehmann oh you
12:53 erlehmann honestly, doubt it makes make sense to diff formspecs. all the formspec performance problems i am aware of are latency / prediction things.
12:53 hecks     I like the diff thing because it requires no changes to anything
12:53 erlehmann i am not aware of everything though
12:53 hecks     really.
12:53 hecks     erlehmann
12:54 hecks     have you tried having a real time clock in a player's inventory
12:54 erlehmann then the remaining thing is “is it backwards compatible”
12:54 hecks     or any kind of dynamic display
12:54 erlehmann realtime compass lol
12:54 erlehmann horrible
12:54 hecks     are you aware that the server knows nothing about what a player is doing with their inventory formspec
12:54 hecks     and if you want to have an RTC, you basically have to send the player their whole inv form every 10 seconds
12:54 hecks     and yeah, any time the form is dynamic in any way
12:55 hecks     you're sending the whole thing for every small change
12:55 hecks     of *course* it needs diffs
12:55 erlehmann in that case, look at the proxy anon5 build
12:55 erlehmann i believe it was made for the use case of “my whole inventory is shulkers of shulkers and their meta is HUGE”
12:55 erlehmann built
12:55 hecks     that doesn't solve anything
12:55 hecks     regarding forms
12:56 erlehmann na, but it helps to dissect the problem better than wireshark ig
12:56 hecks     you could catch entirely duplicate forms with a packet shark but
12:56 hecks     I don't need to inspect packets to know what the problem is here ,ó
12:56 erlehmann ok
12:57 erlehmann well i often try to measure to figure out if my intuition was wrong. especially if i am *really* sure. but i think you might be right, the RTC case seems bad enough.
12:57 erlehmann although i think an RTC should maybe be a CSM actually
12:58 erlehmann well, regardless
12:58 erlehmann hecks, if you feel like telling me next time you play with packets, pls do. i am interested.
12:58 hecks     probably not any soon, sorry
12:58 erlehmann oh ok
13:00 hecks     too busy with graphics, although denial of service and exploitation with crafted packets is a pretty serious thing
13:00 erlehmann do you fuzz your graphics stuff btw?
13:00 erlehmann if you have proper unit tests i can try to marry them to afl-fuzz
13:00 erlehmann it's not that hard *if* you have tests
13:00 hecks     no reason to
13:01 erlehmann uh, aren't … crashes … a reason?
13:01 hecks     we might want to do this if server sent shaders were on the menu
13:01 hecks     to test any sanitizer we might be using to, well, sanitize the shaders
13:02 hecks     but at the moment, fuzzing OpenGL would only reveal graphics vendor bugs, not ours
13:02 erlehmann sanitizing *usually* is bullshit, no idea why it could work on shaders though
13:02 erlehmann also, the server can already send all kinds of crap to clients to crash them if it wants
13:02 erlehmann like, if you hate your users lol
13:02 hecks     the idea of sanitizing shaders is to prevent more trivial exploits on the shader compiler such as absurdly long identifiers leading to overflows because some guy hardcoded the buffer for that to [256]
13:02 erlehmann ah ok
13:02 kilbith   it seems like we have two cretins on the channel
13:03 hecks     :o
13:03 kilbith   I'm reading the logs muthafucka
13:03 hecks     I'm staying out of this...
13:03 hecks     weren't you sleeping or something
13:03 erlehmann kilbith it seems, talent or not, that you are more arrogant than everyone here. if hecks and i can get along, you can too. just try.
13:03 kilbith   doesn't matter
13:03 erlehmann and stop writing “i am better than all of you” or talking about france lol
13:04 erlehmann hecks, i just got an idea. i think i should make some kind of thing that instead of kicking griefers who try to crash the server, also kicks the offender by means of a client crash.
13:04 erlehmann that way they will do the bug fixing for me
13:05 erlehmann :D
13:05 hecks     i am willing to put up with a little sass if there's quality code behind it. this statement is my personal opinion and does not reflect any official policy of the minetest developers.
13:05 hecks     if my code (code itself) is trash i'll be glad to hear why
13:06 hecks     as long as whoever is saying it has a clue what they're talking about
13:06 erlehmann i think it's pretty important to focus on the code too.
13:06 erlehmann instead of calling each other names
13:07 erlehmann so about the dpi thing, can i have my pixel fonts back for the time being until you figure out how to bend freetype to your will? i promise to do sth useful with it.
13:07 hecks     I don't think I touched anything to do with fonts?
13:07 hecks     correct me if I'm wrong
13:08 hecks     did I accidentally mop up some obscure irrlicht bitmap font feature
13:08 hecks     (pretty sure I didn't because DIB was left in just so those still compile)
13:08 erlehmann no, sfan5 did and has a PR for fixing it. the question was not for you.
13:08 hecks     ah.
13:08 sfan5     well I wanted to hear hecks opinion on it
13:08 erlehmann sorry, i should have made that clear
13:08 hecks     I honestly think there is no difference between a badly scaled TTF pixel font and a badly scaled bitmap pixel font
13:08 hecks     both will look equally trash
13:09 sfan5     bitmap fonts don't get scaled
13:09 erlehmann the thing is that the pixel fonts *aren't* scaled
13:09 sfan5     that's the thing
13:09 erlehmann that is why they are crisp
13:09 hecks     *at all*?
13:09 sfan5     Minetest picks from the sizes the font author shipped
13:09 erlehmann yep, that is why it works
13:09 hecks     well, it "works" if they don't scale for integer multiple DPIs
13:09 hecks     the text itself probably looks fine, but the alignment is still shot
13:09 sfan5     nobody has ever used it for this purpose though, it's missing coloring, bold and italic and was also broken for several years
13:10 sfan5     but technically it works for pixel fonmts
13:10 sfan5     fonts*
13:10 hecks     our time is probably better spent implementing integer scaling
13:10 hecks     since this seems like it hasn't ever worked correctly in the first plaace
13:10 hecks     let me guess that this is another thing that only MCL uses
13:10 erlehmann the missing coloring is a feature imo. i have made about >500 unifont glyphs that are all black and white, *solely* so i could have a font in which emoji are not colored. also i absolutely hate the ppl spamming rainbow text with their hack clients.
13:10 erlehmann hecks, no, games can't use it
13:10 hecks     if so, deprecate and keep until 6.0 but axe it after
13:11 hecks     if games couldn't ever use those fonts then axe them
13:11 erlehmann that way you remove “crisp pixel fonts”
13:11 sfan5     that's what makes it even more funny
13:11 hecks     I have crisp pixel fonts with TTF
13:11 sfan5     the only way someone could have used is is by individual choice from users
13:11 sfan5     yet nobody ever did
13:11 erlehmann “it only breaks for ppl who actually rely on the feature”
13:11 hecks     I've tested: Press Start, Perfect DOS and Terminus in MT, all ttf versions
13:11 hecks     they work
13:12 hecks     I use terminus as the console font
13:12 erlehmann hecks, bc your dpi is close enough to 96 probably
13:12 hecks     my dpi *is* 96
13:12 sfan5     erlehmann: if you rely on this feature show me the .png + .xml pixel font you use with MT
13:12 sfan5     you have 30 seconds
13:12 erlehmann sfan5 the builtin one
13:12 sfan5     not a pixel font, rejected
13:12 hecks     but this just keeps sounding like the whole DPI system was a mistake
13:12 erlehmann uh, i don't get rainbow spam?
13:12 hecks     and integer constraining it would fix everything
13:12 hecks     he probably means the irrlicht builtin
13:12 erlehmann yeah i think it *can* be fixed
13:13 erlehmann without retaining the PNG fonts
13:13 hecks     I'd axe it if I could be bothered to figure out exactly how
13:13 MTDiscord <josiah_wi> wb hecks
13:13 hecks     I left in "silent" DIB support in the meantime to let it compile
13:13 hecks     hi
13:13 sfan5     better question is what are we discussing this for
13:13 sfan5     game authors can't ship fonts
13:13 hecks     (do NOT start relying on DIBs for anything or I'll find a way to axe it out of spite)
13:13 erlehmann i think it can be axed once the DPI mess is worked out so that it doesn't degrade user experience
13:13 erlehmann DIBs?
13:13 sfan5     the current usecase for interger scaling is formspec design
13:14 hecks     forget I said anything
13:14 hecks     ;]
13:14 hecks     pardon me but
13:14 hecks     we don't have server sent TTFs yet right?
13:15 hecks     the font and its size is actually all picked by the client anyway
13:15 sfan5     indeed
13:15 hecks     so what's stopping a poor oppressed 72 DPI user from just correcting his pixel font size
13:15 sfan5     like I said integer scaling would help you design guis
13:15 hecks     integer scaling would help anyway
13:15 hecks     I can design guis just fine, they just look like trash if it's not divisible by 96
13:16 sfan5     nothing, we infact have a new setting that makes it easy to correct the dpi
13:16 erlehmann look, i think a button “render 1pt font as 1px font” + a scaling thing could solve this as well
13:16 erlehmann the problem is that this doesn't exist ig?
13:16 hecks     1pt as 1px is equivalent to 96 dpi
13:16 hecks     72 dpi seems like a mistake anyway
13:17 hecks     a mode for forms that renders them at the closest multiple of 96, that's all I want for christmas ,ó
13:17 erlehmann come on its absurdly rare that ppl have a dpi that is exactly a single value
13:17 hecks     96 is literally the most common dpi on computer monitors
13:18 hecks     and that's also the dpi setting where our engine treats 1pt as 1px
13:18 hecks     it makes perfect sense to just make that the assumed 1x
13:18 hecks     because that's when everything is pixel perfect
13:21 erlehmann well i just tried on 2 machines one has 96, one has 90 (which still works btw)
13:22 erlehmann hecks 72 dpi is apple default or what, while 96 is windows?
13:24 erlehmann sfan5 hecks btw, what do to with pixel fonts in your free time if you like riddles http://news.dieweltistgarnichtso.net/bin/plainpbm2nonogram-sh.html
13:25 erlehmann and yes, this does not parse all valid PBMs
13:26 hecks     i do not have free time
13:26 erlehmann oh ok
14:15 MTDiscord <josiah_wi> I fixed that compiler error with GCC4.9. Using auto to determine a type is a little bit dangerous, because you may not realize you're passing a raw pointer to a constructor that wants a unique_ptr.
14:15 MTDiscord <josiah_wi> Names will go unmentioned to protect the inoccent. xD
14:16 MTDiscord <josiah_wi> mostly innocont*
14:16 MTDiscord <josiah_wi> inoccent*
14:17 MTDiscord <josiah_wi> I'm very curious why this doesn't fail on newer versions of the compiler.
14:41 MTDiscord <josiah_wi> Use of a deleted ostringstream operator. I will need to consult about this one.
14:45 MTDiscord <josiah_wi> hecks, png.cpp line 40, basic_ostringstream(const std::basic_ostringstream&) constructor was implicitly deleted because the default definition would be ill-formed (says GCC).
14:46 MTDiscord <josiah_wi> (src/utils/png.cpp)
14:51 sfan5     copy elision should take care of that
14:52 sfan5     if you want it fixed just swap "auto name_here = std::ostringstream(std::ios::binary);" for "std::ostringstream name_here(std::ios::binary);"
14:53 erlehmann hey hecks i just triggered a new (?) heap butter overflow on the client. do you want to go with me through how to possibly turn into something other than a crash?
14:53 erlehmann i'd really like to learn that
14:53 erlehmann josiah_wi wow cool
15:09 hecks     I mean if the overflow can be fixed, it's probably not important to determine how it can be exploited
15:09 hecks     it should be fixed either way
15:10 hecks     I hope you are doing all this in a debugger and can tell us where it crashes and what exactly corrupts the memory
16:37 erlehmann hecks it is more that i want to practice exploitation
16:40 MTDiscord <josiah_wi> Thank you sfan5, that fixed the error wonderfully.
16:40 MTDiscord <josiah_wi> Every error it gets worse: "#error Minetest cannot be built without exceptions or RTTI"
16:41 hecks     ah, understood
16:42 sfan5     well don't disable exceptions or rtti
16:43 MTDiscord <josiah_wi> Haha, I hope I can earn your confidence that I would not do something like that.
16:45 MTDiscord <josiah_wi> I will investigate the circumstances triggering the error, in case it is a false alarm.
16:56 MTDiscord <josiah_wi> There is nothing wrong with the rtti/exception detection, and I am finding it difficult to figure out whether gcc4.9 supports rtti and exceptions or not.
17:00 sfan5     of course it does
17:01 MTDiscord <josiah_wi> I mean, it definitely ought to. And according to stack overflow RTTI is always enabled by default in GCC. I found a flag to explicitly enable exceptions, and I'm testing that, but I have no clue what is up with the RTTI.
17:03 sfan5     you can try -frtti and -fexceptions but that should not be neeeded
17:03 sfan5     btw make VERBOSE=1 shows the commands it is invoke
17:20 MTDiscord <josiah_wi> The Ninja build generator shows the command that was executed any time there is a build failure.
17:21 MTDiscord <josiah_wi> I love it.
17:21 MTDiscord <josiah_wi> Ninja build system*
18:02 MTDiscord <josiah_wi> sfan5, it appears the __cpp_rtti and __cpp_exception macros are not implemented in GCC4.9, despite RTTI and Exceptions being enabled.
18:04 MTDiscord <josiah_wi> __cpp_exceptions*
18:12 sfan5     that sounds wrong and contrary to the C++ standard
18:12 sfan5     which OS / distro are you testing on?
18:56 MTDiscord <josiah_wi> Linux, Alt Linux Starter Kit. I installed gcc4.9 and g++4.9 from their repository.
18:56 MTDiscord <josiah_wi> I found a case on stack overflow of GCC not implementing a macro for whether elision is guaranteed, so it is possible. It is also possible something is configured incorrectly.
19:00 MTDiscord <josiah_wi> I confirmed that neither macro is defined by splitting it into two separate checks, and the verbose output shows that -std=gnu++11 is set. There are no flags set disabling rtti and exceptions, so they are almost certainly enabled.
19:02 MTDiscord <josiah_wi> Both macros are part of the standard since before C++11, according to cppreference.com.
19:03 sfan5     I tried to look for them in the standard PDFs so maybe they're actually not
19:04 sfan5     +and didn't find anything
19:04 MTDiscord <josiah_wi> Was GCC4.9 picked as the minimum version arbitrarily? Did Minetest ever compile on it? lol.
19:05 sfan5     the minimum versions were picked according to what worked, obviously
19:07 MTDiscord <josiah_wi> I was thinking finding the PR that added the macro checks would be useful, to understand the discussion that went on then and how that would affect deciding how to go forward.
19:08 sfan5     ha
19:08 sfan5     you'd be disappointed, there was no discussion
19:09 MTDiscord <josiah_wi> It's a single commit, "Add preprocessor check for weird (incorrect) build configurations"
19:09 MTDiscord <josiah_wi> Going by this, I should probably be doubly sure my build configuration is not "weird (incorrect)"
19:10 MTDiscord <josiah_wi> You authored this commit, do you have any recollection of what this improper configuration was? The check replaced a Irrlicht version check that noted Irrlicht 1.8.2 is known to be broken.
19:10 MTDiscord <josiah_wi> Would my Irrlicht configuration have any possibility of breaking my Minetest configuration?
19:11 sfan5     unless you accidentally build Minetest with the same flags as Irrlicht, which has -fno-exceptions -fno-rtti: no
19:12 MTDiscord <josiah_wi> Well, then, what would you like me to do? This probably is not high priority, so if it is a difficult question there is probably no rush to answer it right away.
19:36 MTDiscord <josiah_wi> With the rtti/exceptions check commented out, the client compiles and devtest is running as smoothly as can be expected on my computer.
23:27 MTDiscord <josiah_wi> minetestserver also compiles fine.