| Time |
Nick |
Message |
| 00:07 |
|
proller joined #minetest-dev |
| 00:07 |
MTDiscord |
<Bastrabun> Not that it hasn't been requested and shot down already multiple times |
| 00:10 |
MTDiscord |
<Bastrabun> But if, I'd love to see it happen ? |
| 00:21 |
v-rob |
To actually make sending the screen size useful, you'd also have to know about font dimensions, really, which is difficult from a technical standpoint |
| 00:22 |
v-rob |
I can see DPI and aspect ratio being useful without anything else, but screen size really needs font dimensions to be useful |
| 00:23 |
MTDiscord |
<josiah_wi> Barging in to let you all know, I'm still looking for a second approval on my IRRLICHTMT_BUILD_DIR PR. Barging back out. |
| 00:23 |
MTDiscord |
<Jonathon> you should link it |
| 00:23 |
|
proller joined #minetest-dev |
| 00:24 |
MTDiscord |
<josiah_wi> #11656 |
| 00:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/11656 -- Add variable to use existing IrrlichtMt build by JosiahWI |
| 00:26 |
v-rob |
It wouldn't be very nice to expose that info anyway because it would be expecting modders to take into account screen size, DPI, GUI scaling factor, and font dimensions. |
| 00:26 |
v-rob |
I guess DPI + GUI scaling could be abstracted into some sort of abstract pixel, but that'd probably make people unhappy still. |
| 00:27 |
MTDiscord |
<Jordach> no |
| 00:27 |
MTDiscord |
<Jordach> just give us the full information |
| 00:28 |
MTDiscord |
<Jordach> we can already do lots with screen percentages |
| 00:28 |
MTDiscord |
<Jordach> knowing exactly the size of the screen would allow us to provide properly shaped formspecs for even stranger devices |
| 00:28 |
MTDiscord |
<Jordach> let mods actually handle the problem rather than shoehorning a completely fucking terrible solution to the problem |
| 00:28 |
MTDiscord |
<Jordach> are you developing a game or game engine |
| 00:29 |
MTDiscord |
<GreenXenith> >expecting modders to take into account screen size, DPI, GUI scaling factor, and font dimensions |
| 00:29 |
MTDiscord |
<GreenXenith> that is literally what modders want |
| 00:30 |
MTDiscord |
<Jonathon> ^ |
| 00:30 |
MTDiscord |
<Jordach> or better yet, we could build fully working games with the HUD API given the screen information |
| 00:30 |
MTDiscord |
<Jordach> see https://content.minetest.net/packages/luk3yx/prang/ for more details |
| 00:32 |
MTDiscord |
<Jordach> hell how can we even dare call minetest a game engine let alone it lacks the usual facilities to even create the most minimal of 2D or even 3D games |
| 00:36 |
MTDiscord |
<Jordach> hell why are we even debating the need of this |
| 00:36 |
MTDiscord |
<Jordach> browsers send it without question to relative javascript APIs and there's no issue there |
| 00:37 |
MTDiscord |
<Jordach> but god forbid it makes lives easier for mod/game devs |
| 00:37 |
v-rob |
But browsers mainly use CSS for layouting. |
| 00:37 |
MTDiscord |
<Jordach> get a load of web 1.0 over here |
| 00:40 |
v-rob |
To actually make it easy for game devs, we'd have sizers built into the GUI. I feel split because the right way to do it is to make sizers actually built into the GUI, but formspecs have no such thing. However, I don't want modders being forced to do manual absolute positioning calculations be the norm. |
| 00:42 |
v-rob |
In other words, I don't want to set the workarounds in concrete and make them the solution |
| 00:43 |
MTDiscord |
<Jordach> just leave it to mod developers to build their own libraries around the problem |
| 00:43 |
v-rob |
Yeah, I know |
| 00:43 |
MTDiscord |
<Jordach> stop dictating what mod/game devs need because without absolute control and precision i may as well write it in god forbid, unreal |
| 00:43 |
v-rob |
I just want the engine to be doing it so the modders don't have to. Ugh |
| 00:44 |
MTDiscord |
<Jordach> you need to stop handholding people, the faster they get the stick rather than the carrot the better |
| 00:44 |
MTDiscord |
<Jordach> as much as i dislike saying this, the hypertext formspec element is far more useful than any of the existing versionings has ever done |
| 00:45 |
MTDiscord |
<Hugues Ross> I think you may be running into the difference between "don't have to" and "are unable to". Having simpler solutions doesn't preclude exposing information for custom lower-level solutions |
| 00:45 |
MTDiscord |
<Hugues Ross> In fact, I think having both is ideal |
| 00:45 |
MTDiscord |
<Jonathon> ^this |
| 00:46 |
v-rob |
I mean, that does make sense |
| 00:46 |
v-rob |
There is, of course, the technical aspect as well |
| 00:46 |
v-rob |
Fonts are particularly problematic |
| 00:46 |
MTDiscord |
<Jordach> boxing users and ostensibly the developers you're trying to attract with a limited viewpoint is extremely bad for business |
| 00:47 |
MTDiscord |
<Jordach> if a mod begins to require engine changes to do any form of heavy lifting it's automatically a failure |
| 00:47 |
MTDiscord |
<Jonathon> vrob: dont box yourself into not given x because of y, y can always be done later, but x can be used without y in multiple ways typically |
| 00:49 |
MTDiscord |
<Jordach> we're complaining simply because we see a very major problem in why it's a very bad idea |
| 00:49 |
MTDiscord |
<Jordach> let them have cake, and eat it, too |
| 00:50 |
v-rob |
OK then, presume we are planning on adding client info then. Sending window sizes is easy (it changes rarely, so a callback is possible, like `minetest.register_on_window_resize`), as is DPI and GUI scaling. How could one get font info then? |
| 00:51 |
MTDiscord |
<Jordach> pretty sure calculating pt based on DPI is super simple |
| 00:52 |
MTDiscord |
<Jordach> most character glyphs range from about a 1:1.5 to 1:2.5 ratio |
| 00:52 |
rubenwardy |
If the window changes screens, the DPI may change |
| 00:52 |
rubenwardy |
And the window size may change at any time |
| 00:52 |
rubenwardy |
So that's something you'd need to take into account |
| 00:52 |
v-rob |
That would be the idea of a callback, not a static field |
| 00:52 |
MTDiscord |
<Jordach> system dpi != monitor display size |
| 00:53 |
rubenwardy |
DPI is per screen |
| 00:53 |
MTDiscord |
<Jordach> maybe per screen but even 1440p (WQHD) is 97dpi |
| 00:53 |
MTDiscord |
<Jordach> 96* |
| 00:53 |
v-rob |
Some laptops nowadays are preeeeety high DPI, even if external screens connected to them are not. |
| 00:54 |
MTDiscord |
<Jordach> DPI is only a measurement of how far is a physical inch |
| 00:54 |
MTDiscord |
<Jordach> if anything depending on a user configurable value in minetest.conf is very dumb |
| 00:55 |
v-rob |
Still, a callback would mitigate the issue. Or, `player:get_window_info()` where the client sends window info to the server whenever it changes. It's not really insurmountable at all. |
| 00:55 |
MTDiscord |
<Jordach> saying that we need a major talk about networking |
| 00:56 |
MTDiscord |
<Jordach> serious business discussion going forwards because it's a total fucking mess |
| 00:56 |
rubenwardy |
It doesn't really solve this particular issue though, as there's no good way to find out how big text will be |
| 00:56 |
MTDiscord |
<Jordach> considering the default font we use is a practical known quantity that shouldn't be difficult |
| 00:56 |
rubenwardy |
It would help, along with touchscreen info, with switching between touch friendly and desktop UIs |
| 00:57 |
v-rob |
I don't know anything about the networking code, but it would just be a client->server message whenever screen info changes, and the server stores that info |
| 00:57 |
MTDiscord |
<Jordach> basically for any feature that communicates either way you spend one packet of 255 afaik |
| 00:57 |
MTDiscord |
<Jordach> 255 total unique enums |
| 00:57 |
v-rob |
Fonts, though, are completely unreliable. Font height is probably easy enough to calculate, but there's no way in the world to query the font width |
| 00:58 |
v-rob |
E.g. a hypertext is nigh impossible from the server without it |
| 00:58 |
MTDiscord |
<Jordach> instead of complaining about fonts just give us the option to use a bounding box |
| 00:58 |
MTDiscord |
<Jordach> defined the exact same way for positioning we do now |
| 00:59 |
v-rob |
Although, servers should 100% not implement their own hypertexts. I don't care how much we should give to the modders, they will never support Unicode properly. |
| 00:59 |
erlehmann |
<Jordach> just give us the full information |
| 00:59 |
v-rob |
I know we don't (yet), but modders never will. |
| 00:59 |
erlehmann |
Jordach great then i can finally get servers who will exclude me based on screen size |
| 00:59 |
erlehmann |
and i have to make a hacked client |
| 00:59 |
erlehmann |
to access them |
| 00:59 |
MTDiscord |
<Jordach> it's more the operator won't care |
| 00:59 |
MTDiscord |
<Jordach> https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam |
| 00:59 |
MTDiscord |
<Jordach> see this? |
| 01:00 |
erlehmann |
LVDS1 connected primary 1400x1050+0+0 (normal left inverted right x axis y axis) 290mm x 210mm |
| 01:00 |
MTDiscord |
<Jordach> if you click primary display resolution, it'll show you the exact percentage of the many millions of steam users |
| 01:00 |
erlehmann |
oh you are THAT kind of person |
| 01:00 |
MTDiscord |
<Jordach> 1400x1050 sounds exactly like a 19:10 display |
| 01:01 |
erlehmann |
uh what |
| 01:01 |
erlehmann |
it's 4:3 |
| 01:01 |
erlehmann |
approx |
| 01:01 |
MTDiscord |
<Jordach> point is we can gather aspect from calcuating w/h so it's not an issue |
| 01:02 |
erlehmann |
like how do you even get to 16:10 |
| 01:02 |
MTDiscord |
<Jordach> because it's one of those wack resolutions |
| 01:02 |
erlehmann |
i think you fail at division forever |
| 01:03 |
erlehmann |
; printf '4 k 1400 1050 / p 4 3 / p' |dc |
| 01:03 |
erlehmann |
1.3333 |
| 01:03 |
erlehmann |
1.3333 |
| 01:03 |
erlehmann |
all clear? :D |
| 01:03 |
MTDiscord |
<Jordach> i've got no problem with 4:3, 16:10 or the wack as fuck mobile users |
| 01:03 |
|
tekakutli joined #minetest-dev |
| 01:04 |
erlehmann |
Jordach i have done CSS layouts that worked for mobile and desktop and the most important lesson i have learned is it is a bad idea to give the server too much control |
| 01:04 |
erlehmann |
what is good is to have constraint-based layout and breakpoints |
| 01:04 |
erlehmann |
but what is bad is sending exact resolution etc. |
| 01:04 |
MTDiscord |
<Jordach> it's not our job to police everything a user does like some kind of stasi |
| 01:05 |
MTDiscord |
<Jordach> we leave that to the mod/game dev to taste |
| 01:05 |
erlehmann |
no no it is about API design |
| 01:05 |
erlehmann |
good API design makes entire classes of fuckups impossible |
| 01:05 |
MTDiscord |
<Jordach> canvas.js and Phaser; two notable things hard depend on that |
| 01:05 |
erlehmann |
for example, user agents. bad API design. |
| 01:05 |
erlehmann |
you can see it bc clients start to lie. |
| 01:05 |
erlehmann |
content negotiation? good API design. no reason to lie. |
| 01:06 |
erlehmann |
minetest ideally should not repeat problems the web has |
| 01:07 |
MTDiscord |
<Jordach> the real problem is not allowing regular users to make an absolute mess on their own |
| 01:07 |
MTDiscord |
<Jordach> giving them a free out is extremely bad |
| 01:08 |
erlehmann |
Jordach actually pretty much everyone i have seen who uses javascript on websites to do layout or animation instead of CSS or SVG is getting it horribly wrong |
| 01:08 |
v-rob |
If we're criticizing API design, formspecs are about the worst possible API ever in the history of GUIs |
| 01:08 |
erlehmann |
v-rob yeah but you can make them worse |
| 01:08 |
MTDiscord |
<Jordach> see every MTG fork that aims to fix it and ends up becoming some amalgam of forum mods |
| 01:09 |
erlehmann |
i am actually pretty happy that the engine devs do not give in to clowns who want the server to send every detail about the client to the server |
| 01:09 |
erlehmann |
i mean who want the client to send it |
| 01:09 |
erlehmann |
it is a great show of foresight |
| 01:09 |
MTDiscord |
<Jordach> so then why the hell are you using any browser |
| 01:09 |
MTDiscord |
<Jordach> it does that by default |
| 01:09 |
MTDiscord |
<Jordach> hell even your regular desktop does this with apps and it's DE |
| 01:10 |
erlehmann |
i am a hypocrite, society is broken and yet i participate in it! |
| 01:10 |
erlehmann |
actually, no. wayland does not allow a bunch of things. |
| 01:10 |
erlehmann |
that you can do with X11 |
| 01:10 |
erlehmann |
and it follows from their API design that you can not do them anymore in wayland |
| 01:11 |
erlehmann |
i think an app window can, for example, not absolutely position itself |
| 01:11 |
erlehmann |
(i may be wrong on this, can't test it right now) |
| 01:12 |
erlehmann |
Jordach i believe one has to talk about what you want to achieve. CSS-like constraint based layout is actually a good way to not send data to the server. |
| 01:12 |
MTDiscord |
<Jordach> a window should only choose positions where it's most logical to place it (ie where the mouse pointer resides on a screen, or predefined display) |
| 01:12 |
MTDiscord |
<Jordach> CSS works until you find yourself arguing with how shit it truly is |
| 01:12 |
MTDiscord |
<Jordach> there's a reason adobe flash isn't dead |
| 01:12 |
erlehmann |
i use tiled window managers and object to any windows that place themselves |
| 01:12 |
MTDiscord |
<Jordach> because every major game uses it as a HUD |
| 01:12 |
erlehmann |
flash is deader than dead tbh |
| 01:13 |
MTDiscord |
<Jordach> flash maybe dead but the schema it gave is why most games use it |
| 01:13 |
MTDiscord |
<Jordach> https://en.wikipedia.org/wiki/Scaleform_GFx |
| 01:14 |
erlehmann |
jordach for some reason *every* person who argued how shitty CSS was was unable to understand the cascade or sibling selectors or other basic stuff. and actually most of them admit it after a short while. |
| 01:14 |
erlehmann |
and it is not bc it is complicated too |
| 01:14 |
erlehmann |
they are unable because they chose to |
| 01:14 |
erlehmann |
i have made complex interfaces in CSS only |
| 01:14 |
MTDiscord |
<Jordach> CSS may not be complicated but the assigned box method is absolute ass |
| 01:15 |
erlehmann |
but if you want flash-like stuff, use svg, honestly |
| 01:15 |
erlehmann |
dvd menus use it i think |
| 01:15 |
v-rob |
@media screen and (max-width: 1000px) { * { display: none !important; } #haha { display: block !important; } } (HTML: <p id="haha">Your screen is too small"</p>) <<<< Yeah, CSS can *definitely* discriminate against you based on screen size. |
| 01:15 |
MTDiscord |
<Jordach> something like that is upto the mod/game devs taste |
| 01:15 |
MTDiscord |
<Jordach> doing any of that would invite it, sent or not |
| 01:16 |
erlehmann |
v-rob it can, of course. but since the client interprets it, you can work around it easier using user stylesheets. |
| 01:16 |
v-rob |
But you were just saying that you don't want to workaround it. |
| 01:16 |
erlehmann |
yeah so you should not give any way to access raw pixls |
| 01:16 |
erlehmann |
rather have landscape/portrait or touch/pointer paradigms |
| 01:16 |
erlehmann |
but in a way that one size fits all |
| 01:17 |
erlehmann |
i believe one of the best examples for this is GNU emacs. if you do some graphical stuff with it, it will just work in the GTK interface and also in your terminal. |
| 01:17 |
erlehmann |
no additional work required |
| 01:17 |
erlehmann |
like, i don't know, if you make some elisp that highlights all occurrences of the letter “e” |
| 01:17 |
MTDiscord |
<Jordach> if you want to make it just work let mod developers do as they please |
| 01:18 |
MTDiscord |
<Jordach> forcing them into a shitty little box that you defined is extremely hostile |
| 01:18 |
erlehmann |
actually not |
| 01:18 |
erlehmann |
having well-designed APIs and languages makes systems much more powerful in the end |
| 01:18 |
erlehmann |
have you read the langsec stuff? |
| 01:19 |
v-rob |
erlehmann: I WANT these good APIs you speak of. But they're impossible for formspecs, and the new GUI, even if I worked on it right now every day, it would still take a long time to finish coding, testing, reviewing, and bugfixing it, even in the best case scenario. So modders are stuck with nothing in the meantime. |
| 01:19 |
erlehmann |
basically, you need to find out what the complexity of your problem is and then use an approach of exactly that complexity, not more complex (bc then it gets unmaintainable) and not less (but if it is a bit less, you can always add to it later) |
| 01:20 |
erlehmann |
v-rob every solution will take a long time. fast, cheap, good – choose max. 2 |
| 01:20 |
v-rob |
Alternatively, do fast and cheap right now while we work on fast and good. |
| 01:21 |
erlehmann |
cheap in this case includes maintainability though |
| 01:21 |
MTDiscord |
<Jordach> this is exactly why i suggested just one release a year with the rest of it being bug fixes for up and coming |
| 01:21 |
erlehmann |
if you make a too powerful interface, you can never take it away |
| 01:21 |
v-rob |
Note: I'm not yet advocating for sending screen size, I still don't know if I support it or am against it yet. I still remain unconvinced either way. |
| 01:21 |
MTDiscord |
<Jordach> please see the implementation of PRANG! on CDB |
| 01:22 |
MTDiscord |
<Jordach> it's all done with raw HUD API |
| 01:22 |
erlehmann |
also if you have a shitty API that is easy to understand or use it will crowd out almost every API that is a bit better |
| 01:22 |
MTDiscord |
<Jordach> having known window borders would make it less frustrating |
| 01:24 |
MTDiscord |
<Jordach> keeping it simple is far better than the alternatives# |
| 01:24 |
erlehmann |
Jordach i think a good web example is the <select> elements in browsers. you can't style them well, but they will always be a reasonably good input field for the platform the user is on. |
| 01:24 |
v-rob |
It is 100% possible to limit this feature to formspecs only, so unless you want to use formspecs over the new GUI when it comes, you couldn't use the feature. (And no, no one wants to use formspecs, ever) |
| 01:24 |
erlehmann |
like it will be a drop down on one platform, a modal on another, a tab-completion text field on the third etc. |
| 01:25 |
erlehmann |
v-rob Jordach which libraries do you think do GUI in minetest the best? i wanna check them out |
| 01:25 |
MTDiscord |
<Jordach> no clue |
| 01:25 |
MTDiscord |
<Jordach> i build my own tools because using anything else leads to massive dependancy usage for next to no benefit |
| 01:25 |
erlehmann |
well |
| 01:26 |
erlehmann |
there are at least 2 kinds of those users |
| 01:26 |
MTDiscord |
<Jordach> i keep it super simple with an explicit focus |
| 01:26 |
erlehmann |
i am the kind that builds their own tools because existing tools suck for the purpose |
| 01:27 |
erlehmann |
like busybox tar, it does not make bit-exact reproducible tarballs. but my tar implementation is <100 LOC of bourne shell. |
| 01:27 |
erlehmann |
i only wrote it after understanding how exactly the busybox tar sucks though |
| 01:27 |
MTDiscord |
<Jordach> a lot of the ideas are depending on having lots of backend complexity for absolutely no reason |
| 01:28 |
erlehmann |
oh yeah i think backend complexity is bad |
| 01:28 |
erlehmann |
some mod devs jump through shitty hoops |
| 01:28 |
MTDiscord |
<Jordach> this is my point |
| 01:28 |
erlehmann |
to make everything eXaCtLy LiKe MiNeCrAfT for example ;) |
| 01:28 |
MTDiscord |
<Jordach> giving us user/system configured DPI, screen x,y would effectively solve all the problems |
| 01:29 |
erlehmann |
their code sucks |
| 01:29 |
erlehmann |
how |
| 01:29 |
MTDiscord |
<Jordach> we know mcl sucks |
| 01:29 |
MTDiscord |
<Jordach> if you listen closely you can hear the sound of a hoover sucking out all forms of hope from the maintainers |
| 01:30 |
erlehmann |
yeah but it is a good showcase on to how much lengths ppl go for example why particle spawners did not do what the devs wanted (which is being worked on i think) |
| 01:30 |
erlehmann |
Jordach so if you have user/system configured DPI, screen x,y … what would the backend do? |
| 01:30 |
erlehmann |
send different formspec based on that? |
| 01:31 |
erlehmann |
<Jordach> stop dictating what mod/game devs need because without absolute control and precision i may as well write it in god forbid, unreal |
| 01:31 |
MTDiscord |
<Jordach> basically it's up to the mod/game serving the content to find the most optimal way of showing things |
| 01:32 |
erlehmann |
this is the attitude i fear btw |
| 01:32 |
MTDiscord |
<Jordach> we're in an open source community with practically 100% open source content |
| 01:32 |
erlehmann |
well that is basically like “build everything in javascrap” |
| 01:32 |
erlehmann |
look people SUCK at UX |
| 01:32 |
MTDiscord |
<Jordach> people suck at UX because they never have to handle it |
| 01:32 |
erlehmann |
if you give them more opportunities, they will suck more. you probably not. |
| 01:32 |
MTDiscord |
<Jordach> give them the damn stick |
| 01:32 |
erlehmann |
but others. |
| 01:33 |
erlehmann |
uh i'll take html <select> or <video> over every custom-designed form element or video player any day of the week |
| 01:33 |
MTDiscord |
<Jordach> at the end of the day it's up to the lua developer to choose what works best |
| 01:34 |
erlehmann |
i think you are optimistic because you are talented |
| 01:34 |
MTDiscord |
<Jordach> the client doesn't need to know the specifics of how it works |
| 01:34 |
erlehmann |
and then ofc you hate being boxed in |
| 01:34 |
MTDiscord |
<Jordach> the client is a very dumb renderer |
| 01:34 |
erlehmann |
but it is possible to make APIs that make the right usage easier than the wrong usage, it is just damn hard |
| 01:35 |
MTDiscord |
<Jordach> making it any smarter risks having mods become visually or impaired between versions |
| 01:35 |
erlehmann |
oh yeah hmm |
| 01:35 |
MTDiscord |
<Jordach> it's an extreme level of risk |
| 01:35 |
MTDiscord |
<Jordach> keeping it simple by forcing the developer to choose at the risk of being beaten by the stick |
| 01:35 |
erlehmann |
every client improvement i have seen in formspec territory btw was CSM based |
| 01:35 |
v-rob |
So, either "dang hard" with screen size or "impossible" without |
| 01:35 |
v-rob |
Lovely options |
| 01:35 |
MTDiscord |
<Jordach> rather than giving them a carrot everytime |
| 01:35 |
MTDiscord |
<Jordach> you can already get "screen size" |
| 01:36 |
erlehmann |
how actually? |
| 01:36 |
MTDiscord |
<Jordach> per pixel offsets already exist for hud elems |
| 01:36 |
MTDiscord |
<Jordach> note that i said, per pixel, not per DPI |
| 01:36 |
MTDiscord |
<Jordach> with some experimenting you can find it |
| 01:37 |
MTDiscord |
<Jordach> by having a very large square texture with a simple crosshair drawn |
| 01:37 |
erlehmann |
do you need user assistance? |
| 01:37 |
MTDiscord |
<Jordach> yes |
| 01:37 |
MTDiscord |
<Jordach> and depending on DPI that may not be visible |
| 01:37 |
erlehmann |
what is “per DPI”? |
| 01:37 |
MTDiscord |
<Jordach> ie devices with a sub 7 inch display |
| 01:38 |
MTDiscord |
<Jordach> where it becomes near impossible to pick individual pixels out |
| 01:38 |
erlehmann |
oh |
| 01:38 |
MTDiscord |
<Jordach> if i know where the hard limits are, rather than the relative positions are |
| 01:39 |
erlehmann |
oh btw |
| 01:39 |
erlehmann |
> a vector-graphic based font system that uses a single texture to dynamically cache glyphs on demand |
| 01:39 |
MTDiscord |
<Jordach> it's much easier to relatively place hud elems |
| 01:39 |
erlehmann |
this is so funny, it always breaks down if you use unicode |
| 01:39 |
erlehmann |
(as in, it is almost a memory leak) |
| 01:39 |
MTDiscord |
<Jordach> unicode is a major mistake |
| 01:39 |
erlehmann |
at least in other libraries i have seen |
| 01:39 |
erlehmann |
what why |
| 01:40 |
MTDiscord |
<Jordach> the kind of thing that increasingly becomes overblown to the point it's painful to support each revision |
| 01:41 |
erlehmann |
uh |
| 01:41 |
erlehmann |
well |
| 01:41 |
MTDiscord |
<Jordach> and our currently bundled font doesn't even handle script like fonts |
| 01:41 |
erlehmann |
it kinda works |
| 01:41 |
erlehmann |
bundle unifont |
| 01:41 |
MTDiscord |
<Jordach> kek |
| 01:41 |
MTDiscord |
<Jordach> it's either all of the bloat or none of it by delimiting to ascii |
| 01:41 |
erlehmann |
look i am using unifont almost everywhere |
| 01:42 |
erlehmann |
and if you use it in a ttf engine |
| 01:42 |
erlehmann |
then you can have all the sweet sweet unicode fun |
| 01:42 |
erlehmann |
with a pixel font! |
| 01:43 |
MTDiscord |
<Jordach> here's what makes having known display sizes useful, a test case would be implementing the bouncing DVD logo |
| 01:43 |
MTDiscord |
<Jordach> you can also do bounds testing should you know image dimensions, with a basic aabb test |
| 01:44 |
erlehmann |
i am pretty sure i can implement that in both css and svg without knowing the absolute screen size … ? |
| 01:44 |
erlehmann |
i mean svg is basically flash-like |
| 01:44 |
erlehmann |
but without the bad parts |
| 01:45 |
erlehmann |
(exploits) |
| 02:16 |
MTDiscord |
<Jordach> i think the problem is you're shit scared of something being used to discriminate except for the fact it's needed to guarantee that xyz works properly on the game side |
| 02:17 |
MTDiscord |
<Jordach> don't be scared of doing things to make life better |
| 02:22 |
erlehmann |
Jordach i used to take part in web standards discussions in the past. also i have some experiences from my job regarding bad and good API design. that is why i am afraid. ultimately, my opinion does not count much, what counts is what is implemented, i just want ppl to be aware of the tradeoffs. |
| 02:22 |
MTDiscord |
<Jordach> if you're going to do it manually, you're probably already aware of the problems you're likely to encounter |
| 02:23 |
erlehmann |
you seem to think the risk is negligible, i have a different view based on different experiences |
| 02:23 |
MTDiscord |
<Jonathon> you seem to want to keep modders in a black box for supior vaporware designs |
| 02:24 |
erlehmann |
like i have made interfaces that worked well on small mobile screens and big screens, by following constraints i would best explain as “try to make a visual composition that would work both as a landcape poster and as a portrait postcard” |
| 02:24 |
MTDiscord |
<Jonathon> good for you, that doesnt solve minetest issues |
| 02:25 |
MTDiscord |
<Jordach> you would be doing that manually as part of it anyway |
| 02:25 |
erlehmann |
i am very well aware that most people are actually unable to work well with constraint-based layouts |
| 02:25 |
erlehmann |
that is why i asked how popular existing libraries do it |
| 02:26 |
erlehmann |
i have literally no idea what to do that is both usable and maintainable |
| 02:26 |
erlehmann |
(from a formspec POV) |
| 02:26 |
erlehmann |
Jonathon how do you do formspecs to make them portable? just keep them small? |
| 02:26 |
MTDiscord |
<Jordach> formspecs should be consigned to the void |
| 02:27 |
MTDiscord |
<Jordach> not keep them small but rather just as smaller individual pieces much like i3 (WM) |
| 02:27 |
MTDiscord |
<Jordach> at least with smaller pieces re-arranging to fit is much less ass |
| 02:27 |
erlehmann |
i guess we all agree on that. just don't let hecks rip out the formspecs, otherwise we get a ton of regressions followed by “that was never supported anyway”. ;) |
| 02:27 |
erlehmann |
oh yes i3 and sway do it *very* well |
| 02:28 |
MTDiscord |
<Jordach> formspecs are pretty much i3 DE to begin wtih |
| 02:28 |
|
queria^clone joined #minetest-dev |
| 02:28 |
MTDiscord |
<Jordach> just on a more expanded scale |
| 02:28 |
erlehmann |
well they are not very good at making me think about them like that |
| 02:28 |
MTDiscord |
<Jordach> we already have container[] |
| 02:29 |
erlehmann |
i'd *love* to help improve formspecs |
| 02:29 |
erlehmann |
it is so tedious |
| 02:29 |
MTDiscord |
<Jordach> to fix formspecs you'd have to look at the most common actions of a formspec |
| 02:29 |
MTDiscord |
<Jordach> what are games and mods trying to achieve most |
| 02:30 |
erlehmann |
inventory shenanigans, button-pressing state changes (turning on/off), hypertext |
| 02:30 |
erlehmann |
did i miss anythig major with that? |
| 02:30 |
MTDiscord |
<Jordach> hypertext practically solves all the UI problems |
| 02:30 |
erlehmann |
uh why do you think that? |
| 02:31 |
MTDiscord |
<Jordach> because i've been so far been able to implement a somewhat functional state machine with them |
| 02:31 |
erlehmann |
sorry i can't really follow here |
| 02:31 |
erlehmann |
pls elaborate? |
| 02:31 |
erlehmann |
what kind of state machine? |
| 02:32 |
MTDiscord |
<Jordach> i can click through a limitless amount of known dialogue entries |
| 02:32 |
MTDiscord |
<Jordach> or have it as a tree that locks off other choices given user inputs |
| 02:33 |
erlehmann |
ah |
| 02:33 |
erlehmann |
minetest text adventure made by jordach when |
| 02:33 |
erlehmann |
or dialog trees RPG style |
| 02:33 |
|
queria^clone joined #minetest-dev |
| 02:35 |
MTDiscord |
<Jordach> a lot of the engine flaws are paved over by MTG doing all the work for modders that depend on it |
| 02:36 |
MTDiscord |
<Jordach> the moment you stop using MTG you find there's a whole lot more choice |
| 02:37 |
erlehmann |
i kinda hate mtg |
| 02:37 |
MTDiscord |
<Jonathon> who doesnt hate it? |
| 02:38 |
MTDiscord |
<Jordach> BfA was an experiment to prove if minetest could handle much more demanding game types on the engine |
| 02:38 |
MTDiscord |
<Jordach> to take it any further requires me to have near gigabit upload |
| 02:38 |
MTDiscord |
<Jordach> or completely reinvent the network stack |
| 02:39 |
erlehmann |
why though |
| 02:39 |
erlehmann |
honestly, quake etc. did not have to do that |
| 02:39 |
MTDiscord |
<Jordach> because minetest is extremely network inefficient |
| 02:39 |
MTDiscord |
<Jordach> quake didn't need to because it had access to local client side entities that ran local code |
| 02:39 |
erlehmann |
is it bc of stuff like every entity in range spamming its updates? |
| 02:39 |
MTDiscord |
<Jordach> which means i don't have to send entity updates |
| 02:40 |
erlehmann |
could you give me a link for the current version so i can look at it again? |
| 02:40 |
erlehmann |
i liked the dynamics |
| 02:40 |
erlehmann |
and i want to figure out what makes the most traffic |
| 02:40 |
MTDiscord |
<Jordach> https://github.com/Dumpster-Studios/BattleForArkhos |
| 02:40 |
erlehmann |
you might remember, cora & me did a lot of analyzing regarding that |
| 02:41 |
erlehmann |
i still thing that minetest should emit a warning and not resend redundant packets if they were sent over a reliable channel |
| 02:41 |
erlehmann |
think |
| 02:41 |
erlehmann |
i sleep soon |
| 02:41 |
MTDiscord |
<Jordach> i already do that for HUD |
| 02:41 |
erlehmann |
thx |
| 02:41 |
erlehmann |
we do too |
| 02:41 |
MTDiscord |
<Jordach> i manually track last updates |
| 02:41 |
MTDiscord |
<Jordach> entities are a bit more uh |
| 02:41 |
MTDiscord |
<Jordach> special |
| 02:42 |
erlehmann |
i wish we would do it for entities |
| 02:42 |
MTDiscord |
<Jordach> i mean i already know the state before and after |
| 02:42 |
MTDiscord |
<Jordach> so it's not exactly farfetched an idea |
| 02:42 |
MTDiscord |
<Jordach> but because of server_step being cranked to 30hz, that means 30 lua steps per second |
| 02:42 |
MTDiscord |
<Jordach> which means huge network load |
| 02:42 |
erlehmann |
that can't possibly end well |
| 02:43 |
erlehmann |
but hey, on the other hand, finally something that has more traffic than mcl2 :D |
| 02:43 |
MTDiscord |
<Jordach> do you want a shooter where hitreg takes over 0.25s to register |
| 02:43 |
erlehmann |
it will be good for my engine studies |
| 02:43 |
MTDiscord |
<Jordach> or do you want it within 0.03s |
| 02:43 |
erlehmann |
like to figure out empirically what minetest is bad at |
| 02:43 |
erlehmann |
especially on the hardware i have |
| 02:44 |
MTDiscord |
<Jordach> also if you crank the shotguns pellets, minetest won't even crash at the thought of ~10k entities being spawned at once |
| 02:44 |
erlehmann |
by which i mean old thinkpad and new reform laptop |
| 02:44 |
MTDiscord |
<Jordach> render thread will nosedive |
| 02:44 |
MTDiscord |
<Jordach> but the lua thread soldiers on |
| 02:44 |
erlehmann |
ha |
| 02:45 |
erlehmann |
honestly i think making shotgun shells entities and not particles is wrong |
| 02:45 |
MTDiscord |
<Jordach> fun tip |
| 02:45 |
MTDiscord |
<Jordach> those are cosmetic |
| 02:45 |
erlehmann |
but i may have played too many emulated retro games recently |
| 02:45 |
MTDiscord |
<Jordach> everything outside of rockets etc are raycast |
| 02:46 |
erlehmann |
mode 7 gang reports in |
| 02:48 |
MTDiscord |
<Jordach> a handful of critical entities like the player head, arms and body do indeed track previous states |
| 02:49 |
MTDiscord |
<Jordach> however because these are critical to gameplay, they're properly handled |
| 02:49 |
MTDiscord |
<Jordach> more cosmetic ones are less cared for |
| 02:49 |
MTDiscord |
<Jordach> (and probably are the problem) |
| 02:50 |
erlehmann |
i see |
| 02:50 |
erlehmann |
well, every ornament is a crime |
| 02:51 |
MTDiscord |
<Jordach> i prioritise visual clarity |
| 02:51 |
MTDiscord |
<Jordach> which means the bells and whistles are needed |
| 02:52 |
erlehmann |
what i mean is |
| 02:52 |
|
Extex joined #minetest-dev |
| 02:52 |
erlehmann |
an ornament, a specific style, is usually not visual clarity |
| 02:52 |
erlehmann |
once you have reached a point where no stylistic changes will improve user experience, you have transcended the ornamental phase |
| 02:52 |
erlehmann |
for everything you display will have a use |
| 02:53 |
erlehmann |
i guess if someone manages that in minetest, it may be you |
| 02:53 |
erlehmann |
oh way, nodecore exists hehe |
| 02:57 |
|
v-rob joined #minetest-dev |
| 03:45 |
|
specing_ joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 06:10 |
|
v-rob joined #minetest-dev |
| 07:54 |
|
ivanbu joined #minetest-dev |
| 08:05 |
|
hendursa1 joined #minetest-dev |
| 09:13 |
|
Fixer joined #minetest-dev |
| 09:14 |
MTDiscord |
<IhrFussel> Does Minetest already support 16:10 well btw? Cause the upcoming handheld device "Steam Deck" will have that aspect ratio and depending on how popular it will become I could see many people using it for Minetest in the future |
| 09:19 |
sfan5 |
I'm sure it works just as well as 16:9 |
| 09:47 |
MTDiscord |
<MNH48> Steam Deck runs SteamOS 3.0 by default, which is based on Arch Linux; and it runs the normal KDE Plasma DE |
| 09:47 |
MTDiscord |
<MNH48> probably the question is more on, if Minetest run correctly in 16:10 on KDE Plasma, as afaik the windowing / fullscreen is handled by the DE |
| 09:57 |
|
appguru joined #minetest-dev |
| 10:32 |
|
calcul0n_ joined #minetest-dev |
| 11:00 |
|
Taoki joined #minetest-dev |
| 11:26 |
erlehmann |
platform powkiddy Q90, anyone of you ever built minetest for that? |
| 11:31 |
MTDiscord |
<Sublayer plank> powkiddy q90? |
| 11:37 |
erlehmann |
a china arm based console for about 30 monies |
| 11:37 |
erlehmann |
comes with a ton of emulators, but also quake and stuff |
| 11:37 |
erlehmann |
so i thought, maybe … |
| 11:47 |
erlehmann |
https://obscurehandhelds.com/2019/12/the-powkiddy-q90-looks-like-a-switch-lite-mini/ |
| 12:26 |
|
olliy joined #minetest-dev |
| 12:45 |
MTDiscord |
<IhrFussel> The Steam Deck has well over 110,000 preorders though so it could be a big mainstream hit |
| 12:46 |
erlehmann |
i don't get how some ppl focus on how much stuff steam or something else has |
| 12:46 |
erlehmann |
almost as if software development was a popularity contest |
| 12:46 |
erlehmann |
(i get the idea about that more ppl will be running arch though) |
| 12:47 |
|
proller joined #minetest-dev |
| 12:48 |
MTDiscord |
<Sublayer plank> yummy arch |
| 12:48 |
MTDiscord |
<Sublayer plank> anyways I'm pretty sure 16:10 is close enough to 16:9 to look decent |
| 12:49 |
MTDiscord |
<IhrFussel> Isn't that how for example console releases are prioritised? The more people have it the higher the device is on the list (usually) |
| 12:54 |
erlehmann |
IhrFussel all console releases of free software i have seen have been prioritized by “who puts in the effort” and none of the ppl who port stuff i have seen posting “oh it is so popular”, it was mostly that they had it laying around |
| 12:55 |
erlehmann |
IhrFussel our experiences may be different though, what are you referring to? |
| 12:56 |
MTDiscord |
<IhrFussel> Nevermind then, I was only thinking of commercial products not open source |
| 12:58 |
erlehmann |
if you'd optimize minetest for whatever the steam survey says, in half a year it would only run on contemporary gaming systems |
| 12:58 |
erlehmann |
you'd lose a bunch of mod devs that way |
| 12:58 |
erlehmann |
which is interesting, bc no one ever notices that kind of thing |
| 13:02 |
MTDiscord |
<Sublayer plank> are you still salty over the new opengl 2.0+ renderer that hecks was going to implement |
| 13:06 |
erlehmann |
i actually think hecks is careless and reckless in everything. if it was implemented properly (i.e. with easily switchable backends) i would have no issue, but if i recall correctly, hecks hinted that the abstraction will be cut in a way that will make switchable backends hard. |
| 13:07 |
erlehmann |
i mean the whole “lets rip stuff out of irrlicht instead of improving it” story is evidence for a “my use case is most important, unless anyone complains” approach (and if you want to be cynical, every complaint is a fringe opinion and the feature was never officially supported anyway) |
| 13:08 |
erlehmann |
not the way *that* it is done, but *how* |
| 13:08 |
pgimeno |
oh my, could you please stop flaming? |
| 13:08 |
erlehmann |
i was asked if i am still salty, ig i should have said yes? |
| 13:08 |
MTDiscord |
<exe_virus> Interesting viewpoint, I will say it's hard to make MT generically plug into a backend |
| 13:09 |
MTDiscord |
<exe_virus> Because all the backends are different |
| 13:09 |
MTDiscord |
<exe_virus> But, we can do it |
| 13:09 |
erlehmann |
minetest definitely does not use irrlicht like other ppl do, so the change is inevitable ig |
| 13:09 |
erlehmann |
or like other projects do |
| 13:09 |
MTDiscord |
<Sublayer plank> there's a difference between making minetest only run on RTX graphics cards and intel i9 processors, and raising the minimum requirements slightly in order to bring improvements to everyone above those minimum requirements |
| 13:10 |
MTDiscord |
<exe_virus> Oh very true. Definitely the goal should be to get to a legitimate ogl 2 pipeline |
| 13:10 |
MTDiscord |
<exe_virus> Nothing more is really needed for the next ten years. |
| 13:11 |
MTDiscord |
<exe_virus> In 2030, we can move on to ogl 3 or something |
| 13:11 |
MTDiscord |
<exe_virus> Cause right now we're on a mediocre ogl 1 pipeline haha |
| 13:11 |
erlehmann |
sublayer plank, it is usually not necessary to raise minimum requirements if rendering is correctly abstracted. |
| 13:12 |
MTDiscord |
<exe_virus> Mostly true, I'm sure there would be wonky specifics |
| 13:12 |
erlehmann |
like if minetest would be rendered to a terminal or 3d output device it should not matter |
| 13:12 |
MTDiscord |
<exe_virus> Not a big deal either way. And also that's a rather large project so I cannot speak or complain about the progress being made |
| 13:13 |
erlehmann |
oh i think it is legitimate to complain if something that used to work perfectly stops working |
| 13:13 |
MTDiscord |
<exe_virus> Instead I'll keep working on the webp PR, and keep improving my MT status/skills to eventually be a minor core dev |
| 13:14 |
pgimeno |
it may be legitimate to complain, but not to bully |
| 13:14 |
erlehmann |
pgimeno, am i bullying if i point out lies? |
| 13:15 |
pgimeno |
if you accuse people of misbehaving because they don't do what you want them to do, you're effectively bullying |
| 13:16 |
erlehmann |
i think it is not bullying to point out that ppl justify changes with stuff they think is obvious but have not benchmarked (hardware with ogl <2.0 not existing, new reforms having good OGLES support – i still get less frames than an old thinkpad, RLE encoded TGA files being better than PNG for very small pixel art) |
| 13:16 |
pgimeno |
you have complained, your complaints have been heard, now let the devs take the decision instead of hogging the chat for flaming constantly |
| 13:16 |
erlehmann |
but i wish to point out that i think the behaviour is the issue, not the person |
| 13:16 |
erlehmann |
ok! |
| 13:17 |
pgimeno |
I said it once and I'll repeat it, you're hindering development, not helping it |
| 13:18 |
erlehmann |
something else, do extensive reviews by me make it more likely that stuff gets approved my coredevs? i only reported bugs when it was clear to me that my reviews do not really count |
| 13:18 |
erlehmann |
by coredevs, sorry |
| 13:19 |
erlehmann |
i.e. if anyone wants me to do reviews (mostly i am interested in wuzzy stuff), i'd like to have at least a vague promise that putting in the amount of time a proper review can take does something |
| 13:20 |
erlehmann |
also does anyone maybe want to do pair programming (in a stream with screensharing) on the ub issues i reported? |
| 13:23 |
erlehmann |
pgimeno, i'll make a PR so i am helping development ok |
| 13:23 |
pgimeno |
thanks |
| 13:46 |
|
hendursaga joined #minetest-dev |
| 14:02 |
rubenwardy |
IhrFussel: reservations, not preorders |
| 14:04 |
rubenwardy |
it's necessary to raise minimum requirements to keep maintenance costs low |
| 14:08 |
rubenwardy |
(the difference being that it's only $5 to reserve, and you can get the money back if you decide not to get one closer to the time) |
| 14:43 |
MTDiscord |
<Jordach> erlehmann: consider the following, the steamdeck is a regular PC with a controller bolted on |
| 14:44 |
MTDiscord |
<Jordach> a lot of people are construing it as locked down, despite the fact valve mentions you can install whatever, including windows on it |
| 14:45 |
rubenwardy |
I love Steam and Valve - they've gained my respect for being open despite having a monopoly, and also improving Linux support |
| 14:45 |
rubenwardy |
well, "love" is a strong word |
| 14:45 |
rubenwardy |
but you get what I mean |
| 14:46 |
MTDiscord |
<Jordach> valve is only a monopoly because nobody else went to the lengths to build everything in properly |
| 14:46 |
rubenwardy |
yeah |
| 14:46 |
MTDiscord |
<Jordach> or go out of their way to ensure support |
| 14:46 |
rubenwardy |
even now, Epic are trying to use exclusives to gain market rather than a better client. Not that I've tried EGS, as they don't support Linux |
| 14:47 |
MTDiscord |
<Jordach> i refuse to even touch EGS outside of an actual hardware cosole |
| 14:53 |
|
v-rob joined #minetest-dev |
| 14:55 |
|
Fixer joined #minetest-dev |
| 14:55 |
rubenwardy |
also, just noticed this is -dev not #minetest. Definitely more of a #minetest discussion |
| 15:09 |
|
hendursaga joined #minetest-dev |
| 15:45 |
|
specing_ joined #minetest-dev |
| 15:56 |
|
Extex joined #minetest-dev |
| 17:09 |
|
fluxionary joined #minetest-dev |
| 17:55 |
|
v-rob joined #minetest-dev |
| 18:21 |
sfan5 |
rubenwardy: did you get the android build working yesterday? |
| 18:21 |
sfan5 |
I can try too if it doesn't work |
| 18:21 |
rubenwardy |
works locally |
| 18:21 |
rubenwardy |
gcc/clang still broken in CI |
| 18:23 |
sfan5 |
you can ignore that |
| 18:26 |
|
v-rob joined #minetest-dev |
| 18:32 |
rubenwardy |
minetest/src/network/connection.cpp:1210:16: error: call to member function 'push_back' is ambiguous |
| 18:32 |
rubenwardy |
after applying the two networking fixes |
| 18:37 |
sfan5 |
I see src/server.cpp:1307:32: error: call to member function 'push_back' is ambiguous in CI output |
| 18:38 |
sfan5 |
not that it makes any more sense |
| 18:38 |
rubenwardy |
yeah, I think it just got there first |
| 18:40 |
sfan5 |
you accidentally added a duplicate build/android/native/jni/Android.mk btw |
| 18:43 |
sfan5 |
ah |
| 18:43 |
sfan5 |
try backporting these: https://github.com/minetest/minetest/commit/f0bad0e2badbb7d4777aac7de1b50239bca4010a#diff-a87e3d649206e1295277fb509f8fba4b8120314187adeb82e30af2dca7c90482 |
| 18:44 |
sfan5 |
(just the container.h should be enough) |
| 19:24 |
|
behalebabo joined #minetest-dev |
| 19:24 |
|
proller joined #minetest-dev |
| 19:37 |
|
v-rob joined #minetest-dev |
| 19:55 |
|
v-rob joined #minetest-dev |
| 20:02 |
|
v-rob joined #minetest-dev |
| 20:11 |
|
proller joined #minetest-dev |
| 20:22 |
|
Fixer_ joined #minetest-dev |
| 20:29 |
|
v-rob joined #minetest-dev |
| 20:56 |
|
Fixer joined #minetest-dev |
| 21:06 |
|
v-rob joined #minetest-dev |
| 21:10 |
|
rubenwardy joined #minetest-dev |
| 21:22 |
|
proller joined #minetest-dev |
| 22:12 |
|
Extex joined #minetest-dev |
| 22:34 |
erlehmann |
sfan5 rubenwardy do you have scripts to bisect regressions? |
| 22:34 |
rubenwardy |
Git bisect |
| 22:35 |
erlehmann |
or rather, better question: for each revision, how do i build the canonical minetest binary, assuming an empty working directory? |
| 22:36 |
erlehmann |
i can not automate git bisect without that information (and it is not cmake && make) |
| 22:36 |
rubenwardy |
I don't get it |
| 22:37 |
rubenwardy |
The way to bisect is to use git bisect, and then make each time |
| 22:37 |
erlehmann |
i want to give a script to git bisect that builds minetest for each revision |
| 22:37 |
erlehmann |
the problem is that i found issues with the make based thing |
| 22:37 |
erlehmann |
so i need to build from zero |
| 22:37 |
rubenwardy |
With irrlicht this is more complicated, as there's no link to which version is needed |
| 22:37 |
rubenwardy |
Issues? |
| 22:37 |
erlehmann |
but the irrlicht thing kinda throws a wrench |
| 22:39 |
erlehmann |
yes, the actual dependency tree is somehow underspecified, i.e. it is possible that you get a binary not corresponding to the source code. the only thing that masks it seems to be the make behaviour that always rebuilds a lot of superfluous things if you check out a git branch. |
| 22:39 |
erlehmann |
so i fixed the latter and ran into the former |
| 22:40 |
erlehmann |
so if you check out git commits often you are likely to only rarely encounter it |
| 22:40 |
erlehmann |
but you will not know if you do, which makes it funny (no one will ever know that it happens unless they strace their build system) |
| 22:41 |
erlehmann |
regardless, i got the impression that with the new irrlicht thing minetest and irrlichtmt dependency is also underspecified |
| 22:41 |
erlehmann |
i.e. some versions of minetest work with some versions of irrlichtmt |
| 22:42 |
erlehmann |
but is there a canonical list of the working combinations? |
| 22:42 |
erlehmann |
should i go by date? |
| 22:43 |
erlehmann |
rubenwardy, i must admit that so far i have been trying irrlichtmt versions until one worked |
| 22:43 |
erlehmann |
starting from the newest |
| 22:45 |
erlehmann |
btw, i have not investigated if the make/git interaction fully masks the underspecified dependencies, in theory it should not be able to do that 100% |
| 22:47 |
rubenwardy |
when bisecting, you do want to have the same dependencies in possible |
| 22:47 |
rubenwardy |
as you want to find the bug in the MT code |
| 23:02 |
|
erlehmann joined #minetest-dev |
| 23:04 |
|
v-rob joined #minetest-dev |
| 23:05 |
MTDiscord |
<exe_virus> Are formspecs inside Mt or irrlicht? |
| 23:06 |
rubenwardy |
MT |
| 23:06 |
rubenwardy |
formspecs are in MT and they use the Irrlicht GUI API |
| 23:10 |
erlehmann |
is u64 the same as uint64_t? |
| 23:11 |
erlehmann |
context, i am debugging this https://github.com/minetest/minetest/issues/11631 |
| 23:13 |
rubenwardy |
probably effectively |
| 23:13 |
rubenwardy |
uint64_t was added in c++11, Irrlicht is C++03 (and so was MT originally) |
| 23:13 |
rubenwardy |
so IRrlicht has its own uint64_t type |
| 23:14 |
erlehmann |
thx |
| 23:15 |
|
Alias2 joined #minetest-dev |
| 23:19 |
rubenwardy |
update: I'm unable to generate signed APKs in the latest android studio \o/ |
| 23:24 |
MTDiscord |
<josiah_wi> erlehmann, if you describe some of the CMake dependency bugs at some point, I may be able to work on them. |
| 23:30 |
|
proller joined #minetest-dev |
| 23:35 |
erlehmann |
jjosiah_wi what kind of info do you need, a repro case? |
| 23:35 |
MTDiscord |
<josiah_wi> Yeah that would be awesome. |
| 23:44 |
erlehmann |
hard to find due to the nature of the thing |
| 23:45 |
erlehmann |
i can prove ofc that such a case must exist and construct one from that, but it will not be realistic |
| 23:46 |
|
jonadab joined #minetest-dev |
| 23:46 |
erlehmann |
josiah_wi is it possible to make cmake spit out a dot dependency graph, similar to redo-dot? |
| 23:46 |
erlehmann |
that would help me find a real case of this |
| 23:47 |
MTDiscord |
<josiah_wi> I believe so, but I haven't done it. Man page should tell. |
| 23:48 |
MTDiscord |
<josiah_wi> I think it uses graphviz or no. |
| 23:48 |
MTDiscord |
<josiah_wi> or something* |
| 23:50 |
erlehmann |
anyone here have an ARM computer? |
