| Time |
Nick |
Message |
| 00:06 |
Zughy[m] |
I've finished labelling all the issues. These are the ones where I can't find any proper "@" label |
| 00:06 |
Zughy[m] |
https://github.com/minetest/minetest/issues?page=1&q=is%3Aissue+is%3Aopen+-label%3A%22%40+Builtin%22%2C%22%40+Client+rendering+engine%22%2C%22%40+Devtest+Game%22%2C%22%40+Network%22%2C%22%40+Mainmenu%22%2C%22%40+Documentation%22%2C%22%40+Content%2FPkgMgr%22%2C%22%40+Translation%22%2C%22%40+Script+API%22%2C%22%40+Client+%2F+Controls+%2F+Input%22%2C%22%40+Build%22%2C%22%40+Client+%2F+Audiovisuals%22%2C%22%40+Mapgen%22%2C%22%40+Client+Script |
| 00:06 |
Zughy[m] |
+API%22%2C%22%40+Startup+%2F+Config+%2F+Util%22%2C%22%40+Server+%2F+Client+%2F+Env.%22 |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:00 |
|
behalebabo joined #minetest-dev |
| 06:18 |
|
calcul0n joined #minetest-dev |
| 08:11 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:02 |
|
appguru joined #minetest-dev |
| 09:46 |
|
HuguesRoss0 joined #minetest-dev |
| 11:14 |
|
queria joined #minetest-dev |
| 11:30 |
|
proller joined #minetest-dev |
| 12:33 |
|
Wuzzy joined #minetest-dev |
| 12:33 |
Wuzzy |
#11432 |
| 12:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/11432 -- Add support for attached facedir nodes by Wuzzy2 |
| 12:39 |
|
Taoki joined #minetest-dev |
| 13:06 |
|
proller joined #minetest-dev |
| 13:08 |
|
queria^clone joined #minetest-dev |
| 13:20 |
|
Fixer joined #minetest-dev |
| 14:38 |
|
queria^clone joined #minetest-dev |
| 14:41 |
|
kilbith joined #minetest-dev |
| 14:43 |
kilbith |
I created a realtime camera formspec element that I want to generalize to the HUD: https://www.youtube.com/watch?v=elpPXFiSgYE |
| 14:45 |
MTDiscord |
<Warr1024> Pretty cool stuff. Can you move that camera indepedently of the player then? |
| 14:46 |
MTDiscord |
<ZweiKamel> Oh damn |
| 14:46 |
MTDiscord |
<ZweiKamel> That's incredible |
| 14:46 |
MTDiscord |
<ZweiKamel> So that formspec element renders in real-time? |
| 14:46 |
kilbith |
yes and yes |
| 14:47 |
MTDiscord |
<ZweiKamel> I imagine it could be super useful as like, a security camera kind of mod |
| 14:48 |
kilbith |
a Duke-Nukem like security camera |
| 14:48 |
kilbith |
if you ever played it |
| 14:48 |
MTDiscord |
<ZweiKamel> I vaguely remember Duke Nukem |
| 14:48 |
MTDiscord |
<Warr1024> Being able to paint the render onto an in-world surface, like a node or entity upright_sprite, would be a pretty awesome v2 :-) |
| 14:49 |
MTDiscord |
<luatic> First we need a Camera API, then we can talk about HUD / FS cameras. |
| 14:49 |
MTDiscord |
<ZweiKamel> OH, Duke Nukem 3D? I remember that! That'd be super cool! |
| 14:49 |
MTDiscord |
<luatic> I don't want to have to use a fullscreen HUD element, painting over the entire screen and wasting half the FPS just to get a Camera API. |
| 14:49 |
kilbith |
luatic: perfectionism is the enemy |
| 14:49 |
MTDiscord |
<luatic> This isn't perfectionism, this is just building this modularly and properly |
| 14:50 |
kilbith |
then do it, show me the code |
| 14:50 |
MTDiscord |
<luatic> Rather than putting the cart before the horse |
| 14:50 |
MTDiscord |
<Warr1024> sometimes you have to build something messy first, and then pretty it up later. |
| 14:50 |
kilbith |
"done" sounds better than "better" |
| 14:50 |
erle |
kilbith haha are you doing it like duke nukem? |
| 14:50 |
MTDiscord |
<luatic> Which is why the entire Minetest API is a hot mess |
| 14:50 |
erle |
kilbith, can you do MIRRORS? |
| 14:50 |
kilbith |
@Warr1024: exactly. |
| 14:51 |
erle |
nothing lasts as long as a temporary solution |
| 14:51 |
MTDiscord |
<Warr1024> It's not so much putting the cart before the horse as it is just pushing the cart yourself because you're not confident the horse is going to arrive at all :-) |
| 14:51 |
erle |
anyway, if you can paint onto an in-world surface, you are thinking with portals |
| 14:51 |
kilbith |
erle: mirrors require screen-space reflection, so we need a postprocessing framework first |
| 14:51 |
MTDiscord |
<Warr1024> erle, there's no such thing as a non-temporary solution, so... |
| 14:51 |
kilbith |
we can't do that with another camera for each node |
| 14:52 |
erle |
what |
| 14:52 |
|
Baytuch joined #minetest-dev |
| 14:52 |
MTDiscord |
<Warr1024> painting onto an in-world surface vs. stenciling out an in-world surface would be different things |
| 14:52 |
erle |
just paint the damn thing and let's make euclidean manifolds |
| 14:53 |
MTDiscord |
<Warr1024> Personally, I'd like to see both portals and cameras painted onto a surface ... but I'll take them separately in any order. |
| 14:53 |
erle |
short reminder how duke nukem did mirrors, i am sure there was no big postprocessing framework involved https://nitter.net/Foone/status/1372768129395224578 |
| 14:53 |
MTDiscord |
<ZweiKamel> Technically, putting the cart before the horse is just as doable as putting the cart behind the horse. For example, trains regularly have an engine that pushes or pulls cars depending on which direction they are heading in. If you were to surgically implant a steam engine and wheels onto a horse, it would make a lot of sense to put the cart in front of it. |
| 14:53 |
kilbith |
erle: yeah sure, but it's different for a STATIC scene |
| 14:54 |
erle |
kilbith why can't your camera move |
| 14:54 |
kilbith |
clientmap ain't static |
| 14:54 |
erle |
explain a bit more please |
| 14:54 |
kilbith |
for each reflective node you need to add up a new CameraSceneNode |
| 14:54 |
MTDiscord |
<Warr1024> duke nukem's way of doing mirrors was kinda bizarre, considering that the engine was already a portal renderer, and it was good to see that they fixed all that weirdness for the later shadow warrior. |
| 14:54 |
erle |
oh |
| 14:54 |
kilbith |
which isn't efficient at all |
| 14:54 |
MTDiscord |
<ZweiKamel> kilbith: how does the camera know where to render, and at what direction? how can you configure that? |
| 14:55 |
MTDiscord |
<ZweiKamel> can you feed it co-ordinates and a heading? |
| 14:55 |
kilbith |
but in a static scene it perfectly fits it |
| 14:55 |
kilbith |
ZweiKamel: yes you can specify position and rotation |
| 14:55 |
MTDiscord |
<ZweiKamel> oh damn you can ping users over IRC? |
| 14:56 |
erle |
kilbith you are talking among a group of people who have a ten year history of “let's spawn more particles” :P |
| 14:56 |
MTDiscord |
<ZweiKamel> kilbith: is the source code online? can you possibly link it or an example? |
| 14:56 |
kilbith |
patience |
| 14:56 |
MTDiscord |
<ZweiKamel> lol |
| 14:56 |
MTDiscord |
<ZweiKamel> ok |
| 14:57 |
|
Toothless joined #minetest-dev |
| 14:57 |
kilbith |
but yeah, I'd love to bring SSR for 5.6 |
| 14:59 |
MTDiscord |
<ZweiKamel> the camera functionality is certainly impressive |
| 15:00 |
MTDiscord |
<ZweiKamel> is the camera itself tied to the formspec, or could you have a camera independent of a formspec? |
| 15:00 |
kilbith |
for the moment I'll target GUI and HUD |
| 15:01 |
MTDiscord |
<ZweiKamel> oh okay |
| 15:01 |
MTDiscord |
<ZweiKamel> is it possible to have several cameras in a single formspec? |
| 15:01 |
kilbith |
well sure |
| 15:01 |
kilbith |
it's meant for that |
| 15:01 |
MTDiscord |
<ZweiKamel> i wonder if you could actually make a kind of security camera thing with that |
| 15:01 |
MTDiscord |
<ZweiKamel> sounds like a fun idea actually lol |
| 15:02 |
MTDiscord |
<ZweiKamel> keep up the great work! |
| 15:42 |
|
Thomas-S_ joined #minetest-dev |
| 15:53 |
|
izzyb joined #minetest-dev |
| 15:57 |
|
nore joined #minetest-dev |
| 16:02 |
|
wsor4035 joined #minetest-dev |
| 16:29 |
|
Alias joined #minetest-dev |
| 17:01 |
Zughy[m] |
Wuzzy: since you've taken care of the tool documentation, any chance you can have a look at this? https://github.com/minetest/minetest/issues/3864 |
| 17:04 |
MTDiscord |
<Warr1024> When making a link to a specific line in a document, you should use the commit-id in the URL instead of the master branch name, because lines may be added/removed in that doc over time, causing your URL to point to the wrong lines. If you point to the right line in an old commit, at least it's still pretty clear what you're referring to, and generally feasible to find the corresponding content in the current version. |
| 17:22 |
Wuzzy |
Zughy[m]: the link it 6 years outdated :( |
| 17:23 |
Zughy[m] |
Wuzzy: look for "capabilities of", now it says "item" instead of "tool" |
| 17:23 |
sfan5 |
OTOH it's easy to determine how the file looked on 15 Mar 2016 and find the correct line |
| 17:24 |
MTDiscord |
<Warr1024> Right, it's just a question of whether you want to present barriers to the reader early in the process, or later, after they've gotten more invested in it. |
| 17:25 |
Zughy[m] |
OTOH? Damn these acronyms |
| 17:25 |
Wuzzy |
the issue is very very vague on what is the actual bug |
| 17:25 |
MTDiscord |
<Warr1024> DTA |
| 17:26 |
Wuzzy |
this is one of these issues that stays up forever cuz noone understands it xd |
| 17:26 |
MTDiscord |
<ZweiKamel> lol |
| 17:26 |
Zughy[m] |
*reaches the "possible close" label |
| 17:27 |
Zughy[m] |
what a great sensation every time |
| 17:27 |
Wuzzy |
https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L2006 |
| 17:27 |
Wuzzy |
Do you see any issue with that secion? |
| 17:27 |
MTDiscord |
<Warr1024> Arguably it's no longer as relevant anymore because the idea that MTE would enforce game-specific conventions about tools is probably an anachronism. |
| 17:28 |
MTDiscord |
<Warr1024> Stuff like how to use tool groups or what they should mean should probably be moved into MTG anyway. |
| 17:28 |
Wuzzy |
no |
| 17:28 |
Zughy[m] |
Also, May 28 big party for the 13 "possible close" PRs that will be brutally closed, possibly reaching <100 PRs |
| 17:29 |
MTDiscord |
<Warr1024> Need a special "possible brutal close" label for those... |
| 17:29 |
Wuzzy |
ah i can get what the issue poster meant. maybe they claim the clculated times are incorrect |
| 17:29 |
Wuzzy |
this can be verified |
| 17:29 |
Wuzzy |
also, the formula for calculating these is already part of the documentation |
| 17:32 |
Wuzzy |
oh, i found a syntax error in the example. missing comma. :D |
| 17:32 |
Wuzzy |
the issue poster is correct after all XD |
| 17:33 |
MTDiscord |
<ZweiKamel> i love how in programming, showing somebody where they missed a comma is helpful whereas in english class, it gets you punched in the face and sent to the dean's office and suspended for engaging in violence |
| 17:40 |
erle |
Zughy[m] “possible close” as a result of “no one understands it” seems wrong |
| 17:40 |
MTDiscord |
<Warr1024> "possible close" is the only path to closure for some issues. If it's rotted out to the point where nobody can make any use of it, you might as well just close it. |
| 17:41 |
Zughy[m] |
^ |
| 17:41 |
MTDiscord |
<Warr1024> If it's REALLY a problem someone will reopen/refile it. |
| 17:41 |
erle |
LOL |
| 17:41 |
erle |
given that i have had reproducible crashes tagged with “unreproducible” and “possible close”, well |
| 17:41 |
erle |
maybe it should only come after it is clear there is no other option |
| 17:42 |
erle |
i mean “unconfirmed” |
| 17:42 |
erle |
unreproducible is not a tag i think |
| 17:42 |
Zughy[m] |
we're not talking about crashes, we're taking about some documentation that has been changed throughout the years, don't |
| 17:42 |
erle |
oh |
| 17:45 |
MTDiscord |
<Warr1024> A crash that's unreproducible will eventually "rot" as well, in the sense that we don't know if it was inadvertently fixed and no longer relevant. If you can make it happen again, then it either shouldn't be marked "not repro" or, if you actually care about the issue, it may be worth investing a bit more time on repro instructions. |
| 17:45 |
MTDiscord |
<Warr1024> If something is super rare and only happens 1 in 1000 times, it's not like your repro instructions can't be something like "run this script for 2 hours and see if there's a crash in the log". That would still count, I think. |
| 17:47 |
MTDiscord |
<Warr1024> Given that, it would be nice if the triage process included running through the repro steps and removing the "unconfirmed bug" label from stuff ... but I don't know whether it is or not, or maybe it's just a process that takes some time...? |
| 17:49 |
Zughy[m] |
yes, it includes that, but I'm definitely better at scavenging and keeping things in order |
| 17:50 |
sfan5 |
can we merge some PRs today |
| 17:50 |
Zughy[m] |
appguru and erle asked to become triagers for confirming bugs as far as I remember |
| 17:50 |
appguru |
yes |
| 17:54 |
sfan5 |
merging #12328, #12326, #12316 in 5m |
| 17:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/12328 -- DevTest: Fix broken PNG textures by Wuzzy2 |
| 17:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/12326 -- Add vcs-browser and contribute URLs to Appdata by JakobDev |
| 17:54 |
ShadowBot |
https://github.com/minetest/minetest/issues/12316 -- Remove confusing message by savilli |
| 17:57 |
Wuzzy |
Zughy[m]: #12339 |
| 17:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/12339 -- Add missing comma in example in lua_api.txt by Wuzzy2 |
| 17:57 |
erle |
oh, btw, i notice that one of the TGA test textures i made is upside down. the reason for that is that i used imagemagick, which for a specific combination of “where does the image start” (i.e. top left or bottom left) and some other stuff i have not figured out manages to flip every picture that you convert with it. |
| 17:57 |
erle |
like when you do „convert file1.exta file2.extb” your image may just be upside down lol |
| 17:58 |
Wuzzy |
frankly, I think it's a good idea to be more aggressive with closing issues with terrible information, only like 2 sentences and people try to figure out what the issue poster actually meant |
| 17:59 |
Wuzzy |
#3864 is a good example for poorly-worded issues, except it is *technically |
| 17:59 |
ShadowBot |
https://github.com/minetest/minetest/issues/3864 -- API Tool Example Incorrect |
| 17:59 |
Wuzzy |
* valid |
| 18:00 |
Wuzzy |
issues like these are kept up forever because nobody is bold enough to close them because of the fear that they *might* be valid. |
| 18:00 |
Wuzzy |
imho if the issue poster is too lazy with supplying us with basic info, just close the damn thing :D |
| 18:00 |
MTDiscord |
<Warr1024> erle: re: the imagemagick flipping bug, just use the "labyrinth guard algorithm" and process it a second time XD |
| 18:02 |
Wuzzy |
When is the next meeting btw? |
| 18:19 |
appguru |
I've found the cause for server-client entity desync |
| 18:19 |
sfan5 |
let me guess: the design is fundamentally broken |
| 18:19 |
appguru |
It is acceleration being implemented incorrectly |
| 18:20 |
appguru |
See e.g. https://github.com/minetest/minetest/pull/11855 |
| 18:20 |
sfan5 |
on which side |
| 18:20 |
appguru |
The error is dependent on the step size |
| 18:20 |
appguru |
Clients use a different step than servers |
| 18:20 |
appguru |
I.e. the client runs at 60 steps per second (dtime 1/60) whereas the server runs at 10 SPS |
| 18:20 |
sfan5 |
well which one is right |
| 18:20 |
appguru |
Neither |
| 18:20 |
appguru |
Fleckenstein is right |
| 18:20 |
appguru |
His formula |
| 18:20 |
erle |
what did fleckenstein say? |
| 18:21 |
appguru |
Erle: s' = (v + v')t/2 rather than s' = v't |
| 18:21 |
sfan5 |
appguru: by neither you mean both are wrong |
| 18:21 |
appguru |
Both client and server do the math wrong, yes |
| 18:21 |
appguru |
Unfortunately fixing it is necessarily compat-breaking |
| 18:21 |
erle |
> Fix server-side luaentity acceleration code in case it's wrong like the client side player acceleration code. |
| 18:22 |
erle |
i hope no one actually takes this gravity thing seriously as a default |
| 18:22 |
erle |
it would ruin so many games |
| 18:22 |
erle |
as an option, fine |
| 18:22 |
appguru |
Yes, but is fundamentally broken currently |
| 18:22 |
appguru |
Sure we can't break backwards compat |
| 18:22 |
appguru |
But for 6.0 this needs to be among the breakages |
| 18:22 |
MTDiscord |
<Warr1024> I mean to be fair, gravity has ruined way more than just games. |
| 18:22 |
appguru |
This isn't just gravity BTW |
| 18:22 |
appguru |
This applies to all acceleration |
| 18:23 |
appguru |
Gravity just usually happens to be the only acceleration used |
| 18:23 |
MTDiscord |
<Warr1024> but only to acceleration? |
| 18:23 |
appguru |
Only to acceleration, yes |
| 18:23 |
appguru |
Hence all projectile physics are broken |
| 18:23 |
erle |
yeah but come on there is like 10 years of history of “wrong” physics |
| 18:23 |
appguru |
erle: The implications of this are HUGE |
| 18:23 |
MTDiscord |
<Warr1024> I was hoping it might be related to https://github.com/minetest/minetest/issues/12317 but soundsn't like it is. |
| 18:23 |
erle |
if you change this, will my egg-throwing mesecons machine still hit its target? |
| 18:24 |
appguru |
No, it won't |
| 18:24 |
appguru |
But currently you are relying on undefined behavior that it hits its target in the first place |
| 18:24 |
appguru |
You're relying on the server step |
| 18:24 |
MTDiscord |
<Warr1024> I suspect that 12317 is also a case of "I had to implement a calculus thing but didn't know how to integrate over time" but might be a different manifestation of that. |
| 18:24 |
appguru |
If lag changes server steps, it will miss its target |
| 18:25 |
MTDiscord |
<Warr1024> I can confirm that lag step sizes can have a very big impact on entity aim, yeah. |
| 18:25 |
erle |
i can confirm that lag has a big impact on everything |
| 18:25 |
erle |
like prediction or if i am going to get out of the water before drowning |
| 18:25 |
appguru |
Currently, the percentual error after a time may be calculated as `dtime / time`. |
| 18:25 |
MTDiscord |
<Warr1024> I've designed most of my game mechanics to be very lag tolerant and sometimes test under extreme artificial lag, but engine mechanics tend to break down first. |
| 18:25 |
appguru |
erle: yes, but this is fixable! |
| 18:25 |
appguru |
you'd just have to integrate properly (as Fleckenstein did) |
| 18:26 |
MTDiscord |
<Warr1024> tbh lag is only partially fixable. Integrating properly only fixes an uninterrupted trajectory, but if the object was supposed to collide with something, then respond to that collision in some way, there's no way to fix that, really. |
| 18:26 |
MTDiscord |
<Warr1024> it'd be nice to get at least the first collision to behave consistently of course |
| 18:26 |
appguru |
granted |
| 18:27 |
MTDiscord |
<Warr1024> but the more I run into this class of problem, the more I start to think that the solution is less "integrate properly" and more "run the internal simulation with a fixed step size" and then integrating correctly becomes less critical. |
| 18:29 |
appguru |
The error after a single step is 100% (dt/dt =1) |
| 18:34 |
MTDiscord |
<Warr1024> If it could be switchable, like the way there's that "new player movement" option, then I'd probably just enable it for my game. |
| 18:34 |
appguru |
Not just players, all entities |
| 18:34 |
MTDiscord |
<Warr1024> I mean I'm thinking like per-world. |
| 18:35 |
MTDiscord |
<Warr1024> you enable it, it's replicated to the client, and it makes every thing in the world operate with the corrected math. Not everything needs to be all that fine-grained. |
| 18:35 |
MTDiscord |
<Warr1024> People can start migrating to it for an eventual 6.0 cutover, and stuff that relies on the old behavior can keep compat. |
| 18:36 |
MTDiscord |
<Warr1024> then for 6.0 I guess you just flip around the default and deprecate/remove the old jank math. |
| 18:36 |
erle |
appguru my suspicion is that fleckenstein hat integration in school and then was like WAIT I KNOW WHERE TO USE IT |
| 18:36 |
appguru |
yes, Fleckenstein must've had the basic physics courses the Minetest devs clearly lacked |
| 18:37 |
MTDiscord |
<Warr1024> Ironically a lot of MT core devs actually have had pretty strong backgrounds in physics... |
| 18:37 |
appguru |
well, not the one who wrote this code I suppose |
| 18:37 |
appguru |
whoever that is :-) |
| 18:37 |
MTDiscord |
<Warr1024> IIRC at least rubenwardy or paramat would not have made this mistake had they been aware of this. |
| 18:37 |
MTDiscord |
<Warr1024> Well, I once had to fix a bug ages ago caused by somebody not knowing trig, so I guess somebody not knowing calculus is not a stretch :-D |
| 18:37 |
erle |
some even have a background in programming. and still minetest runs on undefined behaviour and MSN crystals! |
| 18:38 |
erle |
i once did runge-kutta integration for a physics simulation and then i figured out that you can just do a flyby if you get close enough to another object and gain speed |
| 18:38 |
erle |
physics, not even once! |
| 18:43 |
appguru |
Anyways, https://github.com/minetest/minetest/issues/12340 |
| 18:44 |
MTDiscord |
<Warr1024> tbf sometimes the janky physics can still be a valid part of the game. IRL tunneling happens only on quantum scales, but if your collision detection is sloppy enough, what constitutes such a scale just gets a bit larger in your game. |
| 18:45 |
MTDiscord |
<Warr1024> There's no real way around the "stuff unloads in mapblock units" thing that can leave machines half loaded and half unloaded, so I expose the mapblock boundaries to players via an in-game mechanism (they are meant to play without debugging enabled) so players can account for it in their designs. |
| 18:47 |
erle |
Warr1024 elaborate please |
| 18:54 |
MTDiscord |
<Warr1024> elaborate on which thing? |
| 18:57 |
erle |
Warr1024 what is the mechanic about mapblocks |
| 18:59 |
MTDiscord |
<Warr1024> Well what I ended up settling on is anywhere an optic beam crosses a mapblock boundary, it generates some subtle sparks floating along that boundary. |
| 19:00 |
MTDiscord |
<Warr1024> So basically you can visualize where mapblock boundaries are, so you can plan around them proactively, instead of just discovering them via your machines not working the way you expect when you travel far enough away. |
| 19:04 |
|
proller joined #minetest-dev |
| 20:01 |
sfan5 |
distributions that have updated to 5.5.1 already (according to repology.org): alpine linux, chocolatey, fedora, freebsd, homebrew, openmandriva, scoop |
| 20:26 |
Wuzzy |
NICE |
| 20:44 |
|
x2048 joined #minetest-dev |
| 20:48 |
x2048 |
kilbith: Regarding the shadow updae lag, would this be an improvement: https://github.com/x2048/minetest/tree/shadows_frequency? |
| 20:48 |
x2048 |
*shadow update |
| 21:12 |
|
hlqkj_ joined #minetest-dev |
| 21:13 |
Zughy[m] |
is #3476 still relevant, considering we have a roadmap? |
| 21:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/3476 -- A clear mission statement for Minetest is missing. |
| 21:20 |
MTDiscord |
<ZweiKamel> lol |
| 21:20 |
MTDiscord |
<ZweiKamel> minetest isn't just off the rails, there aren't any rails to begin with |
| 21:23 |
Zughy[m] |
you should have been here two years ago, when the roadmap wasn't even a thing and nobody had any idea where to go |
| 21:25 |
MTDiscord |
<ZweiKamel> what a stupid bucket :trollface: |
| 21:26 |
MTDiscord |
<Benrob0329> Rails are overrated, magnetic hover carts are the way to go |
| 21:27 |
MTDiscord |
<ZweiKamel> nonono |
| 21:27 |
MTDiscord |
<ZweiKamel> cars |
| 21:27 |
MTDiscord |
<ZweiKamel> body pillows |
| 21:27 |
MTDiscord |
<ZweiKamel> airplanes |
| 21:27 |
MTDiscord |
<ZweiKamel> and selling texture packs for 9,999$ |
| 21:28 |
MTDiscord |
<ZweiKamel> harshtest ™️ |
| 21:31 |
MTDiscord |
<Warr1024> "A clear mission statement for Minetest is missing." <-- it's not missing, it's just clear. Try raising the opacity. |
| 22:09 |
kilbith |
x2048: looks good yeah - there's no performance concern to have from map update when you activate ultra high resolution and that your HW can support it |
| 22:10 |
kilbith |
* ultra high resolution shadows |
| 22:11 |
kilbith |
we need to revise the rules btw, there should be a lead core-developer role and their approval counts for 2. |
| 22:12 |
kilbith |
and I vote for sfan5 to be the lead dev as he is more responsible and more consistent on the long run than anyone else |
| 22:12 |
kilbith |
^ celeron55, opinion? |
| 22:35 |
|
panwolfram joined #minetest-dev |
| 23:10 |
|
queria joined #minetest-dev |
| 23:28 |
MTDiscord |
<Warr1024> You mean create a sort of "steward benevolent dictator" role to supplant our "benevolent dictator at large"? That can be a very high-risk-high-reward way to run a project, though MT might be at a point in its lifecycle where it's a lot harder to get support for something like that. It's easier to implement when there aren't so many existing dependants demanding stability, and it's a lot easier lost than added. |
| 23:29 |
MTDiscord |
<Warr1024> I would kind of want to know though how often it happens that sfan approves of something but can't get a second. It seems like the things that don't make it to 2 approvals tend to be things that everyone feels unsure about... |
| 23:52 |
MTDiscord |
<ZweiKamel> the steward benevolent dictator should be Warr1024 because he made funny eggcorn game |
| 23:52 |
MTDiscord |
<ZweiKamel> and also because he's rather knowledgeable about minetest |
| 23:55 |
MTDiscord |
<Warr1024> My time might be a bit too unreliable for that. |
| 23:55 |
|
kilbith joined #minetest-dev |
| 23:55 |
MTDiscord |
<Warr1024> Also I'm not sure "benevolent" really fits :-) |
| 23:56 |
MTDiscord |
<ZweiKamel> lol |
| 23:56 |
MTDiscord |
<ZweiKamel> nc_stairs |
| 23:56 |
MTDiscord |
<ZweiKamel> :trollface: |
| 23:56 |
|
AliasAlreadyTake joined #minetest-dev |
| 23:57 |
kilbith |
ZweiKamel: please refrain from making noise in this channel |
| 23:57 |
kilbith |
Warr1024: your moderation job btw |
| 23:58 |
MTDiscord |
<ZweiKamel> sorry, i like to mix in jokes with serious statements |
