| Time |
Nick |
Message |
| 00:12 |
|
AliasAlreadyTake joined #minetest-dev |
| 00:23 |
|
Extex joined #minetest-dev |
| 00:54 |
|
v-rob joined #minetest-dev |
| 00:57 |
|
Taoki joined #minetest-dev |
| 03:28 |
|
queria^clone joined #minetest-dev |
| 03:34 |
|
queria^clone joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:55 |
|
YuGiOhJCJ joined #minetest-dev |
| 07:35 |
|
v-rob joined #minetest-dev |
| 08:02 |
|
appguru joined #minetest-dev |
| 08:34 |
|
calcul0n joined #minetest-dev |
| 08:35 |
|
appguru joined #minetest-dev |
| 08:37 |
|
appguru joined #minetest-dev |
| 10:32 |
MTDiscord |
<Sublayer plank> why did we keep the BMP image loader in IrrlichtMt now again? |
| 10:34 |
sfan5 |
it's used internally by irrlicht and low complexity |
| 10:35 |
|
calcul0n joined #minetest-dev |
| 10:40 |
|
calcul0n joined #minetest-dev |
| 11:34 |
|
appguru joined #minetest-dev |
| 12:35 |
|
calcul0n joined #minetest-dev |
| 12:42 |
|
calcul0n joined #minetest-dev |
| 12:53 |
|
calcul0n joined #minetest-dev |
| 13:08 |
|
calcul0n joined #minetest-dev |
| 14:32 |
|
calcul0n joined #minetest-dev |
| 14:57 |
|
calcul0n joined #minetest-dev |
| 15:13 |
MTDiscord |
<Sublayer plank> Yeah so Irrlicht uses BMP for its built-in font, which Minetest uses in some places like the open file dialog (if you stub out CGUIEnvironment::loadBuiltInFont() you can notice that the X character disappears from the close dialog button). But you can convert it into a PNG image, reencode that and put it in BuiltInFont.h and it will still work, just like that (close dialog button retains its X!). Then the BMP loader can be |
| 15:13 |
MTDiscord |
removed without any adverse effects. |
| 15:13 |
MTDiscord |
<Sublayer plank> Relevant commit doing this in practice: https://github.com/rollerozxa/irrlicht/commit/850579d4bbc00b8241c244287367d7cb7d3a3de2 |
| 15:13 |
MTDiscord |
<Sublayer plank> About compatibility and use of BMP by mods, I'd be hard pressed to see any mod make use of BMP images. Even for programmatically generating images there's TGA which is even more simple than the BMP format and therefor easier to generate programmatically. |
| 15:22 |
sfan5 |
we intended to get rid of TGA though, not BMP |
| 15:25 |
|
Fixer joined #minetest-dev |
| 15:55 |
MTDiscord |
<josiah_wi> Hmm, I may need to update the unit tests slightly if this is removed. |
| 15:57 |
MTDiscord |
<Sublayer plank> Well yeah, but the only reason hecks kept BMP to begin with was due to IrrlichtMt not being able to compile anymore after that. TGA was removed but it was later figured out that it is both a simpler format than BMP and that it is actually being used in the wild due to this (only minetest mod using BMP that I can find was a game from 2016 that includes its own fork of minetest 0.4.13 and probably isn't compatible with minetest |
| 15:57 |
MTDiscord |
5.x anyways). |
| 15:58 |
MTDiscord |
<Sublayer plank> Also I really don't want to bring up the whole "TGA vs. the world" drama again and wasn't intending to, I just wanted to put this out there because of the fact BMP was kept not because it was seen as a necessary image format but because it seemed necessary in order to not break Irrlicht, and I wanted to show that it is actually not the case. |
| 15:59 |
MTDiscord |
<Sublayer plank> @josiah_wi oh, the unit tests make use of BMP images don't they? |
| 16:00 |
MTDiscord |
<josiah_wi> Ideally only the ones that actually test BMP loading specifically, which I think would be one test. |
| 16:39 |
MTDiscord |
<Jordach> minor nitpick and minor issue |
| 16:39 |
MTDiscord |
<Jordach> when can we smoothly interpolate the player camera |
| 16:39 |
MTDiscord |
<Jordach> from Lua |
| 16:43 |
MTDiscord |
<Warr1024> smoothly interpolate? Heh, just being able to disable user camera movement without having to jank it back into place every globalstep would be nice ? |
| 16:46 |
MTDiscord |
<Jordach> people complain of "lag" but i know for sure the entities aren't lagging to death |
| 16:47 |
MTDiscord |
<Jordach> the engine already has smooth rotation support for entities based on velocity |
| 16:49 |
MTDiscord |
<Warr1024> In cases where you can do something every step, but not every frame, I tend to feel that as jank or judder, not as "lag". If your globalstep is 20Hz and your refresh is 60Hz, 2 out of every 3 frames, not only is the camera not animating smoothly (I could live with 20Hz camera movement) but can actually be yanked all over the place by the player's mouse movement (that's very noticeable). |
| 16:50 |
|
Fleckenstein joined #minetest-dev |
| 17:00 |
MTDiscord |
<luatic> Currently there's only set_look_dir + cinematic mode interpolation (which messes with get_look_dir though) |
| 17:10 |
|
fluxionary joined #minetest-dev |
| 17:17 |
|
Extex joined #minetest-dev |
| 17:24 |
|
proller joined #minetest-dev |
| 17:26 |
|
calcul0n joined #minetest-dev |
| 17:29 |
|
Taoki joined #minetest-dev |
| 18:57 |
|
calcul0n_ joined #minetest-dev |
| 19:16 |
MTDiscord |
<Benrob0329> I would like a wider core dev opinion on a "simple" suggestion to help improve our settings situation: Make the server only read from a world-specific "world.conf". |
| 19:16 |
MTDiscord |
<Jordach> And what about games that are transient with worlds, i.e. they're extremely disposable |
| 19:17 |
MTDiscord |
<Benrob0329> This would allow games to have default settings for new worlds without users unwittingly screwing it up from past changes, and allow games to force certain settings without screwing over every other game. |
| 19:19 |
MTDiscord |
<Benrob0329> It would also allow per-world settings for things (as has been requested for years) inherently. |
| 19:19 |
MTDiscord |
<Benrob0329> @Jordach Can you give a more specific example, and also why we'd need to care about that specific existing problem right now? |
| 19:24 |
MTDiscord |
<Jordach> the problem starts at the fact that if a game needs worlds to be regenerated at server end world.mt and oestensibly the conf also need to be destroyed at pre server start |
| 19:26 |
MTDiscord |
<Benrob0329> Thats just sounds like games need to be able to require the dummy backend, which is a different issue. |
| 19:27 |
MTDiscord |
<Jordach> dummy backend means no files stored in worlds dir either |
| 19:27 |
MTDiscord |
<Benrob0329> Can you please stop trying to bring in other issues (that are neither helped nor harmed by my suggestion) than the one I'm trying to suggest a solution for? |
| 19:28 |
MTDiscord |
<Benrob0329> Its almost like you want to contribute to the bureaucratic hell we go through. |
| 19:29 |
MTDiscord |
<Jordach> anytime something needs to be changed for a subgame or mod it involves a full server/game restart |
| 19:37 |
sfan5 |
which settings do you have in mind that subgames want to set? |
| 19:40 |
MTDiscord |
<Benrob0329> Yes |
| 19:41 |
MTDiscord |
<Benrob0329> aka an arbitrary amount, because different games want to be able to override the defaults of any number of settings. |
| 19:44 |
sfan5 |
well it can only be server settings and of those movement settings seems like the most obvious target |
| 19:45 |
MTDiscord |
<Benrob0329> The current issue is that users can set settings in minetest.conf and completely disable games which rely on settings to be within a certain range. These can include the active block range, player movement settings, and others. |
| 19:46 |
MTDiscord |
<Benrob0329> And games which get around this by forcing settings to certain values need to take care to reset them, and many don't. |
| 19:47 |
MTDiscord |
<Benrob0329> Splitting the server and client settings would seem to solve multiple issues and reduce the room for user error when tweaking game settings. |
| 19:48 |
MTDiscord |
<Benrob0329> (Again, specifically splitting server settings into a world-specific conf file) |
| 19:50 |
MTDiscord |
<Benrob0329> I'm going to name drop @Warr1024 as he's expressed interest in this kind of solution. |
| 19:52 |
|
Extex joined #minetest-dev |
| 19:58 |
Sokomine |
quick question: is there a way to enable logging of chat? |
| 19:59 |
Sokomine |
(for the client to a local file) |
| 20:07 |
MTDiscord |
<Jonathon> seems like something for #minetest but you could do that with a csm |
| 20:10 |
Sokomine |
many servers disable that, so it's not a solution. i patched my mt years ago to do such logging but then forgot. it's annyoing to maintain local patches |
| 20:11 |
MTDiscord |
<Jonathon> seems you already know the answer to your question then |
| 20:12 |
MTDiscord |
<Jonathon> in theory minetest saves chat till the client is closed at least. provable by open one world, typing something into chat, opening another world and scrolling up |
| 20:13 |
Sokomine |
thanks. i'm aware of that and have used it to catch up on hist in case of server crashes |
| 20:13 |
Sokomine |
just want text logged to a file for easier reading |
| 20:17 |
|
calcul0n joined #minetest-dev |
| 20:25 |
|
calcul0n joined #minetest-dev |
| 21:04 |
MTDiscord |
<j45> That can very easily be done with a quick mod or csm |
| 21:24 |
|
calcul0n joined #minetest-dev |
| 21:45 |
Sokomine |
no, sadly it can't be fixed with a mod. those are not loaded when joining a server. and csms can be disabled and don't have access to the file system. guess i have to patch my mt again |
| 21:45 |
|
Extex joined #minetest-dev |
| 21:47 |
celeron55 |
it's a valid feature request, but i wonder how many would actually use it |
| 21:48 |
celeron55 |
what if there was a base level csm allowance that would... well, allow a csm to read chat and write it on disk, even if the server disallowed csms |
| 21:49 |
celeron55 |
some might think of that as a slippery slope |
| 21:53 |
MTDiscord |
<exe_virus> We already can't trust the client, as it's relatively easy to make a "hacked client", so why bother with the default restriction or even have it? |
| 21:58 |
|
Taoki joined #minetest-dev |
| 21:58 |
Sokomine |
in a way, yes. in general it's a good idea that csms are so much restricted. servers disallowing logging seems to be a privacy consideration in general, except that so much happens on discord now that it's a lost case |
| 21:59 |
Sokomine |
yes. annoying to have to go to a hacked client just to support one's memory or to read what happened more than x lines ago if beeing afk lasted longer than planned |
| 21:59 |
celeron55 |
well it makes sense that a hacked client shouldn't be *trivial* to make |
| 22:10 |
|
v-rob joined #minetest-dev |
| 22:10 |
MTDiscord |
<Jonathon> making it isnt the issue, the issue is that anyone can now go grab df and use it, or change a few lines and compile |
| 22:13 |
|
erlehmann joined #minetest-dev |
| 22:24 |
MTDiscord |
<j45> There is a way you can do it basically without having to use csms... You can use anon5555's Go mt protocol implementation (https://pkg.go.dev/github.com/anon55555/mt) and log into the server with that and every packet you get, see if it is a chat message and if so, save it to a file.... I have actually made a bot that does just this for oysterity but it is in a private repo for now |
| 22:25 |
MTDiscord |
<j45> When i get back home from holidays, i might make the repo public |
| 22:26 |
MTDiscord |
<j45> We should probs move to #minetest |
| 22:46 |
Sokomine |
hmm. that'd require a seperate client then. not a great solution either. the client would still be receiving all those other packages and add load to the server |
| 22:47 |
MTDiscord |
<Warr1024> Could really do the same as a proxy so you just connect one client... |
| 22:48 |
MTDiscord |
<Benrob0329> @ExeVirus Because server owners complained when CSMs revealed numerous security vulnerabilities |
| 22:49 |
MTDiscord |
<Benrob0329> And mild annoyances like chat spam |
| 22:52 |
erlehmann |
j45 there is a hacker conference starting in a few days (rc3), i can show your stuff a few ppl with too much time on their hand if you publish before the end of the year |
| 22:53 |
MTDiscord |
<j45> I will try do it from my phone if u want |
| 22:54 |
erlehmann |
<sfan5> we intended to get rid of TGA though, not BMP |
| 22:54 |
erlehmann |
TGA is lower complexity for the same result btw. |
| 22:54 |
erlehmann |
which is the reason why game devs nowadays use TGA and not BMP |
| 22:55 |
erlehmann |
try figuring out how to encode/decode each format |
| 22:56 |
erlehmann |
like, *IF* you want a low-complexity format that needs no zlib etc. pp., use TGA, throw BMP out |
| 22:57 |
erlehmann |
> The current issue is that users can set settings in minetest.conf and completely disable games which rely on settings to be within a certain range. |
| 22:58 |
erlehmann |
i think this can even happen accidentally. for example, it is possible to crash a lot of mods at startup with a non-default blocksize. |
| 22:58 |
erlehmann |
for example, because they assume they can search the entire volume of a mapblock. |
| 23:00 |
sfan5 |
what is a "non-default blocksize"? a block is always 16 nodes, there is no setting for this |
| 23:00 |
erlehmann |
chunksize, sorry |
| 23:01 |
sfan5 |
yea could be |
| 23:01 |
sfan5 |
though the api provides all means to do this safely IIRC |
| 23:01 |
erlehmann |
true, but game mechanics actually rely on stuff not colliding |
| 23:02 |
erlehmann |
i.e. the wuzzy mineshaft burrowing thing starts in the middle of a mapchunk IIRC |
| 23:03 |
erlehmann |
sfan5, i am not saying it is the engines fault that modders write bad code, it is just that having game/world-specific settings is an easy way to sidestep the accumulated cruft |
| 23:16 |
|
Extex joined #minetest-dev |
| 23:21 |
|
v-rob joined #minetest-dev |
| 23:39 |
|
v-rob joined #minetest-dev |
| 23:53 |
|
v-rob joined #minetest-dev |
