IRC log for #minetest-dev, 2021-11-16

Time	Nick	Message
00:44		AliasAlreadyTake joined #minetest-dev
01:05		olliy joined #minetest-dev
01:13		erlehmann joined #minetest-dev
01:26		kilbith joined #minetest-dev
03:28		queria^clone joined #minetest-dev
03:33		queria^clone joined #minetest-dev
05:00		MTDiscord joined #minetest-dev
05:50		v-rob joined #minetest-dev
08:52		MTDiscord joined #minetest-dev
08:55		kilbith joined #minetest-dev
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 joined #minetest-dev
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:03		kilbith joined #minetest-dev
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:31		hecks joined #minetest-dev
10:33	hecks	Slowly getting back to the shader thing, did I miss anything important?
10:33		kilbith joined #minetest-dev
10:35		tekakutli joined #minetest-dev
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		proller joined #minetest-dev
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:04		proller joined #minetest-dev
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		calcul0n__ joined #minetest-dev
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		Fleckenstein joined #minetest-dev
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:24		tech_exorcist joined #minetest-dev
12:25	hecks	that sounds a little pedantic
12:25		tech_exorcist joined #minetest-dev
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		proller joined #minetest-dev
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		kilbith joined #minetest-dev
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:23		calcul0n__ joined #minetest-dev
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:49		tekakutli joined #minetest-dev
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
14:58		tech_exorcist joined #minetest-dev
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
15:25		Fixer joined #minetest-dev
15:56		Extex joined #minetest-dev
15:57		tech_exorcist joined #minetest-dev
16:01		hecks joined #minetest-dev
16:11		m42uko joined #minetest-dev
16:30		appguru joined #minetest-dev
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:46		Extex joined #minetest-dev
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*
17:51		tech_exorcist joined #minetest-dev
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:10		fluxionary joined #minetest-dev
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		proller joined #minetest-dev
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:11		kilbith joined #minetest-dev
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.
20:05		proller joined #minetest-dev
21:06		kilbith joined #minetest-dev
23:27	MTDiscord	<josiah_wi> minetestserver also compiles fine.
23:47		proller joined #minetest-dev

← Previous day | Channels | #minetest-dev index | Today | Next day → | Google Search | Plaintext