Time |
Nick |
Message |
00:59 |
|
kilbith joined #minetest-dev |
00:59 |
kilbith |
hey hmmmm |
00:59 |
hmmmm |
hi |
01:00 |
kilbith |
whatcha doing here |
01:00 |
hmmmm |
just hanging out, i miss you guys |
01:01 |
rubenwardy |
oh hi |
01:01 |
hmmmm |
hey |
01:01 |
kilbith |
you do not miss nrz :] |
01:01 |
hmmmm |
haha |
01:01 |
hmmmm |
he probably mellowed out since then |
01:02 |
hmmmm |
wasn't happy with the way commits were being shoveled in back then but at least i didn't let any of those vulns through |
01:02 |
kilbith |
we have got another core-dev that you would love |
01:02 |
hmmmm |
i hope the review process got better |
01:04 |
kilbith |
tbh it's much less oppressive than we used to have when you were there |
01:04 |
kilbith |
but the other hand the QA has lowered |
01:04 |
kilbith |
+on |
01:05 |
kilbith |
more regressions after merges, but it's fixed quick |
01:05 |
kilbith |
it's more flexible than before |
01:06 |
hmmmm |
every time i took a break from minetest and came back 6 months later, update to latest in master, and then try it out, there'd be a new stutter or lag |
01:06 |
hmmmm |
lol |
01:06 |
hmmmm |
drives me insane |
01:06 |
kilbith |
you might take a look to what I tinkered with: https://www.youtube.com/channel/UCL3-3UWAMEjalYeGYzZvjxg/videos |
01:06 |
rubenwardy |
maybe you're just forgetting the stutter or lag |
01:06 |
kilbith |
I implemented ffmpeg in MT |
01:06 |
rubenwardy |
:D |
01:07 |
hmmmm |
like ilu guys but you gotta get better at profiling and optimizing the changes you made instead of just constantly adding in new changes |
01:07 |
kilbith |
and we have got shadowmapping |
01:07 |
hmmmm |
woow nice |
01:07 |
rubenwardy |
it's hard to avoid regressions in a program with less than 13% unit test coverage. There's Lua unit tests and a couple of integ tests, but no real progress on regression tests |
01:07 |
hmmmm |
lol i was working on that right before i got busy |
01:07 |
rubenwardy |
I mean - shadowmapping is probably a good example of "new changes rather than profiling and optimising" |
01:07 |
hmmmm |
yeah sorry for abandoning you |
01:07 |
hmmmm |
i switched jobs, moved, etc. life happened |
01:08 |
hmmmm |
i'm glad people are working on the hard stuff like shadowmapping |
01:08 |
rubenwardy |
we have forked Irrlicht and have deleted like 90% of the code |
01:08 |
rubenwardy |
it has allowed us to work on fixing input issues that were unfixable |
01:08 |
hmmmm |
sweet |
01:09 |
hmmmm |
yeah irrlicht used to be a huge pain point |
01:09 |
rubenwardy |
well, I say we but I mean s*an and h*cks |
01:09 |
hmmmm |
at some point after MT i started working on my own game, it's like a real time strategy with procedurally generated maps |
01:09 |
kilbith |
yeah we have got hecks - who is literally a beast on the rendering dev |
01:09 |
hmmmm |
i settled on irrlicht and got tired of it fairly quick |
01:10 |
hmmmm |
that whole thing went nowhere fast |
01:10 |
hmmmm |
oh i wonder how build a world ended up |
01:10 |
hmmmm |
remember them |
01:10 |
kilbith |
hmmmm: https://www.youtube.com/watch?v=uz1douFQcok |
01:10 |
rubenwardy |
they pivoted to education and sold their company I believe? |
01:11 |
hmmmm |
nice |
01:11 |
hmmmm |
i mean the reflections |
01:11 |
kilbith |
https://github.com/minetest/minetest/pull/9430 |
01:11 |
hmmmm |
didn't think we were gonna have any more shader work after RBA left us |
01:11 |
hmmmm |
RIP |
01:12 |
kilbith |
we trashed some of the RBA shaders eventually |
01:12 |
rubenwardy |
hecks has filled his place, only 7 years later... |
01:12 |
rubenwardy |
eh |
01:12 |
hmmmm |
maybe they weren't the best, but at least they existed |
01:13 |
hmmmm |
lol @ the ffmpeg commit |
01:13 |
hmmmm |
so you got TV blocks or something now |
01:14 |
kilbith |
I closed the PR |
01:14 |
hmmmm |
aw |
01:14 |
kilbith |
they said it's too big of a dependancy |
01:14 |
hmmmm |
yeah it is, but i wouldn't complain about it if it were optional... |
01:14 |
rubenwardy |
that was one issue, the other was that our media transfer system wouldn't have worked |
01:14 |
hmmmm |
thing is, in a collaborative game like MT, you know everybody's gonna want to use it in their servers, and make it de facto mandatory |
01:14 |
rubenwardy |
although - with dynamic media, it's more viable |
01:15 |
rubenwardy |
(dynamic media = servers can send media at runtime, since v5.3) |
01:15 |
kilbith |
yeah we can update media dynamically now |
01:15 |
hmmmm |
5.3?! |
01:15 |
rubenwardy |
yeah, we went from v0.4.17 to v5.0 |
01:15 |
hmmmm |
ohh |
01:15 |
rubenwardy |
dropping the 0. |
01:15 |
hmmmm |
should probably went to 1 imho ohwell |
01:15 |
hmmmm |
you pulled a SunOS |
01:16 |
hmmmm |
how do you do the render to texture in game without causing significant lag? |
01:16 |
MTDiscord |
<josiah_wi> I'm looking for some easy coding related stuff to get into. I've merged a couple PRs to the build system, so I have the slightest bit of experience with the PR system and the project structure. I don't mind code quality stuff and little issues that are quick fixes, but there's no system I'm aware of for an amateur contributor to find issues that are appropriate for him to work on. |
01:17 |
hmmmm |
to be fair that's the issue with many of the open source projects, it takes a ton of prior context and skill to be useful much of the time |
01:17 |
hmmmm |
"anybody can just contribute if they want!" is such a bald faced lie lol |
01:18 |
rubenwardy |
yeah |
01:18 |
rubenwardy |
we need more highly skilled contributors with time who can become core developers |
01:18 |
MTDiscord |
<josiah_wi> Well, to my discredit, I did introduce more problems in my first PRs for me to subsequently fix, creating a cycle of constant opportunities for myself. |
01:18 |
hmmmm |
my advice is to not look for easy stuff, but focus on one part of MT that you really want to make better, study up all you can on it, become an expert on it |
01:19 |
MTDiscord |
<josiah_wi> Well, that's the build system and the code style, but neither align with the core devs goals afaik. XD |
01:20 |
hmmmm |
most of the time the problems aren't difficult, per se, but they need somebody to understand how what currently exists works, why it's like that, how it interacts with everything else, etc. |
01:20 |
hmmmm |
hmmm last time i checked the build system was pretty decent |
01:20 |
hmmmm |
but still fragile |
01:20 |
rubenwardy |
it used outdated CMake rather than a modern approach, with targets and modules |
01:21 |
rubenwardy |
josiah_wi has being improving that |
01:21 |
hmmmm |
i didn't know there was an outdated way of using CMake :( |
01:21 |
hmmmm |
sounds good |
01:21 |
rubenwardy |
one of the things you can do now is clone Irrlicht-MT to `minetest/lib/irrlicht`, and CMake will pick it up and compile it automagically |
01:21 |
hmmmm |
ohhh it's a git submodule |
01:22 |
MTDiscord |
<josiah_wi> I'm studying CMake build system design to a degree that's kind of crazy. But studying doesn't replace experience... I broke server builds with headers due to a versioning issue I believe and just heard about it. |
01:22 |
rubenwardy |
it's not, because there's a dislike of submodules |
01:22 |
rubenwardy |
it also wasn't directly included because the SLoC dwarves MT |
01:23 |
MTDiscord |
<josiah_wi> I didn't actually do the lib/irrlicht, NeroBurner did that. |
01:23 |
rubenwardy |
eventually, it'll probably be swallowed by Minetest - I'm not sure what the plans were for that |
01:23 |
hmmmm |
josiah if you wanna do experimental stuff with the build system you've gotta have an array of test systems |
01:23 |
hmmmm |
I used to have a win7 x64 VM, mac osx VM, linux VM, etc. for testing minetest builds |
01:23 |
MTDiscord |
<josiah_wi> Yeah, that's my issue. In particular we have to support CMake 3.5 and I'm on 3.18 |
01:24 |
hmmmm |
the mac osx vm was such a pita i think i dropped testing on that |
01:24 |
rubenwardy |
we use GitHub CI for Windows and Linux VMs |
01:24 |
hmmmm |
awesome |
01:24 |
MTDiscord |
<josiah_wi> I'm thinking about purposefully getting a computer to install an archaic debian on. |
01:24 |
rubenwardy |
not sure if it supports Mac OS |
01:24 |
hmmmm |
of course it doesn't |
01:24 |
hmmmm |
you're not allowed to run mac osx on a VM as per the license |
01:25 |
rubenwardy |
haha right |
01:25 |
rubenwardy |
great |
01:25 |
rubenwardy |
it's like Apple doesn't want people to support their devices |
01:25 |
hmmmm |
I mean, people have managed to get it running on a VM, but it's fragile |
01:26 |
hmmmm |
macs are the BMWs of the computer world |
01:29 |
MTDiscord |
<josiah_wi> How come we have a MacOSX CI build for Irrlicht now then? |
01:30 |
hmmmm |
well that's a positive thing |
01:33 |
hmmmm |
i have no idea how they do it. maybe they set it up so the CI runs on a physical machine? |
01:33 |
MTDiscord |
<josiah_wi> No idea. I just saw it today and all I care about is that the light is green lol. |
01:42 |
|
calcul0n joined #minetest-dev |
01:46 |
pgimeno |
> <rubenwardy> eventually, it'll probably be swallowed by Minetest - I'm not sure what the plans were for that <-- from my understanding, the plans are to get rid of it, not to swallow it |
01:47 |
pgimeno |
the long-term plans at least |
01:49 |
pgimeno |
to that end, the hardest nut to crack is probably going to be the GUI; v-rob said he's willing to take on that. I'm also concerned about the scene graph, but hecks said it's not a problem so... |
01:52 |
kilbith |
also, the GUI/HUD will be unified under the same API |
01:54 |
MTDiscord |
<Jordach> >you're not allowed to run mac osx on a VM as per the license |
01:55 |
MTDiscord |
<Jordach> factually incorrect |
01:55 |
MTDiscord |
<Jordach> VMs on actual macs are fine |
02:08 |
|
kilbith_ joined #minetest-dev |
02:17 |
|
v-rob joined #minetest-dev |
02:19 |
v-rob |
"the hardest nut to crack is probably going to be the GUI; v-rob said he's willing to take on that" -- Correction: already taking it on and making good progress too. |
02:26 |
hmmmm |
>The macOS Virtualbox option is designed for genuine Apple hardware. You will not get community support from Virtualbox if you have trouble with this process, as it’s against Apple ToS. |
02:28 |
|
queria^clone joined #minetest-dev |
02:30 |
|
queria joined #minetest-dev |
02:35 |
v-rob |
I think I ought to give a progress report: I decided to work on the GUI entirely separate from Minetest so I don't have to worry about any cruft or dependencies that I have to make first (like Irrlicht deficiencies). Currently, I have a simple abstraction over SDL that can be ported to Irrlicht (or OpenGL if hecks gets there first). At this point, I've got a lot of the important basic stuff down and am working on layouting/sizers and the Lua bindings. |
02:35 |
v-rob |
Once that's all done, I'll work on events and text (I've decided that Unicode support will be as full as possible or bust -- I'm sick of the current situation). Then, make the rest of the elements, a few more features, integrate with Minetest, and destroy formspecs. Nothing too it. |
02:35 |
v-rob |
too -> to |
02:36 |
v-rob |
Personally, I want to do a few beta releases on the GUI (via temporary integrations with Minetest in the dev versions or something) so people can mess around with it, find all the bugs, criticize the API, and tell me how terrible it all is. |
02:37 |
v-rob |
Anyhow, my schedule is rather hectic right now, so don't expect miracles, but it's moving forwards |
02:40 |
|
behale_ joined #minetest-dev |
02:42 |
hmmmm |
it seems as though the EULA changed as of OSX 10.8.2: "(iii) to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using OS X Server; or (d) personal, non-commercial use." |
02:42 |
hmmmm |
so apple says that you can have two mac osx VMs, but only on a mac osx host |
02:44 |
hmmmm |
errrr wait jordach specified "on actual macs" ok nvm :) confirmed then |
04:00 |
|
MTDiscord joined #minetest-dev |
05:23 |
|
YuGiOhJCJ joined #minetest-dev |
05:51 |
|
v-rob joined #minetest-dev |
06:50 |
|
Kimapr joined #minetest-dev |
07:00 |
|
entuland joined #minetest-dev |
07:24 |
nrz |
Haha that kilbith troll. People dors n'y change in 6 years :p |
08:57 |
|
calcul0n joined #minetest-dev |
09:40 |
|
Fixer joined #minetest-dev |
09:54 |
|
specing_ joined #minetest-dev |
10:01 |
|
longerstaff13 joined #minetest-dev |
10:15 |
|
TaokiLaptop joined #minetest-dev |
11:16 |
sfan5 |
<josiah_wi> I'm thinking about purposefully getting a computer to install an archaic debian on. |
11:16 |
sfan5 |
you run linux don't you? just use a container |
11:28 |
|
Alias joined #minetest-dev |
11:38 |
sfan5 |
<hmmmm> i hope the review process got better |
11:38 |
sfan5 |
eh doubt you'd consider it better |
11:39 |
sfan5 |
reviews are already slow and people are frustrated with it, tightening it without a better approach wouldn't be good |
12:59 |
|
kilbith joined #minetest-dev |
12:59 |
MTDiscord |
<josiah_wi> I am new to containers, and my dev PC is a total potato. I believe it can run docker, but maybe not an OS inside it. |
13:00 |
MTDiscord |
<josiah_wi> I could try it though. |
13:01 |
MTDiscord |
<Warr1024> Docker doesn't run a whole OS, it just runs the applications. It assumes that the inner OS uses the same kernel as the outer one, so it runs only the single shared kernel, but the userland (what differentiates distros generally) can be independent. |
13:01 |
sfan5 |
with proper containers (not VMs) running a program inside of them is no different than running one outside |
13:02 |
MTDiscord |
<Warr1024> I run tons of docker containers on raspis; it's pretty impressively lightweight. Mostly just costs a little extra disk space. |
13:02 |
sfan5 |
so it will run even on a potato |
13:18 |
|
Desour joined #minetest-dev |
13:35 |
|
calcul0n_ joined #minetest-dev |
14:02 |
|
olliy joined #minetest-dev |
14:18 |
|
longerstaff13 joined #minetest-dev |
14:52 |
|
Extex joined #minetest-dev |
15:16 |
|
v-rob joined #minetest-dev |
15:32 |
|
entuland joined #minetest-dev |
15:38 |
|
v-rob joined #minetest-dev |
15:53 |
MTDiscord |
<Jordach> it sounds more like he won't put his money where his mouth is |
16:30 |
|
v-rob joined #minetest-dev |
16:35 |
|
v-rob joined #minetest-dev |
16:52 |
MTDiscord |
<josiah_wi> Is there a good resource for learning to set up docker containers for this kind of purpose? |
16:54 |
|
appguru joined #minetest-dev |
16:55 |
sfan5 |
I don't use docker actively but I can imagine you can literally pull the debian image and just open a shell inside to do what you want |
16:55 |
sfan5 |
since the container instances are exist while they're used, not permanently |
17:34 |
MTDiscord |
<josiah_wi> I have no idea how to use docker, though. Should I just look up a simple docker tutorial? |
17:35 |
MTDiscord |
<josiah_wi> I absolutely do not want to redownload dependencies every time I start the container btw... |
17:54 |
nrz |
go on docker website, there is plenty of resources on the web |
18:30 |
MTDiscord |
<josiah_wi> I cannot find a Linux distribution that has a CMake 3.5 package. De ian Jessie had 3.7. Does anyone know where I can find a distribution with this version? |
18:31 |
MTDiscord |
<josiah_wi> It seems weird to have a minimum 3.5 requirement if no distros anywhere have a package for it, so there must be at least one out there. |
18:33 |
sfan5 |
slackware 14.2 |
18:33 |
sfan5 |
debian 9 comes close with 3.7 |
18:43 |
MTDiscord |
<josiah_wi> Thank you. |
18:47 |
sfan5 |
you can build and install cmake 3.5 on a modern distro btw, just extra work |
18:49 |
|
v-rob joined #minetest-dev |
19:01 |
|
Desour joined #minetest-dev |
19:26 |
pgimeno |
why cmake 3.5? |
19:30 |
MTDiscord |
<Sublayer plank> it's the lowest cmake version minetest is intended to support |
19:33 |
sfan5 |
I went through some package version overview of Linux distros and all distros that weren't ancient (cmake 2.8.*) had at 3.5 or newer so I went with that |
19:33 |
sfan5 |
at least* |
19:34 |
MTDiscord |
<josiah_wi> Do we know whether anyone actually uses that version to compile Minetest? |
19:34 |
sfan5 |
npo |
19:34 |
sfan5 |
no* |
19:35 |
|
Desour joined #minetest-dev |
19:35 |
MTDiscord |
<josiah_wi> Do we ever test on it (does it even work)? |
19:37 |
sfan5 |
no and probably |
19:38 |
MTDiscord |
<josiah_wi> Good grief, slackpkg doesn't install dependencies for packages you install. |
19:39 |
sfan5 |
yes uh slack is quite ... antiquated |
19:39 |
MTDiscord |
<josiah_wi> Anyone compiling Minetest on Slackware must be a brave guy. |
19:39 |
MTDiscord |
<josiah_wi> If we confirm Minetest doesn't work on Slackware can we raise the minimum CMake version? I'm curious. |
19:42 |
sfan5 |
if that's a purely theoretical question then the answer is I don't know |
19:42 |
MTDiscord |
<Warr1024> Being the "do everything yourself the hard way" distro is sort of like slack's niche these days |
19:43 |
MTDiscord |
<josiah_wi> I just want to check before I continue. Will my work go away if I exit the container? I started it with docker run --interactive --tty <container> bash |
19:43 |
MTDiscord |
<josiah_wi> There's no way I'm going to continue this atm until I know my work will be saved. |
19:46 |
MTDiscord |
<Warr1024> I think you didn't use --rm so your work is ... somewhere |
19:46 |
MTDiscord |
<Warr1024> but not necessarily easy to access? |
19:47 |
MTDiscord |
<Warr1024> Usually with docker you script things out, and treat the containers themselves as throwaway, but I believe docker doesn't automatically throw them away for you either |
19:47 |
MTDiscord |
<josiah_wi> No idea, I am running in the dark. I've already done more work in the container than I should've. |
19:48 |
MTDiscord |
<josiah_wi> A container is an unviable solution unless I can have it save all the packages I need and preferably the file system. |
19:49 |
MTDiscord |
<josiah_wi> Docker is supposedly easy, but for me it's a nightmare to work with lol. |
19:49 |
sfan5 |
treating containers as throwaway is specifically a docker thing |
19:49 |
sfan5 |
you wouldn't have this systemd-nspawn containers for example |
19:49 |
sfan5 |
or lxc/lxd |
19:50 |
MTDiscord |
<josiah_wi> I just want advice on where to go from here; I'm thinking building CMake 3.5 would be significantly easier... |
19:51 |
sfan5 |
well I'd say go with systemd-nspawn and get a debian 9 container with cmake 3.7 where you'll do your work in |
19:53 |
MTDiscord |
<Warr1024> With docker, the least throwaway thing is your dockerfile, which is basically the src. Then the compiled image is somewhat more throwaway, and then the running container is most throwaway. |
19:57 |
|
BuckarooBanzai joined #minetest-dev |
19:57 |
MTDiscord |
<josiah_wi> That was quick. There's a CMake dependency that there's no package for apparently. |
19:59 |
|
proller joined #minetest-dev |
19:59 |
MTDiscord |
<josiah_wi> nevermind; it was in another package |
20:04 |
|
v-rob joined #minetest-dev |
20:42 |
|
behale_ joined #minetest-dev |
21:16 |
|
appguru joined #minetest-dev |
21:52 |
nrz |
debian 9 will be EOL soon, in 1 year max |
21:53 |
|
specing_ joined #minetest-dev |
21:54 |
|
Extex joined #minetest-dev |
21:58 |
|
proller joined #minetest-dev |
21:59 |
|
Desour joined #minetest-dev |
22:13 |
MTDiscord |
<josiah_wi> SQLite is a required dependency even if PostgreSQL is enabled? |
22:14 |
Desour |
it's listed as dependency in the README, so I think so. |
22:15 |
MTDiscord |
<josiah_wi> I'm curious why though. |
22:16 |
sfan5 |
it'd be very inconvenient if there wasn't a minimum standard world format all minetest builds understand |
22:16 |
sfan5 |
aside from the fact that auth and player database currently only support legacy plaintext files OR sqlite3 (current default) |
22:16 |
MTDiscord |
<josiah_wi> No, I'm asking why I have to install SQLite if I'm only using PostgreSQL. |
22:17 |
MTDiscord |
<josiah_wi> Ah, got it |
22:17 |
MTDiscord |
<josiah_wi> Pretty soon I will have a package list for dependencies on Slackware. :) |
22:18 |
sfan5 |
https://0x0.st/-toP.mp4 beautiful |
22:18 |
Desour |
that won't be so beautiful on a remote multiplayer server I guess |
22:19 |
sfan5 |
you need to live with the latency |
22:19 |
Desour |
not if we had sscsm |
22:20 |
MTDiscord |
<GreenXenith> Isnt there already a CSM for that |
22:20 |
MTDiscord |
<GreenXenith> That honestly seems like a job for straight CSM |
22:23 |
sfan5 |
dunno |
22:23 |
sfan5 |
I need this to test the server-part anyway |
22:30 |
|
Extex joined #minetest-dev |
22:39 |
MTDiscord |
<Jordach> honestly SSCSM is simple |
22:39 |
MTDiscord |
<Jordach> you're just making it more difficult than it actually is |
22:46 |
Desour |
actually, I've recently worked on a branch to implement sending of files with paths and so on. it basically reforms all the media sending stuff (at least the announcing and receiving, I didn't come yet to the data sending) |
22:46 |
Desour |
the problem is just that there's so much one could improve in this area. eg. that you can use paths for textures |
22:46 |
Desour |
or using tcp for reliable packets; and implementing some sort of stream packet, to replace the "bunches" in the media sending protocol |
22:46 |
sfan5 |
sounds like remote_media except no manual setup |
22:46 |
sfan5 |
(and more complicated) |
22:47 |
Desour |
something like remote media is one application of stream packets. another would be streamed sounds |
22:47 |
Desour |
ie. ingame music that doesn't take seconds to load |
22:50 |
Desour |
and reimplementing the reliable packets with tcp would also bring all the other benefits of tcp. minetest currently doesn't even probe the MTU and just uses packet sizes of 500 or 512 (one is server, the other the client) |
22:52 |
sfan5 |
plus the downsides of tcp |
23:01 |
|
v-rob joined #minetest-dev |
23:19 |
|
AliasAlreadyTake joined #minetest-dev |
23:57 |
MTDiscord |
<josiah_wi> At last! I'm building my Docker image, and it'll be able to use a graphical display. I compiled Minetest, but I couldn't test it yet. |
23:58 |
MTDiscord |
<josiah_wi> This is still using Slackware. So Minetest does build, with a simple configuration and no sound. |
23:59 |
MTDiscord |
<josiah_wi> (I didn't figure out the right vorbis libs yet so I skipped that because it was getting boring.) |